Data-Centric Security (DCS) is a widely used term for the security practice of focusing on the security of data and how data is secured throughout its lifecycle. This is distinct from traditional Network-Centric Security approaches that work on the principle that if the network is secure, the data it holds will be secure.  However, unless carefully applied, use of Data-Centric security can create interoperability challenges.

Data-Centric Security is a Strategic Solution

Data-Centric Security is a strategic solution for the MOD, NATO and Allies to protect data as it moves between national systems, partner networks and international alliances.  It provides a way of ensuring the security of data with some level of independence from the security of the underlying networks, which would be hard to assess in a many-partner collaborative system.

At the heart of the Data-Centric Security model, there are three concepts:

Control – The owner of the information can describe how the data is to be handled; for example, classification and who it can be released to. This information is encoded in meta-data cryptographically bound to the data to ensure the integrity of the meta-data. (If only the meta-data is supplied, without a secure binding this is referred to as DCS Level 1). NATO labelling standards (STANAGs) specify an internationally agreed and interoperable way to be able to label data, whereby any type or format of metadata is trustworthily associated to any type or format of data. "Trustworthy-ness" of the label is delivered by digital signatures to bind labels to data.

Protect – A Data Centric Security model will describe how the data is protected, at rest, in transit and in use. This may be via an access control mechanism (often referred to as DCS Level 2), or via an encryption method (DCS Level 3). Widely agreed standards are less mature than with the control labels.

Share – Crucially, the DCS mechanisms are designed to share information between different organisations, which requires the agreement of the data formats, meta-data formats, access control mechanisms and encryption mechanisms. As we shall discuss in this blog, there is an issue in these data formats to achieve wide-scale interoperability.

Interoperability

There is a strategic desire for the MOD, NATO and allies to be able to seamlessly share information in what is often referred to as a Single Information Environment. The role of the Single Information Environment is to enable friction free access to data. It connects sensors, systems and platforms within and between domains, via decision makers at the relevant levels of command. This is all carried out in real time to achieve a multi-domain effect that adds up to far more than simply the sum of the parts.

To achieve this level of interoperability requires common standards. However, most end systems are proprietary and hold data in some form of native data format. Achieving interoperability requires that data is transformed from one format to another to enable the data to be understood (both syntactically and more importantly semantically). See the Nexor blog Series “Interoperability – Are we there yet?” for more information on the challenges of achieving interoperability, and the complex role of standards.

Data-Centric Security Meets Interoperability

A quick recap – Data-Centric Security uses digital signatures to detect if data has been modified. Interoperability requires data to be transformed between formats.

Can you see the issue? The data transformation required to achieve interoperability breaks the digital signatures required by Data Centric Security if the transformation takes place after the DCS is applied. But Data-Centric Security is designed as an end-to-end solution.

So, by implication, Data-Centric Security cannot be used end-to-end unless there are very specific standards for every type of data transfer that is used natively by every application – something that has so far eluded the military world.

End-to-End Data-Centric Security

Let’s explore this a little further. Let’s say a MOD System uses a JSON data format internally. Data Centric Security is used, so we add a DCS wrapper around the data – DCS(JSON). Now, consider what happens when this is sent to a NATO System which natively supports XML. The NATO system unwraps the data to extract – JSON – and can now use it – if and only if, it recognises the JSON data format or converts it to its own XML format i.e., the NATO systems need to be able to cope with JSON and XML.

Using this model, every system MUST understand the data formats used by every system it wishes to communicate with – a so called N-Squared interoperability problem.

NOTE, the JSON/XML example is simply to achieve data syntactic interoperability, ignoring the more complex challenge of data semantic interoperability (i.e., understanding the meaning of the JSON).

This is why standards are crucial – in this example, MOD and NATO must agree on a common format to be used to avoid the N-Squared issue – we discuss why choosing standards is not simple in the Nexor blog “Standards and Interoperability ”.

Only by both systems natively supporting the agreed standard, can DCS be used end-to-end. Getting native support is a long game. In the interim, the system will need to transform from internal formats to the agreed interoperability standard.

Data-Centric Security Trust Gateways

So, this leads to the need for trusted gateways at system boundaries. The gateway will provide the data transformation required between the internal format and the agreed interoperability standard, and then add the DCS signature. For example, the security is added at the gateway, or system boundary - the very challenge DCS has tried to avoid. The solution has become system centric by accident.

This is not as bad as it may seem at first sight. It’s system-centric and not network-centric or domain -centric – the world we really do want to avoid. If deployed at the edge of each system – where the proprietary solution meets interoperability standards, then DCS is applied as soon as the data leaves the proprietary world and is used to protect the data on its interoperable journey.

To give an example, if I send you an email, the security would be added by my email server as it leaves the Nexor domain, but not my email client as it leaves my laptop. Between my email client and email server Zero Trust techniques are used to ensure the message sent by the server is the one I intended (this is actually how email security works today, as S/MIME was too hard to deploy to the desktop).

Data-Centric Security and Zero Trust

The consequence is there is a partnership between Zero Trust Security Architecture and Data-Centric Security Architecture. Use Data-Centric Security where it makes interoperable sense, leveraging Zero-Trust Security from the point the data is generated to the point where DCS can be sensibly applied.

This encourages the argument used by many that Data-Centric Security is an overlay on Zero Trust Security, adding another layer of trust, where you cannot be sure of the security of transient networks, clouds or data storage used in the data lifecycle.

The Data-Centric Security Challenge

Data-Centric Security has been shown as viable in controlled experimental or collaborative environments, where project specific DCS security architecture and data-interoperability standard choices have been agreed upon. However, for DCS to be openly deployable outside of these tightly managed environments, widely agreed data-interoperability standards and DCS deployment architectures will need to be agreed upon, and adopted, by all communicating parties, otherwise “DCS islands” will appear, resulting in the need for DCS to DCS gateways. This presents a barrier to inter-domain and international collaboration .

We've been here before, S/MIME was a great concept and worked in closed user groups, but the deployment and interoperability challenges stopped widescale adoption across the Internet.

Solving the Data-Centric Security Challenge

Leadership is needed to recognise that Interoperability and Security cannot be treated as two stove pipes at architectural and standards levels. You cannot design or evolve an interoperability solution that uses DCS, unless DCS is baked into the solution architecture. The old security adage of you cannot bolt security on applies to DCS.

This should lead to an architecture that encompasses both interoperability and security.

The Single Information Environment research being undertaken by Nexor provides a framework within which DCS can live alongside Zero Trust, to provide long term data protection where needed, leaving Zero Trust to provide the broader security control at the edges.

Come and talk to Nexor about your security and interoperability challenges before you back your security project into an interoperability challenge.