GuardDuty and Security Hub: what to actually act on

The week after we enabled GuardDuty and Security Hub across the organization, my inbox had 1,400 findings. By the time I triaged the first fifty, none had turned out to be a real incident. That is the trap with these tools: they generate signal volume that looks like work but mostly is not. The skill is not turning them on, it is knowing what to actually act on.

This is the filter I built after living with both for a year, written for the engineer who got handed "the security findings" and does not have a SOC.

What each tool is for

They are easy to conflate, but the division is clean:

• GuardDuty is a detector. It watches VPC flow logs, DNS queries, CloudTrail, and EKS audit logs, and emits findings about suspicious behavior, crypto mining, credential exfiltration, reconnaissance.
• Security Hub is an aggregator and scorer. It ingests GuardDuty findings plus config-based checks (CIS, AWS Foundational Security Best Practices) and gives you a posture score.

GuardDuty tells you "something is happening right now." Security Hub tells you "your account is configured unsafely." You act on them differently.

The GuardDuty findings I always act on

GuardDuty severity is a 0 to 10 float, bucketed into Low, Medium, and High. Severity alone is a weak filter; finding type matters more. These are the types I treat as page-worthy regardless of stated severity:

Triage by finding type first, severity second. A High-severity port-scan finding against a host with no open ports is noise; a Medium credential-exfiltration finding is an incident.

Automating the response, not the reading

Reading findings by hand does not scale. I route them through EventBridge so the ones that matter page someone and the rest file themselves. This rule forwards only high-severity GuardDuty findings to an SNS topic:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [ { "numeric": [">=", 7] } ],
    "type": [ { "prefix": "UnauthorizedAccess:" },
              { "prefix": "Backdoor:" } ]
  }
}

# Wire the rule to an SNS topic that pages on-call
aws events put-targets --rule guardduty-high-sev \
  --targets "Id"="1","Arn"="arn:aws:sns:us-east-1:123456789012:secops-page"

Everything below that bar lands in Security Hub for weekly review rather than interrupting anyone.

Security Hub: fix classes, not findings

Security Hub's config checks (public S3 buckets, unencrypted volumes, root account without MFA) are different. They are not incidents; they are debt. The mistake is closing them one by one. Instead, group by control and fix the root cause:

• 50 "S3 bucket allows public read" findings usually trace to one missing account-level BlockPublicAccess setting. Fix that, 50 findings clear at once.
• "Security group allows 0.0.0.0/0 on port 22" across many accounts is a Terraform module problem, not 30 individual edits.

I suppress the findings that are genuinely accepted risk (a deliberately public static-site bucket) with a suppression rule so they stop dragging the posture score, rather than leaving them open and learning to ignore the dashboard.

The one metric I actually track

Not the finding count, which is meaningless. I track time-to-acknowledge on the high-severity GuardDuty page. If a credential-exfiltration finding sat for six hours, that is the failure, not the 1,400 config findings I will never read.

Takeaways

• GuardDuty detects active threats; Security Hub scores configuration posture. Act on them differently.
• Triage GuardDuty by finding type first, severity second, and page only on exfiltration, C2, and mining types.
• Route high-severity findings through EventBridge to a pager; let everything else aggregate for weekly review.
• Fix Security Hub findings by root-cause control, not one at a time, and suppress genuine accepted risk so the score stays meaningful.