Forensic AWS Account – Incident Response – SCS-C02 Study Guide

Forensic AWS Account

A separate AWS account for forensic investigations is ideal to help you diagnose and isolate the affected resources. By utilizing a separate account, you can architect the environment to be more securely appropriate to its forensic use. You could even use AWS Control Tower to provision the account quickly, using the account vending machine. Once the account has been provisioned, you could use an additional CloudFormation template to set up all the correct S3 buckets and provision any other resources you would need from a configuration standpoint. A process such as this allows you to build the account and environment using a known configuration without relying on manual processes that could be susceptible to errors, which would be undesirable in the early stages of a forensic investigation. This setup can also allow you to spin up the account and take it back down when not in use for extended periods.

While investigating, you should ensure your steps and actions are auditable; this can be done by using logging mechanisms such as CloudTrail and CloudWatch logs. Having your logs all go to a centralized logging account for storage is the best practice. A centralized logging account is a security recommendation listed in the WAF security pillar.

The following section will examine prescriptive IR guidance based on the AWS Security Incident Response Guide.

Incident Response Guidance from AWS

AWS has taken lessons learned from a number of customer incidents and along with a few other industry-leading resources, such as the NIST SP 800-61 Computer Security Incident Handling Guide, compiled a guide to help with IR. This guide is composed of three major sections:

• Preparation: This involves detecting and responding to incidents when they occur in your accounts. This includes the preparation of playbooks and runbooks, which can be manual, automated, or a combination of the two. These allow quick and consistent responses to incidents.
• Operations: This is when the incident has occurred and you are following the NIST phases of IR: detect, analyze, contain, eradicate, and recover.
• Post-incident activity: Once the incident is over, the team needs to take time to understand and record how the events transpired. This is an excellent time to take away any lessons learned and action items to make the response go smoother the next time it is needed.

One of the main aspects addressed in the AWS security pillar whitepaper is containment. When an event requires an IR, you (and your team) must be able to contain the damage. According to the AWS security pillar whitepaper, you should have a containment strategy for any or all of the following reasons:

• To stop or prevent potential damage to and theft of your resources and data
• To preserve evidence
• If the response will take time to implement
• If you are unsure of the effectiveness of the response
• If you are unsure how long the response would be effective

There are multiple ways to enforce containment in an AWS account, which you will go through now.

Containment can be refined down to three main concepts:

• Source containment is the use and implementation of filtering access to all or specific resources from a specific IP or range of IP addresses. You can execute this type of containment using items such as security groups that can explicitly allow or deny traffic to EC2 instances or other AWS resources. S3 bucket policies or access control lists (ACLs) can also be used as a source containment method, and you could use the web application firewall service for more fine-grained control.

Figure 4.2: Source containment example

• Destination containment is the use and implementation of filtering access to a specific resource. This can be accomplished by shutting down the resource. You can also contain the resource by removing it or detaching it from any autoscaling groups or load balancers so that the EC2 instance can no longer receive traffic. Another method of destination containment is adding a Network Access Control List (NACL) and denying rules to prevent access to a particular resource. The rule could be created with a single deny rule for both inbound and outbound access to the targeted resource.
• Technique and access containment prevent the use of resources by limiting the actions that IAM principals and functions have concerning those resources. This can include actions taken, such as removing previously granted privileges or rescinding a combination of access keys or temporary access keys and security credentials.

Although containment is only one part of the IR process, the steps needed to perform containment for various scenarios should be preconceived before any exploit. This way, each scenario can be mapped to either a manual or an automated containment response.

The following section presents an overview of these areas from the security pillar whitepaper, as questions on the exam can come from knowing how to handle incidents in the manner that AWS prescribes.