In the blog “Interoperability – Are we there yet”, I discussed the challenges getting dislike systems from interoperating, recommending that it is crucial to consider the different levels of interoperability:
Technical Interoperability;
Syntactic Interoperability;
Semantic Interoperability;
System Interoperability;
Business Interoperability.
As discussed in the previous blog, failing to consider each level, has led to some well documented business outcome failures, with the finger often being firmly pointed at the higher levels of the interoperability hierarchy.
Security adds a new dimension to the challenge, and can play out at any level, constraining interoperability and thus restricting positive business outcomes.
Broadly, there are two approaches to securing an information flow:
A point-to-point approach, where each hop in the security chain is secured;
An end-to-end security solution when the content is protected irrespective of the network security controls.
Point-to-point
In a point-to-point solution, each communication step is secured using a method optimised for that step. For example, a web browser using HTTPS to secure a data transfer to a web server. The web server may use different techniques to the onward transfer of that data to an application server, partner system or a database server. The key feature is the data itself is not protected; the channels used to transfer the data are.
The challenge with this approach, is the overall security of the system is only as secure as the weakest link in the chain – which could be the web server in the example above. If the webserver itself is not secure, the fact HTTPS is used to pass data to it is irrelevant (and many argue provides a false sense of security). How many times have we seen documented security failures, where an intermediary point has failed, such as a mis‑configured firewall or poorly implemented authentication control?
However, the good thing about this approach, is that generally it does not interfere too much with any interoperability architecture. Each point in the chain can chose the protocol and content formats most likely to achieve interoperability, and security can be applied at the protocol level.
End-to-end
In an end-to-end security solution, the sending system uses cryptography to protect the data to be communicated. The crypto-protected data is passed to the communication system. Examples include S/MIME and Data Centric Security , when the data to be communicated is placed inside an encrypted wrapper.
This overcomes the weakest link in the communication chain problem – If the communication channel has security weaknesses, the data is protected by the cryptography.
The challenge with this approach is it pushes data interoperability issues to the end point. Both sender and receiver need to agree on the content format. If they use different formats (for example sender XML and recipient JSON), either the sender needs to know what the recipient can accept and transform it for them (e.g., convert to an agreed JSON format), or the receiver needs to be able to transform the XML (taking into account the interoperability hierarchy – just understanding the XML is insufficient). This pushes interoperability complexity to the system edge, and by implication limits scalability.
As an example of this, lets return to a subject I covered in the blog “What can DCS Learn from S/MIME?”. Research into email security developed an end-to-end solution (S/MIME), but the interoperability and implementation challenges mean that email security today relies on point-to-point solutions.
The end-to-end approach also requires crypto systems interoperability, which has so far evaded widescale adoption in anything but a closed system.
Where does this leave us?
In practice, to achieve interoperability, you have to work with the capabilities of the systems you are connecting. Some may use a point-to-point security approach; others may use an end-to-end security approach. So, in practice you end up with a hybrid approach utilising gateways and proxies, which add complexity. With complexity comes the risk of weak links, which is back to the challenges of a point-to-point approach.
The Zero Trust approach has been put forward as a way of dealing with understanding and mitigating risks associated with these weak links, and in the 3rd blog in this series I will explore how Zero Trust helps, as part of an overall Secure by Design approach.
Data Centric Security is a current focus of research and a strategic desire in many environments. However, unless designed and deployed carefully, using a Secure by Design / Zero Trust approach Data Centric Security risk harming system interoperability, which could lead to its downfall, just like S/MIME vision. Standards are often put forward as the solution – in the 4th blog in this series we will explore how poor standards can be part of the problem in achieving secure interoperability.
NOTE: this blog has primarily considered data confidentiality and integrity – a significant concern in system interoperability. However, other situations may have additional security concerns such as data availability and traffic analysis – all more reason as to why a Secure by Design approach must be taken.
The Interoperability Series
This is part 2 of a 4 part series on Interoperability explore the full story:
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).