D3-NVA Network Vulnerability Assessment: Judging Risk Across the Whole Network

A scanner report lists vulnerable hosts one by one, but an attacker experiences the network as a connected whole, where a modest flaw on a reachable host can open the way to a critical one. MITRE D3FEND names the countermeasure that addresses this Network Vulnerability Assessment (D3-NVA) and defines it as relating "all the vulnerabilities of a network's components in the context of their configuration and interdependencies", adding that it "can also include assessing risk emerging from the network's design as a whole, not just the sum of individual network node or network segment vulnerabilities." It sits under the Model tactic as a child of Network Mapping (D3-NM). This page explains how D3-NVA differs from ordinary scanning, what inputs it needs, how reachability changes prioritisation and how to run it without breaking production. It is for vulnerability management leads, network security engineers and security architects who already scan and want to rank findings by what the network actually exposes.

Key takeaways

• It is assessment in context, not scanning. D3-NVA combines per-node findings with configuration and dependencies; a scanner is one input, not the technique.
• Design-level risk is in scope. D3FEND explicitly includes risk from the network's design as a whole, such as flat segments, single points of failure and management planes reachable from user zones.
• Reachability changes priority. D3FEND's reference describes finding every resource a vulnerable resource can reach or be reached by, then prioritising remediation on that basis.
• D3FEND lists no ATT&CK relations. The technique page shows none; any mapping to adversary behaviour on this page is labelled as our view.
• Output must change a decision. The useful result is a short, ranked list of fixes (patch, rule change or segment change) with the paths each one closes.

D3-NVA at a glance

How it differs from vulnerability scanning

NIST SP 800-115 treats vulnerability scanning as one technique among several for finding weaknesses in systems and networks. D3-NVA sits a level above: it takes the scan output and asks what the findings mean together.

The D3FEND reference describes this approach: identify a vulnerable resource, determine "all computer resources in the networked computer system that are accessible from, or are accessed by, the vulnerable computer resource", and prioritise the remediation action accordingly. The word "safe" in its title points to the second half of the problem: a remediation that breaks the application the resource serves is not a usable fix, which is why dependency data belongs in the assessment.

Inputs the assessment needs

• Asset and network inventory: every node, its segment and its owner. See the Asset Inventory and CMDB Security Guide.
• Vulnerability findings: authenticated scans where possible, plus agent data and network device findings (network devices are covered in the Vulnerability Management for Network Devices Guide).
• Traffic policy model: which sources can reach which services, from D3-NTPM Network Traffic Policy Mapping. Without it, reachability is guessed.
• Exploitability signals: CISA's Known Exploited Vulnerabilities catalogue, EPSS probabilities and the CVSS vector (see the EPSS Guide and CVSS v4 Guide).
• Dependencies and criticality: which business services depend on each node, so a finding on a shared database outranks the same finding on an isolated test box. Operational context comes from D3-ODM Operational Dependency Mapping.
• Credential relationships: where the same service account, local administrator password or SSH key is valid across many hosts, one compromised host reaches all of them regardless of segmentation.

Where identity fits

Credentials are the dependency most often missing from network risk models. A service account with logon rights across a server tier, a shared SNMP community string on every switch, or a scanner's own privileged credential turns separate hosts into one blast radius. Include non-human identities and their reach as edges in the model; the Identity Attack Paths Guide covers identity graphs in depth. The authenticated scanner account is itself a high-value identity: scope it, vault it and monitor its use.

How to run a network vulnerability assessment

