Raghu Reddy

Posted on Sep 30, 2025 • Edited on Apr 25

AWS Security Hub in Action: Expert Strategies for Threat Detection and Compliance

#aws #cybersecurity #infosec #security

AWS Security Hub in Action: Expert Strategies for Threat Detection and Compliance

Updated April 25, 2026: The new Security Hub went GA in December 2025 with near real time analytics and signal correlation. Originally written in September 2025 when this was still in preview. Everything below still works, the new GA features sit on top of it.

It's 2 AM. A security engineer has six browser tabs open. GuardDuty is flagging a suspicious API call from an IP in some country she cannot pronounce. Inspector wants attention on three EC2 instances with critical CVEs. Macie has flagged a bucket holding credit card numbers in plaintext. Config is failing nine rules. CloudTrail is fine, probably. Two of those tabs have not loaded yet.

Which fire does she put out first? She has no idea. There's no single place that ranks all of this by what actually matters. So she picks the loudest alarm and hopes for the best.

This is the problem AWS Security Hub was built to solve. With the preview of the new Security Hub announced at re:Inforce 2025, which adds near real time risk analytics and signal correlation across services, it's on track to become something close to a unified security operations console rather than just an aggregator.

This post covers what threat detection and compliance actually mean, where Security Hub fits in solving both, and two real use cases that take you from basic visibility to continuous compliance posture. The use cases are ordered simple to advanced, so you can implement them in that order if you are starting fresh.

Threat Detection and Compliance, Briefly

These two terms get used interchangeably in vendor marketing, and that's part of why teams stay confused.

Threat detection is about catching bad behavior in the act. Someone is brute forcing your IAM credentials. An EC2 instance is suddenly making DNS calls to a known command and control server. A new IAM user was created at 3 AM from an IP that has never logged in before. These are signals that something is happening right now, or just happened, and you need to know about it. GuardDuty is the AWS service that produces most of these signals.

Compliance is the other side of the coin. It is about proving that you have the right controls in place to prevent bad things from happening in the first place. Is MFA enforced on the root account? Is CloudTrail logging to an S3 bucket that is not publicly readable? Are your RDS snapshots encrypted? Compliance is the boring, foundational hygiene that auditors care about and that engineers usually ignore until the week before an audit.

Most teams treat these as two separate problems handled by two separate tools, owned by two separate people who do not talk to each other. That's exactly why their security posture leaks. A misconfigured S3 bucket (compliance failure) gets exploited by a remote attacker (threat) because the team that runs Config never looks at the dashboard the team that runs GuardDuty stares at all day.

Security Hub treats these as two halves of the same job.

Where AWS Security Hub Fits

Strip away the marketing and Security Hub does four things that matter.

It aggregates. Findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Systems Manager Patch Manager, and Config rules all land in Security Hub automatically once you enable the integrations. You stop tab hopping.

It normalizes. Every finding from every source is converted into a single schema called the AWS Security Finding Format, or ASFF. A GuardDuty alert about a crypto mining EC2 instance and a Config rule failure about an unencrypted EBS volume look structurally identical to your downstream code. ASFF is what makes downstream automation possible at all. Without it, every script you write would need a different parser per source. With it, one Lambda function can react to anything.

It runs compliance checks. Security Hub continuously evaluates your AWS environment against industry standards. The big ones are AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark v3.0.0, PCI DSS, NIST SP 800-53, and NIST SP 800-171. Each standard is a set of automated controls. Each control runs on a schedule or on configuration change, and a failure becomes a finding in ASFF.

It ships every finding to EventBridge. Every new finding and every update to an existing finding becomes an EventBridge event in near real time. You write rules to match the ones you care about, point them at Lambda or Step Functions, and you have a closed loop from detection to fix.

The new Security Hub announced in preview at re:Inforce 2025 layers correlation on top of all of this. It can spot when a publicly exposed EC2 instance has a critical Inspector vulnerability and also has access to an S3 bucket that Macie flagged as containing sensitive data, and surface that as a single high priority exposure instead of three separate findings sitting in three different queues. The classic Security Hub features still work the same way underneath. You don't need to relearn anything.

That's the foundation. Now the use cases.

Use Case 1: One View Across Every Account in Your Organization

Picture a busy international airport without a control tower. Every pilot is on their own radio frequency talking to nobody in particular. One plane is on final approach, another is taxiing onto the same runway, a third is reporting an engine warning, and a fourth is requesting a gate change. Each pilot is competent. Each one knows their own aircraft well. But there is no single person watching all of them at once and ranking what needs attention first. The result is predictable, and it is why control towers exist.

