Writing SIEM Detection Rules and Alerts

Detection rules are the logic encoded in a SIEM that defines what conditions constitute a security alert. Without good detection rules, a SIEM is just an expensive log storage system. Well-crafted rules identify specific attacker behaviors — credential stuffing, lateral movement, data exfiltration — while avoiding triggering on normal operations. Detection engineering is the discipline of writing, testing, and maintaining these rules continuously.

Every detection rule has key components. A data source specifies which logs are queried. A filter condition specifies what events match. A threshold or pattern defines how many events or what sequence triggers the alert. Metadata includes severity, MITRE ATT&CK mapping, description, and recommended response. Well-documented rules help analysts quickly understand what an alert means and how to respond when it fires.

Every detection rule balances sensitivity (catching all true positives) against specificity (avoiding false positives). A highly sensitive rule catches every attack variant but generates enormous alert noise. A highly specific rule fires rarely but may miss novel attack variations. Good detection engineering starts with high specificity to build analyst trust, then progressively broadens scope as tuning reduces false positives and confidence in the rule grows.

Threshold-based rules trigger when an event count exceeds a limit within a time window. They are ideal for detecting volume-based attacks like brute force, port scanning, and DDoS. Key parameters: count threshold (how many events), time window (within how many minutes), and grouping field (per source IP, per user, per host). Incorrect thresholds cause alert noise or missed detections — tune carefully using historical baseline data.

Sequence-based rules look for a specific ordered chain of events, which is ideal for detecting multi-stage attack patterns. For example: phishing email received THEN malicious attachment opened THEN PowerShell spawned by Office application. Each event alone may be benign, but the sequence indicates compromise. Most modern SIEMs (Splunk, Sentinel, Elastic) support sequence matching with time correlation across event chains.

Sigma is an open, vendor-agnostic format for writing detection rules that can be converted to SIEM-specific query languages (SPL for Splunk, KQL for Sentinel, Lucene for Elastic). The security community shares thousands of Sigma rules on GitHub, covering common ATT&CK techniques. Using Sigma allows organizations to adopt community detections without manually rewriting them for their specific SIEM platform, accelerating detection coverage significantly.

Detection rules must be tested before production deployment. Best practices include: unit testing with synthetic events that represent both true positive and false positive scenarios, replay testing using recorded benign traffic to measure false positive rate, and red team exercises where the rule is expected to fire on controlled attack simulations. Tools like Atomic Red Team provide small test scripts that simulate specific ATT&CK techniques safely.

After a rule is deployed, continuous tuning is required. Common tuning techniques: exclusion lists for known-good processes or accounts that legitimately trigger the rule, allow-listing specific source IPs (scanners, monitoring tools), adjusting thresholds based on observed baseline rates, and adding context conditions (only alert if the host is also externally reachable). Document every exclusion with justification so future analysts understand why they exist.

Detection rules should carry severity ratings that guide analyst prioritization. Common tiers: Critical — active exploitation, ransomware, domain controller compromise. High — lateral movement, credential dumping, C2 communication. Medium — suspicious reconnaissance, policy violations. Low/Informational — unusual but not immediately dangerous events worth tracking. Severity should align with business impact, not just technical severity.

Detection rules have a lifecycle that must be actively managed. Rules become stale when the environment changes (new software deployed, IP ranges change) and generate false positives. Rules miss new attack techniques as adversaries evolve. Best practice: maintain rules in version control (git), review and update quarterly, map every rule to at least one ATT&CK technique, and measure rule effectiveness (fires-per-week, true positive rate) to retire or improve underperforming rules.

A detection coverage map overlays existing detection rules against the MITRE ATT&CK matrix to visualize coverage gaps. Each technique covered by at least one rule is marked green; uncovered techniques are red. This visual reveals which attack phases (e.g., Persistence, Exfiltration) lack detection coverage, helping teams prioritize new rule development. Regular coverage reviews ensure the detection program keeps pace with evolving adversary techniques.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: detection rules encode specific attacker behaviors as alert conditions in the SIEM, threshold and sequence-based rules address different attack pattern types, and Sigma provides a portable format for sharing detections across the security community. Next up we explore UEBA and behavioral analytics for detecting insider threats and compromised accounts.