What All DevOps Teams Should Know About The AWS Shared Responsibility Model

Keeping your cloud workloads secure, compliant, and protected while moving at the speed of DevOps is no easy task. Our team at Threat Stack knows this truth very well. There are many different viewpoints on the best approach to take to keep your customer data and systems protected in the cloud, and it all starts with understanding where your cloud provider’s responsibility for security ends and where yours begins. Let’s use AWS as an example throughout this post as they have a Shared Responsibility Model that demonstrates this well.

The very first step in implementing security in the cloud is understanding that there are two distinct types of cloud security:

  1. Security of the Cloud: Cloud providers like AWS are responsible for the security of the cloud itself.

  2. Security in the Cloud: You are responsible for implementing security measures in the cloud.


So while providers like AWS manage the security of the cloud, security in the cloud is your responsibility. This means that you retain control of what security you choose to implement to protect your own data, platform, applications, systems, and networks. This is no different from what you would do for applications in an on-site data-center.

The diagram below illustrates this relationship and asks some questions you should be able to answer with the right security measures in place in your cloud environment:

 

AWS-Shared-Responsibility-Model

(Click image to enlarge)

To further color the above diagram, we’ve put together four of the best practices for achieving better security in the cloud. These simple guidelines will help you determine the right cloud security approach for your organization:


  1. Focus on Protecting the Workload: In the cloud, your efforts should be concentrated on your workload. But how can you know what’s happening to your files and who’s running what if you don’t have visibility into events on the host? To ensure your workload is continuously protected, focus on collecting data directly from the kernel. This enables an entirely new depth of monitoring, auditing, and alerting that is simply impossible to achieve with traditional network and log driven systems.


  1. Beware of Hidden Costs: Many vendors have hidden costs, such as having to purchase AMIs or MSSP services in order to roll out or see the full value of their solution. Be sure to get all of these costs upfront so you can make smarter purchasing decisions and achieve greater visibility into where your budget is actually going. We also encourage you to look into the performance costs some solutions have on your infrastructure and applications. This too can add up fast.


  1. Can You Get Up and Running Quickly? Sure, every solution claims to be easy to get up and running, but what does this really mean for you? We’ve compiled a few important questions to ask to ensure that you’ll find immediate value and don’t create an unnecessary drain on your DevOps team’s time and resources:

     

    1. What is the deployment process?

    2. Can it integrate with my configuration management tools?

    3. How long before I can see alerts in the system?

    4. How do you integrate with AWS?

    5. How does your platform keep up with my growth?

       

  2. Make Sure Your Solution is Cloud-Native. Too many vendors are hopping on the cloud bandwagon without actually putting the engineering cycles into developing a real cloud-native solution. Look past the BS and identify these solutions for what they really are: lazy attempts to re-market traditional on-premise networking products as trendy solutions. Here are three questions to ask to reveal what sort of solution you’re actually dealing with:

 

    1. Does your solution auto-scale? Cloud-washed solutions aren’t built in the cloud so they can’t easily auto-scale to the elastic needs of cloud infrastructures. They instead require manual server management in order to scale. This will negatively impact you if you need to elastically scale your workload, but are constrained by your security monitoring infrastructure.

    2. Do you collect data from the host or the network? The lack of a network edge and the proliferation of Software Defined Networking in the cloud means that traditional network-based approaches won’t translate well. But if a solution is host-based, analyzing the workload regardless of whether it’s an application or load balancer, that means it’s cloud-native by design.

    3. Can you go back in time? Security is not a point in time problem. Ask about audit and forensic capabilities (especially for transient servers) to ensure your solution retains historically accurate, contextualized data when you need it.

 

You are responsible for protecting your own workloads and data. Armed with the understanding of the Shared Responsibility Model and using the guidelines outlined in this post, you can better evaluate and implement Security in the Cloud.