Back in the initial days of cloud computing, AWS came out with clear and concise statement on shared security: AWS will take responsibility from the “concrete to the hypervisor,” and the customer is responsible for everything “above the hypervisor.” A clear line was drawn between what your cloud provider would do to protect you and what you had to do to protect yourself.
Over the years, I think AWS has done a great job in keeping that message consistent and trying to educate their customer base. However, as the customer base has increased exponentially and the number of products and features that AWS provides has grown at nearly the same rate, the message is getting lost. Likewise, as you look at the dizzying array of other providers in this space, each with their own security tools and messaging, confusion is setting in.
We regularly conduct surveys and polls and ad-hoc questions to large groups of people, posing questions like “Who is responsible for securing your applications?” and an unnerving amount of people say it is the cloud provider. And it is not just us who are worried.
Bill Murray, AWS Head of Security Programs:
“We are asked this question a lot: ‘What keeps you up at night?’ What keeps us up at night in AWS security is the customer not configuring their applications correctly to keep themselves secure,”
Personally, I think this is a very dangerous position for customers to be in. Cloud providers deliver an incredibly secure infrastructure, far more secure than the vast majority of commercial and government organisations could ever dream of providing. In the “Shared Security Model,”they have their bit sorted.
However, if you don’t have your side of the ‘Shared Security Model’ nailed as well, it is a bit like sitting in a well-built and fortified castle with the gates open as the barbarian hordes come over the hill…
I have recently spoken to a number of very savvy, and large organisations with existing on-prem infrastructures. Ask them what security products they use in that environment and they can list them: firewalls, IDS, log management, WAFs. Ask them what they are using to protect their apps in AWS environments and there is a nervous silence.
Within AWS, you can do away with a lot of the traditional network firewall tools but the application layer is not protected.
One of our customers, Colin Bodell, CTO of Time Inc., stood up at the San Francisco summit and framed the problem perfectly:
“AWS is great for physical security and network security, but when you are building an application, you have to own that security yourself – Amazon does not know what you are building.”
To be honest, I think some of the other cloud providers could be clearer here–we have had customers tell us they do not need application level protection because their cloud provider is covering that. You have to sometimes read between the lines:
“Our infrastructure includes hardware, software, administrative and operations staff, and physical data centers. This cloud platform addresses security risks across its infrastructure with continuous intrusion detection and prevention systems, denial of service attack prevention, regular penetration testing, and forensic tools that help identify and mitigate threats. Customers can reduce the need to invest in these capabilities on their own and benefit from economies of scale in our datacenter infrastructure.”
This is an example of where a cloud provider is talking about how they protect their infrastructure, not yours. As I said earlier, the cloud providers do an incredible job of protecting their infrastructure; however in the shared responsibility model, you are responsible for protecting yours. If you want continuous 24×7 protection of your applications, you might want to give us a ring.
The Shared Security model is well documented by AWS (http://aws.amazon.com/compliance/shared-responsibility-model/) and referenced by Alert Logic.
Curious about who owns what when it comes to security and compliance in AWS? View an on-demand webinar that clears things up: https://www.alertlogic.com/resources/webinars/?commid=124235