NATO vision for DCS is to deliver shareable, timely and reliable information: protected at source; and, controlled for life.

NATO strategy for implementing DCS is evolutionary defined by three Maturity Levels (MLs), whereby each ML facilitates interoperability and builds ontop of each other to reach the defined end-state.

DCS ML 1: Basic Labelling (DCS-1) – Facilitated by the NATO standards (STANAG 4774, STANAG 5636 and STANAG 4778) to provide consistent, reliable and trustworthy labelling with metadata associated for use with all common types of file formats and core services. Use of the XMLSPIF is fundamental for ensuring confidentiality metadata (STANAG 4774 confidentiality label and confidentiality clearance) is consistently applied and consistently displayed based upon the governing security policy that is being enforced.

DCS ML 2: Enhanced Labelling (DCS-2) – Facilitated by the emerging NATO standard (STANAG 5663) to provide federated identity and access management (FIAM) and facilitate attribute-based access control (ABAC). The “Holy Trinity” (not George Best, Dennis Law and Sir Bobby Charlton) of STANAG 4774 confidentiality label, STANAG 4774 confidentiality clearance and XMLSPIF are used to provide Confidentiality Metadata-based access Control (CMBAC; pronounced as “Come Back“), fundamental for facilitating ABAC. XMLSPIF specifies the rules for how CMBAC is enforced based upon comparing the confidentiality metadata value domains provided in a STANAG 4774 confidentiality label (associated with a resource) against a STANAG 4774 confidentiality clearance (associated with a Subject i.e. a user, application device or service). Implementation of CMBAC (as illustrated below), through the ratification of ADatP-5663: Federated Identity, Credentials and Access Management, is recognised as a core capability for evolving NATO DCS vision and strategy towards achieving DCS-2.

DCS ML 3: Cryptographic Protection (DCS-3) – NATO currently do not have a standardised approach for achieving DCS-3.

STANAG 4774 provides a XML syntax for representing a confidentiality label in an arbitrary policy, and includes information about the life-cycle of the confidentiality label e.g. when it should be reviewed.

An example of simple confidentiality label using the example AMOCO security policy, is shown below:

<slab:originatorConfidentialityLabel>
  <slab:ConfidentialityInformation>
    <slab:PolicyIdentifier>TEST-Amoco</slab:PolicyIdentifier>
    <slab:Classification>General</slab:Classification>
    <slab:PrivaryMark>MINIMUM</slabPrivacyMark>
   </slab:ConfidentialityInformation>
   <slab:CreationDateTime>
     2016-11-10T12:30:00Z
   </slab:CreationDateTime>
</slab:originatorConfidentialityLabel>

An XMLSPIF can be used to describe the value domains for the PolicyIdentifier, Classification, GenericValue (a category value), and PrivacyMark elements of the confidentiality metadata label.

The confidentiality metadata label syntax was designed to be used define metadata elements, with those metadata elements in turn being bound to information. STANAG 4774 defines two metadata elements that use the syntax:

• originatorConfidentialityLabel – the confidentiality label assigned to the information by the originator
• alternativeConfidentialityLabel – an confidentiality label in a different policy that is equivalent to the originatorConfidentialityLabel

The binding of metadata elements to information (both XML and non-XML) is the subject of a second STANAG, STANAG 4778, Metadata Binding Mechanism, which is expected to be ratified in 1Q18.

It is highly recommended that metadata elements which use the confidentiality metadata label syntax only use the STANAG 4778 binding mechanism to associate a confidentiality label with information.

STANAG 4774 is not openly available, so in order to obtain a copy of STANAG 4774, you should contact your National Technical Expert (NATEX).

In 2010, the group published for a proposal for an XML Labelling and Metadata Binding specification.

This work has gone on to be developed into two new Standards Agreements (STANAGS), which in turn, are cover documents for the associated Allied Data Publications (ADatPs)):

• STANAG 4774 – Confidentiality Metadata Label Syntax – an XML schema that can be used to represent a confidentiality (security) label.
• STANAG 4778 – Metadata Binding Mechanism - an XML Schema that can be used to bind arbitrary metadata (including metadata that uses the confidentiality metadata label syntax, to pieces of information.

Both of these STANAGs are currently in the process of being ratified by the NATO Nations.

STANAG 4774 defines the structure of a confidentiality label, which includes elements such as the policy identifier, classifications and security categories. The non-normative Annexes B and D of STANAG 4774 provide descriptions of two security labelling policies, “NATO” and “PUBLIC”, in the form of Security Policy Information Files (SPIFs), which provide the value domains for the elements of the confidentiality label.

The SPIFs in the STANAG obviously can only contain a snapshot of the NATO security labelling policy, as new categories are added and removed to support missions and exercises. However, an up-to-date SPIF is maintained in the NATO Metadata Registry and Repository (NMRR) (login required), along with the STANAG 4774 and 4778 XML schemas, and other associated artefacts.

One of the “notable interoperability highlights” identified in this year’s Final Report is that a CWID 2010 trial:

“Demonstrated a potential cross-domain solution to e-mail services, Extensible Messaging and Presence Protocol (XMPP) chat services, web services, and document sharing all of which were governed by a common security policy based on open standards to meet the requirements for providing a network enabled capability.”

This refers to a trial run by the UK to demonstrate Cross Domain Chat between the UK, US and NATO. The trial adopted the XMLSPIF schema in order to provide a revisable, extensible schema that could support widespread adoption. The UK were able to represent the US and NATO Security Labelling policies with this standard and hence define the equivalent security labels to support mapping of labels within Cross Domain Services. The UK SPIF was stored in the X.500 / LDAP Enterprise Directory and a number of services then retrieved the SPIF, via LDAP, in order to display and apply Security Labels, and also make Access Control Decisions.

Appendix C of UK Cross Domain Chat Technical Report contains an XMLSPIF representing UK JSP 457 Volume 7 Electronic Labelling Services used in the trial.

• Validity periods for the whole policy and individual category values.
• MarkingData and MarkingQualifiers for the SPIF, privacy marks and tag categories.
• Enhanced constraints on the number of privacy marks and tags that can be selected.
• Date format specification for category values containing a date.
• Required categories for an equivalent policy, classification and categories to provide enhanced equivalency mappings.
• Equivalency between tag sets, where the tag values are the same in each tag set. For example, ISO3166 country codes.
• Fixes to the schema constraints.

Version 2.0 of the schema replaces Version 1.0 of the schema at:
http://www.xmlspif.org/schema/xmlspif.xsd

The Version 2.0 schema is backwards compatible with Version 1.0. However, for those people who wish to specifically reference Version 1.0 of the schema, it is still available at:
http://www.xmlspif.org/schema/2009/03/xmlspif.xsd