Mitigations and Data Sources
The Mitigations and Data Sources domain tests defensive mapping: how ATT&CK connects techniques to controls and telemetry. Mitigations (M####) describe defensive measures that can prevent or reduce the impact of a technique. They are not guarantees and often apply to multiple techniques. Data Sources (DS####) and Data Components (DC####) describe the telemetry needed to detect behavior; they are not detections themselves. A detection strategy combines a data component, an analytic, and environmental context. ATT&CK relationships connect techniques to mitigations and data sources, but coverage claims require evidence that the telemetry is collected and the analytic works.
Core rules
- A mitigation can be preventive, detective, or both; check its description.
- A data source without a component and analytic is too vague to engineer.
- One data component can support many techniques; one technique may need several.
- Validate logging coverage, retention, and time synchronization before claiming detection.
Worked example
For credential dumping against LSASS, the relevant data source is Process, with the Process Access component. The technique is OS Credential Dumping: LSASS Memory (T1003.001). A detection might alert when an unsigned process opens LSASS with read memory permissions, excluding approved security tools. A mitigation such as Credential Access Protection reduces exposure but does not replace the detection. The mapping should record the data component, the analytic logic, and the tested false-positive rate.
Traps
Do not equate a mitigation with a detection. Do not list 'Endpoint' or 'Network' as a data source and call it coverage. Do not assume a technique's recommended data source is available in your estate. Do not ignore the difference between data collection and data analysis.