AWS Security Hub Explained: Findings, Standards, and Setup

Simple explanation

Think of your AWS security services as specialists. GuardDuty watches for threats. Inspector scans for software vulnerabilities. Macie finds exposed sensitive data. Each specialist writes up reports. Security Hub is the team lead who collects every report, puts them in one binder, and adds a scorecard that measures how well your accounts follow security best practices.

Without Security Hub, a team running five AWS accounts with GuardDuty, Inspector, and Macie enabled has to check fifteen separate consoles to understand their security posture. With Security Hub, they check one.

The key mental model: Security Hub is not a detector. It is an aggregator and a compliance checker. It does not replace the services that find problems. It makes sure you actually see what they found and measures how well your configuration follows established frameworks.

What AWS Security Hub is

Security Hub is a cloud security posture management (CSPM) service. It does two things:

1. Aggregates findings. It collects security alerts from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, and third-party tools into one normalized format called the AWS Security Finding Format (ASFF).
2. Runs compliance checks. It continuously evaluates your AWS configuration against security standards like CIS, NIST, and PCI DSS, reporting each control as PASSED, FAILED, WARNING, or NOT_AVAILABLE.

Every finding appears in the same dashboard with the same severity format, whether it comes from GuardDuty detecting a compromised credential or from Security Hub’s own check finding an S3 bucket without encryption. This normalization is what makes Security Hub useful. You do not have to learn five different alert formats or check five different consoles.

Under the shared responsibility model, AWS secures the infrastructure, but you are responsible for your configuration. Security Hub helps you measure how well you are doing on your side of that responsibility.

Why it matters

A production AWS environment typically runs multiple security services. GuardDuty monitors for threat patterns. Inspector scans workloads for known vulnerabilities. Macie identifies exposed sensitive data. CloudTrail logs every API call. Each service generates its own findings in its own console. Without Security Hub, keeping track of all of these requires switching between dashboards and manually correlating information.

Security Hub solves three real problems:

• Visibility. One place to see every security finding across all accounts and regions.
• Prioritization. Normalized severity scores so you can focus on CRITICAL and HIGH findings first, regardless of which service produced them.
• Compliance measurement. Automated checks against CIS, NIST, PCI DSS, and AWS’s own best practices, with a percentage score that updates continuously.

For teams managing multiple accounts through AWS Organizations, this matters even more. Security Hub can aggregate findings across every account in the organization into a single administrator view. Without it, each account is a blind spot.

How Security Hub works

Findings aggregation

When you enable Security Hub and its integrated services, findings flow in automatically. GuardDuty sends a finding when it detects unusual API activity. Inspector sends a finding when it discovers a vulnerable package on an EC2 instance. Security Hub receives these, converts them to ASFF format if needed, assigns severity, and displays them in a unified dashboard.

You do not push findings to Security Hub manually. The integration is automatic once services are enabled. Third-party tools can also send findings through the BatchImportFindings API.

Standards and controls

Security Hub’s compliance engine evaluates your AWS configuration against security standards. Each standard is a collection of controls. A control checks one specific thing. For example: “is CloudTrail enabled in all regions?” or “do any security groups allow unrestricted inbound SSH?”

These checks rely on AWS Config. When you enable a standard, Security Hub creates Config rules behind the scenes that evaluate your resource configuration. This is why AWS Config must be enabled and recording resources before Security Hub standards work correctly.

Regional behavior

Security Hub operates per-region. Findings from resources in us-east-1 appear only in the Security Hub instance in us-east-1. If you have workloads in three regions, you need Security Hub enabled in all three. To view everything together, configure a finding aggregation region: a home region that receives copies of findings from all other linked regions.

Cross-account behavior

In a multi-account setup, you designate one account as the Security Hub administrator (typically the security tooling account, not the management account). Member accounts send their findings to the administrator account. The administrator sees findings and compliance scores across all member accounts in one dashboard.

What Security Hub does and does not do

Security Hub sits in the middle of your security toolchain. The detection services (GuardDuty, Inspector, Macie) feed findings into it. Security Hub normalizes, scores, and presents those findings. Automation services (EventBridge, Lambda) consume findings from Security Hub to trigger responses.

When to use this

Security Hub is valuable when:

• You run multiple AWS security services and want a single view of all findings.
• You manage multiple AWS accounts and need centralized security visibility.
• You need to demonstrate compliance against CIS, NIST, PCI DSS, or AWS best practices.
• You want to automate responses to security findings using EventBridge rules.
• Your organization requires a security score or posture metric that updates continuously.

Before you enable it

Decisions to make before turning on Security Hub:

Enable AWS Config first

Security Hub’s compliance checks depend on AWS Config recording your resource configuration. Enable Config with a recorder that captures all supported resource types in every region where you plan to use Security Hub. Without Config, most controls show NOT_AVAILABLE.

Plan your regions

Security Hub is regional. Enable it in every region you use. If you operate in three regions, enable it in all three and pick one as the finding aggregation region. Many teams also enable Security Hub in regions they do not use. Combined with service control policies that deny resource creation in unused regions, this ensures that any unauthorized activity in those regions still generates findings.

Plan your accounts

In a multi-account setup through AWS Organizations, decide which account will be the delegated Security Hub administrator. AWS recommends using a dedicated security tooling account rather than the management account. The administrator account sees all findings from all member accounts.

Choose which standards to enable

Do not enable every standard on day one in a large environment. Each standard generates findings for every non-compliant control across every resource. Start with AWS Foundational Security Best Practices because it covers the most common issues. Add CIS, NIST, or PCI DSS as your compliance requirements demand.

