AWS Security Hub: Centralized Security Posture Management

You've got 500 AWS accounts, each with 50 security findings per day. Your security team is drowning in alerts from GuardDuty, Inspector, Macie, and a dozen third-party tools. You're spending more time triaging noise than fixing actual risks. That's the exact problem AWS Security Hub was built to solve—but only if you configure it right. Most teams treat it as a simple aggregator, then wonder why their findings are still a mess. The truth is, Security Hub is a powerful normalization engine that can reduce alert fatigue by 80% when you properly tune its integration rules, custom actions, and automated response workflows. This article cuts through the marketing fluff and shows you how to deploy Security Hub for real production environments, including multi-account aggregation, custom insight rules, and integration with incident response pipelines.

Why Centralized Security Posture Management Matters

In multi-account AWS environments, security teams face a fragmented view of threats. Each account generates its own findings from services like GuardDuty, Inspector, and Macie, making it nearly impossible to correlate incidents or enforce consistent policies. AWS Security Hub aggregates these findings into a single dashboard, normalizing them with the AWS Security Finding Format (ASFF). This eliminates the need to manually stitch together data from multiple sources. Without centralized management, you risk missing critical alerts buried in individual account consoles. Security Hub also integrates with AWS Organizations, allowing you to enable it across all accounts with a single API call. The real value emerges when you automate responses—for example, triggering a Lambda function to isolate an EC2 instance when a high-severity finding appears. In production, failing to centralize leads to alert fatigue and delayed incident response, which directly impacts compliance postures like SOC 2 or PCI DSS.

#!/bin/bash
# Enable Security Hub in the management account and all member accounts
aws securityhub enable-security-hub --region us-east-1 --enable-default-standards

# Associate member accounts (assuming AWS Organizations)
aws organizations list-accounts --query 'Accounts[?Status=="ACTIVE"].Id' --output text | tr '\t' '\n' | while read account_id; do
  aws securityhub create-members --account-details "AccountId=$account_id" --region us-east-1
  aws securityhub invite-members --account-ids $account_id --region us-east-1
done

Architecture: How Security Hub Ingest and Normalize Findings

Security Hub acts as a central ingestion point for findings from AWS services and third-party tools. It uses the ASFF schema to normalize data, making it queryable via APIs and Athena. The ingestion pipeline works as follows: enabled services (e.g., GuardDuty, Inspector, Macie) push findings to Security Hub via AWS Config rules or direct integration. Third-party tools can use the BatchImportFindings API. Once ingested, Security Hub applies deduplication and enrichment, such as adding resource tags or severity adjustments. The normalized findings are stored for up to 90 days. For long-term retention and analysis, you can export findings to Amazon S3 or stream them to Amazon EventBridge. In production, we found that enabling all default standards (CIS, PCI DSS, AWS Foundational Security Best Practices) generates a high volume of low-severity findings. To avoid noise, we recommend customizing standards and using filters to suppress known false positives. The architecture must also account for cross-region aggregation—Security Hub is regional, so you need a central region (e.g., us-east-1) to aggregate findings from all regions using cross-region aggregation rules.

import boto3
from datetime import datetime

client = boto3.client('securityhub', region_name='us-east-1')

# Example finding from a custom scanner
finding = {
    'SchemaVersion': '2018-10-08',
    'Id': 'custom-scanner/2023/11/01/12345',
    'ProductArn': 'arn:aws:securityhub:us-east-1::product/custom-scanner',
    'GeneratorId': 'custom-scanner',
    'AwsAccountId': '123456789012',
    'Types': ['Software and Configuration Checks/Vulnerabilities/CVE'],
    'CreatedAt': datetime.utcnow().isoformat() + 'Z',
    'UpdatedAt': datetime.utcnow().isoformat() + 'Z',
    'Severity': {'Product': 7.5, 'Normalized': 75},
    'Title': 'Critical vulnerability in web server',
    'Description': 'CVE-2023-1234 found in Apache 2.4.49',
    'Resources': [{'Type': 'AwsEc2Instance', 'Id': 'i-0abcd1234efgh5678'}],
    'Compliance': {'Status': 'FAILED'},
    'Workflow': {'Status': 'NEW'},
    'RecordState': 'ACTIVE'
}

response = client.batch_import_findings(
    Findings=[finding]
)
print(f"Success count: {response['SuccessCount']}")

Automating Response with EventBridge and Lambda

Security Hub's true power comes from automation. By integrating with Amazon EventBridge, you can trigger workflows based on finding severity or type. For example, when a high-severity finding like 'UnauthorizedAccess:EC2/SSHBruteForce' appears, you can automatically isolate the instance by modifying its security group. The pattern is: Security Hub sends findings to EventBridge as events. EventBridge rules match specific patterns (e.g., severity >= 70) and invoke a Lambda function. The Lambda function parses the finding, identifies the affected resource, and performs remediation. In production, we built a tiered response system: critical findings trigger immediate isolation, high findings trigger a ticket in Jira, and medium findings are logged for review. One common failure mode is over-automation—automatically terminating instances without proper validation can cause production outages. Always include a rollback mechanism and manual approval for destructive actions. Also, ensure your Lambda function has the necessary IAM permissions to modify resources in the affected account. For cross-account automation, use a central automation account with cross-account IAM roles.

