How to Write Detection Rules That Catch Real Threats (Not Just Generate Noise)

The Detection Quality Problem: Coverage Isn't Everything

The standard metric for detection programs is coverage: what percentage of MITRE ATT&CK techniques do you have a detection rule for? This metric is intuitive but deeply misleading. A rule that matches on every PowerShell execution "covers" T1059.001 (Command and Scripting Interpreter: PowerShell) while producing thousands of false positives daily. Coverage percentage is 100%. Analyst value is negative.

The more useful metric is true positive rate per rule per month: of all the alerts a given rule fires, what percentage resulted in confirmed incidents or meaningful analyst actions? A rule that fires twice per month and catches real attacker activity both times is more valuable than a rule that fires 1,000 times per month and catches nothing.

Sixty-seven percent of detection rules never produce a confirmed true positive finding. They exist because someone wrote them during a threat hunt three years ago, or because a vendor included them in a default ruleset, or because a compliance requirement said "you must have detection for X" without any consideration of whether the detection actually works. This is the detection quality problem.

Detection Engineering Fundamentals: What Makes a Good Rule?

Good SIEM detection rules share four characteristics regardless of the format or platform they're written for.

1. Specificity Without Fragility

A good rule is specific enough to exclude benign activity but not so specific that a minor attacker variation bypasses it. Matching on the exact command string mimikatz.exe is too fragile — attackers rename the binary on day one. Matching on the behavior pattern Mimikatz uses (specific Windows API call sequences for LSASS memory access) is specific without being fragile.

2. Context-Awareness

The same event can be completely benign or highly suspicious depending on context. A local administrator account creating a new user is normal during system provisioning and suspicious during an active incident. Good rules incorporate contextual conditions: the event must occur on a specific asset class, outside of normal business hours, in conjunction with other recent activity, or from an account that doesn't normally perform that action.

3. Measurable Severity

Every rule should have a defined severity level and a clear rationale for that level. Severity should reflect two dimensions: the probability that the event represents genuine malicious activity (precision) and the potential impact if it does (criticality). A high-precision, high-criticality rule (direct administrator account compromise with confirmed malicious context) is a critical alert. A low-precision, high-criticality rule (privileged account activity during off-hours, unconfirmed context) is a medium alert that requires investigation rather than immediate incident response.

4. Pre-Deployment False Positive Analysis

Every new rule should be run against 30–90 days of historical data before deployment to measure its false positive rate in your specific environment. A rule that Elastic or Splunk includes in their default ruleset may fire constantly in your environment because of a specific technology or workflow that the ruleset author didn't anticipate. Running against historical data before deployment reveals this problem before it hits analyst queues.

SIGMA: The Universal Detection Rule Format

SIGMA is a generic, open signature format for log-based detection rules. The core value proposition: write a detection rule once in SIGMA, convert it to the query syntax of any SIEM, EDR, or log management platform. One SIGMA rule can be deployed to Splunk, Elastic, Azure Sentinel, Google Chronicle, QRadar, and ZonForge Sentinel without rewriting the detection logic.

SIGMA rules are YAML files with standardized fields: title, description, author, references, tags (MITRE ATT&CK mappings), log source (what type of log the rule applies to), detection logic (field matching conditions), and false positives (known benign triggers to document). The format is human-readable and version-control-friendly, making it well-suited to detection-as-code workflows.

The SIGMA community maintains an open repository of rules covering thousands of MITRE ATT&CK techniques — a starting point for any detection library. The critical caveat: community rules are written for generic environments and will require tuning for your specific log structure, asset inventory, and acceptable false positive tolerance.

Anatomy of an Effective Detection Rule (SIGMA Example)

The following example demonstrates a SIGMA rule for detecting process injection patterns via the CreateRemoteThread API, a technique used by Cobalt Strike, Meterpreter, and many other post-exploitation frameworks. This represents a mid-pyramid detection — it targets a technique (T1055: Process Injection) rather than a specific tool, making it robust against tool variation.

title: Suspicious CreateRemoteThread Into Common Process
id: 66d31e5f-52d6-40a4-9974-2e1a1374b027
status: test
description: Detects a process calling CreateRemoteThread into a commonly abused
  target process — a classic process injection technique used by Cobalt Strike,
  Metasploit, and custom implants for code execution and privilege escalation.
author: ZonForge Detection Engineering
date: 2026/06/13
references:
  - https://attack.mitre.org/techniques/T1055/
tags:
  - attack.defense_evasion
  - attack.privilege_escalation
  - attack.t1055
logsource:
  category: create_remote_thread
  product: windows
detection:
  selection:
    TargetImage|endswith:
      - '\lsass.exe'
      - '\svchost.exe'
      - '\explorer.exe'
      - '\winlogon.exe'
      - '\csrss.exe'
  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Program Files\Microsoft Security Client\'
  condition: selection and not filter_legitimate
falsepositives:
  - Security software performing memory scanning
  - Legitimate debugging sessions (developer workstations)
level: high

Note how the rule is structured: a selection condition identifies the suspicious behavior (CreateRemoteThread targeting sensitive processes), a filter condition excludes known-legitimate sources (Windows system processes that legitimately perform this operation), and the condition combines them to produce the final match logic. The false positives section documents known benign triggers so analysts investigating alerts have context for evaluation. The level field maps directly to alert severity.

Testing Your Detection Rules Before Deployment

Deploying an untested detection rule to production is the fastest path to alert fatigue. The testing workflow for every new rule should include three stages:

Historical Data Replay

