In the blog “Interoperability – Are we there yet?”, I discussed the challenges getting dissimilar systems to interoperate, recommending that it is crucial to consider the interoperability as a hierarchy from technical interoperability to business level interoperability. This was followed by the blog “Secure Interoperability”, which looked at two broad security approaches, point-to-point and end-to-end, from the perspective of interoperability, concluding both have challenges to overcome – maybe Zero Trust can help.

What is Zero Trust?

That is not an easy question to answer.  There are the definitions from NCSC and NIST; then we have suppliers’ and vendors’ marketing teams spinning the term to align to the bit their solutions do, which adds confusion.

Additionally, the term Zero Trust itself implies not trusting anything – but the simple practicality is you have to trust something.  I challenge you to contact me with an example of a security solution where you literally trust nothing.

A better term would be “Understand what you are trusting and what makes it trustworthy”, but that is not quite as snappy for the marketeers to play with.

But this rephrasing is crucial to understanding how Zero Trust helps with Secure Interoperability.

NCSC Zero Trust Principles:

1. Know your architecture including users, devices, services and data.
2. Know your user, service and device identities.
3. Assess user behaviour, service and device health.
4. Use policies to authorise requests.
5. Authenticate and authorise everywhere.
6. Focus your monitoring on users, devices and services.
7. Don't trust any network, including your own.
8. Choose services which have been designed for zero trust.

Zero Trust and Secure Interoperability

Principle 7 of the NCSC Zero Trust Principles starts “Don’t trust any network…”, this is fundamental to secure interoperability.  How can you ensure that the system you plan to interoperate with is trustworthy?  You are implicitly trusting it to some level, as you are prepared to accept data from it!  How do you know that data is trustworthy?  The Zero Trust principles are insufficiently detailed to help us here, so we need to refer to NCSC Secure Communication Principles.

NCSC Secure Communication Principles:

1. Protect data in transit.
2. Protect network nodes with access to sensitive data.
3. Protect user access to the service.
4. Ensure secure audit of communications is provided.
5. Allow administrators to securely manage users and systems.
6. Use metadata only for its necessary purpose.
7. Assess supply chain for trust and resilience.

Principle 1 “Protect data in transit” was the focus of a previous blog in this series, offering two broad approaches: point-to-point security and end-to-end security.  With a point-to-point approach the Zero Trust principles are crucial to ensure you have a trusted path for the data, eliminating weak links – the history of security breaches has shown this is actually quite hard to do.

This is why there is interest in end-to-end approaches, as you eliminate the need to trust the intermediary systems – or do you?  When you dig into end-to-end security it turns out you still need to apply Zero Trust principles each hop of the way – “Don’t trust any network” – you could still be susceptible to network based attacks.  What is more, to make end-to-end approaches you need a secure key management approach, a big Zero Trust topic in its own right.

So, it turns out “Zero Trust” is crucial however you approach secure interoperability.  Zero Trust helps you “Understand what you are trusting and what makes it trustworthy” – a process encapsulated by the Secure by Design approach.

Taking “Understand what you are trusting” a step further: Principle 7 of the secure communication principles starts “Assess supply chain for trust…”, are you prepared to trust the system your are interoperating with?

If you are not prepared to trust it (I’d argue this is the situation in most cases for interoperating with external systems) applying the NCSC Cyber Security Design Principles, you need to follow Principle 2 - “Make compromise difficult”, which states “External input can't be trusted. Transform, validate, or render it safely” – the domain of security gateways.

 NCSC Secure Design Principles

1. Establish the context before designing a system.
2. Make compromise difficult.
3. Make disruption difficult.
4. Make compromise detection easier.
5. Reduce the impact of compromise.

Security Gateways

In point-to-point security the world of security gateways is well known and understood

Here I want to focus on gateways for end-to-end security.  The typical security gateway will deploy validation or transformation technology to detect or eliminate malware in the content – to do so it needs to able to access the content – which end-to-end security is design to prevent.

So, there is a dilemma.

• Do you modify the end-to-end security mechanism to allow the gateway to access the data?  In essence weakening the end-to-end solution architecture, introducing aspects of point-to-point security;

• Do you trust the data sender?  Zero Trust implies that is not a good thing to do.  What is the basis of that trust?;

• Rely on security controls into the recipient endpoint?  The history of cyber-attacks has shown this to be not very effective.

Zero Trust does not help here – these are architectural questions.  The Zero Trust principles offer guidance once architectural choices have been made.  As per the 1st Secure Design Principle, Zero Trust principles need to be adopted within the context of overall system being designed to understand the trade-offs, understand what is being trusted, and ultimately if it is trustworthy.

Conclusion

Secure interoperability is hard, balancing the need to remain flexible for interoperability, while being effective for security.  Zero Trust provides some of the tools, but still needs to be deployed using a robust process.  So, rather than talk about Zero Trust, I suggest we should be talking about Secure by Design, which embraces Zero Trust concepts.  By embracing Zero Trust concepts, we can determine the appropriate security controls to use, to provide security while maintaining interoperability.

In the final blog in this series on interoperability, I will talk about the role standards have to play – they are not always a good thing.

The Interoperability Series

This is part 3 of a 4 part series on Interoperability explore the full story:

1. Interoperability – Are we there yet?

2. Security and Interoperability – a Conflict

3. Zero Trust and Interoperability

4. Standards and Interoperability