MITRE D3FEND Network Traffic Analysis Implementation Guide: Choosing Sensors and Sequencing Its Twenty Analytics

Network detection programmes often buy a sensor, switch on its default rules and then cannot say which attacker behaviours their traffic analysis would actually catch. MITRE D3FEND organises this work under Network Traffic Analysis (D3-NTA), a technique in the Detect tactic with twenty descendant techniques ranging from signature matching and DNS analysis to certificate checks, relay detection and download to upload ratios. This guide treats D3-NTA as a programme: what the family covers, which data each child needs, how to sequence them, how to prove they work and where they fail. It is written for detection engineers, network security teams and SOC leads. Each child technique has its own deep guide on this site, linked below; this page does not repeat them. For D3FEND itself see the MITRE D3FEND Guide.

Key takeaways

• Network Traffic Analysis is a family of analytics, not a product. D3FEND defines it as analysing intercepted or summarised network traffic to detect unauthorised activity, and splits it into twenty techniques.
• Data source decides what you can run. Flow records support volume, community and ratio analytics; protocol logs support DNS, certificate, RPC and administrative protocol analysis; full packets are needed for file carving, byte sequence emulation and payload profiling.
• Sequence from cheap and broad to costly and deep. Start with DNS, connection attempts and signatures, add protocol metadata and administrative activity baselines, and keep packet-level techniques for chokepoints that justify the storage.
• Encryption moves the work, it does not end it. Certificate, DNS, metadata and volume analytics still work on encrypted traffic; payload techniques need decryption or a host-side view.
• The ATT&CK links are inferred. D3FEND says its offensive mappings for D3-NTA "are inferred, experimental", so use them to plan tests, not to claim coverage.

What D3FEND means by Network Traffic Analysis

In the D3FEND ontology, Network Traffic Analysis (D3-NTA) is a defensive technique that enables the Detect tactic. Its definition is: "Analyzing intercepted or summarized computer network traffic to detect unauthorized activity." The word "summarized" matters: D3FEND counts flow records and protocol metadata as inputs, not only full packet capture. The parent itself has no digital artefact relations; each child names the traffic it analyses, such as outbound internet DNS lookup traffic, intranet administrative network traffic, RPC network traffic or file transfer network traffic.

NIST SP 800-94, the long-standing NIST guide to intrusion detection and prevention systems, describes network-based IDPS and network behaviour analysis as separate technology types. D3-NTA spans both: signature analysis is classic network IDS, while community deviation, metadata anomaly and ratio analysis are behaviour analysis. NIST's page notes that the draft revision of SP 800-94 was retired and that no replacement guidance has been announced, so the 2007 publication remains the reference.

The child techniques

The table lists every descendant of D3-NTA in the D3FEND ontology, grouped by the minimum data source each needs. Purposes paraphrase D3FEND's definitions. The data source column is NHI Mgmt Group's reading, not a D3FEND field.

Choosing, combining and sequencing

The children are cheap or expensive mainly because of the data they need. The second table sets out the three tiers.

Decision guidance

• Start with DNS and signatures. DNS query logs are cheap and cover command and control, dynamic resolution and some exfiltration; signature analysis catches known tooling with low tuning effort. This is the usual first tier in our view, not a D3FEND ranking.
• Add administrative protocol baselines next. D3-ANAA, D3-RTA and D3-RTSD target lateral movement, which is where many intrusions spend their time, and they work on metadata rather than payloads.
• Use flow analytics for scale. Cloud estates often have flow logs before anything else; D3-NTCD and D3-PHDURA give wide coverage of unusual peers and exfiltration-like ratios at low cost.
• Keep packet techniques for chokepoints. Internet egress, data centre ingress and OT conduits justify packet capture for D3-FC and D3-BSE; most internal segments do not.
• OT operators: the APCA and RFUM branch matters more than web analytics, because unauthorised controller commands and firmware pushes are high-impact events.
• Small organisations: resolver logging, a managed IDS ruleset at the internet edge and cloud flow logs cover the first tier without dedicated sensors.
• Large organisations: place protocol metadata sensors at segment boundaries as well as the perimeter so lateral movement is visible, and build per-segment baselines.

Implementation roadmap

