Strategies for Building a Forensic Investigation Environment on AWS
This blog is a translation of “Forensic investigation environment strategies in the AWS Cloud”.
When security baselines are deviated, it is critical to respond quickly, resolve the issue, and follow up with forensic investigation and root cause analysis. With a pre-configured infrastructure and a practical plan for following up if there is a deviation from the baseline, you can extract and extract the information you need to determine the impact, scope and root cause of an incident. Analyze and resume operations with confidence.
You need to know the 'what', 'how', 'by whom', 'where' and 'when' of a security incident in a timely manner. We often hear the term automated incident response, which is about having a repeatable and auditable process to standardize incident resolution and quickly collect evidence artifacts.
Similarly, having a standard, unattended, pre-configured, repeatable and clean forensic environment that is automatically deployed by templates helps organizations minimize human contact. to keep large organizations out of contamination, expedite evidence collection and root cause analysis, and protect the integrity of forensic data. The forensic analysis process helps preserve, retrieve and analyze data to identify the root cause of incidents. This approach also facilitates the presentation and transfer of evidence to external legal entities and auditors. AWS CloudFormation templates, or other Infrastructure as Code (IaC) provisioning tools, help achieve these goals and provide consistent, structured, and auditable results for your business, thereby improving overall It allows you to improve your overall security posture. Having these environments as a permanent part of your infrastructure is well documented and proven. And you get the chance to train your team on how to use it.
This blog presents strategies that organizations can use to address secure baseline deviations. These strategies employ best practices in each of the following topics.
Specifically, the focus is on providing an environment in which evidence artifacts can be examined using Amazon Elastic Compute Cloud (Amazon EC2) instances with forensic tools installed.
This blog also assumes that you already have or have implemented procedures for collecting evidence artifacts, and that you are able to transfer evidence artifacts to the accounts described here. If you're looking for advice on how to automate artifact collection, see How to automate disk collection in AWS.
Infrastructure Overview
A well-architected multi-account AWS environment is based on the structure provided by Organizations. As companies grow and need to expand their infrastructure with multiple accounts in multiple AWS Regions, Organizations automatically creates new AWS accounts with a combination of central management and governance to ensure control and standardization. help you do it the way you want it. This automated, centralized approach should be used to create the forensic investigative environment described in this blog strategy.
This blog example uses a simplified structure with separate dedicated OUs and accounts for security and forensics as shown in Figure 1. Your organization's architecture may be different, but the strategy is the same.
Note: While it may be quick to perform forensic analysis within a compromised account, such as shutting down or avoiding access to compromised instances or resources, such an approach is Not covered in this article.
Figure 1: Example Forensics OU in AWS Organizations
The most important components in Figure 1 are:
Security OUs are used to host security-related access and services. Security OUs and associated AWS accounts must be owned and managed by your security organization.
Although the Forensics OU may have some similarities and overlapping responsibilities with the Security OU, it should be a separate entity. There are several reasons for having separate OUs and accounts. The forensic team may be a separate team from the security team (or a group within it), certain investigations may be legally binding and access restrictions may be added, to name a few important reasons. and security team members may be subject to investigation.
When thinking about Organizations, accounts, and the permissions required for various actions, we should first focus on the core functionality of Organizations: SCPs. SCPs can govern the maximum available privileges for all accounts within an organization. In this article's example, SCP can be used to provide similar or identical authorization policies for all accounts under the forensic OU used as a resource container. This policy overrides all other policies and is an important mechanism for ensuring that you can explicitly deny or allow the API calls you want. Some use cases for SCPs are restricting disabling of AWS CloudTrail, restricting root user access, and ensuring that all actions taken in a forensic investigation account are recorded. This allows you to centrally manage individual policies for users, groups, or roles to prevent changes.
Access to the forensic environment should adhere to the principle of least privilege, which states that no one can alter or compromise collected evidence. In a research environment, denying all actions except those listed as exceptions is the simplest approach. Start with the default "deny all" and work your way toward the minimum privileges required to perform your organization's established forensic processes. AWS Config can be a valuable tool for tracking changes made to your account and providing evidence of these changes.
Keep in mind that once a restricted SCP is applied, even the root account and those with administrator access will not have access beyond that privilege. Therefore, it is a best practice to test frequently and proactively as the environment changes. Also, be sure to verify which principals can remove the protection policy in order to transfer the account to an external entity, if necessary. Finally, create environments and move accounts under the Forensics OU before restrictive permissions are applied.
Having an AWS account dedicated to forensic investigations insulates a large organization from the threat of contamination from the incident itself, ensures independence and integrity protection of the artifacts analyzed, and ensures the confidentiality of the investigation. perfect for keeping. If the attacker used all the resources available in her compromised AWS account, they would hit the service quota limit and even be unable to launch Amazon EC2 for investigation. can also be avoided.
Having a forensic investigative account in each region keeps investigative capabilities close to the data being analyzed, reduces latency, and avoids data protection regulation issues in each country without transferring data. It's also good practice. For example, data located in the EU needs to be examined by a research team in North America, but the data itself cannot be moved because the North American architecture is not GDPR compliant. For global customers, forensic teams may be located in different locations around the world and have different processes. It is better to have a forensic account in the region where the incident occurred. We can also provide your entire account to local legal authorities and third party auditors if required. That said, if your AWS infrastructure consists of multiple regions, but only one jurisdiction or country, you can have a single account in one region that can be recreated and keep the artifacts of evidence in each region. Sharing and storing from , you have a long-term manageable architecture.
Accounts created in an automated manner using CloudFormation templates or other IaC methods can recreate a completely new, human-free forensic analysis instance for each individual investigation and verify its integrity. By securing it, human work before use can be minimized. Individual access rights should only be granted as part of a security incident response plan, with minimal or no authority to modify the environment. Post-exploration environments are saved in a locked state or deleted, creating a fresh, pristine environment for the next investigation, leaving no trace of previous artifacts. Templated environments also make it easier to test to ensure that your investigation strategies, permissions, and tools work as intended.
Accessing the Forensic Infrastructure
Once you have decided where to put your investigative environment, you need to think about who will have access and what permissions they will need. The forensic investigation team can be a separate team, the same team, or part of the security incident response team. As part of maintaining least privilege, you need to provide precise access rights to groups of individuals conducting investigations.
Depending on the different needs of the forensic procedure, you should create specific roles each with only the required privileges. As with SCPs and other situations described here, start with no permissions and add only the permissions you need while establishing and testing a templated environment. As an example, you can create the following roles within your forensics account:
Responder – Get Evidence
Investigator – Analyze Evidence
Data Controller – manage evidence (copy, move, delete, expire)
Analyst – access forensic reports for analysis, trends and predictions (threat intelligence)
It is recommended that you establish access procedures for each role and describe them in the countermeasure manual. This helps ensure least-privilege access and environmental integrity. For example, a security incident response plan owner establishes a process for reviewing and approving requests for access to the environment. There is also a method called the two-person rule. Log-in alerts are a security measure you can add to increase confidence in the integrity of your environment and monitor unauthorized access.
Investigators typically have read-only access to original collected artifacts, such as Amazon Elastic Block Store (Amazon EBS) snapshots, memory dumps, logs, or Amazon Simple Storage Service (Amazon S3) buckets. It is desirable to have The original source of evidence should be protected. MFA deletion and S3 versioning are two ways to do so. If it's not possible to keep the original immutable, you should work on a copy of a copy, especially if something changes to the artifact. More on this below.
Evidence should only be accessible to those roles that absolutely require access, i.e. investigators and data managers. To prevent potential insider threats from learning of the investigation, read access should also be denied to anyone other than the role that accesses and analyzes the evidence.
Protecting the Integrity of Your Forensic Infrastructure
Once you have established your organization, account structure, and roles, you need to determine the best strategy within the account itself. Analysis of collected artifacts can be done with forensic analysis tools hosted on EC2 instances, ideally within a dedicated Amazon VPC in the forensic account. This Amazon VPC should be configured with the same restrictive approach as before, be completely isolated and auditable, and have the only resources dedicated to the forensic task at hand.
This suggests the possibility that Amazon VPC subnets do not have Internet gateways and therefore all S3 access must be done through the S3 VPC endpoint. VPC Flow Logs must be enabled at the Amazon VPC level to record all network traffic. The security group should be strictly restrictive and should deny all ports not relevant to the requirements of the forensic tools. SSH and RDP access should be restricted and controlled by an auditable mechanism, such as a bastion host configured to log all connections and activity, AWS Systems Manager Session Manager.
If you want to use Systems Manager Session Manager, which has a graphical interface, you can still access it via RDP or other methods. Commands and responses executed using Session Manager can be logged to Amazon CloudWatch and S3 buckets. This enables auditing of all commands executed on Amazon EC2 instances for forensic tools. It is also possible to restrict administrator privileges as needed. You can also configure to receive Amazon Simple Notification Service (Amazon SNS) notifications when new sessions are started.
Given that Amazon EC2 instances dedicated to forensics may not have direct access to the internet, we pre-configure standardized Amazon Machine Images (AMIs) with a set of properly installed and updated tools for analysis. You may need to create a process to deploy. Several best practices apply to this process. The AMI's OS should be hardened to reduce the vulnerable area. You do this by starting with an approved OS image, such as an AMI provided by AWS or one you create and manage yourself.
Next, remove unnecessary programs, packages, libraries, and other components. Make sure all updates and patches are applied, including security patches. Setting up host-based firewalls and intrusion detection tools is also a good precaution. Additionally, ensure that attached disks are always encrypted.
If your OS is supported, we recommend using EC2 Image Builder to create a golden image. Golden images should be updated by rebuilding at least monthly to keep up to date with security patches and features. Combining EC2 Image Builder with other tools can ease the hardening process, for example, by allowing the creation of automated pipelines that generate AMIs hardened with CIS (Center for Internet Security) benchmarks. increase. If you don't want to maintain your own hardened image, you can find the CIS Benchmark AMI on AWS Marketplace.
You will also need to choose the right EC2 instance type keeping in mind the forensic tool's infrastructure requirements (minimum CPU, memory, storage, network requirements, etc.). There are many different types of instances, but based on your minimum requirements and expected workload, you need to make sure you can strike the right balance between cost and performance.
The goal of this environment is to provide the means to gather evidence, conduct a comprehensive investigation, and effectively return to safe operations. Evidence gathering is best done through the automation strategy described in the blog post How to automate incident response in the AWS Cloud for EC2 instances. During the evidence gathering process, it is strongly recommended that evidence be hashed as soon as it is obtained. The hash, and thus the evidence itself, can be verified after subsequent transfer or access, ensuring that the integrity of the evidence is maintained. Preserving original evidence is very important if legal action is taken. Evidence and artifacts include, but are not limited to:
Access to the above control plane logs, like CloudTrail logs, can be done in one of two ways: Ideally, the logs should live in a central location and be accessible read-only for investigation as needed. However, if not centralized, you can give read access to the original logs in the source account if needed. Read access to specific service logs found within your security account, such as AWS Config, Amazon GuardDuty, Security Hub, and Amazon Detective, may be required to correlate evidence and indicators of compromise found during analysis. As mentioned earlier, it is essential to have an immutable version of all evidence. This can be accomplished in a variety of ways, not limited to the examples below.
Note: AWS services like KMS can help enable encryption. KMS is integrated with AWS services to simplify key operations for encrypting data across AWS workloads.
As an example use case for sharing an Amazon EBS disk as evidence to a forensic account, Figure 2 below shows the bucket and folder structure of a simplified S3 bucket used to store and work with evidence.
Figure 2 shows the S3 bucket structure of the forensic account. An S3 bucket and folder are created to hold incoming data (e.g. from Amazon EBS disks), which is streamed to Incoming Data > Evidence Artifacts using dc3dd. The data is then copied from there to a folder in another bucket ( Active Investigation > Root Directory > Extracted Artifacts ) and analyzed with tools installed on forensic Amazon EC2 instances. Also under Active Investigation is a folder for investigative notes created during the analysis (Investigation Notes) and a folder for the final report (Investigation Report) described at the end of this blog post. Finally, buckets and folders for legal holds. This is where object locks are placed to hold evidence artifacts in a particular version.
Figure 2: S3 Bucket Structure of Forensic Account
Things to Consider
Finally, depending on the severity of the incident, your on-premises network and infrastructure may also be at risk. Having an alternative environment available for security responders to prepare for such situations can reduce the risk of being unable to respond in an emergency. Services such as Amazon Workspaces are fully managed, persistent desktop virtualization services that provide a ready-to-use, isolated environment where responders can access digital forensics and indictment tools to perform their tasks. increase.
Apart from research tools, communication services are one of the most important for coordinating responses. With Amazon WorkMail and Amazon Chime, we can offer that capability outside of our regular channels.
Summary
The goal of any forensic investigation is to deliver a final report supported by evidence. This includes what was accessed, who accessed it, how it was accessed, and whether the data was exposed. This report may be required in legal situations, such as criminal or civil investigations, or situations requiring notice of infringement. It is necessary to determine in advance what outputs are required in order to build an appropriate response and reporting process for each situation. Root cause analysis is essential in providing the necessary information to prepare the resources and environment to prevent similar incidents in the future. The report should include not only the root cause analysis, but also the methods, procedures and tools used to draw conclusions.
This post showed you how to get started creating and maintaining a forensic environment so that your team can use AWS services to perform advanced incident resolution investigations. By implementing the foundation of a forensic environment as described above, automated disk collection can be used to initiate an iterative process of forensic data collection functions to prepare for security events.
Let us know what you think about this article in the comments section below. If you have any questions about this blog, please start a new thread on one of the AWS Security, Identity, and Compliance forums or contact AWS Support.
Follow us on Twitter for more AWS Security how-tos, news, and feature announcements.
The translation was handled by Solution Architect Kodai Sato. Here is the original.