Becoming a DART Engineer — Foundations

Day 01 — What Is a DART Engineer?

A DART/DFIR engineer is the person who gets called in after something bad has already happened on a network. Concretely, the job is:

• Collecting forensic evidence from endpoints and servers (live and offline)
• Rebuilding an incident timeline from disk, memory, and log artifacts
• Identifying Indicators of Compromise (IOCs)
• Scoping the blast radius — which systems, accounts, and data were touched
• Containing and eradicating the threat
• Supporting recovery
• Writing the root-cause report for leadership or regulators

This is modeled on real teams: Microsoft's DART (Detection and Response Team — roughly 4,500 engagements in 2024) and Google's Mandiant Incident Response practice (2-hour SLA for retainer clients).

How This Differs From Adjacent Roles

SANS' own DFIR taxonomy names these as overlapping specializations within one discipline, not a strict hierarchy — smaller companies often have one person doing all of it; larger orgs (and consultancies like Mandiant) split them into dedicated teams.

The Incident Response Lifecycle (NIST SP 800-61)

The classic four-phase model every SOC/DART job posting and cert (like GCIH) still references:

1. Preparation — runbooks, escalation paths, SIEM/EDR access set up before anything fires
2. Detection & Analysis — the alert-triage phase: is this actually an incident?
3. Containment, Eradication & Recovery — stop the bleeding, remove the root cause, restore normal operation
4. Post-Incident Activity — the lessons-learned review that feeds back into Preparation

(Note: NIST formally withdrew Rev. 2 in April 2025 in favor of Rev. 3, but the four-phase model above is still what's universally taught — you'll see it everywhere in this field.)

---

Go Deeper — Free Learning Material

Everything above traces back to real, publicly available sources. Read them directly for more depth than a 60-second reel can cover:

• Microsoft — "DART: the Microsoft cybersecurity team we hope you never meet"
• Microsoft Tech Community — "Meet DART, the people behind Microsoft Incident Response"
• Google Cloud — Mandiant Incident Response Services
• SANS Institute — "How to Get Started in Digital Forensics & Incident Response (DFIR)"
• LetsDefend — "SOC Analyst vs Incident Responder: What's the Difference?"
• Tyler Technologies — Senior DFIR Engineer job listing (real day-to-day duties)

Day 02 — What Is a SIEM?

Your first real tool as a DART engineer is the one that catches the alert in the first place: a SIEM — Security Information and Event Management.

Gartner defines the SIEM market around the need to analyze event data in real time for early detection of targeted attacks and breaches, while also collecting, storing, investigating, and reporting on log data for incident response, forensics, and compliance. In plain terms: it's a centralized platform that pulls in logs from everything — firewalls, servers, cloud apps, identity systems — normalizes all of it into one format, and lets you correlate events across your entire environment in real time.

Real, named tools in this space: Splunk, Microsoft Sentinel, and historically IBM QRadar (its SaaS product line was acquired by Palo Alto Networks in 2024 and formally retired in 2025 — on-prem QRadar continues separately).

A Concrete Example: Impossible Travel

Definitions are abstract until you see the correlation actually work. Here's a standard SIEM detection pattern:

• Event 1 — a login attempt fails from Frankfurt, Germany.
• Event 2 — four minutes later, the same account succeeds from Ohio, USA.

On their own, these are two unremarkable events — a failed login and a successful one. No single log entry looks suspicious. But a SIEM correlates them across the network: the same account, in two geographically impossible locations, minutes apart. That correlation is what fires the alert — impossible travel — not either event individually.

This is the actual job of a SIEM: it's not watching one machine. It's watching the relationships between all of them.

Where This Fits

A SIEM answers "what happened across the environment, and when?" — the first tool a DART engineer pivots to when triaging whether an alert is real. It's the counterpart to an EDR (Endpoint Detection and Response), which answers a different question — "what exactly did this one machine do?" — coming in Day 3.

---

Go Deeper — Free Learning Material

Everything above traces back to real, publicly available sources. Read them directly for more depth than a 60-second reel can cover:

• Gartner IT Glossary — Security Information and Event Management (SIEM)
• NIST CSRC Glossary — SIEM Tool (NIST SP 800-128)
• CrowdStrike — "What is EDR? Endpoint Detection & Response Defined"
• Palo Alto Networks — "Palo Alto Networks Acquires IBM QRadar SaaS Assets"
• SDxCentral — "What Palo Alto Networks' acquisition means for IBM QRadar customers"

Day 03 — What Is an EDR?

The SIEM (Day 2) tells you what happened across the whole environment. It has no idea what happened on any one machine in detail. That's the gap an EDR closes — Endpoint Detection and Response.

The term was coined by Gartner analyst Anton Chuvakin in 2013. Gartner's definition: a solution that records and stores endpoint-system-level behaviors, uses data analytics to detect suspicious system behavior, provides contextual information, blocks malicious activity, and provides remediation suggestions to restore affected systems.

In practice: an EDR agent runs directly on the endpoint, capturing process execution, file, registry, and network activity at a granular level. Unlike a SIEM, it can also act directly on that machine, in real time — killing a process, isolating a host from the network, rolling back ransomware encryption.

Real, named tools in this space: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne.

A Concrete Example: Ransomware Containment

Say a process on someone's laptop suddenly starts encrypting file after file — classic ransomware behavior. A SIEM alone might not catch this in time; it's watching the environment, not the fine-grained behavior of one process on one machine.

An EDR sees it happening in real time, on that one machine, and can:

• Detect — flag the mass file-encryption pattern as it starts
• Kill the process — stop the ransomware binary immediately
• Isolate the host — cut the laptop off from the network so it can't spread
• Roll back — undo the encryption on files already touched

Where This Fits

A SIEM and an EDR answer different questions. The SIEM answers "what happened across the environment, and when?" — cross-machine correlation. The EDR answers "what exactly did this one machine do, right now?" — deep, real-time, single-host telemetry and action. In a real incident, a DART engineer pivots between both: the SIEM's correlation flags something worth looking at, the EDR gives the granular detail and the ability to act.

The line between the two has been blurring for years — vendors increasingly sell unified "XDR" platforms that fuse both (Microsoft Sentinel + Defender XDR, Palo Alto Cortex XSIAM). Worth knowing both halves regardless of which platform label a vendor uses.

---

Go Deeper — Free Learning Material

Everything above traces back to real, publicly available sources. Read them directly for more depth than a 60-second reel can cover:

