Ignore Rules

Ignore rules let you filter incidents out of the ingestion pipeline before they are published. An incident that matches a rule is silently dropped; it never appears in the case queue.

⚠️ Enabling an ignore rule can cause security events to be silently discarded. Once a rule is active, matching incidents are dropped permanently and cannot be recovered. Only proceed if you are confident in what you are configuring.

How Rules Work

Conditions within a rule: AND logic

A rule contains one or more conditions. All conditions must match for the rule to fire. Think of them as a logical AND:

rule fires  ⟺  condition₁ AND condition₂ AND … AND conditionₙ

Multiple rules: first-match wins

Rules are evaluated in order. The first rule that fires wins; evaluation stops. Rules that come later are never tested against that incident.

Operators

Operator	UI label	What it does
`IN`	Is one of	Exact string match: the field value must equal one of the strings in the list
`MATCH`	Matches any of the regexes	Regex match: the field value must match at least one pattern in the list

Quick Reference

# Dotted (duck-typed, forall over arrays)
source.policy.name

# Index selector (strict array, single element)
alerts[0].severity
alerts[2].tags[1]

# Wildcard selector (strict non-empty array, forall)
alerts[*].policy
alerts[*].tags[*]

# Chained brackets
matrix[0][1]

Selector	Array required?	Empty array	Which elements
`key` (dotted)	No (fans out if array)	No match	All
`[N]`	Yes	No match	Element N only
`[*]`	Yes	No match	All

Path Syntax

A condition's path identifies which field in the incident payload to test. Three forms are supported:

1. Dotted keys: nested objects

source.policy.name

Each dot-separated segment descends into an object key. When a segment's value is an array, the rule fans out and requires every element to satisfy the rest of the path (forall, duck-typed).

2. Index selector `[N]`: specific array element

alerts[0].severity
alerts[2].tags[0]

[N] is a strict array selector. The runtime asserts that the value at that point is an array and that index N exists. If either check fails, the condition does not match (fails closed).

3. Wildcard selector `[*]`: all elements, strict array

alerts[*].policy
alerts[*].tags[*]

[*] is also strict: the value must be a non-empty array. Every element must satisfy the rest of the path (forall). An empty array produces no match.

Chaining selectors

Bracket selectors chain directly without a dot between brackets:

matrix[0][1]
alerts[*][0]

A bare key after a bracket requires a dot:

alerts[0].name   ✓
alerts[0]name    ✗  (invalid: no dot before bare key)

Edge-Case Behavior

The guiding principle is fail closed: when the payload shape differs from what the path expects, the condition does not match and the incident is not excluded.

Situation	Result
Field is missing from the payload	No match
Field value is `null`	No match
Field value is an empty array with `[*]`	No match
Index `N` is out of bounds	No match
`[N]` or `[*]` on a non-array value (object, string, number)	No match
Malformed path (e.g. `alerts[`, `alerts[abc]`, `alerts[-1]`)	No match + warning logged
`MATCH` pattern is not a valid regex	No match (pattern silently skipped)

A malformed path never crashes the ingestion pipeline: one bad rule cannot cause incidents to be lost.

Worked Examples

Example 1: Exclude all alerts from a specific policy (forall across array)

Goal: drop any incident where every alert in the bundle has policy = "RedTeam-Noise".

{
  "path": "alerts[*].policy",
  "operator": "IN",
  "values": ["RedTeam-Noise"]
}

// ✅ Ignored — all alerts match
{ "alerts": [{ "policy": "RedTeam-Noise" }, { "policy": "RedTeam-Noise" }] }

// ❌ Case created — one alert has a different policy
{ "alerts": [{ "policy": "RedTeam-Noise" }, { "policy": "Critical-Alert" }] }

[*] asserts the field is a non-empty array and requires every element to match.

Example 2: Exclude based on the first alert only

Goal: drop incidents where the first alert has severity = "low", regardless of other alerts.

{
  "path": "alerts[0].severity",
  "operator": "IN",
  "values": ["low", "informational"]
}

// ✅ Ignored — first alert is low severity
{ "alerts": [{ "severity": "low" }, { "severity": "high" }] }

// ❌ Case created — first alert is high severity
{ "alerts": [{ "severity": "high" }, { "severity": "low" }] }

Only alerts[0] is tested. If alerts has one element or many, only element 0 matters.

Example 3: Exclude by regex on a top-level field

Goal: drop incidents originating from any internal test host.

{
  "path": "hostname",
  "operator": "MATCH",
  "values": ["^test-", "^lab-", "\\.internal\\.corp$"]
}

// ✅ Ignored — hostname matches a pattern
{ "hostname": "test-endpoint-42" }

// ❌ Case created — hostname does not match any pattern
{ "hostname": "prod-endpoint-07" }

The field value is tested against each pattern in turn; if any pattern matches, the condition fires.

Example 4: Combine two conditions to narrow the match

Goal: drop incidents only when the source is "CrowdStrike" AND the first alert's severity is "low".

[
  {
    "path": "source",
    "operator": "IN",
    "values": ["CrowdStrike"]
  },
  {
    "path": "alerts[0].severity",
    "operator": "IN",
    "values": ["low"]
  }
]

// ✅ Ignored — source is CrowdStrike and first alert is low
{ "source": "CrowdStrike", "alerts": [{ "severity": "low" }] }

// ❌ Case created — source matches but severity is high
{ "source": "CrowdStrike", "alerts": [{ "severity": "high" }] }

// ❌ Case created — severity matches but source is different
{ "source": "SentinelOne", "alerts": [{ "severity": "low" }] }

Example 5: `alerts.policy` vs `alerts[*].policy` when the shape varies

Some vendors send alerts as a single object; others send it as an array.

Payload	`alerts.policy`	`alerts[*].policy`
`{ "alerts": { "policy": "X" } }`	✅ Ignored (descends into object)	❌ Case created (`[*]` requires array)
`{ "alerts": [{ "policy": "X" }] }`	✅ Ignored (forall over 1-element array)	✅ Ignored
`{ "alerts": [] }`	❌ Case created (empty array)	❌ Case created (`[*]` rejects empty array)

Use alerts[*].policy when you know the vendor always returns an array and you want the rule to fail closed if it doesn't. Use alerts.policy when the vendor may send either an object or an array and you want the same rule to handle both.

Common Mistakes

Forgetting that `alerts.field` requires every element to match

{ "path": "alerts.severity", "operator": "IN", "values": ["low"] }

This rule fires only if every alert has severity = "low". If even one alert has a different severity, the incident passes through. To check only the first alert, use alerts[0].severity.

Using `MATCH` with an invalid regex

{ "path": "hostname", "operator": "MATCH", "values": ["[unclosed"] }

[unclosed is not a valid regex. The pattern is silently skipped and the condition never matches. The incident is not excluded. Test your regexes before deploying: a pattern that never matches looks identical to a missing field from the outside.

Targeting a field that is sometimes absent

{ "path": "alerts[0].mitre_technique", "operator": "IN", "values": ["T1059"] }

If the vendor omits mitre_technique on some incidents, those incidents will not match: the rule appears broken. Add a second fallback rule, or confirm with the vendor that the field is always present.

Expecting `[*]` to match an empty array

[*] on an empty alerts array produces no match. An incident with zero alerts passes through even if the rule targets alerts[*].*. This is intentional: a vacuously-true exclusion could silently drop real incidents.