1. Set scope and rules of engagement. Agree segments, scan windows, fragile systems (OT, medical, legacy) that must be excluded or assessed passively, and who to call if something fails.
2. Refresh the inputs. Pull a current inventory, a current policy snapshot and recent scan results. Record their dates; an assessment on month-old inputs should say so.
3. Build the reachability graph. Nodes are assets and services; edges are permitted network paths and credential relationships. Mark internet-facing entry points and the crown-jewel targets.
4. Overlay vulnerabilities. Attach findings to nodes with exploitability data. Treat any KEV-listed finding on an internet-reachable node as an immediate item.
5. Find design-level risk. Look for patterns no single scan reports: management interfaces reachable from user zones, flat segments mixing tiers, dual-homed hosts bridging zones, single points of failure, and credentials valid across zones.
6. Rank remediation by paths closed. For each candidate fix, count the entry-to-target paths it removes. A firewall rule change can close more risk in a day than a patch campaign closes in a quarter.
7. Check fixes are safe. Before blocking a path or taking a service down, check dependency data for legitimate users of that path. Use change control, test in a pilot segment, and keep the prior configuration for rollback.
8. Re-assess after change. Rebuild the graph and confirm the targeted paths are closed and no new ones opened.

Decision guidance

The Risk-Based Vulnerability Management Guide covers prioritisation programmes in general; D3-NVA adds the network structure that such programmes often lack.

ATT&CK relations

The D3FEND technique page for D3-NVA lists no related ATT&CK techniques, and none are claimed here as a D3FEND mapping. In our view at NHI Mgmt Group, the assessment models the same ground an adversary explores with T1046 Network Service Discovery and T1590 Gather Victim Network Information, so running it first lets defenders see their network as a discovery-stage adversary would. That is our reading, not D3FEND's.

How to verify it works

• Penetration test comparison: compare the paths found by an authorised penetration test with the paths the model predicted. Paths the testers used that the model missed point to missing inputs.
• Incident replay: for past incidents, check whether the model would have ranked the exploited path highly.
• Coverage checks: confirm every segment in the inventory appears in the graph and every scanned host has a reachability record.

Example metrics (illustrative, not a standard):

• Number of internet-to-crown-jewel paths, tracked over time.
• KEV-listed findings on internet-reachable nodes, and their mean age.
• Percentage of remediations chosen by paths closed rather than by base score.
• Share of assets with authenticated scan coverage.
• Age of the inventory and policy data the latest assessment used.

Limits and common failure patterns

• Scanner output presented as the assessment: a ranked CVSS list with no reachability or dependency data is scanning, not D3-NVA.
• Stale reachability: a policy model from last quarter misses the rule opened last week. Record input dates on every report.
• Ignoring network devices themselves: firewalls, VPN gateways and load balancers are nodes with vulnerabilities, often internet-facing; see Exploited Vulnerability Breaches for incidents where an exploited vulnerability was the way in.
• Unsafe remediation: blocking a path or patching a shared service without dependency data causes outages, which erodes support for the programme.
• Leaving out credentials: segmentation that looks strong on a network diagram fails when one service account logs on to every tier.
• Active scanning of fragile systems: OT and medical devices can fail under scanning; see the ICS Advisory Triage and OT Vulnerability Management Guide.

Framework mapping

Related countermeasures

D3-NVA is a sibling of D3-NTPM Network Traffic Policy Mapping under Network Mapping (see the MITRE D3FEND Network Mapping Implementation Guide). System Vulnerability Assessment (D3-SYSVA) does the equivalent at system level. Findings are acted on through Harden and Isolate techniques such as D3-NTF Network Traffic Filtering and D3-CDP Change Default Password.

Practitioner checklist

• Agree scope, exclusions and contacts before any active testing.
• Use authenticated scans with a scoped, vaulted scanner identity.
• Build reachability from configuration, not diagrams.
• Add credential relationships (shared service accounts, local admin passwords, keys) as edges.
• Flag KEV-listed findings on internet-reachable nodes for immediate action.
• Look for design-level risk: exposed management planes, dual-homed hosts, flat segments.
• Rank fixes by paths closed and check dependencies before each change.
• Re-run the assessment after remediation and record input dates.

Standards and references

• MITRE D3FEND: Network Vulnerability Assessment (D3-NVA)
• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• CISA: Known Exploited Vulnerabilities Catalog
• US Patent 11637861: Reachability graph-based safe remediations for security of on-premise and cloud computing environments
• NIST: IR 8179 Criticality Analysis Process Model

Related NHI Mgmt Group resources: MITRE D3FEND Guide · Vulnerability Management Guide · Attack Surface Management Guide · M1016 Vulnerability Scanning