Use zero trust to fight network technical debt

Zero trust (ZT) is a mindset and a method, not a technology. The current push to adopt ZT is driven by an urgent and growing need to make a major leap forward in risk management and attack containment in enterprise networks, a need driven home by every successive wave of ransomware. IT can use the urgency of moving to ZT to root out some of the technical debt in the environment. Specifically, it can be a catalyst to find areas exempted from network and network security standards and bring them up to date under the new paradigm of zero trust.

No more exempting network components from access-control roles

In a ZT environment, the network not only doesn’t trust a node new to it, but it also doesn’t trust nodes that are already communicating across it. When a node is first seen by a ZT network, the network will require that the node go through some form of authentication and authorization check. Does it have a valid certificate to prove its identity? Is it allowed to be connected where it is based on that identity? Is it running valid software versions, defensive tools, etc.? It must clear that hurdle before being allowed to communicate across the network.

In addition, the ZT network does not assume that a trust relationship is permanent or context free: Once it is on the network, a node must be authenticated and authorized for every network operation it attempts. After all, it may have been compromised between one operation and the next, or it may have begun acting aberrantly and had its authorizations stripped in the preceding moments, or the user on that machine may have been fired.

This is a radical change to how network professionals have to think about network services. Indeed, many network teams have only recently gotten really comfortable with even basic admission control based on 802.1x, and networks are rife with ports, switches, segments, and subnets that don’t even enforce that basic level of admission control. In many cases, the port/segment/subnet/whatever has been exempted because systems connecting through it—or even the underlying hardware itself—cannot handle the security protocols, or because the folks running that part of the network don’t see a need for that level of security or want to adopt it, or the administrative overhead of implementing and running the system is considered too high.

Because it forces so complete a shift in perspective, and comes with board-level-down support, ZT will be a powerful aid to exposing technical debt and finding the motivation to finally address it.

Shift to zero trust forces network teams to find technical debt

Implementing a ZT infrastructure requires digging into every level of the infrastructure and either using it to enforce security policies or making sure it is configured to prevent end-runs around policy enforcement points (PEP).

Focusing in on switches, for example, if a switch is to be a PEP, it must require that a node be permitted to send packets through it before allowing it do so. It must continually reconfirm that permission by checking for changes in pushed policy updates.

If the switch is not the PEP, and some separate gateway node is, the switch needs to make sure all traffic goes through that gateway. For example, if the gateway is upstream of the switch, all traffic from edge ports must be directed through an uplink, even if that traffic is ultimately destined for another of its own edge ports.

If an organization truly is committed to implementing ZT from top leadership down, network teams and business owners will no longer be able to kick the modernization can down the road. With a goal of implementing zero trust, they will be less able than usual to excuse chunks of non-compliant infrastructure because it’s costly to update them.

That’s not to say there won’t be bubbles of “old network” enclosed behind gateways of “new network.” Rather, that the drive to ZT will exert continual pressure on those bubbles to shrink, and not just on the configuration of the networking components – the application owners will be under pressure to modernize an application that is decades behind the security curve, at the very least enough so to accommodate an agent to act as a host-level ZT gateway for components that cannot be updated.

To be sure, owners will answer, as they so often do, that there is no money to cover the costs of those modifications. The only sure counterweight to that is solid commitment from the CEO down that the risk associated with failing to embrace ZT is more expensive in the long run. Networking teams should be joining together with cybersecurity and risk management to advocate for and advance ZT throughout the network.