Automate AWS GuardDuty threat detection findings processing using EventBridge and Lambda to enable real-time incident response, automatic quarantine of compromised resources, and security notification workflows.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Automate AWS GuardDuty threat detection findings processing using EventBridge and Lambda to enable real-time incident response, automatic quarantine of compromised resources, and security notification workflows.
Amazon GuardDuty is a threat detection service that continuously monitors AWS accounts for malicious activity and unauthorized behavior. By integrating GuardDuty with Amazon EventBridge and AWS Lambda, security teams achieve automated, real-time responses to threats, reducing mean time to response (MTTR) from hours to seconds. GuardDuty analyzes VPC Flow Logs, CloudTrail management and data events, DNS logs, EKS audit logs, and S3 data events.
When to Use
When investigating security incidents that require detecting aws guardduty findings automation
When building detection rules or threat hunting queries for this domain
When SOC analysts need structured procedures for this analysis type
When validating security monitoring coverage for related attack techniques
Detection Gaps & Validation
EventBridge fires on the finding, but repeats update it: GuardDuty aggregates recurring activity into the same finding ID and re-publishes on the detector's findingPublishingFrequency (default FIFTEEN_MINUTES, up to 6h). Your Lambda may not re-trigger for ongoing attacks, and there's a delay before the first event. Lower the frequency for faster response and key idempotency on id + updatedAt.
A severity >= 7.0 filter drops Medium findings: recon and many Persistence/Policy findings sit at 4.0–6.9 and never reach the rule. Decide explicitly whether to handle the 4–7 band.
It's regional and per-account: you need a detector and an EventBridge rule + target in every region; org member-account findings only centralize to the admin account within the same region.
Data-source coverage gaps: if S3 Protection, EKS Audit Logs, Runtime Monitoring, or Malware Protection aren't enabled, the matching finding types are never produced — absence of findings isn't absence of threat.
Validate end-to-end: generate aws guardduty create-sample-findings --detector-id <id> --finding-types <type> and confirm the Lambda actually ran via its CloudWatch Logs / Invocations metric and that the SNS notification arrived. (Sample findings carry GeneratedFinding* IDs — the handler already guards accessKeyId == 'GeneratedFindingAccessKeyId' so test runs don't disable a real key.)
