D3FEND Detect Tactic: All 90 Techniques, Priorities and ATT&CK Coverage

Most security teams already run detection tools, but few can say which defensive techniques those tools actually perform and which attacker behaviour is left unwatched. MITRE D3FEND's Detect tactic gives that question a shared vocabulary: D3FEND defines it as the tactic "used to identify adversary access to or unauthorized activity on computer networks." In D3FEND 1.6.0 it holds 90 techniques in eight top-level families, from File Analysis to User Behavior Analysis. This hub lists every one, suggests where to start and shows how D3FEND relates them to ATT&CK, for detection engineers and SOC leads mapping coverage. For the framework itself, see the MITRE D3FEND Guide.

Key takeaways

• Detect is the largest D3FEND tactic to map. Its 90 techniques sit under eight families: File, Identifier, Message, Network Traffic, Process and User Behavior Analysis, plus Physical Access and Platform Monitoring.
• Families follow the data, not the product. Each family is defined by the digital artefact it analyses or monitors (files, identifiers, email, traffic, processes, platform state, accounts), which maps neatly to log sources.
• ATT&CK links are inferred, not proven. D3FEND relates techniques through shared artefacts and states that it does not characterise effectiveness, so treat each link as test scope.
• Start where telemetry already exists. Process, authentication and account monitoring usually give the most coverage per unit of effort; firmware and physical monitoring come later for most organisations.
• Measure detections, not tools. Coverage only counts when a technique has a rule, a tested alert and an owner.

What Detect means in D3FEND

D3FEND groups defensive techniques into tactics (Model, Harden, Detect, Isolate, Deceive, Evict, Restore). Detect covers techniques that observe or analyse something and decide whether it indicates adversary activity. Blocking belongs to Harden and Isolate, removal to Evict. In the ontology each Detect technique carries a relation to an artefact, such as "analyzes" a Process Tree or "monitors" a Domain User Account. D3FEND's FAQ describes the catalogue as defensive techniques and their relationships to adversary techniques, and says it neither rates their effectiveness nor prescribes specific countermeasures.

Every technique in the Detect tactic

The tables below list all 90 techniques from the D3FEND 1.6.0 ontology, grouped by top-level family. The Parent column shows the hierarchy (for example, Domain Name Reputation Analysis sits under Identifier Reputation Analysis, which sits under Identifier Analysis). Purposes paraphrase D3FEND's definitions. Process Analysis and Application Protocol Command Analysis are listed as plain text.

File Analysis (6 techniques)

Identifier Analysis (9 techniques)

Message Analysis (3 techniques)

Network Traffic Analysis (21 techniques)

Physical Access Monitoring (5 techniques)

Platform Monitoring (22 techniques)

Process Analysis (12 techniques)

User Behavior Analysis (12 techniques)

How the families fit together and where to start

The eight families split along three planes. Host plane: Process Analysis, Platform Monitoring (including Operating System Monitoring, File Integrity Monitoring and firmware checks) and File Analysis. Network plane: Network Traffic Analysis, Identifier Analysis and Message Analysis. Identity and physical plane: User Behavior Analysis and Physical Access Monitoring. Aim for at least one working technique per plane.

A practical rollout order:

1. Inventory telemetry: map each log source (EDR, identity provider, DNS, proxy, mail gateway, flow records) to the artefacts above.
2. Cover process and identity first: Process Spawn Analysis, Process Lineage Analysis, Script Execution Analysis, Authentication Event Thresholding and Domain Account Monitoring rest on data most organisations already collect.
3. Add reputation and message checks: domain, URL, IP and file hash reputation on proxy, DNS and mail flows.
4. Add network baselines: Connection Attempt Analysis, DNS Traffic Analysis and Per Host Download-Upload Ratio Analysis need a learning period, so run them in alert-only mode first.
5. Add platform integrity: File Integrity Monitoring, Scheduled Job Analysis and System Init Config Analysis on servers, then firmware verification where hardware supports it.
6. Test and tune: emulate the related ATT&CK techniques in a test environment, confirm each alert fires, then tune. Roll a noisy rule back to alert-only.

ATT&CK techniques D3FEND relates to Detect

D3FEND relates Detect techniques to ATT&CK techniques that act on the same artefact. These are inferred relationships, not tested coverage claims. The table shows examples from the ontology, checked against ATT&CK v20.

Some relationships in D3FEND still point at ATT&CK IDs revoked in v20 (for example the old Impair Defenses entries, now T1685 Disable or Modify Tools). Use the v20 successor when building test plans. See MITRE ATT&CK T1078 Valid Accounts Guide, T1003 OS Credential Dumping and MITRE ATT&CK T1566 Phishing.

Where identity fits

User Behavior Analysis is written around users, but its account techniques apply directly to service accounts, workload identities and API keys. Authentication Event Thresholding, Resource Access Pattern Analysis and Credential Compromise Scope Analysis are often more reliable for machine identities, because their behaviour is narrower than a person's. See the Service Account Behavioural Baselining Guide and the ITDR Guide.

Measuring progress

• Technique coverage: share of the 90 Detect techniques with at least one deployed, tested rule (count each technique once).
• Telemetry coverage: share of in-scope hosts, identities and network segments sending the data each technique needs.
• Test pass rate: share of emulated ATT&CK techniques that produced the expected alert in the last quarter.
• Time to detect: median time from emulated activity to alert, per family.
• Alert precision: share of alerts per rule closed as true positive, reviewed monthly.

Framework mapping

Common failure patterns

• Counting tools as coverage: an EDR licence does not mean Process Lineage Analysis is in place; only a tested rule does.
• Reading inferred links as proof: a D3FEND relationship says a technique observes the same artefact, not that it catches the attack.
• Skipping the baseline period: thresholding and community deviation techniques flood the SOC if switched to alerting on day one.
• Humans only: behaviour analytics scoped to employees leaves service accounts and tokens unwatched.
• Unowned telemetry gaps: scheduled job, init configuration and firmware data often go uncollected.

Practitioner checklist

• Map each log source to the D3FEND artefacts it carries.
• Mark each of the 90 Detect techniques as deployed, tested, planned or not applicable.
• Cover Process Analysis and User Behavior Analysis first, including non-human accounts.
• Run network baselining techniques in alert-only mode before alerting.
• Enable file integrity, scheduled job and init configuration monitoring on servers.
• Translate D3FEND's ATT&CK links into an emulation test plan using v20 IDs.

Standards and references

• MITRE D3FEND: Detect tactic
• MITRE D3FEND: Frequently asked questions
• MITRE D3FEND: About
• MITRE ATT&CK: Enterprise matrix
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• CISA and partners: Best Practices for Event Logging and Threat Detection

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Detection Engineering Guide · SIEM Guide · EDR Guide · Detection Engineering for Non-Human Identities Guide