GuardDuty and Security Hub, Explained

Introduction¶

Two AWS security services people conflate:

• GuardDuty — a threat detection service. It continuously analyses CloudTrail, VPC Flow Logs, DNS query logs, EKS audit logs, S3 data events, RDS login activity, and more, using threat intel + ML, and produces findings ("this instance is talking to a known C2 server", "credentials used from an unusual location").
• Security Hub — an aggregator and posture manager. It collects findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Config, and partners into one place, deduplicates them, and runs security standards checks (CIS AWS Foundations, AWS Foundational Security Best Practices, PCI, NIST).

Turn on GuardDuty for detection; turn on Security Hub to see everything together and measure posture.

GuardDuty¶

• No agents, no config of log sources — it reads the telemetry directly. Enable per region (do all regions you use, plus ones you don't, to catch abuse there).
• Finding types: Recon:*, UnauthorizedAccess:*, CryptoCurrency:* (mining), Trojan:*, Backdoor:*, Impact:*, Exfiltration:*, Persistence:*, PrivilegeEscalation:*, Discovery:*, plus EKS, S3, RDS, Lambda, and Malware Protection categories.
• Severity 1–8 (Low < 4, Medium 4–6.9, High 7–8).
• Malware Protection — scans EBS volumes (from a snapshot) of a suspicious instance, or S3 objects on upload, for malware.
• Add-on protections cost extra and are worth it selectively: EKS runtime monitoring, RDS, Lambda, S3.

Common real findings: an EC2 instance mining crypto (compromised via an exposed service), IAM credentials from a Tor exit node, an instance querying a DGA-pattern domain, S3 bucket accessed from an unusual location.

Security Hub¶

• Standards — enable AWS FSBP + CIS; each is a set of automated controls (checked via Config rules) with pass/fail and a remediation link. You get a security score per account/standard.
• Findings in the ASFF (AWS Security Finding Format) — normalised so GuardDuty, Inspector, and partner tools all look the same.
• Insights — saved queries ("resources with the most failed controls").
• Automation rules — auto-suppress known-accepted findings, change severity, or set workflow status.

Organisation-wide setup¶

1. Designate a delegated administrator account (your security/audit account) for both services in AWS Organizations.
2. Auto-enable for all existing and new member accounts.
3. All findings aggregate to the delegated admin's Security Hub in an aggregation region.
4. Members can't disable it (org policy).

Routing findings to action¶

Findings are noise until they trigger something:

GuardDuty / Security Hub finding
   -> EventBridge rule (filter by severity / type)
       -> SNS (page on-call for High) 
       -> Lambda / SSM Automation (auto-remediate: isolate an instance's SG,
          revoke a session, quarantine a key)
       -> Jira/ticket for Medium
       -> Slack for visibility

Example EventBridge pattern for high-severity GuardDuty:

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

Auto-remediation to be careful with: isolating a production instance's security group stops an attack but also stops the service. Scope auto-actions to non-prod, or to "contain but alert a human", by default.

Verification and troubleshooting¶

aws guardduty list-detectors
aws guardduty get-findings --detector-id <id> --finding-ids <id>
aws securityhub get-findings --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}'
aws securityhub describe-standards-controls --standards-subscription-arn ...

• GuardDuty enabled but no findings ever — that can be good (nothing detected), but verify with a sample finding: aws guardduty create-sample-findings. If samples don't appear, the detector is disabled or you're looking in the wrong region.
• Findings for a region you don't use — that's the point; someone spun up resources there (abuse, or a rogue deploy). Investigate; consider an SCP restricting regions.
• Security Hub score low on day one — expected; the CIS/FSBP controls flag every non-compliant resource. Triage by severity, suppress accepted risks with an automation rule (with a documented reason), remediate the rest.
• Duplicate findings — GuardDuty updates an existing finding for recurring activity (same finding ID, incremented count) — don't treat each update as new. Security Hub dedupes across sources.
• EventBridge rule not firing — findings go to the detector's region; your rule must be in that region (or use the Security Hub aggregation region). Test the event pattern.
• Cost higher than expected — GuardDuty bills on volume of analysed events (CloudTrail, flow logs, DNS) + the add-on protections; a chatty account or S3 data events can add up. Review the usage breakdown; disable add-ons you don't need.
• Can't disable a member account's GuardDuty — org auto-enable + the delegated admin owns it by design.

Related tools and reading¶

• On-site: JSON formatter.
• Related posts: AWS IAM policy evaluation logic, EC2 instance metadata and IMDSv2.