We all know about the 2019 Capital One Breach - 106 million customer data records breached, all on AWS. And so when U.S. senators Elizabeth Warren and Ron Wyden called for an investigation of Amazon's role and responsibility in this incident, Amazon's response was more or less "Not our problem. Working as intended."

Although AWS has outlined their security duties in their shared responsibility model, as is their style, it's clear enough to technically pass, and ambiguous enough for loopholes. However, there is no "checklist" that one can neatly gobble up to see what they're responsible for and what AWS is responsible for. However, we can sum up their line in the sand in our first security rule to remember:

Rule #1 - If you can configure it, you're responsible for the security of it.

That means if you launch an EC2 instance, misconfigure a firewall, and allow 106 million customer records to get away from you, AWS will not come to save you. Your ship will sink and AWS will sail right past you, probably in a yacht.

"But why?"

Why aren't there more technical experts, especially those in the AWS space, pinning the blame on AWS? Why, despite the constant stream of S3 bucket breaches, are they not flocking away from AWS? Well, this brings us to our second security rule to remember:

Rule #2 - Everything in AWS is IMPLICITLY DENIED, unless EXPLICITLY ALLOWED. However, EXPLICIT DENIALS trump everything.

This is especially true for Identity and Access Management (IAM), but largely applies to everything in AWS. When you create a new S3 bucket, NO ONE except the root account can access it. When you create a brand new IAM user, they can't do ANYTHING at all. If you create an EC2 instance, unless you open up the firewall or use an input an SSH key pair, NO ONE can access it. If you make a Lambda, same thing, closed to the world by default. In order for anyone to access anything, the AWS account owner must explicitly allow it.

(Yes, there are exceptions, but those are generally for their "PaaS" like services such as LightSail, Elastic Beanstalk, etc. The default VPC (cloud network) also defaults with public internet access, but this seems to be a user experience decision.)

And so, much like your home, if you leave all the doors and windows open, you can't blame the builders and architects if bugs and burglars get in.

"But then, why are there so many breaches?"

Well, unlike a smaller home, with limited openings, AWS is more like a mansion (and potentially haunted) with a massive staff that needs to move throughout. However, since all of the doors, windows, and openings are closed and locked by default...they can't really do anything. Bob the Butler needs to go grab some tonic, and he can't even get out of his room. So you unlock his room, but now he can't get out of the hall. And so you unlock the hall. Meanwhile Mary the Maid also can't get out of her room, and needs to go fetch some gin because a gin and tonic using "micro-servants" is the new best pattern for crafting drinks.

After 100 butlers and maids have asked you to open various doors, what are you likely to do?

"Fine, just unlock them all Jerry!"

Jerry obliges and now himself and Jenkins go skipping down the hallway unhinged and unhindered. Mansion operations start running smoothly, and your micro-servant architecture is flowing perfectly. That is, until you start noticing masked figures intermingling with the staff.

Whispers and mild suspicions at first. Sure, it's been 3 days since you've seen Jerry. In fact Jenkins hasn't been around much either, but then again he was always slow. And so, with your afternoon tea, you flip on the television to find both of those smiling idiots sharing your shower routine with the world.

That was a long rant to get to my point. Why are there so many breaches then? Because it becomes easier to open up everything when you're developing complex services and applications. It's hard enough to build some of these amazing things and this shortcut, whether intentional or through ignorance, speeds things up. But once you do that, it's time consuming and tedious to figure out each and every opening that SHOULD be closed. Closing the wrong opening could result in a temporary service outage and work hours you don't have time for.

No, none of the aforementioned reasons are a good enough excuse, but it's easy to lose sight of the fact that we're not just dealing with machines here. We're dealing with businesses and humans behind machines. Close deadlines can turn filling in security gaps into a low priority. Human memory can just...completely forget there was a gap in the first place. And when there's 100 potential places these gaps could exist? Well...to err is human.

Enjoy Posts Like These? Sign up to my mailing list!

My Tech Guides and Thoughts Mailing List