1. Map visibility. For each network segment and cloud account, record which of the three data tiers you collect today, where sensors sit and how long data is kept. Gaps in east to west visibility are usually the first finding.
2. Turn on the cheap sources. Enable resolver query logging and cloud flow logs everywhere, and send both to the SIEM or data lake with consistent host and identity enrichment.
3. Deploy protocol metadata sensors. Place them at the internet edge and at the boundaries of server, management and OT segments. Confirm capture loss stays low before relying on the output.
4. Run analytics in alert-only mode. Inline prevention modes should start as detection only; tune rules against two business cycles of traffic before blocking. Keep a documented rollback to passive mode with a named owner.
5. Build baselines. D3-ANAA, D3-NTCD, D3-PMAD and D3-CSPP all depend on a baseline. Agree the baseline window, the owner and how known changes (new services, migrations) are recorded so they do not appear as anomalies.
6. Add packet techniques at chokepoints. Enable file extraction and shellcode analysis where storage and legal review allow, with retention set by policy.
7. Test. In a test environment, replay or emulate the behaviours in the next section and confirm each produces an alert with enough context to triage.

ATT&CK techniques D3FEND relates to D3-NTA

D3FEND relates offensive and defensive techniques through the digital artefacts both touch, and labels the offensive list for D3-NTA "inferred, experimental". The parent page lists techniques across Exfiltration, Command and Control, Execution, Persistence, Lateral Movement, Privilege Escalation, Credential Access, Initial Access, Collection, Discovery and Impact. The table groups a representative selection by tactic, using ATT&CK v20 IDs.

The last column is NHI Mgmt Group's reading of which children meet each behaviour, not a D3FEND mapping. See the MITRE ATT&CK T1071 Application Layer Protocol, T1572 Protocol Tunnelling Defensive Guide and T1048 Exfiltration Over Alternative Protocol guides for those behaviours in depth.

Where identity fits

Much of the traffic D3-NTA analyses is machine to machine: service accounts using RPC and SMB, workloads calling APIs, automation using SSH and remote management protocols. Administrative activity baselines are far more useful when each flow can be tied to the service account or workload identity behind it, rather than an IP address that changes. Certificate analysis also covers machine identities directly: unexpected or self-signed certificates on internal services are both a configuration finding and a detection signal. See the Certificate Transparency Monitoring Guide for Web Teams.

Detection and measurement

Metrics we suggest at NHI Mgmt Group (targets are examples, not standards):

1. Visibility coverage: percentage of segments and cloud accounts with each data tier collected.
2. Sensor health: capture loss and log gaps per sensor, reviewed weekly.
3. Child coverage: number of the twenty D3-NTA techniques with at least one tuned, owned analytic.
4. Emulation pass rate: percentage of tested ATT&CK behaviours that produced an alert with enough context to triage.
5. Alert quality: percentage of network detections closed as true positive or useful benign, per child technique.
6. Encrypted share: percentage of outbound traffic where only metadata and certificate analytics apply, tracked over time.

Framework mapping

Common failure patterns

• Perimeter-only sensors. Lateral movement between internal segments never crosses the sensor, so administrative and RPC analytics see nothing.
• Default rules and no ownership. Signature sets left untuned generate noise until alerts are ignored or suppressed wholesale.
• Baselines without change records. Migrations and new services appear as anomalies, analysts learn to dismiss them, and real deviations follow the same path.
• Ignoring capture loss. Overloaded sensors drop packets silently; detections fail without any error.
• Assuming encryption ends analysis. Teams drop network analytics when traffic is encrypted, losing DNS, certificate, volume and timing signals that still work. See the Beaconing and C2 Detection Guide.
• Treating inferred mappings as coverage. A D3FEND link is a test idea, not evidence that a behaviour would be detected.

Practitioner checklist

• Map each segment and cloud account to the data tiers collected and their retention.
• Enable resolver query logging and cloud flow logs everywhere.
• Place protocol metadata sensors at the internet edge and at internal segment boundaries.
• Run new analytics and inline modes as detection only for two business cycles, with a rollback owner.
• Agree baseline windows and record planned changes for D3-ANAA, D3-NTCD and D3-PMAD.
• Limit packet capture, file carving and shellcode analysis to justified chokepoints.
• Monitor sensor capture loss and log gaps weekly.
• Emulate the mapped ATT&CK behaviours and confirm each alerts with triage context.

Standards and references

• MITRE D3FEND: Network Traffic Analysis
• MITRE D3FEND: DNS Traffic Analysis
• MITRE D3FEND: Administrative Network Activity Analysis
• NIST: SP 800-94 Guide to Intrusion Detection and Prevention Systems
• OISF: What is Suricata
• Zeek: Book of Zeek
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Network detection and response (NDR) rollout playbook · DNS Security Guide · Beaconing and C2 Detection Guide · M1031 Network Intrusion Prevention