VWHP A KLWHFWX D FXPHQPrateek S Brent Nord Dan Segu Alan Claso Cord3 Inn Prepared Cord3 Inn 206-900...

DefenContractDRDC-ROctober 2

CWIXCONOPCross C

Glen HendAlan MagaJim MacAPrateek SBrent NordDan SeguAlan ClasoCord3 Inn Prepared Cord3 Inn206-900 MOttawa ONPSPC CoTechnical DRDC – CContracto

ce Reset Report DDC-2019-C2019

X2015 P and ReCoalition I

derson ar

Allister rivastava din

uin on ovations

by: ovations

Morrison Dr, N K2H 8K7 ntract NumbeAuthority: Da

Centre for Opr's date of pu

earch an

C256

Systemference AInformatio

er: W7714-08aniel Charleboerational Resblication: July

nd Deve

CAN U

CAN UNCLA

m ArchArchitecturon Exchan

FE01 ois, Defence search and Any 2015

lopment

UNCLASSIFIE

ASSIFIED

hitecture for a Dnge

Scientist nalysis

t Canad

ED

ure DoCS Deplo

a

cumenoyment in

nt Support oof

Template in use: EO Publishing App for CR-EL Eng 2019-01-03-v1.dotm

© Her Majesty the Queen in Right of Canada (Department of National Defence), 2015 © Sa Majesté la Reine en droit du Canada (Ministère de la Défense nationale), 2015

CAN UNCLASSIFIED

CAN UNCLASSIFIED

IMPORTANT INFORMATIVE STATEMENTS

This document was reviewed for Controlled Goods by Defence Research and Development Canada using the Schedule to the Defence Production Act.

Disclaimer: This document is not published by the Editorial Office of Defence Research and Development Canada, an agency of the Department of National Defence of Canada but is to be catalogued in the Canadian Defence Information System (CANDIS), the national repository for Defence S&T documents. Her Majesty the Queen in Right of Canada (Department of National Defence) makes no representations or warranties, expressed or implied, of any kind whatsoever, and assumes no liability for the accuracy, reliability, completeness, currency or usefulness of any information, product, process or material included in this document. Nothing in this document should be interpreted as an endorsement for the specific use of any tool, technique or process examined in it. Any reliance on, or use of, any information, product, process or material included in this document is at the sole risk of the person so using it or relying on it. Canada does not assume any liability in respect of any damages or losses arising out of or in connection with the use of, or reliance on, any information, product, process or material included in this document.

CWIX2015 System Architecture Document

CONOP and Reference Architecture for a DCS Deployment in Support of Cross Coalition

Information Exchange

Prepared by: Glen Henderson Cord3 Innovation

Date: Mar 29, 2015

Revision: Final v.1.3

C19-0916-02635_Document.docx

CONOP and Reference Architecture

July 31, 2015 Revision: Final v1.3 ii

Confidentiality This document is UNCLASSIFIED. Disclaimer A number of sections of the report are comprised of material contributed by multiple authors, most notably members of the Bell Canada / Cord3 Innovation team Authors

Cord3 Innovation Team Role Glen Henderson Lead System Architect Alan Magar Information Security Analyst Jim MacAllister Information Security Analyst Prateek Srivastava Senior Programmer Brent Nordin Senior Programmer Dan Seguin Senior Programmer Alan Clason Quality Assurance Specialist

Review

Cord3 Innovation Team Role Will Coxon Technical Project Manager



July 31, 2015 Revision: Final v1.3 iii

Executive Summary Data-Centric Security Service (DCSS) is a security overlay: a set of interconnected services that communicate through the exchange of messages on top of an existing network deployment. Any network security or application security based environment can be enabled for data-centric protection without the need to remove or de-emphasize existing security protections. In this way, an environment protected by DCSS retains the existing safeguards that were in place prior to the deployment of the security overlay. Additionally, DCSS itself is able to leverage existing physical, administrative, network and application safeguards as part of its deployment profile. Most significantly, the deployment of DCSS does not change the underlying accreditation of the target network by modifying the security architecture that was initially certified. This document provides information in support of the Canadian DCSS program participation at the Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise (CWIX) to be held in June 2015. At this experiment, the DCSS program team will be delivering new capabilities that build upon and extend the Data-Centric Security (DCS) information protection model. Specifically, these extensions will enable the exchange of information assets between national partners in a coalition environment in a manner that adheres to the principles of a DCS-based information protection architecture. These principles include:

1. The ability to apply national and cross coalition information handling policy decisions to individual assets;

2. The ability to ensure that information assets are not released to requesting users

or nations unless explicitly permitted by the national security policy; and

3. The ability to record the application of security policy decisions in a trusted and tamper-resistant audit store in support of incident analysis and forensic investigation.

This document describes the required enhancements and extensions to the current DCS information protection model that will support cross coalition information sharing and that will be demonstrated at the CWIX2015 experiment. In addition, this cross coalition capability is intended to achieve the following objectives:

1. To prove the viability of the DCS cross coalition trust model and information exchange framework as proposed in this document;

2. To validate the over-arching design decisions that form the core of the DCS

cross coalition information exchange functional model;

3. To observe the behaviour of the solution in an operational context with respect to:



July 31, 2015 Revision: Final v1.3 iv

a. Ease of implementation and deployment; b. Robustness of the security protection mechanisms; c. Operational performance;

4. To observe the proposed solution from a functional perspective and assess the

degree to which application support, information exchange and integration with established processes can be done seamlessly and transparently;

5. To gather evidence to justify further exploration, examination and evaluation of a

DCS cross coalition model; and

6. To mitigate risks associated with transitioning this capability to an operational environment.



July 31, 2015 Revision: Final v1.3 v

Table of Contents 1. INTRODUCTION ............................................................................................................. 1

1.1. DOCUMENT PURPOSE .......................................................................................................................... 2 1.2. DOCUMENT AUDIENCE ........................................................................................................................ 3 1.3. DATA-CENTRIC SECURITY PROGRAM HISTORY ......................................................................................... 3

1.3.1. Prior experiments .................................................................................................................... 5 1.3.2. The CWIX2014 Exercise ........................................................................................................... 5

1.4. CWIX2015 ....................................................................................................................................... 7 1.5. ASSUMPTIONS .................................................................................................................................... 7 1.6. GLOSSARY ......................................................................................................................................... 8 1.7. DOCUMENT OUTLINE .......................................................................................................................... 9

2. DCS CROSS COALITION INFORMATION EXCHANGE ........................................................ 10 2.1. DATA-CENTRIC SECURITY WITHIN NATIONAL NETWORKS......................................................................... 11 2.2. THE CROSS COALITION TRUST MODEL .................................................................................................. 12 2.3. GENERAL MODEL FOR CROSS COALITION INFORMATION EXCHANGE ......................................................... 14 2.4. DCS CROSS COALITION SOLUTION REQUIREMENTS ................................................................................ 16

2.4.1. Electronic Memorandum of Understanding .......................................................................... 17 2.4.2. Cross Coalition Asset Transfer ............................................................................................... 23 2.4.3. Border PEPs ........................................................................................................................... 25

2.5. DETAILED MODEL FOR CROSS COALITION INFORMATION EXCHANGE ......................................................... 30 2.5.1. Information Exchange at the Network Level ......................................................................... 31 2.5.2. Information Exchange at the Data Asset Level ..................................................................... 32

2.6. DCS CROSS COALITION INFORMATION EXCHANGE SUMMARY .................................................................. 35

3. CWIX2015 CONCEPT OF OPERATIONS ........................................................................... 36 3.1. TARGET ENVIRONMENTS AND DEPLOYMENT MODELS ............................................................................. 37 3.2. GENERAL DEPLOYMENT REQUIREMENTS ............................................................................................... 38

3.2.1. MNE Overlay Configuration .................................................................................................. 40 3.2.2. MNE Equivalent Configuration .............................................................................................. 42 3.2.3. MNX Configuration ................................................................................................................ 43 3.2.4. Federated Mission Network .................................................................................................. 44

3.3. CAPABILITIES UNDER EVALUATION ....................................................................................................... 45 3.3.1. Updates to the National Information Protection Model ....................................................... 45 3.3.2. Cross Coalition Information Protection ................................................................................. 46 3.3.3. Security Label Equivalency Service ........................................................................................ 46 3.3.4. Transport Security Label ........................................................................................................ 47 3.3.5. Cross Coalition Cryptographic Protections ............................................................................ 48

3.4. APPLICATION SUPPORT ...................................................................................................................... 48 3.4.1. Email ...................................................................................................................................... 48 3.4.2. Instant Messaging ................................................................................................................. 54 3.4.3. Simulated Global Command and Control Systems (SIMG) .................................................... 60

4. CWIX PROTOCOLS AND DATA STANDARDS ................................................................... 63 4.1. NETWORK PROTOCOLS ...................................................................................................................... 63

4.1.1. DCS SOA Messaging Protocols .............................................................................................. 63 4.1.2. Security Labelling Equivalency Service Protocol .................................................................... 64 4.1.3. Cross-Coalition Email Protocols ............................................................................................. 65



July 31, 2015 Revision: Final v1.3 vi

4.1.4. Cross Coalition IM Protocols .................................................................................................. 65 4.1.5. Cross Coalition SIMG ............................................................................................................. 66

4.2. SECURITY LABELLING STANDARDS ........................................................................................................ 66 4.2.1. Titus Document Security Label .............................................................................................. 66 4.2.2. Transport Security Label ........................................................................................................ 67

4.3. CRYPTOGRAPHIC MECHANISMS ........................................................................................................... 69 4.3.1. Asset Protection .................................................................................................................... 69

5. SYSTEM REFERENCE ARCHITECTURE ............................................................................. 71 5.1. COMPONENT MODEL ........................................................................................................................ 72

5.1.1. MNE Infrastructure Components .......................................................................................... 72 5.1.2. Existing DCS Components ...................................................................................................... 74 5.1.3. Enhanced DCS Components................................................................................................... 75 5.1.4. New DCS Components in Support of Cross Coalition Information Sharing ........................... 77

6. CWIX2015 SCENARIO SUPPORT .................................................................................... 80 6.1.1. Testing Strategy .................................................................................................................... 80 6.1.2. Evidence Gathering ............................................................................................................... 81

7. REFERENCES ................................................................................................................ 82

Table of Figures

FIGURE 1: DCS-BASED CROSS COALITION INFORMATION EXCHANGE .......................................................................................... 10 FIGURE 2: DATA-CENTRIC SECURITY FOR NATIONAL NETWORKS ................................................................................................ 12 FIGURE 3: CROSS COALITION INFORMATION EXCHANGE ........................................................................................................... 15 FIGURE 4: NATIONAL DOMAIN LABELLING HIERARCHY ............................................................................................................. 20 FIGURE 5: OUTBOUND BORDER PEP OPERATIONS .................................................................................................................. 27 FIGURE 6: INCOMING BORDER PEP OPERATIONS ................................................................................................................... 29 FIGURE 7: A CROSS COALITION INFORMATION EXCHANGE TRANSACTION .................................................................................... 30 FIGURE 8: CROSS COALITION SECURITY LABEL TRANSLATION ..................................................................................................... 33 FIGURE 9: PROPOSED MNE ENVIRONMENTS FOR THE CWIX2015 EXERCISE ............................................................................... 38 FIGURE 10: MNE OVERLAY DEPLOYMENT ............................................................................................................................ 40 FIGURE 11: MNE EQUIVALENT WITH MNX CAPABILITY .......................................................................................................... 42 FIGURE 12: MNX CAPABILITY THROUGH COI SEPARATION ...................................................................................................... 43 FIGURE 13: NATIONAL PROTECTIONS ON SENDING EMAIL ........................................................................................................ 49 FIGURE 14: BORDER PROTECTIONS ON SENDING EMAIL ........................................................................................................... 50 FIGURE 15: BORDER PROTECTIONS ON RECEIVING EMAIL ......................................................................................................... 52 FIGURE 16:NATIONAL PROTECTION ON RECEIVED EMAIL MESSAGES .......................................................................................... 53 FIGURE 17: PARTICIPATION IN COALITION HOSTED CHAT ROOMS .............................................................................................. 55 FIGURE 18: MESSAGING IN COALITION HOSTED CHAT ROOMS .................................................................................................. 57 FIGURE 19: NATIONAL SUBCHANNELS IN COALITION HOSTED CHAT ROOMS ................................................................................ 59 FIGURE 20: COALITION-BASED SIMULATED GCCS (SIMG) ....................................................................................................... 61 FIGURE 21 - SLES DEPLOYED ARCHITECTURE ......................................................................................................................... 65 FIGURE 22 – ASSET PROTECTION ......................................................................................................................................... 70 FIGURE 23: CWIX2015 REFERENCE ARCHITECTURE ............................................................................................................... 71



July 31, 2015 Revision: Final v1.3 vii

Document History

Version Date Comments

Final 1.1 31 Dec 2014

Final submitted for review

Draft 1.2 25 Mar 2015

Updates to the document include:

i) Updated document to reflect current state of the project

ii) Removed all content/references to the Transport Container (TC)

iii) Removed all content/references to the Transport Container Security Label (TCSL)

iv) Removed all content/references to the Transport Container Service (TCS)

v) Changed GCCS to SIMG throughout the document

Draft 1.2 29 Mar 2015

Updates to the document include:

i) Addition of an Executive Summary

ii) Addition of the Document History

iii) Made a number of minor revisions based on feedback received from the team

Final 1.3 31 July, 2015

Added additional clarifying information from the observed results from the CWIX2015 exercise (June 2015).



July 31, 2015 Revision: Final v1.3 1

1. Introduction This document provides information in support of the Canadian Data-Centric Security Service (DCSS) program participation at the Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise (CWIX) to be held in June 2015. At this experiment, the DCSS program team will be delivering new capabilities that build upon and extend the Data-Centric Security (DCS) information protection model. Specifically, these extensions will enable the exchange of information assets between national partners in a coalition environment in a manner that adheres to the principles of a DCS-based information protection architecture. These principles include:

1. The ability to apply national and cross coalition information handling policy decisions to individual assets;

2. The ability to ensure that information assets are not released to requesting users

or nations unless explicitly permitted by the national security policy; and

3. The ability to record the application of security policy decisions in a trusted and tamper-resistant audit store in support of incident analysis and forensic investigation.

This document describes the required enhancements and extensions to the current DCS information protection model that will support cross coalition information sharing and that will be demonstrated at the CWIX2015 experiment. That is, this document will identify how DCS-based cross coalition information exchange can be achieved by leveraging and combining:

• The trust that is established as part of the standard operating procedure for standing up a coalition network environment; and

• The trust that is established within a national network when information

protection practices based on DCS principles are used to secure information assets.

DCSS is a security overlay: a set of interconnected services that communicate through the exchange of messages on top of an existing network deployment. Any network security or application security based environment can be enabled for data-centric protection without the need to remove or de-emphasize existing security protections. In this way, an environment protected by DCSS retains the existing safeguards that were in place prior to the deployment of the security overlay. Additionally, DCSS itself is able to leverage existing physical, administrative, network and application safeguards as part of its deployment profile. Most significantly, the deployment of DCSS does not change the underlying accreditation of the target network by modifying the security architecture that was initially certified.




The DCS protection model provides a degree of trust by ensuring the responsibility for the protection of information assets lies at the national level. The cross coalition trust model builds upon this trust to enable information sharing across partner nations in a coalition environment. This layered approach to leveraging established trust is the principle upon which DCS cross coalition information exchange is founded.

1.1. Document Purpose While this document presents a comprehensive description of the cross coalition DCS trust model and all the capabilities that are needed to support this model, it also describes the technology target for the CWIX2015 experiment. The CWIX2015 technology target is a subset of the overarching DCS cross coalition information protection model that is intended to:

1. Validate the trust model design decisions;

2. Provide evidence in support of the viability of the DCS-based approach for information exchange in a coalition environment;

