This post was originally written for
Trend Micro .Security in the cloud is a shared responsibility. I’ve written about this before, but with AWS re:Invent right around the corner, now is a good time to explore this idea further and see what the model looks like when applied in production.
The Model
Before we dive in, let’s make sure we’re all working with the same understanding on the model itself.
This is a very straightforward model in its presentation.
We start with the view that security is required everywhere, and in order to manage the security aspects of a deployment, we’ll sort various responsibilities into the following areas:
- Physical infrastructure
- Network infrastructure
- Virtualization layer
- Operating system
- Application(s)
- Data
The next step is to then determine who is responsible for the security aspect of each of these areas: AWS (the cloud service provider) or the users (who consume the cloud services).
Depending on the service in question, the answer of “who is responsible for this area?” changes.
The security responsibilities for these areas change depending on the type of service you are consuming.
Using EC2 as an example, AWS is responsible for the physical infrastructure, network infrastructure, and the virtualization layer. Which means that you are responsible for the security of the operation system, applications, and data.
Being a conscientious (a.k.a., rightfully paranoid) security practitioner, you will want to verify that AWS is holding up their end of the bargain (spoiler alert: they are). You can do that by visiting http://aws.amazon.com/compliance and http://aws.amazon.com/security .
Sliding Scale
While EC2 is the most common example used, you have security responsibilities for every service on AWS. These responsibilities are directly related to the type of service. A common view of this sliding scale is:
But I prefer Mark Ryland’s approach for service division . In lieu of IaaS > PaaS > SaaS, Mark takes the approach of infrastructure > container > abstract.
This makes it a lot easier to get an idea of the level of responsibility you have for the security of a service.
EC2, EBS, VPC, and others are infrastructure services. RDS, EMR, OpsWorks, etc., are container services; SQS, SNS, SES, Route53, etc., fall into the abstract category.
The general rule here is that the more abstract the service, the less direct security responsibilities you have.
Controls & Decisions
We use the term “direct security responsibilities” on purpose. With infrastructure services, in order to fulfill your responsibilities, you are going to need to implement, operate, and maintain more security controls.
This will most likely entail at least hardening the operating system and installing third-party controls (like IPS, anti-malware, process monitoring, etc.) in addition to taking full advantage of the options AWS provides like IAM, security groups, and network ACLs.
As you move towards container and abstract services, your need to deploy and maintain direct controls is reduced. Your responsibilities with these services focus more and more on the proper configuration of access management (usually through IAM) and deciding what type of data to process and store.
More to come
While the model is simple to present and understand at a high level, there is a lot of nuance in its application.
For the next couple of weeks leading up to re:Invent, I’m going to use user-specific examples of recent events to demonstrate how the model is applied to various AWS services.
It’s through these examples that you’ll be able to see how the model changes with each service and how you can adjust your security practice to maximize your security posture and the benefits you get from AWS.
If you’d like a sneak peek, you can take a look at from a talk I recently gave an a meetup at AWS HQ. my slides
