GuardDuty Alert Tuning Without Blind Spots: Audit Suppression Rules and Trial Custom Detection Rules in Dry Run

Why this matters now

On 10 November 2026 the AWS Security Blog published “Reduce alert fatigue by customizing threat detection features in Amazon GuardDuty”. It describes three stages: customize what GuardDuty detects, triage what remains, and accelerate investigation. This is a hardening guide, not an incident report. No evidence found as of 2026-11-12 in the AWS blog post and the three GuardDuty User Guide pages listed in References of exploitation tied to these features; we did not search CISA KEV or threat-intelligence reporting, and none is claimed here.

The security angle is our assessment: every tuning control is also a way to hide a true positive. A suppression rule that is too broad silently removes findings from your SIEM and ticket queue. The steps below show how to tune and keep that risk visible. All facts below come from the AWS blog post and three GuardDuty User Guide pages (listed in References), so everything is single-vendor.

What AWS says changed

Custom Detection Rules are a library of prebuilt, opt-in rules maintained by AWS. According to the blog, at launch it holds 90 rules across CloudTrail management events and Runtime Monitoring events, producing 38 finding types mapped to 13 MITRE ATT&CK tactics.
Each rule runs in dry run (CloudWatch metrics only, no findings, expires automatically after 14 days) or live mode. The User Guide confirms that dry run metrics are emitted only when a rule matches.
Suppression rules archive matching findings. Per the User Guide, archived findings are kept for 90 days and are not sent to Security Hub CSPM, Amazon S3, Amazon Detective or EventBridge. They also will not trigger a Malware Protection for EC2 scan.
Filters now accept Matches and NotMatches wildcards (* for any number of characters, ? for one). The blog says over 1,000 finding fields can now be used as criteria, in the aws partition.

The risk: suppression and attack sequences

The User Guide states that findings archived by suppression rules are not considered as signals for Extended Threat Detection attack sequences. Its example is a rule that archives all EKS cluster findings instead of targeting known activity, which would stop GuardDuty correlating a container exploit, token theft and sensitive resource access. AWS recommends keeping rules focused on specific behaviors, and building them reactively for findings you have repeatedly confirmed as false positives.

Hardening steps

1. Inventory existing suppression rules

Example commands, to test before use. Replace the detector ID and Region.

aws guardduty list-detectors --region us-east-1
aws guardduty list-filters --detector-id <detector-id> --region us-east-1
aws guardduty get-filter --detector-id <detector-id> --filter-name <name> --region us-east-1

Our heuristics: flag any rule whose only criterion is a finding type, any rule with no owner or description, and any rule older than the field expansion. The blog says rules written before the April 2026 expansion may be broader than intended because the field you wanted was not available then. Only the GuardDuty administrator can create these rules in a multi-account setup.

2. Narrow before you archive

Pair the finding type with a criterion that identifies the known source (a scanner’s namespace, a bastion tag, a fixed CIDR). The User Guide’s own examples use two criteria: finding type plus an instance or IP attribute. A wildcard example from the User Guide, saved as criteria.json:

{
  "Criterion": {
    "resource.lambdaDetails.functionName": { "Matches": ["MyFunc*"] },
    "resource.lambdaDetails.tags.key": { "NotMatches": ["TestTag??"] }
  }
}

The next command shows the syntax only; it is not a recommended filter, because it has no finding-type criterion and would archive every finding for matching functions, which is the broad pattern step 2 warns against. Add a finding type and a known-source criterion before using anything like it:

aws guardduty create-filter \
  --detector-id <detector-id> \
  --region us-east-1 \
  --action ARCHIVE \
  --name syntax-example-do-not-use \
  --finding-criteria file://criteria.json

Take field names for your own rules from the AWS “Property filters” page, which we did not open in full.

3. Know that wildcards cannot be pre-tested

The User Guide says criteria containing wildcards cannot be validated with ListFindings or GetFindingsStatistics. The blog suggests starting from a no-action filter and watching the suppression rule metrics.

4. Audit what you have already hidden

The User Guide documents service.archived equal to true as the way to list archived findings through the API. Sample a week of archived findings per rule and ask whether any would have been actionable.

5. Trial Custom Detection Rules in dry run

From the delegated administrator account, the blog’s examples are:

aws guardduty create-custom-detection-rule-org-configuration \
  --rule-id ami-external-access \
  --mode DRY_RUN

aws guardduty update-custom-detection-rule-org-configuration \
  --rule-id ami-external-access \
  --mode LIVE \
  --exclude-account-ids <image-build-account-id>

Watch the CustomRuleDryRunSignalsMatched metric. The blog’s caution is worth repeating: a dry run measuring real attacker activity looks the same as one measuring routine operations, so investigate matches nobody can explain rather than excluding them.

What we could not verify

Rule IDs, subcommand names and flags for Custom Detection Rules rest on the blog post alone. The Custom Detection Rules User Guide page we opened did not show CLI syntax.
list-filters and get-filter are the CLI forms of the ListFilters and GetFilter APIs named in the User Guide; we did not open the CLI reference.
The 90 rules, 38 finding types and 13 tactics figures, the 1,000-field count and the April 2026 date are the blog’s statements and were not independently checked.
No commands were run in a live account.