Amazon Web Services Security Overview

In contrast to a dedicated on-premises solution, cloud services do not require long-term hardware investments and can be scaled up and down on demand easily. Launched officially in 2006, Amazon Web Services, or shortly AWS, is one of the biggest cloud computing platforms nowadays. AWS customers are many, including Netflix and NASA.

With more and more companies and security-critical services moving to the cloud, we need a better understanding of cloud security. While a solid security solution will not bring you fame, a bad one can destroy the business. «Murder in the Amazon cloud» is a prominent example. Code Spaces was a source-code hosting provider. The attackers gained access to the company’s AWS management console and demanded a ransom to release the control back. When Code Space did not comply with the demands, the attackers deleted most of the data, backups and machine configurations resulting in the company’s termination.

The number of various services comprising AWS as well as the range of available security features keeps growing. While not everyone can afford a private Amazon region for themselves (CIA paid $600 million for it), there are plenty of options to tighten AWS security. In this article, we will look into the security features available in AWS as well as the best security practices for protecting systems deployed in AWS.

Security responsibilities

In the cloud, a customer and cloud service provider share security responsibilities. While AWS takes care of securing the underlying infrastructure and foundation services, a higher level security functionality is mostly a customer’s responsibility. The exact amount of security configuration to be done by a customer depends on what service is used. AWS takes more security responsibilities for abstracted services than for infrastructure services, see Figure 1.

Figure 1. A simplified model of shared security responsibility in AWS cloud.

Let’s take Amazon Elastic Compute Cloud (Amazon EC2) as an example. AWS is responsible for physical security of hardware and facilities, as well as the security of network and virtualization infrastructures. At the same time, customers of Amazon EC2 are responsible for securing Amazon Machine Images (AMIs), operating systems, applications, data at rest and in transit, credentials, policies, and more.

Infrastructure security and network segmentation

In any reasonably sized system, system components are likely to differ in their security requirements and value. Security zoning is a process of segmenting infrastructure into zones that have similar security requirements and risk levels. Security zoning is a recommended security practice. The following access control methods can be used to build network segments in AWS cloud.

Amazon Virtual Private Cloud (VPC). Although AWS is a public cloud, since 2013 AWS resources are automatically provisioned in a ready-to-use default VPC. Not all parts of your system need to be exposed on the Internet. Amazon VPC solves this problem by allowing customers to decide which resources should be public and which should stay private. For example, a user database should not be exposed to the Internet directly. Amazon VPC should be used «to define an isolated network for each workload or organizational entity»[1].

Security groups. Use of security groups is another best practice recommended by Amazon. Security groups are stateful firewalls for Amazon EC2 instances at the hypervisor level. Each security group can be assigned rules that control the inbound and outbound traffic on the instance level. Security groups support allow rules only.

Network Access Control Lists (ACL). Security groups can be augmented with network ACLs. In contrast to security groups, network ACLs operate at the subnet level and are session agnostic, or stateless. Network ACLs support both allow rules and deny rules that are automatically applied to all traffic to and from the resources in the subnet. Network ACL rules are applied to the traffic before security group rules. Both security groups and network ACLs are managed through Amazon VPC API.

Host-based IDS/IPS. IDS/IPS use signature-based or anomaly-based methods to detect and respond to network attacks. OSSEC, an open-source IDS, is often used by AWS customers[1]. Web Application Firewalls (WAF) can be used to protect against attacks targeting web applications. AWS offers WAF as a product.

Data security

Securing data at transit. Protection of data in transit applies to network traffic between end-clients and cloud-based services as well as network traffic between services in the cloud. Ensuring data confidentiality, data integrity and parties authentication are the main security concerns that are traditionally addressed by IPsec and TLS standards.

AWS service management traffic (e.g. launching a new Amazon EC2 instance) and Amazon S3 traffic (e.g. saving an object to an Amazon S3 bucket) are HTTPS-based. Other Amazon services such as Amazon RDS and Amazon EMR require manual set up of TLS that usually implies checking a box.

