Detection engineering with Sigma: SIEM rule lifecycle

Detection engineering is the discipline of designing, testing, deploying and maintaining security analytics. Sigma provides a portable format for detection intent, but a YAML rule does not guarantee detection. Outcomes depend on data completeness, field mappings, backend semantics, test quality, exception governance, triage and response.

The essential answer is: a SIEM rule is a production component with a data contract, accountable owner, tests, version, SLO and retirement procedure. It should begin with a hypothesis about adversary behaviour and end with a measurable operational result. Sigma separates detection logic from a vendor query language, but every translation still needs validation against the target SIEM. “Write once, run everywhere” is unsafe when parser and telemetry differences remain untested.

Detection engineering is more than writing alerts

A one-off alert may be created quickly during an incident. Detection engineering establishes a lifecycle that keeps the capability reliable:

1. identify the behaviour and security outcome to detect;
2. define required sources, schema and data-quality expectations;
3. encode logic and map it to MITRE ATT&CK;
4. run positive, negative and integration tests;
5. deploy gradually, observe and tune;
6. provide triage and response guidance;
7. measure quality, coverage and cost;
8. review after system, parser or threat changes;
9. deprecate and retire safely.

This lifecycle connects Cyber Threat Intelligence with SOC operations. CTI supplies hypotheses and context, while analytics should focus on behaviour visible in the organisation’s data rather than only short-lived indicators.

Write a falsifiable detection hypothesis first

A strong hypothesis can be disproved:

If a lower-trust principal changes a security control and then exercises the newly available capability within a bounded interval, sources A and B will record fields X, Y and Z, allowing the sequence to be distinguished from approved administration.

The hypothesis should specify:

Element	Question
Behaviour	What does an adversary or misusing administrator do?
Outcome	Which security consequence should be constrained?
Principal	Which user, host, workload or process initiates it?
Telemetry	Which source records the behaviour and at what latency?
Fields	Which values are mandatory for logic and triage?
Baseline	What does legitimate automation or administration look like?
Window	Is this one event, a count, a sequence or an expected event missing?
Response	What can an analyst safely do after the alert?

If no available telemetry can support the hypothesis, repair logging first. A rule relying on a field absent from half of the fleet creates paper coverage.

The data contract between source and analytic

A data contract defines event semantics, not merely an index name. It should document:

• source-system and data-product owners;
• product version, audit configuration and covered population;
• transport, parser, normalisation and time-zone handling;
• required fields, types, allowed values and null meaning;
• stable user, device, process and session identifiers;
• expected latency, volume, retention and loss tolerance;
• sensitive-data redaction requirements;
• schema change control and notification;
• an end-to-end canary proving ingestion health.

The contract should distinguish “field is absent”, “value is empty” and “parser failed to recognise the structure”. Numbers, IP addresses, lists and text receive different operators in many backends. Keeping controlled access to the raw event helps debug normalisation, subject to privacy and retention policies.

CISA’s event-logging guidance emphasises centralised, protected telemetry. Each analytic therefore needs source semantics plus the reporting-asset percentage, latency and a way to detect collection failure.

Sigma logsource is an abstraction that requires mapping

In the Sigma Rules Specification 2.1, logsource describes data using fields such as category, product, service and optional definition. It does not automatically select an index, table or parser in a specific platform.

For example, process_creation describes process-start semantics. The organisation must still decide whether the source is Windows Security, Sysmon, EDR or another sensor; which fields represent image, parent, command line, signer and user; and which endpoints actually report.

Maintain an explicit chain:

Sigma logsource
  -> physical source and version
  -> parser / processing pipeline
  -> normalised schema
  -> index, table or dataset
  -> Sigma backend and generated query
  -> SIEM rule and alert

A parser change is a dependency change and should trigger regression tests.

Anatomy of a maintainable Sigma rule

A rule contains metadata, logsource and detection. Useful metadata includes a stable UUID id, status, description, author, dates, references, tags, severity level and known false positives. Keep the same identifier for an ordinary logic revision; create a new one when the analytic represents a different hypothesis.

