One year on from our introductory blog on Zero Trust Architecture, what has changed and what friction points have started to appear for organisations after implementation? Crucially, where does Zero Trust fit within the to-do list, or the essential security risk management plan, for the secure enterprise today?
The Evolving Zero Trust Architecture
Zero Trust has matured over the last year following the issue of the draft principles of the NCSC in the UK. Since then, further information has been published in the US, including NIST’s detailed architecture document exploring definitions and use cases and the NSA’s information summary: Embracing A Zero Trust Security Model.
Across a large range of enterprises, many are probably moving towards the inevitable “trough of disillusionment”, where early days software – often third party – starts to show its age. The visionaries delivering it have moved onto the next big thing and an overworked in-house team has to make Zero Trust work for the whole organisation on a day-to-day basis.
So, what can in-house teams do to make Zero Trust work for them and their enterprise?
How to make Zero Trust Security Usable
Two main areas crop up time and time again in order to make security measures usable and, therefore, effective:
1. Challenges to operational flow and automation
Consider how you manage the security vs ops silos to avoid everything coming to a halt – in the same way that firewall breaches managed by the security department (or at least the SIEM team) bring so many workflows to a grinding halt.
Similarly, how do you stop the raising of a ticket on another silo to authorise a change in permissions being an acceptable outcome?
Five years ago this was a matter for operations to take care of as an internal management challenge, but in the era of Software-defined-X and DevSecOps, automation is the (sometimes aspirational) operational norm. Security is generally enforced as part of the development and operational routines, so there are no decisions awaited from flow-stopping silos.
The theory is good, but the fundamental model of who can do what is more than just code, and any lack of understanding or buy-in to its use probably undermines most of the good intentions of a well-orchestrated automated workflow.
2. Understanding your organisation’s access control model
Zero Trust was easy to set up, right? Everyone “agreed” it was the right decision? Security is everyone’s responsibility, so the policy model on which it depends was agreed and understood by all?
So, following agreement, the model was loaded into the appropriate database and accessed by the underlying tools charged with enforcing that policy model. Then, if not before deployment, something changed: someone changes area, a different team picks up a project from a struggling team, and so on. Does the model still work with potentially daily, or hourly, changes? Who has responsibility for maintaining the underlying data to make it work?
Context is everything.
Understanding the implications of a change and relating these to an informed set of judgements on a policy-based challenge (e.g. a request for permission to access a certain database from someone in a different area) is probably not the top issue on everyone’s to-do list.
So how can a modern Zero Trust system empower those who have an understanding of who should have permission to a specific asset, but don’t have it as their main focus? Or, perhaps they haven’t received an access request for the last few months and have forgotten the 1 hour talk or online training showing how easy it was.
Making Zero Trust easy to understand
A Zero Trust system should be clear and easily understandable. As a result, your team won’t have to attend the training course or watch the video on how to config the GUI for a Zero Trust rule every time a change is needed.
Your organisation should trust you as the owner of a sub-set of controlling data, rather than the database itself, giving permission for a certain user to have a specific role, which then gives access with a predefined set of permissions – this can time bounded if necessary.
Accessing and presenting data clearly
Data should be presented clearly and memorably, enabling the first decision to be easily replicated. Recommended decisions in place of a blank decision could make it much easier to click approve or decline, rather than parking a decision until the training video has been reviewed.
Similarly, the work of data-centric security relies on usability. That usually means simplicity – clearly recognisable tags/labels and groups simplify the problem space for the decision maker by making a representation of the access model real and usable, as well as automatable.
Similar scenarios exist when we review the risks associated with the access, effectively standing back and looking at policy through a different lens. For example, does the whole department need to see all the records for the last 5 years, or just the last six months – especially when they’ve never accessed those records in the last six months?
Finally, defining review policies should be presented in a visually attractive, easily understood way as opposed to a 2 hour checklist review.
How Nexor can help
Well connected security solutions and tools from trusted vendors such as Nexor can understand more than a simple pass/block command. On top of this, in-built intelligence from years of secure domain protection can be applied to help simplify the model, trusting the vendors to deliver something more than a dumb API.
Author Bio – Peter Austin
Peter Austin is Nexor’s Portfolio Manager. He has more than 15 years’ experience in the information security field, having previously worked for a major Managed IT services organisation, where he was responsible for development and accreditation of secure networking services.