Amazon SCS-C02: Threat Detection & Alerting — Study Guide
Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Centralizing GuardDuty Across an Organization
Amazon GuardDuty is a continuous threat detection service that analyzes CloudTrail management and data events, VPC Flow Logs, DNS query logs, EKS audit logs, RDS login activity, and runtime telemetry. It produces findings classified by threat purpose (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) and resource type (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).
Operating GuardDuty account-by-account does not scale. The correct architecture in an AWS Organizations environment is to designate a delegated administrator — typically the dedicated security or audit account — using the Organizations management account. From the delegated admin, you enable GuardDuty organization-wide and toggle auto-enable so new member accounts and new Regions are protected automatically as they are created. Without auto-enable, a newly vended account remains blind until an operator manually enables detection, which is exactly the gap attackers exploit during onboarding.
### Practical Problem: Use-Case Scenario
**Scenario:** Meridian Financial runs a multi-account AWS environment across 28 accounts for production, dev, and shared services. Their management account governs accounts through AWS Organizations, with centralized CloudTrail and S3 logging, but security alerts and investigation data are dispersed across member accounts making incident triage slow and inconsistent.
**Challenge:** A recent lateral movement detection in one account produced GuardDuty findings that were not visible to central SOC tools quickly enough, delaying containment and forensic investigation.
**Recommended Approach:**
1. Designate a delegated GuardDuty administrator in the management account and enable GuardDuty across the organization via AWS Organizations so all member accounts forward findings to a central detector.
2. Turn on centralized AWS Security Hub in the management account as the aggregator and enable Security Hub for all accounts and regions to normalize GuardDuty findings alongside other security standards.
3. Configure Amazon EventBridge rules in the management account to capture GuardDuty and Security Hub findings and route them to centralized targets such as Amazon SNS for paging, Amazon Kinesis Data Firehose to S3 for archival, or direct delivery to your SIEM.
4. Deploy Lambda responders triggered by EventBridge for automated containment actions (for example, isolate an EC2 instance via EC2 API and create an AWS Systems Manager incident) and tag findings for investigation.
5. Integrate Amazon Detective for centralized investigation and forward archived findings in S3 to your analytics/SIEM for long-term correlation and reporting.
**Rationale:** Using a delegated GuardDuty admin with Security Hub and EventBridge centralizes detection, normalizes alerts, and enables automated, auditable responses per AWS best practices for organization-wide threat detection and timely incident response.
## From the Organizations management account
aws organizations enable-aws-service-access \
--service-principal guardduty.amazonaws.com
aws guardduty enable-organization-admin-account \
--admin-account-id 111122223333
## From the delegated admin
aws guardduty update-organization-configuration \
--detector-id abc123 \
--auto-enable-organization-members ALL \
--features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
{"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
{"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'
GuardDuty is Regional, so the delegated administrator relationship and auto-enable settings must be established in every Region you operate in. This is a frequent source of blind spots — a team enables GuardDuty in us-east-1 and assumes global coverage.
Service-Specific Protections
Base GuardDuty covers foundational data sources, but several protection plans must be explicitly enabled because they add cost and additional telemetry ingestion:
RDS Protection: profiles login activity to Aurora MySQL/PostgreSQL and RDS engines, generating findings such as
CredentialAccess:RDS/AnomalousBehavior.SuccessfulLoginwhen unknown users authenticate to a DB endpoint. This is the correct source for detecting suspicious database logins — do not build custom CloudWatch metric filters on DB audit logs when RDS Protection already emits the finding natively.EKS Protection: ingests Kubernetes audit logs to detect anomalous API access, privileged pod creation, and use of exposed dashboards.
Runtime Monitoring: deploys a lightweight eBPF-based agent on EC2, ECS/Fargate, or EKS to surface process, file, and network events — required for detecting fileless malware or reverse shells at runtime.
Malware Protection: snapshot-scans EBS volumes attached to instances flagged by other findings, or on-demand scans of S3 objects on upload.
Lambda Protection and S3 Protection: cover function invocation patterns and data-plane S3 access respectively.
Enabling only the base service and expecting DB login anomalies to appear is a common misconfiguration — the finding types simply are not produced until the corresponding feature is toggled on.
Security Hub as the Aggregation Plane
Security Hub ingests findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health, and third-party ISV products, normalizing them into the AWS Security Finding Format (ASFF). It also runs its own compliance standards (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).
To centralize across an Organization:
Enable Security Hub as a service in Organizations and designate a delegated administrator (usually the same security account as GuardDuty).
Turn on auto-enable new accounts so members are enrolled automatically.
Configure a finding aggregation Region (also called the home Region) and link all other Regions to it. Without cross-Region aggregation, each Region maintains an independent Security Hub instance and analysts must pivot between consoles.
The pattern for a global organizational rollout therefore requires two coordinated settings: the aggregation Region link, and the org-wide auto-enable toggle. Enabling one without the other leaves either new accounts uncovered or new Regions siloed.
An important limitation: Security Hub aggregates and prioritizes but does not remediate. Treating it as a remediation platform is a category error — the remediation happens through EventBridge downstream.
EventBridge as the Automation Fabric
Both GuardDuty and Security Hub publish findings to the default event bus. aws.guardduty emits GuardDuty Finding events, and aws.securityhub emits Security Hub Findings - Imported (created/updated by Hub) and Security Hub Findings - Custom Action (operator-triggered).
Overly broad rules such as {"source": ["aws.securityhub"]} invoke targets on every finding update from every provider, quickly flooding SNS topics and paging on-call engineers with informational noise. The correct approach is to filter on severity.Label, ProductArn, Types, or specific Title values:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Finding"],
"detail": {
"severity": [{ "numeric": [">=", 7] }],
"type": [{ "prefix": "CredentialAccess:RDS/" }]
}
}
For a Security Hub-centric pattern that only fires on high-severity GuardDuty findings while ignoring noisy third-party ISV products:
{
"source": ["aws.securityhub"],
"detail-type": ["Security Hub Findings - Imported"],
"detail": {
"findings": {
"Severity": { "Label": ["HIGH", "CRITICAL"] },
"ProductArn": [
{ "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
],
"Workflow": { "Status": ["NEW"] }
}
}
}
Common targets include an SNS topic for email/SMS/Slack notification, a Lambda function that isolates an instance by swapping its security group, an SSM Automation runbook, or a Step Functions state machine orchestrating multi-step response. For the Aurora login-anomaly use case, the minimum-effort path is GuardDuty RDS Protection → EventBridge rule filtered on the RDS finding type → SNS topic with email subscription. No custom polling, no Lambda, no third-party SIEM required.
Security Hub Custom Actions
Custom actions are operator-driven triggers. In the Security Hub console, an analyst selects one or more findings and chooses a custom action (for example, “Quarantine EC2”). Security Hub emits a Security Hub Findings - Custom Action event carrying the selected finding ARNs; an EventBridge rule matches on the custom action’s ARN and invokes a Lambda that performs the response. This gives you a human-in-the-loop button without building a bespoke UI:
aws securityhub create-action-target \
--name "Quarantine EC2" \
--description "Attach isolation SG and snapshot volumes" \
--id QuarantineEC2
The resulting ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) becomes the match value in the EventBridge rule’s resources field.
Suppression and Signal Management
Noise management is a discipline, not a one-time filter. Use Security Hub automation rules or GuardDuty suppression rules to auto-archive findings that are known-benign (a penetration testing tool’s expected Recon:EC2/Portscan finding, for example). Filter EventBridge rules by ProductArn to silence a chatty third-party integration without disabling it entirely. Combine Severity.Label with Workflow.Status = NEW so that reopened or already-notified findings do not re-page. The goal is that every alert reaching a human represents an actionable, high-confidence event — anything else erodes response readiness.
Investigation Pivot
When a high-severity finding fires — for example, Backdoor:EC2/C&CActivity.B!DNS — the fastest investigative path is not to hand-write Athena queries against CloudTrail and Flow Logs. Amazon Detective, when enabled alongside GuardDuty, pre-builds entity graphs from CloudTrail, VPC Flow Logs, and GuardDuty findings. Pivoting from the finding directly to the IAM role or EC2 instance profile in Detective surfaces API activity, network peers, and successful-versus-failed connection counts over the relevant window without any custom query work.
← Identity · All domains · Logging →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →