# Guidance components
The Guidance comprises of the following five key components that collaborate to provide EC2 and EKS forensic orchestration capability:
+ Forensic triage service
+ Forensic memory acquisition service
+ Forensic disk acquisition service
+ Forensic investigation and reporting service
+ Forensic image and AWS Systems Manager document builder service
# Forensic triage service
The diagram below represents the logical interaction view of the forensic triage service. A security event (Application security event) is reported by the Threat Detection Engine. The Threat Detection Engine initiates triaging function to determine the severity of threat based on the threat and infrastructure information. The triaging function initiates forensic acquisition and investigation flow for further analysis.
## Interaction view
**Forensic triage workflow**
![\[forensic triage workflow\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/forensic-triage-workflow.png)
## Implementation view
**Forensic triage - implementation view**
![\[forensic triage implementation view\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/forensic-triage-implementation-view.png)
AWS Security Hub operating in AWS application account is reported with details of the compromised instance and the findings get aggregated to AWS Security Hub administrator AWS master Account. . The security administrator initiates one of the following forensic actions in Security Hub.
\$1 .. Forensic triage .. Forensic isolation . Amazon EventBridge initiates the *triage* Step Functions flow. . *Get Instance* Lambda function assumes role into compromised application account and retrieves instance information. . The *triage flow* triggers *acquisition flow* in parallel unless the instance tag **IsTriageRequired** is set to `false`.
\$1 .. *Forensic memory acquisition flow* initiates the memory acquisition Step Functions. .. *Forensic disk acquisition flow* initiates the disk acquisition Step Functions. . Once completed, the acquisition flow triage results are sent to SNS.
# Forensic memory and disk acquisition service
The diagram below represents the logical interaction view of the forensic memory and disk acquisition service. The Forensic triaging step function initiates forensic acquisition flow to perform memory and disk acquisition. Following memory and disk acquisition, the investigation function is initiated.
Isolation of EC2 instance or EKS cluster is done based on the Security Hub action event types - Forensic triage and Forensic isolation.
## Interaction view
**"Forensic memory disk acquisition**
![\[interaction step"\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/forensic-memory-disk-acquisition-interaction.png)
## Implementation view
**Memory forensics acquisition workflow implementation**
![\[memory forensics acquisition workflow implementation\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/memory-forensics-acquisition-workflow-implementation.png)
The *Forensic triage* Step Function initiates the *memory acquisition* flow. . The *Memory acquisition* Lambda function in workflow leverages the SSM command to run SSM document in the compromised instance. . The *Memory acquisition* Lambda function assumes a role in the application account and passes the SSM document to be run along with credentials to copy the memory dump into an S3 bucket. . AWS Systems Manager runs a memory acquisition document via the Run Command.
\$1 ** The memory dump is stored in an S3 bucket of the forensic account. ** The memory dump has associated meta data tags to indicate the underlying OS and kernel the dump is associated with, assisting the *memory analysis flow* further downstream. . The *Check memory acquisition* Lambda function checks for SSM Run Command to be completed. . If the response from SSM Run Command status is `Pending` or `Delayed` or `In Progress`, it waits for 120 seconds. . If the response from SSM Run Command status is `Success`, it checks if isolation is needed. . If **isolation** is set to `true`, then the Lambda function assumes role into the application account and attaches a security group with no egress and ingress security group, and detaches the existing security group. Isolation is set to `true` during the triaging phase based on security event type. . This initiates investigation flow with forensic type as `MEMORY`. . If any error occurs during the memory acquisition process, the EC2 instance or EKS cluster isolation will be performed based on the `isolation` flag.
**Note**
When the isolation flag is set to `true`, isolation is still performed regardless of the memory acquisition result.
## What happens to instances after isolation?
Instances after isolation will have:
+ Termination protection for the compromised EC2 instance or EKS cluster is set to `true`
+ Shutdown behavior set to `STOP`
+ Any EIP assigned to the compromised instance will be disassociated
+ EBS volumes attached to the compromised instance will be preserved
+ Instance profile will be updated to a strict profile
+ All open credentials session based on the compromised instance role will be invalidated.
**Note**
On isolation, instances sharing the same role with the compromised instance would be impacted as the credentials will be invalidated. If your application does not have the correct retry mechanism to renew new credentials, it can result in failure of the application. For more information, refer to the [Using temporary credentials with AWS resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html#using-temp-creds-sdk-ec2-instances) topic about creating new credentials. Applications using AWS CLI will not be impacted as the credentials will be refreshed automatically
# Disk forensics acquisition workflow
**Disk forensics acquisition workflow**
![\[disk forensics acquisition workflow\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/disk-forensics-acquisition-workflow.png)
The *Forensic triage* Step Function initiates *disk acquisition flow*. . The *Perform Instance Snapshot* Lambda function performs an instance snapshot. . The *Perform Instance Snapshot* Lambda function assumes a role in the application account and initiates an instance snapshot API call. . *Check for Instance Snapshot* Lambda function assumes a role in the application account and checks for snapshot completion. . If the response is `Pending` or `In Progress` it waits for 120 seconds. . The disk acquisition flow [copies](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) the compromised instance snapshot using AWS KMS keys shared with the forensic account. . After the copy snapshot operation of the compromised instance, the disk acquisition flow [shares](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html) the copied EBS snapshot with the forensic account. . To keep the copy of snapshot in the forensic account, copy the shared copy of compromised instance snapshot using Forensic KMS keys. This step allows protection of the shared snapshot with a local copy to perform forensics in case of the AWS account being compromised, or the shared snapshot being deleted by the security team. . Post copy flow the step functions initiates the investigation flow with forensic type as `DISK`.
# Forensic investigation and reporting service
The diagram below represents the logical interaction view of forensic memory and disk investigation service. Once forensic acquisition is completed, forensic investigation flow is initiated, isolation of EC2 instance or EKS cluster is done based on the AWS Security Hub event type.
## Interaction view
**Forensic investigation and reporting service - interaction view**
![\[forensic investigation and reporting interaction\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/forensic-investigation-and-reporting-interaction.png)
## Implementation view
**Forensic investigation and reporting service**
![\[forensic investigation and reporting service\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/forensic-investigation-and-reporting-service.png)
## Forensic investigation and reporting workflow
1. After the acquisition flow, the investigation flow (Step Functions) is initiated.
1. The *Create Instance* Lambda function retrieves the AMI information from AWS Systems Manager Parameter Store and starts an instance in the forensic account.
1. The *Check Instance Lambda* function validates the instance has the necessary tools required for forensic investigation, such as determining the instance is in the running state, AWS Systems Manager is installed and forensic tools are up and running.
1. If the response from SSM Command is `Pending` or `In Progress` it waits for 120 seconds and checks again.
1. Disk forensics investigation flow is initiated for **forensictype** variable set to `DISK`.
1. Disk forensics investigation lambda function creates a volume from the snapshot shared with the forensic account and attaches the volume to the instance started in step 2.
1. The Disk forensics investigation Lambda function leverages the SSM document to perform disk forensics.
1. The Memory forensics investigation flow is initiated for **forensictype** variable set to `MEMORY`.
1. The Lambda function leverages the SSM document to load memory dump from S3 to the EBS volume for memory analysis.
+ The SSM document containing details of the forensic investigation is initiated to *perform disk or memory forensics*.
+ The *Memory forensics flow* retrieves the appropriate meta data tag associated with the memory dump and loads the matching kernel Volatility symbol table from a configurable S3 location.
1. The Lambda function checks if AWS Systems Manager Run Command is complete.
1. The Lambda function waits for 120 seconds before checking again if AWS Systems Manager Run Command is complete.
1. Once complete, the *Terminate Forensic Instance* Lambda function is initiated.
1. The forensic instance is terminated.
1. Details about forensic ID, compromised Amazon EC2 instance or EKS cluster, Amazon S3 bucket location of the results, and Amazon DynamoDB table details about disk and memory analysis are sent as SNS.
# Forensic image and SSM Document builder service
The forensic image builder pipeline creates the forensic AMI with necessary forensic tools needed to perform forensic investigation. The diagram below represents the overall implementation.
**Note**
Customers can use your own forensic AMI or leverage the [Amazon EC2 Image Builder samples](https://github.com/aws-samples/amazon-ec2-image-builder-samples/tree/master/CDK/Linux/hello-world) to build a forensic Image.
**Forensic image and SSM document builder service**
![\[forensic image ssm document builder\]](http://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/images/forensic-image-ssm-document-builder.png)
Amazon EC2 Image Builder initiates the EC2 Image Builder pipeline to build the EC2 Image based on the forensic tools configured in the document. . After successful creation of the AMI, it drops the message as an Amazon SNS topic. . The AWS Lambda function listens to the Amazon SNS topic and gets initiated for each message. . The AWS Lambda function stores the AMI ID in Parameter Store and is used to launch the forensic instance.