This is the second in a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment. This post relates to protecting your virtual infrastructure within AWS.
Protecting any computing infrastructure requires a layered or defence-in-depth approach. The layers are typically divided into physical, network (perimeter and internal), system (or host), application, and data. In an Infrastructure as a Service (IaaS) environment, AWS is responsible for security ‘of’ the cloud including the physical perimeter, hardware, compute, storage and networking, while customers are responsible for security ‘in’ the cloud, or on layers above the hypervisor. This includes the operating system, perimeter and internal network, application and data.
Figure 1: AWS Defense in Depth
Infrastructure protection requires defining trust boundaries (e.g., network boundaries and packet filtering), system security configuration and maintenance (e.g., hardening and patching), operating system authentication and authorisations (e.g., users, keys, and access levels), and other appropriate policy enforcement points (e.g., web application firewalls and/or API gateways).
The key AWS service that supports service-level protection is AWS Identity and Access Management (IAM) while Virtual Private Cloud (VPC) is the fundamental service that contributes to securing infrastructure hosted on AWS. VPC is the virtual equivalent of a traditional network operating in a data centre, albeit with the scalability benefits of the AWS infrastructure. In addition, there are several other services or features provided by AWS that can be leveraged for infrastructure protection.
The following list mainly focuses on network and host-level boundary protection, protecting integrity of the operating system on EC2 instances and Amazon Machine Images (AMIs) and security of containers on AWS.
The checklist provides best practice for the following:
IMPORTANT NOTE: Identity and access management is an integral part of securing an infrastructure, however, you’ll notice that the following checklist does not focus on the AWS IAM service. I have covered this in a separate checklist on IAM best practices here.
Best-practice checklist
1. How are you enforcing network and host-level boundary protection?
Establish appropriate network design for your workload to ensure only desired network paths and routing are allowed
For large-scale deployments, design network security in layers – external, DMZ, and internal
When designing NACL rules, consider that it’s a stateless firewall, so ensure to define both outbound and inbound rules
Create secure VPCs using network segmentation and security zoning
Carefully plan routing and server placement in public and private subnets.
Place instances (EC2 and RDS) within VPC subnets and restrict access using security groups and NACLs
Use non-overlapping IP addresses with other VPCs or data centre in use
Control network traffic by using security groups (stateful firewall, outside OS layer), NACLs (stateless firewall, at subnet level), bastion host, host based firewalls, etc.
Use Virtual Gateway (VGW) where Amazon VPC-based resources require remote network connectivity
Use IPSec or AWS Direct Connect for trusted connections to other sites
Use VPC Flow Logs for information about the IP traffic going to and from network interfaces in your VPC
Protect data in transit to ensure the confidentiality and integrity of data, as well as the identities of the communicating parties.
2. How are you protecting against distributed denial of service (DDoS) attacks at network and application level?
Use firewalls including Security groups, network access control lists, and host based firewalls
Use rate limiting to protect scarce resources from overconsumption
Use Elastic Load Balancing and Auto Scaling to configure web servers to scale out when under attack (based on load), and shrink back when the attack stops
Use AWS Shield, a managed Distributed Denial of Service (DDoS) protection service, that safeguards web applications running on AWS
Use Amazon CloudFront to absorb DoS/DDoS flooding attacks
Use AWS WAF with AWS CloudFront to help protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources
Use Amazon CloudWatch to detect DDoS attacks against your application
Use VPC Flow Logs to gain visibility into traffic targeting your application.
3. How are you managing the threat of malware?
Give users the minimum privileges they need to carry out their tasks
Patch external-facing and internal systems to the latest security level.
Use a reputable and up-to-date antivirus and antispam solution on your system.
Install host based IDS with file integrity checking and rootkit detection
Use IDS/IPS systems for statistical/behavioural or signature-based algorithms to detect and contain network attacks and Trojans.
Launch instances from trusted AMIs only
Only install and run trusted software from a trusted software provider (note: MD5 or SHA-1 should not be trusted if software is downloaded from random source on the internet)
Avoid SMTP open relay, which can be used to spread spam, and which might also represent a breach of the AWS Acceptable Use Policy.
4. How are you identifying vulnerabilities or misconfigurations in the operating system of your Amazon EC2 instances?
Define approach for securing your system, consider the level of access needed and take a least-privilege approach
Open only the ports needed for communication, harden OS and disable permissive configurations
Remove or disable unnecessary user accounts.
Remove or disable all unnecessary functionality.
Change vendor-supplied defaults prior to deploying new applications.
Automate deployments and remove operator access to reduce attack surface area using tools such as EC2 Systems Manager Run Command
Ensure operating system and application configurations, such as firewall settings and anti-malware definitions, are correct and up-to-date; Use EC2 Systems Manager State Manager to define and maintain consistent operating system configurations
Ensure an inventory of instances and installed software is maintained; Use EC2 Systems Manager Inventory to collect and query configuration about your instances and installed software
Perform routine vulnerability assessments when updates or deployments are pushed; Use Amazon Inspector to identify vulnerabilities or deviations from best practices in your guest operating systems and applications
Leverage automated patching tools such as EC2 Systems Manager Patch Manager to help you deploy operating system and software patches automatically across large groups of instances
Use AWS CloudTrail, AWS Config, and AWS Config Rules as they provide audit and change tracking features for auditing AWS resource changes.
Use template definition and management tools, including AWS CloudFormation to create standard, preconfigured environments.
5. How are you protecting the integrity of the operating system on your Amazon EC2 instances?
Use file integrity controls for Amazon EC2 instances
Use host-based intrusion detection controls for Amazon EC2 instances
Use a custom Amazon Machine Image (AMI) or configuration management tools (such as Puppet or Chef) that provide secure settings by default.
6. How are you ensuring security of containers on AWS?
Run containers on top of virtual machines
Run small images, remove unnecessary binaries
Use many small instances to reduce attack surface
Segregate containers based on criteria such as role or customer and risk
Set containers to run as non-root user
Set filesystems to be read-only
Limit container networking; Use AWS ECS to manage containers and define communication between containers
Leverage Linux kernel security features using tools like SELinux, Seccomp, AppArmor
Perform vulnerability scans of container images
Allow only approved images during build
Use tools such as Docker Bench to automate security checks
Avoid embedding secrets into images or environment variables, Use S3-based secrets storage instead.
7. How are you ensuring only trusted Amazon Machine Images (AMIs) are launched?
Treat shared AMIs as any foreign code that you might consider deploying in your own data centre and perform the appropriate due diligence
Look for description of shared AMI, and the AMI ID, in the Amazon EC2 forum
Check aliased owner in the account field to find public AMIs from Amazon.
8. How are you creating securecustom (private or public) AMIs?
Disable root API access keys and secret key
Configure Public Key authentication for remote login
Restrict access to instances from limited IP ranges using Security Groups
Use bastion hosts to enforce control and visibility
Protect the .pem file on user machines
Delete keys from the authorized_keys file on your instances when someone leaves your organization or no longer requires access
Rotate credentials (DB, Access Keys)
Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys
Ensure that software installed does not use default internal accounts and passwords.
Change vendor-supplied defaults before creating new AMIs
Disable services and protocols that authenticate users in clear text over the network, or otherwise insecurely.
Disable non-essential network services on startup. Only administrative services (SSH/RDP) and the services required for essential applications should be started.
Ensure all software is up to date with relevant security patches
For in instantiated AMIs, update security controls by running custom bootstrapping Bash or Microsoft Windows PowerShell scripts; or use bootstrapping applications such as Puppet, Chef, Capistrano, Cloud-Init and Cfn-Init
Follow a formalised patch management procedure for AMIs
Ensure that the published AMI does not violate the Amazon Web Services Acceptable Use Policy. Examples of violations include open SMTP relays or proxy servers. For more information, see the Amazon Web Services Acceptable Use Policy http://aws.amazon.com/aup/
Security at the infrastructure level, or any level for that matter, certainly requires more than just a checklist. For a comprehensive insight into infrastructure security within AWS, we suggest reading the following AWS whitepapers – AWS Security Pillar and AWS Security Best Practises.
For more details, refer to the following AWS resources:
Let us know in the comments below if we have missed anything in our checklist!
DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written. Also, please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.
Neha Thethi is a senior information security analyst at BH Consulting. She is an AWS Certified Solutions Architect – Associate and holder of the SANS GIAC Certified Incident Handler (GCIH). Neha has published papers, spoken at conferences, written blogs and delivered webinars about challenges of conducting forensics in the cloud environment. She has helped clients develop incident response plans and conducted several digital forensic investigations for cloud environments including AWS and Microsoft Azure.
