Shared Responsibility - AWS Security Incident Response Guide

Shared Responsibility

The responsibility for security and compliance is shared between AWS and you. This shared model relieves some of your operational burden because AWS operates, manages, and controls the components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operates.

You are responsible for managing the guest operating systems (including updates and security patches) and application software, as well as configuring the AWS provided security controls, such as security groups, network access control lists, and identity and access management. You should carefully consider which services you use, because your responsibilities vary depending on the services you choose, the integration of those services in your IT environment, and applicable laws and regulations. Figure 2 shows a typical representation of the shared responsibility model as it applies to infrastructure services, such as Amazon Elastic Compute Cloud (Amazon EC2). It separates most responsibilities into two categories: security of the cloud (managed by AWS) and security in the cloud (managed by the customer). Responsibilities can change, depending on which services you use. For abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. Customers are responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

However, the shared responsibility model changes with the addition of containers and other services that move the operations model to the service provider. As we move to the left of the operating model, away from IaaS and data centers and towards PaaS, the responsibility of the service provider increases. A customer has fewer responsibilities in the cloud and an easier time operating when migrating to the left of the graph. Note the following figures and the differences in the ability to operate or function in the cloud. As your shared responsibility in the cloud changes, your options for incident response or forensics change also. As the customer, while you plan your incident response, you'll also need to make sure that you plan around the abilities that you have in your operating model, and that you plan the possible interactions before they occur in the model that you have chosen. Planning for and understanding these tradeoffs and matching them with your governance needs is a crucial step in incident response.



Shared Responsibility Model

Figure 1: Shared Responsibility Model

Figure 2: Amazon Elastic Container Service (Amazon ECS) with AWS Fargate Type Shared Responsibility Model

In addition to the direct relationship you have with AWS, there may be other entities that have responsibilities in your particular responsibility model. For example, you may have internal organizational units that take responsibility for some aspects of your operations. You may also have partners or other third parties that develop, manage, or operate some of your cloud technology.

Creating an appropriate incident response and forensics runbook that matches your operating model is extremely important. Your success hinges on your understanding of the types of tools that you need to create, or the tools you need to purchase, for the operating model that you have selected. The better your organization understands the tools available, the better prepared you will be to meet the needs of your enterprise’s governance risk and compliance (GRC) model.