3. Identify new, or refine existing, requirements for the components in the proposed

solution; and

4. Gather evidence in support of the acceptability of the proposed cross coalition information exchange capability.

This document will serve as the baseline definition for the technology target that will be delivered for the CWIX2015 experiment. This document provides:

• High level architectural description of the new DCS cross coalition capability that will be demonstrated;

• Identification of enhancements to the existing national DCS model required to

support a cross coalition capability; and

• A description of how the new cross coalition DCS model will be deployed as an overlay to existing coalition network and application infrastructures.

This document identifies the information standards that have a bearing on the deployed solution including:

• Data format standards for information assets;

• Security labelling standard for applying security metadata to information assets;




• Security standards for the application of cryptographic protection on information assets; and

• Networking protocols used to exchange information assets at a national level and

between coalition networks. Additionally, this document provides a linkage between the technology target and the CWIX2015 exercise quality assurance, testing and scenario development documentation. Specifically, the three main support documents that will present the findings from the CWIX2015 exercise are:

1. The CWIX2015 Test Plan [Reference 1] that will define the practices that will be used to test, demonstrate and evaluate this capability; and

2. The CWIX2015 Trial Report [Reference 2] that will present the results of the

exercise both in terms of the results gained from CWIX2015 participation and an assessment of the technology in the context of the overarching exercise scenarios.

3. The CWIX2015 Exercise Summary Report [Reference 6] that provides a high

level overview of the exercise results, observations and lessons learned.

1.2. Document Audience The intended audience for this document is security practitioners that have an interest in DCS information protection and have a specific need to build or evaluate the proposed cross coalition information exchange model. This includes security professionals with a need for:

1. A description of the DCS cross coalition capability and the CWIX2015 technology target that will serve to prove the viability of DCS-based cross coalition information exchange; and

2. An understanding of the design, development, and testing requirements that will

lead to the technology target deployment at the CWIX2015 exercise.

1.3. Data-Centric Security Program History The DCS program has been assigned the mandate to develop and transition DCS concepts towards the eventual target of operational deployment. It derives much of its information protection architecture from research conducted by Defence Research and Development Canada (DRDC) and the Secure Access Management for Secure Operational Network (SAMSON) technology demonstration. The goal of this research was to leverage DCS capabilities to reduce the need for multiple SECRET networks through community of interest (COI) separation. Ultimately, the intent was to rationalize




the DCS architectural specification in order to define the next generation of secure networks through its ability to address the following four basic challenges in information assurance.

1. The specification, application and enforcement of a unified and holistic security policy across all information assets;

2. The restriction of transactions against information assets to only those communities with the policy right to perform those actions;

3. The ability to provide assurance that information is only released to those users that have a policy right to access it; and

4. The use of a trusted audit facility that records the details related to the release of information in a tamper-resistant form.

These four design priorities were enacted through the development of the DCS core solution components, which include the following:

• A centralized Policy Decision Point (PDP) that brokers access to information assets based on the security attributes of the requesting user, the security attributes of the targeted information asset, the operation requested on the asset and any environmental conditions that impact the decision-making process (e.g. time of day, location, user role);

• Application aware Policy Enforcement Points (PEPs) that intercept operations on

information assets and ensure that the requested action is in compliance with the security policy. Vetting the action against the security policy of the PDP derives this assurance;

• Asset-level Cryptographic Transformation Service (CTS) protection where each

asset is uniquely encrypted with its own symmetric key; a key that is only accessible to the PEP and only applied when the requested operation is compliant with the security policy; and

• A Trusted Audit Service (TAS) that creates a record of each requested action on the information asset, the decision that was made to permit or deny the action and a rationale for the decision that was made.

These DCS capabilities were delivered as a security overlay to existing application, network and information architectures. This national DCS information protection model is presented in the context of the cross coalition information exchange model in Section 2.1 - Data-Centric Security within National Networks.




1.3.1. Prior experiments The DCS capability has evolved as a maturing capability as new requirements, new capabilities and new data assets have been brought into the DCS program scope. The DCS capability has been demonstrated in the following network environments:

1. Empire Challenge 2010: An initial DCS capability for file protection and email services providing community-based access control and auditing over information assets;

2. Empire Challenge 2011: An extension of the initial DCS architecture that included

symmetric key protection of information assets and support for persistent instant messaging assets;

3. Coalition Warrior Interoperability Demonstration (CWID2011): Further refinement

of the DCS deployment to include Global Command and Control System (GCCS) data feeds; and

4. Coordinated Attack Guidance Experiment II (CAGE II 2012): Deployment of DCS

as a security overlay on an existing operational network and information architecture.

1.3.2. The CWIX2014 Exercise In June 2014, the DCS program participated in the Coalition Warrior Interoperability Exercise (CWIX2014). The intent of this experiment was to gather evidence to prove the viability of a new mechanism to exchange information between organizational domains. The challenge presented in existing information architectures is that organizations typically select their own preferred security-labelling format. The lack of a common approach to defining inter-organization security labels and associating information assets with those labels significantly hinders the ability to exchange information in a controlled manner. In contrast, when a common labelling mechanism is in place for the exchange of data assets, information can be shared between organizations (and handled and processed) according to mutually agreed to memoranda of understanding (MoU). The goal of this experiment was to create, deploy and test an implementation of a cross organization information exchange solution that would support the use of MoUs between organizations through a common labelling standard for information in transit. The programmatic and technical objectives for the CWIX2014 experiment were:

• To prove the viability of a cross organization information exchange mechanism where:

o Security metadata from assets sent from a source domain are used to

create a transport security label;




o Information assets and their associated transport security labels are placed in a container for transmission between domains;

o At the receiving domain, the security metadata on the transport container is validated against the security metadata on the original asset to ensure that it was not modified in transit;

• To support a set of security labelling formats on the original information assets

including:

o Property-based security attribute files (e.g. Titus Document Classification); o XML Security Policy Information File (SPIF); o NCIA Security Label Attributes (SLAB) format;

• To exchange information using unmodified client and server software while

supporting the capability to encapsulate information assets into a transport container in transit;

• To demonstrate cross coalition information sharing using email as the information

exchange method; and

• To gather supporting information in the form of log files to demonstrate the effectiveness of the proposed solution.

This experiment included participation by the following nations and organizations:

1. United States; 2. United Kingdom; 3. Germany; 4. Finland; and 5. Netherlands.

While the detailed test results are documented in the SD003 CWIX2014 Test Report [Reference 3], the following observations can be made about the results from the experiment.

• All solution elements performed as expected;

• The approach to hardware and software deployment, configuration and operation allowed the experiment to take place without any technical difficulties;

• All testing was successful: no failures were encountered during the test cycle

procedures; and

• The solution was successfully demonstrated to partners and VIP representatives.




1.4. CWIX2015 Based on the success of the CWIX2014 exercise, CWIX2015 will continue to evolve the concept of cross coalition information exchange by introducing some new capabilities and enacting scenarios that include a full end-to-end DCS-based information exchange between partner nations. This cross coalition capability is intended to achieve the following objectives:

1. To prove the viability of the DCS cross coalition trust model and information exchange framework as proposed in this document;










1.5. Assumptions This report makes the following assumptions:

• Security Classification & Clearance – It is assumed that for the CWIX2015 experiment all networks will be at the same classification level and all users will have the proper clearance to access networks at that classification level. Specifically, for CWIX2015 it is assumed that all information exchange occurs at the SECRET level and that all users are cleared to this level; and

• Original Security Metadata – It is assumed that for CWIX2015 all participants will wish to retain the original security metadata on information assets that are transferred between domains. While the syntactic representation of this metadata may change prior to release to other domains, the core security attributes and their relevance to the bound asset will be retained.




1.6. Glossary In order to avoid confusion and improve clarity, a number of key terms will be defined within this section of the report. Specifically, this section will define how the following terms will be used within the context of this report:

• Community Of Interest (COI) – The term COI is used throughout this report. In the context of this report the term is applied to both users and data. In terms of users, the term denotes membership within the COI. In terms of assets, the term is used to restrict access to a specific COI. The term COI is synonymous with caveats and warning terms;

• Domain – Within this report the terms domain (short for security domain) and

national network are used interchangeably. In reality, a security domain may be comprised of a number of networks all governed by the same security policy. However, in the context of CWIX2015, and this report, the term domain and national network are synonymous as each of the national networks will have a unique security policy;

• Security Label – A security label is used primarily to denote the sensitivity of an

information asset, but may contain additional security metadata. Security labels are sometimes referred to as confidentiality labels. The term security label will be used throughout this report;

• Security Labelling Policy - A security labelling policy in the context of this report

refers to the syntax and semantics for the construction of security labels on information assets. For example, a new classification value denotes a change to the national security labelling policy; and

• Trust - Trust has different meanings in different contexts. In the context of this

document trust refers to inherited trust as opposed to provable trust. The trust that is achieved within a domain through the use of DCS is being extended cross-coalition. Specifically, the information protections provided in the originating domain are replaced by equivalent information protections during transit between domains. Consequently, when the recipient domain receives the asset they can be confident that it has not been altered or disclosed. However, in this information exchange the originating domain ultimately trusts the recipient domain to handle the information that was exchanged in a responsible manner commensurate with the assigned security label and in compliance with the MoU in place between the two nations. It should be noted that this inherited trust improves upon existing paper-based mechanisms and will drastically improve information sharing between coalition nations by automating the process.




1.7. Document Outline This document is structured into the following sections:

• Section 2 - DCS Cross Coalition Information Exchange: This section outlines and describes the key technology components needed to establish a trust model that will be built upon national DCS information protections, and that will support information exchange between partner nations in a coalition environment. The key capabilities that are described in this section, and form the basis for the trust model, include:

o Electronic Memorandum of Understanding (eMoU); o Full end-to-end DCS protection; and o Border Policy Enforcement Points (bPEPs);

• Section 3 - CWIX2015 Concept of Operations: This section identifies the subset

of the capabilities described in Section 2 that will be implemented for the CWIX2015 exercise. This section also describes the Concept of Operations in terms of how the experiment will be structured from an architectural standpoint so as to support the testing and evidence gathering activities to be conducted during the exercise;

• Section 4 - CWIX Protocols and Data Standards: This section identifies the data,

network, security and metadata formats that are being leveraged as part of this exercise, where those standards are being applied and where they are being extended to support the exercise objectives;

• Section 5 - System Reference Architecture: This section provides a high-level

architectural specification for the solution including a description of the significant data flows, component model and enumeration of new capabilities that must be developed for the exercise;

• Section 6 - CWIX2015 Scenario Support: This section provides a linkage to the

supporting documentation that will be created during the exercise itself, specifically:

1. The CWIX2015 Test Plan [Reference 1] that will be shared with a partner

nations and details how testing, scenario participation and evidence gathering will take place during the exercise; and

2. The CWIX2015 Trial Report [Reference 2] that will summarize the testing objectives, methodology, results and impact of the actual experiment itself.

C19-0916-02635_Document.docxCONOP and Reference Architecture


2. DCS Cross Coalition Information Exchange

This section provides a high-level description of the Data-Centric Security (DCS) information protection model and the manner by which it can be extended to accommodate trusted cross coalition information exchange.

As shown in Figure 1: DCS-based Cross Coalition Information Exchange, the desired capability is to allow an originating national network to send DCS protected information assets to another national network in a manner that:

• Allows each nation to manage information assets using their own DCS profile (security policies, security metadata);

• Ensures information release to another nation is in accordance with the originating national policy;

• Ensures that the transition of information assets is protected against disclosure or modification; and

• Ensures that the information asset, when received by the target nation, is accompanied by sufficient security metadata to allow that nation to handle the information appropriately.

Figure 1: DCS-based Cross Coalition Information Exchange

This cross coalition concept, therefore, must be defined in a way that meets all requirements for cross coalition information exchange, including:

1. Programmatic requirements that ensure that all information handling agreements between nations are honoured;




2. Security requirements that ensure that the deployed solution meets an agreed upon level of minimum risk; and

3. Functional requirements that ensure the flow of information between national domains is possible when in accordance with national and coalition security policies.

This section addresses the following topics as they relate to the DCS-based cross coalition information exchange concept:

• An overview of the trust that is established, at the national level, for DCS protected information architectures;

• A description of the Cross Coalition Trust Model and how it builds upon, and leverages, both national and coalition information protection;

• The general model for DCS-based cross coalition information exchange; and

• A summary of the trust model.

2.1. Data-Centric Security within National Networks The DCS approach to information protection ties and enforces policy protection mechanisms to the individual asset level. Information can only be created, published, accessed and shared when that action is in compliance with a unified, national security policy. Without the explicit policy right to access an information asset, the information content of that asset is not released to the requesting user. In this way, a nation with a DCS-based information protection infrastructure achieves granular control over the creation, usage, and sharing of assets through the full information asset lifecycle. Specifically, the DCS model, as shown in Figure 2: Data-Centric Security for National Networks, provides a layered defence over information assets whereby:

a) Information cannot be created or accessed unless the request is in compliance with the national security policy. The PDP mediates the request based on the security attributes of the requesting user, the security attributes of the requested asset and the requested action;

b) Information can only be created or accessed if it traverses a PEP. Furthermore,

the information protection safeguards, based on cryptographic transformations, mean that only a PEP can formally protect or access an asset’s content; and



c) All requests for actions on data (whether permitted or denied) are placed in a trusted store for future audit analysis or forensic investigation.

Figure 2: Data-Centric Security for National Networks

With a DCS information protection model in place it is possible to trust that information content that has been created within a national network is treated by that nation as being a trusted information asset.

2.2. The Cross Coalition Trust Model

The trust that is established within a nation is based not only on national security policies and national information protection mechanisms, but also on national security metadata practices. This means, in a DCS model, that each nation may have different national policies, practices and tools for:

1. Expressing security metadata as attributes within a security label (label syntax);

2. Expressing values for those security attributes (label semantics);

3. Formatting a security label for inclusion with the asset; and

4. Binding security labels to assets.




Currently, when an information asset is shared between national networks, the security metadata that is bound to that asset will only have meaning to the originating nation. That is, the target nation will not know where to locate the security metadata, how to verify the security binding on that asset or how to interpret the security metadata attributes and values within the security label itself. There is, therefore, no assurance that the information security provided in the new domain adheres to the originating nation’s trust model and protection mechanisms. What is needed for a cross coalition information exchange is an approach that allows individual nations to retain their local DCS information protection model that builds trust at a national network level. This trust could then be leveraged and combined with the trust that is established between nations in a coalition network environment. This provides the following capabilities:

• National assets are protected with national security practices and are released to other nations only when that action is permitted by policy;

• When assets are shared with another nation the security metadata, asset

protection, security label binding and secure transport are all done in a manner that is agreed to in bilateral nation-to-nation agreements. This agreement is formalized in a MoU and electronically represented in an eMoU; and

• When the new domain receives an asset, it is afforded a degree of information

protection commensurate with its security label. Such an approach would have significant practical benefits for the participating nations, as described below:

• It does not dictate changes to the way individual nations:

o Build trust within their own networks; o Utilize information protection tools and techniques; o Manage the security metadata on their information assets;

In other words, individual nations are able to continue to leverage the existing investment they have made in an information protection model that meets their current national need;

• It allows nations to exercise granular control, not only of what information assets

are shared with other nations, but also of the mechanism by which their security metadata is transformed prior to release to the target nation; and

• It limits the scope to which trust is required, specifically, between nations at a

national level rather than to individual users, roles, or communities.




This last point has its basis in a fundamental truth in cross coalition information exchange; once a nation decides to share information with another coalition member the originating nation must trust that the other nation will be a responsible custodian of those shared information assets.

