Building a cloud-specific incident response plan

In order for your organization to be prepared before a security event occurs, there are unique security visibility, and automation controls that AWS provides. Incident response does not only have to be reactive. With the cloud, your ability to proactively detect, react, and recover can be easier, faster, cheaper, and more effective.

What is an incident?

An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service. Through tools such as AWS CloudTrail, Amazon CloudWatch, AWS Config, and AWS Config Rules, we track, monitor, analyze, and audit events. If these tools identify an event, which is analyzed and qualified as an incident, that “qualifying event” will raise an incident and trigger the incident management process and any appropriate response actions necessary to mitigate the incident.

Setup your AWS environment to prevent a security event

We will walk you through a hypothetical incident response (IR) managed on AWS with the Johns Hopkins University Applied Physics Laboratory (APL).

APL’s scientists, engineers, and analysts serve as trusted advisors and technical experts to the government, ensuring the reliability of complex technologies that safeguard our nation’s security and advance the frontiers of space. APL’s mission requires reliable and elastic infrastructure with agility, while maintaining security, governance, and compliance. APL’s IT cloud team works closely with APL mission areas to provide cloud computing services and infrastructure, and they create the structure for security and incident response monitoring.

Whether it is an IR-4 “Incident Handling” or IR-9 “Information Spillage Response,” the below incident response approach from APL applies to all types of IR.

1. Preparation: The preparation step is critical. Train IR handlers to be able to respond to cloud-specific events. Ensure logging is enabled using Amazon Elastic Compute Cloud (Amazon EC2), AWS CloudTrail, and VPC Flow Logs, collect and aggregate the logs centrally for correlation and analysis, and use AWS Key Management Service (KMS) to encrypt sensitive data at rest. You should consider multiple AWS sub accounts for isolation with AWS Organizations. With Organizations, you can 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.
2. Identification: Also known as Detection, you use behavioral-based rules for identifying and detecting breaches or spills, or, you can be notified about which user accounts and systems need “cleaning up.” You should open up a case number with AWS Support for cross-validation.
3. Containment: Use AWS Command Line Interface (CLI) or software development kits for quick containment using pre-defined restrictive security groups. Save the current security group of the host or instance, then isolate the host using restrictive ingress and egress security group rules.
4. Investigation: Once isolated, determine and analyze the correlation, threat, and timeline.
5. Eradication: Secure wipe-files. Response times may be faster with automation. After secure wipe, delete any KMS data keys, if used.
6. Recovery: Restore network access to original state.
7. Follow-up: Verify deletion of data keys (if KMS was used), cross-validate with Amazon Support, and report findings and response actions.

Watch the Incident Response in the Cloud session from the AWS Public Sector Summit in Washington, DC for a more detailed discussion with Conrad Fernandes, Cloud Cyber Security Lead, Johns Hopkins University Applied Physics Lab (JHU APL).

Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.