Detection Engineering Lifecycle
Design, test, deploy, tune, and maintain detections as evidence-producing security controls.
Start with a decision and behavior
A detection exists to support a decision. Define the behavior, affected environment, intended responder, likely benign alternatives, and required action before writing a query. Turning threat evidence into detection begins with an observable hypothesis.
A useful requirement states the protected asset, adversary or failure behavior, evidence expected, acceptable delay, and decision the responder can make. Avoid beginning with an indicator list or ATT&CK technique number. “Detect credential dumping” is too broad; “identify an unsigned process reading a protected authentication process on managed Windows servers, then isolate the host after validation” is testable. Record assumptions and non-goals so later tuning does not silently change the purpose.
Confirm available telemetry
Confirm that the required events, fields, identifiers, timestamps, and retention are present and trustworthy. Document blind spots. A precise rule over absent or unstable telemetry provides false confidence.
Sample real records from each in-scope platform, version, and collection path. Verify field semantics, time sources, process and session identifier scope, normalization, parser behavior, latency, sampling, and retention. Measure population rather than assuming a configured source is complete. If evidence cannot distinguish the target behavior from normal activity, change the requirement, add context, or accept and document the limitation before building logic.
Translate behavior into logic
Express the smallest logic that distinguishes the behavior from expected activity. Preserve field semantics, select a peer group, and map ATT&CK only at the specificity supported. Store logic, tests, ownership, and rationale together.
Separate selection, correlation, aggregation, thresholds, exclusions, and enrichment so each assumption can be tested. Use stable identifiers and bounded time windows. Baselines should compare relevant peers—domain controllers with domain controllers, build agents with build agents—not the entire fleet. An exclusion should describe a verified benign workflow, owner, scope, and expiry. Broad exclusions based on filenames, administrators, or corporate ranges can hide the same behavior an attacker would adopt.
Test before deployment
Replay representative malicious and benign cases in an authorized environment. Test field loss, timing, scale, and expected exceptions. Simulation validates observable logic; emulation can test a longer adversary sequence.
Keep positive, negative, boundary, and regression cases with expected outcomes. Test renamed binaries, reordered events, missing fields, clock skew, duplicate ingestion, high volume, and normal administration. A rule that fires in a laboratory but not through the production collection path is not validated. Use controlled attack simulation only with authorization and safety controls, and preserve test identifiers so responders can distinguish exercises from real activity.
Operate and improve the analytic
Monitor volume, usefulness, data changes, false patterns, missed cases, and responder feedback. Tune with documented exceptions, expiry, and review. Retire or replace detections whose assumptions no longer hold.
Assign an owner and review triggers for source-schema changes, platform migration, adversary adaptation, incidents, and repeated low-value outcomes. Measure more than alert count: coverage tests, data health, time to review, confirmed outcomes, missed behaviors, and actions enabled all matter. Version logic and tests together, deploy through review, and keep rollback available. Retirement is healthy when evidence disappears, a stronger control replaces the rule, or the decision no longer exists. A detection that fires rarely can still be valuable when it covers a severe, well-tested behavior; frequency alone is not a sound retirement criterion.
