What are the key ATT&CK Enterprise data source best practices?

What ATT&CK Enterprise data sources are meant to do

ATT&CK Enterprise data sources are not a generic logging checklist, they are a way to translate a detection idea into the telemetry you must have available. The practical goal is to define the observable data needed for a technique, then confirm that the right systems are producing it, the fields are usable, and the telemetry is stored long enough to support detection and investigation.

That distinction matters because a detection can look complete on paper while still failing in practice if the source is disabled, filtered too aggressively, or collected only on a subset of hosts. For that reason, the best use of data sources is to connect each ATT&CK technique to a real collection path, not to treat the matrix as a theoretical mapping exercise.

A useful working pattern is to start with the behaviours you care about, then ask what evidence would prove or disprove them. The ATT&CK Enterprise Matrix gives the technique side of that relationship, while MITRE ATT&CK Guide for Defenders helps translate ATT&CK coverage into practical defender workflows and prioritisation.

How to decide which data sources deserve priority

Not every possible source deserves equal effort. Prioritise telemetry that covers techniques with higher blast radius, higher likelihood, or higher investigative value, especially where a single source supports multiple detections. For example, authentication, process, network, endpoint, cloud control plane, and directory data often deliver more value than narrowly scoped logs that only satisfy one edge case.

Priority should also reflect the quality of the telemetry, not just its existence. A source that is technically enabled but incomplete, delayed, noisy, or missing key fields may be less useful than a smaller source that is consistently queryable. This is why data-source selection should be tied to concrete detection requirements and then reviewed after tuning, because tuning can quietly remove the very signal the detection relied on.

Practitioners should also watch for coverage gaps that appear after engineering changes. New agents, new endpoints, a SIEM migration, or a platform policy update can all break collection assumptions even when the ATT&CK mapping still looks current. For a broader view of how source onboarding, retention and detection engineering fit together, SIEM Guide is a useful companion because it focuses on operationalising log sources, retention and detection content.

What good ATT&CK data source coverage looks like in practice

Good coverage means the defender can prove three things: the source exists, the data is centralised and searchable, and analysts can actually use it during an investigation. That usually requires more than collection alone. You also need retention that matches investigative timelines, enough normalised fields to support hunting or correlation, and a clear understanding of which techniques remain uncovered.

The most effective programmes test coverage at the technique level, then validate whether the data source really supports an analyst workflow. If a source only works through a specialised query that nobody can run, it is functionally weaker than the coverage score suggests. Likewise, if a source is present but only retained for a short period, it may support alerting but fail incident response.

Coverage should also be reviewed as a living control, not a one-time matrix exercise. Data sources can be reduced by cost decisions, altered by log forwarding changes, or lost when a platform is reconfigured. In ATT&CK terms, the important question is not whether a source is listed somewhere, but whether it still produces reliable evidence for the techniques you most care about.

Practitioner Guidance

What to verify: For each high-priority technique, verify the exact source, the collection path, retention period, and the query pattern an analyst will use. If any one of those four is missing, treat the coverage as incomplete even if the source appears in documentation.

Common mistake: Teams often equate “enabled in the platform” with “usable for detection.” In practice, trimming fields, short retention, or broken normalisation can make a source unsuitable long before anyone notices that a detection has gone blind.

What good looks like: A strong programme can answer, for each important ATT&CK technique, what telemetry proves it, where that telemetry lives, how long it is retained, and who has validated that an analyst can query it without special exceptions.

Practitioner takeaway: Treat ATT&CK data sources as an evidence pipeline, not a catalogue entry, because coverage only matters when the telemetry is enabled, retained, centralised, and actually usable under investigation pressure.

Related resources from NHI Mgmt Group

• What are the key ATT&CK coverage mapping best practices?
• How does ATT&CK Enterprise data source work?
• What is an example of ATT&CK Enterprise Data Source in practice?
• ATT&CK Enterprise Data Source