A Note on Federated Trust Models In the absence of a DCS model, trust is established and tied to the individual. In a cross coalition information exchange, therefore, trust must be established between the participating individuals through a fully federated model. This requires the establishment of a complex hierarchical structure of trust between nations and their representatives. It necessitates the use of security metadata structures that have been mutually agreed upon and adopted by all participating nations. This imposes significant constraints on a nation’s selection of tools and practices for the labelling formats, syntax and semantics of security metadata structures attached to information assets. It also requires nations to expose security interfaces that allow security attributes of individuals, groups and communities to be made available between nations. These requirements and limitations are present in a fully federated model where security practices cannot be applied and enforced at the data asset level.

2.3. General Model for Cross Coalition Information Exchange The cross coalition trust model that is espoused by the DCS information protection architecture is shown in Figure 3: Cross Coalition Information Exchange. In this general information exchange, a user in the originating national network generates an information asset that is subject to that nation’s security policy, specifically:

• A policy decision is made to ensure that the user has the right to generate an information asset with the asset’s security attributes (e.g. releasability, COI);

• If the action is permitted, the asset is protected with a unique symmetric key to

ensure that it cannot be released without the involvement of the DCS protection model; and

• An audit record of the event is made and submitted to the trusted audit facility.

As a result, a user is not able to create information assets without the policy right to do so; therefore, any assets generated within the originating network can be trusted to be in compliance with that nation’s security policy.



If that asset is to be shared with another nation, the asset would transition from the national network to the coalition network at a border checkpoint. At this border checkpoint, the DCS cross coalition information protection policy would be invoked, ensuring that:

• This asset can be released (at a national level) to the target nation;

• Any local protection mechanisms are removed from the asset; since the asset level encryption is only relevant for the local DCS implementation (algorithms/keys);

• The asset’s National Security Label (NSL) is transformed into a Transport

Security Label (TSL). This new security label would be expressed in an intermediary format that is in accordance with the negotiated syntax and semantics for the target nation;

• For structured data, the TSL is embedded in the asset and a cryptographic binding is included to prevent tampering; and

• The asset, with its TSL, is delivered to the target nation.

Figure 3: Cross Coalition Information Exchange




The target nation would receive the information asset and perform a similar process. Specifically, the actions at the target nations border checkpoint would be to:

• Ensure that the security label has not been altered and is bound to the asset;

• Extract the security metadata from the security label and generate a new label on the asset using its own NSL format;

• Apply location protection mechanisms on the asset (local encryption); and

• Deliver the asset to the local network data service.

The target nation is now able to apply its own local DCS protection processes on the asset. The asset would be delivered to the target user in the target national network if and only if that user has the policy right to access the information. This generalized scenario forms the basis for how DCS-based information sharing could be applied to any cross coalition information exchange. This general concept, including the needed solution components that would be required to achieve this capability, is described in the following sections.

2.4. DCS Cross Coalition Solution Requirements This section provides a detailed description of the extensions to the DCS information protection model that form the basis for supporting cross coalition information exchange. These new DCS solution elements are presented in this section in order to provide evidence for the validity of a DCS-based cross coalition capability. However, these elements are presented in a broader context than will be deployed for the immediate CWIX2015 technology target. That is, the functionality that will be built, deployed and tested at the CWIX2015 exercise will represent a subset of the overarching component architecture that is presented in this section. The technology target for CWIX2015 is described in Section 3.3 - Capabilities Under Evaluation. In order to support the cross coalition trust model, the following new elements must be added to the DCS information protection architecture.

1. A mechanism to translate security metadata, including security label syntax and semantics, from its original representation in the originating national network first to an intermediary security label and then to its equivalent for the target national network. This capability is achieved through two enhancement to the DCS service model:




o Extensions to the existing Security Labelling Service to support the ability to both read and write national security labels and transport security labels; and

o A security service or software module that provides mapping and equivalency of security metadata between national networks as described in Section 2.4.1 - Electronic Memorandum of Understanding

2. A mechanism to exchange data securely between nations. It is this mechanism

that provides asset level protection during transport and security label binding. This mechanism is responsible for exchanging information assets between national networks and is described in Section 2.4.2 - Cross Coalition Asset Transfer; and

3. A policy enforcement mechanism, the Border Policy Enforcement Point (bPEP),

that operates at the border and enforces information protection by leveraging new and existing security services. This boundary service is responsible for coordinating the operations against information assets during an exchange of information so that the transaction is in accord with policy, ensures that security metadata is correctly applied to the information content and transitions the asset between the national and transport security protection models. A detailed description of the capabilities provided by these boundary services is provided in Section 2.4.3 - Border PEPs.

It is worth noting that the new DCS solution elements, in support of cross coalition information exchange, work in a unified way. That is, the solution elements form a trust model based upon the services they provide and how they leverage the pre-existing information protection capabilities that are already in place within DCS-enabled national networks. In a subsequent section, Section 2.5 - Detailed Model for Cross Coalition Information Exchange, the cross coalition information exchange scenario that was shown previously in Figure 3: Cross Coalition Information Exchange is re-visited and presented in the context of these new DCS information exchange support services.

2.4.1. Electronic Memorandum of Understanding This section introduces the concept of an Electronic Memorandum of Understanding (eMoU); a mechanism that enables nations to achieve a common understanding of the equivalencies of security metadata between their respective national networks. The proper mapping of the security metadata syntax and semantics on information assets as they are exchanged between national networks:

• Facilitates the information sharing process by ensuring that each nation has the requisite information to appropriately apply proper information protection practices to the data assets it receives; and




• Allows national network DCS information protection mechanisms to be enforced when an asset is received at another nation’s network.

This forms a key element of the cross coalition information exchange trust model. In order to fully appreciate the role of the eMoU in the trust model, several related concepts must be explained in the context of information protection. While some concepts are new to the capability that is being defined for the eMoU, others have their origin in the DCS national trust model. These concepts are:

1) Security Labels; 2) Security Label Portability; 3) Hierarchical Security Labels; 4) Electronic Memorandum of Understanding (eMoU); and 5) Security Label Equivalency Service (SLES).

Security Labels Nations employ security labels in order to denote the sensitivity of information assets. A security label is defined by its:

1. Syntax: the format the security metadata takes in the label in the form of named label attributes1; and

2. Semantics: the set of allowed values that can be used in each attribute.

The security metadata, in the form of a security label, is bound to one or more information assets. The purpose of the binding is twofold. First and foremost, it ensures that the security label travels with the information asset. Second, the binding is often accomplished using cryptographic mechanisms, thus ensuring that the security label cannot be modified without detection.

Security Label Portability Each nation is free to use its own security label syntax, semantics and software tools that will be used to create and consume security labels. Since the location, format and interpretation of security labels can be different for each nation, and for different assets (e.g., email, files, IM, etc.), a label created by one nation cannot necessarily be interpreted by another nation. This situation, referred to as a lack of security label portability, greatly complicates information sharing in coalition environments.

1 For example, named label attributes might take the form of elements or attributes in an XML-based label structure. This is how Titus classification labels are represented in security labelled Microsoft Office documents.




There are two potential solutions to the challenge of security label portability. The first approach, and the one espoused in this document, relies on translating the content of a security label to a common format while the asset is in transit between networks. The originating nation will convert the NSL to the common format and use security label syntax and semantics that are understood by the target nation. Similarly, on receipt of the asset, the target nation will convert the common label expression into a security label format that is used by its national DCS information protection standard. The second approach proposes that a common labelling scheme be adopted by all coalition member nations. This eliminates the need for any translation since all nations have agreed on a format, syntax and semantics for the security metadata expression. A common labelling scheme, while attractive in theory, would likely prove problematic in practice due to the difficulty in achieving multinational agreement over a common labelling format. The security label translation approach is therefore the preferred approach for coalition environments, as it allows nations to retain local control over their security labelling format, syntax and semantics.

Hierarchical Security Labels Hierarchical security labels are an enhanced capability for security label translation that allows national sub-groups to define and add security metadata. This security metadata is relevant to the subgroup’s operational practices and requirements for their role within the national network. Specifically, hierarchical security labels have the following characteristics:

• Security label attributes that are defined (or “owned”) at a higher level in the national domain structure are inherited at the lower levels of the hierarchy as the label is generated;

• Security label attributes can be added to the label schema at lower levels of the hierarchy without violating the validity of the generated label as it is interpreted at a higher hierarchical level; and

• Each level of the hierarchy can define attributes, which then become immutable2 at the lower levels.

At a given level within the national domain hierarchy, a security label for an information asset must be built dynamically by collecting all of the needed attributes from the higher levels and combining it with the attributes that are specified at the level where the security label is being generated. This means that changes to the labelling syntax can be made at the higher levels in the national domain without the need to consult the lower levels. 2 Immutable in this context means that the meaning of the attribute cannot be redefined and the list of acceptable values for that attribute cannot be altered.




A hierarchically structured labelling domain is shown in Figure 4: National Domain Labelling Hierarchy. In this structure, labelling attributes can be specified at the national level (e.g. classification, releasability, COI information). Additional attributes that are relevant to sub-groups within the national structure can be added at the government agency level, the departmental level or the section level.

Figure 4: National Domain Labelling Hierarchy

When creating new information assets at the lower levels of the hierarchy, the labelling software (the software that generates and binds security labels to the asset) must be made aware when the national labelling policy has changed. The policyID attribute, a required element in security label standards, can be used to convey the hierarchical nature of the label’s construction. Figure 4: National Domain Labelling Hierarchy shows a national domain hierarchy with the policyID reflecting the fact that an information asset was provided with a security label that was generated by a specific section. Such a label would, therefore, contain security metadata attributes that are relevant to that section, as well as all the security metadata inherited from the departmental, governmental and national levels. It is significant to note that in this model the tools, practices and policies associated with security labels remains under the control of the nation, including:




1. The mechanisms by which security labels for information assets are generated;

2. The mechanism by which security labels are dynamically built (e.g. top down from the most authoritative source to the lower level attributes); and

3. The mechanisms by which updates to the labelling structure are propagated

through the hierarchical structure. Having these security labelling practices defined at a national level eliminates the need for a standardized data labelling policy approach across coalition members. The manner by which security labels are managed within national boundaries remains a national concern and does not require consultation with partner nations. When a security labelled asset crosses the national boundary as part of a cross coalition information exchange, the national security label must be translated to an equivalent expression that:

• Is understood by both partner nations; • Retains the original security metadata profile; and • Uses security metadata expressions that can be interpreted by the receiving

nation. The process of generating the equivalent security metadata profile of an asset, while translating the metadata into an appropriate expression for the target nation, is the role and purpose of the SLES, in conjunction with the eMoU.

eMoU as an Expression of Policy The eMoU is a representation of an information exchange agreement that exists between nations. More accurately, it is an electronic coding of a formal agreement that specifies the manner in which security labels from one nation should be interpreted by another nation. In this role, the eMoU will serve as a means for applying both data labelling policy and data labelling translation actions on information assets shared between nations. These two functions are described below.

• eMoU for Applying a Data Labelling Policy: For each level in the labelling hierarchy, as specified by the policyID, the eMoU will identify which security attributes from the national security label can be shared with each partner nation. Similar to the generation of the security label, the list of shareable attributes is built dynamically. The hierarchy level that defined (or “owns”) the attribute determines if that attribute can be shared with a partner nation. Attributes can be identified as required or optional. If, when the list of shareable attributes is determined, there is no entry for the target nation then there is no eMoU agreement in place and the attribute should not be shared; and




• eMoU for Security Label Equivalency: For each discretionary security attribute that is to be shared with a target partner nation, the eMoU will specify the appropriate translated attribute name for that nation and the correct equivalent value. As an example, consider an asset with a discretionary security attribute of “NAVCOM” with the value of “ATLANTIC”. In the course of sharing that asset with another nation, the eMoU might specify that the discretionary security attribute should equate to “ADMIRALTY” and the value of the attribute should map to a value of “ATL”. In this scenario, the eMoU has provided the mapping for both the attribute name and the attribute value so that the information asset, on receipt, has a security metadata context that allows it to be properly handled and protected by the receiving nation.

The translated values provided by the eMoU will determine what security metadata will be placed in the TSL as described in Section 2.4.2 - Cross Coalition . The TSL is the intermediary security label format applied to information assets as they transition between national networks. As with the trust model itself, it is worth noting that this approach to security label equivalency could be applicable to intra-nation data exchanges. This would allow individual departments to exercise control over how asset metadata is shared with, and interpreted by, other departments.

Security Label Equivalency Service (SLES) Of specific interest within this document and for the CWIX2015 exercise is the development of a SLES that provides the ability to:

1. Translate security meta-data on assets from a national format to a common format for exchange based on,

2. Syntax and semantics equivalencies that are formally agreed upon by nations and coalitions.

The eMoU codifies these equivalencies while the SLES applies the translation to assets as they traverse national boundaries. The design, development and testing of the SLES and eMoU solution elements will be a primary target during the scenario development, testing and evidence gathering activities for the CWIX2015 exercise. The SLES will determine equivalencies for, and translations of, security labels on information assets as they are exchanged between coalition members. As a security service, the SLES is integrated with the DCS SOA and can be called upon by the bPEP during an information exchange between national networks. As one would expect, the SLES relies on the eMoU in place to dictate the manner in which security label translation is performed. Section 3.3.3 - Security Label Equivalency Service provides the capability target for the SLES service for the CWIX2015 exercise.




2.4.2. Cross Coalition Asset Transfer When there is a request to share an information asset with a partner nation:

1. There are verifications to ensure that the exchange adheres to the national security policy; and

2. There are actions taken based on the asset’s security label to ensure that the asset is assigned security metadata that the partner nation can interpret.

Specifically, these operations occur at the national boundary and are meant to answer the following two questions with respect to the information sharing transaction:

1. Can the asset be released to the target nation? This is a function of the bPEP to ensure that there is alignment between the releasability metadata on the asset and the target network to which the asset is being sent. This action, on the part of the bPEP, is described in detail in Section 2.4.3 - Border PEPs; and

2. What security metadata, in the form of a security label, needs to accompany the

information asset? This is the labelling translation and equating function performed by the SLES, as described in Section 2.4.1 - Electronic Memorandum of Understanding.

Assuming that the policy and security metadata verifications are successful, the originating nation will have an information asset that can be shared with the partner nation and a set of security attributes for that asset that can be interpreted by the partner nation. The next step in the information exchange process, therefore, is to prepare the asset for delivery to the partner nations. There are three key steps in preparing the asset for transfer. These steps consist of the following:

1) Generating the TSL for the each labelled element within the asset3; 2) Creating a digital signature to bind the TSL to the asset; and 3) Encrypting the asset for transport

This process is followed for both static information types, where the asset is sent and received as a single object (e.g. a file), and for structured data types, where information is sent as discrete records within a session-based connection (e.g. an IM chat session or a stream of GCCS records).

3 For example an email message is a single information object but it may container multiple labeled assets in the form of a labelled message body and labeled file attachments. In this case, each labeled asset in the object would have a separate NSL from which a TSL would be derived.




Transport Protections The previous section defined a requirement for cryptographic protections to bind each TSL to the asset that it represents and prevent the disclosure or modification of the asset during transit. A mechanism is required, therefore, which enables coalition partners to exchange sensitive information while protecting the confidentiality and integrity of the asset and its security metadata. The DCS cross coalition information exchange model does not dictate a specific implementation for providing the protection on an asset. Any information protection mechanisms that are present in the coalition environment and are acceptable to both parties for use in cross coalition information exchanges can be used, including the following:

1. Public Key Infrastructure (PKI)-based certificates; 2. Public keys using manually exchanged certificates; 3. One time pad solutions; or 4. Manually exchanged shared secret.

The actual selection of the information protection mechanism to secure the asset will be based on a risk management decision agreed to by both parties in the information exchange framework. It is significant to note that this approach to securing cross coalition information exchange is in alignment with the trust model in that it does not rely upon a federated or overarching cryptographic infrastructure. Additionally, this approach means the trust model can evolve over time to address new security requirements and integrate new data protection capabilities.

Transport Security Label & Binding

