Make a wish. It might be granted! #awswishlist
This is a hiatus for a minute on my series on Automating Cybersecurity Metrics to tell you about the AWS Wish List.
AWS Feature Requests
Back when I worked at Capital One on the cloud engineering team one of the things I was asked to do was to manage the list of AWS features that Capital One wanted AWS to implement. Of course Capital One had a lot of leverage with AWS at the time because they were the first major bank in the United States to move to AWS. And yes they had a breach, but cloud security is complicated and that is what my latest blog series is trying to address.
At any rate, Capital One did help make some major improvements to AWS security. One of the issues with AWS S3 is that it required applications to traverse the Internet in order to put or get objects. This was something Capital One was not keen on doing since prior to cloud any connection to a vendor required a private line (MPLS for those who are familiar) to do business with the bank. Sending data over the Internet was just not cool.
Capital one requested a feature that would allow companies to keep the information off the Internet as it traversed the network from an AWS VPC to an S3 bucket and vice versa. That feature became S3 endpoints. From there S3 endpoints have evolved to Network Endpoints. Now you can send data from application sources to storage sources either within your VPC or at least keep it on the AWS backbone as it traverses the network. It will depend on which services you are using and if they keep all data between regions on the AWS backbone or not.
Capital One obviously had a bit more leverage than you or I do to get new features implemented at AWS, but AWS does listen to customers. If enough people ask, they will implement new features and fix problems. There are different ways to submit requests to AWS but one of the most visible is the AWS Wish List.
#awswishlist
One day as I was frustrated about something I couldn’t do or was not working correctly I randomly tweeted it out on Twitter with the tag #awswishlist. I didn’t realize that anyone else had ever done that before. Out of curiosity I searched for that tag and found that some other people had done something similar.
As it turns out, AWS created a whole website just for the #awswishlist. You can see who is contributing and some of the wishes that have been fulfilled.
You can also head over to Twitter to see what’s on the wishlist and like or retweet your favs. AWS will likely take notice if a particular tweet gets a lot of likes and retweets.
Some of the other ways you can ask for features or fixes on AWS, though I have had little success with some of these not being a huge corporation:
- AWS support in the AWS console
- The feedback link on the AWS site — I’ve been submitting requested changes for SSO, Control Tower, and Organizations and I don’t see that any of them had any effect, unfortunately.
- Some of the AWS services have Github accounts where they publish their road map and people can submit feedback directly on a road map for a specific service.
If you have a TAM (account manager) with AWS and especially if you are a large company paying a lot of money, you will likely have more success with direct feature requests with your account manager. I used to track all our feature requests across the organization with the help of our TAM in a spreadsheet, who submitted it, and when AWS was planning a release of that feature (or if they couldn’t do it.)
There are some things that AWS said were “absolutely not possible” back then that are possible today. For example, we got an increase in the number of security group rules but there was no way to increase the number of rules for a subnet network access control list (NACL). I recently noticed that now you can request an increase (though still limited) to NACL ingress and egress rules but they warn you that might come with a performance degradation. So never say never when it comes to a request. It may take some time for AWS to re-architecture things but if enough people ask — wishes come true!
Bugs and Error Messages
Lately I’ve been working on a new batch of code on AWS and sometimes it’s the littlest thing that takes so much time to resolve. If only the error message was clear I could have fixed the problem in no time and and get back to writing the code that actually accomplishes my objective. Instead I’m digging around on Google and in AWS documentation seeking answers to obscure problems with unclear error messages. I recently started writing a blog post every time I hit one of these obscurities both to help myself in the future and anyone else having the same problem. I’m documenting them on this new blog — Bugs that Bite:
I don’t send all these out in emails because they might not apply to everyone and who wants a bug list? The bugs and error messages are not all related to AWS, that just happens to be the platform I’m working on at the moment. If I switched to Azure or Google I would run into and equal or greater number of problems because I have — while preparing for classes or performing security assessments or penetration tests on those platforms.
My global wish for AWS is that they (and everyone else in the world writing software because I find bugs EVERYWHERE) would take the time to test code thoroughly and write proper error messages. In addition, error handlers can be very helpful in providing a proper response to errors. I don’t want to put every one of these on the wishlist because some of them are too complicated to explain in a tweet, plus there are so many and I don’t want to overload the list with little bugs as opposed to major features or changes.
I put in a general request for AWS to look through this list and address some of these issues. If you’ve ever experienced one of these error messages or problems and feel like a better error message would help please clap for the story to get it to rise to the top of the list.
A wish for penetration testing on AWS that came true
My favorite AWS wishlist item was the request to perform a penetration test without submitting a request form. I think I may have submitted that request multiple times. This was after I was working at Capital One. I debated this item with someone in Seattle at AWS who oversaw or worked with that group located in South Africa at the time, and he tried to tell me it was simply not possible, even though Microsoft and Google allowed it.
Then one day, I was in the middle of my first beta class through 2nd Sight Lab and I realized I forgot to request access for students to perform the pentest lab. Shoot! My students were not going to be able to do the lab! Oh no…I quickly sent an email to AWS begging them to quickly process the request. It was on that day that they told me in an email that I no longer needed to make that request. Hallelujah.
I put a copy of the email on Twitter with a statement: Behold…the rules for Pentesting on AWS have changed… or something to that effect. I went to class and when I got out the Tweet had about 1500 likes and was getting retweeted all over the place, but someone was questioning it because the AWS web site hadn’t been updated. I freaked out a bit because I thought what if I had somehow been sent a bogus email and was telling the world to hack AWS?! But it was true. The website got updated a few days later.
I remember going to an advanced penetration testing class at SANS Institute and someone asked the instructor (who shall remain unnamed because now he is a colleague and friend) how to do penetration tests on AWS. He provided an incorrect answer so I raised my hand and explained that you no longer need to put in that request. I was publicly rebuked and humiliated in front of the class telling me I was wrong. No hard feelings but…I was not wrong.
It is so much easier to perform penetration tests for customers now as a result of that change. There are still limitations on what you can do in a penetration test on AWS so make sure you follow the rules! Someone contacted me and said, “so I can test anyone’s account?” No, only your own.
Now…about that Bug Bounty request…. 🙂
Teri Radichel
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