detection contains named selections and a condition combining them. Value modifiers such as starts-with, ends-with, contains, regular expression and CIDR matching alter comparison semantics. Backend support and query cost differ.

A safe pipeline canary can use a purpose-built process rather than an attack technique:

title: Detection Pipeline Canary Process
id: 9a0cd600-1ed0-4f0a-8946-10aa7df0bb72
status: test
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\detection-canary.exe'
    CommandLine|contains: '--sigma-validation'
  condition: selection
falsepositives:
  - Approved detection pipeline test
level: informational

This does not represent offensive execution. It verifies schema, translation and alert transport with a harmless, attributable event. A production rule also needs risk context, ATT&CK mapping, required fields and triage instructions.

Correlation rules model count, diversity and order

One event is often legitimate. Suspicion comes from frequency, distinct-value count or sequence. The Sigma Correlation Rules Specification defines correlations referring to base rules and types that include event count, distinct-value count, temporal relationship and ordered temporal sequence.

Specify:

• referenced base rules and stable identifiers;
• group-by representing the same entity, such as user, host or session;
• a timespan justified by the behaviour and ingestion delay;
• threshold and comparison direction;
• treatment of late and duplicate events;
• what a missing intermediate event means;
• how the alert presents the full sequence.

Temporal logic cannot assume perfect ingestion order. Endpoint and cloud events may arrive at different times. Use event time for behavioural ordering while preserving ingestion time for pipeline health.

Sigma filters and exception governance

The Sigma Filters Specification separates environment-specific exclusions from reusable detection logic. The shared rule remains readable, while a business exception has its own lifecycle and owner.

Each filter needs:

• narrow scope such as process, signer, account, host, path or behaviour pair;
• justification and approval reference;
• business and technical owners;
• creation and expiry dates;
• a negative test proving exactly what is excluded;
• monitoring for unintended expansion after schema changes.

Do not suppress an entire domain, product, administrator population or system directory just because the first version is noisy. That transforms false positives into a blind spot.

Backend translation does not remove SIEM differences

Sigma expresses intent. A backend and processing pipeline produce the target query. Translation may alter field names, values, wildcard handling, escaping, types and correlation implementation. Engines differ in case sensitivity, regex dialect, arrays, null, event ordering and optimisation.

Before deployment, inspect the generated query:

1. Does it target the right dataset and time partition?
2. Are field mappings and types correct?
3. Did backslashes, wildcards and regular expressions retain their meaning?
4. Does not accidentally discard events with a missing field?
5. Is the time filter based on event or ingestion time?
6. Are query cost and latency acceptable?
7. Does correlation group the intended entity?

Version the source rule and generated artefact with the backend and processing-pipeline release. This makes migration differences reproducible. The operational distinction between platforms is explored in SIEM vs XDR vs EDR.

Unit, integration and negative tests

Unit tests

A unit test feeds a compact event fixture into the logic and asserts whether it should match. Cover every condition branch, modifier, missing field, case variation and boundary value. Validate YAML schema, UUID, status, tags and references as well.

Integration tests

An integration test sends an event through the real collector, parser, normalisation, storage, generated query and alert mechanism. It confirms timestamps, user/host mapping, enrichment, deduplication, routing and analyst-console rendering.

Negative tests

A negative set represents legitimate administration, automation, scanners, deployment systems, updates and near-miss activity lacking one critical element. Near misses are more valuable than unrelated logs because they test the decision boundary.

Regression tests

Run every fixture after changes to the rule, parser, data provider, backend, allowlist or SIEM version. Compare both match results and query cost.

Tuning without silently losing coverage

Classify false positives before changing the rule:

• source or parser defect;
• legitimate behaviour needing context;
• over-broad hypothesis;
• incorrect threshold or time window;
• missing asset or user enrichment;
• duplicate alert covered by another analytic;
• correctly detected but low-impact behaviour.