To enable information sharing between coalition participants, the originator4 of the information asset must ensure that the receiving nation can apply sufficient controls to protect the integrity and confidentiality of the information. A key enabler for maintaining this trust relationship is a common understanding of the security labels on information assets.5

The TSL holds the security metadata that must travel with the asset. Any labelling standard can be used for the TSL so long as it is agreed to by the nations that are participating in the information exchange. For the CWIX2014 experiment, this common understanding of security label information was achieved by converting national network specific security labels into a common security label format while the asset was in 4 In this case, the term originator refers to the originating domain and not a specific individual. 5 CWIX2014 Trial Report [Reference 4]




transit between nations. A similar approach will be used to support the trust model for DCS cross coalition information exchange. The cryptographic binding links the TSL to the asset in such a way as to permit the detection of unauthorized tampering. For example, the use of digital signatures to bind the security label to the information asset might be an acceptable approach for ensuring the integrity of the security metadata on the asset. Several proposed NATO standards are advancing the maturity of the management of security metadata, including:

• NATO STANAG 4774 that describes the syntactic representation for confidentiality labels; and

• NATO STANAG 4778 that described mechanisms for binding confidentiality labels to assets using a set of profiles for specific data and protocol types.

The DCS cross coalition trust model presented in this document fully supports the adoption of these standards.

2.4.3. Border PEPs The border PEP (bPEP), which is a specialized variant of a the national PEP (nPEP), supports the cross coalition information exchange model by acting as the coordinating process around which policy, security label management and information protection take place. While the bPEP performs a similar function to the nPEP, a distinction is made between these two PEP variants:

1. The nPEP provides information protection services to activities that take place within a national network (between users and national data services); and

2. The bPEP provides information protection services to activities that occur at the

national boundary (between national networks). An nPEP, in conjunction with the PDP, serves to mediate access to national information assets by national users. This PEP is also responsible for ensuring that information assets are appropriately protected within the national domain. By contrast, the bPEP is responsible for ensuring that information is released to other nations only when the action is in accordance with the national security policy. It is also responsible for ensuring that released information (data and security metadata) is presented to the partner nations in a format that allows the partner nations to enforce their own information protection policies.




In order to accomplish this, the bPEP must have the following capabilities:

• An understanding of the data service network protocols that are used for information exchange between national networks;

• The ability to identify the information assets that require DCS protection prior to release; and

• The ability to leverage the DCS SOA services so that information assets can be transformed, protected and audited prior to release.

In this role, the bPEP leverages the following standard DCS services within the national domain:

• The security labelling service that creates, interprets and validates:

o national security labels on information assets in accordance with the nation’s security labelling policy; and

o transport security labels in accordance with the coalition labelling standard;

• The policy engine to determine if operations against information assets are in

compliance with the national security policy;

• The cryptographic and key management services that protect information assets using the nation’s mechanism for encryption; and

• The trusted auditing service that generates and stores an audit record of each

information request. In addition to these four standard DCS services, the bPEP leverages one additional software module service to the DCS protection model in order to enable cross coalition information exchange. This service is responsible for equating security labels in accordance with the eMoUs established between nations, as defined in Section 2.4.1 - Electronic Memorandum of Understanding. This Security Label Equivalency Service (SLES):

• Identifies what security attributes must accompany an information asset when it is shared with a partner nation; and

• Provides any security metadata mapping and equivalencies when:

o A national security label must be expressed as a transport security label; and

o A transport security label must be expressed as a national security label.



The following two sections illustrate how the bPEP leverages these DCS-based services as it brokers the exchange of an asset with a partner nation.

Border PEP Outbound Processing In this example, an email message is being relayed from a mail server in the originating domain to a mail server in the target domain. The email message, in this case, is a DCS protected asset with national security labels on the message body and any attachments. Since the asset is originating from the mail server in this example it is assumed that the email has already been validated at a national level (i.e., that the email sender had the policy right to generate the message) and is protected using national cryptographic protections. On message creation, the sender will have defined security metadata which are reflected in the message’s national security label, including:

1. Classification of the message; 2. Releasability of the message; and 3. COIs (discretionary elements) for the message.

Similar metadata is reflected in the national security label on any files attached to the message. As the message transitions between mail servers, it is relayed through the originating nation’s network boundary where the bPEP intercepts the message.

Figure 5: Outbound Border PEP Operations




1) The border PEP requests the validated security metadata from the NSL on the

asset (and its attachments). In its role and location within the information exchange, the bPEP is aware of the domain to which the asset is being sent. For an email message, this information can be extracted from the message headers and will indicate the target domain to which the message will be directed (e.g. [email protected]). The contents of the releasability field (a list of nations to which the asset can be released) are validated against the partner nation to which the asset is being sent. The asset is only released if the nation to which the asset is being sent is included in the releasability field;

2) Assuming the release of the asset is permitted, the national cryptographic

protections are removed from the asset;

3) The SLES is consulted using the policyID from the asset in order to acquire the list of discretionary security attributes, in addition to the four core attributes, that must be extracted from the asset’s security label and the security attribute/value equivalencies for the target partner’s network are retrieved;

4) The bPEP prepares the asset for delivery to the target domain. In order to

accomplish this, it performs the following functions:

a. It creates a new security label for the asset based on the TSL format and embeds it in the asset;

b. It digitally signs the asset (and the embedded TSL), effectively binding the TSL to the asset;

c. It encrypts the asset using the cryptographic protection mechanism agreed to by the originating and target partner nations; and

5) An audit record is generated and submitted to the trusted audit store to create a

record of the information exchange and the operations that took place on the information asset as it was released.



Border PEP Inbound Processing As the message transitions between mail servers, it is relayed through the recipient nation’s network boundary where the border PEP intercepts the message as it ingresses the national network.

Figure 6: Incoming Border PEP Operations

1. The bPEP prepares the asset for delivery to the national network. In order to accomplish this, it performs the following functions:

a. It removes the cryptographic protections on the information asset using the cryptographic protection mechanism agreed to by the originating and target partner nations;

b. It validates the digital signature on the information asset; c. It reads the security label in its common interchange format from the TSL;

2. The SLES is consulted using the policyID from the asset in order to retrieve and

apply any security attribute/value equivalencies needed for the national DCS information protection model;

3. It calls the national SLS to create a new security label for the asset based on the

NSL format;



4. It calls the local cryptographic protection service to encrypt the asset using the national encryption standard; and

5. An audit record is generated and submitted to the trusted audit store to create a record of the information exchange and the operations that took place on the information asset as it was received.

The information asset can then be delivered to the local mail server for delivery to the designated user. Note that the PEP will enforce DCS-based information protection on the delivery of the asset to the intended recipient. This means that only users with the policy right to access the information will be permitted to receive it. Because the information asset now reflects the national encryption and security labelling formats, it will be subject to the national security protection mechanisms.

2.5. Detailed Model for Cross Coalition Information Exchange

Figure 7: A Cross Coalition Information Exchange Transaction revisits the simplified cross coalition exchange diagram shown in Figure 3: Cross Coalition Information Exchange and expands upon the concepts to include the new capabilities presented in this section. This scenario, which is shown in the figure below, will examine the steps that comprise a typical cross coalition exchange, focusing on releasability, policy enforcement and security label translation. This scenario uses the exchange of an email message as the information asset to be shared, but the principles and processing steps would apply equally to any asset type.

Figure 7: A Cross Coalition Information Exchange Transaction




2.5.1. Information Exchange at the Network Level In this example, an email is sent from an originating national network (Domain A) to a user in the target national network (Domain B). The processing that takes place at each stage in this end-to-end scenario is described below.

1. A Domain A user composes an email and assigns the message a COI. The email is labelled “Releasable Domain B” and sent to a colleague in Domain B. The email message includes a Domain A security label (NSL) which conforms to the nation’s data labelling policy (format, required attributes and semantics);

2. The Domain A Email PEP intercepts the email message as it traverses the network between the user’s workstation and the local mail server. The Email PEP, in conjunction with DCS information protection services, enforces the national access control security policy. Specifically, the Email PEP, in conjunction with the PDP, performs the following policy checks:

a. Is the user permitted to create an email with this COI? b. Is the user permitted to assign this releasability to the email? c. Is an information asset with this COI able to have this releasability?

The email will be blocked by the PEP if any of these policy checks fail.6 If the policy checks are successful, the PEP will allow the asset to traverse the local network to the mail server and will protect the asset with local symmetric encryption so that it is in a secure state while at rest and in transit over the national network;

3. Since the email is destined for a different national network, the email message is forwarded to a mail service outside of the local network. At the outgoing national boundary, the Domain A bPEP intercepts the email message as it traverses the network between the Domain A mail server and Domain B.

At this stage in the information exchange process, a final policy check is made to ensure that the asset can be released to the target network. At the outgoing bPEP, the coalition network configuration can provide a definitive statement of which nation is the intended recipient of the asset based on the destination network name. The bPEP can ensure that this nation is listed in the releasability field within the information asset’s security label releasability field. If the target nation is on the releasability list, then the asset can be sent to its intended destination.

6 It should be noted that this description is specific to this example; additional checks will be applied at the national PEP for any local recipients. That is, the PEP will ensure that any local recipients have the policy right to access the information assets. If any policy checks fail then the email will be blocked and a message returned to the sender.




The bPEP, in conjunction with DCS information protection services, removes any national level protection mechanisms and prepares the email message for transfer to Domain B. Specifically, the bPEP prepares the asset for transfer;

4. The message is transferred from Domain A to Domain B. It is assumed that all

cross-coalition traffic leverages inter-nation protection mechanisms7, thus ensuring the confidentiality, integrity and authenticity of the data. Furthermore, the email message includes a TSL that is cryptographically linked to the asset;

5. The Domain B bPEP receives the email message as it traverses the network between Domain A and Domain B. The bPEP, in conjunction with DCS information protection services, prepares the email message to enter the Domain B national network. Specifically, the bPEP decrypts the asset, validates the security label, generates a security label using the local national labelling format and protects the asset with local symmetric encryption so that it is in a secure state while at rest. These operations on the asset are described in section 2.5.2:Information Exchange at the Data Asset Level below;

6. The message, now with a Domain B national security label, is transferred to the

Domain B local mail server;

7. The Domain B Email PEP intercepts the email message as it traverses the network between the domain mail server and the user’s workstation. The Email PEP, in conjunction with DCS information protection services, enforces the national access control security policy. Specifically, the PEP, in conjunction with the PDP, performs the following policy checks:

a. Is the user permitted to receive an email with this COI?

8. The Domain B user receives the email message.

2.5.2. Information Exchange at the Data Asset Level Figure 8: Cross Coalition Security Label Translation illustrates security label translation within the cross-coalition information exchange scenario described in the previous section. It should be noted that security label translation only occurs on the primary security label. The original national security label, which is not translated, is may be maintained if:

• The originating nation does not scrub the national security label from the asset; and

• The TCL does not use the same location with the asset as the NSL; otherwise the NSL will be overwritten.

7 This process works with any mutually agreed upon protection mechanism and is independent of the DCS solution.



Figure 8: Cross Coalition Security Label Translation

1) The Domain A Security Label is used, and understood, within Domain A. The elements that comprise the security label are meaningful within that domain;

2) The Domain A Security Label is translated to a TSL according to the current Domain A / Domain B eMoU. The core security label elements within the Domain A security label are automatically translated to their equivalents within the TSL.

In addition, the current eMoU specifies that two other elements are required; CreationDateTime and VersionIndicator. Since an element within the TSL has not been defined for these elements, they are translated directly to the corresponding elements within the Domain B Security Label, as specified in the eMoU. The last element in the Domain A Security Label is not specified for translation in the eMoU. Consequently, it is determined to be extraneous and is not included in the TSL. The values for this translation process can be seen in Table 1 – Cross Coalition Security Label Translation.

Table 1 – Cross Coalition Security Label Translation

Domain A Security Label

(NSL)

Transport Security Label

(TSL)

Domain B Security Label

(NSL)Core Security Label Elements

PolicyID PolicyIdentifier Policy Classification Classification Classification

Caveat Category - Additional Sensitivity

Codeword

ReleasableTo Category - Releasable To

Releasability

eMoU Security Label Elements

CreationDateTime CreationDateTime CreationDateTime VersionIndicator Version Version

Extraneous Security Label Elements

OriginatorID




3) Unless nations adopt the TSL as their NSL labe format representation, the TSL is only used in an interim capacity during the cross coalition information exchange. It is worth mentioning that the main security label elements are understandable by all coalition members. However, the additional elements specified in the eMoU are only understandable by the respective domains exchanging the information;

4) The TSL is translated to the Domain B Security Label (NSL) according to the

Domain A / Domain B eMoU in place. The core security label elements within the TSL are automatically translated to their equivalents within the Domain B Security Label. Furthermore, the additional Domain B elements specified in the eMoU have already been included in the TSL so there is no need to translate them for use within the Domain B Security Label. This translation process can be seen in Table 1 – Cross Coalition Security Label Translation; and

5) The Domain B Security Label (NSL) is understood within the Domain B national

network and all local DCS information protection services can use the security metadata that is reflected in that security label.

The advantages of the eMoU model in defining the security label mapping are apparent from this scenario. Specifically, they are as follows:

• The core security label elements of coalition security labels are automatically mapped to equivalent elements within the TSL. This ensures that coalition members can exchange security labelled information with one another with only a basic (or default) eMoU in place. This may prove useful if a coalition of thirty member nations needs to be established quickly in order to respond to a crisis;

• Rather than having to understand the security labelling formats of every coalition

member, each nation needs only to understand its own NSL format and the SLAB format used by the TSL; and

• Coalition members that require more granularity in the security labels they

exchange can do so by leveraging the security label translation capability within the eMoU. The eMoU allows nations to specify required elements down to the section level in order to improve information utility and asset protection.

The approach to security label translation described in this section provides for a simple set of defaults that enable coalition partners to quickly establish a mechanism for secure information exchange. At the same time, it supports more granular control over security labelling. This increased level of granularity may be a requirement for certain partners, such as the 5-eyes community. This trade-off between complexity and granularity is often encountered in information security, including the dual requirement for simple, yet highly granular security policies. However, the proposed approach for security label equivalency strives to achieve a balance between granularity and ease of deployment.




2.6. DCS Cross Coalition Information Exchange Summary By providing the capability to equate security labels between nations and leveraging pre-existing trust that exists between nations, it is possible to extend the national DCS information protection model to cross coalition information exchanges. Trust that is established between nations allows national DCS capabilities to be extended across coalitions, ensuring that all information assets created are protected in compliance with the national security policy. Fundamentally, a user cannot create or share information where that action is not sanctioned by the nation. DCS ensures that it is actions on assets, not actions by individuals that are in compliance with national policy. In no case can an individual create or share information where that action is not permitted at the national level. In this way national trust is pushed down to the individual level. It is worth noting that this architecture supports a peering model; the parameters around the information exchange between nations can be established between individual nations. The agreements negotiated between individual nation pairs do not need to be sanctioned by the entire coalition. This supports a model where any combination of national information protection approaches can share information:

• Between nations that use the same DCS model; • Between nations that have different DCS implementations; and • In scenarios where a DCS-enabled nation exchanges information with a non-

DCS architecture. It is also worth noting that this approach to cross coalition information exchange is not tied to a specific scale. This approach would work equally well for intra-nation data exchanges where individual departments want to exercise control over how assets are shared with other departments.




3. CWIX2015 Concept of Operations Section 2:DCS Cross Coalition Information Exchange, provided a high level overview of the DCS capabilities that are required for a cross coalition information exchange framework and trust model. This section draws from the technical and programmatic aspects of this DCS cross coalition concept and defines the technology target for participation at the CWIX2015 exercise. The capabilities that will be demonstrated during the exercise have been chosen to achieve the following objectives:

1. To prove the viability of the proposed DCS cross coalition trust model and information exchange framework;




o Ease of implementation and deployment; o Reliability of the security protection mechanisms; o Operational performance;