Securing data at rest. It is important to store data securely. Similarly to how user passwords should be hashed and salted when stored in a database, all data should be encrypted at rest. AWS security features for protection of data at rest vary depending on the service type. Enabling server-side data encryption is easy: for most databases it is only one click away.

With server-side encryption, AWS generates a unique encryption key for each object and then encrypts the object using AES-256[1]. This process does not require client interaction. AWS recommends that customers do not place sensitive information in Amazon S3 metadata because object metadata is not encrypted.

With client-side data encryption, AWS has no control over the encryption keys and encryption process. It is, therefore, the customer’s responsibility to create and manage encryption keys. The client should encrypt the data before sending it to AWS, and decrypt it when received from AWS. It is possible to have a hybrid solution with both server- and client-side encryption.

Secure key management

AWS Key Management Service (KMS) provides centralized control of cryptographic keys secured by hardware security modules (HSM). HSM is a physical tamper-resistant device that securely stores various digital keys as well as provides cryptoprocessing. With AWS CloudHSM, a cloud HSM service designed to be used with Amazon EC2 and VPC, customers gain access to dedicated single tenant CloudHSM appliances. However, on-premises HSMs can also be used assuming they are accessed securely, e.g. over IPsec.

AWS CloudHSM provides the following functionality among other things: offloads SSL/TLS processing for web servers, protects private keys for an issuing certificate authority (CA), provides quorum authentication for critical administrative and key management functions.

Identity and access management

While end-user identity and access management is exclusively a customer’s responsibility, AWS facilitates secure access management to AWS services and resources by providing AWS Identity and Access Management (IAM) service at no additional charge. AWS IAM users can be an individual employee, service, or application. Some of the best practices for AWS IAM are listed below[2].

AWS account root user access key gives full access to all resources for all AWS services. Restricting root keys permissions is impossible unless the corresponding account is part of an organization created through AWS Organization service. For this reason, the root keys must be kept private, and ideally be disabled. The AWS root key should not be used to access AWS. Instead, individual IAM users should be created.

Organize users into groups. Each IAM user can be assigned a set of permissions that can be changed or entirely revoked when needed. Even more conveniently, you can use groups to assign appropriate permissions to IAM users based on their job functions. The best practice is to assign groups even in cases where there is only one user who requires access to a specific resource.

Use roles for permission delegation. IAM roles address the issue of access delegation to users and services that do not have their own permanent set of credentials. A role has permissions associated with it. Access keys and other credentials should not be shared between accounts or users. Instead, roles should be used to delegate permissions.

It is recommended to use roles for applications that run on Amazon EC2 instances and need access to other AWS resources, such as Amazon S3 buckets or Amazon DynamoDB. This is because managing long-term credentials on each instance is challenging and may increase security risks.

Configure a strong password policy for users. IAM console allows specifying password requirements such as minimum length and how frequently it must be rotated. Enabling Multi-Factor Authentication (MFA) for all users is recommended. It is also important to remove unnecessary credentials, e.g. IAM users that are used by employees do not need access keys, and IAM users that are used by applications do not need passwords to sign in to AWS websites. Least privilege checks can be done using AWS IAM user Access Advisor and AWS IAM user Last Used Access Keys.

Logging

Consistent logging simplifies both security analysis and troubleshooting. Moreover, logging is often required for compliance with regulatory standards such as Payment Card Industry Data Security Standard (PCI DSS).

Examples of security events that should be logged (PCI DSS) include actions taken by any individual with root or administrative privileges, access to all audit trails, invalid logical access attempts, use of identification and authentication mechanisms, initialization of audit logs, and creation and deletion of system level objects.

AWS is Level 1 compliant under the PCI DSS. CloudTrail is an AWS service that generates a log of all API calls related to AWS resources within given account. Access to CloudTrail log files can be restricted to specific users and roles.

Security monitoring and automation

Log analyzing. The next step following log collection is log analyzing. Amazon offers several products to assist with security monitoring based on log information, although open source log management systems can also be deployed.

