AWS Security Hub & GuardDuty Integration
Implement comprehensive AWS security monitoring with Security Hub, GuardDuty, and automated incident response for threat detection and compliance.
📋 Prerequisites
- In-depth experience with GuardDuty, Security Hub, IAM, and EventBridge.
- Proficiency in Python for writing Lambda functions.
- Strong skills in Infrastructure as Code, specifically Terraform.
- An AWS Organization with a dedicated, delegated security administrator account.
💡 From Alert Fatigue to Automated Response
Effective security operations isn't about staring at dashboards; it's about speed and consistency of response. By integrating GuardDuty's threat detection with Security Hub's aggregation and custom actions, you can build a powerful, semi-automated incident response engine. This approach transforms your SecOps from a reactive, manual process into a highly efficient, orchestrated framework.
What You'll Learn
🏷️ Topics Covered
Centralized Security Operations Architecture
At scale, security services must be managed centrally. The best practice is to designate a "Security" or "Audit" account within your AWS Organization as the **delegated administrator** for both GuardDuty and Security Hub. This account aggregates all findings, manages configurations, and serves as the execution environment for response actions.
🎯 The Delegated Administrator Model
This model ensures that member accounts cannot tamper with security monitoring. The central security account has a complete, organization-wide view of threats and compliance, enabling consistent policy enforcement and incident response.
🛡️ Delegated Security Account
A dedicated account that manages security services, aggregates findings, and orchestrates incident response for the entire organization.
👥 Member Accounts
All other accounts in the organization, automatically enrolled as members. GuardDuty and Security Hub are enabled and managed from the central account.
📊 Centralized Dashboards
Security Hub provides a single pane of glass to view, filter, and act on findings from GuardDuty, Inspector, IAM Access Analyzer, and more.
⚙️ Global EventBridge Bus
A central EventBridge bus in the security account receives all Security Hub findings, serving as the trigger point for all automated workflows.
Creating Custom Actions for Analyst Response
Security Hub Custom Actions allow you to embed your response playbooks directly into the console. An analyst can select a finding and trigger a predefined workflow, such as "Isolate Instance" or "Archive Finding," with a single click. This bridges the gap between detection and response.
Example: Defining an "Isolate and Snapshot" Action
This Terraform code creates a custom action in Security Hub that analysts can invoke on findings related to compromised EC2 instances.
🏗️ HCL: Security Hub Custom Action in Terraform
resource "aws_securityhub_action_target" "isolate_and_snapshot" {
name = "Isolate and Snapshot EC2"
description = "Applies a quarantine SG, snapshots EBS volumes, and tags the instance."
identifier = "IsolateAndSnapshot"
}Building an Automated Incident Response Workflow
This is where the automation comes to life. The custom action sends an event to EventBridge, which then triggers a Lambda function to execute a complex, multi-step response playbook.
Detection
GuardDuty detects an EC2 instance making unauthorized cryptocurrency miners calls.
Analyst Action
Analyst views the high-severity finding in Security Hub and triggers the "Isolate and Snapshot EC2" custom action.
Trigger
EventBridge catches the custom action event and invokes the response Lambda function.
Response
The Lambda function executes the playbook: isolate, snapshot, tag, and notify.
Example: Incident Response Lambda Function
This Python function contains the logic to perform the isolation and forensics preparation steps.
🐍 Python: Incident Response Lambda
import boto3
import json
import os
from datetime import datetime
ec2 = boto3.client('ec2')
SNS_TOPIC_ARN = os.environ['SNS_TOPIC_ARN']
QUARANTINE_SG_ID = os.environ['QUARANTINE_SG_ID']
def lambda_handler(event, context):
print(json.dumps(event))
finding = event['detail']['findings'][0]
resource = finding['Resources'][0]
instance_id = resource['Id'].split('/')[-1]
try:
# 1. Isolate the instance by applying a quarantine security group
print(f"Isolating instance: {instance_id}")
ec2.modify_instance_attribute(
InstanceId=instance_id,
Groups=[QUARANTINE_SG_ID]
)
# 2. Snapshot EBS volumes for forensics
print(f"Snapshotting volumes for instance: {instance_id}")
volumes = ec2.describe_volumes(Filters=[{'Name': 'attachment.instance-id', 'Values': [instance_id]}])
for vol in volumes['Volumes']:
ec2.create_snapshot(
VolumeId=vol['VolumeId'],
Description=f"Forensic snapshot for incident {finding['Id']}"
)
# 3. Tag the instance for tracking
print(f"Tagging instance: {instance_id}")
ec2.create_tags(
Resources=[instance_id],
Tags=[
{'Key': 'SecurityStatus', 'Value': 'Quarantined'},
{'Key': 'IncidentID', 'Value': finding['Id']}
]
)
# 4. Notify SecOps team
message = f"Successfully isolated and snapshotted instance {instance_id} due to GuardDuty finding: {finding['Title']}"
boto3.client('sns').publish(TopicArn=SNS_TOPIC_ARN, Message=message)
return {'status': 'SUCCESS', 'message': message}
except Exception as e:
print(f"Error during incident response: {e}")
boto3.client('sns').publish(TopicArn=SNS_TOPIC_ARN, Message=f"FAILED to respond to incident for instance {instance_id}. Error: {e}")
raise eDeploying the Full Framework with Terraform
To ensure this response framework is reliable and repeatable, all components—the custom action, the EventBridge rule, the Lambda function, and its IAM role—must be defined as code.
🏗️ HCL: Complete SecOps Automation Stack
# 1. The Security Hub Custom Action (already defined)
resource "aws_securityhub_action_target" "isolate_and_snapshot" {
name = "Isolate and Snapshot EC2"
description = "Applies a quarantine SG, snapshots EBS volumes, and tags the instance."
identifier = "IsolateAndSnapshot"
}
# 2. The EventBridge Rule to catch the custom action
resource "aws_cloudwatch_event_rule" "capture_custom_action" {
name = "CaptureSecurityHubIsolateAction"
description = "Fires when the IsolateAndSnapshot custom action is invoked"
event_pattern = jsonencode({
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Custom Action"],
"detail": {
"actionName": ["Isolate and Snapshot EC2"]
}
})
}
# 3. The Lambda function (assuming code is zipped) and IAM Role
resource "aws_iam_role" "ir_lambda_role" {
# ... Assume role policy for Lambda
}
resource "aws_iam_policy" "ir_lambda_policy" {
# ... Policy granting ec2:ModifyInstanceAttribute, ec2:CreateSnapshot, etc.
}
resource "aws_lambda_function" "incident_response_lambda" {
function_name = "IncidentResponseHandler"
handler = "response_handler.lambda_handler"
role = aws_iam_role.ir_lambda_role.arn
runtime = "python3.9"
filename = "response_handler.zip"
environment {
variables = {
SNS_TOPIC_ARN = "arn:aws:sns:..."
QUARANTINE_SG_ID = "sg-quarantine"
}
}
}
# 4. Link the EventBridge rule to the Lambda function
resource "aws_cloudwatch_event_target" "lambda_target" {
rule = aws_cloudwatch_event_rule.capture_custom_action.name
target_id = "IncidentResponseLambda"
arn = aws_lambda_function.incident_response_lambda.arn
}
resource "aws_lambda_permission" "allow_eventbridge" {
statement_id = "AllowExecutionFromEventBridge"
action = "lambda:InvokeFunction"
function_name = aws_lambda_function.incident_response_lambda.function_name
principal = "events.amazonaws.com"
source_arn = aws_cloudwatch_event_rule.capture_custom_action.arn
}Correlating Findings with Custom Insights
With thousands of findings, you need a way to filter for what matters most. Security Hub Insights allow you to create saved, correlated views of your findings. This helps you quickly identify trends and prioritize high-risk issues.
Example: Insight for High-Severity Findings on Production Resources
This insight filter will create a view showing only High or Critical severity findings from any service that are on resources tagged with `Environment=Production`.
📊 JSON: Security Hub Custom Insight Filter
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "HighSeverityOnProd",
"Effect": "Allow",
"Principal": "*",
"Action": "securityhub:GetFindings",
"Resource": "*",
"Condition": {
"StringEquals": {
"securityhub.Finding:RecordState": "ACTIVE",
"securityhub.Finding:Workflow.Status": "NEW",
"securityhub.Finding:Resources.Tags.Environment": "Production"
},
"LabelEquals": {
"securityhub.Finding:Severity.Label": [
"HIGH",
"CRITICAL"
]
}
}
}
]
}🔑 Advanced SecOps Best Practices
- Delegate Administration: Always use the delegated administrator model for GuardDuty and Security Hub to ensure central control and prevent tampering.
- Automate Response, Not Just Detection: Go beyond alerting. Build automated playbooks for common findings to reduce mean time to response (MTTR).
- Keep a Human-in-the-Loop: For destructive actions (like terminating an instance), configure your workflow to require manual approval (e.g., via a Slack message with buttons or a Step Functions callback).
- Use Tags for Context: Enrich your findings by ensuring all resources are tagged with application, owner, and environment information. Use this context in your response logic.
- Develop Custom Playbooks: Different findings require different responses. Create separate Lambda functions or Step Functions workflows for different finding types (e.g., IAM vs. EC2 vs. S3).
- Tune Your Findings: Use suppression rules in Security Hub to silence noisy or low-value findings so your team can focus on what's critical.