6. To mitigate risks associated with transitioning this capability to an operational state.

This section will describe how the CWIX2015 experiment will be structured from an information technology, networking and data flow perspective. This section will identify, within the defined test infrastructure, where the new DCS cross coalition capabilities will be deployed and how those capabilities will be exercised in operational cross coalition information exchanges. Additionally, this section will define the nature of the testing that will be performed against the deployed test infrastructure and will identify those solution elements that will be the focus of the testing methodology. These topics will be discussed in more detail in Section 6 - CWIX2015 Scenario Support.




3.1. Target Environments and Deployment Models The CWIX2015 technology target will include 2 types of deployment models. The first deployment model will be used for partner nations where the data services and IT infrastructure are provided by that nation. The infrastructure, in this model, will be instantiated as a Mission Network Environment (MNE) for that domain. The DCS team will provide DCS security components as a security overlay. The security overlay will sit on top of the established baseline infrastructure configuration. This deployment model is referred to as the MNE overlay. The second deployment model will be used for those environments where there is no MNE baseline infrastructure configuration available. In this model, the DCS team is responsible for deploying the entire infrastructure including underlying hardware, hosting software, virtualized guest operating systems to support the full information architecture and DCS infrastructure. The intent of this model is to create an information architecture that aligns closely with the established MNE baseline. The information architecture deployed in this model should appear identical to other MNE environments in terms of exposed interfaces and general connectivity. Within this information architecture, the DCS security components will be added to the environment as a security overlay. This model is referred to as the MNE equivalent. The MNE Equivalent will also support the CWIX2015 DCS model for Federated Mission Experiment (MNX) capability, as described in Section 3.2.3 - MNX Configuration. Each deployed DCS domain will be connected by the Federated Mission Network (FMN) based on the networking infrastructure and routing policies provided by the CWIX NATO hosting environment. The mechanism by which inter-domain network connectivity is achieved is not in scope for this document and is assumed to be the responsibility of the inter-coalition hosting services. As of March 2015, 7 candidate MNE Overlay infrastructures have been identified:

1. The Canadian domain hosted within Canada (TSIL facility); 2. The US Army domain hosted out of the US; 3. The US Marine Corps domain hosted out of the US; 4. The UK domain hosted out of the UK; 5. The Czech Republic domain hosted out of Poland; 6. The Finnish domain hosted out of Poland; and 7. The Austrian domain hosted out of Poland.

Additionally, there is 1 MNE Equivalent infrastructure:

8. The NATO domain hosted out of the NATO CWIX site in Poland, but with participants from the following countries:



a. France; b. Hungary; c. Netherlands; and d. Sweden.

Figure 9: Proposed MNE environments for the CWIX2015 Exercise

This list of potential deployment targets is representative of the initial interest expressed by CWIX2015 nations for participation in the DCS experiment. The list of actual DCS participants, and the observed results from their DCS testing, is presented in the CWIX2015 Exercise Summary Report [Reference 6].

3.2. General Deployment Requirements It is assumed that each deployed environment, whether MNE overlay or MNE equivalent, will adhere to the following technology requirements. These requirements will either be met by the MNE baseline configuration or will be provided as an extended configuration in support of the CWIX2015 experiment.

1. The local domain must host a Windows domain:

a. Local Windows workstations must be joined to that domain; b. Local users must authenticate to that domain;

2. The Windows domain must be hosted on a Windows 2008 R2 server;




3. The local domain must host a Microsoft Exchange server 2010;

4. The workstations must be based on the Windows 7 operating system;

5. The workstations must host the Microsoft Office 2007 (SP3) suite;

6. The workstations must have a software suite for document and message

classification installed;

7. The workstations must have an IM client installed (Spark preferred);

8. All Windows infrastructure components must use the 64-bit architecture; and

9. All domains must host an IM server based on OpenFire 3.7.1. Additionally, all domains must have the following infrastructure and capabilities.

1. The ability to import and run Virtual Machines based on the ESX5.1 virtualization platform;

2. Sufficient processing capacity to host up to 10 virtual machines, each with 512MB of RAM, 1 virtual CPU, and 8GB of storage;

3. The ability to enable SMTP/POP3 access for Outlook clients to the local

Exchange Server;

4. The ability to load a new trusted root certificate in Active Directory;

5. The ability to allow shell (SSH) access to the VM that provides the DCS capabilities; and

6. The ability to deploy network protection services that reside in the path between

the user workstation and the data services, and network protection services that reside between the data service and the national network boundary.




3.2.1. MNE Overlay Configuration For the MNE overlay, the targeted deployment configuration will be derived from the following general architecture.

Figure 10: MNE Overlay Deployment

In this model, the MNE baseline workstations and information services are present in the MNE enclave. The DCS elements are deployed into this enclave and placed within the network service data flow in such a way as to be able to provide asset level protection on information as it traverses the MNE. This list of DCS elements includes:

1. The DCS Security Services: a. The access control policy engine; b. The cryptographic key management; c. The user security attribute service; and d. The trusted audit service.

The PEPs leverage these security services over the segregated SOA security service messaging bus.

2. The DCS bPEPs which enact programmatic and technical operations on information assets in support of cross coalition information exchange including:

a. Security label equivalency; and b. Inter nation cryptographic protections.




3. The DCS PEPs which enforce local access control restrictions and provide data protection services, including:

a. Policy enforcement over access to information; b. Release of information to authorized users; and c. Generation of audit records for data access attempts.

Note that not all overlays need to include the PEP protections. For certain deployments only the bPEPs, which will support and prove the viability of the DCS-based cross coalition model, will be needed and used. In this deployment model, the MNE is using DCS-based protection at the national boundary to support information exchange with other coalition networks, but are using their own information protection model within their national network. This decision to provide national DCS protection for some deployments and deployments without a national DCS protection model is in support of the CWIX2015 exercise. Specifically, it provides evidence that DCS and non-DCS environments can leverage the cross coalition exchange model that is part of the CWIX2015 capability target.




3.2.2. MNE Equivalent Configuration In the MNE Equivalent deployment model, the same DCS components are provided as part of the security overlay. However, the baseline information infrastructure on which the overlay resides is provided in addition to the DCS components. As stated previously, it is a technology objective to ensure that the MNE Equivalent is aligned with the MNE from a networking configuration, data service model and data processing perspective.

Figure 11: MNE Equivalent with MNX Capability

Unlike the MNE Overlay model, the MNE Equivalent must provide PEPs for the protection of local information assets. For the CWIX2015 exercise, the MNE Equivalent will only be deployed in the operations environment in Poland. The MNE Equivalent also includes a remote desktop service that will allow external laptops to connect to the deployed information infrastructure. This is in support of an MNE capability as described in the following section




3.2.3. MNX Configuration For certain mission deployments, some partner nations will not provide IT infrastructure. These partners will connect to other nations via the FMN through a MNE that support Federated Mission Extensions (MNX). Through MNX, partner nations will have limited access to coalition assets. For the CWIX2015 exercise, the MNE Equivalent will offer an MNX capability based on remote desktop access to information services that are protected with DCS security services. The MNE Equivalent will host a common NATO Windows domain into which partner nations can be provisioned. Partner nation users will be able to connect, via RDP, to remote desktop sessions where they will have access to email, IM and SIMG information services. On the NATO MNE Equivalent network, however, partner nations will only be members of communities of interest for which they have a need to know or communities that they create themselves. In effect, this single protected network will be providing any number of COI separated information communities, as shown in Figure 12: MNX Capability through COI Separation.

Figure 12: MNX Capability through COI Separation

Information assets that are created, therefore, can be restricted to ensure that they are only released to those partner nations with a policy right to access the content. In the above example,




1. Asset A would only be accessible to users that are members of Partner 1’s contingent;

2. Asset B would be accessible to members of both Partner nations; and 3. Asset C would be accessible to members of the International Security Assistance

Force (ISAF) group, a group to which both Partner 1 and Partner 2 belong. This approach to deploying a MNX capability that builds upon the information protection principles of DCS is very flexible, easily allowing:

1. New partners to join the NATO network; 2. New communities to be created for specific partner requirements; and 3. New policies to be enforced that will safeguard information through the

application of DCS security protection. It is significant to note that MNX partner nation participants are able to share information assets with other nations in cross coalition exchanges. As members of the NATO MNE, information assets destined for other MNEs will traverse the border protection services and be made available to the receiving nation so long as the action is in accord with the established information sharing security policies.

3.2.4. Federated Mission Network For the CWIX2015 exercise, it is assumed that the FMN will serve as the mechanism of exchange for sending information assets between MNE deployments. It is assumed that each MNE will have access to the FMN and that routing, DNS services, and reliable delivery are provided by the FMN. Type 1 cryptographic protection, provided by the FMN and used to protect point to point exchanges between MNEs, does not interfere with the CWIX2015 exercise nor is the exercise reliant on link level cryptographic protection. The link level protections on the FMN are present in order to achieve the required minimum level of risk for the multi-coalition environment. These protections are leveraged by the CWIX2015 experiment but do not represent a core requirement for the trust model established between MNEs.




3.3. Capabilities Under Evaluation This section draws from the technical and programmatic aspects of this DCS cross coalition concept and defines the technology target for participation at the CWIX2015 exercise. This section identifies the capabilities of individual DCS cross coalition components that will form the basis for the CWIX2015 experiment testing, evaluation scenarios and evidence gathering.

3.3.1. Updates to the National Information Protection Model Within an MNE that has DCS protection services in place, the national security policy and national security services will protect information as it is stored and processed within the national network. This form of DCS information protection, at a national level only, has been vetted through C&A assessments that endorse the DCS security protection model for providing COI separation on a single national network. When migrating the national DCS model to a cross coalition information sharing model, the releasability of the information becomes part of the information security evaluation process. For the CWIX2015 exercise, releasability is used and validated as part of a three-way policy decision; when a user attempts to send an information asset to a partner nation, the following policy checks will apply:

1. Does the user have the policy right to create content with the defined COIs?

2. Does the user have the policy right to set the releasability on the asset for the target nation?

3. Can assets with the defined COIs be released to the target nation?

The intent of this process is to vet the release decision as close as possible to the acting user so that auditing of the event can be definitively linked to that user. Vetting policy decisions earlier in the exchange process also minimizes the amount of processing that is done at the bPEPs. The policy decision process could also include validation of the user’s clearance and nationality. However, as mentioned previously, these aspects of security policy enforcement are not part of the capability target for CWIX2015. This extension to the national DCS protection model requires extensions to the management of asset security metadata, user security attributes and national policy enforcement. The required changes to the security labelling, user management and policy decision services are described in Section 5.1.1 - MNE Infrastructure Components.




3.3.2. Cross Coalition Information Protection The capabilities that are enacted in support of the cross coalition information exchange form the core of the targeted capability for the CWIX2015 exercise. These capabilities are primarily provided by the bPEPs and the services that they draw upon; most significantly by the Security Label Equivalency Service (SLES) described in a subsequent section. From an operational perspective, however, the bPEP is responsible for the following activities when it intercepts an information asset that is in transit from one national network to another:

1. Determine the identity of the target nation by mapping the network or network name to a national identity (e.g. gc.ca = CAN);

2. Ensure that the asset can be released to that nation; 3. Remove national information protection mechanisms; 4. Create the TSL based on information provided by the eMoU; 5. Cryptographically bind the security label to the asset; 6. Encrypt the asset; and 7. Send the asset to the recipient domain.

The receiving bPEP performs a similar process.

1. Decrypt the asset; 2. Validate the digital signature; 3. Map the TSL to the NSL format; 4. Apply national information protection mechanisms to the asset; and 5. Deliver the asset to the destination data service for delivery to the target user.

The reference architecture and high-level requirements for the bPEPs and the DCS services that they rely upon is described in Section 5 - System Reference Architecture.

3.3.3. Security Label Equivalency Service For the CWIX2015 experiment, the capability target for the eMoU is a subset of the component concept described in Section 2.4.1 - Electronic Memorandum of Understanding. The SLES that is implemented for the CWIX2015 exercise will be a subset of the eventual capability set for fully supporting cross coalition information exchange. However, the scenarios that leverage the deployed SLES capability will be sufficient to prove the viability of the approach and to demonstrate how the eMoU supports the cross coalition information sharing trust model. The SLES deployment for CWIX2015 will also serve as a basis for better understanding the problem space and better defining the requirements that would need to be met in an operational instantiation of the eMoU in a full DCS cross coalition infrastructure.




For the CWIX2015 exercise, the eMoU will be limited to the nation-to-nation level only. That is, there will be no sub groups within a nation that will require support for hierarchically structured security attribute dependencies within the security label. Additionally, the eMoU will only specify the following four core security attributes:

1. PolicyID; 2. Classification; 3. Releasability; and 4. COIs.

These are mandatory security label elements and it is assumed that the security labelling capability that is being used within national networks will support these fields. Since these are the only mandatory fields for a security label, the CWIX2015 eMoU will not dictate what attributes must be on a security label. This issue is addressed de facto through the specification of these 4 security attributes. The eMoU mapping between MNE network names, national identities and security equivalencies will be defined as part of the security infrastructure configuration for the exercise. Hierarchical eMoU rules and dynamic security label mapping by the SLES will not take place.

3.3.4. Transport Security Label For the CWIX2015 exercise, the SLAB security label format will be used to express security labels that adhere to the STANAG specification, as documented in the Confidentiality Labelling and Binding for Joint Coalition Information Sharing [Reference 5]. It is assumed that a security labelling capability will be present within each domain. When egressing a national network, the TSL will be generated in the following manner:

1. The SLES will transform the security attributes on the original NSL to create a new security label (TLS) that will be expressed in SLAB format and placed in custom.xml; and

2. The original NSL on the information asset will be retained and placed in custom.orig.

When ingressing a national network MNE the digital signature is validated in order to ensure that the security label and the asset have not been modified. The protected information asset will be decrypted using the cryptographic protections defined in Section 3.3.5 - Cross Coalition Cryptographic Protections. The TSL embedded within an asset will be processed in the following manner:

• The SLES will transform the security attributes on the TLS to values that are relevant for the national network and a NSL will be generated for the information asset based on the mapped values provided by the eMoU.




3.3.5. Cross Coalition Cryptographic Protections For the CWIX2015 experiment, the protection of information assets and binding of security labels will be done using manually exchanged public key certificates. A digital signature of the asset, including the embedded TSL, will be implemented. The information asset will be encrypted for the target nation. It is significant to note that the use of public key cryptography is one possible mechanism for protecting information assets in a cross coalition framework but is by no means the only mechanism that can be used in this DCS-based approach to information sharing. Any means of information protection is valid so long as the approach meets the risk management requirements of the participating nations. The encryption standards and protocols that are used in the CWIX2015 exercise are described in Section 4 - CWIX Protocols and Data Standards.

3.4. Application Support The experiment will demonstrate cross coalition information exchanges based on email, IM sessions and Simulated GCCS (SIMG) data feeds.

3.4.1. Email Email messages can be sent to both local (within the same MNE) and to cross coalition recipients. Email messages can have attachments and DCS protection will be applied individually to both the message body and the message attachments. If DCS protections are deployed within the sender MNE, the sending of email messages must be compliant with the national policy. That is, the sender must have the policy right to send the email message and the local recipients must have the policy right to receive the information. When emails are sent to another nation, the sender must have the policy right to assign the releasability attribute in the asset. This check occurs at the PEP/PDP. In addition, the recipient national network is compared to the list of releasable countries on the asset to ensure that the asset can be released to the target network. This check occurs at the bPEP. Within a national network the asset will have a NSL and national DCS asset level protections to prevent tampering and disclosure. This security label and protection mechanisms are not understood outside of the national network, including in other national networks. Consequently, at the bPEP the NSL is transformed into a standards-based TSL using security metadata values that are appropriate for the receiving national network. The TSL will in turn be transformed at the recipient bPEP into the recipient NSL so that it can be appropriately handled within that environment. Similarly, the DCS asset level protections added by the sender national network are removed at the bPEP, and replaced by protection mechanisms agreed upon by both national networks. These protection mechanisms are then removed at the recipient bPEP and