import json
import boto3

eventbridge = boto3.client('events')

def lambda_handler(event, context):
    # Parse the Security Hub finding from EventBridge event
    detail = event['detail']
    finding_id = detail['findings'][0]['Id']
    severity = detail['findings'][0]['Severity']['Normalized']
    resource_id = detail['findings'][0]['Resources'][0]['Id']
    
    if severity >= 70:
        # Isolate the EC2 instance by removing all security groups except a quarantine one
        ec2 = boto3.client('ec2')
        quarantine_sg = 'sg-0123456789abcdef0'
        try:
            ec2.modify_instance_attribute(
                InstanceId=resource_id,
                Groups=[quarantine_sg]
            )
            print(f"Isolated instance {resource_id}")
            # Update finding workflow status
            securityhub = boto3.client('securityhub')
            securityhub.batch_update_findings(
                FindingIdentifiers=[{'Id': finding_id, 'ProductArn': 'arn:aws:securityhub:us-east-1::product/aws/securityhub'}],
                Workflow={'Status': 'RESOLVED'}
            )
        except Exception as e:
            print(f"Failed to isolate: {e}")
            # Send to SNS for manual intervention
            sns = boto3.client('sns')
            sns.publish(
                TopicArn='arn:aws:sns:us-east-1:123456789012:security-alerts',
                Message=json.dumps({'finding': finding_id, 'error': str(e)})
            )
    return {'statusCode': 200}

Custom Actions and Playbooks for Incident Response

Security Hub supports custom actions that appear in the console, allowing analysts to trigger predefined workflows. For example, you can create a custom action called 'Remediate' that sends the finding to a Step Functions state machine for investigation. To set this up, you create a custom action in Security Hub, which generates an ActionTarget ARN. Then, you configure an EventBridge rule that matches the custom action event and invokes a Lambda or Step Functions. This bridges the gap between automated and manual response. In production, we built a playbook for 'S3 Bucket Public Access' findings: the custom action triggers a Step Functions workflow that first checks if the bucket truly needs public access, then either applies a bucket policy or creates a ticket for review. The key is to keep playbooks simple and test them regularly. A common mistake is making playbooks too complex, leading to failures in the middle of a response. Also, ensure that custom actions are only available to authorized IAM roles to prevent accidental triggers. We also log all custom action invocations to CloudTrail for audit purposes.

{
  "EventPattern": {
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Custom Action"],
    "detail": {
      "action-target": ["arn:aws:securityhub:us-east-1:123456789012:action/custom/remediate-s3"]
    }
  },
  "State": "ENABLED",
  "Targets": [
    {
      "Arn": "arn:aws:states:us-east-1:123456789012:stateMachine:s3-remediation-playbook",
      "Id": "StepFunctionsTarget",
      "RoleArn": "arn:aws:iam::123456789012:role/eventbridge-invoke-stepfunctions"
    }
  ]
}

Compliance Monitoring with Security Hub Standards

Security Hub provides built-in compliance standards: CIS AWS Foundations, PCI DSS, and AWS Foundational Security Best Practices. These standards continuously evaluate your accounts against hundreds of controls. For example, CIS 2.1 checks if CloudTrail is enabled in all regions. When a control fails, Security Hub generates a finding. You can also enable custom standards using AWS Config rules. In production, we found that enabling all standards at once generates thousands of findings, most of which are informational. To avoid noise, we prioritize standards based on compliance requirements. For PCI DSS, we only enable the relevant controls. We also use filters to suppress known false positives, like a control that checks for MFA on root account but we already have an organizational policy. Another tip: use the 'Compliance' status in findings to track remediation progress. We built a dashboard in QuickSight that shows compliance scores over time. One failure mode is not updating standards when new controls are added—AWS periodically updates standards, so you must review changes to avoid unexpected failures.

#!/bin/bash
# Enable specific standards
aws securityhub enable-security-hub --region us-east-1 --enable-default-standards

# Disable a standard if not needed
aws securityhub batch-disable-standards \
  --standards-subscription-arns arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/1.4.0

# List enabled standards
aws securityhub get-enabled-standards --region us-east-1 --query 'StandardsSubscriptions[].StandardsArn'

Integrating Third-Party Tools for Extended Coverage

Security Hub supports integration with third-party security tools via the AWS Security Hub Finding Provider (ASFF) API. Popular integrations include CrowdStrike, Palo Alto Networks, and Splunk. These tools can send findings to Security Hub, allowing you to view them alongside AWS-native findings. To integrate, you typically install a solution from AWS Marketplace or configure the tool to push findings via API. In production, we integrated a custom vulnerability scanner that sends findings to Security Hub. The key is to map your tool's severity levels to ASFF normalized severity (0-100). We also use the 'ProductArn' field to distinguish findings from different sources. One challenge is deduplication—Security Hub does not automatically deduplicate across different products. You may need to implement custom logic to merge similar findings. Another consideration is cost: each finding ingestion incurs a small fee, so high-volume tools can increase costs. We recommend setting up filters in the third-party tool to only send findings above a certain severity. Also, ensure that the IAM role used by the third party has the minimum permissions to call BatchImportFindings.

