shane -

The tensions behind that simple phrase ‘zero trust’

NetEvents recently assembled a squad of experts to investigate the ‘myths of zero trust’ and we managed to ask them for their thoughts about just what the term means

It seems no discussion of network security is complete these days without a mention of zero trust

The subject dominated a recent NetEvents discussion and in a series of Q&As sent to some of the panellists, a picture was painted that revealed there was some debate about the best way to describe the approach to minimising risk and some tension between DevOps and security.

By researching LinkedIn profiles to get a sense of their personal interests, the panellists were challenged to use familiar metaphors to explain the intricacies of zero trust.

Security vendor NetFoundry’s founder Galeal Zino

Can you see why the relationship between DevOps and security officers is like a Laurel and Hardy sketch? Is Oliver like the network security boss, who patiently closes down all the holes in the system, with a keyboard in one hand and a spreadsheet printout in the other? Meanwhile, Stan has got a DevOps machine and is spinning up dozens of new servers with each click of his mouse. Eventually, the weight of containers collapses on poor Ollie, who gets buried. In the words of Oliver Hardy, do something to help me! Does NetFoundry make it easier for the security man to keep up?

Absolutely. Our head of DevOps was in a podcast recently where he was talking about making his environment dark and his co-presenter said he often had dark environments as he purposely didn’t tell the security team. This is the key to programmable, app-embedded zero trust.

Oliver Hardy ensures that all inbound ports can be closed and that access to resources is based on strong identity, micro-segmentation, least privileged and encryption. His initial attack surface and any potential blast radius is massively reduced. He can get full visibility and logs of who accessed what and when using the embedded identity rather than IPs. Finally, he gets his security without annoying the DevOps team who then try to avoid using it. Stan can wire up his systems, innovate quickly and work programmatically. Everyone gets what they want, so the sketch isn’t as funny.

We created a blog and video on YouTube recently that looks at why every DevOps engineer loves OpenZiti.

Rik Turner, principal analyst, Omdia

As someone with a firm grip on a linguistic, does the conversation about zero trust confuse you too? If myths are a second order linguistic signification (as the internet says), then what language are the zero trust myth-takers talking?

I think zero trust is pretty straightforward, summed up in its motto: Never Trust, Always Verify. To which I might add, and Continuously Monitor.

In essence, zero trust is institutionalised paranoia, which might not go down well in your social circles, but makes eminent sense in cyber security. In other words, assume everyone is against you, but some folks still need some level of access to do their jobs, so keep it to a minimum and keep your beady eyes on them while they’re doing it. 

Vivek Bhandari, senior director of product marketing, networking and security, VMware

According to LinkedIn, you are a regular tennis player. Can you explain, using a nice tennis metaphor, one or more of the myths of zero trust?

What most security practitioners experience on a regular basis is like having a bad day on the tennis court, says Bhandari.

You cannot win the battle with just an identity-based solution, or a single point product. You need to enable critical capabilities across your digital infrastructure spanning users, devices, networks and workloads, assuming someone unwelcome is looking to access the resources by any means. You need to eliminate any gaps and weakness in your game that the opponent could take advantage of.

Jordan LaRose, director of consulting and incident response, Americas, F-Secure

What are the zero trust myths lurking below the surface? Using the metaphor of a submarine, can you explain what users need to do to be protected?

I think what’s important to understand about zero trust is that its moniker is somewhat misleading. In practice, what we really need to implement is “minimum trust”, even if it doesn’t sound as cool. 

To put it into a submariner’s terms, every compartment of the ship needs a bulkhead. If one compartment starts to flood, we need to ensure that we design our ship in a way that prevents as many other compartments from flooding as possible. It’s impossible to separate some components, like steam generators and turbines, or applications and databases, but if we lose those groups, we need to be able to close off access to the rest of our ship if we want to have any chance of survival.

“The cornerstone of a strong zero-trust strategy is documentation. We can all hear the collective sighs of cyber security folks everywhere at the mere mention of its name, but documentation is the anchor that keeps us in place when disaster strikes”
Jordan LaRose, F-Secure

So, whenever a systems administrator is integrating a new appliance in their network, there is a bare minimum amount of privilege that they must give it to function, but we should always give it as little exposure, and privilege, as possible to limit impact if that component is breached. Likewise, when we’re integrating those components, it’s a critical point of process to analyse, understand and document the potential impact of a breach before that breach happens – no submariner’s manual is complete without emergency procedures for every component in the sub.

