shane -

Why zero trust may not be all it’s cracked up to be

While they are discussed ad nauseam in the security industry, zero-trust architectures may not be all they’re cracked up to be, according to analyst Sam Bocetta

Zero trust architectures were a major theme of the 2020 RSA Conference, with several panels devoted to the strategy and it being touched on in almost every security-focused plenary.

With a few notable exceptions, however, these discussions were less than useful for the majority of cyber security professionals in the room. That’s because most of the literature on how to implement zero trust architectures assumes that systems are being built from scratch. In the real world, achieving a true zero trust model to existing networks – and particularly if they include legacy systems and P2P functionality – is almost impossible.

That’s not to say that zero trust isn’t a great idea. Far from it. As customers demand more security, and as professionals increasingly understand the security implications of the cloud, zero trust definitely has real value. This value, however, is a conceptual one rather than a concrete one: in other words, we should all be aiming for zero trust, whilst also recognising that it’s never (truly) going to happen. In this article, we’ll take a look at why.

Cyber security professionals will need little reminder about what zero trust is supposed to achieve, but it’s worth reminding ourselves if only to see where the model doesn’t match reality.

The most succinct summary of zero trust implementation I know of is the one published by Forrester a few years ago. In this document, we are told there are five main steps to achieving zero trust:

  1. Identify and categorise how sensitive data is, where it is stored, and how it is transmitted.
  2. Define the routes through which this data can be shared and block any devices and users from data egress processes through non-permitted channels. This includes any PCI architectures you are using.
  3. Enforce microperimetry around all sensitive data and audit all access to it.
  4. Monitor this entire system with an overarching security analytics package, having carefully chosen a vendor who understands your business, sector, and IT infrastructure.
  5. Automate security protocols as far as possible and undertake frequent tests of this automation. 

If you think that sounds like a year’s worth of work, you are right. In fact, returning to the basic principles of zero trust in this way makes it clear that hardly anyone has actually achieved it, despite having claimed to. Why is that?

The problems with zero trust

When it comes to implementing zero trust in the real world, even small organisations will run into a number of problems

The first is that almost every existing company has a level of technical debt. Even if your software is just a few years old, you are going to have to spend significant amounts of time re-working and re-coding it to accommodate zero trust. In reality, given the demands of the development cycle, hardly any company has these resources.

Second, legacy applications have no concept of least privilege or of lateral movement. You can track these systems with web monitoring tools, but this monitoring will only take place at a superficial level. In other words, you might be able to keylog the way that your users are interacting with these systems, and monitor the network traffic they produce, but you will have no insight into the internal operation of them.

Third, even companies who are starting from scratch will find it difficult to stick to 100% zero trust after only a few months. A startup, as of 2020, will likely implement a role-based access model for all of their components. But as soon as they want to start using cloud services (or, worse, IoT devices), they will have to invest in additional technology to ensure their access model stays consistent. And, given the resource constraints on startups, they won’t.

The solutions

None of these issues have easy solutions. What is required, instead, is a recognition that zero trust is a great model to guide ongoing security hardening, and not a monolithic standard to hold yourself to.

In fact, this has long been the way that other security architectures have been thought about, without the hype that zero trust has generated. PCI compliance bears many similarities with zero trust architectures and without the overly rigid cross-system expectations, which is why it’s something that small businesses would be wise to take seriously. Moving to a privileged access model is more feasible for most companies than attempting to overhaul entire systems to run as zero trust architectures.

Read more about zero trust

In this context, whilst a privileged access model will protect your systems from unauthorised access, your trusted accounts are simply going to get hacked. In other words, controlling the user is pointless if the resources they are accessing are vulnerable to other types of cybersecurity risks and exploits. You are better off giving your employees personal VPNs, rather than locking down access to malicious agents.

Finally, it is necessary to recognise that different usage conditions require pragmatic solutions. People and organisations alike are well aware of the privacy and security issues involved in working remotely, for instance, but many still choose incredibly weak passwords.

The average small-to-medium sized enterprise in the United States currently only invests less than $500 a year (£420) on cyber security. It should be no wonder that thanks to this very low average investment figure, the majority of such enterprises will be the victim of a cyber attack or attempted attack each year. Even if zero trust policies may not be one hundred percent achievable, these enterprises would still be wise to follow the zero trust approach as a guide using the above solutions. 

The future

It’s likely that you’ve found yourself troubled with these kinds of thoughts before, but felt unable to share them with your colleagues. Indeed, at the 2020 RSA conference it was quite amusing how many people were willing to point out the difficulties they had encountered when trying to achieve zero trust, but that these same people were unwilling to admit that they didn’t run the model.

So let’s start taking zero trust seriously. Let’s go beyond the hype, and start to think about how it can actually be applied in the real world. Only then will the model regain its utility. 

Next Steps

SDP vs. VPN vs. zero-trust networks: What's the difference?

Read more on IT risk management

Data Center
Data Management