There’s a lot of noise about penetration testing cloud workloads, much of it from people who don’t really understand cloud security. I thought I’d lay out my thoughts on the matter. This post isn’t about the skills needed, or typical findings. This is here to cover what the point of a penetration test against an AWS workload is, what a penetration testing program should look like, and how to make it a success. Hopefully, it helps people make better decisions when buying and running engagements like these.
Cloud security is an area of the industry with some of the biggest skill shortages. Combine that with the cloud industry growing at 30-40% a year (judging by AWS’ revenues for the last several years), and to my mind, there’s no better area of security to be getting into right now. There’s a reason for that skills shortage, though - being effective requires more than just technical skills. This post will lay out some advice and direction on how to build the knowledge and approaches you’ll need to succeed.
AWS have released their own security maturity model, which contains a lot of detail on their take as to how to secure your AWS estate. Does it stack up against what we’re seeing in real-world attacks, or the approaches being suggested by the rest of the AWS security community? Unfortunately, I’m not convinced, and I’ll lay out why below.
AWS Access Keys are the credentials used to provide programmatic or CLI-based access to the AWS APIs. This post outlines what they are, how to identify the different types of keys, where you’re likely to find them across the different services, and the order of access precedence for the different SDKs and tools.