Detection Engineering | IR Framework

01 / PRINCIPLES

Detection begins with a response decision

A detection is valuable when it gives an analyst enough reliable context to decide whether to investigate, contain, escalate, or dismiss. A rule without data ownership, validation, runbook context, and an expected responder action is only a query.

Behavior before indicators

Use hashes, domains, and IP addresses for enrichment and short-lived blocking. Anchor durable analytics in adversary behavior and environmental context.

Evidence before severity

Severity should reflect confidence, asset or identity criticality, blast radius, privilege, data exposure, and active impact—not a vendor default.

Test before production

Validate positive, negative, boundary, performance, suppression, and data-loss cases before enabling automated response.

02 / TELEMETRY

Collect the control plane and the workload

Core telemetry and the questions it can answer
Domain	Required evidence	Questions supported	Common failure
Identity	Sign-ins, MFA, sessions, risk, role/group changes, OAuth grants	Who authenticated, how, from where, with what privilege, and what changed?	Collecting failures but not successful sessions or administrative changes
Endpoint	Process, file, registry, persistence, network, logon, sensor health	What executed, under which identity, with what lineage and effect?	Short retention or missing server and privileged-workstation coverage
Network	DNS, proxy, firewall, flow, packet metadata, VPN, load balancer	Which systems communicated, through what path, and at what volume?	No east-west visibility or inconsistent asset attribution
Cloud and SaaS	Control-plane audit, data access, workload, storage, secrets, email and collaboration logs	What configuration, access, sharing, or workload action occurred?	Management events retained while data-plane events are absent
Containers	Kubernetes audit, admission, runtime, registry, image and node evidence	Who changed the cluster, what ran, and whether the image or workload drifted?	Posture findings without runtime or API audit context

Telemetry health is a detection: alert on disabled audit sources, ingestion delay, parser failure, unexpected volume changes, sensor loss, retention changes, and time synchronization drift.

03 / LIFECYCLE

Run detections as versioned engineering assets

HypothesisAdversary behavior and responder decision.

Data contractSources, fields, owner, latency, and retention.

AnalyticLogic, ATT&CK mapping, exclusions, and enrichment.

TestPositive, negative, boundary, and performance cases.

DeployPeer review, version, monitoring, and rollback.

MeasurePrecision, coverage, response outcome, and drift.

Minimum detection record

Objective and expected responder decision
ATT&CK technique and relevant data components
Query/rule owner, version, review date, and repository location
Required fields, normalization assumptions, latency, and retention
Known false positives, exclusions, and abuse cases
Test procedure, expected result, severity logic, and runbook link
Rollback, suppression, health monitoring, and expiration criteria

04 / WORKED EXAMPLE

Example: shadow-copy deletion behavior

This Microsoft Defender XDR advanced-hunting example looks for common recovery-inhibition commands. It is a starting hypothesis, not a production-ready detection. Validate fields, legitimate administrative tooling, and execution context in your environment.

DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName in~ ("vssadmin.exe", "wbadmin.exe", "wmic.exe")
| where ProcessCommandLine has_any
    ("delete shadows", "delete catalog", "shadowcopy delete")
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, FileName, ProcessCommandLine,
          InitiatingProcessSHA256
| order by Timestamp asc

Required context

Asset role and criticality
Initiating process and signer
User privilege and logon context
Change window or backup activity
Related credential access, discovery, and lateral movement

Validation tests

Approved backup administration
Benign command variants and case changes
Encoded or indirect execution
Missing command-line telemetry
Query cost and expected event volume

05 / TRIAGE

Move from alert to incident hypothesis

Validate the source: confirm telemetry freshness, parser behavior, event identity, and sensor health.
Establish context: asset, identity, privilege, business service, expected behavior, and recent change.
Correlate behavior: search identity, endpoint, network, cloud, SaaS, and threat-intelligence evidence.
State the hypothesis: known facts, assumptions, confidence, alternative explanations, and missing evidence.
Choose the action: dismiss, monitor, investigate, escalate, or contain—with an owner and validation step.

Impossible travel: treat it as a risk signal. VPN egress, mobile routing, shared infrastructure, and token reuse can produce misleading location changes. Correlate device, authentication method, session, user agent, ASN, activity, and identity history.

06 / MEASUREMENT

Measure system performance, not analyst activity

Metrics tied to useful outcomes
Metric	What it reveals	Guardrail
Time to triage / investigate / contain	Where evidence or authority creates delay	Segment by incident type and severity; averages hide outliers
Detection precision	Proportion of reviewed signals that support action	Do not improve precision by suppressing uncertain high-impact behavior
Validation pass rate	Whether analytics still detect tested behavior	Include parser and telemetry-loss tests
ATT&CK and data coverage	Known defensive visibility	Technique counts do not measure effectiveness
Telemetry availability and latency	Whether evidence is present when needed	Measure by source, tenant, region, and critical asset class
Incident-derived improvements	Whether lessons become tested changes	Close only after verification