Stereotypes, context and situational awareness.

One of the things most likely to put me into a strop is being told that "you can't do that!", particularly when such a statement is accompanied by absolutely no rationale as to why not. One common example of this is whenever I am told, or hear, or read, blanket statements about what CISOs (or other senior leaders) are, or are not, interested in.  "You can't say that to a CISO, they're just not interested". Oh really?

I have a few issues with such a blanket statement. Firstly, lived experience. I'm not a great fan of being told that some of the things I've done didn't happen. Secondly though, don't you think it's a bit simplistic to stereotype all CISOs as having the same interests, with the organisations that they work for all being in the same position with the same dynamics?  Consider the simple chart below:

You probably already know where I'm going with this. You can plot both individuals and organisations against these axes. There's also a time dimension - for example, a CISO may need to come in to fix a broken security function before then settling into a steady state. Individuals will often be more comfortable in specific quadrants - some folks love the challenge of driving difficult change, others love maintaining order.  There are no value judgments here. Likewise organisations: some will be in a good state and looking to keep things ticking over as they are, others will be in the middle of the churn of a fundamental transformation. It helps when you have a match between the leaders and the organisation! But that's a different topic. Anyway. Depending upon where the CISO is sitting at the time of your conversation then you may well find that they are interested in different topics. Clearly, going to a meeting with an assurance-focussed CISO, comfortable with the status quo in a stable and mature organisation, and trying to talk about the practicalities of moving towards zero trust, security by design or devsecops is unlikely to go well. Mention of DAST, SAST and SBOMs may well induce a few eye rolls. However, if you're talking to a CISO that has staked their personal reputation on delivering just such a transformation, don't you think they may have at least a little interest in how they could protect that reputation by talking through the "how" of how such a transformation can be achieved in the real-world? I'm not suggesting we have to talk 0000s and 11111s, raw TCP/IP or any other deep technical jargon relating to security transformation (although some modern CISOs have grown-up in the industry and it's not necessarily an alien tongue to them), but we certainly don't have to limit ourselves to platitudes and quotes by our favourite analysts.  Yes, there are some commonalities in the role of a CISO; the need to be able to manage upwards, the need to be able communicate with (and influence) business stakeholders, the need to be able to manage budgets, the need to be able to nurture and shield your team etc. However, if you find yourself being told that "the CISO won't be interested in that", then try asking the person telling you that whereabouts on the chart they'd place the individual CISO they have in mind. They may be right. But they may not be. It's probably worth finding out.

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?