Amazon GuardDuty is an AWS service for continuous security monitoring. To identify malicious activity, GuardDuty analyzes data from AWS CloudTrail event logs, VPC Flow Logs, and DNS logs (if internal AWS DNS resolvers are used). Amazon GuardDuty can detect security events indicative of backdoors, cryptocurrency mining, pen-testing activity, reconnaissance attacks, trojan presence, unauthorized access, as well as deviation from normal behavior. Amazon recommends enabling GuardDuty in all supported AWS regions, otherwise GuardDuty ability to detect activity that involves global services is reduced.

Response automation. Security automation is another essential ingredient of security-centric system design. Amazon CloudWatch is a generic monitoring and management service that allows to create alarms, visualize logs and metrics, take automated actions, and more. CloudWatch and GuardDuty can be used together to automate security responses. For example, Amazon CloudWatch can be configured to invoke an action in response to suspicious behavior detected by Amazon GuardDuty. The response can be modifying access controls, terminating instances, or revoking credentials.

Reducing security misconfigurations. AWS Trusted Advisor allows identifying underutilized resources and common security misconfigurations such as leaving certain ports open, allowing public access to Amazon S3 buckets and more. CVE-scanning tools such as Amazon Inspector can be used to detect publicly known vulnerabilities. Multiple open source continuous security auditing tools such as Security Monkey by Netflix exist. Security misconfigurations can in general be found via security testing, as discussed later.

Maintaining security consistency. Enforcing consistent security policies throughout multiple services and redeployments can be challenging. AWS Config allows to evaluate the resource configurations against your ideal configuration settings. Rules in AWS Config are customizable. AWS Config marks the resource and the rule as non-compliant if a violation is found. AWS CloudFormation and AWS Systems Manager help with provisioning infrastructure consistently.

Distributed Denial of Service (DDoS) attacks

A certain amount of DDoS mitigation is provided in AWS cloud by default and at no additional charge. Amazon handles DDoS mitigation and protection in Amazon S3 and other abstracted services. AWS Shield Standard protects Amazon Route 53 Hosted Zones, Amazon CloudFront, and Amazon EC2 instances from common infrastructure level DDoS attacks such as SYN floods, UDP floods, or various Reflection attacks. However, protection against application level attacks and in-depth protection against infrastructure layer attacks requires more configuration.

Many conventional approaches for DDoS mitigation and protection in the cloud are part of infrastructure security discussed earlier: firewalls (security groups, network ACLs and host-based firewalls), WAFs, host-based IDS/IPS. Traffic shaping or rate limiting is another typical approach. Although DDoS protection is built around detecting and blocking malicious requests, availability of the service under attack to legitimate users is a concern. To continue serving legitimate user traffic during a DDoS attack, a »scale to absorb» principle is often adopted by cloud-based systems.

A DDoS-resilient reference architecture recommended by AWS[3] is shown in Figure 2. The purpose of the main infrastructure components is discussed below.

Figure 2. DDoS-resilient reference architecture recommended by AWS.

Elastic Load Balancing (ELB). Amazon EC2 allows to scale the computing capacity up and down by adding more instances or by using larger instances. This is important when absorbing a DDoS attack. DDoS attacks of a significant size can exceed the resources of a single Amazon EC2 instance. Elastic Load Balancing (ELB) allows to distribute traffic across many Amazon EC2 instances and can scale automatically.

Amazon CloudFront. Amazon CloudFront, a Content Delivery Network (CDN) service for web application delivery at the edge, reduces the total number of connections to the origin which helps with HTTP floods, SYN floods, and UDP reflection attacks.

Amazon Route 53. Amazon Route 53 is a scalable edge DNS service by Amazon. It uses shuffle sharding and anycast striping to improve fault tolerance and performance. Moreover, »Amazon Route 53 can detect anomalies in the source and volume of DNS queries, and prioritize requests from users that are known to be reliable.»[3]

AWS WAF. AWS WAF allows to detect and filter malicious web requests by defining configurable web ACLs.

Diversification of regions and availability zones allows for various internet connections and peering relationships and provides resilience against DDoS and natural disasters. Obfuscation of AWS resources through proper utilization of VPC and allowing only ELB to communicate with the instances by setting up security groups and network ACLs reduces the overall attack surface.