Order matters. Repair data and enrichment first, narrow selections second, add correlation third and create precise filters last. Lowering severity does not reduce workload. A broad allowlist can improve a dashboard while weakening detection.

Review exceptions by age, match count and owner. A filter that never matches may be obsolete; one suppressing a large share of events requires re-modelling.

Alert triage belongs in the rule design

The alert should tell the analyst:

• why the behaviour is suspicious;
• principal, host, process, source and destination;
• values that matched the selections;
• first and last time plus event count;
• baseline and comparable assets;
• links to raw events and related alerts;
• verification steps and escalation criteria;
• safe containment options and system owner.

If every analyst must manually reconstruct this context, operating cost is hidden outside the rule. A security monitoring programme should account for queues, priorities, service hours and access to customer context.

Versioning and analytic lifecycle

Store rules, filters, fixtures, documentation and translation pipelines in version control. A pull request should show the logical diff, tests, generated-query diff, cost, rollout plan and rollback. Sigma status should communicate maturity rather than marketing.

Practical lifecycle gates include:

• draft or experimental — hypothesis and data are under investigation;
• test — fixtures exist and the rule runs in observation mode;
• stable — owner, SLO, playbook, tests and quality history exist;
• deprecated — another analytic replaces it or source telemetry no longer supports it;
• retired — disabled after checking dependent dashboards, correlations and playbooks.

Retirement must preserve or deliberately replace coverage and update everything referring to the rule ID.

Metrics: precision, recall, coverage and health

Precision is TP / (TP + FP): the proportion of alerts representing the target behaviour. Recall is TP / (TP + FN): the proportion of target cases detected. The true production recall denominator is usually unknown, so estimate it using controlled variants, purple-team results and retrospective incidents.

Also measure:

• percentage of required assets delivering telemetry;
• ingestion and alert latency;
• alert, event and unique-entity counts;
• median and percentile triage time;
• alert-to-case and case-to-incident conversion;
• exception age and share of events suppressed;
• search and storage cost;
• time from schema drift to health alarm;
• ATT&CK coverage weighted by quality rather than tag count.

An ATT&CK tag does not demonstrate effectiveness. One fully tested analytic with healthy data is more valuable than ten rules mapped to a technique but unable to run. MITRE ATT&CK is a behavioural knowledge base and shared language, not an automatic risk score.

Safe purple-team validation

A purple-team exercise should jointly define the hypothesis, expected events, scope, prohibited data, rollback and success criteria. Validation can progress through:

1. synthetic fixtures testing logic;
2. an attributable canary traversing the real pipeline;
3. a controlled simulation of a safe ATT&CK-aligned behaviour;
4. end-to-end alert, triage, escalation and containment;
5. a retest confirming remediation without regression.

Do not use customer data, persistence or destructive commands when a harmless event produces the required telemetry. If realistic execution is necessary, use a dedicated asset with written approval, bounded actions and owner observation.

Exercise the decision process through an incident-response tabletop as well. A technically correct alert without an escalation and communications path does not reduce response time.

Sigma SIEM rule checklist

• The hypothesis defines behaviour, outcome, evidence and response.
• A data contract defines fields, types, coverage, latency and ownership.
• logsource maps to a named physical source and parser.
• The rule has stable ID, status, description, tags, false positives and owner.
• Processing pipeline and backend versions are recorded.
• The generated query has been reviewed in the target SIEM.
• Tests cover positive, negative, near-miss and missing-field cases.
• Integration confirms ingestion, alerting, enrichment and routing.
• Filters carry scope, owner, justification and expiry.
• Triage shows matching evidence and escalation criteria.
• Precision, test recall, data health, latency and cost are measured.
• Purple-team retesting uses no production data or weaponised payloads.

Primary sources

• Sigma Rules Specification 2.1
• Sigma Correlation Rules Specification
• Sigma Filters Specification
• SigmaHQ main repository
• MITRE ATT&CK
• NIST Cybersecurity Framework 2.0
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations
• CISA — Best Practices for Event Logging and Threat Detection