replaced by national DCS asset level protections to prevent tampering and disclosure in the recipient national network.

An end-to-end scenario of the email exchange process is provided below and consists of four stages:

1. The sending of the email message from the sender national network; 2. The releasing of the email to the recipient national network; 3. The acceptance of the email from the sender national network; and 4. The delivery of the email to the intended recipient.

Each stage is described in the following sections.

National Protections on Sending Email

Figure 13: National Protections on Sending Email

1) A user generates an email message. The email may or may not include file attachments. The email message body, and any attachments, each have a NSL appropriate for the information content as determined by the sender. This message is sent from the mail client on the user’s workstation to the mail server, via SMTP, but is intercepted by the Email EP to ensure that DCS information protection is applied;

2) The PEP leverages the SLS to validate and retrieve the required security metadata from the NSL on the email and each of its attachments;



3) The PEP consults the local authorization service (PDP) to ensure that the email, and its attachments, is compliant with the security policy. These checks ensure that:

a. The user has the policy right to create information assets using the security attributes in the asset’s security label;

b. The user has the policy right to assign the releasability attribute in the asset;

4) The email, and its attachments, is protected using the national cryptographicprotection mechanism (KMS/CTS). This cryptographic protection mechanism ensures that the email, and its attachments, is protected while at rest (while awaiting delivery by the mail server) and while in transit in the sender national network;

5) An audit record of the transaction is submitted to the TAS; and

6) The newly protected email, and its attachments, is submitted to the mail server for distribution.

Border Protections on Sending Email

If the email is being sent to a recipient in another national network, the email is routed through the bPEP at the nation’s boundary in preparation for delivery to the recipient national network.

Figure 14: Border Protections on Sending Email




1) At the bPEP, the email, and any attachments, is separated into its component

parts. The email and each of the attachments is considered a separate asset, each with their own NSL;

2) At the bPEP, the national cryptographic protections on each asset are removed;

3) At the bPEP, the recipient national network is compared to the list of releasable countries on the asset to ensure that the asset can be released to the recipient national network;

4) Using the NSL, the SLES 8 provides equivalent security data mapping for each

asset security label that is used in the creation of the TSL. The TSL, which uses the NATO STANAG format for security labels, is built based on the security attributes that are appropriate for the recipient national network. The TSL is stored in the message header of the email, and the custom.xml field of the file attachment. The original NSL is retained in the custom.orig field of the file attachment;

5) The bPEP digitally signs and encrypts each asset, effectively binding the TSL to

the asset. The bPEP will use the private signing key of the sender national network for the digital signature and the public encryption key of the recipient national network for the encryption;


7) The newly formatted email message, with any attachments, is sent, via SMTP, to

the recipient national network.

Border Protections on Receiving Email At the entry point to the recipient national network, the email message is routed through the bPEP at the recipient nation’s boundary in preparation for delivery to the recipient network. Specifically, at the bPEP, the email (and any attachments) is processed to transform it into an information asset to which national DCS protections can be applied.

8 The SLES, which can be implemented as a DCS service, has been implemented as a software module running on the bPEP for CWIX2015.



Figure 15: Border Protections on Receiving Email

1) The bPEP decrypts each asset (using the recipient national network private decryption key), validates that the integrity of the asset and ensures that the TSL has been maintained (using the sender national network public verification key), and extracts the TSL from the asset;

2) For each asset, the SLES converts the TSL to a NSL that is understandable within the recipient national network. The NSL is stored in the message header of the email, and the custom.xml field of any file attachments. The sender national network NSL, stored in the custom.orig field of any file attachments, is retained;

3) Each asset is protected using the national cryptographic protection mechanism

(KMS/CTS). This cryptographic protection mechanism ensures that the email, and its attachments, is protected while at rest (while awaiting delivery by the mail server) and while in transit in the recipient national network;

4) An audit record of the transaction is submitted to the TAS and

5) The newly protected email, and any attachments, is submitted to the mail server for distribution within the recipient national network.

National Protection on Received Email Messages

The final stage of the email exchange process is the delivery of the email from the local mail server to the intended recipient in the recipient national network. This final leg of



the delivery process uses POP3 as the network protocol through which email messages are retrieved.

Figure 16:National Protection on Received Email Messages

1) The recipient requests the message from the local mail server. This message is sent from the mail server, via POP3, but is intercepted by the PEP to ensure that national DCS information protections are applied;

2) The PEP leverages the SLS to validate and retrieve the required security metadata from the security label on the asset;

3) The PEP consults the local authorization service (PDP) to ensure that email access by the recipient is compliant with the security policy. These checks ensure that:

a. The user has the policy right to access the information assets based in part on the security attributes in the asset’s security label;

4) The asset’s cryptographic protections are removed (KMS/CTS);


6) The email, and any attachments, is delivered to the intended recipient(s).




Note – If the PEP/PDP determines that a recipient is not permitted to receive an email sent from a sender national network, then the email will bounce back to a local security officer in the recipient national network. The sender in the sender national network will not be automatically notified of the failed delivery as this notification mechanism would constitute a covert channel that could be exploited by attackers in order to determine user privileges in the recipient national network.

3.4.2. Instant Messaging The granularity of asset level protection for IM sessions is set at the individual message level. Each message is protected using a unique symmetric key. At a national level, listing and joining a chat room are actions that are subject to an access control check that ensures the operation is in compliance with the security policy. As a result, each chat room has an assigned COI that is defined when the room is established. The bPEP will broker conversations between XMPP servers. These conversations use the XMPP Server to Server (S2S) protocol. A request for a chat room listing will be vetted by the bPEP to only show those chat rooms that can be accessed by a partner nation. The security label on the chat room will be equated for the requesting partner nation so that local DCS protections can enforce access control to that remote chat room. An IM user in a national network that has joined a coalition chat room hosted at another network can request that individual messages be placed in a subchannel. Subchannels are national messages that reside on non-national XMPP servers. A subchannel message is protected at the originating nation’s IM PEP and is, therefore, doubly encrypted when it resides on the IM server:

1. Once with national DCS protection; and 2. Once with the hosting nation’s DCS protection.

Other nations will only have the ability to remove one layer of encryption9 and, therefore, the message will remain encrypted for all nations but the originator. Even the host nation will not be able to access the content of the subchannel messages. This means that the content is not accessible to both XMPP users and the XMPP administrator at the hosting nation. Only at the originating nation will both layers of protection be removed and the content made available to members of the originating nation.

9 Since the symmetric key that was used to protect the message is not accessible outside a nation’s boundary.



Participation in Coalition Hosted Chat Rooms

Figure 17: Participation in Coalition Hosted Chat Rooms

When presented with a request for a list of chat rooms, the DCS-based information exchange process would adhere to the following process:

1. In the figure above, a user connects to their local XMPP server via a national PEP that enforces local national protection on chat room messages. This user would only have access to those local chat rooms for which the user has a policy right to access. Once connected to a local XMPP server, the IM client user can request a list of available chat rooms from an XMPP server in another national network;

2. The remote XMPP server would provide a list of DCS protected chat rooms and deliver this information in an XMPP S2S formatted message;

3. At the remote bPEP, the releasability attributes on the chat rooms in that list

would be vetted against the requesting nation. Chat rooms that cannot be released to the target nation would be removed from the list, ensuring that the list of chat rooms only includes those rooms that can be released to the requesting nation;

4. The remote bPEP would also invoke the following DCS Security Services:




a. The remote bPEP will consult the SLES service to map the security metadata on the chat room to their equivalent value for the receiving nation;

b. An audit record of the transaction is submitted to the TAS;

5. The list of releasable chat rooms will be sent to the requesting domain where it will be intercepted by the local bPEP;

6. The local bPEP invokes the following DCS Security Services:

a. The security attributes on the chat rooms would be translated by the

SLES to reference their local national security attribute equivalents; b. An audit record of the transaction is submitted to the TAS;

7. The chat room list would be presented to the local XMPP server; and

8. The PEP invokes the following DCS Security Services:

a. The national PEP leverages the SLS to validate and retrieve the

required security metadata from the security label on the asset; b. The national PEP consults the PDP to ensure that the requesting user

has the policy right to see and join the chat rooms on the list. Any chat rooms for which the user does not have a policy right to access will be scrubbed from the list;

c. An audit record of the transaction is submitted to the TAS; and

9. The chat room list is delivered to the local IM user.



Messaging In Coalition Hosted Chat Rooms

Once a user (local or remote) has been given the right to join a chat room, all messages at that COI within that chat room can be viewed by that user. Messaging, in this scenario can be supported in the following manner.

Figure 18: Messaging In Coalition Hosted Chat Rooms

1. A user at the remote network creates and sends a message to the chat room.

2. This message is intercepted by the PEP, which invokes the following DCS Security Services:

a. The PEP leverages the SLS to validate and retrieve the required security metadata from the security label on the asset;

b. The PEP consults the local authorization service (PDP) to ensure that the message is compliant with the security policy. These checks ensure that:

i. The user has the policy right to create information assets using the security attributes in the asset’s security label;

ii. The user has the policy right to assign the releasability attribute in the asset;

c. The message is protected using the national cryptographic protection mechanism (KMS/CTS);

d. An audit record of the transaction is submitted to the TAS

3. Once delivered to the XMPP server, the message is relayed to all chat room recipients including those in remote national networks;




4. When the message is to be delivered to another national network, the message

is intercepted at the bPEP, which invokes the following DCS Security Services:

a. The national cryptographic protections on each asset are removed; b. The recipient national network is compared to the list of releasable

countries on the asset to ensure that the asset can be released to the recipient national network;

c. The SLES provides equivalent security data mapping for each asset security label that is used;

d. An audit record of the transaction is submitted to the TAS; e. Commonly agreed upon asset protection will be added to ensure the

confidentiality/integrity of the data sent over the coalition network;

5. The asset level protected XMPP message will be sent to the requesting nation’s bPEP;

6. The local bPEP invokes the following DCS Security Services:

a. The local bPEP will decrypt and validate the asset; b. The security attributes on the messages would be translated by the

SLES to reference their local national security attribute equivalents; c. Each asset is protected using the national cryptographic protection

mechanism (KMS/CTS); d. An audit record of the transaction is submitted to the TAS;

7. The message is sent to the local XMPP server;

8. The PEP invokes the following DCS Security Services:

a. The PEP leverages the SLS to validate and retrieve the required

security metadata from the security label on the asset; b. The PEP consults the PDP to ensure that the requesting user has the

policy right to receive the message; c. The asset’s cryptographic protections are removed (KMS/CTS); d. An audit record of the transaction is submitted to the TAS; and

9. The message is delivered to the local IM user.



National SubChannels In Coalition Hosted Chat Rooms

The IM chat room subchannel capability allows members of one nation to have a segregated conversation (using marked messages) within a coalition chat room that is hosted by another nation and includes participants of many other partner nations. The context of the national conversation would only be accessible to members of the subchannel nation and only viewable from within that nation’s network.

Figure 19: National SubChannels In Coalition Hosted Chat Rooms

1. A user generates a message that is flagged for national protection (a subchannel).10 At the PEP, this message is protected with national encryption that is not removed when the message is delivered to the remote XMPP network;

2. At the local bPEP, asset level protections will be placed on the XMPP messages to prevent tampering of the message while in transit over the coalition network. These asset level protections are removed by the remote bPEP;

3. At the remote bPEP, national asset level protections will be applied. Since the

bPEP does not distinguish between normal IM messages and subchannel messages, the national asset level protections will be applied to both. Consequently, normal messages are protected so that they are not disclosed while stored at the XMPP server. Subchannel messages are thus doubly protected with dual encryption (once with the originating nation’s encryption infrastructure and again with the host nation’s encryption); and

10 The three characters (!) are used to flag messages for national protection. “(!) Message A” is only viewable within the national domain, whereas “Message B” can be seen by everyone.




4. A coalition member will receive the subchannel message, but since the message has been protected with an external cryptographic infrastructure, the message content will not be disclosed.

In this scenario, it is important to realize that coalition members will be made aware of subchannel messages. If the presence of subchannel message is not desired, a separate chat room and session for members of the originating nation should be established. The IM user would have 2 concurrent chat sessions active: one with the coalition and one for nationals only. The DCS protection model, however, supports this configuration by allowing national and coalition information to reside concurrently on a single network.

3.4.3. Simulated Global Command and Control Systems (SIMG) Each MNE will have a SIMG Server that processes command and control information in the form of web traffic consisting of structured SIMG data records. This information can be received by two local systems:

1. A SIMG Client for more detailed review of the SIMG data; and 2. A SIMG Graphical Client, based on NASA World Wind, for a common operating

picture (COP) based Geographic Information System (GIS) representation of data.

Access to the SIMG Server will be subject to local DCS information protection restrictions. When a DCS is overlaid over the SIMG system, the data begins to flow through a national PEP or a border PEP, that encrypt/decrypt parts of event data and filter the events based on security labelling information.



Figure 20: Coalition-based Simulated GCCS (SIMG)

For the CWIX2015 experiment, SIMG information sharing will be handled according to the following processing model (as illustrated in Figure 20):

1. The SIMG Client will generate SIMG data records in command line mode and send them to the SIMG Server. The SIMG data will include security metadata that identifies the information as belonging to a specific classification, releasability and community11;

2. SIMG client systems, in the form of the SIMG Client or the SIMG Graphical Client, access the SIMG Server through their PEP. This PEP will, based on DCS-based access control decisions12, restrict a user’s view of the SIMG situational awareness based upon their defined access rights and need-to-know. It will also ensure that SIMG data submitted to the SIMG Sever by the SIMG Client is appropriately protected;

11 SIMG has a security label field that will be used to store the security metadata. 12 User access to SIMG data will also be filtered by the SIMG Server. Specifically, the SIMG Server will filter client requests normally, while the national PEP filters the requests on the way back based on the security metadata associated with the SIMG data.




3. The SIMG Graphical Client, based on NASA World Wind, displays the SIMG data received from the SIMG Server over GIS maps.

4. SIMG Servers can also subscribe to SIMG data feeds from sources in other

national networks. Specifically, it maintains a subscription database that contains a list of other SIMG Servers that might be interested in one or more filters. When events are assigned to a filter, the SIMG Server pushes the events to the required server. This data feed will be provided as encrypted records using the cryptographic mechanism negotiated between nations on the coalition shared network;

5. At a nation’s boundary, only those SIMG records that can be released to a

requesting nation will be sent along the SIMG data feed. The security metadata in the individual SIMG records will be mapped, according to the eMoU and SLES to the equivalent security metadata values for the requesting nation; and

6. At the receiving national boundary, the receiving bPEP can validate the record

format to ensure that it retains its original integrity. The bPEP can also further refine the security metadata on the incoming data feed records to match the national security labelling and information protection strategy.13

13 The SIMG geolocation data will be encrypted on the SIMG Server in order to prevent unauthorized access to the data. A separate cryptographic key will be used for each event and the encryption token will be retained in the description field.




4. CWIX Protocols and Data Standards This section will examine the protocols and data standards that will be used to provide the capabilities required for the CWIX2015 technology target. It identifies those protocols and standards that are needed for DCS information protection capability in general and those that are specifically required to support the cross coalition information exchange capability. The components of the DCS information protection model that will be examined include the following:

• Network protocols that support information exchange and are the focus of information protection processes;

• Data formats for the information assets to be protected through the DCS information protection services;

• Security labelling standards that are applied to information assets; and • Cryptographic mechanisms used to protect information assets.

4.1. Network Protocols This section of the report will examine network protocols used to facilitate cross-coalition information exchange for CWIX2015. Specifically, this section will examine the following:

1. The DCS SOA messaging protocols; 2. The Security Label Equivalency Service (SLES) protocol; 3. Application protocols in support of cross coalition information exchange of:

a. Email; b. Instant Messaging; and c. SIMG information.

4.1.1. DCS SOA Messaging Protocols The individual bPEPs have many similarities to the corresponding traditional PEPs in that they leverage the same Security Messaging Service Bus (SMSB) over which DCS information protection services are accessed. That is, the SMSB provides the transport mechanism over which the DCS SOA services are provided. For the DCS information protection capability that will be demonstrated at the CWIX2015 exercise, the SMSB uses the Extensible Messaging and Presence Protocol (XMPP) as the delivery mechanism for exchanging security messages between the PEPs and their associated information protection security services. Through the DCS SOA, the bPEP will exchange security messages with following DCS-based security services.




• The Security Labelling Service (SLS) - A PEP can assign security metadata to an asset by requesting that the SLS create a security label on that asset. Similarly, a PEP can validate and retrieve security metadata on an asset by requesting that the SLS access the content in a security label on an asset. Security label requests are formatted as XACML context messages that are transported over XMPP. An SLS implementation is tied to a specific security label format; in a national network environment, the SLS can perform actions on the national security label format;

• The Cryptographic Transformation Service (CTS) - The CTS, in conjunction with

the national key escrow system, will apply and remove symmetric key protections on an asset. Both CTS and key management service requests are XACML context messages and are transported over XMPP; and

• The Trusted Audit Service (TAS) - Audit traffic, in the form of AuditXML-based

messages, is transmitted over the Audit SMSB 14 using XMPP. The bPEP will also exchange messages with the new security service; the Security Label Equivalency Service (SLES). The protocols involved in providing these services are discussed in the following section.

4.1.2. Security Labelling Equivalency Service Protocol The communication between the bPEP and the SLES takes the form of XACML context messages and is transmitted over the SMSB using XMPP. This process, which is illustrated in Figure 21 - SLES Deployed Architecture, consist of the following:

• As a DCS SOA service, the SLES will connect and authenticate to the XMPP-based security-messaging infrastructure in order to become a participant on the Security SMSB. Once connected to the SMSB, the SLES waits for the security label translation requests;

• When a security label translation operation is needed, the bPEP sends security label mapping information, in the form of an XACML context message to the SLES;

• The SLES maps these NSL attributes to their equivalent values for the intended target national network as per the eMoU; and

• The SLES sends the mapped security label attributes back to the calling bPEP in the form of an XACML context response message.

14 Audit messages may be transmitted by the same security message bus, or have its own dedicated audit bus depending on the security posture of the target infrastructure. For the purpose of CWIX2015 there will be a single messaging bus for all XMPP traffic.



Figure 21 - SLES Deployed Architecture

4.1.3. Cross-Coalition Email Protocols It is anticipated that cross-coalition email will be provided using an email intercept strategy based on the SMTP protocols. When a message is sent from the sender national network’s mail server, the bPEP intercepts the message, applies cross coalition information protection processing on the message and associated attachments, and allows the SMTP transaction to continue using a newly created email with attachments. The recipient national network bPEP similarly intercepts the SMTP email message. It processes both the email and its attachments in order to generate a nationally protected email asset. This new asset is relayed via SMTP to the recipient national network’s mail server. Within the recipient national network, delivery of email messages to the intended user recipient is also subject to policy enforcement, information protection and auditing. The application of DCS protections to the delivery of email to a user is implemented as a POP3 protocol intercept. This approach to email protection is predicated on the other domain mail servers being enabled for SMTP/POP3 email support. SMTP/POP3 support is included as part of the Microsoft Exchange product but is not enabled by default.

4.1.4. Cross Coalition IM Protocols At a national level, the DCS protection of instant message sessions is achieved using an XMPP-based application proxy. A user connects to their local XMPP server and messages that are exchanged between the user and the server are intercepted by an application proxy that works on the XMPP Client to Sever (C2S) protocol. The C2S




protocol is a single bi-directional communications channel consisting of client to server and server to client communications. IM exchanges between nations take place as persistent connections between XMPP servers at each domain. An application proxy at the national network boundary protects messages as they are exchanged with other national networks. This application proxy works on the XMPP Server to Sever (S2S) protocol. The S2S protocol is a unidirectional communications channel. Consequently, when two XMPP servers communicate they each establish a communications channel to their counterpart which is used to send-only to the other side.

4.1.5. Cross Coalition SIMG The SIMG data feeds used in the CWIX2015 are SIMG formatted (XML-based) data records that are exchanged over HTTP. The PEPs and bPEPs intercept this web-based traffic in order to apply information protection services on the SIMG assets that are being shared. The SIMG Graphical Client receives the XML data from the SIMG Server. Each event is then parsed, processed and subsequently displayed using direct calls to NASA World Wind’s SDK.

4.2. Security Labelling Standards This section will examine the two primary security labelling standards used for the CWIX2015 DCS information protection model and to facilitate cross-coalition information exchange. They are:

• The Titus Security Labelling Suite that is used to label information assets at a national level (NSL); and

• The Transport Security Label (TSL) that is used to assign security metadata to information assets to be exchanged with coalition partners.

4.2.1. Titus Document Security Label A NSL refers to a security label in which the format, syntax and semantics are proprietary to a domain and are generated using security tools for the originating domain. For CWIX2015 the baseline security labelling software for national networks will be the Titus Document Classification Suite. The Titus document classification plug-in for the Microsoft Office suite of products allows the creation of labelled Word, Excel and PowerPoint files that adhere to a specific, nationally specified, set of security metadata attributes and values.




As of Microsoft Office 2007, the Office product suite stores documents in a ZIP archive format. Within this archive there is:

1. a directory named docProps that contains; 2. a file called custom.xml.

This custom.xml file is reserved for 3rd party Office suite developers to add supplemental XML data to office documents. The Titus security labelling software suite places security attributes in this file using a security label structure that is configured for the security domain. The security label format that is used by the Titus Document Classification product is structured using XML elements as property value pairs, as shown in the example below. <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <Properties> <property name="CWIXPOLICYID"><vt:lpwstr>CAN 1.2.3.4</vt:lpwstr></property> <property name="CWIXCLASSIFICATION"><vt:lpwstr>NATO SECRET</vt:lpwstr></property> <property name="CWIXRELEASABILITY"><vt:lpwstr>FIN/USA</vt:lpwstr></property> <property name="CWIXCAVEATS"><vt:lpwstr>SPECIAL_OPS</vt:lpwstr> </property> </Properties>

It should be noted that the attribute names used to store security metadata can be configured within the Titus software suite. The attributes used in this sample represent one possible use of the Titus software to store the 4 mandatory security attributes for the CWIX2015 exercise, for example:

1. CWIXPOLICYID to store the security label policyID, 2. CWIXCLASSIFICATION to store the asset classification, 3. CWIXRELEASABILITY to store the asset releasability, and 4. CWIXCAVEATS to store the asset COI.

The only exception to the Titus’ approach to handling security labels on Office documents is its approach to labelling the body of email messages. The Titus Message Classification product, a plugin for Outlook, adds security attributes to the header information of an email message. A Titus labelled email message, therefore, has security metadata in the header that defines the security label for that message. Note that the message body and message attachments may have different security metadata. This requires PEPs to evaluate not only the security labels on email messages, but also on all attachments when making access control decisions for that message.

4.2.2. Transport Security Label The TSL uses a transient security labelling schema for the purpose of seamlessly transitioning from the originating nation’s security label format to the recipient nation’s security label format during cross coalition information exchange. For the CWIX2015




experiment, the schema chosen for the TSL is the STANAG supported SLAB format, as documented in the Confidentiality Labelling and Binding for Joint Coalition Information Sharing [Reference 5]. An example of a TSL based security label based on the SLAB format is shown below. <slab:ConfidentialityLabel xmlns:slab=”http://www.nato.int/2014/06/nl/cl”>

<slab:ConfidentialityInformation> <slab:PolicyIdentifier>CAN 1.2.3.4</slab:PolicyIdentifier> <slab:Classification>NATO SECRET</slab:Classification> <slab:Category Type="RESTRICTIVE" TagName="Special Category Desigrs">

<slab:GenericValue>SPECIAL_OPS</slab:GenericValue> </slab:Category> <slab:Category Type="PERMISSIVE" TagName="Releasable to">

<slab:GenericValue>FIN</slab:GenericValue> <slab:GenericValue>USA</slab:GenericValue>

</slab:Category> </slab:ConfidentialityInformation>

</slab:ConfidentialityLabel> <slab:AlternativeConfidentialityLabel xmlns:slab=”http://www.nato.int/2014/06/nl/cl”>

<slab:ConfidentialityInformation> <slab:PolicyIdentifier>CAN 1.2.3.4</slab:PolicyIdentifier> <slab:Classification>NATO SECRET</slab:Classification> <slab:Category Type="RESTRICTIVE" TagName="Special Category Desigrs">

<slab:GenericValue>SPECIAL_OPS</slab:GenericValue> </slab:Category> <slab:Category Type="PERMISSIVE" TagName="Releasable to">

<slab:GenericValue>FIN</slab:GenericValue> <slab:GenericValue>USA</slab:GenericValue>

</slab:Category> </slab:ConfidentialityInformation>

</slab:AlternativeConfidentialityLabel> The SLAB format provides both a ConfidentialityLabel and an AlternativeConfidentialityLabel. Within the TSL, only the ConfidentialityLabel will be used for the CWIX2015 exercise.

• The ConfidentialityLabel, will reflect the unmodified security label as it existed prior to release from the originating national network. That is, it is a direct translation from the national security label to the SLAB format.

For the CWIX2015 exercise, within the ConfidentialityLabel, there are four mandatory elements:

1. PolicyIdentifier, 2. Classification, 3. Special Category Desigrs, and 4. Releasable to.

All other elements, as documented in Confidentiality Labelling and Binding for Joint Coalition Information Sharing [Reference 5], are compatible with the DCS cross coalition information sharing concept, but are not in scope for this exercise.




4.3. Cryptographic Mechanisms This section will examine the cryptographic mechanisms used to ensure data confidentiality and integrity during cross-coalition information exchanges. Specifically, this section will look at securing the assets during the exchange. Transport Layer Security (TLS) between coalition domains will be supported where required (e.g., between XMPP servers using the S2S protocol) but will not be used universally. This is due to the fact that the assets themselves will be protected. It is worth noting that the cryptographic mechanisms outlined in this section leverage public key cryptography but do not necessitate the use of a PKI. In other words, participating domains can secure information transfer by exchanging public key certificates without having to participate in onerous cross-certification activities.

4.3.1. Asset Protection Asset protection, which is illustrated in Figure 22, consists of the following components:

• Digital Signature – A cryptographic hash of the asset, including the embedded TSL, is calculated. This value is then encrypted (signed) using the originating domain private key. SHA-256 will be used for hashing operations, while 2048-bit RSA will be used to encrypt the hash value;

• Asset Encryption – The information asset, including TSL and NSL, is encrypted with a symmetric key that has been generated by the originating domain specifically for this purpose. AES-128 will be used for all symmetric encryption; and

• Symmetric Key Encryption – The symmetric key is encrypted using the recipient domain public key. 2048-bit RSA will be used for this operation.

The encrypted asset can be decrypted by the receiving domain by first decrypting the symmetric key using its domain private key and then using the symmetric key to decrypt the asset. The receiving domain will be able to verify that the asset, including TSL, was not modified in transit. This is accomplished by calculating a cryptographic hash, and then comparing it to the encrypted value stored as part of the digital signature. The encrypted cryptographic hash can be decrypted using the originating domain public key.



Figure 22 – Asset Protection



5. System Reference Architecture

This section presents the reference architecture for the CWIX2015 exercise deployment. This architecture, shown in Figure 23: CWIX2015 Reference Architecture, identifies all of the significant solution components; including the IT infrastructure elements provided by the MNE, the DCS security support infrastructure and the DCS information protection components. This diagram also shows the interconnections between application components and the data flows between the overlay and the baseline infrastructure.

Figure 23: CWIX2015 Reference Architecture

This diagram indicates which existing architectural components can be used in a cross coalition model without the need for modification (blue), which existing components will




require a degree of enhancement or extension (orange) and which architectural pieces are new (red). It should be noted that the CTS service, which does not need to be modified is co-located with each of the PEPs and bPEPs. In addition, the SLS, which will need to undergo a degree of enhancement, is co-located with both the Email PEP and bPEP. Lastly, the SLES, which is an entirely new service, is co-located with each of the bPEPs. Each of the architectural components in this diagram is described in the following section, including the capability requirements those components must adhere to or provide. New solution elements, as well as modifications to existing DCS information protection components, are described in detail. The intent of this section is to provide the DCS solution team with a high level definition of the requirements for the creation of the DCS components, as part of achieving the overarching objective for DCS-based cross coalition information sharing.

5.1. Component Model This section is divided into specifics subsections for:

• MNE Infrastructure components that must be configured to support DCS-based information protection;

• Existing DCS solution elements, based on the national DCS protection model, that can support the DCS cross coalition information protection model without the need for enhancements to their current capability;

• Existing DCS solution elements, based on the national DCS protection model, that must be extended or enhanced to support the DCS cross coalition information protection model; and

• New DCS solution elements that must be developed to support the DCS cross coalition information protection model.

5.1.1. MNE Infrastructure Components The MNE infrastructure components that will be leveraged in the CWIX2015 experiment are defined below. While there are no changes required to the software that is deployed for these components, there are some configuration requirements (e.g. protocol support) that must be enabled to support the DCS information protection model. These requirements are listed in this section.

Microsoft Windows Active Directory The expectation is that the Windows Active Directory deployment will be based on Window Server 2008 R2. All workstations in the national network will authenticate to this server using NTLMv2. Within the AD structure, 3 extensionAttribute elements of the AD user schema will be reserved for use by the DCS solution so as to support the dynamic security attribute lookup for domain users. This dynamic security update is a




capability needed by the Titus labelling software. The MNE environment will provide an account with the permissions to update these extensionAttribute values so that the DCS authoritative security attributes can be kept synchronized with the non-authoritative security attributes stored in the Active Directory server. To reiterate, this lookup capability is in support of the Titus labelling software. MNE environments that do not use Titus to generate security labels on information assets will not need this capability. The extensionAttribute schema attributes will be used to store the following: the user’s clearance, non-authoritative releasability rights and community membership.

Microsoft Exchange Server The expectation is that an Exchange Server 2010 deployment will be in place within the MNE environment. All users will use this service as their local mail server. The Exchange Server must support local SMTP and POP3 email protocols. This is a capability that is installed with the Exchange Server, but must be enabled, as the default configuration is to have the POP3 service disabled.

OpenFire IM Server The OpenFire IM Server software does not require any modification in order to support the DCS information protection model.

Workstations It is anticipated that the MNE environment will provide Windows 7 workstations with the following software installed:

• Microsoft Office 2007; • Spark IM client; and • Titus Labelling Suite (for MNE environments that use Titus)

o The Titus software must be configured to use the dynamic lookup to the local Active Directory server in order to display the current user’s security attributes.




5.1.2. Existing DCS Components This section describes the DCS solution elements that will be deployed to the MNE environment as part of the security overlay and do not require any modification to support the DCS cross coalition information exchange capability.

SOA Messaging Capability The DCS SOA messaging infrastructure is an unmodified XMPP message server. All DCS services connect to this messaging infrastructure and the message server is responsible for relaying messages to the intended recipient service over SSL/TLS. The manner by which the CWIX2015 DCS service will leverage this messaging infrastructure in a cross coalition model is unchanged from a nation-only DCS model. It is significant to note, however, that the messages that are exchanged between DCS components remain within the national network. Additionally, the SOA traffic may be deployed on a physically separated network, depending on the hardware capability of the deployed MNE environments.