import boto3
import requests

# Fetch findings from a third-party API (example)
response = requests.get('https://third-party-scanner.example.com/api/findings', headers={'Authorization': 'Bearer token'})
findings = response.json()

client = boto3.client('securityhub', region_name='us-east-1')

asff_findings = []
for f in findings:
    asff_finding = {
        'SchemaVersion': '2018-10-08',
        'Id': f['id'],
        'ProductArn': 'arn:aws:securityhub:us-east-1::product/third-party-scanner',
        'GeneratorId': 'third-party-scanner',
        'AwsAccountId': '123456789012',
        'Types': ['Software and Configuration Checks/Vulnerabilities/CVE'],
        'CreatedAt': f['created_at'],
        'UpdatedAt': f['updated_at'],
        'Severity': {'Product': f['severity'], 'Normalized': int(f['severity'] * 10)},
        'Title': f['title'],
        'Description': f['description'],
        'Resources': [{'Type': 'AwsEc2Instance', 'Id': f['resource_id']}],
        'Compliance': {'Status': 'FAILED'},
        'Workflow': {'Status': 'NEW'},
        'RecordState': 'ACTIVE'
    }
    asff_findings.append(asff_finding)

response = client.batch_import_findings(Findings=asff_findings)
print(f"Imported {response['SuccessCount']} findings")

Cost Management and Optimization

Security Hub pricing is based on the number of findings ingested and the number of enabled standards. Each account incurs a monthly fee per standard, plus a per-finding fee. In a large organization with hundreds of accounts, costs can escalate quickly. To optimize, disable standards that are not required for compliance. For example, if you don't need PCI DSS, disable that standard. Also, use finding filters to suppress low-severity findings before ingestion—this reduces the per-finding cost. Another strategy is to aggregate findings from member accounts into a central account and disable Security Hub in member accounts (except for the central one). However, this may break some integrations. We also recommend setting up budgets and alerts to monitor costs. In production, we saw a 60% cost reduction by disabling the CIS standard (which we didn't need) and filtering out informational findings. One failure mode is forgetting to disable Security Hub in accounts that are no longer active—orphaned accounts still incur costs. Use AWS Config rules to detect accounts with Security Hub enabled but no resources.

#!/bin/bash
# Disable unused standards
aws securityhub batch-disable-standards \
  --standards-subscription-arns arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/1.4.0

# Disable Security Hub in member accounts (if using central aggregation)
for account in $(aws organizations list-accounts --query 'Accounts[?Status=="ACTIVE"].Id' --output text); do
  aws securityhub disable-security-hub --region us-east-1 --account-id $account
done

# Set up a budget alert for Security Hub costs
aws budgets create-budget --account-id 123456789012 --budget '{
  "BudgetName": "SecurityHubBudget",
  "BudgetLimit": {"Amount": 500, "Unit": "USD"},
  "CostFilters": {"Service": ["AWS Security Hub"]},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}' --notifications-with-subscribers '[
  {
    "Notification": {"NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80},
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "security-team@example.com"}]
  }
]'

Advanced: Custom Insights and Aggregation Rules

Security Hub allows you to create custom insights—groupings of findings based on specific criteria. For example, you can create an insight for 'Critical S3 Public Access Findings' that groups findings by resource. Insights are useful for dashboards and reporting. To create an insight, you define a filter and a group by field. Additionally, you can set up aggregation rules to automatically group related findings. For example, if multiple findings point to the same resource, you can aggregate them into a single 'case'. This reduces noise and helps prioritize remediation. In production, we created an insight for 'Top 10 Most Vulnerable Resources' to focus our patching efforts. We also used aggregation rules to combine findings from GuardDuty and Inspector for the same EC2 instance. One advanced technique is to export findings to Amazon OpenSearch Service for custom analytics. We built a dashboard that shows trends in mean time to remediate (MTTR) across teams. The key is to regularly review and update insights as your environment changes. Stale insights can mislead prioritization.

import boto3

client = boto3.client('securityhub', region_name='us-east-1')

# Create an insight for critical S3 public access findings
response = client.create_insight(
    Name='Critical S3 Public Access',
    Filters={
        'SeverityNormalized': [{'Gte': 70}],
        'ResourceType': [{'Value': 'AwsS3Bucket', 'Comparison': 'EQUALS'}],
        'ComplianceStatus': [{'Value': 'FAILED', 'Comparison': 'EQUALS'}]
    },
    GroupByAttribute='ResourceId'
)
print(f"Insight ARN: {response['InsightArn']}")

# Create an aggregation rule (via API, but typically done via console)
# Note: Aggregation rules are not directly available via API; use CloudFormation or console.