Threat Detection and Unified Security Operations with GuardDuty, Security Hub, and Detective
_Category: Threat Detection_
In the SCS-C03 exam, the heart of the Threat Detection domain is knowing how these three services work together. Think of GuardDuty as a 24/7 automated intrusion alarm, Security Hub as the unified security operations dashboard, and Detective as the forensic investigator who reviews camera footage and access logs. Each has a distinct job, and the exam tests exactly those distinctions.
---
The Threat Detection Pipeline: Collect → Detect → Prioritize → Investigate → Respond
Thinking of threat detection as a five-stage pipeline makes the role of each service immediately clear.
Stage one is data collection. CloudTrail management events, VPC Flow Logs, DNS query logs, S3 API call records, EKS Audit Logs, and Lambda network traffic all serve as raw inputs. GuardDuty consumes this data — you do not need to ship logs to a separate bucket or install any agent. Enabling GuardDuty is enough to start detection.
Stage two is detection. GuardDuty applies machine learning and curated threat intelligence to identify anomalous behavior and generate Findings.
Stage three is prioritization. GuardDuty Findings are classified by severity (Low, Medium, High) and forwarded to Security Hub. Security Hub normalizes Findings from GuardDuty, Macie, Inspector, Firewall Manager, IAM Access Analyzer, and third-party tools into ASFF (Amazon Security Finding Format), then aggregates them in one place.
Stage four is investigation. From a Security Hub Finding, you can pivot directly into Amazon Detective for deep-dive analysis. Detective uses a graph database to visualize relationships between entities — letting you trace exactly when a suspicious IP first touched your account and what it did.
Stage five is response. GuardDuty Findings are automatically published to EventBridge, which can trigger Lambda, SNS, Step Functions, and more. Security Hub Automation Rules let you automatically modify Finding attributes or kick off a response workflow whenever a Finding matches a defined pattern.
---
Amazon GuardDuty: How Automated Threat Detection Works and What Data It Consumes
GuardDuty is a managed threat detection service that continuously monitors your AWS environment for malicious or anomalous activity. You activate it, and detection starts immediately — no agents, no log-shipping pipelines required.
GuardDuty organizes its coverage into discrete feature categories:
| Data Source / Feature | What It Detects | Enabled by Default? | |---|---|---| | CloudTrail Management Events | Abnormal IAM credential use, unusual console sign-ins | Included by default | | VPC Flow Logs | Port scans, abnormal outbound connections, C2 communication | Included by default | | DNS Logs | DNS tunneling, queries to known malicious domains | Included by default (via Route 53 Resolver) | | S3 Protection | Anomalous S3 access, bulk deletions or downloads | Requires separate enablement | | EKS Audit Logs | Abnormal privilege use in containers, unusual kubectl patterns | Requires separate enablement | | Malware Protection | EC2/ECS malware scanning via EBS volume analysis | Requires separate enablement | | RDS Login Events | Anomalous login patterns to Aurora databases | Requires separate enablement | | Lambda Network Activity | Unusual outbound network calls from Lambda functions | Requires separate enablement |
An important nuance for DNS detection: GuardDuty only analyzes queries that flow through the Route 53 Resolver within your VPC. If an EC2 instance points to a custom DNS server — an external resolver or an on-premises forwarder — those queries are invisible to GuardDuty. Enabling Route 53 Resolver Query Logging separately does not share that data with GuardDuty.
In multi-account environments, you can integrate with AWS Organizations and designate a Delegated Administrator account to centrally manage GuardDuty across the entire organization.
---
GuardDuty Finding Categories and the Scenarios That Appear on the Exam
GuardDuty Findings follow a prefix taxonomy that signals the nature of the detected threat.
Reconnaissance covers attacker enumeration behavior — Recon:EC2/PortProbeUnprotectedPort is a classic example. UnauthorizedAccess flags abnormal credential use, including successful console sign-ins from unusual geolocations (UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B). CryptoCurrency identifies crypto-mining activity (CryptoCurrency:EC2/BitcoinTool.B). Backdoor catches C2 communication (Backdoor:EC2/C&CActivity.B). Behavior signals anomalous IAM credential usage patterns, and Pentest fires when recognized penetration testing tools are detected.
False positive suppression is a frequent exam topic. The Trusted IP List suppresses all Findings for traffic originating from specified IPs. A Suppression Rule lets you archive Findings selectively — combining criteria such as Finding type, source IP, and resource tags — so only the specific pattern you've approved gets silenced. Archived Findings disappear from the console view but are retained for 90 days.
If InstanceCredentialExfiltration Findings keep firing because legitimate traffic from an on-premises NAT gateway matches the detection rule, the correct answer is a Suppression Rule, not a Trusted IP List. Using a Trusted IP List would suppress all Findings from that IP, including real threats.
---
AWS Security Hub: Aggregating Findings and Applying Security Standards
Security Hub is the service that pulls Findings from multiple AWS security services and third-party tools into a single pane of glass and continuously evaluates your compliance posture against Security Standards.
ASFF (Amazon Security Finding Format) is the normalized JSON schema that gives every Finding — regardless of whether it came from GuardDuty, Macie, or Inspector — a common structure, enabling unified search and filtering across sources.
| Security Standard | Focus | Primary Use Case | |---|---|---| | AWS Foundational Security Best Practices (FSBP) | AWS service-level security best practices | General AWS security baseline | | CIS AWS Foundations Benchmark | CIS (Center for Internet Security) recommendations | Industry-standard hardening | | PCI DSS | Payment Card Industry security standard | Cardholder data environments | | NIST SP 800-53 | U.S. federal information system security controls | Government and regulated industries |
Insights group Findings that share a common pattern into aggregated views. Automation Rules trigger automatically when an incoming Finding matches a configured condition — modifying Finding attributes or routing the Finding to a response workflow without human intervention. When you designate a Delegated Administrator through AWS Organizations, Security Hub is automatically enabled in all new member accounts, and their Findings flow into the central administrator account.
---
Amazon Detective: Graph-Based Deep-Dive Investigation
When you receive a Finding from GuardDuty or Security Hub, you need to answer two questions: How serious is this, really? And are there other related anomalies? Detective is the tool built for exactly that.
Think of it like a detective reviewing surveillance footage and building timelines from access logs. Detective uses a graph database to visualize relationships between entities and surfaces behavioral patterns that would be invisible in raw log data.
Detective ingests CloudTrail logs, VPC Flow Logs, and GuardDuty Findings. From GuardDuty or Security Hub, clicking the Investigate in Detective button takes you directly into the Detective console. There, Detective presents a timeline of IPs, accounts, and API calls associated with the Finding, and compares current activity to a learned behavioral baseline to show you how anomalous the behavior actually is.
Detective requires GuardDuty to be enabled — it is a prerequisite. Because Detective is a manual investigation tool, it is not suited to EventBridge automation or real-time alerting. The rule of thumb: use Security Hub when you want to aggregate and correlate Findings across services; use Detective when you need to investigate a specific Finding in depth.
---
Side-by-Side Comparison of All Three Services and EventBridge Automation
Here is a quick reference for how the three services compare across key dimensions.
| Attribute | GuardDuty | Security Hub | Detective | |---|---|---|---| | Core role | Automated threat detection | Findings aggregation and compliance evaluation | Deep-dive investigation and root cause analysis | | Analogy | 24/7 intrusion alarm system | Security operations dashboard | Forensic investigator with CCTV footage | | Inputs | CloudTrail, VPC Flow Logs, DNS, S3, EKS, and more | GuardDuty, Macie, Inspector, third-party sources | GuardDuty Findings, CloudTrail, VPC Flow Logs | | Outputs | Findings (detection results) | Aggregated Findings, compliance scores | Graph visualizations, timeline analysis | | Automation | Publishes events to EventBridge | Automation Rules, EventBridge integration | Manual investigation (no automation support) | | GuardDuty dependency | Independent | Independent (usable without GuardDuty) | Requires GuardDuty to be enabled |
!GuardDuty versus Security Hub versus Detective
EventBridge-powered automatic response architectures are extremely common on SCS-C03. Every time GuardDuty generates a Finding, it automatically publishes an event to EventBridge. An EventBridge rule can filter for severity values of 4 or higher to target Medium and above. From there, you can send an SNS notification via email, or trigger a Lambda function that automatically isolates the compromised EC2 instance.
Security Hub also publishes EventBridge events whenever Findings are created or updated, meaning the same automated response pipeline applies equally to Findings from Macie or Inspector. In the Macie + GuardDuty