Zero Trust - Its An Architectural State of Mind

Author: Colin Robbins

What Is Zero Trust?

The term Zero Trust was first coined by John Kindervag in 2010, building off a concept put forward by David Lacey at the Jericho Forum, an international group founded in 2004 that worked to promote deperimeterization.

Deperimeterization means to “protect an organisation's systems and data on multiple levels, by using a mixture of encryption, secure computer protocols, secure computer systems and data-level authentication” (Wikipedia). Our Managing Security Consultant, Colin Robbins, has been discussing deperimeterization for over 5 years.

Over the past few years, the world has seen a period of digital transformation. The increasingly popular use of Cloud-based solutions and remote working are eroding traditional security boundaries. Network architecture is changing, as static work environments are being phased out in favour of letting employees work from any location at any time.

In this new world, the role of local networks and Intranet changes, it no longer poses a significant security boundary, as business data is now outside of that network on cloud services. Thus, the priorities of the local network have shifted to providing access, not security. The need for security has not been diminished and a replacement solution must be found - this is where Zero Trust fits in - it helps provide confidence that your users and devices are appropriately trusted to be able to access your (on premise and cloud-based) services.

Zero Trust Architecture - NCSC

Zero Trust is a term being (mis)used by some product vendors, to push their unique angle on it. To cut through this, the NCSC, along with techUK, are working toward a non-partisan view of the base principles.

As part of this, the NCSC has developed a series of principles that will help people understand and migrate to a zero trust architecture. These principles are still in development and they have recently reduced the 10 alpha principles down to 8 beta principles.

The 8 Beta Principles

1. Know your architecture including users, devices, and services

You need to know your assets - who are your users, what trusted device do you expect them to use, and what services are they likely to need access to? Who or what are you prepared to trust to access services via a cross domain solution?

2. Know your user, service, and device identities

Often attributed to the aforementioned Jericho Forum is the phrase “Identity is the new frontier”. Simply knowing your users and devices is not sufficient - how are they going to demonstrate they are who they claim to be when on the other end of a network connection? A Cross Domain Solution will, most likely, want to be certain as to who is trying to use the service.

3. Know the health of your users, devices, and services

This is where Zero Trust starts to add a new dimension, simply knowing the right user is at the end of the network connection is not sufficient. They may be on a malware-ridden PC (even if it is the right PC). Is that PC up to date with the latest patches and compliant with the anti-malware policy?

This is a significant advantage for a cross domain solution, whose role is often to protect from malware import. If the “sender” of the data is now fully compliant with security policy, the risk level of the data transfer is reduced.

4. Use policies to authorise requests

Based on the above points, we know the users and devices are trustworthy. But are they authorised to access the service? Why does a sales guy need to see the underlying technology? This is fundamentally what Cross Domain Solutions do. They authorise data transfers between domains based on their compliance to security policy.

5. Authenticate everywhere

In a Zero Trust model, the network is assumed hostile, thus all connections need to be authenticated to ensure the request is from a trusted source. This applies to cross domain solutions that are becoming increasingly modular. The modules need to authenticate each other.

6. Focus your monitoring on devices and services

Despite putting in place great protection mechanisms, at some point you will still be attacked, but that attack could now be anywhere - including a cloud service no longer on your network. How are you going to monitor the service to get the earliest possible indication something is awry?

A Cross Domain Solution needs to be part of that monitoring governance mechanism, with the added complication of not allowing the Cross Domain Solution to straddle the two domains, providing a bypass.

7. Don't trust any network, including your own

Your network is just as likely to be attacked as anyone else's. This includes the Cross Domain Solution itself. A good Cross Domain Solution will provide mechanisms to protect itself.

8. Choose services designed for Zero Trust

Fundamentally, if your services adopt points 1-7 above, and do them well, you're going to carry less security risk. Ask your Cross Domain Solution supplier how they adopt these principles. If they start talking about how their appliance, device, or black box implements Zero Trust, then they have probably misunderstood your question, and you should inquire about their overall solution architecture.

Why Zero Trust is important in Cross Domain

Traditional cross domain solutions act as a “bump in the wire”, and are designed to enable data transfers between systems that have different security policies of levels of trust. In short, they identify how the two systems can be physically connected via network cable, then provide a cable, with a strong security device built in to verify the data that runs over the cable complies to security policy. Without a Cross Domain Solution in many cases, the data transfer may otherwise be prohibited by policy.

In such solutions, a significant element of trust is placed on physical access to the “wire”, so you know exactly what is connecting to what.

As Cross Domain Solutions adopt more modular architectures and embrace the cloud, then zero trust principles become key, as you can no longer clearly identify the “wire”, IT “in the cloud” or “software defined”.

Thus, the trust in the wire erodes, and knowing what is connected to the far end of the wire becomes more important. Zero trust principles let you know what is at the end of the wire!

Nexor's Cyber Resilience consulting team can support your business, identifying where and how the zero trust principles can be adopted to provide great levels of trust and usability in your secure information exchange solutions. For more information, get in touch with our team.

Read more posts on

About the author

Colin Robbins is a Principal Security Consultant, leading customer-funded research activities in secure interoperability and information exchange. He has specific technical interests in the Single Information Environment and Data Centric Security, as well as the processes of security, such as Secure by Design and Information Security Management Systems (ISMS). He is a Fellow of CIISec, and a former NCSC certified Security and Information Risk Adviser (Lead CCP).

Colin Robbins on Linkedin

Read more posts by Colin Robbins