Zero trust and users: Cutting through the noise

I’ll admit – trying to explain zero trust without relying on the usual jargon and buzzwords is no small feat. But here goes.

At its core, cybersecurity aims to ensure the right people have the right access to the right systems and data at the right time. Breaches tend to occur when any one of these elements goes wrong. Over the years, we’ve leaned heavily on user identity and associated access controls – think usernames and passwords – but that approach has its flaws, both in effectiveness and in user experience. So, what have we learned over the years?

• Organizations work in collaborative ecosystems – building metaphorical walls is ineffective due to the sheer number of holes you have to punch through them.
• Users don’t want to be confronted by security. They will work around your controls if they are too onerous. Transparent security is more effective.
• Segmentation is important. Many ransomware attacks succeed because attackers, once inside, face minimal resistance in moving laterally across systems. Today’s focus on operational resilience puts a spotlight on the need to reduce that blast radius.

And this is where “zero trust” comes in.

You’ll often hear “never trust, always verify” when it comes to zero trust. It’s not necessarily wrong, it’s just not particularly helpful. The underlying philosophy is really “assume compromise”: start from the assumption that anything and everything in your IT ecosystem may be compromised; that could be the user themselves, their credentials, their laptop, the network they are using, or any combination of the above. How do you secure your systems and data if anything or everything is broken? Well, you start by building up trust, from that position of no trust whatsoever.

How can I build up trust in the user’s laptop? Is it one of ours? If so, can we give it a certificate it can use to identify itself? Is it configured in-line with our policy? Perhaps we can run a policy check. Has it been compromised? What does the endpoint security agent we have installed on the device say? From that position of untrusted, we’ve now built up a degree of trust – assuming that the security tooling providing those checks is effective! (That trust thing again, eh?). What about the user? Well… have they presented the right credentials? Are they accessing from their usual location? At the usual times? In this case, we’re now making decisions based on previous patterns of behavior, and this is where AI can help, particularly machine learning which can raise an alert and/or deny access should behavior be seen as outside of normal baselines. We can score the trustworthiness of each and every access request, and grant access if a request is deemed sufficiently “normal.” What about the network? Frankly, we don’t really care, we’re going to encrypt all the traffic and so the network is just a way of transporting data backwards and forwards. Just pick quantum-safe algorithms if your threat model demands it.

One of the nice things about modern approaches to zero trust is that it connects the user to their applications rather than to the underlying network on which those applications are hosted. If you group the applications appropriately then you get that benefit of segmentation. An attacker may be able to compromise the application to which they have been given access, but they will then only be able to traverse to whatever other systems that application can see rather than having access to the full underlying (often flat) network. You can reduce the blast radius of a compromise.

There are also some tangential, not security-specific benefits available. When you think about traditional ways of doing security, you’ll likely find a fairly complex stack of security technologies in place within the data center. Wouldn’t it be nice to be able to simplify that stack? Perhaps reduce the total cost of ownership in terms of overall license and support costs? All while still delivering the same security capabilities? That’s where technologies like Zscaler can help. Centralize those security capabilities and deliver them from the cloud. This does, however, mean you are placing a LOT of trust in your “zero trust” security services provider. An irony that is not lost on most security professionals, but another reason why I do grumble somewhat about the term.

In summary, “zero trust” is really just a way of delivering the dynamic, context-based security controls that modern business demands. You can choose the authentication credentials you want to use to provide the user experience you desire. Every access request is checked, such that if something goes wrong in the period between a user accessing Application A and asking to access Application B then you can deny the second request. You are only providing access to applications and not networks and so you reduce the risk of full network compromise. You can simplify your legacy security tooling and deliver much of this from the cloud, supplemented by other technologies (e.g. endpoint security) where it makes sense to do so.

Businesses may not want “zero trust,” but they probably will want the outcomes described above – improved user experience, reduced total cost of ownership, and improved operational resilience. Sometimes it’s helpful to forget the buzzwords and focus on the outcomes. The final post in this series will talk about how we help our clients to do just this.

In the next post, we will explore zero trust and devices – because yes, machines have identities too.