An attacker who lands on one host needs the network to do almost everything else: discover neighbours, move laterally, reach a command and control server and carry data out, and network traffic filtering is the control that decides which of those flows are possible at all. MITRE D3FEND names this countermeasure Network Traffic Filtering (D3-NTF) and defines it as "Restricting network traffic originating from any location." It sits under the Isolate tactic as a child of Network Isolation (D3-NI), and is itself the parent of Inbound Traffic Filtering (D3-ITF) and Outbound Traffic Filtering (D3-OTF), with Email Filtering (D3-EF) also shown beneath it on the D3FEND site. This card explains what D3-NTF covers, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to prove the filters do what the rule base says and where filtering is bypassed. It is written for network security engineers, cloud platform teams and detection engineers who own firewall policy.
Key takeaways
- It is the umbrella technique. D3-NTF covers filtering in any direction; the direction-specific detail lives in D3-ITF and D3-OTF, so use this card for the shared design and verification model.
- D3FEND's ATT&CK links are inferred. Because D3-NTF filters Network Traffic, Remote Command, OT Protocol Message and Email, D3FEND relates it to a long list of techniques from lateral movement to exfiltration; these are artefact-based inferences, not proof of coverage.
- Defaults decide most outcomes. Windows Firewall, AWS security groups, Azure network security groups and Google Cloud VPC firewall rules all allow outbound traffic by default, so most estates filter inbound well and outbound poorly.
- A rule base is a claim, not evidence. Verification means generating test flows that should be blocked and confirming both the drop and the log record, on every enforcement layer.
- Port-based rules miss protocol abuse. D3FEND's own considerations warn that traffic on non-standard ports evades filters that do not identify the application protocol from content.
D3-NTF at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-NTF (d3f:NetworkTrafficFiltering) |
| Tactic | Isolate |
| Parent technique | Network Isolation (D3-NI): "Network Isolation techniques prevent network hosts from accessing non-essential system network resources." |
| Child techniques | Inbound Traffic Filtering (D3-ITF), Outbound Traffic Filtering (D3-OTF); the D3FEND site also lists Email Filtering (D3-EF) |
| Sibling techniques under D3-NI | Broadcast Domain Isolation, Directional Network Link, DNS Allowlisting, DNS Denylisting, Encrypted Tunnels |
| Digital artefacts (relation: filters) | Network Traffic, OT Protocol Message, Remote Command (ontology); the D3FEND site also shows Email |
| Typical enforcement points | Host firewalls, network and next-generation firewalls, cloud security groups and firewall rules, Kubernetes network policies, OT protocol firewalls, web and mail gateways |
| Typical evidence | Firewall drop and allow logs, cloud flow logs, Windows Filtering Platform events, rule hit counters |
| Main limitation | Filters only what crosses the enforcement point, by the attributes the rule can see; allowed paths stay open to abuse |
How it works
A filter evaluates each packet or connection against an ordered rule base and allows, drops or rejects it. The attributes available depend on the layer:
- Network and transport (layers 3 and 4): source and destination address, protocol, port, interface and connection state. This is what host firewalls and cloud security groups mostly do.
- Application identity: next-generation firewalls and proxies identify the protocol from content rather than port, and can filter on host name, URL category or, for some OT firewalls, individual protocol commands. D3FEND's references include a patent on firewalls that filter based on protocol commands, and its Remote Command and OT Protocol Message artefacts point to this deeper level.
- Workload identity: host firewalls and some cloud and container platforms can scope a rule to an application, a service tag or a label instead of an address, which survives address changes.
Two design choices matter more than any product feature: the default action (deny by default with allow rules by exception, which NIST SP 800-53 describes in SC-7(5)) and the direction. Inbound filtering protects listening services; outbound filtering limits what a compromised host can reach. Lateral, east-west filtering between internal segments is where many estates have the least control and attackers spend the most time.
Where identity fits
Filtering by address alone treats every process on a host the same. Rules scoped to a service account, a workload identity or an application path are narrower: a build agent may reach a package registry, but an interactive shell on the same server should not. Cloud workloads that call provider APIs with role credentials are a common case where egress filtering limits what a stolen token can be used for; see the Cloud Egress Filtering guide.
ATT&CK techniques D3FEND relates to D3-NTF
Relationship type: inferred only. D3FEND derives these relations because D3-NTF filters an artefact that each technique uses (D3FEND site checked November 2026). They show where filtering can interfere with an attack, not that a given rule set stops it. The list is long, so it is grouped by tactic. Each ID was checked against ATT&CK v20.
| Tactic (ATT&CK v20) | Techniques D3FEND relates to D3-NTF | Where filtering helps |
|---|---|---|
| Lateral Movement | T1021 Remote Services (incl. T1021.001 RDP, T1021.004 SSH), T1570 Lateral Tool Transfer, T1563 Remote Service Session Hijacking, T1210 Exploitation of Remote Services, T1550 Use Alternate Authentication Material (incl. T1550.001, T1550.004), T1534 Internal Spearphishing | East-west rules that allow RDP, SSH, SMB and WinRM only from jump hosts or management subnets |
| Command and Control | T1071 Application Layer Protocol (T1071.001 to T1071.004), T1090 Proxy (T1090.001 to T1090.004), T1573 Encrypted Channel (T1573.001, T1573.002), T1205 Traffic Signaling (T1205.001 Port Knocking), T1102 Web Service, T1568 Dynamic Resolution, T1219 Remote Access Tools, T1095 Non-Application Layer Protocol, T1105 Ingress Tool Transfer, T1572 Protocol Tunneling, T1571 Non-Standard Port, T1001, T1008, T1104, T1132 | Default-deny egress through a proxy; block direct outbound from servers; block unused protocols |
| Exfiltration | T1048 Exfiltration Over Alternative Protocol (T1048.001 to T1048.003), T1567 Exfiltration Over Web Service (T1567.001, T1567.002), T1041, T1020, T1029, T1030, T1011 | Destination allowlists and egress through inspected paths |
| Credential Access and Collection | T1557 Adversary-in-the-Middle (T1557.001, T1557.003), T1110 Brute Force (T1110.003, T1110.004), T1003.006 DCSync, T1558.003 Kerberoasting, T1114.001, T1185 | Block LLMNR, NBT-NS and rogue DHCP paths; restrict directory replication traffic to domain controllers |
| Initial Access and Execution | T1566.001, T1566.002, T1189, T1199, T1190, T1204.001, T1197 BITS Jobs, T1047 WMI | Inbound exposure limits, web filtering, restricting WMI and BITS destinations |
| Persistence, Privilege Escalation, Stealth | T1098.001, T1546.003, T1546.008, T1542.005 TFTP Boot, T1218.003 CMSTP, T1207 Rogue Domain Controller | Block TFTP and unexpected boot services; restrict access to management services |
| Discovery and Impact | T1018 Remote System Discovery, T1565.002, T1498.001, T1498.002, T1499.002 | Limit scan reach between segments; upstream filtering for floods |
D3FEND's tactic labels follow ATT&CK v20, including the reorganised defence evasion tactics; T1207 now sits under Defense Impairment (TA0112). See the technique guides for MITRE ATT&CK T1557 Adversary-in-the-Middle and T1018 Remote System Discovery.
Where it is implemented
| Layer | Implementation class | Default behaviour (from vendor docs) | Logging to enable |
|---|---|---|---|
| Windows host | Windows Firewall (Windows Filtering Platform) | Blocks unsolicited inbound unless a rule allows it; allows outbound unless a rule blocks it; separate Domain, Private and Public profiles | Audit Filtering Platform Connection (event 5157, connection blocked) and the firewall log file |
| Linux host | netfilter with nftables or iptables | No filtering until rules are loaded; locally generated packets pass the output then postrouting hooks, routed packets the forward hook | Log rule statements, sent to the journal or a collector |
| Cloud (listed alphabetically) | AWS security groups; Azure network security groups; Google Cloud VPC firewall rules | AWS: default outbound rule allows all traffic. Azure: AllowInternetOutBound at priority 65001 above DenyAllOutBound at 65500. Google Cloud: implied deny ingress and implied allow egress. All three are stateful. | VPC Flow Logs (AWS), flow logs (Azure), per-rule firewall rules logging (Google Cloud) |
| Network | Firewalls and next-generation firewalls, router access lists | Product specific; zone policies usually start as deny between zones | Session start and end logs with rule ID |
| Application | Forward proxies, secure web gateways, mail gateways, OT protocol firewalls | Product specific | Request logs with user or workload identity |
D3FEND's own implementation examples for the child techniques are iptables and Netfilter (Linux), Windows Firewall, pf (BSD) and OpenWRT. Platform specifics are covered in the Windows Defender Firewall Guide, the Linux Firewall Guide and the Host-Based Firewall Guide.
Implementation steps
- Map the flows that must exist. Build the list from flow logs and application owners, per segment and per workload type. This list becomes the allow rules.
- Choose enforcement layers. Use at least two for high-value systems: a host or cloud-native filter close to the workload, and a network filter at segment or internet boundaries.
- Write allow rules first, then a logged default deny. Put an explicit deny-and-log rule at the bottom so blocks produce evidence.
- Run in audit mode first. Where the platform supports it, log what would be blocked for two to four weeks (an example period) and fix missing allows before enforcing.
- Enforce in rings. Start with a pilot segment, then server tiers, then user devices. Keep the previous rule set exported so rollback is one change.
- Tie rules to owners and expiry. Every rule gets a ticket, an owner and a review date; see the Firewall Rule Review Checklist.
- Protect the filter. Alert on rule changes and on firewall profiles or services being turned off, which ATT&CK tracks as T1686 Disable or Modify System Firewall; see MITRE ATT&CK T1686 Disable or Modify System Firewall.
How to verify it works
Verification proves three things: the block happens, the block is logged, and the allowed path is as narrow as intended.
| Test | Method | Expected result |
|---|---|---|
| Lateral reachability | From a standard workstation, attempt TCP connections to RDP 3389, SMB 445, WinRM 5985 and 5986 and SSH 22 on servers outside the management path | Connections fail; host or network log shows a drop with the rule ID |
| Direct egress from servers | From a server, attempt an outbound HTTPS connection to an internet address that bypasses the proxy | Dropped and logged; only the proxy path works |
| Unused protocols | Attempt outbound DNS to an external resolver, SMB to the internet and TFTP | All dropped |
| Log pipeline | Search the SIEM for the test flows within the expected delay | Each test appears with host, process (where available) and rule |
| Rule drift | Compare the live rule base and cloud rules with the approved baseline | No unapproved any-to-any or internet-wide rules |
Run these from a scheduled breach and attack simulation job or a simple scripted test host, and record results over time. Useful measures, with targets set locally: share of segments with a logged default deny; share of server egress forced through an inspected path; number of rules with any source or any destination; percentage of rules with an owner and review date; median time from rule change to detection of an unapproved change.
Limits, bypasses and failure patterns
- Allowed paths carry the attack. Command and control over HTTPS to a popular cloud service, or tunnelled in DNS, passes any rule that allows those destinations; pair filtering with analysis such as D3-DNSTA DNS Traffic Analysis and D3-NTSA Network Traffic Signature Analysis.
- Port is not protocol. D3FEND notes that non-standard ports circumvent filters that do not detect the application protocol from content (ATT&CK T1571).
- Inbound only. Outbound defaults to allow on the main host and cloud platforms, so an estate that only manages inbound rules has little containment once a host is compromised.
- Address drift. Dynamic addressing and auto-scaling break address-based rules; D3FEND's outbound considerations suggest linking IP address management data to the filtering logic, or scope by tag and identity instead.
- Silent rule rot. Temporary rules left open, and exceptions that widen to "any", erode a filter without anyone noticing; review hit counts and remove unused rules.
- Local administrators. An attacker with administrative rights on a host can change its firewall, so host filters need a network-layer backstop for sensitive segments.
Framework mapping
| Framework | Reference | Fit |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-7(5) Deny by Default, Allow by Exception; AC-4 Information Flow Enforcement | Core control and default-deny enhancement |
| NIST CSF 2.0 | PR.IR-01; DE.CM-01 | Protect networks from unauthorised logical access; monitor networks |
| CIS Controls v8.1 | 4.4 and 4.5 (firewalls on servers and end-user devices); 13.4 (traffic filtering between network segments); 13.10 (application layer filtering) | Host and segment filtering safeguards |
| ISO/IEC 27001:2022 Annex A | A.8.20 Networks security; A.8.22 Segregation of networks | Network controls and segregation |
| ATT&CK mitigations | M1037 Filter Network Traffic; M1030 Network Segmentation | See M1037 Filter Network Traffic and M1030 Network Segmentation |
Related countermeasures
- Inbound Traffic Filtering (D3-ITF): the inbound child. See D3-ITF Inbound Traffic Filtering.
- Outbound Traffic Filtering (D3-OTF): the egress child. See D3-OTF Outbound Traffic Filtering.
- Broadcast Domain Isolation (D3-BDI): reduces who can reach whom at layer 2. See D3-BDI Broadcast Domain Isolation.
- DNS Denylisting (D3-DNSDL): filtering at name resolution. See D3-DNSDL DNS Denylisting.
- Encrypted Tunnels (D3-ET): the sibling that protects permitted flows. See D3-ET Encrypted Tunnels.
Practitioner checklist
- Document required flows per segment and workload before writing rules.
- End every rule base with a logged default deny, inbound and outbound.
- Override the allow-all outbound defaults on servers and cloud workloads.
- Restrict RDP, SSH, SMB and WinRM to management sources.
- Force server internet access through an inspected proxy path.
- Enable Windows Filtering Platform auditing, cloud flow logs and firewall logs into the SIEM.
- Give every rule an owner, ticket and review date; remove rules with no hits.
- Alert on firewall rule changes and disabled firewall profiles.
- Run scheduled block tests and keep the results as evidence.
Standards and references
- MITRE D3FEND: Network Traffic Filtering (D3-NTF)
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7, AC-4)
- Microsoft Learn: Windows Firewall overview
- Microsoft Learn: Event 5157, the Windows Filtering Platform has blocked a connection
- nftables wiki: Netfilter hooks
- AWS: Control traffic to your AWS resources using security groups
- Microsoft Learn: Azure network security groups overview
- Google Cloud: VPC firewall rules
Related NHI Mgmt Group resources: Firewall Management Guide · Network Segmentation and Microsegmentation · Cloud Egress Filtering · MITRE D3FEND Guide