Lesson 4 of 5 · 20 min read

Data Sources, Detection Coverage, and Prioritization

You now know how to navigate ATT&CK and read technique pages. The next question is practical: which techniques should you detect first, and do you even have the data to detect them?

Both questions are answered by the same two ATT&CK features: Data Sources and Coverage Mapping.

Data Sources in ATT&CK

Every ATT&CK technique page lists the data sources that can detect it. These aren’t SIEM-specific — they’re abstract categories that apply across platforms.

The current ATT&CK data source model uses a two-level hierarchy:

Process
  ├── Process Creation
  ├── Process Termination
  ├── Process Access
  ├── Process Metadata
  └── OS API Execution

Network Traffic
  ├── Network Connection Creation
  ├── Network Traffic Content
  └── Network Traffic Flow

Windows Registry
  ├── Windows Registry Key Access
  ├── Windows Registry Key Creation
  ├── Windows Registry Key Deletion
  └── Windows Registry Key Modification

When you see “Process: Process Creation” on a technique’s detection tab, that maps to:

The Coverage Gap Problem

Here’s a realistic detection team scenario:

The gap between rules you’ve written and rules that will actually fire is one of the most common problems in detection programs. ATT&CK helps you find it.

Mapping Your Coverage

The process:

  1. For each deployed detection rule, tag it with the ATT&CK technique(s) it covers
  2. For each technique, verify you’re collecting its required data sources
  3. Color your Navigator layer accordingly:
    • Green: Rule exists + data source collected + rule tested against real telemetry
    • Yellow: Rule exists but data source not fully collected, or rule untested
    • Gray: No rule, no data source
    • Red: Adversary uses this heavily and you have nothing

Prioritizing What to Cover First

With ~190 techniques and ~400+ sub-techniques, you can’t cover everything. ATT&CK gives you two prioritization signals:

1. Threat Group Prevalence

ATT&CK tracks which techniques are used by which adversary groups. The most frequently-appearing techniques across threat groups deserve the most detection investment. Tools like DeTT&CT compute this automatically.

2. Your Threat Model

Not all techniques are equally likely for your organization. A healthcare org faces different threats than a crypto exchange. ATT&CK’s threat group profiles let you focus on groups that target your sector.

Example prioritization workflow:

1. Pull threat groups relevant to your sector from ATT&CK Groups page
2. In Navigator, load each group's profile as a layer
3. Overlay all layers — techniques that appear in multiple groups get higher scores
4. That composite map = your prioritized detection backlog

3. Data Source Feasibility

Before prioritizing a technique, ask: “Do we have the data source for this?” If you have Process Creation events but not DNS Query logs, techniques that require DNS data should rank lower — regardless of adversary prevalence — until you fix the collection gap.

DeTT&CT — Automating Coverage Measurement

A DeTT&CT data source YAML looks like this:

name: Process Creation
applicable_to: [all]
data_quality:
  device_completeness: 4    # 1-5: how many endpoints send this?
  data_field_completeness: 3  # 1-5: are all fields (CommandLine, ParentImage) present?
  timeliness: 4               # 1-5: how fast does it land in the SIEM?
  consistency: 5              # 1-5: is it reliable across environments?
  retention: 3                # 1-5: how long do you keep it?

Higher scores = more trustworthy data = more credible detection. A rule that fires on poor-quality data gives you low-confidence alerts even when it technically matches.

DeTT&CT— Rabobank CDC ATT&CK Data Sources— MITRE ATT&CK