NIST 800-207 Has a Network Requirement Most Agencies Are Still Missing

TL;DR
However, most of the Zero Trust deployments in the federal government sector have been successful in improving the pillars of identity and device but still fail to meet the requirements for network visibility that are stated in the NIST SP 800-207 publication. This is because there is no constant visibility provided at the wire level for East-West traffic, encryption, and unagented devices.
Introduction
A large amount of money has been invested by the United States government in Zero Trust. There have been continuous improvements made to the identity platform. The device continues to be compliant. The policy engine runs in real time. However, even after all that, attackers go through the network undetected for several months. This is not a policy-related problem but a visibility problem.
Does Zero Trust Really Assume You Can See Everything?
The central tenet of NIST SP 800-207 architecture, forming the backbone of any Zero Trust model within the framework of the U.S. government, is simple: an organization must be able to observe all activity taking place on its network. This does not just mean observing activity at the perimeter and at controlled endpoints; this also means observing all activity between hosts, observing all encrypted traffic, all communication through containers, and all activity by unmanaged systems without an agent. Full observability is crucial to the successful operation of the trust algorithm. The Policy Engine enforces continuous access control using only this data. Once the network starts to become invisible, the trust algorithm will need to run with limited visibility.
Where Do Most Federal Zero Trust Programs Actually Stand Today?
The current status of Zero Trust adoption in the federal government agencies shows that Identity and Devices have been adopted, but the Networks have not been fully adopted yet. This is clearly demonstrated by the CISA Zero Trust Maturity Model, where the maturity levels of all the components are depicted. Among the two components yet to be fully adopted, Networks seem to be lagging behind significantly.
Why Can’t Device Logs Alone Solve the Problem?
The logs of the device are not enough to solve this problem. The adversaries know about this problem.
Here is an example of the situation. In the framework of the MITRE ATT&CK there are particular attacks that will disable logging for the device or the application.
T1070 – Indicator Removal.
T1562 – Impair Defenses.
This is not just a theory. The state actors use these methods when they attack the federal network. They disable logging on the endpoints, erase auditing logs and event logs and continue their lateral movement undetected within the networks considered secure by the entities.
If the attacker has already hacked the endpoint, disabled EDR and cleaned the logs he has not changed anything in wire-level data. The packets were captured, the network traffic passed through the network. This information exists, but only if somebody captures it.
Data captured from the packet are different from the logs of the device. Data captured from packets are wire-level data, which does not depend on the logs created by some monitoring tool. This means the true view of what happened in the network is captured.
That’s why the trust algorithm can’t use the network logs as the input. That’s the exact problem that the Networks pillar tries to solve.
What Does Closing the Networks Gap Actually Look Like?
The Aviz Deep Network Observability pipeline captures traffic across every environment, data center, cloud, containers, field offices, tactical edge, and delivers two outputs from a single capture point:
Figure 1: Aviz Deep Network Observability intelligent fabric feeding optimized raw packets and enriched packet-derived telemetry to the Security and observability tools stack
Optimized raw packets for your security detection tools. The NDR and IDS solutions analyze clean and filtered packets, where there are no duplicate packets, which would simply overload the tool’s capabilities but rather packets that can be processed by the tool as designed. Since these packets are observed directly from the wire, the detection capabilities are still valid even when host-based protection is evaded on a compromised host.
Figure 2: Malware and threat detection on Security Onion (Suricata-IDS) by receiving Optimized raw packets from Aviz Deep Network Observability Intelligent Fabric
Packet-derived metadata to your SIEM and analytics platforms. Flow information, session information, visibility into DNS activity, identification of applications, and TLS posture information are gathered in an enriched fashion and made available in open formats to your existing platform. This provides a constant stream of network activity that feeds the trust algorithm as the per-session input, from the moment the information becomes available in the network.
One capture point. Both outputs. No additional tool displacement.
What Does the Evidence Show?
In a sample implementation using this architecture, an IDS capable of analyzing optimized raw packets from the Aviz DNO fabric was able to detect attack behaviors, C2 beaconing check-ins, credential harvest attacks against Active Directory, lateral movement across internal hosts, and C2 communications for malware. These all took place in East-West traffic that was never captured by the perimeter. What’s important about all of these is that they cannot be discerned through device logging alone. This is not a marketing statement; this is the reality of a properly implemented network visibility layer.
Why Is the Networks Pillar More Than a Checkbox?
A Zero Trust architecture cannot be fully implemented simply by operating a policy engine. It can only be fully implemented by having a policy engine that utilizes true, ongoing, packet-level proof of everything that is really going on within the whole network, including east-west traffic, TLS encryption, and even those agentless devices that older architectures can’t see into. The network is the battlefield on which attackers operate, and it needs to be the very last thing they have cover in. Aviz Deep Network Observability offers the network observability and telemetry component upon which the Zero Trust architecture depends.
Conclusion
While NIST SP 800-207 foresees a state of total visibility within an enterprise, there are still many agencies that struggle with significant gaps in their networks. Although Identity and Devices controls have improved, Networks is still the vital gap that prevents the successful implementation of Zero Trust architecture. Visibility at wire level and telemetry from packets are the means of proving the necessary facts to increase trust and reveal lateral movement.
By closing the Networks gap, organizations move closer to fulfilling all the promises of Zero Trust, continuous verification based on total and credible evidence.
Frequently Asked Questions
What network visibility requirement does NIST SP 800-207 establish?
NIST SP 800-207 requires organizations to observe all activity on their network, including East-West traffic between hosts, encrypted traffic, container communications, and activity from unmanaged systems without an agent. Full observability is essential for the trust algorithm to enforce continuous access control.
Why are device logs alone insufficient for Zero Trust compliance?
Attackers can disable endpoint logging and erase audit trails using techniques like MITRE ATT&CK T1070 and T1562, allowing lateral movement to go undetected. Wire-level packet data exists independently of host-based logs and captures what actually traversed the network regardless of endpoint tampering.
Which Zero Trust pillar do most federal agencies still struggle with?
According to the CISA Zero Trust Maturity Model, most federal agencies have made progress on Identity and Devices but have not fully adopted the Networks pillar. Network visibility remains the most significant gap in current Zero Trust deployments.
What are the two outputs of the Aviz Deep Network Observability pipeline?
The Aviz DNO pipeline delivers optimized raw packets for security detection tools like NDR and IDS, and packet-derived metadata for SIEM and analytics platforms. Both outputs come from a single capture point across data centers, cloud environments, containers, and field offices.
What types of threats can wire-level packet capture detect that device logs cannot?
In sample implementations, packet-level analysis detected C2 beaconing, credential harvest attacks against Active Directory, lateral movement across internal hosts, and malware communications. These threats occurred in East-West traffic that never reached the perimeter and could not be identified through device logging alone.
Why does the trust algorithm require wire-level network data?
The Policy Engine in a Zero Trust architecture enforces continuous access control using real-time observability data. When network visibility is incomplete, the trust algorithm operates with limited inputs, reducing its ability to detect and respond to threats accurately.
What makes packet-derived data different from device logs?
Packet-derived data is captured directly from the wire and does not depend on logging tools running on monitored systems. This makes it a reliable and tamper-resistant source of ground truth about network activity.
Ready to Strengthen Your Zero Trust Architecture? Contact Aviz Networks to learn how Deep Network Observability can provide the packet-level visibility and telemetry required to support NIST SP 800-207 and accelerate Zero Trust maturity across your environment.





