Guardduty Security

AWS GuardDuty Security

When to Use

• Enabling and configuring AWS GuardDuty for threat detection
• Understanding and triaging GuardDuty finding types
• Automating incident response to GuardDuty findings via EventBridge + Lambda
• Managing GuardDuty across multiple AWS accounts (Organization integration)
• Distinguishing GuardDuty from Inspector, Macie, and Security Hub
• Preparing for AWS Certified Security Specialty (SCS-C02) exam

Core Jobs

1. GuardDuty Data Sources

GuardDuty continuously analyzes these sources for threats:

GuardDuty does NOT require you to enable VPC Flow Logs or CloudTrail separately — it accesses these directly without storing logs in your account.

2. Finding Types

Format: ThreatPurpose:ResourceAffected/ThreatFamilyName.DetectionMechanism!Artifact

Finding severity:

• 🔴 High (7.0–8.9): Active threat, immediate action required
• 🟡 Medium (4.0–6.9): Suspicious activity, investigate
• 🟢 Low (1.0–3.9): Informational, monitor

3. Multi-Account Management

Administrator account = central visibility and control:

• Sees findings from ALL member accounts
• Can enable/disable GuardDuty for member accounts
• Member accounts CANNOT disable GuardDuty themselves
• Single GuardDuty administrator account across Organization

Setup via AWS Organizations (recommended):

1. Designate GuardDuty administrator account (Security/Audit account)
2. Auto-enable for all current + future member accounts
3. All findings flow to administrator account

Manual invitation method (non-Organizations):

• Administrator sends invitation to member account; member accepts

Suppression rules: Filter known-safe findings by account, region, resource type, or finding type. Suppressions apply to future findings. Suppressed findings still stored but not active.

4. Automated Incident Response

Pattern: GuardDuty finding → EventBridge rule → Lambda/SNS/SQS → automated action

GuardDuty finding
    ↓
EventBridge rule (filter by severity, finding type)
    ↓
SNS topic → email/Slack notification
Lambda function → automated remediation
    ↓
Actions: block IP via NACL, isolate SG, disable IAM key, snapshot EBS

EventBridge rule for high-severity findings:

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

Common automated responses:

• Crypto mining finding → block outbound traffic to mining pool IPs via NACL
• Compromised IAM key → disable access key via iam:UpdateAccessKey
• Malicious EC2 → isolate by replacing SG with deny-all forensic SG
• C2 communication → isolate EC2 to forensic VPC, take EBS snapshot for analysis

5. S3 Protection and Malware Protection

S3 Protection:

• Analyzes CloudTrail S3 data events for unusual access patterns
• Detects: unusual API callers, access from new geographic locations, high-volume data exfiltration
• Enable per-account (not enabled by default even when GuardDuty is enabled)

Malware Protection for EC2:

• Scans EBS volumes attached to EC2 when GuardDuty detects suspicious activity
• Creates EBS snapshot, attaches to GuardDuty-managed scanner instance
• Does not impact running instance performance

Malware Protection for S3:

• Scans objects uploaded to S3 (on new object uploads)
• Creates prefixed/tagged findings for malicious objects

6. Suppression vs Archiving

Key Concepts

• Threat intelligence feeds — GuardDuty uses AWS-curated threat intelligence (known bad IPs, domains, hashes) + custom lists
• Anomaly detection — ML-based baselines; alerts on deviations from normal behavior (new geographic access, unusual API patterns)
• Finding retention — findings retained for 90 days by default; archive to S3 via EventBridge for longer retention
• GuardDuty delegated administrator — in AWS Organizations, designate specific account to manage GuardDuty for all accounts
• Runtime Monitoring — installs lightweight security agent on EC2/ECS/EKS to detect runtime threats (file access, process execution, network activity)
• Cross-region — GuardDuty is regional; enable in every region where you have resources; aggregate via Security Hub

Checklist

• GuardDuty enabled in ALL AWS regions (threats don't respect regional boundaries)?
• Multi-account: GuardDuty administrator account designated in AWS Organizations?
• S3 Protection enabled (not on by default)?
• EKS Protection enabled for Kubernetes workloads?
• EventBridge rules configured to route high-severity findings to incident response?
• Suppression rules documented and reviewed (know what you're filtering out)?
• Custom threat IP list added for known external threat feeds?
• Trust IP list includes pen test IP ranges (to avoid false positives during authorized tests)?

Output Format

• 🔴 Critical — GuardDuty disabled in active regions; high-severity finding (CryptoCurrency, Backdoor, UnauthorizedAccess) with no response; member accounts able to disable GuardDuty (not using Organizations)
• 🟡 Warning — S3 Protection not enabled (S3 threats not detected); no automated response for medium/high findings; suppression rules too broad (hiding real threats)
• 🟢 Suggestion — Security Hub integration to aggregate GuardDuty + Inspector + Macie findings; Runtime Monitoring for deep container/EC2 threat visibility; Detective for investigation of GuardDuty findings

Exam Tips

• GuardDuty = threat detection (behavioral anomalies); Inspector = vulnerability scanning (CVEs, network exposure); Macie = PII/sensitive data discovery in S3 — different tools, different purposes
• GuardDuty does NOT block traffic; use Lambda + NACL/SG for automated blocking in response to findings
• Multi-account: administrator account sees all member account findings; members cannot disable GuardDuty (when enrolled via Organizations)
• CryptoCurrency finding = EC2 communicating with known cryptocurrency mining infrastructure (one of the most common exam questions)
• EventBridge integration = route findings to SIEM, ticketing system (Jira), Slack, or Lambda automation — this is the standard response pattern
• Suppression rules ≠ fixing the threat — only suppress after confirming finding is definitely not a real threat (e.g., authorized pen test activity)
• S3 Protection must be enabled separately — enabling GuardDuty does NOT automatically enable S3 data event analysis
• DNS logs: GuardDuty only analyzes DNS queries going through AWS DNS resolver (Route 53 Resolver); custom DNS servers on EC2 bypass this