That's most multi account AWS setups before Security Hub. Each account has its own GuardDuty, its own Config, its own Inspector. The security team gets findings only when somebody in that account remembers to forward a screenshot. The dev team in account 47 has been running an EC2 instance with a critical CVE for nine months, and the security team has no idea it exists. Every account is a pilot on their own frequency. Nobody is the tower.

The Security Hub delegated administrator is the control tower. One account becomes the single pane of glass for every other account in your AWS Organization, across every Region, with one console, one ranked feed of findings, and one place to write your automation.

Here is the setup at a high level. You have an AWS Organization with a management account and many member accounts. You pick one member account that is dedicated to security tooling (please, not the management account, AWS recommends keeping these separate and so does common sense, since the people who handle billing should not also have full security visibility) and you designate it as the Security Hub delegated administrator.

# Run this from the Organizations management account
aws securityhub enable-organization-admin-account \
    --admin-account-id 555555555555

Once that delegated admin is in place, switch to that account and turn on central configuration. This is the bit that scales. Without central configuration, you have to enable Security Hub Region by Region, account by account, and re enable it whenever a new account joins. Central configuration lets you write a configuration policy once and have it apply to every account and every Region automatically, including new accounts that join the org later.

# Run this from the delegated administrator account
aws securityhub update-organization-configuration \
    --auto-enable \
    --organization-configuration '{"ConfigurationType": "CENTRAL"}'

Then you set up cross Region aggregation so findings from every Region roll up to one home Region. Pick a home Region close to where your security team works, link the rest, and your console in the home Region now shows everything.

# Run this from the delegated administrator account in the home Region
aws securityhub create-finding-aggregator \
    --region-linking-mode ALL_REGIONS

Three commands. That is the core of it. There is more polish you can add (configuration policies for different OUs, IAM permissions for cross account read access, a separate aggregator for AWS Config since Security Hub recommends the same account act as the Config aggregator too), but those three commands give you a working multi account Security Hub setup that scales to 10,000 member accounts under one delegated admin per Region.

A practical note. The first time you turn this on across a real org with dozens of accounts, the findings list is going to be long. Much longer than you expect. This is not a sign of broken setup. The findings were always there, you just couldn't see them before. Resist the urge to hit "suppress all" out of frustration. Filter by severity, sort by account, and start working through CRITICAL and HIGH first. The MEDIUM and LOW noise can wait until you have your compliance baseline sorted out, which is exactly what use case 2 is about.

Use Case 2: Continuous Compliance Without the Audit Week Panic

Picture a restaurant kitchen. There are two ways to handle the food safety inspector. Option one, scramble the morning of the visit, scrub the floors, hide the questionable chicken, fake the temperature logs, and pray. Option two, run the dishwasher continuously, fill the temperature logs as you go, change gloves between stations, and have everything inspection ready every single day. The first one is how most teams handle compliance. The second one is what Security Hub gives you.

The pattern is familiar. Compliance team runs a quarterly audit. Audit returns 800 findings. Engineering panics for a month. Six hundred get fixed. Two hundred become "accepted risks" in a spreadsheet nobody opens again. Six months later, the same audit finds 850 findings, including the original 200 plus new ones. Nothing actually got better. The team just got better at running fire drills.

Security Hub breaks this loop by running compliance checks continuously, in the background, against industry standards you opt into. You enable a standard, AWS Config evaluates each control either on a schedule or whenever the underlying resource changes, and the result becomes an ASFF finding with a Compliance.Status of either PASSED, FAILED, or WARNING. Your compliance posture stops being a quarterly snapshot and becomes a live number that updates on its own.

Here is how to think about which standards to enable.

Start with FSBP. AWS Foundational Security Best Practices is written by AWS security engineers who have specific product knowledge. It covers over 30 services and is the broadest baseline you can pick. If you only enable one standard, this is the one.

Add CIS AWS Foundations Benchmark. This is what auditors and partners recognize. CIS v3.0.0 is the current version supported in Security Hub. There is significant overlap with FSBP, which is fine because Security Hub maps overlapping controls so fixing one resource often clears multiple control failures at once.

Add PCI DSS only if you actually process cardholder data. Enabling it for the optics is a bad idea because it adds noise to your dashboard without changing your real risk surface.

Add NIST 800-53 only if you work with US federal agencies or have contracts that require it. Same reason as above.

