An ATT&CK Enterprise Data Source is a category of telemetry or evidence used to detect techniques in the ATT&CK Enterprise matrix. It tells defenders what data to collect, such as process, network, or authentication evidence, so they can build coverage, write detections, and validate logging.
What ATT&CK Enterprise Data Sources Do
ATT&CK Enterprise data sources define the telemetry defenders need in order to see adversary behaviour at the level ATT&CK models it. They turn the matrix from a catalogue of techniques into an evidence plan for collection, correlation, and detection engineering.
That makes the term operational rather than purely descriptive: the point is not just to name a data type, but to identify what must be observable if an organisation wants to detect, validate, and measure coverage against ATT&CK Enterprise techniques.
Why Data Sources Matter in Detection Coverage
Data sources are the bridge between an ATT&CK technique and the logs, events, and artefacts that can prove it happened. A technique without the right telemetry may still be relevant on paper, but it cannot be reliably detected, triaged, or measured in practice.
That is why defenders map process, network, authentication, endpoint, cloud, and identity evidence back to ATT&CK rather than treating logging as a generic checklist. The MITRE ATT&CK Enterprise Matrix is the canonical reference for linking observed behaviour to specific tactics and techniques.
In a mature program, data source selection also shapes prioritisation. If the telemetry is absent, noisy, or incomplete, the detection gap is often more important than the rule itself.
How Defenders Use the Category in Practice
Security teams use ATT&CK Enterprise data sources to decide what evidence to onboard, where to place sensors, and how to validate that collection is sufficient for a given use case. This is especially useful when building threat-informed detection content, because the same technique may require multiple evidence streams to detect with confidence.
The category also helps teams write better coverage statements. Rather than saying a control “covers” a technique in the abstract, analysts can show which source types support detection, which ones support investigation, and which ones are only useful after compromise is suspected.
For defenders building ATT&CK coverage mappings, NHIMG’s MITRE ATT&CK Guide for Defenders is a useful companion for mapping techniques, data sources, and coverage decisions in a structured way.
Common Limits and Quality Issues in Telemetry
ATT&CK data sources are only useful when the underlying telemetry is complete enough to answer the detection question. Missing fields, inconsistent timestamps, disabled logging, and short retention windows can all break an otherwise sound detection design.
They can also mislead teams into overestimating visibility. A source label may exist in a platform, but if the event content does not include the fields needed to distinguish benign from malicious activity, the source is only partially useful.
This is why defenders often pair ATT&CK mapping with detection engineering review and log-source validation. The taxonomy helps teams ask a practical question: can we actually observe the behaviour we care about, with enough fidelity to act on it?
Risk and Threat Considerations
When the required data sources are missing, attackers gain time, stealth, and persistence. Weak logging can hide process execution, remote access, authentication abuse, or post-compromise movement long enough for an intrusion to spread before defenders notice.
Failure mechanism: An organisation assumes it has detection coverage because a technique is mapped in ATT&CK, but the specific telemetry needed to confirm the behaviour was never collected, was not retained, or was not reviewed at the right fidelity.
Impact: Detection fails late or not at all, which increases dwell time, weakens incident scoping, and can leave identity abuse, lateral movement, and command activity invisible during the most important phase of response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0005 — Defense Evasion | ATT&CK data sources are used to detect enterprise adversary techniques and behaviors. |
| Recommendation — Map telemetry to ATT&CK techniques and hunt for gaps where detections lack supporting evidence. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | This term centers on collecting and retaining the logs needed for detections. |
| Recommendation — Collect, retain, and review the logs required to validate ATT&CK coverage. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The subject depends on selecting events to be logged so behavior can be detected. |
| AU-12 — Audit Record Generation | Data sources depend on generating the audit records that feed detection pipelines. | |
| Recommendation — Define logged event types that support ATT&CK-aligned detection and investigation. Generate the audit records needed to support enterprise threat detection use cases. | ||
Practitioner Guidance
Why practitioners should care: Treat ATT&CK Enterprise data sources as a design requirement for visibility, not as a documentation exercise. If the source cannot support a detection or investigation decision, it should not be counted as meaningful coverage.
What to watch for: Pay close attention to techniques that rely on sparse or optional telemetry, especially where endpoint, authentication, or network evidence is inconsistent across platforms. Those are often the gaps that create false confidence in coverage reporting.
Practitioner takeaway: The value of the taxonomy comes from proving what you can actually observe, not from listing techniques you hope your tooling can see.
Related resources from NHI Mgmt Group
- Why does linking threat intelligence to MITRE ATT&CK and live vulnerability data improve cloud defense decisions?
- What breaks when teams try to measure security posture with ATT&CK data by hand?
- How should data governance teams build a single source of truth for enterprise metadata across fragmented systems?
- How should security teams evaluate open source software for protecting sensitive enterprise data?