Another crucial thing to realise about zero trust, just like every element of a security strategy, is that it’s only one piece of the larger puzzle. While it’s vital to build zero trust into your designs, that effort is worth nothing without other strong defensive elements to support it.

Perhaps the most key element is endpoint detect and response (EDR) – AKA threat hunting. A submarine’s compartments may be designed to withstand a torpedo or collision, but the ship is useless without its eyes: the sonar system. A smart captain ensures that not only does he have a fine-tuned system, but also an expert team to keep a watchful eye (and ear) over it. There’s a reason why the sonar is manned 24/7 – attacks can come from any direction and without warning, and the crew must always be ready to respond immediately to a threat and enact those carefully designed emergency procedures at a moment’s notice. No successful security strategy is complete without a zero-trust design backed by a strong EDR and matching threat hunting team.

Finally, the cornerstone of a strong zero-trust strategy is documentation. We can all hear the collective sighs of cyber security folks everywhere at the mere mention of its name, but documentation is the anchor that keeps us in place when disaster strikes. Every submarine ships with thousands of pages of technical manuals for this express purpose – and those tomes in the hands of an expert crew are an invaluable weapon when disaster strikes. 

Chris Kent, senior director, product marketing, Hashicorp

Can you help us visualise zero trust by setting it in a human world that we can relate to?

If we look at zero trust in a human world example, it’s a lot like checking into a hotel. When you’re at the front desk, you have to use some sort of identification, like your driver’s licence or passport. Once verified, they will then issue you a key to access a particular room. That room may be one of hundreds or thousands, but that’s the only room you have access to. And if you lose your key card, they can turn off the access and issue you a new one to make sure no one else can access your room.

We believe zero-trust security is predicated on securing everything based on trusted identities and access. This ensures that every request is verified, including machines and humans, every action is verified and every action taken is authorised.

Ian Farquhar, director of worldwide security architecture, Gigamon

As a no-nonsense Australian and an engineer, can we expect you to be blunt? Do you think zero trust is a name that has already run its course? 

I actually like the name zero trust, but a more accurate name would be rational trust. It’s not as catchy, but it’s correct, so let me explain why I think it’s a better name.

When we trust something, we should have a rational reason for doing so. The problem is that in IT, we haven’t been. For years we’ve used approximations for trustability – whether it’s on one side of the firewall or not, whether we own the system or don’t, whether the user is an employee or not, that a system was secure in the past. These aren’t trustability measurements, they’re gross approximations often based on poorly understood assumptions. When that trust assumption fails, we introduce risk. When threat actors see those assumptions, they use them to evade our controls and cause problems.

“Any vendor that claims to be “the only zero-trust solution you need” has really missed the point – you shouldn’t be trusting a single vendor at all. That’s a violation of zero-trust principles in itself”
Ian Farquhar, Gigamon

Zero trust means to stop doing that, and dynamically measure whether something is trustable by looking at how it works, and for every connection it makes, assessing whether we have a rational basis for trusting it and letting that connection happen. This isn’t just systems, but individual devices, security mechanisms themselves, and even users.

Fundamentally, this is a change in the way we architect and implement networks, and we’re still figuring out how to do this. I think the final solution will actually simplify many things, and this might not be to the benefit of some existing players in this market. Any vendor that claims to be “the only zero-trust solution you need” has really missed the point – you shouldn’t be trusting a single vendor at all. That’s a violation of zero-trust principles in itself.

I see nothing in zero trust which is impossible, but I do see a massive challenge, and it’s a Layer 8 challenge. Ccognitive bias makes us over-trust things that are familiar to us, and ignore things that aren’t. I actually perceive we have a massive problem in zero trust around this. 

Above, I said we should assess the trustability of security mechanisms. Take logging. We’ve been doing logging for decades now, and a lot of zero-trust architects rely heavily on logging and telemetry from hosts to assess trustability.

Yet you see organisations reliant on logging and host-sourced telemetry (and EDR) to assess trustability. Why? Because they’re familiar. They’re comfortable. They’re understood. But they’re not reliable, for so many reasons, and we shouldn’t be implicitly trusting them.

It’s a bad habit, and it has to stop. This is what I see as the biggest issue. Once we start doing zero trust properly, we will get there. My biggest concern, to address your last action, is that the industry won’t spot this in time and zero trust will fail to achieve the results it could.

Read more on Security Network Services