Zero Trust - a little light grumbling.

I think I've reached the conclusion that if I haven't annoyed at least 5% (arbitrary figure) of my audience when talking about Zero Trust then I haven't done my job properly. Too many competing definitions, too many strongly held sacred beliefs. Naturally the next step is to see how many folks I can annoy on the Internet :). So, definitions for starters - I use NIST SP800-207 and the CISA ZT Maturity Model (now at v2) as my baseline. Vendor-agnostic. Analyst-agnostic. Wide in scope. Great fun for annoying folks who insist that ZT is purely focused on Identity or the Network*.  I do then try to simplify the topic:

⁌ every access request starts from a position of zero trust (applies to all entities - humans, devices, services)
⁌ authorisation is granted based on dynamic context (risk-based)**, ideally per request
⁌ assume breach - of user ID (including machine or application service ID), access device, transport network.

What does this give you? Well, you've done away with the arbitrary distinction between "inside" and "outside". You now need to do something about those legacy flat networks. Reduce your blast radius! You can also now give your users access to the business applications they need, wherever they (or those business applications) may be located.

You've also now got to do something about your machine (OT, IoT) and workload (VMs, cloud instances, containers, applications) entities so that a compromise of such entities doesn't mean easy traversal.

You're assuming breach, this means you should be embedding observability into your in-house developed apps and configuring everything else to generate the signals you need to automate and orchestrate those dynamic authorisation decisions.

In short, improved access for legitimate users, dynamic per request authorisation based on current context (including risk) for all entities and better visibility across your IT ecosystem, enabling faster detection and response.

I'm not sure why delivering those security outcomes remains a little controversial. Perhaps Zero Trust is just another one of those labels (like cloud) that rubs folks up the wrong way. Look past the label. Oh, and don't get too attached to specific definitions. Except the ones I like. Those ones are fine. 😇

*both key pillars to be sure, but not the sole focus.
**dynamic context - which is why your network microsegmentation is not really Zero Trust.

Growing pains?

An interesting story here on the legal status of relying upon US-owned cloud services for the processing of law enforcement data - https://www.computerweekly.com/news/365534023/Scottish-police-tech-piloted-despite-major-data-protection-issues.  The conflict of such processing with the obligations stated within Part 3 of the UK Data Protection Act 2018 is something that Owen has been raising for a long time now [Disclaimer: I’ve known Owen for years – he knows his onions] and it is good to see these issues now being explored more widely.

For me though, this is part of a wider re-evaluation of the usage of the cloud hyperscalers. Consider also the context of financial services regulators across the globe expressing increasing concern about systemic risk and how the reliance on a small number of hyperscale cloud providers impacts upon the current push to improve operational resilience across that sector.  Speaking of resilience, how comfortable should we be with quite so much of our public sector and other providers of Critical National Infrastructure (CNI) services being fulfilled by the same limited pool of US-owned services?  There is increasing discussion of Sovereign Cloud approaches (e.g. https://www.capgemini.com/insights/research-library/cloud-sovereignty/) however, in reality, can such sovereign solutions compete with the hyperscalers? The experience of UKCloud, an early entrant into the UK cloud market suggests it is a rough ride for smaller players (they were placed into compulsory liquidation in October last year).  Should pure commercial considerations be put aside and Government subsidies made available to provide safe, legal sovereign cloud services?  Can any of the hyperscalers derive ownership structures that provide genuine confidence that their “sovereign” solutions offer sufficient protection from US over-reach via the Cloud Act?

So, am I saying that we should avoid the hyperscalers? As ever, it’s more complicated than that (is that framing taking over from “it depends” as the consultant’s phrasing of choice?). The advantages of cloud services remain – for many the infrastructure, security and physical hosting services offered by the likes of AWS, Azure and GCP surpass those available using existing technologies and skillsets.  They have greater budgets for innovation, greater elasticity and, these days, a growing pool of certified talent able to deliver value to cloud consumers – at pace. I do however think that there is a growing conflict between the needs of individual organisations and the needs of wider sectors, their regulators and wider society.  The former (quite rightly!) want the best bang for their buck whilst the latter are more worried about the “severe, but plausible” events that may lead to catastrophic consequences.  I remain a big fan of the capabilities that the likes of Microsoft, Amazon and Google offer their consumers.  I remain of the view that, in the majority of cases, a new, well-configured, cloud-native solution will likely be more secure than a solution delivered through legacy alternatives. But there are tensions.  Looks like we are approaching the point where those tensions need to be properly explored and informed actions taken by both regulatory authorities and governments to better balance risk and reward for the societal needs that they are there to protect and serve.  Thoughts?