Build detections that can be explained, tested and improved
Connect behavioural objectives to the telemetry, analytic logic, validation evidence, alert outcomes and lifecycle decisions needed to support a defensible detection programme.
Five detection-engineering questions that should have evidence
The goal is not to accumulate mappings. It is to know what behaviour matters, whether the necessary data exists, whether the analytic works, what analysts do with the signal and when the detection should change.
ATT&CK detection strategy mapping
Use ATT&CK as a behavioural reference, not a coverage badge. Start with the adversary behaviour or detection strategy that matters, identify the telemetry required to observe it, define analytic logic and expected benign conditions, test the detection against representative data, record limitations, and keep the mapping linked to evidence of the source, logic, test and operational outcome.
Open guide → Detection engineeringLog-source coverage
Measure coverage as a chain, not a source count: required source, accountable owner, connection state, expected event categories, recent ingestion, usable normalized fields, time quality, retention/access expectations, dependent detections, and known gaps. A source listed in an inventory is not evidence that useful telemetry is arriving or that a detection can use it.
Open guide → Detection engineeringDetection validation
Validate the full detection path: required telemetry, analytic logic, representative positive and benign test cases, expected output, escalation behaviour and failure conditions. Retain the detection version, test date, test case, result, reviewer and unresolved gaps so later coverage claims can be traced to evidence rather than memory.
Open guide → Detection engineeringAlert quality
Measure whether alerts lead to timely, explainable decisions. Track duplicate or repeated signals, missing asset or identity context, closure reasons, escalation to incidents, ageing, unresolved material alerts, analyst tuning feedback and source-related failures. High alert volume is not proof of strong detection, and a low false-positive rate can still hide missed coverage.
Open guide → Detection engineeringDetection lifecycle
Treat each detection as a governed operational asset. Record the detection objective, behavioural reference, required telemetry, analytic logic, owner, severity/escalation expectations, validation evidence, deployment state, tuning history, performance feedback, known gaps and retirement rationale.
Open guide →Detection evidence library
See what should prove telemetry coverage and detection validation rather than relying on screenshots or unsupported coverage claims.
Explore detection evidenceHow Cybatar separates mapping from proof
Read the rules for ATT&CK references, telemetry evidence, test evidence, alert feedback and product claim boundaries.
Read methodologyConnect to the security operating model
Detection only matters when signals can be triaged, escalated, investigated and linked to accountable response.
Security operations