The currently available standards are:

• AWS Foundational Security Best Practices (FSBP). AWS’s own curated controls covering IAM, S3, EC2, RDS, Lambda, and more. The best default starting point.
• CIS AWS Foundations Benchmark. Versions 1.2.0, 1.4.0, 3.0.0, and 5.0.0 are available. Version 5.0.0 is the latest and recommended.
• NIST SP 800-53 Rev. 5. For organizations with NIST or FedRAMP requirements.
• NIST SP 800-171 Rev. 2. For organizations handling Controlled Unclassified Information (CUI).
• PCI DSS. Versions 3.2.1 and 4.0.1 are available. Version 4.0.1 is the latest.
• AWS Resource Tagging Standard. Checks that resources have required tags. Useful for cost allocation and governance.
• Service-Managed Standard: AWS Control Tower. Available only if you use AWS Control Tower.

Enabling Security Hub

In a single account

# Enable Security Hub with default standards (FSBP and CIS)
aws securityhub enable-security-hub \
  --enable-default-standards \
  --tags Environment=production

# List all available standards and their ARNs
aws securityhub describe-standards

# Enable a specific standard (e.g., CIS v5.0.0)
aws securityhub batch-enable-standards \
  --standards-subscription-requests \
    StandardsArn=arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/5.0.0

# View your compliance score for enabled standards
aws securityhub get-enabled-standards

Across an AWS Organization

For multi-account deployments through AWS Organizations, AWS recommends the central configuration approach. This lets the delegated administrator define configuration policies that control which standards and controls are enabled in each account or organizational unit.

# Step 1: From the management account, designate a delegated admin
aws securityhub enable-organization-admin-account \
  --admin-account-id 111111111111

# Step 2: From the delegated admin account, enable central configuration
aws securityhub update-organization-configuration \
  --auto-enable \
  --organization-configuration ConfigurationType=CENTRAL

# Step 3: Create a configuration policy for the organization
aws securityhub create-configuration-policy \
  --name "org-baseline" \
  --configuration-policy '{
    "SecurityHub": {
      "ServiceEnabled": true,
      "EnabledStandardIdentifiers": [
        "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0"
      ]
    }
  }'

With central configuration, new accounts that join the organization automatically receive the configuration policy. You do not need to enable Security Hub in each account individually. This is the simplest way to maintain consistent security posture across a growing organization.

Working with findings

Every finding in Security Hub has two key attributes you use to triage it:

• Severity: CRITICAL, HIGH, MEDIUM, LOW, or INFORMATIONAL. Start your remediation work with CRITICAL and HIGH.
• Workflow status: NEW, NOTIFIED, RESOLVED, or SUPPRESSED. Use these to track where each finding stands in your remediation process.

When you first enable Security Hub with a standard, expect a flood of findings. This is normal. Filter by severity, focus on CRITICAL findings first, and work down. Assign ownership of finding categories to specific team members. For example, IAM findings go to the identity team, network findings go to the infrastructure team.

Filtering findings

# Get all CRITICAL findings that are still NEW
aws securityhub get-findings \
  --filters '{
    "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}],
    "WorkflowStatus": [{"Value": "NEW", "Comparison": "EQUALS"}]
  }' \
  --sort-criteria '{"Field": "UpdatedAt", "SortOrder": "desc"}' \
  --max-results 20

Resolving and suppressing findings

# Mark a finding as resolved after remediation
aws securityhub batch-update-findings \
  --finding-identifiers Id=arn:...,ProductArn=arn:... \
  --workflow Status=RESOLVED \
  --note '{"Text": "Remediated in PR #1234", "UpdatedBy": "alice"}'

# Suppress a finding that does not apply to your environment
aws securityhub batch-update-findings \
  --finding-identifiers Id=arn:...,ProductArn=arn:... \
  --workflow Status=SUPPRESSED \
  --note '{"Text": "Not applicable - bucket serves public static assets only", "UpdatedBy": "alice"}'

Suppressed findings are excluded from compliance scores. Always add a note explaining the suppression. Auditors will ask why, and “not applicable” without context is not an adequate answer. Following least privilege principles, restrict who can suppress findings so that individual engineers cannot quietly dismiss alerts they should be fixing.

Automating responses

Security Hub sends all findings to Amazon EventBridge automatically. You can create EventBridge rules that match specific finding patterns and trigger Lambda functions, SNS notifications, or Step Functions workflows.

For example, automatically isolate an EC2 instance when GuardDuty detects it communicating with a command-and-control server:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {
        "Label": ["CRITICAL"]
      },
      "ProductName": ["GuardDuty"],
      "Types": ["TTPs/Command and Control*"]
    }
  }
}

This EventBridge rule matches any CRITICAL GuardDuty finding related to command-and-control activity. The target Lambda function could move the affected EC2 instance into a quarantine security group with no outbound access, revoke associated IAM role sessions, and send an alert to your security team through Slack or PagerDuty. For patterns to detect in your logs, see detecting suspicious activity in AWS logs.

AWS Security Hub vs GuardDuty vs Inspector vs Macie

These four services are complementary, not competing. Here is how they differ:

The short version: GuardDuty finds threats, Inspector finds vulnerabilities, Macie finds exposed data, and Security Hub collects all of their findings into one place and adds compliance scoring. Disabling Security Hub does not stop the other services from working. They continue independently. But you lose the single-pane view and the compliance checks.