Comments on NIST Special Publication 1800-35B, ‘Implementing a Zero Trust Architecture’ Volume B

Originally published by Gigamon here.

Written by Ian Farquhar and Orlie Yaniv, Gigamon.

Editor’s note: As a supplier of network software and hardware to multiple U.S. government agencies, Gigamon reviews and comments on many draft standards and documents issued by government agencies. This has accelerated as Zero Trust became a key focus, not only within the U.S. federal government but also for other governments worldwide, enterprises, and even service providers. It’s safe to say that Zero Trust is a major driving force in security architecture.

To this end, Gigamon has decided to publish our feedback on these government documents here on this blog. The purpose of this is twofold:

• To explain our strategic thinking around this major shift in the way we architect our INFOSEC infrastructure
• To elicit comments and feedback from security architects, with the aim of enhancing the practicality and deployability of Zero Trust architectures (ZTAs)

While NIST SP 800-207 has given us an excellent definition of what Zero Trust architecture is, and both CISA and DISA have significantly augmented these, there are so many ways this can be achieved, and those discussions are worthwhile and mutually beneficial. Please feel free to do so by emailing Ian (ian dot farquhar at gigamon.com) and Orlie (orlie dot yaniv at gigamon.com) or by participating in the Gigamon Community’s Public Sector group.

You can download the original draft document from NIST here.

Lastly, we welcome your feedback on whether these comments are beneficial. Our aim is to publish here moving forward when the response seems beneficial.

Gigamon appreciates the opportunity to comment on NIST Special Publication 1800-35B, “Implementing a Zero Trust Architecture” Volume B. We fully support the NCCOE’s progress in developing standards-based ZTA implementations and hope to participate in future builds as the NCCOE evolves to the “walk” and “run” phases.

We have identified inconsistencies between the guidance in NIST SP 800-207 “Zero Trust Architecture” and SP 1800-35B with respect to the characterization of endpoint detection and response (EDR) capabilities and the role of telemetry derived from analyzing network traffic. It appears that in the SP 1800-35B, the project team created a new supporting component called endpoint detection and response/endpoint protection platform (EDR/EPP) that is not referenced in SP 800-207 but is nonetheless considered on par with ICAM, security analytics, and data security.[1] Analysis of telemetry from network traffic, on the other hand, is subsumed within Security Analytics in SP 1800-35B, and no mention is made of the SP 800-207 network requirement that “[T]he enterprise can observe all network traffic.”[2] This oversight suggests or implies that the analysis of network traffic is less valuable than the analysis of telemetry from the endpoint, which is absolutely not the case.

As explained below, not only are the elevation of EDR/EPP to its own supporting component and denigration of network traffic analysis inconsistent with SP 800-207, but they have negative security implications, particularly when it comes to an organization’s ability to detect and stop sophisticated adversaries that are capable of compromising endpoints, EDR, and the telemetry they generate. When all else fails, the truth is in the packet, because even if adversaries evade EDR and modify or tune down logs, they must generate network traffic to conduct nefarious activity. This traffic can be observed and analyzed.[3]

As such, analysis of network traffic provides a powerful mechanism for validating the integrity of logs generated by network components and vice versa. In a ZTA, where nothing is trusted, this is essential. To break down the argument further, the emphasis on EDR/EPP in SP 1800-35B is problematic because:

1. Not all endpoints are able to run EDR/EPP tooling, including major infrastructure (such as mainframes) that may be highly data laden, some BYOD devices, and IoT/OT/ICS/SCADA.
2. Adversary tactics, techniques, and procedures (TTPs) include disabling, minimizing, modifying, and spoofing logs and telemetry from inside the host. While OMB M-21-31 addresses log integrity through the implementation of various security controls, those measures focus on protecting the logs rather than the assurance of the component generating the log. If a component is compromised, how can an organization trust the log? And without the analysis of network traffic, how would an organization detect a compromised endpoint? While EDR vendors will validly claim they will implement countermeasures to prevent such an attack, their agents run inside the blast radius of the attack, and these countermeasures may be compromised. A ZTA should account for these possibilities.
3. Certain high maturity techniques, especially those which are delivered via the supply chain, may not be discernible to an EDR agent or detected via log analysis. Examples of such attacks are “below the firmware” and implant-style attacks.
4. Fundamentally, without a mechanism for ensuring EDR and log integrity, the implementation appears to implicitly trust EDR/EPP tooling, a fundamental concept that a Zero Trust architecture seeks to eliminate.

Conversely, traffic inspection, which may be addressed through a network detection and response (NDR) or other traffic analysis solutions,[4] can fill the EDR gaps and mitigate risk associated with EDR and logs. Specifically:

1. No agent is needed, nor is logging required, and anything that generates network traffic can be monitored. No matter where an adversary implant runs, the traffic it needs to generate to perform its function (C2, discovery, exfiltration) remains visible on the network.
2. Monitoring occurs outside the blast radius of the compromise, and any adversary activities that generate network traffic, including but not limited to EW lateral movement and their C2 channel, will be visible to an NDR or traffic analysis tool.
3. NDR/traffic analysis, EDR/EPP, and logs can be deployed so that each capability functions as a cross-check on the others, thereby eliminating implicit trust in any one capability. Gartner refers to this deployment model as the “SoC Triad,” and the approach makes sense in the ZTA context.[5]

As the implementation described in SP 1880-35B incorporates an NDR tool, Gigamon recommends either making that tool a supporting component on par with EDR/EPP or subsuming EDR/EPP within another supporting component described in SP 800-207. This latter approach would be more consistent with SP 800-207, which does not describe EDR/EPP as its own supporting component. In fact, SP 800-207 only uses the word “endpoint” twice and does not even mention the phrase “endpoint detection and response.” As the NCCOE considers future ZTA implementations, we encourage consideration of a network-focused approach built around traffic analysis and logging rather than EDR/EPP.

In the spirit of collaboration, transparency, and stimulating a healthy debate amongst experts, Gigamon will be publishing these comments on our website as a blog. Gigamon invites reviewers of this response to provide comments and peruse Gigamon’s previous comments.

Notes

[1] See SP 1800-35B at Figure 4-1 General ZTA Reference Architecture on page 46 at line 1666.

[2]See SP 800-207 3.4.1 (3) at page 21.

[3] While network evasion techniques exist, they can be defeated. Network evasion techniques typically work better for low volumes of communications but fail with the high volumes of traffic typically generated by an adversary inside an infrastructure. Indeed, an adversary inside a target network is typically in an unfamiliar environment for them and engaging in the activities that correspond to the “Discovery” phase of the MITRE ATT&CK framework. This is classic strategy: attacker/defender asymmetry favoring the attacker, but the roles change once the attacker has penetrated an environment, causing them to assume a defender role and be at a strategic disadvantage. This discovery activity, as well as subsequent phases, generates a lot of atypical traffic which, even with attempts to evade visibility, frustrate successful network evasion by the attacker.

[4] The acronym NDR in this context is used to describe any solution that generates network metadata from traffic inspection and performs processing to identify risk and feed the policy engine based on that analysis. This could be a single, consolidated solution or a series of components (for example, network metadata generators feeding an analytics platform) that perform the function. There is no need to be specific — it’s the function that is key to this discussion.

[5] As stated in previous comments, having separate EDR and NDR tools instead of one combined tool (e.g., XDR, whether defined as EDR+logs/telemetry or EDR+NDR) allows each tool to cross-check the integrity of the other, making it more difficult for an adversary to compromise an environment and remain undetected. We believe this approach is consistent with the challenges outlined in section 1.1 of SP 1800-35B, which specifically highlights that “No single ZTA solution exists.”