Detection Engineering

#What Is Detection Engineering?

A SOC analyst responds to alerts. A detection engineer creates and improves the alerts. The job is software engineering applied to threat detection: you write detection logic as code, test it, version-control it, measure its quality, and retire it when it stops earning its keep.

The mental shift that separates a detection engineer from a tool operator: you don't ask "what does my SIEM alert on?" — you ask "what attacker behavior do I want to catch, what evidence does it leave, and how do I write logic that fires on that evidence without drowning in false positives?"

#Why It Matters

#The Detection Engineering Lifecycle

A detection is not write-once. It moves through a repeatable lifecycle, just like a software feature.

 1. HYPOTHESIZE   "Attackers using technique X leave evidence Y in log source Z."
        │
 2. RESEARCH      Find the data source. Confirm Y actually appears in Z.
        │         Generate the behavior in a lab (Atomic Red Team).
        │
 3. BUILD         Write the detection logic (Sigma/SPL/KQL/YARA-L).
        │         Define severity, ATT&CK mapping, and response runbook.
        │
 4. TEST          Run against (a) known-malicious data → does it fire?
        │                     (b) 30 days of production data → how noisy is it?
        │
 5. TUNE          Add exclusions for known-good. Adjust thresholds.
        │         Target a true-positive rate you can live with.
        │
 6. DEPLOY        Ship as code (PR review, CI validation). Document it.
        │
 7. MONITOR       Track fire rate, TP/FP ratio, and analyst feedback.
        │
 8. RETIRE        If the log source dies, the threat is gone, or a better
                  detection supersedes it — remove it. Dead rules are debt.

Interview signalwhen handed a detection idea, walk through this loop out loud. Don't jump straight to "I'd write a rule" — name the hypothesis, the data source, how you'd test for noise, and how you'd tune.

#Detection-as-Code

Modern detection teams treat detections like application code:

Platforms built around this model: Panther (Python detections-as-code), Matano (open-source, OCSF-native), Sigma + converters, Elastic detection rules (YAML in Git), Chronicle/Google SecOps (YARA-L rules in repos).

# Example: a Panther-style detection (Python). The `rule` function returns
# True when the event is suspicious. This is testable like any unit.
def rule(event):
    # Hypothesis: AWS root account usage is rare and high-risk.
    return (
        event.get("userIdentity", {}).get("type") == "Root"
        and event.get("eventName") not in ALLOWED_ROOT_EVENTS  # tuned exclusion
    )

def title(event):  # the alert headline analysts see
    return f"AWS Root activity: {event.get('eventName')} from {event.get('sourceIPAddress')}"

def severity(event):
    return "HIGH"

#Detection Rule Languages

You will be expected to read — and ideally write — at least one of these. Know the shape of each; you can look up exact syntax.

#Sigma — the vendor-neutral standard

Sigma is YAML that describes a detection abstractly, then converts to whatever SIEM you run (Splunk, Elastic, Chronicle, Sentinel). Write once, deploy anywhere.

title: Suspicious PowerShell Download Cradle
logsource:
    product: windows
    category: process_creation
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|contains:
            - 'DownloadString'
            - 'IEX'
            - 'Net.WebClient'
    condition: selection          # fire when 'selection' matches
falsepositives:
    - Legitimate admin scripts
level: high
tags:
    - attack.execution
    - attack.t1059.001            # ATT&CK technique ID

#Splunk SPL — search-driven

index=windows EventCode=4688 NewProcessName="*\\powershell.exe"
| where match(CommandLine, "(?i)(downloadstring|iex|net\.webclient)")
| stats count by host, User, CommandLine
| where count > 0

#KQL — Microsoft Sentinel / Defender

DeviceProcessEvents
| where FileName == "powershell.exe"
| where ProcessCommandLine has_any ("DownloadString", "IEX", "Net.WebClient")
| summarize count() by DeviceName, AccountName, ProcessCommandLine

#YARA-L — Google SecOps (Chronicle)

rule suspicious_powershell_download {
  events:
    $e.metadata.event_type = "PROCESS_LAUNCH"
    $e.target.process.file.full_path = /powershell\.exe$/ nocase
    $e.target.process.command_line = /downloadstring|iex|net\.webclient/ nocase
  condition:
    $e
}

The common shapefilter to the right log source → match the suspicious field values → group/aggregate → apply a threshold. Once you see that pattern, the languages are interchangeable.

#Mapping to MITRE ATT&CK

ATT&CK is the shared vocabulary for what attackers do. Every detection should map to one or more technique IDs (e.g., T1059.001 = PowerShell). This lets you:

Toolsthe ATT&CK Navigator colors a heatmap of your coverage. DeTT&CT scores data-source quality and detection coverage per technique. The honest output is a map with green (solid coverage), yellow (partial/noisy), and red (blind spots) — and red is where your next sprint goes.

Coverage caveat"we have a detection for T1059" does not mean you detect all PowerShell abuse. Coverage is about depth and evasion-resistance, not a checkbox. A detection that any attacker trivially bypasses is yellow at best.

#Detection Quality: The Metrics

The two failure modes are false positives (noise → alert fatigue) and false negatives (misses → breaches). Detection quality is the balance.

The precision/recall tradeoffyou can catch everything by alerting on everything (perfect recall, useless precision), or alert on nothing (perfect precision, zero recall). Good detection engineering finds the threshold where a rule is sensitive enough to catch the threat but specific enough that analysts trust it. State this tradeoff explicitly in interviews.

#Detection Validation & Testing

You cannot claim a detection works until you've seen it fire on real malicious activity and stay quiet on benign activity.

The drift problema detection that worked at deploy can silently break — a log source changes format, a field is renamed, an agent stops reporting. Continuous validation catches "detection went dark" before an attacker does.

#The Pyramid of Pain (why TTP detections beat IOC detections)

David Bianco's Pyramid of Pain ranks indicators by how much it hurts the attacker when you detect on them:

            ▲  TTPs              ← hardest to change; detecting these forces
            │  Tools                the attacker to retool. Most durable.
            │  Network/Host Artifacts
            │  Domain Names
            │  IP Addresses
            ▼  Hash Values       ← trivial to change; detecting these annoys
                                     the attacker for minutes. Most volatile.

A hash-based detection breaks the moment the attacker recompiles. A behavior-based detection ("process spawned from Office that then spawns PowerShell with an encoded command") forces them to change how they operate — far more expensive. Build toward the top of the pyramid. This is the single most cited concept in detection interviews.