Detection rule

Detection rules come in several logical types. Atomic or single-event rules match one log record against conditions (a process named rundll32.exe with a command line referencing a URL). Threshold or aggregation rules count events per key over a time window (more than N failed logons per account in five minutes). Correlation or sequence rules require several events in order, often across sources (a successful logon from a new country followed within an hour by mailbox forwarding rule creation). Indicator-matching rules join events against a feed of indicators of compromise. Rules can run as scheduled queries over stored data or as streaming evaluations on ingest; scheduled rules need overlapping look-back windows and must account for ingestion delay, or events that arrive late are silently never evaluated.

Each platform has its own language: Splunk SPL, Microsoft Sentinel and Defender KQL, Elastic EQL and ES|QL, and Google SecOps YARA-L. Sigma, started in 2017 by Florian Roth and Thomas Patzke, is the vendor-neutral YAML format: a rule declares a logsource (product, category, service), named selections of field conditions, a condition expression that combines them, plus metadata such as level (informational to critical), falsepositives and ATT&CK tags; converters translate it into the query language of the target backend. Sigma specification 2.0 standardised correlation rules for counting and ordering matches of other rules. Neighbouring formats cover other layers: YARA for byte and string patterns in files and memory, and Snort or Suricata signatures for network traffic.

Mature teams treat rules as code (detection-as-code). Rules live in version control with a unique ID, an owner, an ATT&CK mapping, a triage guide, known benign causes and test data; changes go through review and CI that validates syntax, runs the rule against recorded malicious and benign samples, and deploys it. Adversary emulation (for example Atomic Red Team tests mapped to ATT&CK techniques) verifies that the telemetry and the rule actually fire. The ATT&CK mapping yields a coverage map, though coverage by technique ID is only a rough proxy: one rule rarely covers every procedure that implements a technique.

Rule quality is a trade-off along David Bianco's Pyramid of Pain: rules keyed to hashes or IP addresses are precise but trivially evaded, whereas rules on behaviour (tools, techniques, procedures) are more durable but generate more benign matches and need tuning. Tuning usually adds exclusions, which must be narrow and reviewed, because a broad allowlist entry such as a whole directory or a signed binary becomes a blind spot attackers can use. Rules also depend on logging configuration: a rule for PowerShell script-block content is useless if script-block logging (event ID 4104) is not enabled, which is why rules should document their required data sources.