Security Detection Engineering: ATT&CK & Sigma

Security Detection Engineering

Detection engineering is the discipline of designing, building, testing, and maintaining the logic that turns security telemetry into alerts worth a human's attention. It replaces the traditional approach — enable every vendor rule, then drown in alerts — with a deliberate one: decide which attacker behaviors matter to you, confirm you have the data to see them, write detections as reviewed and tested code, and measure whether they work.

Good detections are rare signals in an ocean of normal activity. Every rule trades sensitivity against noise: too broad and analysts learn to ignore it, too narrow and attackers walk past it. Treating detections like software — versioned, tested, owned, and retired when obsolete — is what keeps that trade-off under control as systems and attackers change.

TL;DR

Start from threats relevant to you, mapped to MITRE ATT&CK techniques, not from whatever rules a product ships with.
Prefer behavior-based detections (how attackers operate) over brittle indicators (hashes, IP addresses) that attackers change cheaply.
Write detections as code: version control, peer review, automated tests with true-positive and false-positive samples, and a deployment pipeline.
Use Sigma to express rules in a vendor-neutral format and convert them for your SIEM.
Every alert needs an owner, a severity, and a runbook; tune noise with narrow, expiring exceptions.
Measure precision, coverage, and time to detect, not the number of rules.

Quick Example

A Sigma rule for a successful AWS console sign-in without MFA, written once and converted to the query language of whichever SIEM you use.

The rule states what it detects, which ATT&CK technique it covers, which data it needs, and its known false positives — the metadata an analyst needs when it fires at 3 a.m.

Core Concepts

Threat-Informed Detection With ATT&CK

MITRE ATT&CK is a public knowledge base of adversary tactics (goals such as initial access or persistence) and techniques (how those goals are achieved, such as using valid cloud accounts). Mapping detections to techniques shows what you can see and what you cannot, and lets you prioritize techniques that real attackers use against organizations like yours.

The Pyramid of Pain

Detections at the top of the pyramid — behaviors such as "a new access key created for another user and immediately used from a new location" — keep working when attackers rotate infrastructure.

The Detection Lifecycle

Sigma

Sigma is an open, YAML-based format for describing detections independently of any SIEM. Tooling (such as sigma-cli and the pySigma library) converts rules into Splunk SPL, Elastic queries, Microsoft Sentinel KQL, and other backends. A large community rule repository provides starting points — which still need testing against your own data.

Detection Versus Threat Hunting

Detection engineering builds automated, repeatable alerts. Threat hunting is a human-led search for activity that existing detections miss. Successful hunts should become new detections, so the next occurrence is caught automatically.

Detection as Code

Treat the detection repository like any other production codebase:

Version control for every rule, with history and authorship.
Peer review of new and changed detections.
Metadata per rule: ATT&CK mapping, data source, severity, owner, runbook link, known false positives.
Automated tests that run on every change.
A deployment pipeline that converts and pushes rules to the SIEM, so the repository is the source of truth.

Testing Detections

Test each detection with recorded or synthetic events that should fire and events that should not:

Beyond unit tests, emulate the technique in a test environment — frameworks such as Atomic Red Team provide small, documented attack simulations — and confirm the alert fires end to end. Periodic re-runs catch detections broken by log format changes.

Measuring Detection Quality

Coverage maps are useful for finding gaps, but a technique counts as covered only if a detection for it has been tested recently.

Best Practices

Document Each Detection's Strategy

A short structured record — goal, ATT&CK mapping, technical context, blind spots and assumptions, false positives, validation steps, priority, and response — makes detections reviewable and transferable. Palantir's Alerting and Detection Strategy framework is a widely used template.

Prefer Behavior, Correlate for Confidence

Single events are often ambiguous; sequences are not. "New OAuth grant with mail-read scope, followed by bulk mail access from a new IP" is far more precise than either event alone.

Tune Narrowly and Temporarily

When a rule is noisy, exclude the specific benign pattern — a named service account, a known automation — with an expiry date and owner, rather than raising thresholds or disabling the rule.

Close the Loop With Analysts

Record the outcome of every triaged alert (true positive, benign, false positive) and review the noisiest rules regularly. Detection engineers who never see triage outcomes cannot improve precision.

Common Mistakes

Indicator-Only Detection

Untested Rules That Silently Break

Broad Permanent Allowlists

FAQ

What is detection engineering?

The practice of designing, implementing, testing, and maintaining the rules and analytics that detect malicious activity in security telemetry. It applies software engineering discipline — version control, review, testing, metrics — to the content of a SIEM or detection platform.

What is a Sigma rule?

A detection written in Sigma's vendor-neutral YAML format, describing the log source, the matching conditions, and metadata such as ATT&CK tags and false positives. Converters translate Sigma rules into the query languages of specific SIEMs.

How do we measure detection coverage?

Map tested detections to the MITRE ATT&CK techniques relevant to your environment, and mark a technique covered only if a detection for it has been validated recently — ideally by emulating the technique. Combine coverage with precision and time-to-detect so the map reflects working detections, not rule counts.

How do we reduce false positives?

Add context through enrichment, correlate several weak signals into one stronger detection, exclude specific benign patterns with expiring exceptions, and review the noisiest rules with analysts. Avoid disabling rules or raising thresholds so far that real attacks no longer trigger them.

Where should a small team start?

With a handful of high-value detections on identity and cloud audit logs: sign-ins without MFA, new administrator grants, disabled logging, new access keys, and impossible travel. Test each one, attach a runbook, and grow from there. See Security Information and Event Management for the data foundation.