In 2021 an Executive Order by President Biden mandated that all federal agencies move toward adopting a Zero Trust (ZT) architecture. Since then, every network manager, infrastructure director, and chief technology officer in higher education has been receiving cold calls from vendors about ZT solutions. You know you should move to ZT, but how?
In this blog, we offer some stepping stones to guide you on your path to ZT. We don’t claim to know the exact ZT architecture for your institution, but with the information we’ve gleaned from many hours speaking with vendors, we’ll give you a starting point. We’ll focus on the network aspects of ZT, but that does not diminish critical needs around identity, logging and monitoring, malware detection, and more. We are continually disappointed at how many network and security vendors have no or poor IPv4/6 dual-stack capability. If that matters to you, be sure to ask the vendors pointed questions and test carefully.
Industry leaders realized almost two decades ago that to achieve best-practice network security, they must:
- Reduce attack surface size;
- Simplify protect surface management; and
- Enforce least-privileges access to assets.
Identity-aware, dynamic segmentation (we call this Role-Based Access Control or RBAC) has been the gold standard for higher education for years. With the increase in working from home during the pandemic, ZT took that to the next level, incorporating the complete micro-segmentation of all endpoints. With end users and institutional assets located literally everywhere all at once and in every flavor imaginable (not to mention IoT being plugged in all over campus), institutions need to be thinking about extending the RBAC concepts to embrace full ZT ideas. (For the purposes of this blog, operational technology, ICS, SCADA, and other specialty items are out of scope.)
- As defined in NIST SP 800-207: “Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies. Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) and operational policies that are in place for an enterprise as a product of a zero trust architecture plan.”
- Segmentation versus Micro-Segmentation
The industry has not fully settled on the definitions for these terms. Vantage describes network segmentation as splitting up your logical topology into segments or neighborhoods, inside of which you intentionally house other devices with a similar institutional function or role (e.g., one segment for student network access from residential halls and one segment for CCTV devices that community safety monitors). You then protect and control each segment by deploying security solutions at the boundaries between these segments. Network segmentation makes it more difficult for a compromised device requiring only limited network access to move laterally to a segment that has expanded network access. Properly segmented networks uphold RBAC principles.
Micro-segmentation takes this a step further, placing each device or even each application within its own segment. All traffic between devices or applications is inspected for potentially malicious content or violations of security or access control policies and only explicitly allowed traffic is allowed to cross role boundaries.
Unfortunately, ZT isn’t like fluoride toothpaste; you can’t just buy any ZT solution and call it good. Gartner’s ZT magic quadrant has more than 30 ZT Network Access solutions listed, and slogging through the repetitive solution websites is frustrating at best because:
- ZT websites are full of buzzwords and lack substance;
- Marketing material does not effectively highlight solution differentiators or helpful design specs; and
- Higher education institutions by their nature have much more complicated openness, scale, and extensibility requirements than other industries, and many ZT solutions aren’t designed with this in mind.
Some ZT background to level set our understanding: the basic “never trust, always verify” motto of the ZT idea was coined by John Kindervag in 2008, which led to the NIST SP 800-207’s ZT explanation that ZT’s “focus is on authentication, authorization, and shrinking implicit trust zones while maintaining availability and minimizing temporal delays in authentication mechanisms. Access rules are made as granular as possible to enforce least privileges needed to perform the action in the request.”
To implement ZT, you want an easy-to-administer flexible enterprise-level IT architecture that inherently functions with identity-aware dynamic segmentation as its core, and you need to figure out how you can get your network infrastructure from here to there.
Basic Required ZTA Components
– A solid identity and access management system (IAM). Explore ways to move into confederated identities and identity certificates if you haven’t already. Confidently tying a user’s identity to a device in the user’s possession with an identity certificate is a current best practice but there are other strong options like Webauthn.
– A mechanism to automatically see and profile any device plugged into your campus network (here, we specifically mean headless devices like IoT) so you know what it is, where it is located, and what it should be allowed to access with zero manual effort required from IT staff.
– A client-endpoint security check, be it an Extended Detection and Response solution (XDR) or part of your device profiling mechanism, to lower the risk of a compromised user endpoint gaining access to the institution’s systems. By this, we’re not talking about the nightmare that was posture-based NAC in the 2000s, but rather something that also is designed for a positive user experience.
– Tools that monitor, record, scrutinize, and respond to all network and access activity so that anything anomalous can be spotted and reviewed for incident response and compliance purposes (e.g., threat intelligence-informed IDS/IPS, NDR, SIEM, etc.).
– An authoritative policy decision point (PDP) which is the access policy management engine.
– Policy enforcement points (PEP), where the institution’s access policies are actually applied to the traffic, and in ZTA solutions, where the micro-segmentation applied by the network fabric is executed to allow appropriate traffic to pass.
The big leap from RBAC to ZTA is the combination of more complete micro-segmentation and extension of the architecture beyond the on-campus network infrastructure (aka the network fabric). Combining these objectives effectively reduces the protect surface, enables cloud and remote work, and minimizes pivot risks from compromised hosts.
ZT Architecture Types
We’ve boiled down the ZTA implementation variants we’ve seen from vendors into four types, although we acknowledge there are vendor solutions that don’t perfectly match any of the below. We also haven’t attempted to enumerate all of the vendor solutions out there. Nonetheless, the ones highlighted below are representative vendor solutions whose names you may recognize. Some vendors offer more than one of these types.
All the Firewalls!
This model is the preferred ZT solution of distributed firewall vendors. The basic idea is that in order to shrink the institution’s attack surface, a distributed set of firewalling devices or applications can be placed directly in front of ALL of your institutional systems and services, whether it be a physical box, VM, cloud solution, or an IPsec tunnel back to your border firewall as the only access point. Wherever each service sits: drop in a firewall. In the past, the complexity of managing a number of firewalls with a cohesive and consistent access policy set entailed far too much for a higher education institution to approach reasonably with a small team, especially if the institution’s standard operating procedure for the past few decades included cordoning distributed departments off to manage themselves. However, the policy management systems to build and sync the full set of access policies for a complicated institution involving a large number of firewalls have matured considerably and are now much more approachable for higher education.
To create the micro-segmentation required for ZTA, the policy enforcement points (PEP), are pushed in the physical topology as close to both the endpoints and the servers as possible (in essence: the gazillion firewalls).
| PRO | CON |
|
|
|
VENDORS:
|
|
Fabric ACL
While reminiscent of the “All the Firewalls!” model, “Fabric ACL” is appropriate for any Next Generation firewall that does Layer 7 firewalling, as well as any campus fabric infrastructure all the way to the edge. The whole campus network can be, effectively, micro-segmented per your policy set as unicast traffic can even be disallowed between endpoints on the same VLAN, including any potential IoT that is connected. The access logic is interwoven directly into the fabric by the network. This means the PEP is effectively located everywhere the traffic enters the fabric at the ingress point. The upside of this is that firewall and network resources aren’t spent inspecting or moving traffic around that will ultimately get denied. In most cases, the fabric does what are essentially sophisticated ACLs (some vendors even do L7 rules) with traffic requiring further inspection routed through a real firewall.
| PRO | CON |
|
|
|
VENDORS:
|
|
Traffic Squish
This solution is some variation of the east-west firewall, traditional VPN concentrator, or the proxy service approach, depending on the implementation. Vendors who pursued this model provide a central point that all network traffic has to traverse in order to reach any service; client traffic is forced through the central PEP. Depending on the vendor implementation, these PEPs can be located on campus, off campus, or both, and there doesn’t have to be an upper limit on the number of deployed traffic squish locations.
In the east-west firewall version, traffic is segmented on the network and crosses a firewall to enforce policies when crossing role boundaries. For the proxy version, managed traffic is directed through a software proxy usually located in the cloud. In most cases, proxy throughput is designed for normal endpoint traffic making research flows that require higher throughput hard to incorporate.
For some vendors, the traffic to the PEP is fully integrated into their network fabric which is located on-premises. However, for the solutions that act as an overlay on existing infrastructure, a client-side component or agent may be required to establish the connection to the PEP. Institutions with multiple campuses geographically far apart may find vendor-hosted traffic proxy infrastructure less complicated than other ZT options, as it avoids needing to stand up on-premises proxy concentrators at each campus.
You may be nervous that the ZT proxy does a lot of heavy lifting for this solution; however, this model can radically simplify future network upgrades or modifications. A hosted ZT proxy directs the service connection as configured from the PEP, so any change in destination IP is transparent to the user, even if you are moving a service from on-prem to the cloud. The security access will not change, and the user will not have to change what they do to connect. IoT traffic is typically incorporated through a specialized network gateway for each IoT network.
In this solution, the PEP:
- is the ZT proxy squish location;
- does not need to be located physically near the services it is proxying; and
- logically creates the gateways for the service ZT micro-segmentation.
| PRO | CON |
|
|
|
VENDORS:
|
|
P2P Network Overlay
This is a newer concept. While it looks very involved from the graphic below, it has interesting benefits and is deceivingly simple. The premise behind this model is to allow the establishment of encrypted point-to-point (P2P) tunnels directly between a client endpoint and the services it is authorized to access. This is accomplished with a lightweight agent on every endpoint (user systems and servers) that coordinates with the PDP policy engine to provision private N-node networks, operating as overlays on top of any existing network infrastructure, ensuring that all traffic between devices is encrypted, and that devices are authenticated and reachable regardless of how or where they’re connected to the Internet. This means you can move on and off campus, flip between campus wireless and cellular data, change IP addresses, etc., and your P2P network will remain connected. It also means that the traffic is not being forced through any additional security appliance like a proxy, so the routed path is optimized and the transport layer is independent of the security. Because the open source solution Wireguard underlies most of these solutions, performance is vastly superior to conventional tunneling and much closer to wire speed.
The logical micro-segmentation is now pushed to the PDP policy engine as clients will only be able to establish allowed connections and nothing else. The institutional firewall may need to open up a few ports to allow for the encrypted tunnels to flow through it, but otherwise won’t be asked to do much heavy lifting. In our minds, this model flips network security on its head, and creates an excellent exercise to then think about what this means for ZT and information security in general.
One concern is that this eliminates the ability to perform packet scrutiny, so the real-time monitoring of overlay traffic is limited unless your infrastructure contains ways to add concentrators and force the traffic through security nodes (be it Corelight, firewall threat intelligence-informed IDS/IPS, or some other SSL decryption solution). Also, IoT that can’t support the client will need specialized network gateways and mDNS, and multicast traffic would require additional creative solutions. Thus, this model may not be the right fit for many, but the attraction that you can deploy this P2P network overlay independent of the transport layer, piecemeal, without a huge lift, and create 100% secure transport is compelling.
| PRO | CON |
|
|
|
VENDORS:
|
|
The Bottom Line: There Is No Single Path to Zero Trust
While implementing a ZTA with a snap of the fingers is a lovely wish, in reality it will take a thoughtful, phased approach. Start small — don’t start a multi-year “forklift” implementation, as the finish line will move before you get there.
“To reduce the complexity of cybersecurity environments, organizations can prioritize security technologies and tools that support simplicity by automating repetitive and manual tasks, integrating and managing multiple security tools and systems, and autoremediating known vulnerabilities.
Zero trust is a journey best taken one step at a time. I recommend that organizations begin by prioritizing the smallest possible protect surfaces — a single data set, asset, application, or service — depending on the level of sensitivity or business criticality. Then, they can create a microperimeter around each protect surface and granularly control the traffic allowed into the perimeter.” — John Kindervag: ‘The Hallmark of Zero Trust Is Simplicity’, Deloitte/Wall Street Journal, April 15, 2021
If your institution has already started down the ZT path, keep going! The ZT path is long and full of opportunities for improvement. Keep your focus on:
- Taking a risk-informed approach to making iterative progress;
- Doubling down on your existing technology and any key infrastructure you have available to leverage; and
- Identifying what your actionable ZT goals are, even if that means brainstorming specific use-cases; a lot of ZT solutions look the same without defined mile posts to move towards.
You may already have the tools and techniques to go wide with a ZT deployment or it may mean focusing on IoT or certain research enclaves. You should start by doing what works best for your institution, and let us know if we can help guide you in any way!
References
- Executive Order on Improving the Nation’s Cybersecurity | The White House
- Zero Trust Architecture (nist.gov)
- Rose, Scott et al., Zero Trust Architecture, NIST Special Publication 800-207, August 2020 (accessed 1/19/2023)
- The Vantage Vision for a Modernized Network (blog)
- Modernizing the Campus Infrastructure to Support Success (Internet2 webinar recording)
- Modernizing Your Network to Support Institutional Success (EDUCAUSE webinar)
This post was co-authored by Vice President Jon Young, who advises clients on network modernization, technology strategic planning, and initiatives that transform institutional academic, administrative, and research capabilities, and Senior Strategic Consultant Jacqueline Pitter, who advises clients on network modernization, information security program development, and technology architecture.