Skip to content

Custom Detection Rules

Author your own detections, not just the built-in ones (advanced tier and above). Point-and-click conditions on any normalized field (event, error, principal, IP, region, bytes, GuardDuty finding), with thresholds, time windows, severity, and an ATT&CK tag. Every custom rule raises a threat score exactly like a built-in one and rides the same timeline, alerts, reports, and audit trail.

A custom rule fires when all its conditions match and raises the threat score to at least its severity — it never lowers a higher score. Custom rules are floors-only, so a tuning can never hide a real anomaly the behavioral baseline would still catch.

Three ways to create a rule

  • Start from a template — click a ready-made detection (secret read, access-key creation, MFA disabled, snapshot shared, and more) to fill the builder, then tweak. Works on any tier that includes custom rules; no AI required.
  • Describe it in plain English — type what you want to detect (for example, "someone reads a secret from a new IP") and AI drafts the rule for review. Requires the AI (Bedrock) feature. You can also Refine an existing rule the same way, and click More ideas for AI-suggested detections you don't already have.
  • Import a Sigma rule — paste a Sigma rule (YAML) and it is translated into a custom rule. Import is a fast start for a rule you already have — a bounded translator, not a full Sigma engine — and it never silently mistranslates: anything it cannot map is named for you to add by hand.

Whatever the source, the rule opens in the builder for review — nothing is saved until you click Apply, then Save Rules. Custom rules can carry an ATT&CK tactic and technique, so they extend your MITRE coverage. Every save is recorded in the audit trail with a per-rule diff of what was added, changed, or removed.

Sigma import scope

The importer handles AND-ed fields with the modifiers equals / in-list / contains / starts-with / ends-with / > / ≥ / < / ≤ / cidr / exists, plus level, log source, and attack.* tags. An OR condition (selA or selB, or 1 of …) is imported as several rules, one per branch — review each before saving.

Not translated: regular expressions (excluded by design — use contains/starts-with/ends-with or an in-list), |all/base64 modifiers, and nested/AND-across-selection or negated conditions. For anything beyond that, describe the detection in plain English and let AI draft it.

Narrowing a built-in rule (exclusions)

Each built-in rule can carry exclusions so a known-good pattern stops tripping it — for example, excluding your deploy pipeline's office CIDR from Root Account Usage. Under Configure → Detection Rules, each built-in has an Exclusions section: add a condition (field, operator, value) and Save. If any exclusion matches an event, that rule does not fire for it. The fastest way is from the threat itself: open a threat fired by a built-in rule and click "(exclude this)" next to the rule name — it pre-fills an exclusion drawn from that threat (its source IP as a /24, or its principal) for review and Save.

Exclusions suppress only: they can make a rule fire less, never hide a real anomaly (the behavioral baseline still scores every event on its own), and every change is audited. Available on all tiers; source-IP exclusions work on flow-log rules too.

AI assessment and group tuning (advanced+)

  • Assess a rule — in the custom-rule builder, click Assess to have AI sanity-check the rule you're editing: whether it does what its name says, is too broad, has redundant conditions, or is trying to express something the event fields can't (for example a cross-account comparison the data doesn't carry). The critique is grounded in a field-capability contract (each field's type, legal values, and impossible comparisons) plus deterministic checks, so the structural facts don't rely on the model. Advisory only.
  • Analyze a noisy group — when a rule fires repeatedly and fills a group with similar threats, expand the group and click Analyze. AI assesses whether they look like false positives and proposes an exclusion to add to the firing rule. You then choose two separate actions: Apply rule change (opens the rule in the builder with the exclusion added for review — nothing is saved until you Apply and Save, and the change is audited) and Mark these N as false positive. The suggestion can only ever narrow a rule, never broaden it.

Both require custom rules and the AI (Bedrock) feature.