Run the rule against 30–90 days of production log data before activating it in the live detection pipeline. Count the number of matches and manually review a sample to assess the false positive rate. A rule that fires 500 times per day against historical data is going to fire 500 times per day in production — decide before deployment whether that volume is acceptable or whether the rule needs more specific conditions.

Adversary Emulation Validation

Use atomic test cases (Atomic Red Team is the de facto standard library) to simulate the specific attacker behavior the rule is designed to catch, then verify the rule fires as expected. If the rule doesn't catch the simulated behavior, it won't catch the real thing. This step validates that the detection logic is correct and that the required log source is actually generating the expected telemetry.

Rule Unit Testing

SIGMA has native support for unit tests via the sigma-test tool and pySigma. Write explicit positive test cases (example log entries that should trigger the rule) and negative test cases (example log entries that should not trigger the rule). Integrate these tests into your CI/CD pipeline for detection rules — so any modification to a rule is automatically validated against its test suite before deployment.

Detection Lifecycle Management: Creating, Tuning, and Retiring Rules

A detection rule is not a one-time artifact. It has a lifecycle: creation, deployment, active tuning, stability, and eventual retirement. Managing that lifecycle requires explicit state tracking for every rule in your detection library.

Practical lifecycle states:

• Draft: Under development, not deployed to production. Undergoing historical data analysis and adversary emulation testing.
• Pilot: Deployed to a subset of environment or in alert-only mode (generates findings without paging). Gathering production false positive data for 14–30 days.
• Active: Fully deployed, generating alerts that enter analyst queues. Tuning ongoing based on false positive feedback.
• Stable: False positive rate within acceptable bounds, true positive rate validated. Minimal tuning required.
• Under Review: A change in the environment (new tool rollout, infrastructure change) has caused the rule to generate significant new false positives. Requires investigation and re-tuning.
• Deprecated: The technique or threat the rule was designed to detect is no longer relevant, or the rule has been superseded by a better detection. Retired from active deployment but preserved in the detection archive for historical reference.

Alert Severity Mapping: When to Page vs Log vs Ignore

Every detection rule needs an explicit decision about what happens when it fires: does it create a critical incident that pages an on-call analyst immediately? Does it create an alert for queue-based triage during business hours? Does it create a low-priority finding for daily review? Does it just log the event for historical hunting purposes without creating an alert at all?

A practical severity framework:

• Critical (immediate page): High-confidence indicators of active compromise or data breach — root console login, mass deletion of security controls, confirmed C2 communication with known-malicious infrastructure. These should be rare and always require immediate response.
• High (queue triage, response within 1 hour): Likely malicious behavior with moderate context confidence — process injection into sensitive processes, privilege escalation attempts, lateral movement patterns. Requires investigation but not necessarily immediate incident response.
• Medium (queue triage, response within 4 hours): Suspicious behavior that requires investigation to determine malicious vs. benign — off-hours login from unusual location, bulk file access from a non-standard account, new scheduled task creation.
• Low (daily review): Potentially interesting behavior with high false-positive rate — PowerShell execution from a user workstation, new local admin account, network scan activity. Worth reviewing but does not warrant queue prioritization.
• Informational (logging only): Events that are contextually useful for investigations but not actionable as standalone alerts — failed login attempts, process execution logging, DNS lookup patterns. Store for hunting and correlation, don't create analyst-facing alerts.

How ZonForge Sentinel Handles Detection-as-Code

ZonForge Sentinel's detection engine natively supports SIGMA rule ingestion, storing each rule as a versioned, metadata-rich artifact rather than a raw query string. Rules in the platform carry their full SIGMA metadata — author, creation date, ATT&CK mappings, false positive documentation, severity level, and lifecycle state — and are searchable, taggable, and reportable as a detection library.

The detection-as-code workflow integrates with Git: security engineers write SIGMA rules in a version-controlled repository, automated tests (historical data replay, unit test validation) run in CI before any rule is merged, and approved rules are automatically deployed to ZonForge Sentinel via a pipeline that handles the SIGMA-to-platform-query translation. No manual copy-pasting of queries into a SIEM interface.

Lifecycle management is built in: every rule tracks its true positive count, false positive rate, last-fired timestamp, and last-tuned timestamp. Rules that haven't fired in 90 days automatically move to a "review" state. Rules with false positive rates above a configurable threshold are automatically flagged for tuning. The platform produces a detection health dashboard that shows the health of the entire detection library — not just individual rules in isolation.

ZonForge Sentinel also layers behavioral analytics over signature-based detection rules, so high-scoring rules that fire in temporal proximity to behavioral anomalies on the same entity are automatically promoted to higher-confidence incidents. This correlation between rule-based and behavioral signals dramatically reduces the analyst time required to determine whether a rule-based alert represents real attacker activity or benign noise.

Conclusion

Detection engineering is a discipline, not a configuration task. Writing security detection rules that actually catch threats — rather than generating noise that erodes analyst trust — requires specificity tuned against your specific environment, systematic testing before deployment, explicit lifecycle management to prevent accumulating stale rules, and severity mapping that matches alert volume to analyst capacity.

SIGMA provides the portable, version-controllable format that makes detection-as-code practical. Testing against historical data and adversary emulation cases closes the gap between "the rule looks correct" and "the rule actually fires when it should." And lifecycle management with true-positive tracking ensures that 67% figure — the share of rules that never catch anything — shrinks rather than grows as your detection library matures.

ZonForge Sentinel's detection-as-code architecture handles the infrastructure that makes this workflow practical at scale: SIGMA ingestion, automated testing pipelines, lifecycle state management, and the behavioral correlation layer that transforms individual rule hits into high-confidence investigations.