Humans are still necessary to make zero trust security architecture work

A panel at the Computing Cybersecurity Festival discussed some of the challenges created by a zero trust architecture, and why automation isn't always the answer.

Moderating a panel at the Cybersecurity Festival to discuss some of the challenges inherent in zero trust and ideas for making it work, Computing's John Leonard, summarised the nature of the challenge.

"Zero trust is a philosophy not a product," he said, "and it starts with the assumption that the organisation has already been breached and that the attacker is already inside the castle walls. How you prevent them reaching the crown jewels? The short answer is to validate and authenticate every person, every device, every application on the system. The hard part is to do this without becoming an unbearable burden on tech staff or inconveniencing end users to such a degree that they seek workarounds."

The panel were all from organisations at varying points on the zero-trust spectrum, with some such as Matthieu Le Berre, of Mattbzh Consulting and currently Deputy CISO at GSS, being able to start with a greenfield, and others such as Ian Golding, Interim CIO at Landsec dealing with plenty of legacy technology and third-party relationships.

What are the initial steps that organisations looking to transition their security methodology should take? Specifically, did the panel find it useful to use "zero trust language" such as the principle of least privilege or just in time access?

Nick Ioannou, Information Security Manager at digital lettings platform Goodlord, explained that this language could sometimes be beneficial in getting executive support for a toughening of security posture.

"Our COO told us to implement it. We had a feature added recently to Google Workspace Enterprise and the COO mandated that this should be on everyone's because if a laptop is stolen or credentials are stolen, it was a feature that will protect us so it came from the top down."

Ian Golding thought that putting security imperatives through a commercial filter was helpful.

"What are the commercial imperatives? I think it's good for people to understand that bad things can happen but I think the commercial driver can be a more neutral and less scary way of doing it. No company wants to find their future in jeopardy. At the same time it seems like a good path to go down anyway so the hygiene factor combined with future existence perhaps."

What of the role of automation? It's key when you're isolating individual applications or individual devices but also needs some sort of human oversight because it does things that can be slightly unexpected. So what's the balance here? And how do you get that advice?

Goodlord has actually chosen to pull back on some of the automation, according to Nick Ioannou.

"We looked at something that uses APIs to automate and provision everything but that's the key, isn't it? If that provider is compromised, I've just given them everything. The risk is too high for us. Yes, it's a bit of a headache for me and my colleagues if certain people are locked out on the weekend, but we're accepting that risk. We'd rather have the overhead and the control. Automation isn't always good."

Ioannou also raised the possibility that the company could end up locking itself out of its own systems.

"With zero trust you could lock yourselves out. It's great when it works but you've got to test the environments when it goes wrong. Can the account owners of the systems still get in? If something goes wrong, and say some certificates expire or something like that then they can't work. Who wins? You need that escape route."

Matthieu Le Berre, whilst managing a very different type of organisation, agreed with elements of this analysis.

"At GSS we are a SaaS provider and all about scale and information but I agree, and we have "emergency break glass" type accounts. The danger is that, especially in some SaaS providers, if you have the first account or admin account of the SaaS provider, you could literally change the groups or the assertion so the matching of your AD policies doesn't match the SaaS provider policies, and that can be considered a risk as well."

"We have a third-party provider in our AD but they need to ask us to get access to the right places before they can do their bit. We have the approval process and control."

Ian Golding raised the question of whether resolving issues caused by technical debt or moving to zero trust should take primacy.

"How much money, time and effort do you want to spend to engineer solutions for legacy products? That's the reality in a lot of cases, but in the full vision might make it more compelling to remove the technical debt."

Some interesting audience questions focused on the impact of zero-trust security on productivity of a user base. Consistent with his previous argument, Nick Ioannou thought that some short delays for users might not be a bad thing.

"When it comes to delays, part of it is the response time of the helpdesk but part of it is us checking in with the user. Is that you trying to reconnect the device because it's new? Have you got a new phone? It's good because we have that check and balance and users understand that they have to speak to us. Call us, contact us and we'll try and do our bit."

Ian Golding framed the argument for zero-trust automation progressing past initial hitches to the point where it didn't have a negative impact on productivity.

"Although it might take some steps to get to a fully automated environment, once you get there all the processes are slick with fewer errors and defects, so it's all standard profiles and it's therefore a good experience for users."