Practical Control Considerations under the AWS Shared Responsibility Model

Consumers are doing more and more of their shopping on Amazon because it is convenient, cost-effective, quick and simple to use.  In a similar respect (and for the same reasons), there are an increasing number of companies moving their IT environments to Amazon Web Services (AWS).  One of the many benefits of using AWS is that they are very focused on security and compliance.  However, as AWS is quick to point out in their Shared Responsibility Model, security and compliance are a shared responsibility between AWS and their customers.

The purpose of this blog post is to describe the Shared Responsibility Model and provide some practical examples of the types of controls that many of our clients that use AWS have implemented.

The shared model is designed to relieve customer’s operational burden as 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. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall. This differentiation of responsibility is commonly referred to by AWS as Security “of” the Cloud versus Security “in” the Cloud.

“Security of the Cloud” – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.

“Security in the Cloud” – Customer responsibility will be determined by the AWS Cloud services that a customer selects. This dictates the amount of configuration work the customer must perform as part of their security responsibilities. For example, services such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), and Amazon S3 are categorized as Infrastructure as a Service (IaaS) and, as such, require the customer to perform all of the necessary security configuration and management tasks. If a customer deploys an Amazon EC2 instance, they are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance.

This shared responsibility correlates to the necessary IT controls, which are either inherited from AWS (i.e., 100% owned by AWS), shared between the customer and AWS or customer owned.  Physical and environmental controls are inherited from (owned by) AWS.  On the other end of the spectrum, customer specific controls are solely the responsibility of the customer based on the application(s) they are deploying within AWS services. Examples of customer-owned controls include security zones and network segmentation.

Shared controls are those which apply to both the infrastructure layer and customer layers, but in completely separate contexts or perspectives. In a shared control, AWS provides the requirements for the infrastructure and the customer must provide their own control implementation within their use of AWS services. Examples include:

  • Patch Management – AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications.
  • Configuration Management – AWS maintains the configuration of its infrastructure devices, but a customer is responsible for configuring their own guest operating systems, databases, and applications.

Many of our SOC clients who are using AWS or considering moving to AWS inquire about the types of controls they should put in place.  The following are examples of AWS-specific controls that we frequently see in SOC reports:

  • The Company uses Amazon CloudWatch to monitor its production environment and has enabled alarms in CloudWatch so that the CTO receives a notification whenever potential threats are identified.
  • The Company uses AWS CloudTrail to log, continuously monitor and retain activity across their AWS infrastructure.
  • Privileged access to the AWS console is restricted to authorized users with a business need.
  • User access to the AWS console is based on job role and function and requires a documented access request form and manager approval prior to access being provisioned.
  • The AWS console requires unique username and passwords prior to authenticating users.
  • Passwords to access AWS are configured according to the Company’s policy. Company policy requires the following:
    • 8 character minimum.
    • Complexity enabled.
    • 90 day password change.
    • Lockout after 5 invalid attempts.
  • Security groups are built into the Amazon VPC that enable the Company to control access to their environment.
  • Security group rulesets are reviewed at least annually. Change tickets are created to track any security group modifications as a result of the review.
  • Infrastructure supporting the service is patched as a part of routine maintenance and as a result of identified vulnerabilities to help ensure servers supporting the service are hardened against security threats.
  • Anti-malware technology is deployed and is configured to be updated routinely, logged, and installed on all relevant production servers.
  • Data in transit is encrypted across all services with TLS.
  • The Company restricts upload and delete access to production S3 buckets to administrators with a legitimate business need.
  • The Company utilizes AWS Identity and Access Management to manage access to AWS in-scope services and resources securely.
  • The company enforces multi-factor authentication on the root AWS account to protect the root account from unauthorized access.
  • AWS security groups are used and configured to prevent unauthorized access.
  • Production Elastic Block Store (EBS) volume snapshots are marked as private to protect the snapshots from unauthorized access.
  • Production Relational Database Service (RDS) DB snapshots are marked as private to protect the snapshots from unauthorized access.
  • The Company utilizes Amazon Trusted Advisor to monitor for service usage that is more than 80% of the service limit on all in-scope services.
  • Amazon S3 bucket logging is enabled to identify trends that may have a potential impact on the company’s ability to achieve its system security objectives.
  • AWS CloudTrail is enabled to provide increased visibility into user activity in the production AWS account that may have a potential impact on the Company’s ability to achieve its system security objectives.
  • The company rotates IAM access keys at least every 90 days to prevent keys from being compromised.
  • The Company monitors popular code repositories and checks for irregular EC2 usage to verify that access keys have not been compromised.
  • Amazon RDS DB instances are deployed in a multi availability zone configuration to permit the resumption of operations at other entity facilities in the event of loss of a facility.
  • Production EC2 instances are deployed across multiple Availability Zones to help protect applications from a single point of failure.

 

This is not intended to be an exhaustive list of controls that should be implemented in an AWS environment, but should provide some insights as you consider your role in the Shared Responsibility Model.

Thanks for reading!

 

Reference source used for this post: AWS Shared Responsibility Model https://aws.amazon.com/compliance/shared-responsibility-model/