Threats
The Threats page is the core policy engine. For every GuardDuty finding type and every ThreatReaction custom detector you can choose whether the system ignores it, logs it, or executes an automated containment action. Changes are staged locally and applied only when you click Save.
In the app: /threats
Two Threat Sources
The page is divided into two collapsible sections:
- ThreatReaction — custom detectors built on top of S3 event analysis: S3 Data Exfiltration, Unauthorized IAM Credential Use, Ransomware Write, Ransomware Delete, and Ransomware Enumeration.
- GuardDuty — all native GuardDuty finding types, grouped by AWS service (S3, EC2, IAM, EKS, Lambda, RDS, etc.).
Response Actions
Each threat rule can be set to one of five actions:
Detection is disabled. The finding is not written to DynamoDB or SNS. Use this for noisy, low-value finding types you have already risk-accepted.
Finding is logged to the Events table and an SNS notification is sent if a matching rule exists. No automated containment. This is the recommended starting point for all rules.
Actor IP is added to the WAF managed IP set, dropping all subsequent requests at the CloudFront edge. For IAM-related findings, combines with REVOKE. Requires WAF to be enabled in your stack.
Invalidates the IAM access key or session associated with the finding. The credential can no longer be used even if the attacker still has the key material. Only meaningful for IAM finding types.
Exports the full finding JSON to the findings S3 bucket for forensic archiving. Can be combined with REPORT for log + archive workflows.
GuardDuty Service Groups
GuardDuty finding types are grouped by the AWS service they target (e.g., S3, EC2, IAM). Expand a service group to see all finding types within it. You can set an action at the service level (applies to all severity levels within that service) or expand individual finding types to configure per-severity overrides.
Per-Severity Configuration
Within each GuardDuty service group, findings are further divided by severity: Critical, High, Medium, Low. Setting a service-level action applies it to all severities. To override a specific severity, expand the individual threat types table for that service and set actions at the finding-type + severity level.
Bulk Actions
At the top of each section (ThreatReaction and GuardDuty) there is a dropdown to apply one action to all rules in that section simultaneously. Use this when bootstrapping: set everything to REPORT first, monitor for a week, then promote high-confidence finding types to BLOCK.
Wildcard Support
Finding type identifiers support wildcards. For example, UnauthorizedAccess:EC2/* matches all UnauthorizedAccess finding types targeting EC2. This is useful when you want to apply a policy to an entire finding family without setting each variant individually.
Saving Changes
All edits are staged in the browser. The Save button becomes active once you have made at least one change. Clicking Save sends two API calls: one for ThreatReaction rules and one for GuardDuty rules. A loading indicator appears while the save is in progress. If either call fails, an error banner appears and no partial save is committed.
Refreshing Data
The Refresh button in the app header reloads both threat sources from DynamoDB. Use this if another team member has made changes or if you want to confirm a save was applied correctly.
⚠️ Warning
Switching a rule from REPORT to BLOCK will immediately begin blocking matching actors on the next finding. Test BLOCK in a non-production account first, or use it only on Critical-severity finding types where false positives are rare.
💡 Tip
A recommended onboarding flow: set all rules to REPORT, let the system run for 7–14 days, review the Top Threats on the Dashboard, then promote the top 5 high-severity finding types to BLOCK.
ℹ️ Note
REVOKE only revokes the specific IAM access key referenced in the GuardDuty finding. It does not deactivate the IAM user or role. After revoking, review the IAM console to confirm no additional active keys exist for that principal.