Most organisations can list their firewalls, but few can say which flows those firewalls, security groups and proxies actually allow between any two systems. MITRE D3FEND names the countermeasure that closes this gap Network Traffic Policy Mapping (D3-NTPM) and defines it as follows: "Network traffic policy mapping identifies and models the allowed pathways of data at the network, transport, and/or application levels." It sits under the Model tactic as a child of Network Mapping (D3-NM), and D3FEND lists four synonyms: Firewall Mapping, IPS Policy Mapping, Web Security Gateway Policy Mapping and DLP Policy Mapping. This page explains what a traffic policy model contains, where the data comes from, how to keep it current and how it feeds filtering, isolation and detection work. It is written for network security engineers, cloud platform teams and security architects who already run firewalls and want an accurate model of what they permit.
Key takeaways
- It models intent as configured, not traffic as seen. D3-NTPM is about the allowed pathways that policy creates; flow logs tell you what used those paths, and the gap between the two is where the useful findings sit.
- Every enforcement point counts. D3FEND's synonyms make the scope explicit: firewalls, IPS policy, web security gateways and DLP policy all define allowed pathways, alongside cloud security groups, network ACLs and Kubernetes NetworkPolicy.
- D3FEND's ontology ties it to access control configuration. The ttl says the technique maps Access Control Configuration and queries Network Agent; its ATT&CK relations are inferred from that shared artefact, not from direct testing.
- Path analysis beats rule reading. A single rule tells you little; the question that matters is whether source A can reach destination B on port C after every hop, NAT and policy layer is applied.
- The model decays with every change. Unless the map is rebuilt from configuration on each change, it stops matching reality within weeks and gives false assurance.
D3-NTPM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-NTPM (d3f:NetworkTrafficPolicyMapping) |
| Tactic | Model |
| Parent technique | Network Mapping (D3-NM) |
| Ontology relations | maps Access Control Configuration; queries Network Agent |
| Synonyms in D3FEND | DLP Policy Mapping, Firewall Mapping, IPS Policy Mapping, Web Security Gateway Policy Mapping |
| D3FEND reference | Cisco ASR 9000 Series access list command reference (ACL entries with permit or deny actions and filter elements) |
| Typical data sources | Firewall and router configuration exports, cloud security group and network ACL APIs, route tables, proxy and gateway policy, Kubernetes NetworkPolicy objects, flow logs for validation |
| Output | A queryable model of permitted source, destination, protocol and port combinations, with the rule that permits each one |
| Main limitation | Shows what is allowed, not who or what is actually using it; identity-aware and application-layer policy is hard to normalise |
What a traffic policy model contains
D3FEND's parent technique, Network Mapping, covers identifying "the physical layer, network layer, and data exchange layers" and determining "allowed pathways through that network". D3-NTPM is the part that answers the last clause. A usable model has four layers, built in this order:
- Zones and address objects: named segments (user, server, management, OT, partner, internet), the CIDR ranges and cloud network constructs that belong to each, and the object groups the policies reference.
- Enforcement points: every device or service that permits or denies traffic, with its position in the path: perimeter and internal firewalls, router ACLs, cloud security groups and network ACLs, host firewalls, service mesh policy, web proxies and secure web gateways, IPS policy and DLP policy.
- Normalised rules: each rule reduced to source, destination, protocol, port or application, action and hit count, with object groups expanded so overlapping and shadowed rules become visible.
- Computed paths: the end-to-end result for a given source and destination after routing, NAT and every enforcement point on the way, which is what auditors, architects and incident responders actually ask about.
The fourth layer is what separates D3-NTPM from a rule review. A rule base review (see the Firewall Rule Review Checklist) asks whether each rule is justified; policy mapping asks what the combination of all rules permits.
Levels D3FEND names
| Level | What the policy expresses | Typical enforcement point | Mapping difficulty |
|---|---|---|---|
| Network | Source and destination addresses, routes, zones | Router ACLs, cloud network ACLs, route tables | Low: deterministic once objects are expanded |
| Transport | Protocol and port (for example TCP 443, UDP 53) | Stateful firewalls, security groups, host firewalls, Kubernetes NetworkPolicy | Low to medium: state tracking and port ranges complicate analysis |
| Application | URL categories, application signatures, content and data rules | Next generation firewalls, web security gateways, IPS and DLP policy | High: vendor-specific objects and dynamic categories resist normalisation |
Where the data comes from
A traffic policy model is only as complete as the enforcement points it ingests. D3FEND's ontology says the technique queries Network Agent, which its glossary describes as software on a network node "that transmits information back to a collector agent or management system", such as an SNMP agent. In practice the inputs are configuration APIs and exports rather than SNMP alone.
- On-premises network devices: running configuration exports from firewalls, routers and switches, including ACLs, NAT and routing tables. The D3FEND reference for this technique is a router access list command reference, which describes each ACL as entries with a permit or deny action and a filter element.
- Cloud networks: cloud providers expose configuration analysis services that compute paths for you. Platforms are listed alphabetically. AWS Reachability Analyzer is described by AWS as a configuration analysis tool that tests connectivity between a source and destination and, where a path is blocked, identifies the blocking component such as a security group, network ACL, route table or load balancer. Azure Network Watcher offers IP flow verify, NSG diagnostics, effective security rules and a topology view. Google Cloud Connectivity Tests run a static configuration analysis across firewall rules and policies, routes, peering, NAT and VPN, and where supported a live data plane analysis with probe packets.
- Containers: Kubernetes NetworkPolicy controls traffic at layers 3 and 4, and the cluster's network plugin must support it for the policy to be enforced. A cluster where no policy selects a pod leaves that pod open to all traffic, so the model must record which namespaces have no policy at all.
- Application-level gateways: proxy and secure web gateway policy, DLP rules and IPS policy assignments. These are usually exported from the management console and mapped by hand or by the vendor's own reporting.
- Validation data: flow logs (cloud VPC or virtual network flow logs, firewall session logs, NetFlow or IPFIX) are not the model, but they show which modelled paths are used and expose traffic the model says is impossible.
Commercial firewall policy management and network security posture tools automate the ingestion and path computation across vendors; the Firewall Management Guide covers the operational side. Whether built in house or bought, the requirement is the same: every enforcement point on every path, refreshed from source rather than from documentation.
ATT&CK techniques D3FEND relates to D3-NTPM
D3FEND shows the following relations on the technique page and marks them as "inferred, experimental". They come from the shared Access Control Configuration artefact, not from evidence that mapping policy detects or prevents each technique. The value of D3-NTPM against them is indirect: a current model of permitted pathways is the baseline against which unauthorised policy changes become visible.
| ATT&CK tactic (v20) | Technique | Why the shared artefact matters |
|---|---|---|
| Privilege Escalation | T1548.001 Setuid and Setgid; T1548.005 Temporary Elevated Cloud Access | Both alter access control configuration that a policy model records |
| Privilege Escalation, Stealth | T1134.005 SID-History Injection | Changes the effective permissions an access model assumes |
| Defense Impairment, Privilege Escalation | T1484 Domain or Tenant Policy Modification | Policy changes made through directory or tenant settings rather than the firewall console |
| Defense Impairment | T1222 File and Directory Permissions Modification | Permission changes on configuration objects |
| Defense Impairment, Persistence, Credential Access | T1556.009 Conditional Access Policies | Identity-layer access policy that gates network and application paths |
| Credential Access | T1552.006 Group Policy Preferences | Credentials held in policy configuration |
| Discovery | T1615 Group Policy Discovery | Adversaries reading the same policy data defenders model |
In our view at NHI Mgmt Group, the more direct practical link is with network reconnaissance: an adversary running T1046 Network Service Discovery is discovering the same allowed pathways empirically. That is our reading, not a D3FEND mapping. See also the MITRE ATT&CK T1484 Domain or Tenant Policy Modification Guide.
How to build and maintain the map
- Inventory enforcement points. Start from the network inventory and cloud account list, and record every policy engine, including host firewalls and DLP. Missing one enforcement point makes every computed path through it wrong.
- Define zones before rules. Agree the zone model with the architecture owners so that results read as "user zone can reach database zone on TCP 1433" rather than as raw addresses.
- Ingest configuration automatically. Pull configuration from device and cloud APIs on a schedule and on every change ticket, using read-only credentials. Store each snapshot so you can compare versions.
- Normalise and expand. Expand object groups, resolve NAT, and flag rules with any source, any destination or any service, shadowed rules and rules with zero hits over a review period.
- Compute the paths that matter. Begin with crown-jewel systems and regulated data stores: which zones and which internet sources can reach them, on which ports, through which rules.
- Compare against intended policy. Write the intended segmentation as testable statements (for example, "no path from user zone to OT zone") and evaluate them on each snapshot. A violation is a finding with a named rule.
- Validate with traffic. Join flow logs to the model: flows on unmodelled paths indicate a missing enforcement point or a stale snapshot; modelled paths with no flows for months are candidates for removal.
- Feed change control. Run the intended-policy statements against proposed changes before they are approved, so the model blocks bad changes rather than just reporting them.
Rollback is simple because D3-NTPM is read-only: the mapping process changes nothing on the network. The risks sit in the ingestion credentials, which are covered below.
Where identity fits
The configuration collector needs credentials to every firewall, router and cloud account in scope, which makes it a high-value non-human identity. Give it read-only roles, store its secrets in a vault, rotate them, and monitor its sessions like an administrator's; the Cloud Workload Identity Guide covers federation in place of static keys for cloud APIs. A second identity angle is policy that uses identity rather than addresses, such as security group references, service mesh identities or user-based firewall rules. Map those to the workloads and accounts they resolve to, or the model will miss paths that open when a service account is added to a group.
Decision guidance
| Situation | Approach | Trade-off |
|---|---|---|
| Small estate, one firewall vendor, one cloud | Use the vendor's policy reports and the cloud provider's path analysis tool; keep intended-policy statements in a short list tested quarterly | Low cost; manual joins between on-premises and cloud paths |
| Hybrid estate, several firewall vendors | A multi-vendor policy management or network security posture platform that computes end-to-end paths | Licence and integration cost; quality depends on parser support for each device type |
| Heavy Kubernetes or service mesh use | Map NetworkPolicy and mesh authorisation policy per namespace, with default-deny coverage as the first metric | Label-based policy changes with deployments, so mapping must run in the pipeline |
| Regulated segmentation scope (for example cardholder data) | Path proofs for the scope boundary on every change, retained as audit evidence | Requires disciplined zone definitions and change integration |
How to verify it works
- Known-path test: pick paths you know are open and closed, query the model, and confirm the answers match a live test from the source host.
- Change detection test: add a temporary permissive rule in a test zone and confirm the next snapshot reports the new path and the violated intent statement.
- Flow reconciliation: sample flow logs and confirm every observed flow maps to a modelled path and a permitting rule.
Example metrics (illustrative targets, not a standard):
- Percentage of enforcement points ingested automatically (aim for all of them).
- Age of the oldest configuration snapshot in the model.
- Number of intended-policy violations open, and their age.
- Percentage of observed flows that map to a modelled path.
- Count of rules with any source, any destination or any service.
- Kubernetes namespaces with no NetworkPolicy selecting their pods.
Limits and common failure patterns
- Missing enforcement points: host firewalls, cloud network ACLs or a forgotten partner VPN are left out, so paths look closed when they are open, or the reverse.
- Documentation instead of configuration: maps drawn from design documents describe what was intended years ago. Only configuration pulled from the device is evidence.
- Ignoring the application layer: a path shown open on TCP 443 may be restricted by URL category or DLP policy, and a path blocked at layer 4 may be tunnelled through an allowed proxy. Record application-level policy even where it cannot be fully normalised.
- Static snapshot: a one-off mapping exercise is out of date at the next change window. Tie refresh to change tickets.
- Trusting a security appliance's own credentials: the Capital One breach showed how a credential available to a firewall host can become the path to data; see Capital One Breach 2019. A policy map should include what the enforcement points themselves can reach.
- Treating inferred ATT&CK relations as coverage: the D3FEND relations above are inferred through a shared artefact and do not show that policy mapping detects those techniques.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03 | Representations of authorised network communication and internal and external data flows are maintained |
| NIST CSF 2.0 | PR.IR-01 | Networks and environments are protected from unauthorised logical access and usage |
| NIST SP 800-53 Rev. 5 | AC-4 Information Flow Enforcement; SC-7 Boundary Protection | The controls whose configured state the model records |
| NIST SP 800-53 Rev. 5 | CA-3 Information Exchange; CM-7 Least Functionality | Approved exchanges and unnecessary ports and services, both checkable against the model |
| CIS Controls v8.1 | Safeguard 12.4 Establish and Maintain Architecture Diagram(s) | Network architecture documentation kept current |
| ISO/IEC 27001:2022 Annex A | A.8.20 Networks security; A.8.22 Segregation of networks | Network controls and segregation the map evidences |
Related countermeasures
D3-NTPM is the Model step that the Isolate and Harden techniques depend on. Siblings under Network Mapping include Network Vulnerability Assessment (see D3-NVA Network Vulnerability Assessment) and the logical and physical link mapping techniques; the parent is covered in the MITRE D3FEND Network Mapping Implementation Guide. The policy itself is enforced by D3-NTF Network Traffic Filtering, D3-ITF Inbound Traffic Filtering and D3-OTF Outbound Traffic Filtering, and D3-CAA Connection Attempt Analysis uses the model to judge which connection attempts are unexpected.
Practitioner checklist
- List every enforcement point, including host firewalls, cloud network ACLs, proxies, IPS and DLP policy.
- Agree a zone model and map address ranges and cloud networks to it.
- Pull configuration from source automatically, with read-only, vaulted collector credentials.
- Expand objects and resolve NAT so the model computes end-to-end paths.
- Write intended segmentation as testable statements and evaluate them on every snapshot.
- Reconcile flow logs against the model at least monthly.
- Run proposed firewall and cloud network changes through the model before approval.
- Record Kubernetes namespaces without NetworkPolicy and identity-based rules with their resolved members.
Standards and references
- MITRE D3FEND: Network Traffic Policy Mapping (D3-NTPM)
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Cisco: ASR 9000 Series Access List Commands
- AWS: What is Reachability Analyzer
- Microsoft Learn: Azure Network Watcher overview
- Google Cloud: Connectivity Tests overview
- Kubernetes: Network Policies
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Network Segmentation Guide · Firewall Management Guide · M1030 Network Segmentation