The trap engineers fall into is enabling all five standards on day one because more must be better. It is not. More standards means more findings, more dashboard noise, and more fatigue. Pick what you actually need.

# Enable AWS Foundational Security Best Practices
aws securityhub batch-enable-standards \
    --standards-subscription-requests '[{
        "StandardsArn": "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0"
    }]'

# Enable CIS AWS Foundations Benchmark v3.0.0
aws securityhub batch-enable-standards \
    --standards-subscription-requests '[{
        "StandardsArn": "arn:aws:securityhub:us-east-1::standards/cis-aws-foundations-benchmark/v/3.0.0"
    }]'

There is one prerequisite that catches almost everyone. AWS Config has to be enabled and recording resources for most Security Hub controls to evaluate. Security Hub uses service linked AWS Config rules under the hood. If Config is not recording, your security score will look broken and you will spend an afternoon wondering why. Turn Config on in every account and every Region where Security Hub runs. Use the same delegated administrator account for both, since AWS recommends keeping the Config aggregator and the Security Hub administrator in the same place.

Now the part that matters for automation. When a control fails, Security Hub generates an ASFF finding that looks like this (trimmed to the fields you actually care about):

{
    "SchemaVersion": "2018-10-08",
    "Id": "arn:aws:securityhub:us-east-1:111122223333:subscription/aws-foundational-security-best-practices/v/1.0.0/S3.8/finding/abc-123",
    "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/securityhub",
    "GeneratorId": "aws-foundational-security-best-practices/v/1.0.0/S3.8",
    "AwsAccountId": "111122223333",
    "Types": ["Software and Configuration Checks/Industry and Regulatory Standards/AWS-Foundational-Security-Best-Practices"],
    "Severity": {
        "Label": "HIGH",
        "Normalized": 70
    },
    "Title": "S3.8 S3 general purpose buckets should block public access",
    "Description": "This control checks whether an S3 general purpose bucket blocks public access at the bucket level.",
    "Resources": [{
        "Type": "AwsS3Bucket",
        "Id": "arn:aws:s3:::finance-data-2025",
        "Region": "us-east-1"
    }],
    "Compliance": {
        "Status": "FAILED",
        "SecurityControlId": "S3.8"
    },
    "Workflow": {
        "Status": "NEW"
    },
    "RecordState": "ACTIVE"
}

The fields that matter for everything downstream are SecurityControlId (which control failed), Severity.Label (how bad), Resources[].Id (what to fix), AwsAccountId (where), and Workflow.Status (whether anyone has touched it yet). Every control failure produces this same shape. Every GuardDuty finding produces a similar shape. Once you can read this JSON, you can write automation against any signal in your environment.

One more practical note. Do not chase a 100 percent compliance score. Some controls will not apply to your environment. If you do not run any Lambda functions, the Lambda controls will sit there as failures or no data forever. The right move is to disable those specific controls in your configuration policy rather than ignoring the findings, because ignored findings turn your dashboard into background noise and the next person who joins the team will tune it all out. Disable what does not apply, fix what does, and keep the dashboard honest.

Closing Thoughts

Security Hub on its own is a dashboard. The value comes from stacking three things on top of each other. One organization wide view, so nothing in any account or Region escapes your attention. Continuous compliance evidence, so your audit posture is a live number not a quarterly fire drill. And eventually, automation that closes the loop from finding to fix without waking anyone up at 2 AM. That third part is its own topic, and worth a post on its own, because the safety considerations around automated remediation deserve more space than a closing paragraph.

The new Security Hub announced in preview at re:Inforce 2025 makes the first two even better by correlating findings across GuardDuty, Inspector, Macie, and the CSPM controls. A publicly exposed EC2 instance with a critical Inspector vulnerability that also has access to an S3 bucket Macie flagged for sensitive data now shows up as one prioritized exposure instead of three separate findings in three different queues. Most real incidents are exactly this kind of multi signal pattern that human analysts struggle to correlate manually under pressure.

Practical advice if you are starting fresh. Do not try to do everything on day one. Set up the delegated administrator and central configuration in a non production org first, get used to the console, see what real findings look like in your environment. Enable FSBP only for two weeks and watch the noise level. Once you know which controls fail repeatedly in your specific setup, you have the input you need to design useful automation. Trying to automate before you understand your own baseline is how you end up with a Lambda function that disables production resources at 3 AM.

Security Hub rewards patience. Set the foundation right and the rest follows.