AWS Cloud: Proactive Security and Forensic Readiness – Part 5

By Neha Thethi, Information Security Analyst, BH Consulting

Part 5: Incident Response in AWS

In the event your organization suffers a data breach or a security incident, it’s crucial to be prepared and conduct timely investigations. Preparation involves having a plan or playbook at hand, along with pre-provisioned tools to effectively respond to and mitigate the potential impact of security incidents. These response measures are more effective when regularly tested, such as by running incident response simulation exercises.

This post relates to incident response in the AWS Cloud. It’s the last in a five-part series that provides a checklist for proactive security and forensic readiness in the AWS Cloud environment.

Incident response

NIST defines a security incident as “an occurrence that actually or potentially jeopardises the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies”. The figure below outlines the typical phases of an incident response lifecycle.

Figure 1: Incident response life cycle. [Source: Computer Security Incident Handling Guide]

Incident response in AWS Cloud

Incident response in the cloud is not very different from in the traditional on-premise environment. In fact, there are several tools in the AWS cloud environment you can use to help the incident response process, such as AWS CloudTrail, Amazon CloudWatch, AWS Config, AWS CloudFormation, AWS Step Functions, etc. These tools enable you to track, monitor, analyse, and audit events.

Audit logs are treasure troves and are indispensable during investigations. AWS provides detailed audit logs that record important events such as file access and modification. Events can be automatically processed and trigger tools that automate responses through the use of AWS APIs. You can pre-provision tooling and a “clean room” which allows you to carry out forensics in a safe, isolated environment.

Figure 2: EC2 Auto Clean Room Forensics using Lambda, Step Functions, Cloud Formation and SNS Topic. [Source: Automating Incident Response and Forensics in AWS – AWS Summit Sydney 2018]

The following list provides guidance on having an appropriate incident response strategy in place, estimating the impact of incidents in the AWS environment, AWS tools to prepare in advance for incident handling, responding to AWS abuse warnings, containing compromised EC2 instance and wiping information post investigation.

The checklist provides best practice for the following:

1. How will you ensure that you have an appropriate incident response strategy in place?
2. What AWS tools should you use to prepare in advance for incident handling?
3. How will you respond to AWS abuse warnings?
4. How will you isolate and restrict user access to a compromised Amazon EC2 instance?
5. How will you ensure sensitive information is wiped post investigation?

Best-practice checklist

1. How will you ensure you have an appropriate incident response strategy in place?

• Make sure the security team has the right tools pre-deployed into AWS so that the incident can be responded to in a timely manner.
• Pre-provision a ‘clean room’ for automated incident handling.
• Have a list of relevant contacts that may need to be notified.
• Decide on the medium of communication. If the compromised account contains personal data, you may be required to contact the Data Protection Commission (DPC) within 72 hours to comply with GDPR.
• Conduct incident response simulations regularly in the non-production and the production environments as well. Incorporate lessons learned into the architecture and operations.

2. What AWS tools should you use to prepare in advance for incident handling?

• Tags in AWS allow you to proactively label resources with a data classification or a criticality attribute so you can quickly estimate the impact when the incident occurs.
• AWS Organisations allows you to create separate accounts along business lines or mission areas which also limits the “blast radius” should a breach occur; for governance, you can apply policies to each of those sub accounts from the AWS master account.
• IAM grants appropriate authorisation to incident response teams in advance.
• Security Groups enables isolation of Amazon EC2 instances.
• AWS Cloud Formation automates the creation of trusted environments for conducting deeper investigations.
• AWS CloudTrail provides a history of AWS API calls that can assist in response and trigger automated detection and response systems.
• VPC Flow Logs enables you to capture information about the IP traffic going to and from network interfaces in your VPC.
• AWS Key Management Service (KMS) encrypts sensitive data at rest including logs aggregated and stored centrally.
• Amazon GuardDuty is a managed threat detection service that continuously monitors for malicious or unauthorised behaviour.
• Amazon CloudWatch Events triggers different automated actions from changes in AWS resources including CloudTrail.
• Amazon S3 stores snapshots and related incident artefacts.
• AWS Step Functions coordinates a sequence of steps to automate an incident response process.
• APIs automate many of the routine tasks that need to be performed during incident handling.

3. How will you respond to AWS abuse warnings?

• Set up a dedicated security communication email address.
• Do not ignore abuse warnings. Take action to stop the malicious activities, and prevent future re-occurrence.
• Open a case number with AWS Support for cross-validation.

4. How will you isolate and restrict user access to a compromised Amazon EC2 instance?

• When containing the instance manually, use IAM to restrict access permissions to compromised Amazon EC2 instance.
• Isolate the instance using restrictive ingress and egress security group rules or remove it from a load balancer.
• Tag the instance as appropriate to indicate isolation.
• Create snapshots of EBS volumes.
• Notify relevant contacts.
• Use CloudFormation to quickly create a new, trusted environment in which to conduct deeper investigation.
• You can automate the above steps using Lambda, Step Functions, Cloud Formation and SNS Topic to prepare an EC2 auto clean room for containing the instance.
• You could also use aws-security-automation code on GitHub, which is a collection of scripts and resources for DevSecOps, Security Automation and Automated Incident Response Remediation.

5. How will you ensure sensitive information is wiped post investigation?

• Secure wipe-files and delete any KMS data keys, if used.

For more details, refer to the following AWS resources:

• AWS Well-Architected Framework
• AWS Security Pillar
• AWS Security Best Practices
• What is Amazon CloudWatch Logs?
• Automating Incident Response and Forensics in AWS – AWS Summit Sydney 2018
• aws-security-automation (GitHub repository of tools)
• NIST Computer Security Incident Handling Guide

Go back to the introduction AWS Cloud: Proactive Security & Forensic Readiness five-part best practice
Read Part 1 – Identity and Access management in AWS: best-practice checklist
Read Part 2 – Infrastructure level protection in AWS: best-practice checklist
Read Part 3 – Data protection in AWS: best-practice checklist
Read Part 4 – Detective Controls in AWS: best-practice checklist

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.