How a rule works

From a record to a signal#

1. Evidence

   Signal turns each record it reads into evidence of a named type - process_creation, scheduled_task, logon - with named fields: process.name, task.path, account.sid. The field reference lists every type and field.

2. Selections

   A rule names selections: each maps fields to the values they must match. All of a selection's fields must match (AND); a field matches if any of its values does (OR).

3. Condition

   The rule's condition combines the selections with and, or, not and parentheses.

4. Matches become signals

   Every record the condition holds for is a match. Matches about the same subject are one signal, with a count.

Two kinds of rule#

Your own rules are pattern rules. The built-in fact rules are listed in the rule catalog with their evidence shown as run facts.

Three-valued logic: unknown is not false#

Some fields are only recorded when a policy is on: process.command_line needs command-line logging. When a record does not carry such a field, a selection over it is unknown - neither true nor false.

Every rule explains itself#

Every rule answers three questions, each in its own field, about one matching event:

Every rule carries its tests#

A rule must carry tests: at least one record it must match, and one look-alike it must not. A rule that fails a test, or has no look-alike, does not run. This is the fidelity contract: it keeps rules precise.

Why JSON, and not Sigma#

Signal's rules name Signal's own fields and evidence types, give their own next steps, and use three-valued logic. A format that looked like Sigma would invite pasting Sigma rules that then do not work. JSON is strict and needs no extra parser. It has no comments: use a rule's notes.

Next#

Write your first rule.