Lab: Designing and Testing an Automated Incident Response Plan

This lab provides a guided experience in configuring automated detection and response to security incidents within an AWS environment. You will leverage Amazon GuardDuty for detection and AWS Systems Manager for automated containment of a compromised EC2 instance.

[!WARNING] Remember to run the teardown commands at the end of the lab to avoid ongoing charges. Estimated cost for this lab is under $0.50 if within the Free Tier for GuardDuty and SSM.

Prerequisites

AWS Account: An active AWS account with AdministratorAccess permissions.
AWS CLI: Installed and configured on your local machine with credentials for your account.
Region: We will use us-east-1 for this lab.
Resources: A running EC2 instance (Amazon Linux 2023) to serve as the "target" for containment.

Learning Objectives

Configure Amazon GuardDuty to monitor for malicious activity.
Create an AWS Systems Manager (SSM) Runbook to automate the containment of a resource.
Design an incident response workflow using Amazon EventBridge to link detection to remediation.
Test the effectiveness of the response plan by simulating a security event.

Architecture Overview

The following diagram illustrates the flow of the incident response automation we will build:

Loading Diagram...

Step-by-Step Instructions

Step 1: Enable Amazon GuardDuty

Before we can respond to threats, we must be able to detect them. GuardDuty analyzes VPC Flow Logs, DNS logs, and CloudTrail events.

bash

aws guardduty create-detector --enable --region us-east-1

▶Console alternative

Navigate to GuardDuty in the AWS Management Console.
Click Get Started.
Click Enable GuardDuty.

📸 Screenshot: Ensure the GuardDuty dashboard shows "Detector enabled".

Step 2: Create the Containment Runbook

We will create a simple SSM Automation Document that stops a specified EC2 instance. This represents our "containment" strategy to minimize the blast radius.

Create a file named containment-runbook.json:

json

{
  "description": "Stops an EC2 instance for containment",
  "schemaVersion": "0.3",
  "assumeRole": "{{ AutomationAssumeRole }}",
  "parameters": {
    "InstanceId": { "type": "String", "description": "EC2 Instance ID" },
    "AutomationAssumeRole": { "type": "String", "default": "" }
  },
  "mainSteps": [
    {
      "name": "stopInstance",
      "action": "aws:changeInstanceState",
      "inputs": {
        "InstanceIds": ["{{ InstanceId }}"],
        "DesiredState": "stopped"
      }
    }
  ]
}

Now, upload it to SSM:

bash

aws ssm create-document --content file://containment-runbook.json --name "Lab-Containment-Runbook" --document-type "Automation" --region us-east-1

Step 3: Configure the EventBridge Rule

We need to bridge the gap between GuardDuty findings and our SSM Runbook. We will create a rule that triggers when GuardDuty detects a specific finding type (e.g., SSH Brute Force).

bash

aws events put-rule --name "TriggerContainmentOnGuardDuty" --event-pattern '{"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],"detail":{"type":["UnauthorizedAccess:EC2/SSHBruteForce"]}}' --region us-east-1

[!TIP] In a real-world scenario, you would map the InstanceID from the finding to the Runbook parameter using an Input Transformer.

Step 4: Simulate an Incident

To test our response plan, we will use GuardDuty's "Sample Findings" capability. This generates mock alerts to verify that downstream integrations (EventBridge/SSM) work correctly.

bash

aws guardduty create-sample-findings --detector-id <YOUR_DETECTOR_ID> --finding-types "UnauthorizedAccess:EC2/SSHBruteForce" --region us-east-1

Checkpoints

Checkpoint	Action	Expected Result
Detection	Navigate to GuardDuty > Findings	You should see a sample finding for `SSHBruteForce`.
Remediation	Navigate to EC2 > Instances	The instance associated with the finding should transition to `Stopping` or `Stopped`.
History	Navigate to SSM > Automation	You should see a successful execution of `Lab-Containment-Runbook`.

Troubleshooting

Issue	Potential Cause	Fix
Runbook fails	Permissions	Ensure the SSM Automation role has `ec2:StopInstances` permissions.
Finding not detected	Delay	GuardDuty can take up to 5 minutes to aggregate and export findings to EventBridge.
Rule doesn't trigger	Pattern mismatch	Verify the JSON syntax in the EventBridge event pattern matches the finding type exactly.

Clean-Up / Teardown

To avoid ongoing costs, perform the following steps immediately after completing the lab:

Disable GuardDuty:
bash
aws guardduty delete-detector --detector-id <YOUR_DETECTOR_ID> --region us-east-1
Delete EventBridge Rule:
bash
aws events remove-targets --rule "TriggerContainmentOnGuardDuty" --ids "1" --region us-east-1 aws events delete-rule --name "TriggerContainmentOnGuardDuty" --region us-east-1
Remove SSM Document:
bash
aws ssm delete-document --name "Lab-Containment-Runbook" --region us-east-1
Terminate EC2 Instance: Terminate any instances created for this lab via the EC2 console.

Concept Review

This lab demonstrated the Incident Response Lifecycle in AWS:

Preparation: Creating the SSM Runbook.
Detection: Enabling GuardDuty.
Analysis: EventBridge filtering the specific finding.
Containment: The SSM Automation stopping the instance.

For complex scenarios, consider using AWS Systems Manager Incident Manager, which allows you to define "Response Plans" that include human-in-the-loop engagement and automated runbooks simultaneously.