Zero trust is not a magic black box product either. Those that know me are aware that I’m very much a “let’s go back to first principles” kind of person, and often that has saved me from going down rabbit holes, or has found overlooked flaws in previous enterprise architectures and highlighted a clearer path to success.

Over the years, I’ve used Zero Trust Network Access (ZTNA) patterns to create holistic approaches to identity management in large enterprise networks, sometimes with isolated and air-gapped secure enclaves. As a pattern, it has tremendous value in enabling secure access to networks and applications of various sensitivity, especially in large services organisations, as often they are simple and secure solutions that prevent anti-patterns from taking place. However, I believe it’s more than just an architectural pattern. It’s an excellent information assurance principle that makes you think about how and why you begin to trust things.

Having spent the last 18 months full time in the defence and national security sector, I think it’s time we take zero trust back to first principles about what it truly means, if the data centric interoperability challenges are to be solved in the sector.

Inherently, zero trust doesn’t mean that you must stop trusting things completely. At some point you have trust to a certain degree of a system you’re using in order to perform your required tasks. However, there are several things you need to know about a system before you trust it.

Cash machines are an excellent example of how we might apply zero trust attestation principles. They are often in completely open environments, open to tampering, with the potential to cause adverse financial impact if they go wrong – or are tampered with. There are known attack paths that enable criminals to perform attacks I care about such as card cloning, because that can impact my finances.

When you use a cash machine, do you trust the keypad you’re typing your PIN number into? Or if you’re like me, conscious of the risks of card theft and cloning, do you attempt to lift up the keypad and fascia of the card slot before you trust the machine to do your transaction? The example here is attestation. Before I consider making a transaction on a cash machine, I subconsciously think about how I trust it.

Is there somebody looking over my shoulder as I type my PIN number in – or a camera? I can look around and see if that’s the case. Perhaps give a disapproving glare to the shoulder surfer until they disappear.

Has it been obviously tampered with by fitting known card-cloning devices to the outside of the machine? I can feel the machine and identify malicious devices that have been fitted to it, and look for signs of tampering such as attempts to defeat the locks that protect machine.

Is the network likely to have a man-in-the-middle attack? I make sure I use cash machines that are operated by banks that ultimately gain attention from the NCSC to make sure they’re following the correct security designs, which mandate various patterns to make those man-in-the-middle attacks less than likely.

If I still need to get cash and I can’t positively answer the attestation questions, I still have options. The first is quite obvious, don’t use the cash machine. The second is, if I don’t trust the cash machine, is there something I can do to limit the domain of damage? The answer of which is absolutely. If I’m really desperate for cash, I can use one of my challenger bank cards that allow me to place a limit or freeze and destroy the card after use, such that if the details are cloned, the card will not be useful after I’ve made my transaction.

NIST 800-207 – the model Zero Trust Architecture – describes this quite eloquently. Before your policy decision point, you have no level of trust. After your policy decision point, you have an implicit trust zone. That level of trust is ultimately determined by what attributes you’ve collected before making your policy decision. To return to the cash machine analogy, I can reach my policy decision point once I’ve collected the attributes about the environment and the machine itself. That implicit trust zone can change dynamically based on what attributes I’ve collected – whether to use my normal bank card, my challenger card, or not to use the machine at all.

The key part here is to go back to the first principles of this analogy. What attributes did I collect to ultimately achieve some implicit trust?

Whilst Secure by Design means slightly different things to the UK Ministry of Defence and the National Cyber Security Centre, they ultimately have the same core principles crossing over. It’s about building security from the outset, and building it as the core of a system, not bolting it on to the side. It’s about understanding what the system is going to do and the information it’s going to process. It’s about understanding what threat actors are going to be interested in that system, and how they’re going to try and attack it.

Ultimately, you can use the processes within Secure by Design to enable the identification of the correct attributes you need to inform your zero trust policy, to realise your Secure by Design solution. What attributes do you need to have ongoing confidence that you can trust your system?

Taking zero trust even further back to first principles, even walled gardens have attributes about them that allow you to trust them to a certain degree. That is a key consideration for when you consider your zero trust policy, and how you analyse adjacent networks with differing policies.

In the future, I will discuss some of the research and integration projects I’ve been working on (somewhere, and the ones I can talk about) that show where data centric security (DCS) / data centric interoperability (DCI) align with zero trust, and the story really is all about attributes.

Zero trust is the pathway to Secure by Design. Zero trust is the pathway to realising DCI.