“Never trust, always verify”. It’s a great principle. But what happens after we verify?
The answer, of course, is that we trust. Not necessarily for very long – potentially just long enough for a single transaction to take place. But the whole reason for verification is to determine whether we can establish enough trust to allow that transaction to take place. We start from zero trust and verify to see if we can establish enough trust to proceed.
As Zero Trust becomes the guiding principle for more and more enterprises, there’s a danger I’m seeing that some are taking it to mean something else: that there’s no longer any need for trust. And, that we can give up on the need to trust endpoint devices. Quite the reverse: trust in the endpoint device needs to be an integral part of any Zero Trust strategy.
Most of the literature around the “verification” aspect of Zero Trust focuses on the verification of identity: that we need to verify the identity of the user before we allow them to get access to resources. No question about that – this sort of access control obviously lies at the heart of any security plan. If Joe works in Marketing and asks to access branding materials, once we’ve verified his identity, we have enough trust to give him access. But if he asks to access sensitive customer data, then our verification stage reveals that he’s not trusted to do so.
What about Joe’s endpoint device? If that gets compromised by an attacker, then we should assume that the attacker can access anything that Joe can access. Luckily, in this case since Joe can’t access the sensitive customer data, nor can the attacker.
But consider Jane who works in Customer Service – or even more, Sarah the systems administrator. We certainly need to trust them to access sensitive data and systems. However, if their endpoint devices are compromised, we will have to assume that the attacker can access those sensitive data and systems too.
So, Zero Trust must involve verification not only that we trust the user enough to allow them to proceed with their request, but verification that we trust their endpoint device enough as well. And the level of trust that we require depends on what data and systems that endpoint device is being used to access. We may need a lower level of trust in an endpoint device that’s only ever going to be used by Joe than in an endpoint device that will be used by Jane or Sarah.
With Zero Trust, it’s time to move beyond a one-size-fits-all policy for endpoint security. For devices that are never used to access the most sensitive data or systems, the risk of an unmanaged endpoint may be acceptable. For other devices, the impact of a compromise is simply too great: these devices require the strongest possible protection (for example, the use of strong Web Isolation technology).
It’s an obvious approach, but one that’s still quite poorly implemented by many enthusiastically Zero Trust supporting cloud providers. Permissions need to be dependent not only on the (verified) identity of the user, but also on the (verified) security of the endpoint device: the same user should be trusted differently (and hence receive different permissions) depending on the security level of the endpoint device they’re using. With many cloud providers today, that’s not trivial to implement – and can in some cases be impossible – so it may be one of the key areas that customers look to ZTNA providers to help with.