Application and OS security

Various basic security principles such as minimizing attack surface area, security by default, defense in depth (layered security) and least privilege principle should be followed. End users should always be authenticated and authorized for the requested actions. Dependencies on external libraries should be minimized and the applicable security updates performed on time.

It is crucial that EC2 instances are launched from trusted AMIs and that only trusted software from a trusted software provider is installed and run. Immutable infrastructure, where a server or a cluster has limited lifetime and a new deploy means a new server with the new application version, can be used to further reduce the attack surface. Diversified offline backups are also recommended.

Incident response and forensics

Incident response and forensics are mostly clients responsibilities. If your AWS instance is compromised, Amazon recommends to shut down and rebuild the instance completely[1]. This mitigation strategy is less challenging in the cloud environment than in a self-hosted system with limited resources.

Forensic analysis of a compromised instance can be desired to detect the root cause. To prevent the infection from spreading during the investigation, the compromised instance must be isolated. It is possible to take an offline Amazon EBS snapshot of the infected instance. Such an offline snapshot can be delivered to forensic experts for further analysis.

Security testing

Security testing is needed to reveal security issues and verify the existing controls. Security testing is a broad area that includes vulnerability assessment and penetration testing among other things. White-, gray- and blackbox testing are commonly employed. Security testing is usually performed by security experts.

To conduct penetration testing in AWS, permission must be requested first. While permission is needed for any security testing, only a limited set of service types is allowed to be tested. Testing of such services as API-gateway, Cognito, S3, ECS/EKS and small or micro RDS instance types are not permitted.

Various simulated security events such as security game days, red team and blue team testing, and disaster recovery simulations require authorization and undergo a manual approval process. In addition to the standard security tools, specialized tools for offensive security testing in AWS such as Pacu and WeirdAAL are emerging.

Multi tenancy and physical security

In the public cloud, both the cloud provider and other tenants are potential security threats. The host controls all the guests: secure execution of software on remote hardware that is fully controlled by a third party is an unsolved problem. Data protection laws and abilities for governmental agencies to seize customer’s data from a cloud provider vary from country to country.

Multi tenancy, as in multiple customers sharing the same hardware, is an integral part of the public cloud model. Multi tenancy opens doors for shared memory and cross virtual machines attacks where a malicious tenant can attempt to gain unauthorized access to or extract data from other tenants instances and services.

In Amazon EC2, each new instance is launched into a VPC and runs on shared hardware by default. It is possible, however, to run the instances on a single-tenant hardware or on a dedicated host, i.e. an isolated server with customizable configurations. The non-default tenancy options have a different pricing policy.

Security solutions for the privacy concerns in the cloud are emerging. Intel’s Software Guard Extensions (SGX) aims to protect application code and data from unauthorized access and tempering by malicious software running at higher privilege levels, e.g. from a hypervisor. As for 2018, AWS does not offer SGX capable servers, while Microsoft Azure and IBM Cloud do. Homomorphic encryption schemes, if ever practical, would be another way to mitigate the same issue.

Conclusion

Although AWS provides an extensive set of advanced security features out of the box, these features need to be enabled and professionally configured based on the security needs of a specific organization. In this document we mostly covered traditional infrastructure; managed services and serverless compute require less security configuration.

While there are many security advantages of AWS, such as effective mitigation of DDoS attacks, there are certain limitations such as restrictions on penetration testing as well as security risks associated with any multi-tenant environment. The best software engineering and security practices should be followed independently of if the system is run in the cloud or not.

Acknowledgments. I thank Anders Bjørnestad (Webstep), Arne Solheim (Webstep), and Christian Otterstad (Simula@UiB) for their insightful feedback.

References

1. Amazon Web Services, Inc, “AWS Security Best Practices.” https:// d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf, August 2016.
2. Amazon Web Services, Inc, “IAM Best Practices.»  https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
3. Amazon Web Services, Inc, “AWS Best Practices for DDoS Resiliency.” https:// d1.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf, June 2018.

Tetiana Yarygina
Webstep Tech Expert, Information security