An ATT&CK Enterprise data source is a category of telemetry that can reveal attacker behaviour in enterprise environments, such as process, network, or authentication data. It does not describe the attack itself, but the evidence you need to detect or investigate it. Defenders use it to validate logging coverage and detection logic.
What an ATT&CK Enterprise data source is for
An ATT&CK Enterprise data source is a telemetry category, not a technique. It tells you what evidence might exist in the environment, such as process activity, network connections, authentication events, file changes, or cloud and endpoint logs, so you can reason about whether a technique would be visible.
That distinction matters because ATT&CK techniques describe attacker behaviour, while data sources describe the observable artefacts that may expose it. A strong mapping pairs a technique with the telemetry needed to detect, validate, or investigate it, rather than assuming the technique can be seen from any log stream.
In practice, defenders use data sources to answer a simple question: “If this behaviour happened here, what evidence would we expect to collect?” That makes the concept useful for detection engineering, threat hunting, log onboarding, and control coverage reviews. The ATT&CK matrix is the reference point for the behaviour side of that mapping, and the MITRE ATT&CK Guide for Defenders is the best starting point when you want to connect tactics, techniques, and detection strategy.
How defenders use data sources in detection work
Data sources help teams decide whether a detection is realistically supportable. If a technique depends on authentication abuse, for example, the relevant evidence may sit in identity logs, endpoint events, or directory activity rather than in a single security tool. If the organisation does not collect those events, the detection will be weak no matter how well the rule is written.
They also help separate visibility from inference. Some detections are direct, such as a process tree or a failed logon sequence. Others are indirect, where multiple data sources must be correlated to infer suspicious behaviour. That is why ATT&CK data sources are often used alongside use-case design, log source selection, and coverage mapping instead of as a standalone catalogue.
For defenders who are building an analytic pipeline, the practical value is prioritisation. The same technique may be visible through several telemetry types, but not all of them are equally reliable, complete, or cost-effective. Teams often validate the most stable sources first and then add supporting telemetry where the detection needs higher confidence or better forensic depth. A complementary reference is the SIEM Guide, which helps translate source ideas into onboarding, retention, and tuning decisions.
Why ATT&CK data sources improve coverage and investigations
Coverage tracking is one of the clearest uses of ATT&CK data sources. They let a team see whether a technique is detectable with the telemetry already in place, whether gaps exist in key parts of the environment, and where logging changes would improve investigative reach. That is especially useful when comparing endpoint, network, cloud, and authentication visibility.
For investigations, data sources provide context after the alert fires. A rule may detect the suspicious condition, but the associated data source tells analysts what artefacts to pull for scope, timeline, and root-cause analysis. That is why defenders should think of ATT&CK data sources as evidence types that support both prevention validation and post-incident reconstruction.
They also improve consistency across teams. A security engineer, a threat hunter, and an incident responder may all use the same ATT&CK technique but need different artefacts to prove or disprove it. Naming the data source creates a shared vocabulary for what must be logged, what must be retained, and what must be queryable when an event occurs.
Risk and Threat Considerations
When ATT&CK data sources are missing or too sparse, the main risk is false confidence. A team may believe it has detection coverage because a rule exists, when in reality the required telemetry is absent, delayed, or not retained long enough to investigate the activity.
Failure mechanism: The organisation maps techniques to data sources in theory, but does not verify that the underlying logs are actually collected, normalised, searchable, and retained at the fidelity needed for the use case.
Impact: Attack activity can remain invisible, detections can become brittle, and responders may be unable to reconstruct what happened even when they know a technique was used.
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 NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | Enterprise Matrix | ATT&CK data sources map techniques to observable telemetry in enterprise environments. |
| Recommendation — Map each technique to the telemetry needed to detect, validate, or investigate it. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network devices are monitored to detect events | Data sources define the monitoring evidence needed for continuous detection coverage. |
| DE.CM-02 — The physical environment is monitored to detect events | ATT&CK data-source thinking applies to any monitored evidence stream used for detection. | |
| DE.CM-09 — Computing hardware and software, runtime, data, and/or network connections are monitored to detect potential cybersecurity events | This directly matches ATT&CK's focus on runtime and network evidence for attacker behaviour. | |
| Recommendation — Verify that monitoring telemetry exists for the events your detections depend on. Confirm the required evidence stream is collected and retained for investigation. Align runtime, data, and network telemetry with the behaviours you need to detect. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | ATT&CK data sources depend on logging the events that reveal attacker behaviour. |
| AU-12 — Audit Record Generation | A data source is only useful when the needed audit records are actually generated. | |
| Recommendation — Log the event types required for your detection and investigation use cases. Generate the audit records needed to support ATT&CK-based detections and hunts. | ||
Practitioner Guidance
What to prioritise: Start with the techniques that matter most to your environment, then confirm which data sources are truly available before you promise coverage. If the evidence is weak, treat the detection as unproven rather than “partially implemented.”
What to verify: Check whether the telemetry is complete enough for the question you are asking, not merely present in a tool. A source that logs only fragments, suppresses key fields, or expires before investigations finish will not support reliable ATT&CK mapping.
Practitioner takeaway: ATT&CK Enterprise data sources are most useful when you treat them as evidence requirements, not labels, because good detection depends on observable telemetry that is actually collected, retained, and queryable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org