AWS GuardDuty Finding Triage: Suppression Rules, EventBridge Automation, and Severity-Based Incident Response
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Enabled GuardDuty across an 8-account AWS organization on a Friday afternoon. By Monday morning, the security team had 4,700 new findings across the accounts — the majority of them Recon:EC2/Portscan findings from the organization's own Nessus vulnerability scanner, UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B findings for a developer who was traveling internationally, and various Behavior findings from a CI/CD role that deploys infrastructure across multiple regions in patterns GuardDuty flagged as unusual. Legitimate threats existed in the finding list, but they were buried in the false positive volume.
The finding count dropped to 23 per day after building seven suppression rules targeting the specific known-good activity patterns. The 23 remaining daily findings were reviewed as a team and two represented actual issues — a forgotten EC2 instance making outbound connections to a Tor exit node and an IAM access key making API calls from a country where the organization had no operations. Both would have been invisible in the pre-suppression noise. GuardDuty's value is entirely dependent on suppression configuration quality.
Suppression strategy: categorizing false positives by source
Effective GuardDuty suppression starts by categorizing the sources of false positives rather than suppressing finding types broadly. Suppressing all Recon findings removes the vulnerability scanner noise but also removes findings from external attackers performing reconnaissance. Suppressing only Recon findings that match the vulnerability scanner's IP range preserves the threat detection for external recon while eliminating the known-good source.
Add internal infrastructure IPs to GuardDuty trusted IP lists before enabling detection to prevent day-one false positive flood
Build the trusted IP list before enabling GuardDuty in new accounts to prevent the initial false positive flood that causes teams to dismiss the service before seeing real value. Gather IP addresses for: all registered vulnerability scanner IPs used for internal scanning, all NAT gateway Elastic IP addresses used for outbound connections from private subnets (these appear as source IPs in network-based findings), all VPN endpoint IPs used for developer remote access, and any approved penetration testing firm IP ranges from current SOW agreements. Upload these IPs to an S3 bucket and configure the GuardDuty trusted IP list before enabling the service. The first 24 hours of GuardDuty activity after enabling with a pre-built trusted IP list shows substantially higher signal-to-noise than enabling without one, because the most common known-good activity sources are already exempted. Add a quarterly review process for the trusted IP list to remove IPs that no longer apply (decommissioned scanners, expired VPN endpoints) and add new infrastructure IPs.
Create tag-based suppression rules that automatically apply to resources marked as scan targets or development environments
Create suppression rules that use resource tags as matching criteria to automatically suppress findings from resources that are intentionally subject to security testing or that operate in environments where GuardDuty's threat models do not apply. Tag EC2 instances used as penetration test targets with security-test-target: true and create a suppression rule matching resource.instanceDetails.tags.key = security-test-target and resource.instanceDetails.tags.value = true — all GuardDuty findings for tagged instances are automatically archived during test windows. Similarly, tag development environment resources with environment: development and create suppression rules that archive Low and Medium severity findings from development environment resources while preserving High and Critical finding visibility. Tag-based suppression is more maintainable than IP-based suppression because it follows the resource through IP changes, auto-scaling events, and instance replacement — the tag moves with the AMI or Launch Template rather than requiring suppression rule updates when IPs change.
EventBridge automation: building a finding response pipeline
GuardDuty without EventBridge-based routing is a finding database with a console interface — useful for investigation but not for incident response velocity. EventBridge converts GuardDuty into a real-time event source that triggers investigation workflows, automated containment actions, and escalation processes based on finding type and severity without requiring security team members to actively poll the GuardDuty console.
Build a findings enrichment Lambda that adds asset context before routing to SIEM
Build a Lambda function that intercepts all GuardDuty findings before routing to the SIEM or alerting system, adds asset context from the CMDB or AWS resource tags, and produces an enriched finding record with the resource owner, business criticality, environment (production vs. development), and last known vulnerability scan status. The Lambda receives the GuardDuty finding JSON from EventBridge, extracts the affected resource identifier (instance ID, IAM user, S3 bucket ARN), calls the appropriate AWS API to get resource tags (ec2:describe-instances, iam:list-user-tags, s3:get-bucket-tagging), looks up the resource owner tag and environment tag, then adds these fields to the finding JSON before forwarding to the SIEM via the SIEM's API or to an SNS topic. An enriched finding that includes resource owner (alice@company.com), environment (production), and criticality (tier-1-payment-system) enables the security team to route the incident to the correct team immediately without spending investigation time identifying the resource owner from the instance ID alone.
Implement finding deduplication to prevent PagerDuty storms when GuardDuty refreshes high-frequency findings
Implement finding deduplication in the EventBridge-to-PagerDuty routing Lambda to prevent the same finding from creating multiple PagerDuty incidents. GuardDuty refreshes active findings every 6 hours with updated occurrence counts — each refresh generates a new EventBridge event with the same finding ID but an incremented count. Without deduplication, a finding that persists for 24 hours generates four PagerDuty incidents. Use the GuardDuty finding ID as the PagerDuty incident dedup key: when creating a PagerDuty incident via the PagerDuty Events API v2, set the dedup_key field to the GuardDuty finding ID. PagerDuty treats subsequent events with the same dedup key as updates to the existing incident rather than new incidents. Implement a secondary deduplication layer using an ElastiCache Redis key with a 24-hour TTL keyed on the finding ID — if the key exists, skip PagerDuty notification for refresh events; if the key does not exist, create the PagerDuty incident and set the Redis key. This prevents PagerDuty storms even when the dedup key logic has edge cases.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
AWS GuardDuty provides continuous threat detection across AWS accounts but requires active tuning to deliver actionable signal rather than false positive noise. Build the trusted IP list before enabling GuardDuty in new accounts to prevent the initial noise flood. Create suppression rules for known-good activity patterns targeting specific finding types combined with resource attributes — not broad finding type suppression that removes legitimate threat coverage. Route findings through EventBridge with severity-based logic: High and Critical to PagerDuty with automated Lambda containment for high-confidence finding types, Medium to Slack for team review, Low to S3 for archival. Implement finding enrichment Lambda that adds resource owner and environment context before routing to SIEM. Deploy GuardDuty across all AWS Organizations accounts with a delegated security account administrator for centralized finding management. Enable GuardDuty EKS Protection and Runtime Monitoring for container workloads where API audit log and host-level detection provides coverage that network-only detection misses.
Frequently asked questions
How do I configure GuardDuty suppression rules to reduce false positives?
Configure GuardDuty suppression rules by navigating to GuardDuty > Findings > Suppression rules > Create suppression rule and building filter criteria that target specific finding types combined with resource attributes of known-good sources. The most common suppression rules for reducing immediate false positive volume: First, suppress Recon:EC2/Portscan findings from your vulnerability scanner's IP range by setting finding type = Recon:EC2/Portscan and resource.instanceDetails.networkInterfaces.privateIpAddresses.privateIpAddress matching your Nessus scanner's IP. Second, suppress UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B findings for IAM users who legitimately log in from multiple geographic locations (traveling employees) by setting finding type = UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B and resource.accessKeyDetails.userName matching the specific user name. Third, suppress Policy:S3/BucketBlockPublicAccessDisabled findings for S3 buckets that are intentionally public (static website hosting, public asset CDN) by setting resource tags with a tag like public-access-intended: true and adding that tag condition to the suppression rule. Document each suppression rule with the reason for suppression and the last review date — suppression rules that suppress legitimate threats require periodic review to verify they still apply.
How do I route GuardDuty findings to Slack and PagerDuty using EventBridge?
Route GuardDuty findings to Slack and PagerDuty using EventBridge rules that match GuardDuty finding events and invoke Lambda functions for formatting and delivery. Create an EventBridge rule with source: aws.guardduty and detail-type: GuardDuty Finding as the event pattern to match all GuardDuty findings. Add a detail.severity condition to create separate rules for different severity tiers: High and Critical findings (severity >= 7) route to a Lambda function that posts to a #security-alerts Slack channel with @here mention and creates a PagerDuty incident; Medium findings (4-6.9) route to a Lambda that posts to #security-findings without mention; Low findings route to S3 for archival with no notification. The Lambda function receives the full GuardDuty finding JSON and formats a Slack message including the finding type, severity, affected resource (EC2 instance ID, IAM user, S3 bucket), region, and AWS console deep link. Use the GuardDuty finding's id field as the PagerDuty incident dedup key so that repeated findings for the same activity create only one PagerDuty incident rather than a new alert each time GuardDuty refreshes the finding. Test the EventBridge routing using GuardDuty's Generate sample findings feature which creates representative findings of each type at full severity.
How do I implement automated Lambda remediation for compromised IAM credential findings?
Implement automated Lambda remediation for the UnauthorizedAccess:IAMUser/MaliciousIPCaller finding type by deploying a Lambda function that disables the access key in the finding and attaches a deny-all inline policy to the IAM user when GuardDuty fires this finding type. Create an EventBridge rule targeting finding type UnauthorizedAccess:IAMUser/MaliciousIPCaller with a Lambda target. The Lambda function receives the GuardDuty finding JSON, extracts detail.resource.accessKeyDetails.accessKeyId and detail.resource.accessKeyDetails.userName, then calls aws.iam.updateAccessKey(accessKeyId, status=Inactive) to disable the key and aws.iam.putUserPolicy with a deny-all policy (Effect: Deny, Action: *, Resource: *) as a belt-and-suspenders measure that blocks the user even if they have other active access keys. Send a notification to the security team with the user name, access key ID, the GuardDuty finding details, and the automated actions taken. Include a recovery runbook link in the notification explaining how to re-enable the access key after investigation confirms it was a false positive. For EC2 finding types (Backdoor:EC2/C&CActivity.B, Trojan:EC2/DropPoint), automated remediation can modify the instance's security group to isolate it from the network while preserving the instance for forensic analysis.
How do I set up GuardDuty across multiple AWS accounts using AWS Organizations?
Set up GuardDuty across AWS Organizations by designating a security account as the GuardDuty delegated administrator and enrolling all member accounts for centralized finding management. In the AWS Organizations management account, navigate to GuardDuty > Settings > Delegated administrator and specify the security account ID as the delegated administrator. In the security account, navigate to GuardDuty > Accounts and enable auto-enable for all current and future member accounts — this automatically enables GuardDuty in any new account added to the organization without requiring per-account setup. All member account findings aggregate to the security account's GuardDuty console, where suppression rules created in the security account apply to findings from all member accounts. Create a separate EventBridge rule in the security account that includes account ID in the finding routing logic to tag findings with the source account for incident response context. Use GuardDuty finding export to S3 from the security account to send all cross-account findings to a centralized security data lake for SIEM integration — the export delivers findings in JSONL format to an S3 bucket with 6-hour and 1-hour frequency options.
How do I handle the GuardDuty finding InstanceCredentialExfiltration.OutsideAWS?
Handle the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding — which indicates that EC2 instance metadata credentials were used from an IP address outside AWS — as a critical incident requiring immediate investigation for potential SSRF exploitation. This finding fires when an EC2 instance's IAM role credentials (obtained via the EC2 metadata service at 169.254.169.254) are used to call AWS APIs from an external IP address, which should be impossible unless the credentials were stolen. Immediately check if the EC2 instance metadata service has IMDSv1 enabled (IMDSv2 requires a PUT request to get a token, making credential theft via SSRF more difficult): aws ec2 describe-instances --instance-ids INSTANCE_ID and check the MetadataOptions.HttpTokens field. If HttpTokens is optional (IMDSv1 enabled), the instance is vulnerable to SSRF-based credential theft. Review CloudTrail for the API calls made with the exfiltrated credentials: search for the access key ID in the GuardDuty finding (detail.resource.accessKeyDetails.accessKeyId) in CloudTrail events. Disable the credentials immediately via the Lambda remediation pattern, review the EC2 instance for web application SSRF vulnerabilities, and enforce IMDSv2 across the account with an SCP that prevents running instances without IMDSv2 enforcement.
How do I use GuardDuty trusted IP lists and custom threat intelligence lists?
Use GuardDuty trusted IP lists to exempt known-good IP addresses from triggering findings, and custom threat intelligence lists to add organization-specific threat indicators that GuardDuty should detect. Configure trusted IP lists in GuardDuty > Lists > Trusted IP lists by uploading a plaintext file (one IP or CIDR per line) to an S3 bucket and providing the S3 URI. Add your internal vulnerability scanner IPs, penetration testing firm IPs for approved engagements, and any internal monitoring services that communicate with external IPs in ways that GuardDuty would flag as suspicious. Note that trusted IP lists only suppress network-based findings — IAM and CloudTrail-based finding types are not affected by trusted IP lists and require suppression rules instead. Configure custom threat intelligence lists by uploading a file of malicious IP addresses obtained from your threat intelligence feeds (CrowdStrike, Recorded Future, or open source feeds like Emerging Threats) to S3 and adding the file in GuardDuty > Lists > Threat intel sets. GuardDuty evaluates network traffic against custom threat intelligence lists in addition to its built-in AWS Threat Intelligence, triggering findings when EC2 instances communicate with IPs in your custom list that might not be in AWS's own threat feeds.
How do I tune GuardDuty for a container workload environment running on EKS?
Tune GuardDuty for EKS workloads by enabling the EKS Audit Log monitoring feature, configuring suppression rules for expected container behaviors that trigger findings, and enabling EKS Runtime Monitoring for host-level threat detection. Enable GuardDuty EKS Audit Log Monitoring in GuardDuty > Protection plans > EKS Protection which analyzes EKS control plane audit logs for malicious Kubernetes API activity such as privileged container launches, service account token theft attempts, and ClusterRole privilege escalations. For EKS Runtime Monitoring, GuardDuty deploys a security agent DaemonSet to EKS nodes that monitors process execution, network connections, and file access — configure the agent deployment policy to auto-deploy or manual deploy depending on whether you manage the DaemonSet through GitOps. Common false positives in container environments: Execution:Kubernetes/ExecInPod findings for legitimate kubectl exec operations by developers (suppress for specific namespaces or user identities used for debugging), Policy:Kubernetes/AnonymousAccessGranted for Helm releases that create anonymous access bindings during chart installation (suppress after verifying the chart is legitimate), and Persistence:Kubernetes/ContainerWithSensitiveMount for monitoring agents that legitimately mount the Docker socket or host paths.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.