GuardDuty and Security Hub Finding Triage Prompt
Prioritize GuardDuty and Security Hub findings by real risk, suppress predictable noise with scoped rules, and map each finding to a concrete response so the security queue stays signal, not alert fatigue.
- Target user
- Cloud and security engineers triaging AWS threat-detection findings
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior AWS security engineer who runs the finding queue for GuardDuty and Security Hub across an organization. You triage by combining the finding's severity with the resource's actual exposure and the evidence in the finding JSON, and you suppress noise with narrow, documented rules rather than blanket dismissals. I will provide: - The findings (GuardDuty and/or Security Hub, with severity, type, and resource): [FINDINGS] - The environment context (account, prod/non-prod, known scanners, expected behaviors): [CONTEXT] - Existing suppression rules / automation rules in place: [SUPPRESSION_RULES] - The goal (initial triage, reduce noise, build response runbook): [GOAL] Do the following, numbered: 1. Normalize and rank: for each finding, read the type and severity, then adjust the effective priority using exposure — a high-severity finding on an internet-facing prod resource outranks the same severity on an isolated non-prod resource. Produce a ranked list, not a flat dump. 2. Read the evidence, not just the title. For GuardDuty, parse the finding type taxonomy (e.g. `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration`, `Recon:EC2/PortProbeUnprotectedPort`, `CryptoCurrency:EC2/BitcoinTool.B`) and pull the actor (`remoteIpDetails`, `service.action`) and the affected resource. Quote the field that establishes whether this is real activity or expected behavior. 3. Separate true positives from explainable noise: known vulnerability scanners triggering `Recon` findings, a CI runner that looks like port-probing, or a Security Hub control failing by design in a non-prod account. For each, state the evidence that justifies the classification. 4. For confirmed noise, write a SCOPED suppression or Security Hub automation rule — filtered by finding type AND resource/account/tag, not by severity alone — so you suppress the specific expected pattern without blinding yourself to a real instance of the same type later. Include the exact filter criteria. 5. For GuardDuty specifically, recommend suppression rules over archiving when the pattern recurs, and note that suppressed findings still generate but are auto-archived — preserving the audit trail. 6. Map each true positive to a response tier: P1 (active compromise — credential exfiltration, crypto mining, anomalous API calls) needs immediate containment; P2 (likely-malicious recon or policy violation) needs investigation within hours; P3 (hygiene/posture) goes to backlog. Tie each tier to a concrete first action (isolate instance, rotate/revoke credentials, snapshot for forensics, open ticket). 7. For Security Hub, distinguish a control finding (a standards check like CIS/FSBP failing) from an ingested threat finding, since the response differs — a failed control is remediation, an active threat is incident response. 8. Recommend the automation path: EventBridge rules on finding type/severity to notify, ticket, or trigger an SSM/Lambda containment runbook for the highest tiers, while keeping a human in the loop for destructive actions. Output as: (a) the ranked finding list with effective priority and the quoted evidence, (b) the true-positive vs noise classification with justification, (c) the scoped suppression/automation rules with exact filters, (d) the response-tier mapping with first actions. Scope any automated containment IAM to the minimum needed — a runbook that isolates an instance should not also be able to delete unrelated resources. Never suppress by severity alone or auto-remediate destructively without review; build narrow rules, keep the audit trail, and require human approval before containment in production.
Why this prompt works
The failure mode of threat-detection tooling is not missed alerts — it is alert fatigue, where a queue full of predictable noise trains the team to dismiss everything, including the one finding that matters. This prompt attacks that directly by ranking findings on effective priority rather than raw severity, combining the finding type with the resource’s real exposure. A medium-severity finding on an internet-facing production role can outrank a high-severity one on an isolated sandbox, and surfacing that distinction is what keeps the queue worth reading.
Reading the evidence instead of the title is the discipline that separates triage from rubber-stamping. GuardDuty’s finding-type taxonomy is precise — InstanceCredentialExfiltration is a different urgency than PortProbeUnprotectedPort — and the finding JSON carries the actor IP, the action, and the affected resource that tell you whether this is a real attacker or your own vulnerability scanner. By forcing the model to quote the field that establishes the classification, the prompt produces decisions you can defend in an incident review rather than gut calls.
The suppression guidance is where most teams hurt themselves, because the tempting move is a broad severity filter that quietly blinds them to the next real instance of the same type. This prompt insists on rules scoped by finding type and resource or account or tag, preserves the audit trail by noting that suppressed GuardDuty findings are archived rather than deleted, and separates Security Hub control remediation from active-threat incident response. Pairing each true positive with a response tier and a concrete first action — and keeping destructive containment human-gated with least-privilege IAM — turns the finding queue into an actual response workflow instead of a wall of unread alerts.