Cryptographic and Key Management Services for National Assets The requirement for the protection of information assets at a national level remains unchanged for CWIX2015. The cryptographic transformation and symmetric key management services can be deployed to the MNE overlay without modification. The only change to the use of national encryption is that cryptographic services will now be requested not only from the traditional PEPs but also from the bPEPs. The interface to both services remains unchanged. Note that these cryptographic protection services are only used for the protection of national assets in the national network. Cryptographic protection for assets as they traverse the FMN will be provided through the bPEP, as described in Section 3.3.4 - Transport Security Label and below in Section 5.1.4 - New DCS Components in Support of Cross Coalition Information Sharing.

Trusted Audit Service The requirements for the auditing of actions performed against information assets at a national level remain unchanged for this cross coalition capability. The trusted audit service can be deployed to the MNE overlay without modification. The bPEPs will generate audit information and submit audit records to the TAS that reflect the operations that take place at the border. The intent is for the existing TAS interface to be used to accept, protect and store this information. The TAS will need to be able to process the new audit information that is created by the bPEPs.




5.1.3. Enhanced DCS Components This section describes the DCS solution elements that will be deployed to the MNE environment as part of the security overlay and require enhancements to their existing capabilities in order to support the DCS cross coalition information exchange capability. The purpose and role of these components remains unchanged; they simply must take on a broader context when placed in a coalition environment.

Identity Attribute Service The IAS is responsible for managing individual user’s security attributes. In a single nation DCS model, the releasability attribute was not relevant. In the cross coalition model, however, the nations to which a user has the right to release information is part of the enforcement of DCS information protection. In the CWIX2015 experiment, therefore, the IAS will retrieve the list of nations to which a user can release information. This security attribute will be part of the policy decision made when a user creates information assets. Additionally, the IAS will send non-authoritative information to the local Active Directory so that the workstation-based labelling software can access it. For the CWIX2015 experiment, this information is held in the AD schema extensionAttribute property for each user. This is the location from which the Titus labelling software reads security attributes for a given user.

Security Labelling Service The SLS is responsible for interpreting the security labels on information assets. The SLS is, therefore, implemented for a specific security label standard. For the existing DCS information protection implementation, the SLS is able to interpret security labels generated by the Titus security labelling software. In the cross coalition model, however, national labels for information assets will be created by:

1. National users that leverage their local workstation’s security labelling software; and

2. bPEPs that accept an information asset from a remote national network and need to transform that asset into a form that can be interpreted by the local DCS services.

This means that the SLS must be able to not only read NSLs using the national labelling format, but also must be able to create those security labels on assets.




Additionally, the SLS must support the 4 properties that have been deemed as required for all security labels, specifically: policyID, classification, releasability and caveats. The SLS will be developed using the Titus labelling software as the de facto standard for national labels.

Policy Decision Point The PDP is responsible for making access control decisions on the creation and use of information assets. In a single nation DCS model, this was based on the caveats/communities associated with the asset and the user. In the cross coalition model, however, the creation of information assets that can be released to a nation becomes a relevant part of the policy enforcement process. When information assets are being created (e.g. an email is being sent) the enhanced PDP will be required to make a policy decision based on the following restrictions.

1. Does the user have the policy right to create assets for the specified communities?

2. Does the user have the policy right to release information to the specified nations?

3. Can the communities to which the asset belongs be released to the specified nations?

Only when all three aspects of this policy decision are permitted will the action be allowed to take place.

Email Policy Enforcement Point The requirements for, and implementation of, the Email PEP under a national-only DCS model remains the same under a cross coalition model, with the following exceptions:

• Email recipients that belong to another national network cannot be subjected to a local policy check. The local policy check (PEP/PDP) will only ensure that the user can assign the releasability attribute in the asset. The bPEP will ensure that the asset can be released to the target network by comparing the list of releasable countries on the asset to the recipient national network. The trust model will rely on the recipient nation to restrict access to the email accordingly; and

• The call made to the PDP must contain all the necessary information to allow the

PDP to make a decision as to the user’s suitability to assign the releasability attribute in the asset.




Instant Message Policy Enforcement Point The requirements for, and implementation of, the IM PEP under a national-only DCS model remains the same under a cross coalition model, with the following exceptions:

1. For the purpose of the CWIX2015 exercise, the concept of inter-nation subchannels is superseded by the new concept of national-level subchannels. Users from one nation that are participating in a multi-nation chat room can flag specific messages for local encryption. These messages remain encrypted on all networks except the national network from which the message originated. The IM PEP must recognize requests to keep specific messages protected while they exist outside of the national network.

5.1.4. New DCS Components in Support of Cross Coalition Information Sharing This section describes the new DCS solution elements that will be implemented and deployed to the MNE environment as part of the security overlay. The target capability for these services is to meet the required objectives for the CWIX2015 exercise and help to provide evidence in support of the DCS cross coalition information sharing trust model.

Security Label Equivalency Service For the CWIX2015 exercise, the SLES not be implemented as a single-instance security service. Instead, the SLES code will be embedded in the Dispatcher (bPEP). The bPEPs will call this service in order to acquire the correct security metadata content for:

• The TSL on asset egress; and • The NSL on asset ingress.

The calls to this service will take the form of XACML context messages. On egress, the calls to the SLES will take the following form:

• the subject is the receiving nation, • the resources are the assets to be mapped; and • the action is statically defined as WRITE.

The response will be a DCS security response message with a dictionary of the mapped values and a status message to indicate the result of the operation. On ingress, the calls to the SLES will take the following form:

• the subject is the sending nation, • the resources are the assets to be mapped; and




• the action is statically defined as READ. The response will be a DCS security response message with a dictionary of the mapped values and a status message to indicate the result of the operation. For the CWIX2015 exercise, the mapped values as specified by the eMoU agreement will be stored in and read from a database.

Email Border PEP For the CWIX2015 exercise, the bPEP will be implemented as an SMTP proxy using a similar architecture as that of the Email PEP. Specifically, the bPEP will intercept an email message, decode the message to extract any attachments and apply security policy, asset level protection, security labelling and perform auditing on the assets. The result of this process will create a newly formatted email message that will be sent to the recipient national network. The information protection logic for the bPEP is different for messages that leave a national network as compared to the logic applied when a message is received at a national network for delivery to a user in that network. This is discussed in detail in Section 3.4.1 - Email.

IM Border PEP For the CWIX2015 exercise, the IM Border PEP will be implemented as an XMPP S2S proxy using a similar architecture as that of the national IM PEP. Specifically, the IM Border PEP will apply security policy, asset level protection, security labelling and perform auditing on the chat room content as it transitions between national networks. The information protection logic for the IM Border PEP is different for messages that leave a national network as compared to the logic applied when a message is received at a national network for delivery to a user in that network. This is discussed in detail in Section 3.4.2 - Instant Messaging.

SIMG PEP For the CWIX2015 exercise, the SIMG Server will be deployed and configured to supply SIMG information over HTTP based sessions. These SIMG records will include security metadata against which DCS-based information protection can be applied. These SIMG records will be made available to:

• SIMG Clients that can read and interpret GCCS XML records; and • NASA World Wind Viewer, a GIS application capable of displaying SIMG data.

Not only will the SIMG Server provide SIMG records for the national network, it will also be able to subscribe to SIMG sources from other nations.




At a national level, consumers of SIMG information will access this data source through a SIMG PEP that will restrict the user’s view to only those records for which the user has a policy right to see.

SIMG Border PEP Between nations, the SIMG sources will traverse border PEPs at the originating and receiving nations. When a nation requests a data feed from another nation, the remote SIMG border PEP will perform the following actions for each SIMG data record.

1. Validate that the requesting nation is on the list of nations in the releasability attribute of the security label on the SIMG data record;

2. Consult the SLES to equate the values on the security label to their equivalents

for the requesting nation;

3. Secure the SIMG data using the public key certificate that was manually exchanged between the two nations; and

4. Send the SIMG data to the requesting nation.

At the local bPEP, the integrity of the SIMG record will be validated. The SIMG record will be appropriately labelled using the local security labelling scheme for structured data and the record will be delivered to the SIMG Server and relayed to the user community. Note that records that have been received by the local SIMG Server from remote SIMG sources will be subject to DCS protection since all records traverse the SIMG PEP as they are delivered to the local users. Since SIMG records that were generated locally and remotely now share the same security label format, syntax and semantics, the PEP is able to provide DCS protection for both types of SIMG data.




6. CWIX2015 Scenario Support The overall objective for CWIX2015 is to demonstrate how DCS can be extended to support cross-coalition information exchange. Specific objectives are outlined in Section 1.4 - CWIX2015. The CWIX scenario and test plan is documented in the CWIX 2015 Test Plan – Test Plan for a DCS Deployment in Support of Cross Coalition Information Exchange [Reference 1]. This section will attempt to summarize the CWIX2015 scenario support, and specifically the following:

• Testing Strategy; • Administrative Interfaces; and • Evidence Gathering.

6.1.1. Testing Strategy The testing strategy that will be adopted is multi-faceted. Specifically, it consists of the following testing components:

• Pre-Deployment Testing – These are a series of tests designed to ensure that the “system under test” is fully functional prior to deployment to the CWIX Test site;

• Preliminary Testing – The preliminary testing is basic functionality testing that will

need to be conducted at CWIX2015 prior to initiating the test cases. This testing consists of the following tests:

o A suite of single nation application level functional tests will be conducted

to ensure that each nation domain is operational;

o A series of simple domain to domain connectivity tests will be carried out to establish that the mesh network for the domains is operational and ready for the experiment;

• Test Cases – The CWIX2015 test cases will leverage predefined documents,

pre-provisioned testers, and pre-created IM chatrooms in order to minimize risk. The test cases are predicated on the following:

o Does the user have the policy right to create an email/IM/GCCS object

with the defined COI? o Does the user have the policy right to set the releasability on the object for

the receiving nation(s)? o Does the sending nation permit the asset to be released to the receiving

nation?




o Does each of the recipients have the policy right to receive this email/IM/GCCS object?

• Test Scenarios – The test scenarios are presented as two sets, the first set deals

with Email, IM, and SIMG functional testing within a single nation domain to ensure that the single domain solution is meeting the basic application level functional requirements. The second set deals with the nation to nation testing, which is focused on the sending and receiving boundary mechanisms.

6.1.2. Evidence Gathering The gathering of the test result data, as evidence, will be carried out using the Trusted Audit Service records, specifically the “Notes” field, this will be augmented by specific Information level log files obtained from the bPEP’s. Individual nation DCS records and logs will be automatically collected at the CDN (Ottawa) facility once a day.




7. References [Reference 1] CWIX2015 Test Plan – Test Plan for a DCS Deployment in Support

of Cross Coalition Information Exchange, Draft 2.0, 25 March 2015 [Reference 2] CWIX2015 Trial Report, July 2015 [Reference 3] SD003 CWIX2014 Test Report, July 2015 [Reference 4] SD006 CWIX2014 Trial Report, Bell Canada, July 2014 [Reference 5] Confidentiality Labelling and Binding for Joint Coalition Information

Sharing, Edition A Version 1, NATO Standardization Agency, September 2014.

[Reference 6] CWIX2015 Exercise Summary Report, July 2015.

DOCUMENT CONTROL DATA *Security markings for the title, authors, abstract and keywords must be entered when the document is sensitive

1. ORIGINATOR (Name and address of the organization preparing the document. A DRDC Centre sponsoring a contractor's report, or tasking agency, is entered in Section 8.) Cord3 Innovations 206-900 Morrison Dr, Ottawa ON K2H 8K7

2a. SECURITY MARKING (Overall security marking of the document including special supplemental markings if applicable.)

CAN UNCLASSIFIED

2b. CONTROLLED GOODS

NON-CONTROLLED GOODS DMC A

3. TITLE (The document title and sub-title as indicated on the title page.) CWIX2015 System Architecture Document: CONOP and Reference Architecture for a DCS Deployment in Support of Cross Coalition Information Exchange

4. AUTHORS (Last name, followed by initials – ranks, titles, etc., not to be used) Henderson, G.; Magar, A.; MacAllister, J.; Srivastava, P.; Nordin, B.; Seguin, D.; Clason, A.

5. DATE OF PUBLICATION (Month and year of publication of document.) July 2015

6a. NO. OF PAGES (Total pages, including Annexes, excluding DCD, covering and verso pages.)

89

6b. NO. OF REFS (Total references cited.)

6 7. DOCUMENT CATEGORY (e.g., Scientific Report, Contract Report, Scientific Letter.)

Contract Report

8. SPONSORING CENTRE (The name and address of the department project office or laboratory sponsoring the research and development.) DRDC – Centre for Operational Research and Analysis Defence Research and Development Canada Carling Campus, 60 Moodie Drive, Building 7S.2 Ottawa, Ontario K1A 0K2 Canada

9a. PROJECT OR GRANT NO. (If appropriate, the applicable research and development project or grant number under which the document was written. Please specify whether project or grant.)

9b. CONTRACT NO. (If appropriate, the applicable number under which the document was written.)

W7714-08FE01

10a. DRDC PUBLICATION NUMBER (The official document number by which the document is identified by the originating activity. This number must be unique to this document.) DRDC-RDDC-2019-C256

10b. OTHER DOCUMENT NO(s). (Any other numbers which may be assigned this document either by the originator or by the sponsor.)

11a. FUTURE DISTRIBUTION WITHIN CANADA (Approval for further dissemination of the document. Security classification must also be considered.)

Public release

11b. FUTURE DISTRIBUTION OUTSIDE CANADA (Approval for further dissemination of the document. Security classification must also be considered.)

12. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Use semi-colon as a delimiter.)

Information Access Management and Protection

13. ABSTRACT/RÉSUMÉ (When available in the document, the French version of the abstract must be included here.)

Data-Centric Security Service (DCSS) is a security overlay: a set of interconnected services that communicate through the exchange of messages on top of an existing network deployment. Any network security or application security based environment can be enabled for data-centric protection without the need to remove or de-emphasize existing security protections. In this way, an environment protected by DCSS retains the existing safeguards that were in place prior to the deployment of the security overlay. Additionally, DCSS itself is able to leverage existing physical, administrative, network and application safeguards as part of its deployment profile. Most significantly, the deployment of DCSS does not change the underlying accreditation of the target network by modifying the security architecture that was initially certified. This document provides information in support of the Canadian DCSS program participation at the Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise (CWIX) to be held in June 2015. At this experiment, the DCSS program team will be delivering new capabilities that build upon and extend the Data-Centric Security (DCS) information protection model. Specifically, these extensions will enable the exchange of information assets between national partners in a coalition environment in a manner that adheres to the principles of a DCS-based information protection architecture. These principles include: 1. The ability to apply national and cross coalition information handling policy decisions to individual

assets; 2. The ability to ensure that information assets are not released to requesting users or nations

unless explicitly permitted by the national security policy; and 3. The ability to record the application of security policy decisions in a trusted and tamper-resistant

audit store in support of incident analysis and forensic investigation. This document describes the required enhancements and extensions to the current DCS information protection model that will support cross coalition information sharing and that will be demonstrated at the CWIX2015 experiment. In addition, this cross coalition capability is intended to achieve the following objectives: 1. To prove the viability of the DCS cross coalition trust model and information exchange framework

as proposed in this document; 2. To validate the over-arching design decisions that form the core of the DCS cross coalition

information exchange functional model; 3. To observe the behaviour of the solution in an operational context with respect to:


4. To observe the proposed solution from a functional perspective and assess the degree to which application support, information exchange and integration with established processes can be done seamlessly and transparently;

5. To gather evidence to justify further exploration, examination and evaluation of a DCS cross coalition model; and


VWHP A KLWHFWX D FXPHQPrateek S Brent Nord Dan Segu Alan Claso Cord3 Inn Prepared Cord3 Inn 206-900...

Documents

Transcript of VWHP A KLWHFWX D FXPHQPrateek S Brent Nord Dan Segu Alan Claso Cord3 Inn Prepared Cord3 Inn 206-900...