• CrowdStrike — "What is EDR? Endpoint Detection & Response Defined"
• Wikipedia — Endpoint Detection and Response (cites Chuvakin's original 2013 framing)
• Gartner IT Glossary — Security Information and Event Management (SIEM)
• NIST CSRC Glossary — SIEM Tool (NIST SP 800-128)
• Palo Alto Networks — "Palo Alto Networks Acquires IBM QRadar SaaS Assets"

Day 04 — Alert Triage — Deciding If It's Real

An EDR can kill a process in an instant. But something has to notice it's worth watching in the first place. That's the job NIST calls Detection and Analysis — the second phase of the incident response lifecycle, and the one NIST itself calls the hardest, because the signals are noisy.

The workflow, in order:

1. Monitor — watch for precursors and indicators through your SIEM, your EDR, intrusion detection systems, even a user reporting something strange
2. Determine — decide whether it's actually a real security incident
3. Categorize — sort it by type
4. Prioritize — decide how urgently it needs attention

(NIST SP 800-61 Rev. 2, the four-phase model this is drawn from, was formally withdrawn in April 2025 and superseded by Rev. 3 — but Rev. 2's phases are still what's universally taught, and what most SOC/DART job postings and certs still reference.)

A Concrete Example: 500 Failed Logins

Numbers alone don't tell you much. Five hundred failed logins against one account in an hour sounds alarming no matter what caused it. The pattern is what actually tells the story:

• Brute-force attempt — one unfamiliar IP address, trying different password guesses, fast
• Ordinary user error — the same device, the same usual location, retrying that one stale cached password over and over

Same raw number. Completely different signal. A DART engineer checks the pattern, not just the count, before anything gets escalated.

The Real Job

Most alerts aren't incidents. The actual skill in this phase isn't watching a dashboard, it's knowing which blinking light is an actual fire.

---

Go Deeper — Free Learning Material

Everything above traces back to real, publicly available sources. Read them directly for more depth than a 60-second reel can cover:

• NIST SP 800-61 Rev. 2 — official page, confirms withdrawal 2025-04-03, superseded by Rev. 3
• NIST SP 800-61 Rev. 3 (current)
• Rapid7 — "Introduction to Incident Response: Life Cycle of NIST SP 800-61"

Day 05 — You Can't Detect What You Don't Collect

A detection rule can run for months, return zero results, and still be completely broken. Zero hits doesn't mean nobody tried — it can just as easily mean the rule is querying data that never got generated in the first place. This is the failure mode Day 5 covers: the telemetry layer underneath every rule you'll ever write.

Windows Event ID 4688 is off by default

The Windows event that records a process starting — Event ID 4688, "A new process has been created" — is not logged out of the box. Someone has to explicitly turn on "Audit Process Creation" in Windows audit policy before it generates at all.

Even once it's enabled, 4688 by default omits the full command line. A rule hunting for something like powershell -enc <base64> needs the command-line arguments, not just the fact that powershell.exe ran — and that requires a second, separate policy setting (Include command line in process creation events, via Group Policy or the registry) on top of enabling the event itself.

A rule built against 4688 without both of these switches on doesn't error and doesn't warn you. It just quietly returns nothing, forever, and an empty dashboard looks identical to a clean one.

Sysmon closes the gap — and so does a modern EDR

Sysmon (Microsoft Sysinternals) fills this hole with one structured event: Sysmon Event ID 1, which includes the command line, file hashes, and parent process in a single record, no secondary policy toggle required.

Worth being precise here: if you already run an EDR agent, it typically already captures process execution — command line included — as part of its normal telemetry, independent of Windows audit policy entirely. That's part of why Sysmon and EDR coverage often overlap; many teams run both anyway, since Sysmon's schema is well-documented and vendor-independent, useful for portability across SIEMs.

The three places logging can silently break

The wider lesson generalizes past 4688 specifically. Any piece of telemetry has to pass through three distinct checkpoints, and a rule can go dark at any one of them without a single error message:

1. Generation — is the event being produced at all? (4688 disabled = no.)
2. Collection — is the generated event actually being shipped to wherever the rule runs? (An agent misconfiguration, a forwarder queue backing up, a log source excluded from an index.)
3. Retention — is the data still there by the time anyone queries it? (A short retention window, an index that rolled off before an investigation started.)

Break any one of the three and the result looks identical from the rule's point of view: silence. This is why "the rule has zero hits" is not, on its own, evidence that a detection is working.

Go Deeper

• SANS — You Can't Detect What You Can't See: Closing Gaps in Detection Engineering
• MITRE ATT&CK — Data Sources
• Microsoft — Sysmon (Sysinternals) documentation
• NIST SP 800-92r1 (initial public draft) — Guide to Computer Security Log Management

Day 06 — Same Event, Three Names

Your firewall calls it src_ip. Your cloud logs call it sourceIPAddress. Your identity provider calls it something else again. Same fact, three vendors, three field names — and a rule written against one of them silently can't see the other two. This is the problem Day 6 covers: data normalization, the layer that makes a single detection rule work across every tool you own.

What normalization actually does to a record

Raw logs are vendor dialects. A firewall log, a Zeek conn.log, a CloudTrail record, and an Okta system log can all describe the same underlying fact — "someone connected from somewhere" — and still disagree on the field name for the source IP, the timestamp format, and even what counts as a "user." Without normalization, a query for a suspicious IP has to be written once per log source, and a correlation rule that needs to join endpoint activity to identity to network activity can't be written at all, because there's no shared field to join on.

Normalization does four things to a single record:

1. Renames fields to canonical names — src_ip, SourceAddress, and Zeek's id.orig_h all become one field.
2. Coerces types and formats — timestamps to UTC ISO 8601, ports to integers.
3. Classifies the event into a shared taxonomy — this is an authentication event with outcome failure, regardless of which product produced it.
4. Preserves the original raw message alongside the normalized version — nothing is lost, which matters both for investigation and for fixing a bad parser later.

Do this once at ingest, and every rule written afterward works across every log source feeding it.

Two real schemas — and they didn't merge

Elastic Common Schema (ECS), released by Elastic in 2018, is a flat, dot-delimited field vocabulary — @timestamp, source.ip, destination.ip, user.name, process.name, host.name — layered with a categorization taxonomy (event.category, event.type, event.outcome) with controlled allowed values. That taxonomy is what makes source-agnostic rules possible.

Open Cybersecurity Schema Framework (OCSF), announced August 2022, is a vendor-neutral, security-native schema backed by a large multi-vendor group — AWS, Splunk, CrowdStrike, IBM Security, Palo Alto Networks, Okta, and others. Its structure is hierarchical rather than flat: broad categories (System Activity, Identity & Access Management, Network Activity, and more) contain event classes, each with a class_uid and typed attribute objects. In November 2024, OCSF joined the Linux Foundation — governance moved out of any single vendor's hands, which is a large part of why it's treated as the neutral option going forward.

Here's the part that gets misstated constantly: ECS did not merge with OCSF. The real, dated event is different. In April 2023, Elastic donated ECS to OpenTelemetry, with Elastic and the OTel community jointly committing to converge ECS and OpenTelemetry Semantic Conventions into a single schema maintained by OpenTelemetry — and by Elastic's own account, that convergence is a directional decision, not a completed merge; it remains unfinished today, since some ECS fields resist mapping cleanly onto OTel's data model.

So the actual landscape: ECS is drifting toward OpenTelemetry along an observability lineage. OCSF stands separately as the security-native schema under Linux Foundation governance. Two schemas, two different trajectories, coexisting — not one absorbing the other.

Why this matters for a rule you write

A rule is only as portable as the field names it's written against. A rule hard-coded to a firewall vendor's raw src_ip field breaks the moment that log source changes, or the moment you want the same logic to also catch a cloud-side or identity-side version of the same event. Normalizing at ingest — mapping every source into ECS or OCSF once — means a detection rule speaks one vocabulary instead of memorizing every vendor's dialect.

Go Deeper

• OCSF — official site
• Linux Foundation — OCSF Joins the Linux Foundation (Nov 2024)
• Elastic — ECS and OpenTelemetry reference
• OpenTelemetry — Announcing the ECS and OTel Semantic Convention Convergence (Apr 2023)
• AWS — OCSF in Amazon Security Lake

Day 07 — One Attack, Three Names (MITRE ATT&CK)

A phishing email lands. Threat intel calls it initial access. The SOC calls it a malicious attachment. The red team's finding calls it something else again. All three are describing the exact same email, and without a shared vocabulary, none of them realize it. Day 7 covers the framework built to fix that: MITRE ATT&CK.

What ATT&CK actually is

ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a free, publicly available knowledge base of real adversary behavior, created and maintained by MITRE. It began around 2013 from MITRE's internal research into detecting post-compromise behavior on Windows networks, and went public in 2015.

Its value was never that it lists attacks. It's that it gave the security industry one set of names and IDs for adversary behavior. Before ATT&CK, a threat intel report, an EDR alert, and a red team finding could describe identical activity three different ways, with no way to confirm they were even talking about the same thing.

Three real levels

• Tactics — the adversary's goal, the "why," with TA#### IDs. As of ATT&CK v19, the Enterprise matrix has 15 tactics: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Stealth, Defense Impairment, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.
• Techniques — the "how," with T#### IDs. T1566 is Phishing.
• Sub-techniques — specific variants, T####.###. T1566.001 is Spearphishing Attachment; T1566.002 is Spearphishing Link. A technique can map to more than one tactic, so the matrix isn't a strict tree.

Day to day, a detection team uses ATT&CK as a labeling and prioritization layer, not a rulebook. Every detection rule carries the technique ID it's meant to catch, so an analyst seeing an alert immediately knows roughly where in an intrusion they are. Threat intel about an actor arrives as a list of technique IDs, which converts directly into a detection backlog — that loop is what "threat-informed defense" means in practice. It's also the shared vocabulary for handoffs: "we have coverage for T1566.001 but nothing for T1566.002" is unambiguous in a way prose never is.

The part that's easy to get out of date on

Two structural changes are recent enough that a lot of tooling and online content hasn't caught up:

• v18 (October 2025) replaced the old free-text "Detection" paragraph on each technique page with structured Detection Strategy and Analytic objects, and deprecated Data Sources in favor of Data Components.
• v19 (released 28 April 2026) split the old Defense Evasion tactic. TA0005 was renamed to Stealth (hiding inside legitimate behavior — obfuscation, masquerading, injection), and a new TA0112 Defense Impairment was created for actively breaking security controls (disabling tools, modifying firewalls, tampering with authentication).

Anything written before mid-2026 that says "Defense Evasion, TA0005" is describing the pre-v19 world. Most content still online does exactly that.

What ATT&CK is not

ATT&CK is retrospective by construction: a novel technique isn't in it until someone catches and documents it. It doesn't prioritize; nothing in the framework tells a hospital which techniques matter more for its specific risk than they do for a bank. And the most common misuse, one MITRE itself explicitly warns against, is the checklist fallacy: treating the matrix as a to-do list and chasing "100% coverage." A vendor claiming full ATT&CK coverage is making the commercial version of the same mistake.

Go Deeper

• MITRE ATT&CK — Enterprise Tactics
• MITRE ATT&CK — Enterprise Matrix
• MITRE ATT&CK — Updates / release history
• T1566 Phishing
• TA0112 Defense Impairment
• ATT&CK Design and Philosophy (MITRE, PDF)

Day 08 — What a Detection Rule Actually Is (Sigma and YARA)

A rule fires at 3am. Someone gets paged. If the rule has no notes attached, that person has to reverse-engineer what it means before they can even decide whether to care. Day 8 covers what a detection rule actually is — and why the logic is only half of it.

Two halves, equally load-bearing

A detection rule is code describing a pattern worth alerting on, plus the metadata a human needs to act on it.

• Logic — which data to look at (logsource), what pattern to match (selections), how matches combine (condition, boolean).
• Metadata — a stable unique id, title, description (why this fires), references, author, date/modified, status, level, falsepositives, fields (what to pull up when triaging), and tags (ATT&CK/CAR/CVE mapping).

In the Sigma spec, only title, logsource, and detection are strictly required — which is exactly why undocumented rules are easy to write and painful to inherit.

Sigma: write once, compile everywhere

Sigma is the vendor-neutral YAML format for writing log-detection logic, maintained by SigmaHQ (originated by Florian Roth and Thomas Patzke). The point is portability: write the detection idea once, then compile it to whatever query language your SIEM actually speaks. The current spec is v2.1.0, released 2025-08-02, tracked in its own repo (SigmaHQ/sigma-specification) separate from the rule set (SigmaHQ/sigma).

Sigma is not a query language itself — it compiles to one. The modern toolchain is pySigma, driven by sigma-cli (sigma convert -t splunk ./rules), with backends installed as separate plugins (sigma plugin install splunk). There are 30+ conversion targets, including Splunk SPL, Microsoft KQL, Elasticsearch (Lucene/ES|QL/EQL), QRadar AQL, CrowdStrike LogScale, Grafana Loki LogQL, and SentinelOne. Sigma v2 also added correlation rules, for count/temporal logic a single-event rule can't express on its own.

A real rule: Renamed Whoami

This is reproduced verbatim from the SigmaHQ repository (rules/windows/process_creation/proc_creation_win_renamed_whoami.yml):

title: Renamed Whoami Execution
id: f1086bf7-a0c4-4a37-9102-01e573caf4a0
status: test
description: Detects the execution of whoami that has been renamed to a different name to avoid detection
references:
    - https://brica.de/alerts/alert/public/1247926/agent-tesla-keylogger-delivered-inside-a-power-iso-daa-archive/
author: Florian Roth (Nextron Systems)
date: 2021-08-12
modified: 2022-10-09
tags:
    - attack.discovery
    - attack.t1033
    - car.2016-03-001
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        OriginalFileName: 'whoami.exe'
    filter:
        Image|endswith: '\whoami.exe'
    condition: selection and not filter
falsepositives:
    - Unknown
level: critical

The idea is legible in one line: a renamed binary still carries whoami.exe as its original filename in its own PE metadata, even after someone renames the file on disk to dodge naming-based detection. selection catches anything whose embedded original filename says whoami.exe. filter excludes anything that's still named whoami.exe on disk (the legitimate, unrenamed case). condition: selection and not filter is the whole trick — match the renamed ones, exclude the honest ones.

A few spec details worth knowing when you read a rule like this:

• status values: stable, test, experimental, deprecated, unsupported
• level values: informational, low, medium, high, critical
• ATT&CK tags: techniques (attack.t1033), sub-techniques (attack.t1059.001), tactics hyphenated (attack.defense-evasion) — underscored forms are legacy
• Field modifiers use pipes: Image|endswith, CommandLine|contains

Sigma vs YARA — logs vs files

These two get mixed up constantly, and they're not competitors. YARA (created by Victor M. Alvarez, maintained by VirusTotal) matches patterns in files and memory — bytes, strings, PE structure. Sigma matches patterns in logs and telemetry. Sigma answers "did something suspicious happen"; YARA answers "is this thing the malware I'm looking for." There's a structural parallel — YARA's meta is roughly Sigma's metadata block, YARA's strings are roughly Sigma's selections, and both use a condition — but the substrate they search is fundamentally different, not a matter of one being newer or better.

Worth knowing if you're going deeper on YARA specifically: YARA-X 1.0.0, a Rust rewrite by the same original author, shipped 2025-06-04 and is now used in VirusTotal Livehunt/Retrohunt. Classic YARA 4.x is in maintenance mode (bug fixes only) — syntax is largely compatible, but "which YARA" is a real question to ask before following a tutorial.

The tutorial trap: sigmac is dead

A lot of blog posts and course material still teach sigmac -t splunk as the way to convert Sigma rules. Don't follow that. The original sigmac converter now lives in SigmaHQ/legacy-sigmatools, explicitly unmaintained. If a tutorial invokes sigmac, it's stale — use pySigma + sigma-cli instead.

One honest caveat: how much any given team actually authors detections in Sigma varies. Some author everything in Sigma and compile out to their SIEM; others author natively in their SIEM's own query language and only use Sigma to pull in community-published rules. Sigma-first isn't universal practice — it's a common and growing one.

Go Deeper — Free Learning Material

• Sigma Rules Specification v2.1.0
• Sigma Tags Appendix
• SigmaHQ/sigma — public rule repository
• SigmaHQ/pySigma
• SigmaHQ/legacy-sigmatools — the deprecated sigmac toolchain
• Sigma backends and sigma-cli usage
• Writing YARA rules — official documentation
• YARA-X 1.0.0: The Stable Release (VirusTotal, 2025-06-04)

Day 09 — Writing Your First Detection

Most people open the SIEM and start typing. That's not step one — it's step three, and skipping the first two is a big part of why so many detections stop working a few weeks after someone ships them. Day 9 covers the actual lifecycle: what has to happen before you write anything, and what has to happen after.

It's code, not a one-time hunt

The most important mental shift: a detection isn't an investigation you run once and close out. It's logic you write once that keeps running by itself, forever, against every event that matches from here on. Detection engineering treats detections as software, not console settings — which is also why the discipline borrows software's own vocabulary: requirements, development, testing, deployment, maintenance.

The lifecycle

There's no single canonical diagram for this — vendors publish four-, five-, six-, and seven-stage versions with different names for the same underlying shape. The stages below are a synthesis, not the standard:

1. Requirements / hypothesis — demand comes from somewhere specific: threat intel on a relevant actor, an ATT&CK coverage gap, a purple-team finding, a lesson from a past incident, a new asset entering the environment. The output is a stated hypothesis about adversary behavior — "we should have a rule for Mimikatz" isn't one; "attackers moving laterally will enumerate local admin groups via PowerShell" is.
2. Research — the step beginners skip, and the one that kills a lot of good ideas before they waste anyone's time. Can you even see this behavior in your logs? Which telemetry source carries it? Is that logging actually enabled in this environment? What does normal traffic doing something similar look like, so you have a baseline for false positives later?
3. Develop — write the logic. Under detection-as-code, that's a rule file committed to Git and peer-reviewed via pull request — not a query pasted directly into a SIEM's UI and saved.
4. Test / validate — generate a real true positive (an atomic test, a purple-team exercise, a controlled emulation of the actual technique) and confirm the rule fires. Then run it against historical data to estimate the false-positive load before anyone's pager depends on it.
5. Deploy — ship it through CI/CD, with documentation attached to the alert itself, not living separately in a wiki no one reads at 3am.
6. Tune — the alert meets reality, and reality is noisier than the test data.
7. Maintain / retire — periodically revalidate that the rule still fires the way it did on day one, and delete what no longer earns its place.

Documenting a rule so it survives you

The most citable template for the documentation half is Palantir's open-sourced Alerting and Detection Strategy (ADS) Framework — required sections filled in before a detection reaches production: Goal, Categorization (mapped to ATT&CK), Strategy Abstract, Technical Context, Blind Spots and Assumptions, False Positives, Validation, Priority, Response, Additional Resources. Palantir's own stated motivation for publishing it is blunt: alerts had "gained a reputation of being low-quality, which led to fatigue, alerting apathy."

Two sections do most of the work. Validation — "steps required to generate a representative true positive event" — is what makes a detection re-testable a year later by someone who didn't write it. Response — "general response steps in the event that this alert fired" — is what makes the alert actionable to whoever's on call, not just to its author. A rule with neither is a tripwire with no instructions attached.

ADS adoption is partial in practice; most teams adapt a subset rather than filling in every section for every rule. It's an established reference, not an evolving standard the whole industry has converged on.

A worked example

Say your hypothesis is: attackers enumerating local admin group membership will do it through PowerShell, since it's already present on every modern Windows host and blends into normal admin activity.

Research first. Can you actually see PowerShell command lines in your logs? If Script Block Logging or Module Logging isn't enabled, the rule you write next has nothing to check against — it will simply never fire, and you won't be able to tell the difference between "nothing bad happened" and "the rule can't see anything." That's the research stage doing its job: catching a dead-on-arrival idea before anyone spends time writing logic for it.

Then develop. Once you've confirmed the telemetry exists, the rule itself can be small — something checking that the process is powershell.exe and its command line contains net localgroup administrators is a reasonable starting selection.

Then validate. Run the real technique yourself, on purpose, against a test system — an atomic test — and confirm the rule actually fires. That's what separates validation from assumption. And once it's live, it isn't a one-time catch: it's watching for that exact pattern, every time, from here on, which is the entire point of writing it as code instead of running the check by hand once.

Why detections have to be retired, not just added

The part beginners rarely hear: detections decay. Adversaries change tactics specifically to evade published logic. A log source gets re-architected or a field gets renamed, and the rule silently stops matching anything. The business changes and yesterday's anomaly becomes today's normal deployment pattern. A vendor ships native coverage for something your custom rule already handled, and now you're maintaining a duplicate.

A rule that no longer fires isn't quietly doing its job — it's unfalsified. You can't tell "nothing bad happened" apart from "this rule broke in March" without periodically re-validating it. Practitioners call the accumulated cost of not doing this detection debt — borrowed vocabulary from technical debt, not an industry-standardized term, but the mechanism is the same and the tax is paid the same way: in alert fatigue. Sigma bakes retirement in as a first-class concept — status: deprecated and unsupported are real spec values, and SigmaHQ moves retired rules to a dedicated directory instead of deleting them outright.

Go Deeper — Free Learning Material

• Palantir Alerting and Detection Strategy Framework (GitHub)
• ADS-Framework.md — the required sections, verbatim
• Alerting and Detection Strategy Framework (Palantir Blog, Apr 2019)
• Elastic releases the DEBMM (2024-09-06)
• elastic/detection-rules
• Detection Engineering Maturity Matrix — Kyle Bailey
• What Is Detection Engineering? (Splunk)

Day 10 — Most Alerts Are Nothing

Most security teams know more about what's supposed to be on fire than they know about what's actually on fire — and that's by design, mostly. The interesting failure isn't the rule that missed the attack. It's the rule that fired on the attack, woke up the team, and was treated like every other page that day. The detection worked. The control failed anyway. That's the case for the next several minutes.

Why "we got an alert" stops meaning anything

Alert fatigue is desensitization from a queue producing far more alerts than can be investigated, where the overwhelming majority are benign. The failure isn't laziness — it's structural. When base rates are that skewed, ignoring the queue becomes rational-feeling coping, and the one real alert is statistically indistinguishable from noise at triage time.

The numbers, both from vendor-sponsored research and surfaced as such:

• IDC InfoBrief, "The Voice of the Analysts," sponsored by FireEye (fielded Fall 2020, published February 2021) — 300 US SOC managers/analysts plus 50 MSSPs. More than one-third said they ignore alerts when the queue is full. Alerts not investigated: 27% at 500–1,499 employees, 30% at 1,500–4,999, 23% at 5,000+.
• Vectra AI, "2023 State of Threat Detection," fielded by Sapio Research Mar–Apr 2023, published 19 July 2023 — 2,000 SecOps analysts at 1,000+ employee orgs across 11 markets. Average 4,484 alerts per day; analysts unable to deal with 67% of daily alerts; 83% say alerts are false positives not worth their time.

Both are vendor-funded; both are the most-cited numbers in the field, which is a useful fact in itself — most of what's published on alert fatigue has the same commercial sponsorship as the tools it measures. The ACM Computing Surveys paper "Alert Fatigue in Security Operations Centres" (2025, DOI 10.1145/3723158) calls independent measurement an open research gap.

There is no defensible single "average SOC ignores X%" number. Credible published figures span roughly 23%–67% across those two studies — different populations, different question wording. Anyone quoting a single decimal point on this topic is overselling the data.

The canonical case: Target, 2013

On November 30, 2013, attackers staging exfiltration malware in Target's environment triggered the company's FireEye intrusion-detection system — a roughly $1.6M deployment monitored from a SOC in Bangalore. FireEye fired alerts. The Bangalore team escalated, by the playbook, to the Minneapolis home SOC.

No action was taken. FireEye's automatic malware-deletion capability had been turned off. The page sat. Target reportedly learned it had been breached roughly two weeks later, when the US Department of Justice notified the company. About 40 million payment cards and 70 million customer records were exposed.

Two contemporaneous investigations cross-confirm the timeline:

• Bloomberg Businessweek, "Missed Alarms and 40 Million Stolen Credit Card Numbers," 13 March 2014 — the named-source public account of what the SOC team received, escalated, and didn't act on.
• US Senate Commerce Committee staff report, "A 'Kill Chain' Analysis of the 2013 Target Data Breach," 26 March 2014 — the Senate's reconstruction of the detection-and-response chain, including the off-state of FireEye's auto-delete.

The point for a detection engineer isn't that the attackers were sophisticated. The detection worked. The alert fired. The control failed — at the human-in-the-loop step, the auto-delete step, and possibly at the step where the original FireEye deployment was scoped narrower than the threat model demanded. Detection engineering that stops at "the rule fires" has stopped one step short.

What "tuning" actually means — and what it isn't

The reflex to a noisy alert is to make it quieter. Three categories of lever, with different costs:

Allowlists and exceptions. Encode the specific known-benign condition so it stops paging. Every allowlist is teaching the environment to ignore something. A service account that gets allowlisted for "impossible travel" will never trigger on a credential-theft replay through that account. A vendor subnetwork carved out for "unusual PowerShell" will never trigger on a compromised vendor appliance.

Threshold and aggregation tuning. "50 failed logons in 5 minutes" instead of "every failed logon." An adversary who stays at 40 is invisible. An adversary who knows your threshold and times their attempts accordingly is invisible in a more interesting way — because you built the rule around their activity budget.

Enrichment and context. Often the cheapest and most-overlooked lever. Ambiguity is usually what makes an alert expensive, not raw volume — attaching asset criticality, user role, prior behavior, and a one-line "this looks like X because Y" converts a 20-minute investigation into a 20-second decision. Most teams under-invest in this relative to how much investigation time it would save.

Two related distinctions that get muddled:

• Suppression vs. deletion. Suppression keeps the rule and the underlying telemetry running while stopping known-benign instances from paging — you can still go look at the suppressed events when you have a new hypothesis. Deletion removes coverage and the record that you ever had it. A year later, nobody remembers the rule existed, the gap it covered, or why.
• "Just delete the noisy rule" is wrong. Noise usually means the rule is under-specified for your environment, not that the behavior it watches is uninteresting. Deleting removes detection for the malicious variant along with the benign one, and the team loses both the rule and the institutional memory of what it was protecting.

The mature form of tuning is writing the blind spot down. Every exclusion is a hole an attacker can occupy, and the discipline isn't pretending the hole doesn't exist — it's naming it, on purpose, in the detection documentation, so a future threat-model exercise knows to factor it back in.

What this means for the discipline

If you write detections but never look at what happens to them after they fire, you're doing detection theater. Three practices that close the loop:

1. Measure response time, not alert volume. A team that handles 100 alerts/day to an average MTTR of 8 minutes is doing more useful security work than a team that triages 4,000 alerts to a 4-hour MTTR, even though the second number looks more impressive on a dashboard. MTTR is genuinely ambiguous (respond vs. remediate vs. recover vs. repair — different teams start the clock at different points) — state where yours starts.
2. Every alert gets a story. What fired, what context attached to it, what was decided, why. Palantir's ADS Framework calls this out: an alert without a "Response" section is a tripwire with no instructions, and an alert without a "Validation" section can't be re-tested by whoever inherits it a year later.
3. Re-test fired-on rules periodically. A rule that fires every day and is treated as noise is a different problem than one that fires every day and is treated as signal — and you can't tell which is which without looking. If the false-positive ratio is genuinely 95%, either the rule is misconfigured for your environment or the underlying behavior has stopped being interesting, and both outcomes deserve a decision, not silence.

The Target case isn't a story about a tool that failed. It's a story about every link in the chain working except the one that mattered — the human step that turned "alert fired" into "we acted." The detection-engineering discipline that takes its own name seriously has to own that step, not assume someone downstream will.

Go Deeper — Free Learning Material

• Missed Alarms and 40 Million Stolen Credit Card Numbers — Bloomberg Businessweek, 13 Mar 2014
• A "Kill Chain" Analysis of the 2013 Target Data Breach — US Senate Commerce Committee, 26 Mar 2014
• One-third of analysts ignore security alerts (IDC/FireEye) — Cybersecurity Dive, Feb 2021
• 2023 State of Threat Detection — Vectra AI / Sapio Research
• Alert Fatigue in Security Operations Centres — ACM Computing Surveys, 2025
• Palantir ADS Framework — False Positives / Blind Spots sections

Day 11 — Every Exclusion Is a Hole

The reflex to a noisy alert is to make it quieter. The hard part is that every lever you pull to make a rule quieter is also a hole an attacker can occupy. Day 10 covered the alert-fatigue end of this — why the queue stops meaning anything when base rates are that skewed. This page is about what you do about it as a detection engineer, and the tradeoff you sign up for every time you act.

Three techniques, with different costs

Allowlists and exceptions. Encode the specific known-benign condition so it stops paging. This is the lever most teams reach for first, and the one with the sharpest edge: every allowlist is teaching the environment to ignore something. A service account that gets allowlisted for "impossible travel" will never trigger on a credential-theft replay that uses that account. A vendor subnetwork carved out for "unusual PowerShell" will never trigger on a compromised vendor appliance doing exactly that.

Threshold and aggregation tuning. "50 failed logons in 5 minutes" instead of "every failed logon." Cheap to ship, easy to defend to leadership, and exactly the rule an adversary who knows your threshold can stay under. An adversary who times their attempts to sit at 40 is invisible — and an adversary who has read your detection documentation is invisible in a more interesting way, because you built the rule around their activity budget.

Enrichment and context. Often the cheapest and most-overlooked lever. Ambiguity is what makes an alert expensive, not raw volume — attaching asset criticality, user role, prior behavior, and a one-line "this looks like X because Y" converts a 20-minute investigation into a 20-second decision. Most teams under-invest in this relative to how much investigation time it would save. It does not reduce the number of alerts. It makes each one cheaper.

If you have to choose which of the three to push hardest, push enrichment. It is the only one that doesn't cut a hole. The allowlist and threshold approaches both subtract coverage; enrichment adds context.

The decision that sits above all three

Tuning is not only choosing between allowlisting, thresholding, and enriching. It is also choosing what to do with the rule itself.

Suppression vs. deletion. Suppression keeps the rule running and the underlying telemetry flowing — it stops known-benign instances from paging you, but you can still go look at the suppressed events when you have a new hypothesis. Deletion removes coverage and the record that you ever had the rule. A year later, nobody remembers the rule existed, the gap it covered, or why.

"Just delete the noisy rule" is wrong. Noise usually means the rule is under-specified for your environment, not that the behavior it watches is uninteresting. Deleting removes detection for the malicious variant along with the benign one, and the team loses both the rule and the institutional memory of what it was protecting.

When in doubt, suppress. Suppression is reversible. Deletion is not.

The tradeoff nobody escapes

Every exclusion is a hole an attacker can occupy. Allowlist a service account and you've taught the environment to ignore that account. Set the threshold at fifty and an adversary who stays at forty is invisible. Tuning is not a path to zero false positives. It is the deliberate purchase of signal at the price of a documented blind spot.

That last sentence is what separates mature detection engineering from the naive version of the job. The naive version is trying to make every alert actionable and every rule clean. The mature version is naming the holes on purpose, in the detection documentation, so a future threat-model exercise knows to factor them back in. The discipline isn't pretending the hole doesn't exist — it's writing it down.

Practically, that means every allowlist, every threshold, every suppression in your environment should be paired with:

• What it excludes — the specific condition, written so a new engineer can read it cold.
• Why it was added — the incident or false-positive pattern that motivated it.
• What would change my mind — the condition under which the exclusion should be revisited (new attack technique observed, suppression volume drifting, environment change).

Palantir's ADS Framework gives every detection a place to record this. The "Response" and "Validation" sections are exactly what this requires — but the same idea works in any detection-document format, and a markdown file is fine for a small team.

The honest version of the job

If you write detections but never look at what happens to them after they fire, you're doing detection theater. Tuning is the loop that closes that gap — not by getting the rule perfect, but by knowing exactly what its imperfections cost.

Three practices that make tuning mature instead of just busywork:

1. Measure the suppression volume, not just the page volume. A rule that produces 100 alerts a day and suppresses 9,900 is doing real work. A rule that produces 1 alert a day and suppresses 9 is probably misconfigured — most of the environment is invisible to it. Both numbers matter; only one shows up on the standard dashboard.
2. Re-test tuned rules periodically. A rule that was tuned for benign behavior X is also a rule that was tuned against malicious behavior Y. If the underlying environment changes — new service account, new vendor, new OS version — the tuning needs to be re-validated, not left alone because it "works."
3. Write the blind spots down somewhere a future you can find them. Every exclusion gets a row. Every threshold gets a "why this number." Every deletion gets a one-line "we deleted this and lost coverage of Z." That document is what makes the next threat-model exercise honest, and what keeps the institutional memory when the engineer who tuned it leaves.

The Target 2013 case (covered in Day 10) wasn't a story about a tool that failed. Day 11's point is that even when the tool works — the detection fires, the alert reaches the right team — the tuning decisions made over the months before determine what that team can actually see. Tuning is the discipline that decides what your environment is blind to. The mature form of the job is being honest about that, in writing, before someone else finds out the hard way.

Go Deeper — Free Learning Material

• Palantir ADS Framework — False Positives / Blind Spots sections
• Alert Fatigue in Security Operations Centres — ACM Computing Surveys, 2025
• Missed Alarms and 40 Million Stolen Credit Card Numbers — Bloomberg Businessweek, 13 Mar 2014 (Day 10 covered the full case; this is the primary source for the alert-handoff details Day 11 builds on)
• A "Kill Chain" Analysis of the 2013 Target Data Breach — US Senate Commerce Committee, 26 Mar 2014

Day 12 — An Untested Detection Is a Guess

A detection rule that has never fired on a real technique execution is a hypothesis, not a control. It encodes assumptions — about the log source, the field name, the parser, the EDR event — and any one of those being wrong produces a rule that looks healthy in the console and never fires when it matters. The hard part is that "looks healthy" and "is silent because nothing is happening" are indistinguishable without deliberately triggering the behavior. Day 8 covered what a detection rule is. Day 9 covered how to write one. Day 12 is the step most beginners skip: how to know the one you wrote actually works.

Why silent failure is the default

A SIEM rule is a query plus a schedule plus a notification path. Every layer in that stack can quietly break in ways the rule's own health check doesn't see. The most common failure modes:

• The log source was never on for the target host. A rule for Sysmon Event ID 1 (process creation) running against a fleet where 30% of endpoints don't have Sysmon installed will simply never fire for those hosts. No error, no alert — just silence.
• The log source was on, but the field was renamed by an upgrade. A rule that matches CommandLine|contains against a field that the parser now writes as process.command_line (a typical ECS/OCSF migration) returns zero results with no indication the field moved. The rule is still "enabled."
• The EDR was replaced or downgraded. New EDR agents emit a different event schema. A rule written against the old agent's event ID now matches nothing.
• The OS or platform changed. A rule against a Windows-specific event fired against a Mac fleet — or the cloud workload it was supposed to cover got migrated to a different OS.

Each of these is recoverable if you know it happened. None of them is visible from the rule's own dashboard. The only reliable test is to execute the behavior the rule is supposed to catch and confirm the alert fires.

The tool: Atomic Red Team, from Red Canary

Atomic Red Team is a free, MIT-licensed library of small, discrete "atomic" tests maintained by Red Canary. Each test exercises a single MITRE ATT&CK technique — PowerShell execution, LSASS access, scheduled task creation, the lot — in a way that's safe to run in a lab environment. The frontend is a single PowerShell command, Invoke-AtomicRedTeam, with a test number you pass in.

PS C:\lab> Invoke-AtomicRedTeam -TestNumbers T1059.001

Executing test T1059.001 (PowerShell)...
  → spawning powershell.exe with encoded command
  → outbound DNS query observed
Test completed successfully.

→ check your SIEM: did the alert fire?

The point of running one of these isn't to do damage — it's to make your detection engineering falsifiable. If the rule is supposed to fire on T1059.001 and the alert doesn't, you've just learned one of three things:

1. The rule is broken (most likely).
2. The rule's log source isn't reaching your SIEM for that host.
3. The rule is firing but going to a different queue or being auto-closed before you see it.

All three are real, all three are easy to misdiagnose from the rule console alone, and all three are only catchable by running the technique and watching what comes through the pipeline end-to-end. This is what "tested" means in detection engineering: the artifact has been observed firing, in this environment, against a real execution of the technique it was written for.

The tool, scaled up: MITRE CALDERA

Atomic Red Team is granular by design — one technique per test, runnable on demand. When you want to chain techniques into a full adversary emulation (initial access → execution → persistence → C2 → exfiltration), you reach for MITRE CALDERA. CALDERA runs an agent on the target host, walks an operation through a sequence of techniques, and reports what it did. v5 of CALDERA shipped in 2024 and is the version to know.

The two tools are not competitors. CALDERA ships with a first-party atomic plugin that takes Atomic Red Team's tests and converts them into CALDERA abilities, so the same library works at both scales: one test for validating a specific rule, a full operation for validating a coverage claim. The mental model is:

• Atomic Red Team = the library. Single-technique, single-test, perfect for the validation step of a single detection.
• CALDERA = the engine. Multi-technique, multi-host, perfect for validating a coverage story — "do our detections for the full T1566 → T1059 → T1071 chain actually fire as a sequence?"

You can build the most detailed rule in the world and have a perfectly clean rule console. You can have 1,000 rules covering the entire ATT&CK matrix, all green in your heat map. None of that tells you whether any of them work until you run the technique. The library-and-engine pair is the practical answer.

The vocabulary point: purple team is not a third team

When you hear "purple team," the natural mental model is three teams: red, blue, purple. That's not what it means. Purple team is a working mode, not a separate group — the offense and defense running the exercise together, in the open, in real time, with the blue side able to check telemetry and tweak rules as the red side executes.

The distinction matters because the output is different:

• Red team engagement: covert, objective-driven, blue usually doesn't know it's happening. Deliverable is a report weeks later with findings — "you didn't detect X." The blue team learns from the report, then has to go fix things.
• Purple team exercise: in the open, planned technique-by-technique. Red announces the technique, blue checks telemetry in real time, blue either confirms the detection fired or fixes it and re-runs in the same session. The deliverable is a working detection, not a report.

Concretely: a red team tells you six months later that your detection for T1071.004 (DNS-based C2) is broken. You re-run the test, find out the field name changed, fix the rule, deploy, and discover you now have two months of backlog to look at. A purple team walks through the same T1071.004 with you in real time, the rule fires, you confirm it, and you move on. The first is a finding; the second is a detection. Same technique, same rule, completely different outcomes.

The most-cited formalization of this working pattern is SCYTHE's Purple Team Exercise Framework (PTEF) — worth reading once even if you don't adopt it, just to make the structure of a purple exercise explicit.

Validation in CI: the strong version

For teams mature enough to run CI on their detection rules (Day 14 will go deeper on detection-as-code), the validation step can be automated rather than run by hand. The shape of a working pipeline is:

1. Lint and validate the rule's schema (Sigma syntax, KQL parse, whatever the target SIEM expects).
2. Translate it — Sigma to Splunk SPL or KQL or Lucene via sigma-cli / pySigma.
3. Test it against fixtures — at minimum, one log event the rule must match (positive case) and one benign event it must not (negative case). A rule that ships without both fixtures fails CI.
4. Replay it against a real execution when possible — the most advanced pattern runs the corresponding Atomic Red Team test in a lab and asserts the rule fired. Regression testing against real technique execution, not static sample logs.

Elastic's public detection-rules repo is the most inspectable real-world example of this — the rules Elastic ships are TOML, validated by a Python test suite, and the most mature of them include both fixture-based tests and explicit "this rule should fire when Atomic Red Team test X runs" checks. Reading that repo's tests/ directory once is a fast way to internalize what mature detection validation looks like.

The takeaway

Counting rules is a vanity metric. "We have 900 detections" and "we have 900 detections each proven to fire on a real execution of their technique, in this environment, within acceptable latency, at a false-positive rate the SOC can absorb" are wildly different claims. Only the second is a control. The gap between the two is what Day 12 exists to close.

If you take one thing from this day, it is this: a detection rule is a hypothesis until you have run the technique it was written for, watched the alert fire, and documented the result. Until then, the silent rule looks exactly like a rule with nothing to catch. The discipline isn't writing more rules — it's proving the ones you have work.

Go Deeper — Free Learning Material

• Atomic Red Team — Red Canary (GitHub, MIT)
• MITRE CALDERA (GitHub)
• MITRE atomic plugin for CALDERA
• Purple Team Exercise Framework (PTEF) — SCYTHE
• elastic/detection-rules (GitHub) — public example of detection-as-code with both fixture-based and Atomic-Red-Team-based validation
• The Engineer's Guide to Elastic Detections as Code — Elastic Security Labs
• Comparing open source attack simulation platforms — Red Canary

Day 13 — Are You Actually Covered?

A colored-in ATT&CK matrix feels like proof. It isn't. A Navigator layer where a technique is green because one rule nominally mentions it looks identical to one green because of a tested, high-fidelity, well-tuned analytic. Day 12 covered how to test a single detection. Day 13 is the harder question: how do you know your whole program is actually covered, not just colored in?

Coverage is three questions, not one

Most teams treat "coverage" as a single yes/no per technique. It's really three separate, stackable questions:

1. Do you collect the telemetry? Is the log even generated, from every host, with the right fields?
2. Do you have a detection built on top of it? A rule, a query, an analytic — something that fires.
3. Is that detection any good? Does it actually distinguish the attack from normal activity, or is it either noisy or blind?

Collapsing all three into one color is the mistake. You can pass question 1 and completely fail question 2 or 3, and a flat heat map will never show you the difference.

The heat-map pitfall, concretely

Map every PowerShell execution to technique T1059.001 and that cell turns green. In most real environments, the overwhelming majority of PowerShell activity is legitimate admin work — scheduled tasks, config management, routine scripting. So a rule that fires on "PowerShell ran" is either:

• Drowning in false positives (if it's left loose enough to actually catch the technique), or
• Tuned so aggressively it catches nothing (if it's been narrowed to survive triage).

Either way, the cell is green. Color hides which failure mode you're in — and it hides breadth-within-a-cell too: a rule catching one of a technique's several sub-techniques renders identically to one catching all of them.

The tools that actually separate these questions

ATT&CK Navigator (MITRE) renders the matrix and lets you color, score, comment on, and filter techniques, exporting the result as a JSON "layer." It's deliberately opinion-free — it doesn't know what your scores mean, it just draws what you tell it. Its most genuinely useful feature is calculated layers: expressions like a - b, where a is a threat actor's known technique layer and b is your own detection layer. The output is a map of exactly what that actor does that you cannot catch — a much sharper question than "are we green."

DeTT&CT (built by Marcus Bakker and Ruben Bouman, supported by Rabobank, the CSSA, and the Dutch National Police) adds the rigor Navigator deliberately leaves out. You describe your environment in YAML — data sources and their quality, visibility per technique, and detections per technique — and each of those gets scored separately. The core idea: visibility and detection are different scales. You can have perfect logging and zero detection on top of it, and DeTT&CT shows that as two distinct colors instead of collapsing it into one.

Summiting the Pyramid (MITRE's Center for Threat-Informed Defense) goes after the third question — quality — directly. It scores an individual analytic on robustness: whether it keys on something structural to how the technique works, which an adversary can't change without abandoning the technique, or on something trivially altered — a filename, a hash. SigmaHQ has adopted an STP flag so open-source rules carry this score visibly.

VECTR (Security Risk Advisors) tracks purple team campaign results over time — per-technique outcomes (observed / not detected / alerted) — so coverage claims are backed by actual test history instead of self-assessment.

What's contested here

There is no industry-standard scoring scale. DeTT&CT's 0–5 visibility/detection scale is that project's own convention, not a universal standard, and organizations redefine it routinely. What counts as "covered" is genuinely disputed too: some teams require a firing alert, others accept queryable telemetry a hunter could search. Whether to score the entire matrix or a threat-model-scoped subset is an open disagreement — though scoping to techniques your actual threat model cares about is the more defensible position for most teams.

The takeaway

Good coverage analysis does four things: scopes to techniques your real threat model cares about rather than the whole matrix, scores visibility and detection separately, tests each claimed detection by actually executing the behavior and confirming the alert fired, and scores robustness rather than mere existence. The vanity-metric version of coverage is any number that was never validated by running the technique — "% of the matrix that's green," "number of rules deployed," "100% ATT&CK coverage." The only coverage number worth anything is the one where you ran the attack yourself and watched the alert fire — which is exactly what Day 12's testing discipline exists to produce, technique by technique.

Go Deeper — Free Learning Material

• DeTT&CT — rabobank-cdc/DeTTECT (GitHub)
• DeTT&CT Wiki
• ATT&CK Navigator — usage docs
• ATT&CK Navigator (live tool)
• Summiting the Pyramid — Center for Threat-Informed Defense
• Summiting the Pyramid documentation
• DeTT&CT: Mapping detection to MITRE ATT&CK — NVISO Labs
• You Can't Detect What You Can't See — SANS

Day 14 — Detections Are Software

A detection rule typed into a SIEM console has no diff history. You see the rule as it is today, not why it became that. No peer review before it shipped, no test proving it still matches the behavior it was written for, no clean rollback when a tuning change quietly breaks it, and no portability out of that one vendor's console. When the engineer who wrote it leaves, the reasoning leaves with them. Detection-as-code (DaC) is the fix: manage detection logic the way software teams manage application code.

What detection-as-code actually is

Rules live in Git as structured text — YAML, TOML, JSON, or Python, depending on the tooling. Changes arrive as pull requests. CI validates automatically before anything merges: does the query actually parse, does it reference fields that exist in the mapped schema, is the ATT&CK metadata complete and tagged correctly. A pipeline then deploys the rule to the SIEM or EDR rather than an analyst typing it straight into a console.

A typical pipeline looks like: branch → write the rule plus metadata (an "Alerting and Detection Strategy" style write-up is one common format) → local lint and unit test → pull request with a required reviewer → CI runs syntax validation, schema and field checks, metadata completeness, and positive/negative fixture tests → merge → auto-deploy to a staging or "alert-only" tier that fires into a shadow queue → promote to production → the rule's own alert volume and true-positive rate feed back into the next tuning decision.

A real, public example

elastic/detection-rules is the actual repository Elastic's own threat research team uses, public since 2020. Rules are written in TOML. A Python CLI runs unit tests locally before a PR is even opened. CI validates KQL/EQL syntax, checks that referenced schema fields exist, confirms ATT&CK metadata, and checks tagging — all before a rule merges. Elastic later productized this workflow for customers: alpha in May 2024, beta in August 2024, general availability with Elastic Security 8.18+ during 2025, with Terraform resources added late 2025.

It isn't the only real example. SigmaHQ/sigma and SigmaHQ/pySigma are the clearest working demonstration that detection logic can exist as an artifact separate from any single SIEM. Snowflake's own "Detection Development Lifecycle" write-up (Snowflake Builders Blog, Haider Dost) documents six phases — requirements, design, development, testing/deployment, monitoring, continuous testing — though it's worth noting their earlier open-source SnowAlert project is now explicitly deprecated, with its own README pointing users to Snowflake's native alerts instead. Panther (detections written as Python functions in a repo) and Anvilogic are commercial platforms built on the same underlying idea.

The honest cost

This is not free, and the cost lands up front. Engineers who came up through triage often lack Git, CI, and Python fluency, and building the test harness itself is real software engineering work that produces zero new detections while it's being built. The hardest part is test fidelity: proving a rule parses correctly is cheap, but proving it still catches the technique it was written for requires realistic event samples that most teams don't actually maintain. Several vendor consoles also lack good deployment APIs, which makes the continuous-deployment half of the pipeline brittle glue code rather than a clean integration.

For a two-person team running thirty rules, this pipeline can genuinely cost more than it returns. The honest trigger for adopting detection-as-code isn't a headcount threshold — it's when rule count, reviewer disagreement, or unexplained tuning changes start causing real, measurable losses. Below that point, the overhead of Git discipline and CI maintenance can outweigh what it buys you.

What's contested here

How much testing is "enough" is genuinely unsettled across the industry — some teams stop at syntax and schema validation, others require a full adversary-emulation replay per rule before it ships. Whether the SIEM console or the Git repository is the actual source of truth is also contested: Elastic's own detection-as-code documentation explicitly discusses bidirectional sync, because plenty of teams still want analysts able to edit rules directly in Kibana without breaking the pipeline's authority over what's "real."

The takeaway

Detection-as-code doesn't make detections better on its own — a badly written rule tested by CI is still a badly written rule. What it buys is accountability and continuity: a diff history that survives the person who wrote it, a review step before a change ships, a rollback when tuning goes wrong, and a rule that's portable instead of trapped in one console. Whether that's worth building depends entirely on whether your team has actually started losing time or signal to the problems it solves — not on whether it sounds like the more "grown-up" way to run things.

Go Deeper — Free Learning Material

• elastic/detection-rules (GitHub)
• The Engineer's Guide to Elastic Detections as Code
• DaC Reference documentation
• Palantir — Alerting and Detection Strategy Framework (blog, Apr 2019)
• SigmaHQ/sigma (GitHub)
• SigmaHQ/pySigma (GitHub)
• Snowflake — Detection Development Lifecycle
• snowflakedb/SnowAlert — deprecated (GitHub)

Day 15 — The Tool That Does the Boring Half

SOAR — Security Orchestration, Automation and Response — connects the systems a SOC already uses (SIEM, EDR, identity provider, ticketing, mail gateway, threat intel) and runs multi-step workflows across them. A playbook is that workflow: a defined sequence triggered by an alert, where each step calls an API and branches on the result. A phishing playbook, for example, might detonate the attachment, look up the sending domain, search mail logs for everyone else who received it, and post a summary — waiting for a human to click approve before it touches a single inbox.

The vendor landscape, verified

• Splunk SOAR — originally Phantom, acquired by Splunk in 2018. Splunk itself is now owned by Cisco (acquisition completed 18 March 2024, roughly $28B). Splunk SOAR still ships and is actively integrated; no EOL has been announced.
• Cortex XSOAR — originally Demisto, acquired by Palo Alto Networks for $560M, completed March 2019, reaching general availability as Cortex XSOAR in March 2020. Still shipping with a large public content library, though Palo Alto's strategic push since 2022 has shifted toward Cortex XSIAM — still sold and widely deployed, but no longer where the vendor's roadmap energy sits.
• Microsoft Sentinel splits the concept in two: automation rules are the lightweight layer (tag, assign, close, chain playbooks), while playbooks themselves are Azure Logic Apps, so automation is billed as Logic Apps consumption. Worth flagging: after 31 March 2027, Sentinel will no longer be supported in the Azure portal, moving to the Defender portal.
• Tines (Dublin, founded 2018) offers a no-code workflow builder aimed at the same problem space.
• Torq (founded 2020) positions itself as "hyperautomation" and an AI SOC platform, explicitly marketing against the SOAR label.

How automated actions actually sort by risk

The useful way to think about SOAR isn't "what can it automate" — it's "what should it automate," and that sorts cleanly by blast radius.

Low risk, safe to fully automate: enriching an IP, domain, or file hash against threat intel; pulling a user's manager and department; gathering recent process events; opening a ticket; deduplicating; posting a summary to a channel. These are read-only or additive — the worst case is a wasted API call.

Medium risk: forcing a password reset, expiring sessions, requiring step-up MFA, quarantining an email, blocking a domain at the proxy. Recoverable, but it interrupts someone's day.

High risk, usually gated: isolating a host, disabling an account, revoking all tokens, blocking an IP at the perimeter, killing a process, shutting down an instance. The failure mode here is the automation itself causing the outage — a false positive that isolates a domain controller, disables a service account half the estate authenticates against, or firewalls off the corporate egress IP because a feed flagged it.

The human-in-the-loop line generally falls between medium and high risk, and it moves with confidence and scope. Teams commonly fully automate the enrichment tier plus containment on narrow, high-confidence cases — a laptop with confirmed ransomware canary activity at 3am, say. What stays gated is anything touching a server, a shared account, or a large blast radius, and anything from a rule with a known false-positive history. The practical pattern: the playbook runs every enrichment step automatically, presents a decision with the evidence already attached, and waits for an approve click before the destructive step.

What's contested here

Gartner's Market Guide for SOAR has described the space as remaining "a relatively niche market" that is "being consumed into other markets such as SIEM, XDR and MDR." Read that precisely: SOAR products still exist and are still sold. What's faded is SOAR as a standalone buying category — the capability increasingly ships bundled into SIEM/XDR platforms, or gets reframed by newer entrants as "hyperautomation" or "AI SOC."

The takeaway

SOAR is a robot that does the boring half of incident response. A playbook fires, and before you've even opened the ticket it's looked up the IP, pulled the user's details, checked who else got the same email, and posted a summary. Notice what it did and didn't do: looking things up is fully automatic, nothing can go wrong. Isolating a machine or disabling an account waits for a human, because a false positive there doesn't just waste your time — it takes production down.

Go Deeper — Free Learning Material

• Cisco Completes Acquisition of Splunk — 18 Mar 2024
• Palo Alto Networks Completes Acquisition of Demisto (2019)
• Palo Alto Networks Introduces Cortex XSOAR (2020)
• Automate threat response with playbooks in Microsoft Sentinel — Microsoft Learn
• Automate incident handling with automation rules — Microsoft Learn
• About Torq — company page

Day 16 — The Number Nobody Agrees On

Detection and response teams report a handful of core operational metrics — but precision about what each one actually measures matters more than the acronym. Dwell time is the cleanest of them: how long an attacker was present in an environment before discovery, measured from their first foothold to the moment someone finds them. MTTD (mean time to detect) is close but distinct — it runs from when malicious activity begins, or first appears in telemetry, to when it's flagged, and even here the start point is ambiguous: some teams measure from first log evidence, others reconstruct the initial compromise afterward, which is only knowable retroactively.

MTTR is where the trouble starts. The acronym expands to at least four genuinely different things: mean time to respond (detection to first analyst action), to remediate (detection to threat neutralized), to recover (incident to business-as-normal), and — in reliability engineering — to repair. Cyberhaven, Contrast Security, Palo Alto Networks, and Tenable each define MTTR differently in their own glossaries, which is itself the evidence that no single definition holds industry-wide. Two organizations can both report "MTTR: 4 hours" and be measuring completely different intervals; definitional choice alone can swing the reported figure two- to three-fold. Any team citing MTTR should state which variant it means and exactly where the clock starts and stops — without that, the number is close to meaningless as a comparison point.

The benchmark that actually holds up

Mandiant's M-Trends 2026 report (covering 2025 incident-response engagements, based on 500,000+ hours of frontline work) put the global median dwell time at 14 days — up from 11 days in M-Trends 2025 (covering 2024), which itself was up slightly from 10 in 2023. Mandiant attributes the rise to long-dwell cyber-espionage and North Korean IT-worker operations, both carrying a median dwell of 122 days. Notably, internal detection capability actually improved over the same period — organizations found intrusions themselves 52% of the time in 2025, up from 43% the year before — while externally-notified cases, which tend to run longer before discovery, dragged the overall median upward.

For context on how far this metric has traveled: dwell time was measured in the hundreds of days in Mandiant's earliest reports (400+ in the 2011–2012 era). Richard Bejtlich, who popularized dwell time as a metric at Mandiant, publicly flagged the 11-to-14-day move as a genuine deterioration rather than noise — a useful corrective against reading the metric's long-run decline as inevitable, one-way progress.

Three documented reasons speed-only metrics mislead

1. Gameable. Closing tickets faster hits the target number while quietly degrading resolution quality — the metric improves without the underlying problem actually getting fixed.
2. Unweighted by risk. A fast average across a flood of low-severity alerts can hide a genuinely slow response on the one incident that mattered. MTTR on critical assets specifically is the meaningful cut; an aggregate MTTR across everything is not.
3. It measures failure efficiency, not prevention. Speed metrics track how good a team has become at cleaning up after something already went wrong — not how well they prevented or caught it in the first place. A consistently improving trendline can manufacture false confidence about a program's actual maturity.

Better metrics than speed alone

The research consistently points toward a different set of signals: per-rule detection efficacy and precision; coverage mapped to ATT&CK with tested validation, not merely claimed; rules that ship with a documented true-positive test case (Palantir's Alerting & Detection Strategy framework requires exactly this); time-to-deploy a new detection once relevant intel lands; detection rule health and failure rate (rules silently broken by an upstream log-source change); and — arguably the single most honest maturity signal available — the distribution of how incidents were actually found: automated detection, internal report, or external notification. That last one is precisely what M-Trends measures with its internal-versus-external split, and it's a harder number to quietly redefine than MTTR.

What's genuinely contested

MTTR's four-way expansion is disputed territory, not a settled question with one right answer — teams and vendors use different variants without always saying so. Where the MTTD clock starts is similarly ambiguous and often unknowable in real time. Whether coverage percentages mean anything at all is also contested: several practitioners argue an ATT&CK heat map is a communication tool, not a measurement instrument. And there is currently no industry-standard benchmark for what counts as a "good" alert volume or false-positive rate — any number presented as such should be treated skeptically.

The takeaway

Mandiant tracks one number every year that means the same thing regardless of who's reporting it: how long an attacker sits inside an environment before anyone notices. In 2026's report, covering 2025, that global median was 14 days — up from 11 the year before. MTTR doesn't have that property. Before quoting it in a report, state exactly which clock it is and where it starts — otherwise the number is decoration, not evidence.

Go Deeper — Free Learning Material

• M-Trends 2026 — Google Cloud / Mandiant
• M-Trends 2025 — Google Cloud / Mandiant
• Mandiant Global Median Dwell Time Deteriorates from 11 to 14 Days — Richard Bejtlich, TaoSecurity
• What Is MTTR in Cybersecurity? — DeepStrike
• MTTR Is a Vanity Metric — NeuBird
• Palantir Alerting & Detection Strategy (ADS) Framework
• What is Detection Rule Efficacy? — Zack Allen, Detection Engineering Field Manual

Day 17 — When Detection Isn't Enough

Detection tells you an alert fired. It doesn't tell you what to do next — and the instinct most people reach for first, unplugging or shutting down the machine, is usually the wrong move. Digital forensics is the discipline that governs what happens after detection: how to collect evidence without destroying it, and how to do it in a way that survives being questioned later.

Collect what disappears fastest first

RFC 3227, "Guidelines for Evidence Collection and Archiving" (Brezinski & Killalea, February 2002, published as BCP 55), lays out the practical order first responders should follow — order of volatility. Registers and CPU cache vanish in nanoseconds if the machine's state changes. RAM disappears the instant the system reboots or loses power. Temporary filesystems go next, then the disk itself, which sticks around far longer, then remote logs and monitoring data already sitting elsewhere, then physical network configuration, and finally archival media — the most durable of all. The rule of thumb: collect the most fragile evidence first, before it's overwritten or lost.

This is also why RFC 3227 is explicit that you should never shut a system down before capturing volatile evidence. Some attackers booby-trap shutdown scripts specifically to destroy evidence or trigger further damage on power-off, and a clean reboot alone destroys everything that was only ever resident in memory — including data that exists nowhere on disk.

What a memory capture actually recovers

A memory image (RAM dump) preserves the live, volatile state of a system at the moment of capture. Analysts image RAM with tools like WinPmem, then parse the raw dump with an analysis framework — almost always Volatility 3 today (a full Python 3 rewrite of the original Volatility 2). Its historical alternative, Rekall, has largely wound down as an actively maintained project, with most of that work folding back into the Volatility ecosystem.

From a memory image, investigators can genuinely recover: running processes and process trees, including ones hidden or already terminated by the time an alert fired; network connections active at capture time, which can reveal a command-and-control channel already closed before anyone noticed; injected or unpacked malicious code invisible to file-based antivirus (process hollowing, reflective DLL injection); and — sometimes — credentials, session keys, or decrypted copies of otherwise-encrypted data resident in memory, including a ransomware decryption key if the process holding it is still running. None of this is guaranteed, and interpreting a raw memory dump correctly takes real OS-internals knowledge — it isn't a run-one-command-get-answers process.

Copying the disk without changing it

Once volatile evidence is captured, the disk itself needs to be imaged — and a forensic image is fundamentally different from a normal backup. It's a bit-for-bit copy of the entire device, including unallocated space, file slack, and deleted-but-not-overwritten data, which is exactly why forensic images can recover files a regular backup would never see. A write blocker sits between the forensic workstation and the source drive, permitting reads while physically or logically blocking any write, so the source media is never altered during acquisition. Integrity is then proven by hashing the drive before and after imaging (MD5, SHA-1, or SHA-256) — matching hashes prove the copy is identical to the original.

The paper trail matters as much as the technical findings

Chain of custody is the continuous, documented record of everyone who collected, handled, transferred, or analyzed a piece of digital evidence, and when. The governing international standard, ISO/IEC 27037, defines four core processes — identification, collection, acquisition, preservation — under three principles: auditability, repeatability, reproducibility. In the U.S., NIST SP 800-86 complements this with a four-phase model (collection, examination, analysis, reporting) that requires reporting to be detailed enough for another examiner to reproduce the results independently.

Digital evidence is trivially alterable, and courts need assurance that what's presented at trial is the same, unmodified thing originally seized. Every handoff gets logged and hashed. A gap in that log, evidence left unsecured even briefly, or an undocumented alteration — any of it can let opposing counsel argue the evidence's integrity can't be verified, which can get it excluded outright, regardless of how sound the underlying technical work was.

Putting it together: timeline analysis

Once evidence is safely collected, the actual investigative work is largely about correlating timestamps across sources — filesystem metadata, event logs, registry keys, browser history — into one chronological view of what an attacker actually did. The dominant open-source tool is Plaso (its log2timeline.py engine), which builds what practitioners call a "super timeline" from dozens of artifact types at once, so an analyst can watch the attack unfold step by step instead of viewing each artifact in isolation.

What's genuinely contested

ISO/IEC 27037 and NIST SP 800-86 aren't legally mandatory in most jurisdictions — courts increasingly treat them as benchmarks for judging whether a process was sound, but specific procedural requirements vary by organization and jurisdiction. RFC 3227 is nearly 24 years old and predates cloud workloads, containers, and full-disk encryption; most training still teaches its ordering close to verbatim, but organizations adapt the exact sequence to their environment. And whether a hardware write blocker is strictly required, versus a software one being acceptable, varies by lab policy and device type.

Go Deeper — Free Learning Material

• RFC 3227 official text (RFC Editor)
• ISO/IEC 27037 overview
• Volatility 3 documentation — plugins.windows
• SWGDE — Best Practices for Computer Forensic Acquisitions (17-F-002)
• Plaso official docs
• CyberDefenders — "How Does Memory Forensics Work?"

Day 18 — Analyst vs Engineer

Two job titles sit next to each other in almost every detection-and-response team: SOC analyst and detection engineer. They sound like they should be doing the same thing. They aren't.

One operates the queue. One builds what fills it.

The split is the simplest way to understand the discipline. A SOC analyst works the alert queue — every shift, they open whatever the rules have produced and decide what it means, what to escalate, and what to close. A detection engineer builds the rules that produced those alerts in the first place. The analyst consumes what the engineer produces. That's the whole difference: one operates, one builds.

The work isn't symmetric. The analyst's day is reactive — measured in triage throughput and accuracy against whatever the queue happens to surface. The engineer's day is proactive — reading threat intel reports, post-mortems from incidents the team just cleaned up, MITRE ATT&CK technique pages, and turning each into detection logic that catches the same thing again next time, in version control, tested like software.

Why this became its own discipline

The split isn't invented for tidy org charts. It's the result of detection work repeatedly failing to scale as a side task of SOC analysts. Anton Chuvakin (Google Cloud Security, formerly Gartner, the analyst who has spent more than a decade naming this corner of security) writes that detection engineering emerged precisely because reactive, hand-written SIEM queries after each incident didn't scale. No version control. No testing. No quality bar. Every rule lived in someone's head; when they left, the reasoning left with them.

Chuvakin defines the discipline as building, refining, and managing detection content — explicitly describing it as a relatively new one. That framing matters because it positions detection work as engineering practice, the same way platform teams or SRE teams treat their code: rules in Git, peer-reviewed in pull requests, tested in CI/CD, deployed through pipelines, with portable formats like Sigma (logs) and YARA (files) and platform-as-code tools like Terraform for the surrounding infrastructure.

The closest thing to a formal reference for the discipline isn't a NIST standard — there isn't one, and that's worth saying plainly. It's community artifacts: Elastic's Detection Engineering and Behavioral Analysis Maturity Model (DEBMM), which formalizes five tiers of detection practice; Kyle Bailey's Detection Engineering Maturity Matrix on GitHub; Palantir's Alerting and Detection Strategy (ADS) framework. None of these are standards bodies, but they are the shared language the discipline has converged on.

The four adjacent roles people confuse with it

Most postings and most teams draw these lines differently. The honest caveat is that the boundaries are inconsistent across the industry — say that upfront rather than smoothing it over.

• SOC analyst. Works the queue. Consumes what a detection engineer produces. Reactive by design, measured on triage throughput and accuracy. This is the role most detection engineers come from first.
• Threat hunter. Starts from a hypothesis and searches proactively without waiting for an alert. A successful hunt finding a repeatable pattern usually ends with a detection rule — which is detection engineering work. Many teams combine hunting and detection engineering into one role.
• Incident responder. Takes over once something is confirmed: containment, eradication, forensics, recovery. Detection engineering feeds IR and consumes IR's lessons (post-mortems become detection ideas), but it is not the same job.
• Security engineer. Builds and runs the broader security infrastructure — IAM, network controls, vulnerability management. A detection engineer is a security engineer specialized on detective controls, and is often dependent on the broader team for the telemetry plumbing those controls need.

Why the title doesn't mean what you think it does

Read any two job postings for "detection engineer" and you will likely see overlapping but different work. Adjacent titles — threat detection engineer, SIEM engineer, detection and response engineer, Tier 3 SOC analyst — describe overlapping work, sometimes identical work. At a small company one person is analyst, hunter, detection engineer, and responder simultaneously. At a large company they're separate teams with formal handoffs. The title has not solidified the way, say, "software engineer" or "data engineer" have. There is no equivalent of NIST SP 800-61 defining it.

Two practical consequences. First, when you're comparing offers or reading a posting, read the responsibilities, not the title. Does the role actually involve writing rules in a SIEM, EDR, or cloud platform? Or is it primarily queue triage with "detection" in the title as a recruiting hook? Same word, very different jobs.

Second, when you're trying to hire, the title instability makes job descriptions the load-bearing artifact. Specify what tools the person will work in (Splunk, Sentinel, Elastic, Chronicle, an EDR, a cloud-native platform), what the day-to-day looks like (rule authoring, validation, tuning, pipeline), and what the on-call expectation is. Candidates can self-select against the actual job that way; titles alone won't do it.

Career paths in

The most common path is SOC analyst Tier 1 → Tier 2 → Tier 3, where Tier 3 typically branches into either threat hunting or detection engineering after roughly four to six years in operations. Both adjacent fields are realistic on-ramps: incident responders who already know what attacker behavior looks like in logs often move into detection engineering because they understand the consumer's needs; software or platform engineers moving the other direction bring pipeline, testing, and code-review instincts they can apply to detections-as-code (see Day 14). Both halves are learnable from either direction, and the discipline is healthier when both directions exist on a team.

The recurring asks across real postings converge on a consistent skills core even while the titles differ: SIEM query languages (Splunk SPL, KQL, Sigma), ATT&CK fluency and the ability to turn raw intel into detection logic, Python (often PowerShell on Windows-heavy teams), Git and CI/CD workflow, Sigma and YARA authoring, cloud detection experience on at least one of AWS / Azure / GCP, and typically three or more years in security operations. None of those is a hard prerequisite on day one, but together they describe what a strong detection engineer looks like once they've been in the role for a year.

Go deeper

• Detection Engineering is Painful — and It Shouldn't Be (Part 1) — Anton Chuvakin — the origin essay for the modern framing of the discipline.
• Detection Engineering and SOC Scalability Challenges (Part 2) — Anton Chuvakin — the follow-up on why queue work couldn't keep absorbing detection authoring as a side task.
• Elastic releases the DEBMM — Elastic Security Labs — the five-tier maturity model that formalizes detection practice as engineering work.
• Detection Engineering Maturity Matrix — Kyle Bailey (GitHub) — the community-side reference for what each tier looks like in practice.
• awesome-detection-engineering — infosecB (GitHub) — a curated index of tools, frameworks, and reading for the discipline.
• SOC Roles and Responsibilities — Palo Alto Networks Cyberpedia — one vendor's take on how the SOC's analyst/hunter/engineer/responder split is usually drawn.

Day 19 — Series Recap — The Whole DART Pipeline

Nineteen days ago you knew nothing about this. Now you have seen the whole thing. This is Day 19 of becoming a DART engineer — the full pipeline, one frame at a time.

One frame at a time, 19 days

The series started with a question: what does someone actually need to know to work in detection and response engineering — not as a list of tools, but as a discipline?

Eighteen days later, the answer is a pipeline. Five phases, each one building on the last.

Phase 1 — The tools

Detection starts before detection. You need somewhere to see events and something to act on them.

A SIEM (Security Information and Event Management system) collects logs from across your entire environment and correlates them — turns raw event noise into something searchable and contextual. An EDR (Endpoint Detection and Response agent) watches one machine at a time, records everything that happens on it, and can take action — isolate, block, contain — without waiting for a human. Alert triage decides which of the resulting alerts actually matter.

The foundational constraint: you cannot detect what you do not collect. The events that matter most do not exist by default. Process creation logging on Windows, for example, requires Sysmon Event ID 1 — it is off by default on most systems. Telemetry is a deliberate engineering decision, not a default state.

Phase 2 — Detection and response

With telemetry in place, you build the logic that acts on it.

MITRE ATT&CK gives every attack technique one name that every team — red, blue, or threat intel — can agree on. It is not a tool; it is a shared taxonomy. Sigma is the rule format that says "tell me when this happens" in a way that is SIEM-agnostic — written once, translated into Splunk SPL, KQL, or Chronicle rules.

The step most beginners skip: you do not write a Sigma rule until you know your telemetry actually contains what the rule needs to see. Atomic Red Team runs the simulated attack and proves whether your detection fires. Testing is not optional — it is the validation that closes the gap between "I wrote a rule" and "I caught the attack."

Tuning is not about zero noise. It is about buying signal at the price of a documented gap. Every tuning decision is a written record of what you chose not to detect and why.

Phase 3 — Operations and beyond

Detection is only the beginning of the response.

SOAR (Security Orchestration, Automation and Response) handles the steps a machine can do safely and repeatably — block an IP, update a blocklist, open a ticket, enrich an alert from a threat intel feed — so that humans focus on the ones that need judgment. Automation is not replacing analysts; it is removing the work that drowns them.

The metrics that matter — mean time to detect (MTTD) and mean time to respond (MTTR) — are also the ones nobody agrees on. Both definitions vary across organizations. You must define where your clock starts, or you are comparing nothing.

When detection is not enough, forensics takes over. Memory, disk, order of volatility (collect the most volatile evidence first), chain of custody (document every step). The alert got you there. Investigation tells you what happened.

The discipline

From tools to telemetry to detection to operations to investigation. You did not just learn a job. You learned a whole discipline — the kind where the rules you write are software, the team you build is a practice, and the incidents you catch are the proof it works.

Detection engineering is not a job title with a fixed definition. The field is still defining itself — community frameworks like Elastic's DEBMM (Detection Engineering and Behavioral Analysis Maturity Model), Palantir's Alerting and Detection Strategy framework, and Kyle Bailey's Detection Engineering Maturity Matrix are the reference points, not a NIST standard. That ambiguity is also the opportunity: there is no ceiling on what good detection engineering practice looks like.

Go deeper

The full written companion for the series — every concept, every framework, every source — is on this site. The 18 concept pages are the extended version of everything covered across the video series.

For the discipline-level reading list:

• Detection Engineering is Painful — and It Shouldn't Be — Anton Chuvakin — the essay that named the discipline.
• Elastic DEBMM — Elastic Security Labs — the five-tier maturity model formalizing detection practice as engineering work.
• awesome-detection-engineering — infosecB (GitHub) — the community-curated index of tools, frameworks, Sigma rules, and reading.
• Detection Engineering Maturity Matrix — Kyle Bailey (GitHub) — the practitioner-side reference for what each maturity tier looks like in practice.
• Palantir Alerting and Detection Strategy Framework — Palantir GitHub — the ADS framework that treats detection rules as software engineering artifacts.