You can’t secure what you can’t see
Since nothing in a zero trust network is allowed to communicate unless its attribute-based identity is verified, assets are discovered automatically and data paths are revealed as third-party systems attempt to communicate. Thus, a zero trust network will always provide real-time visibility into:
- Which partner systems are requesting network access
- What’s sending/receiving communications
- What data paths they’re using
- Which other systems they’re talking to
- Normal traffic patterns
What this means is that a zero trust network can always see which partners you have and how their systems are interacting with your network.
Policy enforcement with zero trust
The core tenet of zero trust is, “Never trust, always verify.” In practical terms this means that every data request is authenticated, irrespective of previous permissions, every time they try to communicate with/on your network. In a zero trust network, data access decisions are dynamic and based on a collection of criteria—not just usernames and passwords or approved ports, for example —that form an identity (or fingerprint). For instance, if the identity/fingerprint of an application doesn’t meet criteria because malware has been added, the connection is denied. Same goes for a system that appears to have been updated out of band, or where the connection request is coming from a location never before seen. As such, if your supplier has been exploited, the attack progression is stopped at your doorstep.
Importantly, internal communications are subject to the same verification process as external requests. Just because a user, device, host, application, or workload as been verified by its identity and made its way onto the network, that doesn’t mean it wasn’t exploited on the inside. This is the main difference between a zero trust (i.e., untrusted) network and a trusted network (i.e., a typical network that assumes internal traffic is OK because it passed a previous “check”).
Moreover, a zero trust network removes the need to rely on contracts to enforce security policies (to the extent that that’s effective). If a partner network is vulnerable because of a missing patch, your zero trust network can prevent their systems from talking to yours. If your partner network has been breached due to stolen credentials (which is a hard problem to prevent), and an attacker uses those stolen credentials to try to escalate privileges, the attacker is stopped because a zero trust network doesn’t allow for privilege escalation. If the stolen credentials have administrative privileges and the attacker adds malware to the system, it can’t propagate in a zero trust network because an identity for the malware won’t be built.
Supply chains are an ever-growing problem. The more networked systems you have to account for, the bigger the vulnerability. Removing trust from your networks—whether they’re on premises, in a public cloud, or somewhere in between—tamps down the number of vulnerabilities you will have to manage. A zero trust network:
- Ensures greater data awareness (data mapping and asset identification)
- Operates on the principle of least-privilege access
- Creates security policies based on the identity of communicating assets
- Enforces access based on identity verification (versus network constructs)
- Adapts to change
With these design principles implemented, when your operating ecosystem grows, risk remains in check. Vulnerabilities in third-party systems don’t automatically translate to your environment because security controls that prevent hostile communications are in place; everything and everyone is repeatedly authenticated and authorized. In this way, security is not compromised...and neither are your networks.