An attacker on a compromised laptop has to reach systems that laptop never normally talks to, and that change in who talks to whom is visible long before any data leaves the network. MITRE D3FEND names this countermeasure Network Traffic Community Deviation (D3-NTCD) and defines it as "Establishing baseline communities of network hosts and identifying statistically divergent inter-community communication." It sits under the Detect tactic as a child of Network Traffic Analysis (D3-NTA) and analyses Network Traffic. This card explains how community baselines are built, which ATT&CK techniques D3FEND relates to the technique, what telemetry feeds it, how to verify it and why it is noisy in dynamic networks. It is for detection engineers and network security teams; flow collection itself is covered in the NetFlow and IPFIX Flow Telemetry Guide.
Key takeaways
- Communities, not single hosts. D3-NTCD groups hosts that frequently communicate, then flags communication between communities that do not usually talk. D3FEND's example is a finance community suddenly reaching a code server normally used only by engineers.
- It is a graph problem. The single reference D3FEND cites, a Vectra Networks patent, builds a connectivity graph of internal hosts from session metadata and finds communities with algorithms such as Louvain, then compares each host's current contacts with its baseline.
- Nine direct ATT&CK relations, all inferred. D3FEND links the Network Traffic artefact directly to techniques such as Remote System Discovery (T1018), Network Service Discovery (T1046), Network Share Discovery (T1135) and Adversary-in-the-Middle (T1557), and infers many more through sub-artefacts. Discovery and lateral movement are where community deviation genuinely helps.
- False positives are the stated cost. D3FEND warns of false positives in very dynamic networks and that low and slow attackers may not deviate enough to alert.
- Segmentation makes it sharper. The tighter the intended communities, the more an out-of-community connection means. NTCD and microsegmentation reinforce each other.
D3-NTCD at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-NTCD (d3f:NetworkTrafficCommunityDeviation) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis (D3-NTA) |
| Digital artefact | Network Traffic (D3FEND relation: analyzes) |
| D3FEND reference | Vectra Networks patent US20160191560A1, "System for implementing threat detection using daily network traffic community outliers" |
| Typical data sources | NetFlow or IPFIX, Zeek conn logs, cloud VPC or VNet flow logs, NDR session metadata |
| Typical outputs | Host-level deviation score, alert when a host contacts a large share of new peers or a sensitive asset outside its community |
| Main limitation | Noise in dynamic environments; attackers who stay inside the victim's normal community are invisible to it |
How it works
The cited patent describes the method in five stages. Each stage is a design decision for anyone building or evaluating the capability.
- Collect internal sessions only: passive monitoring of internal traffic from a SPAN or TAP, ignoring sessions to or from external hosts. Per-session metadata includes source and destination host, destination port, connection attempts, data volume, duration, time and protocol.
- Build the graph: each internal host that talked to another internal host is a node; edges are "meaningful" communications, judged by data quantity, connection attempts, sent and received ratio, frequency or destination port, and may be weighted by volume.
- Find communities: clusters of hosts with similar behaviour are learned from the graph, not configured. The patent names Louvain, Leading Eigenvector and MultiLevel. Louvain (Blondel and others, "Fast unfolding of communities in large networks") maximises modularity and was tested on graphs of more than a hundred million nodes.
- Baseline each host: each host's normal contacts and community affiliation over a time window. The patent gives 24 hours or a week as examples, with models rebuilt or updated on a sliding window.
- Score deviations: the key metric is the ratio of newly contacted hosts to all contacted hosts in the current window. The patent's worked example uses a 70% threshold, weights important assets three times, and optionally alerts only when a new contact is a sensitive server.
The 70% threshold and 3x weighting are the patent's illustrative values, not a standard. Treat them as starting points for tuning in your own network.
Design choices and their effect
| Choice | Option A | Option B | Trade-off |
|---|---|---|---|
| Community source | Learned from traffic (graph clustering) | Declared from CMDB, AD organisational units or segmentation zones | Learned communities find real behaviour, including undocumented dependencies; declared ones are explainable and stable but drift from reality |
| Baseline window | Daily | Weekly or longer | Short windows adapt quickly but miss weekly jobs; long windows absorb more legitimate variation and react slower |
| Edge definition | Any connection | Meaningful connection (bytes, repeated contact, service port) | Counting every connection makes broadcast and scanning dominate; thresholds reduce noise but can hide single quiet connections |
| Alert condition | Ratio of new peers above threshold | Any new contact with a high-value asset | The ratio finds broad discovery; the asset rule finds a single targeted access. Many teams run both |
ATT&CK techniques D3FEND relates to D3-NTCD
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-NTCD. Because the technique analyses Network Traffic, D3FEND infers a relation to every technique that produces, may produce or may modify network traffic or one of its sub-artefacts, and labels these "inferred and experimental" (D3FEND 1.6.0, checked November 2026). Each ID below was checked against ATT&CK v20.
Direct relations on the Network Traffic artefact
| ATT&CK ID | Technique | D3FEND relation of the technique | Value of community deviation |
|---|---|---|---|
| T1018 | Remote System Discovery | produces Network Traffic | Strong: sweeps touch many hosts outside the source's community |
| T1046 | Network Service Discovery | produces | Strong: port scans raise the new-peer ratio sharply |
| T1135 | Network Share Discovery | may produce | Strong where shares sit in other communities |
| T1557 | Adversary-in-the-Middle | produces | Moderate: a host that becomes a relay for other communities changes graph shape |
| T1565.002 | Transmitted Data Manipulation | may modify | Weak: content changes, not peers |
| T1205, T1205.001 | Traffic Signaling, Port Knocking | produces | Weak: a few packets rarely shift a baseline |
| T1218.003 | CMSTP | may produce | Weak: visible only if it reaches an unusual internal host |
| T1550.001 | Application Access Token | may produce | Weak: token use mostly goes to external services that NTCD ignores |
Wider inferred set, grouped by tactic
Through sub-artefacts of Network Traffic, the D3FEND page also lists, among others:
- Lateral Movement: Remote Desktop Protocol (T1021.001), SSH (T1021.004), Web Session Cookie (T1550.004), Lateral Tool Transfer, Remote Service Session Hijacking and Exploitation of Remote Services.
- Credential Access: Name Resolution Poisoning and SMB Relay (T1557.001), DHCP Spoofing (T1557.003), Kerberoasting (T1558.003), Password Spraying (T1110.003), Credential Stuffing (T1110.004) and DCSync (T1003.006).
- Command and Control, Exfiltration, Impact and Initial Access: proxy, encrypted channel, application layer protocol, exfiltration and flood techniques such as T1090.001, T1573.002, T1071.004, T1048.003, T1567.002 and T1498.001.
Internal techniques are where NTCD earns its place: DCSync from a workstation community to a domain controller, password spraying across many servers, and RDP or SSH from a user community into a server community. Internet-bound C2 and exfiltration sit outside the internal graph the reference method builds, so other analytics cover them. Technique detail is in T1018 Remote System Discovery, MITRE ATT&CK T1046 Network Service Discovery, the T1135 Network Share Discovery Defensive Guide, MITRE ATT&CK T1557 Adversary-in-the-Middle and T1021 Remote Services.
Where it is implemented
Community deviation is an analytic, so it is implemented on top of flow or session telemetry: in NDR products, UEBA platforms with peer-group analysis, or a SIEM or data platform running graph analytics. The telemetry options below are listed alphabetically; the order is not a ranking, and each row comes from the vendor's or project's documentation.
| Telemetry source | What it provides (documentation) | Points to note for community analysis |
|---|---|---|
| Amazon VPC Flow Logs | IP traffic to and from network interfaces in a VPC, published to CloudWatch Logs, Amazon S3 or Amazon Data Firehose | Some traffic is not logged (for example Amazon DNS server, instance metadata at 169.254.169.254, DHCP and ARP); use pkt-srcaddr and pkt-dstaddr where intermediate interfaces hide the original address |
| Azure VNet flow logs | Layer 4 flows for a virtual network: 5-tuple, direction, flow state, encryption state and throughput, collected at one-minute intervals and written to Azure Storage as JSON | Records name the network security rule that allowed or denied each flow, which helps compare declared and observed communities |
| Google Cloud VPC Flow Logs | Sampled flows aggregated by 5-tuple at intervals from 5 seconds to 15 minutes | Totals are estimates from sampled packets; intranode GKE pod traffic needs intranode visibility; logging retains 30 days by default |
| IPFIX and NetFlow | IPFIX (RFC 7011, Internet Standard STD 77) exports flow records from routers, switches and probes to a collector | Export from internal switching points, not only the edge, or east-west flows are missing |
| Zeek conn log | One record per connection with fields such as id, proto, service, duration, orig_bytes, resp_bytes, conn_state, local_orig and local_resp | local_orig and local_resp make it simple to keep only internal-to-internal sessions, as the reference method does |
Availability: AWS documents flow log limitations, including traffic types not logged and a fixed record format once created. Azure documents a free tier for flow log collection and separate billing for traffic analytics. Google Cloud documents sampling, a per-VM cap on TCP connection logging and default retention. Check each provider's current documentation when sizing. For buying an analytics layer, see the NDR Buyer's Guide and the UEBA Guide.
Where identity fits
A host's community is often a proxy for the identities on it. Service accounts and automation hosts have very stable peer sets, which makes them good NTCD subjects: a CI runner or backup server that suddenly reaches a payroll database is a strong signal. Where host-to-user correlation exists, the reference patent links detections to users. Pair NTCD with account-based analytics such as D3-RAPA Resource Access Pattern Analysis so a deviation can be tied to the credential that made it.
Implementation steps
- Get east-west telemetry. Enable flow export or a sensor on internal paths, plus cloud flow logs for every VPC or VNet in scope. NTCD is blind where only north-south traffic is collected.
- Keep internal sessions and resolve identities. Filter to internal-to-internal flows and enrich addresses with hostnames, asset owner and asset criticality. DHCP churn otherwise splits one host into many nodes.
- Define meaningful edges. Exclude infrastructure noise (DNS, NTP, DHCP, monitoring and patch servers) from community building, or treat those servers as shared services connected to every community.
- Build and review communities. Run the clustering on two to four weeks of data and have network and application owners review the result. Unexpected bridges between communities are findings in their own right.
- Set alert rules in shadow mode. Start with a new-peer ratio rule and a high-value asset rule, both non-paging, for at least two baseline windows. The ratio threshold should come from your own score distribution.
- Integrate change records. Suppress or annotate deviations explained by approved changes, migrations and new deployments, so the SOC can see why a deviation was expected.
- Promote, and keep a rollback. Move rules to paging only once false positive rates are acceptable, and keep the ability to drop back to shadow mode during large migrations.
How to verify it works
- Authorised discovery test: from a workstation in a user community, run an approved, rate-limited service discovery against a test server range in another community. Confirm a deviation alert names the source and the new peers.
- Sensitive asset test: from an approved test host, connect once to a designated high-value test server outside its community. Confirm the high-value asset rule fires even though the ratio stays low.
- Community sanity check: compare learned communities with the segmentation design and the CMDB each quarter. Large mismatches mean either the model or the network design is wrong.
- Telemetry gap check: list subnets and cloud networks with no flow records in the last day.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Internal subnets and cloud networks producing flow records | All in scope | No telemetry, no communities |
| Authorised discovery tests detected | 100% | Proves the core use case |
| Deviation alerts per week explained by approved change | Falling as change integration improves | Shows noise is being engineered out |
| Median time from deviation to triage | Within one shift | Discovery precedes impact; slow triage wastes the lead time |
| Communities reviewed by owners in the last quarter | 100% | Keeps the baseline grounded in reality |
Limits, bypasses and failure patterns
- Living inside the community: an attacker who only reaches hosts the victim already talks to causes no deviation. D3FEND names low and slow movement as a gap. Layer host and identity analytics.
- Dynamic networks: autoscaling groups, containers with short-lived addresses and DHCP churn create constant "new" peers. Cluster on workload identity or labels rather than raw IP addresses where possible.
- Shared services as bridges: jump hosts, management servers and file servers connect every community. Treat them separately, and watch them more closely, because a compromised bridge host has a licence to talk to everyone.
- Baselines that learn the attack: a slow intrusion that spans the baseline window becomes normal. Keep a long-term reference baseline alongside the rolling one.
- Edge-only collection: sensors at the internet boundary see almost no internal sessions.
- Thresholds copied from examples: the patent's 70% is illustrative. Thresholds must come from your own score distribution.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; SI-4(4) Inbound and Outbound Communications Traffic | Monitoring communications for unusual or unauthorised activity |
| NIST SP 800-53 Rev 5 | AC-4 Information Flow Enforcement | Declared flows between zones that community analysis checks against |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Internal boundaries that define intended communities |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Networks monitored; adverse events analysed |
| MITRE D3FEND | D3-NTA, D3-NTCD | Parent and technique |
Related countermeasures
- IPC Traffic Analysis (D3-IPCTA): explains what a deviating host did over SMB and RPC. See D3-IPCTA IPC Traffic Analysis.
- Network Traffic Signature Analysis (D3-NTSA): known-bad patterns in the same traffic. See D3-NTSA Network Traffic Signature Analysis.
- Network Segmentation (M1030): defines the communities that NTCD then watches. See M1030 Network Segmentation and the Network Segmentation Guide.
- Lateral movement detection: the wider picture is in the Lateral Movement Guide.
Practitioner checklist
- Collect internal-to-internal flows from switches, sensors and every cloud network.
- Enrich flow addresses with hostname, owner and criticality before clustering.
- Exclude or separately model shared infrastructure services.
- Build communities from several weeks of data and have owners review them.
- Run a new-peer ratio rule and a high-value asset rule in shadow mode first.
- Set thresholds from your own score distribution, not example values.
- Feed approved changes into the analytic to explain expected deviations.
- Test with authorised discovery from a user community at least quarterly.
- Keep a long-term reference baseline alongside the rolling one.
Standards and references
- MITRE D3FEND: Network Traffic Community Deviation (D3-NTCD)
- Vectra Networks: US20160191560A1 Threat detection using daily network traffic community outliers
- Blondel and others: Fast unfolding of communities in large networks
- IETF: RFC 7011 IP Flow Information Export (IPFIX) Protocol
- AWS: VPC Flow Logs limitations
- Microsoft Learn: Virtual network flow logs overview
- Google Cloud: VPC Flow Logs
- Zeek: conn log script reference
Related NHI Mgmt Group resources: NDR Guide · NetFlow and IPFIX Flow Telemetry Guide · UEBA Guide · Zeek Network Monitoring Guide · MITRE D3FEND Guide