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.
External reference
MITRE ATT&CK publishes Detection Strategies as high-level approaches for detecting adversary techniques. ATT&CK v18 also deprecated the legacy Data Sources model; the older Data Sources page remains available for reference.
https://attack.mitre.org/detectionstrategies/Detection engineering workflow
Start with behaviour
Define the adversary behaviour or detection objective before choosing a rule, query or dashboard.
Identify telemetry dependencies
Record which event sources, fields, timestamps and identities are needed for the analytic to work.
Define analytic logic
Document the conditions, joins, correlation windows, exclusions and expected benign behaviours that shape the signal.
Validate with evidence
Test using representative events or approved simulations and retain the test case, version, result and observed gaps.
Operate and review
Track alert quality, incident conversion, missing context, source health, tuning changes and retirement decisions.
Relevant Cybatar operating surfaces
Claim boundary
An ATT&CK mapping does not prove that a detection exists, that required telemetry is present, or that the detection works. Cybatar does not claim MITRE certification, endorsement or complete ATT&CK coverage.
These pages are Cybatar-authored detection-engineering guidance. External taxonomies and standards are referenced for context; the mappings are not official MITRE, NIST or vendor validations, certifications, endorsements or statements that a particular deployment will detect a technique.