GuardDuty — Org-wide threat detection

Status: Active since 2026-04-18, delegated admin: log-archive. Purpose: SOC 2 CC7.2 (anomalies), HIPAA §164.308(a)(1)(ii)(D), CMS EDE Phase 3 threat detection.

Summary

GuardDuty runs in every account in the org with auto-enrollment. Findings are centralized in the log-archive account (the delegated administrator). GuardDuty ingests VPC Flow Logs, DNS query logs, CloudTrail management events, and S3 data events to detect threat patterns.

Resources

Resource	Value
Delegated administrator	754660694122 (log-archive)
Admin detector (log-archive)	44396c0b61674ade87312ff13ab85996
Mgmt detector (self-managed)	9a71698300b24e55a21a53c4d8f660a9
Finding publishing frequency	Every 15 minutes
Auto-enroll	ALL (any new member account added to org is automatically protected)
Member accounts	039624954211 (prod), 549136075525 (staging) — both Enabled
Features enabled (auto on new accounts)	S3 data events, EBS malware protection, Runtime monitoring (ECS Fargate agent management)

Feature notes

• S3 data events (S3_DATA_EVENTS) — detects unauthorized reads/writes against S3 buckets. Relevant for askflorence-data and future ECS task state buckets.
• EBS malware protection (EBS_MALWARE_PROTECTION) — scans EBS volumes attached to EC2 for malware. Limited relevance in a Fargate-only stack but enabled as defense-in-depth.
• Runtime monitoring (RUNTIME_MONITORING with ECS_FARGATE_AGENT_MANAGEMENT) — real-time syscall-level monitoring of Fargate tasks. Once Phase 5 lands ECS, this provides runtime threat detection inside our containers.
• NOT enabled: EKS audit logs (we don't run EKS), RDS login events (we don't run RDS), Lambda Network Activity (we don't run Lambda), EC2 Agent Management (Fargate-only).

Feature enablement on existing detectors (retroactive, Phase 2.5)

The original Phase 2 org-config call set AutoEnable=NEW on the feature plans — which only auto-enrolls future member accounts, not existing ones. Phase 2.5 (2026-04-21) fixed this by pushing the three scoped features to all 4 existing detectors via update-member-detectors from the log-archive delegated admin, plus a direct update-detector on log-archive's own detector. Required enabling the malware-protection.guardduty.amazonaws.com trusted-access for Organizations first (that was the banner the console was showing).

All 4 detectors now have:

• S3_DATA_EVENTS = ENABLED
• EBS_MALWARE_PROTECTION = ENABLED
• RUNTIME_MONITORING = ENABLED with sub-feature ECS_FARGATE_AGENT_MANAGEMENT = ENABLED

Intentionally NOT enabled:

• EKS, RDS, Lambda sub-features — services we don't run.
• Cross-account EBS Malware Protection service-role grant (separate from the EBS_MALWARE_PROTECTION feature above) — skipped deliberately. Fargate tasks have no persistent EBS volumes to scan. Documented so a future auditor sees this as an intentional scope limit, not a gap.

Malware Protection for S3 (Phase 2.5)

Separate GuardDuty product, scoped specifically to the agent-uploaded PDF surface.

• Plan ID: d4ced6e0c14fe707c26d (mgmt account 778477254880)
• Status: ACTIVE
• Protected resource: S3 bucket askflorence-data, object prefix agent-survey-uploads/
• Action on detection: object tagging (GuardDutyMalwareScanStatus=THREATS_FOUND or NO_THREATS_FOUND). A future EventBridge rule (Phase 11) forwards THREATS_FOUND to alerting.
• Custom IAM role: GuardDutyMalwareProtectionS3Role in mgmt. Trust limited to malware-protection-plan.guardduty.amazonaws.com with aws:SourceAccount == 778477254880 condition. Scan permissions scoped to the agent-survey-uploads/ prefix only. Also has kms:GenerateDataKey/Decrypt/DescribeKey on alias/askflorence-data so SSE-KMS objects can be scanned.
• Smoke-tested 2026-04-21: blank PDF upload via /api/agents/discovery/upload → scan tag applied within ~60 seconds, value NO_THREATS_FOUND.

If malware is ever found, the object stays in S3 but the tag alerts ops (and eventually EventBridge). Manual deletion per the PHI section in ../runbooks/s3-agent-survey-uploads.md.

Where findings go

• GuardDuty console in log-archive account aggregates findings across the org.
• Security Hub (delegated admin also = log-archive) ingests GuardDuty findings automatically, so they appear in the SH console too.
• EventBridge (future): a rule that forwards critical findings to PagerDuty or Slack. Will be added in Phase 11.

SCP protection

ScpBaseline denies:

• guardduty:DeleteDetector
• guardduty:DeleteMembers
• guardduty:DisassociateFromMasterAccount
• guardduty:DisassociateMembers
• guardduty:StopMonitoringMembers

All member accounts are blocked from disabling GuardDuty or leaving the org detector.

Costs

Variable — GuardDuty bills on VPC Flow Log bytes, DNS queries, CloudTrail event volume, S3 data events. Pre-launch estimate: $4–8/mo. Scales with traffic.

Runbook

• aws guardduty list-findings --detector-id <id> — pull findings.
• aws guardduty get-organization-configuration --detector-id <id> — confirm auto-enroll.
• aws guardduty list-members --detector-id <id> — confirm member account status.
• Recommended weekly: review Security Hub summary page in log-archive for aggregated findings.