Technical Interoperability in a Data Centric Environment ... · Prateek Srivastava . Cord3...

Defence Research and Development Canada Contract Report DRDC-RDDC-2019-C251 October 2019

CAN UNCLASSIFIED

CAN UNCLASSIFIED

Technical Interoperability in a Data Centric Environment (TIDCE) CWIX 2017 Experiment

Experiment Summary Report

Glen Henderson Alan Clason Will Coxon Brent Nordin Prateek Srivastava Cord3 Innovation Prepared by: Cord3 Innovation 900 Morrison Drive Suite 206 Ottawa, Ontario K2H 8K7 Project Manager: Will Coxon PSPC Contract Number: W7714-08FE01 Technical Authority: Daniel Charlebois, Defence Scientist Contractor's date of publication: July 2017

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

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

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.

Technical Interoperability in a Data Centric Environment (TIDCE)

CWIX 2017 Experiment




July 26, 2017 Bell Canada / Cord3 Innovation Page ii of vi

Bell Canada

160 Elgin Street

17th Floor Ottawa, Ontario

K1S 5N4

Cord3 Innovation

900 Morrison Drive

Suite 206

Ottawa, Ontario

K2H 8K7

Prepared by: Cord3 Innovation

Date: July 26, 2017

Revision: Final 1.1

Confidentiality This document is UNCLASSIFIED.

Disclaimer

This report is the contract deliverable POST CWIX Experiment Summary (task 6.2) for the task authorization call up TA-92 – CWIX 2017 Deployment. This task authorization is within the scope of the main contract W87714-08FE01/BEL. Content for this report has been prepared by the following participants of the CWIX2017 Execution Team.

CWIX2017 Execution Team

CWIX2017 Team Role



July 26, 2017 Bell Canada / Cord3 Innovation Page iii of vi

Glen Henderson Lead System Architect

Alan Clason Quality Assurance Specialist

Will Coxon Project Manager

Brent Nordin Senior Programmer

Prateek Srivastava IT Security Architect

Revision Control

Revision Date Modifications

1.02 July 14, 2017 Initial Draft

1.1 July 26, 2017 Updated Final to address review comments



July 26, 2017 Bell Canada / Cord3 Innovation Page iv of vi

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

1.1 DCS INFORMATION PROTECTION MODEL PRINCIPLES ................................................... 3

1.2 DOCUMENT PURPOSE .......................................................................................................... 6

1.3 DOCUMENT AUDIENCE ........................................................................................................ 8

1.4 ASSUMPTIONS AND DEFINITIONS ..................................................................................... 8

1.5 DOCUMENT OUTLINE ......................................................................................................... 10

2.0 CWIX2017 GOALS AND OBJECTIVES ........................................................... 12

2.1 CWIX2017 TECHNOLOGY EXPERIMENT GOALS ........................................................... 14

2.1.1 Black Box Testing with NATO partners ........................................................ 17

2.1.2 Shareable Assets Based on 4774/4778 STANAGs .................................. 19

2.1.3 Information Sharing Agreement Extensions ............................................. 19

2.2 CWIX2017 TECHNOLOGY CAPABILITY SPECIFICATION .............................................. 21

2.2.1 Native MAPI Proxy Intercept ........................................................................... 21

2.2.2 Cross Coalition Policy Enforcement .............................................................. 23

2.2.3 Security Attribute Value Domains ................................................................. 24

2.2.4 Binding of Assets Exchanged with Coalition Partners ........................... 26

2.2.5 DCA-based Auditing of Policy Decisions...................................................... 27

2.3 TECHNICAL TO PROGRAMMATIC TEST OBJECTIVE COVERAGE ..................................... 28

3.0 CWIX2017 SYSTEM COMPONENTS ................................................................ 30

3.1 SECURITY SERVICE TECHNOLOGY TARGET .................................................................... 32

3.1.1 Policy Decision Logic and Supporting Functions ...................................... 32

3.1.2 Cryptographic and Keying Services .............................................................. 35

3.1.3 Security Label Equivalency Service .............................................................. 36

3.1.4 Trusted Audit Service ......................................................................................... 37

3.1.5 Service Integration Point .................................................................................. 39



July 26, 2017 Bell Canada / Cord3 Innovation Page v of vi

3.2 APPLICATION INTEGRATION TECHNOLOGY TARGET ...................................................... 40

3.2.1 Asset Labelling at the Endpoint ...................................................................... 40

3.2.2 MAPI Proxy Intercept ......................................................................................... 41

3.2.3 SMTP Proxy Intercept ........................................................................................ 43

3.3 MANAGEMENT SERVICE TECHNOLOGY TARGET ............................................................. 45

4.0 EXPERIMENT CONFIGURATION AND EXECUTION .................................. 47

4.1 EXPERIMENT DEPLOYMENT AND CONFIGURATION STRATEGY ...................................... 47

4.2 INTEGRATION AND CONNECTIVITY STRATEGY ............................................................... 50

4.3 OPERATIONAL TESTING STRATEGY ................................................................................. 52

4.3.1 White Box Testing Strategy ............................................................................. 52

4.3.2 Black Box Testing Strategy .............................................................................. 55

5.0 TESTING METHODOLOGY AND RESULTS .................................................... 60

5.1 TESTING OBJECTIVES AND SCENARIOS.......................................................................... 60

5.1.1 White Box Testing Scenarios ........................................................................... 60

5.1.2 Black Box Test Scenarios .................................................................................. 62

5.2 TEST SESSIONS WITH PARTNERS.................................................................................... 65

5.2.1 White Box Testing with the US SPAWAR Team ....................................... 65

5.2.2 Black Box Testing with the NCIA Team....................................................... 65

5.2.3 Black Box Variation with the Italian Team (ITA) ..................................... 65

5.2.4 Black Box Variation with the Netherlands (NLD) Team ........................ 66

5.3 CWIX2017 TESTING RESULT SUMMARY ...................................................................... 67

5.4 SUMMARY OF CWIX2017 EXERCISE ............................................................................. 68

5.4.1 Observations Relating to the DCA Programmatic Goals ....................... 69

5.4.2 Observations Relating to the Interoperability Issues ............................ 70

5.4.3 Technology and Implementation Issues ..................................................... 71

6.0 LESSONS LEARNED .............................................................................................. 72

6.1 RECOMMENDED NEXT STEPS ........................................................................................... 73



July 26, 2017 Bell Canada / Cord3 Innovation Page vi of vi

List of Figures and Tables

Figure 1: Traceability from High Level Objectives to CWIX2017 Demonstrator .................................. 12

Figure 2: Testing Scenario Configurations ............................................................................................ 18

Figure 3: CWIX2017 Technology Objectives ......................................................................................... 21

Figure 4: CWIX2017 DCS Component Diagram .................................................................................... 31

Figure 5: Policy Enforcement in the Canadian DCS Approach ............................................................. 33

Figure 6: Sample DCA Audit Record ..................................................................................................... 38

Figure 7: National and Border PEPs ...................................................................................................... 42

Figure 8: Sample DCS Test Network Environment ............................................................................... 48

Figure 9: Deployed DCS Test Environments ......................................................................................... 50

Figure 10: eISA Creation and Exchange ................................................................................................ 53

Figure 11: Email Exchange using eISAs ................................................................................................. 55

Figure 12: Testing with Black Box Environments ................................................................................. 56

Figure 13: Black Box Testing eISA Creation .......................................................................................... 57

Figure 14: Email Exchange to non-DCA Partners .................................................................................. 58

Table 1: Mapping of Experiment Goals to Experiment Capability Target ............................................ 15

Table 2: Mapping Experiment Capability Target to Technology Capability ......................................... 28

Table 3: White Box Test Scenario to Technology Capability Coverage ................................................ 61

Table 4: Black Box Test Scenario to Technology Capability Coverage ................................................. 64



July 26, 2017 Bell Canada / Cord3 Innovation Page 1 of 75

1.0 Introduction

In June 2017, the Canadian Department of National Defence (DND) participated in the Coalition Warrior Interoperability eXploration, eXperimentation and eXamination (CWIX2017) exercise. This exercise was hosted at the Joint Forces Training Facility (JFTC) in Bydgoszcz, Poland in cooperation with coalition testing partners.

The decision to participate at this exercise was, as stated in the TIDCE Experiment Campaign Plan, to mature the technical interoperability for information sharing and safeguarding in a Data Centric Environment (DCE). Additionally, it was expected that participation at CWIX2017 would refine technical interoperability understanding through testing and demonstration with coalition partners.

The TIDCE Experiment Campaign Plan defined three overarching objectives for validation and demonstration at exercise venues, including CWIX2017, to address the following aspects of the technical interoperability capability:

1. Security Overlay: The implementation of a data centric security system as an overlay transparent to the existing IT infrastructure of applications, data services and security safeguards;

2. Information Sharing: The application of policy-based authorization on information exchanges with coalition partners to ensure that transactions comply with the overarching security policy and information sharing agreements; and

3. Information Safeguarding: The application of data centric information protection principles to information assets in a multi-caveats environment.

The TIDCE objectives were aligned with the CWIX2017 Data Centric Architecture (DCA) Focus Area (FA) objectives for testing, experimentation and validation.

1. To explore a dynamic data centric information sharing environment using the results of TIDE SPRINT 2/16 DCI workshop and provide feedback to the TIDCE community of interest. This DCA FA objective advanced all the TIDCE objectives in that:




• the solution deployed at CWIX2017 was based on a design that integrated with the

existing IT infrastructure as a security overlay;

• the testing scenarios and the deployed capability supported the exchange of information assets with coalition partners in a DCE context; and

• the solution deployed at CWIX2017 protected assets within partners’ information management domains according to data centric information protection principles.

2. To experiment using the current NATO standards for Email with the following standards

applied to assets exchanged between coalition partner information management domains:

• STANAG 4774 which defines the confidentiality label syntax for expressing security metadata; and

• STANAG 4778 which species how confidentiality labels are bound to information assets.

This DCA FA objective directly supported the TIDCE objective to mature the policy-based sharing of information. This objective was relevant for all scenarios involving the exchange of information assets between partners. CWIX2017 was also seen as a forum whereby these emerging NATO standards for information exchange and interoperability could be verified, validated and tested in a multi-partner coalition environment.

These standards were used in conjunction with documented NATO profiles that specify how these standards should be applied to information asset types and how cryptographic binding mechanisms should be used to provide integrity in the data to metadata associations. For CWIX2017, the expectation was that many NATO partners would be deploying their respective DCA implementations in accordance with these emerging standards and that the degree to which these standards enabled coalition interoperability could be evaluated.

3. To examine capability and service testing in other focus areas using STANAG 4774 and

STANAG 4778 and provide feedback to the custodian. This DCA FA objective directly supported the TIDCE objective to enable the policy-based sharing of information was relevant for all scenarios involving the exchange of information assets with partners.




From these CWIX2017 DCA FA experimentation objectives, specific technology experiment goals and testing objectives were developed which formed the basis for all testing scenarios performed with partners at the exercise.

For the Canadian CWIX2017 participation, new and enhanced software components supporting these standards were added to the Canadian Data Centric Services (DCS) solution and used during the exercise. However, the principles under which the DCA information protection and information sharing models were created remained the primary design influences for the development of these new capabilities, as described in the following section.

1.1 DCS Information Protection Model Principles

The TIDCE experimentation objectives call for the safeguarding of information assets to ensure that information is only made available to individuals that have the explicit policy right to do so. In a DCS environment, the information protection model that must be applied to ensure that this level of safeguarding is in place is based upon the following principles. These principles are documented and expanded upon in the SAMSON High Level Design Document.

1. All transactions against information assets (e.g. asset creation, access, sharing) are only performed when those transactions are in compliance with the information management domain’s security policy. Policies may be defined at a high level (i.e. a national policy) but may also include local policy rules (i.e. at a departmental level).

2. Policy decisions are made based on the policy-relevant security attributes of the user, the information asset, the action being performed against the asset and the environment under which the transaction is made. The set of what constitutes policy-relevant security attributes is defined by the overarching security policy itself.

3. From a policy decision standpoint, all information assets are indistinguishable except for their policy relevant security attributes. From a DCS perspective a file, an email and a chat session that share the same set of security attributed are all handled the same way. They are subject to the same policy enforcement, protected using the same mechanisms and audited with the same information.




4. All policy decisions are audited to include a full set of details about the transaction, the security attributes that were involved in the policy decision, and the policy decision itself.

5. Under the protection of the DCS information protection services all information assets are encrypted and will only be disclosed to requesting users if that action is in compliance with the overarching security policy.

These DCA information protection principles were used in conjunction with an emerging model to enable the sharing of information assets between coalition partners. Whereas the principles defined above were appropriate for a single (e.g. national) information management domain, when applied to a coalition information sharing context, this emerging model was needed to ensure that information assets are both disclosed and processed appropriately by all participants in the exchange. An updated version of the Canadian DCS security overlay that supports this emerging model was deployed in the DCA FA at CWIX2017.

Under this new DCA information sharing model, nations were individually responsible for maintaining and managing the protection of information assets within their own domains. When sharing information assets with other nations, however, users were required to have the explicit policy right to do so and only those assets that could be shared with partners were allowed to be exchanged with those partner nations.

This approach requires the modelling, expression and processing of electronic Information Sharing Agreements (eISAs). An eISA is the digital representation of an agreement to share information between partners and, for the purposes of CWIX2017, is defined by the following characteristics:

• an eISA is represented by a unique identifier;

• an eISA can be associated with an information asset, which indicates that this asset must be handled or processed according to the rules that define that eISA;

• many assets can be associated with an eISA but an asset cannot be associated with more than one eISA;




• an eISA is created for a specific purpose, specifically, to encode the reason (or context) for which the set of assets associated with this eISA need to be shared;

• the eISA identifier must be included in the security metadata encoded on an asset’s confidentiality label; and

• an eISA reflects the following information:

o it includes a set of classifications that can be used with this eISA;

o it includes the set of caveats that can be used with this eISA;

o it includes the set of nations that are participants in the information sharing agreement.

This DCA information sharing model has natural linkages to the existing DCA information protection model in that:

• An eISA can be represented in a STANAG 4774 compliant confidentiality label;

• An eISA represents a set of security attributes that can be part of the policy decision made on transactions against information assets; and

• The use of an eISA can be represented in an audit subsystem component of a DCA implementation to record the creation and release of information assets.




Of significant note, this DCA information sharing model does not require that all coalition partners to use the agreed upon security attribute values encoded in the eISA within their respective domains. In supporting this model, each nation is only required to:

1. Use the agreed upon/negotiated security attribute values when placing confidentiality labels on assets that are to be exchanged with partner nations; and

2. Use semantically equivalent values within their national domains.

Semantically equivalent, in this context, means that the national and coalition security attribute values must be interpreted as requiring the same level of protection, such as having the same level of sensitivity and being restricted to a community with the same need to know.

1.2 Document Purpose

This document is intended to summarize CWIX2017 experiment activities. It provides the following information:

• A statement of the specific technology objectives that:

o Were established from the TIDCE Campaign Pan and CWIX2017 DCA FA objectives; and

o Formed the basis for establishing the CWIX2017 technology target;

• A summary of the CWIX2017 technology target; that is, the set of design, implementation and deployment targets that encapsulated the technology capabilities that was deployed at the experiment;

• A review of the evaluation and testing methodology that was applied during the exercise;




• A summary of the observations and results from the exercise; and

• A statement of the technical, programmatic and operational lessons learned from participation in this exercise.

Additionally, this document provides a linkage between the technology target and the CWIX2017 exercise test methodology, testing activities and scenario development documentation. Specifically, the two primary documents that present the findings from the CWIX2017 exercise are:

1. The CWIX2017 Execution Summary Report that defines the objectives, technology target and execution deployment (this document); and

2. The CWIX2017 Test Report that fully documents the results and observations from the exercise.

Additionally, beneficial background information for the capability deployed at the exercise can be obtained from:

3. The Capability Architecture Document that provides a more comprehensive description of the technology target, the new capabilities and technology rationale that justifies approach taken for the confederation of trust model to be used at all engineering exercises to be held in 2017 and 2018.

4. The Consolidated Development Plan that identifies the high-level development strategies, technology objectives and development timeframes for all engineering exercises to be held in 2017 and 2018.

5. The Secure Access Management for Single Operational Network (SAMSON) High Level Design which provides background material on the design and information management principles regarding data centric architectures.




It is also recommended the security practitioners reading this document be aware of the content described in STANAG 4774, STANAG 4778 and their supporting NATO profiles.

1.3 Document Audience

The intended audience for this document includes security practitioners that have an interest in understanding how the Canadian DCS solution was deployed in an operational context. The audience may also include those practitioners that have an interest in building or evaluating implementations of the DCA information protection model and the approach taken to enable information sharing in a coalition setting. In support of these investigations, this document provides:

1. A description of the CWIX2017 technology target that was used to prove the viability of DCA information sharing model in support of cross coalition information exchanges; and

2. An understanding of the scope and testing methodology applied to the DCA participation at CWIX2017, including the relevant observations and results from the exercise evaluation.

1.4 Assumptions and Definitions

1. The term ‘domain’ has multiple meanings in this document, depending on context.

a. A national domain refers to all the IT infrastructure, networks and IM policies that belong to a specific national partner.

b. A network domain is the set of machines that are part of the same network and use the same network name to identify themselves in the network. A network domain is usually complemented with an email domain name.




c. A national network is a network domain that is part of a nation’s national domain (e.g. usadca.cwix.usa is a US national network and email messages could be sent to a user at that address).

d. An information management domain is the set of IM policies and security services that are part of a common DCS configuration (i.e. the same policies and cryptographic keying mechanisms).

e. A Windows domain is the set of IT resources that are under the management of a Windows Domain controller and Active Directory installation.

f. When used by itself, domain refers to a national domain.

2. For CWIX2017, there was a one-to-one correspondence between a national domain and a national network. For example, the USA domain was hosted on the dcausa.cwix.usa national network.

3. Where appropriate for the testing methodology, testing partners were provided by the Canadian CWIX2017 exercise team with access to separate national domain from which they could execute their test procedures.

4. From either their own national domain or one that they were granted access to use, partners were able to perform coalition information sharing with all other partners. Email with attachments was the application of choice for the CWIX2017 DCA experiment.

5. Each national domain used the STANAG 4774 confidentiality label syntax to express security attributes on their email and file attachment assets and STANAG 4778 for binding of confidentiality labels to those information assets.

6. Minimal security hardening was performed against the CWIX2017 DCS solution deployment. It is expected that hardening and red-teaming evaluation will be addressed in subsequent exercises.




7. Additional Handling Instructions is a term to indicate additional security tags on an information asset and can be used to restrict the dissemination of that asset according to the local security policy. Historically on this project, these tags have been referred to as caveats and caveat-level separation. In this document, the terms caveats and additional handling instructions are used interchangeably.

1.5 Document Outline

This document is structured into the following sections:

• Section 2.0 : CWIX2017 Goals and Objectives provides a high-level summary of the intended goals and objectives for the CWIX2017 experiment.

• Section 3.0 : CWIX2017 System Components provides a general description of the new or extended capabilities that were deployed as part of this exercise; this information is provided in greater detail in the CWIX2017 System Architecture Document.

• Section 4.0 : Experiment Configuration and Execution describes the experiment configuration, including:

o The packaging, delivery and installation methodology,

o The means by which the DCS capability was integrated with the NATO infrastructure and partner networks,

o How cross-coalition information exchange was enabled for testing and demonstration purposes, and

o The management of security metadata, including:




confidentiality labels,

binding of security metadata to information assets

information sharing agreements,

security policies,

confidentiality label mapping between domains; and

auditing of transactions.

• Section 5.0:Testing Methodology and Results summarizes the testing methodology, testing results and identifies the significant observations with respect to:

o The execution details of the CWIX2017 experiment itself;

o The integration effort to enable DCS capabilities for participating partners; and

o Defects pertaining to the solution design, implementation, delivery and integration.

• Section 6.0 : Lessons Learned provides a comprehensive discussion of what was learned from the CWIX2017 experiment with the goal of validating the approach and improving the experience for participation in future coalition experiments.




2.0 CWIX2017 Goals and Objectives

This section describes the experiment and technology goals for Canadian participation at the CWIX2017 exercise. From the high level TIDCE Experiment Campaign Plan objectives, it is possible to trace the development of the more specific technology goals and capability targets to arrive at the deployed capability at the CWIX2017 experiment. This flow from high-level campaign plan objectives to the technology demonstrator that was deployed at CWIX2017 is shown in Figure 1: Traceability from High Level Objectives to CWIX2017 Demonstrator.

Figure 1: Traceability from High Level Objectives to CWIX2017 Demonstrator

This section presents the following new concepts for exercise execution, validation and assessment that support the overarching TIDCE Experiment Campaign Plan and CWIX2017 DCA FA objectives.

Supporting the CWIX2017 DCA Focus Area objectives, the Technology Experiment Goals define the factors that determine what new technology capabilities would be needed to create the Canadian DCS solution that could support the demonstration, testing and validation activities at CWIX2017.

The Technology Capability bridges between the programmatic objectives and the deployed DCS implementation. It is comprised of two aspects:

• the Experiment Capability Target which is a high-level expression of the required capabilities that are needed for the demonstrator in support of the objectives; and

• the Technology Capability Target which is a set of technology requirements and design factors that support the development of a solution that can meet the experiment capability target.

The technology capability is a more technical description of the target solution to be deployed at CWIX2017 and can be used to highlight the required changes to the existing Canadian DCS solution.




The Technology Experiment Demonstrator is the deployed capability brought to the CWIX2017 exercise that includes all the changes defined by the technology capability.




2.1 CWIX2017 Technology Experiment Goals

The technology experiment goals for participation at CWIX2017 were established in order to support the overarching TIDCE and DCA FA objectives. The design, implementation and deployment of the CWIX2017 technology capability target were derived from and support these technology experiment goals. In this way, the technology experiment goals link and show traceability between the high-level TIDCE campaign plan objectives and the solution that was deployed at the experiment. These technology experiment goals are:

1. To continue the extension, refinement and maturation of the DCA information protection model (supports TIDCE objective 1 and DCA FA objective 1)

2. To extend the use of the DCA information protection model and its implementation as a mechanism to support cross-coalition information exchange. (supports TIDCE objective 2 and DCA FA objective 2)

3. To support the maturation of developing standards in the areas of confidentiality labeling and metadata binding through the application and of use of these standards in a cross-coalition information exchange environment. (supports DCA FA objective 2)

4. To identify and provide input into the requirements for new security standards in support of cross-coalition information exchange. (supports TIDCE objective 2 and DCA FA objective 2)

5. To close any technology gaps that have been identified in prior experiments and address any perceived defects, limitations or inaccuracies in the overarching DCA information sharing model. (supports TIDCE objective 3 and DCA FA objective 1)

6. To advance the progress toward an operational deployment of DCA information protection and information sharing model implementation through the demonstration of this capability in controlled exercise experiments. (supports TIDCE objective 1 and 3 and DCA FA objective 1)




From these technology experiment goals, it was possible to derive specific technology capability targets for CWIX2017. These technology targets, in this context, are a high-level expression of the new capabilities that were required for the experiment in order to support the experiment goals and campaign plan objectives. Table 1: Mapping of Experiment Goals to Experiment Capability Target shows the traceability between the test objectives and the programmatic goals (Full or partial).

Table 1: Mapping of Experiment Goals to Experiment Capability Target

Experiment Capability Target

Experiment

Goal

Black Box Testing with NATO Partners

(ECT1)

Enhanced

interoperability with NATO partners using the STANAGs (ECT2)

Improvements to information sharing using eISAs (ECT3)

Maturing the DCA model (EG1)

Fully Relevant Fully Relevant Fully Relevant

Extended support for information

exchange (EG2)

Partially Relevant:

DCA only used on one side of exchange

Fully Relevant Fully Relevant

Maturing standards for information exchange (EG3)

Fully Relevant Fully Relevant Partially Relevant:

More input from partners needed

Identify need for new standards (EG4)

N/A

Partially Relevant:


Fully Relevant

Close any DCA technology gaps (EG5)

Fully Relevant Partially Relevant:


Partially Relevant:


Further progress towards operational deployment (EG6)

Fully Relevant Partially Relevant:


Partially Relevant:





A more detailed discussion of the three technology capability targets is presented in the following sections.




2.1.1 Black Box Testing with NATO partners

A significant technology objective for CWIX2017 was to engage in testing with partners in a manner that used the interoperability standards, specifically STANAG 4774 and STANAG 4778, in their proper role of enabling information exchanges. This technology objective supports:

• Validating and demonstrating DCS-based information sharing (TIDCE objective 2);

• Experimentation using the current NATO standards (DCA FA objective 2); and

• Capability and service testing with other focus areas (DCA FA objective 3).

In prior experiments, the Canadian DCS solution was tested using a white box testing method where the DCA focus area, with Canada as lead, supplied its DCS security overlay to all testing partners (as shown in the left-hand side of Figure 2: Testing Scenario Configurations). While in early stages of DCS model validation this testing helped to prove the DCS concept and educate partners on the DCS information protection model, it did not further the goal of demonstrating interoperability.

With interoperability test procedures performed using the same DCS implementation in both national domains, there was minimal information gained about any potential errors in the proposed standards, the ambiguity of their specification or interoperability issues that might arise from independent interpretations of the standards.

Black box testing was meant to address this concern. In black box testing, shown in the right-hand side of Figure 2: Testing Scenario Configurations, each partner was to supply their own DCA implementation or minimally their own subcomponents capable of generating, interpreting and validating STANAG 4774/4778 compliant labelled information assets. In this testing configuration, no software was to be exchanged between partners, only standards-compliant information assets with properly labelled and bound confidentiality labels.




Figure 2: Testing Scenario Configurations

Given the benefit of this testing configuration for the advancement of the DCS-based information sharing model and the standards with which it is implemented, a preference was shown for black box testing with partners at CWIX2017. However, a white box testing option was made available to those NATO testing partners that did not yet have a DCA implementation capable of undertaking black box testing at CWIX2017.




2.1.2 Shareable Assets Based on 4774/4778 STANAGs

Given the emphasis on interoperability testing, the Canadian DCS solution was to demonstrate a more comprehensive use of STANAG 4774 for the expression of confidentiality labels and STANAG 4778 associations with appropriate profiles used to bind those labels to information assets. This technology objective supports:

• Experimentation using the current NATO standards, including the STANAGs (DCA FA objective 2); and

• Capability and service testing with other focus areas through interoperability testing using standards-based labelled assets (DCA FA objective 3).

An objective for CWIX2017 was to be prepared for a broadly scoped black box testing target where a range of cryptographic binding mechanisms was available for testing with partners. Those cryptographic binding mechanisms included: loose binding, HMAC based signatures and signatures based on X509 certificates.

2.1.3 Information Sharing Agreement Extensions

An objective for CWIX2017 was to improve upon the data model used to express eISAs in order to:

• Clarify the distinction between Security Policy Information Files (SPIFs) and eISAs;

• Simplify the process of generating eISAs; and

• Normalize the process by which security attributes are mapped between their local and coalition forms.

The DCS administration Graphical User Interface (GUI), which was introduced at CWIX2016, was to be maintained as the tool through which eISAs were created, managed and shared.




Improvement and refinement in the way eISAs are used to facilitate information sharing between coalition partners is a key component of the TIDCE campaign plan (objective 2) and the DCA FA objectives.




2.2 CWIX2017 Technology Capability Specification

This section describes the new or expanded capabilities that were deployed at the CWIX2017 exercise. These technology capabilities support the technology programmatic goals, which in turn support the overarching TIDCE and DCA FA objectives, as shown in Figure 1: Traceability from High Level Objectives to CWIX2017 Demonstrator.

Figure 3: CWIX2017 Technology Objectives identifies the new capabilities that were needed to extend the Canadian DCS solution in order to meet the technology programmatic goals for the CWIX2017 exercise.

Figure 3: CWIX2017 Technology Objectives

Each new capability or service extension is described in the following sections.

2.2.1 Native MAPI Proxy Intercept




In defining the needed technical capabilities that would meet the experimental, focus area and campaign objectives, the following requirements were identified for the endpoint, application and data service protocols. The requirements were defined in terms of:

1. Support for the native Outlook / Exchange protocol (i.e. MAPI).

2. Support for the DCA protection and policy enforcement of email message body and file attachments.

3. Support for the DCA protection of file objects sent as attachments as:

a. Embedded label objects (Office documents); and

b. Encapsulated label objects (e.g. graphics image files).

4. Application of DCA protection on email information objects both:

a. At the intra-nation level between the national users and the national email server; and

b. At the inter-nation level prior to the ingress or egress of email assets at the nation’s network perimeter.

5. Desktop confidentiality labelling of email messages, including:

a. Email message body;

b. Office documents; and

c. Generic file objects.

6. Support for the following software:

a. Desktop operating system: Windows7,




b. Microsoft Office suite: Office 2010,

c. Server operating system: Windows Server 2008, and

d. Exchange server: Exchange 2010.

Note that the target software selection was made to align the CWIX2017 exercise with other exercises to be conducted in 2017 and 2018.

2.2.2 Cross Coalition Policy Enforcement

Unlike CWIX2016, where the decision to release information assets was made at the nation’s network boundary, all policy decisions related to email activities were to be made by the national (local) protection services at time of creation. This means that the policy decision to permit the release of information assets to partner was made and enforced as the asset was submitted the local email service. From both a design and process flow perspective, policy decisions should be made as close to the end user as possible in order to provide immediate feedback when an action is not permitted due to policy conflicts and to minimize the creation of information assets that must be handled as exceptions later in the information handling process. For the experiment’s targeted application (Email) it is preferred to prevent invalid email messages from being sent in the first place rather than stopping these messages at the national border.

The submission of an email message was rejected if:

• the sender did not have the policy right to create the email;

• any of the local recipients did not have the policy right to receive the email; and

• the email was destined for a partner that was not part of the information sharing agreement (eISA) reflected in the email’s security attributes.




Based on this policy logic, it was required that all information assets include in their security attributes a reference to the eISA under which it was created. It is important to note that the policy decisions made on the information asset included both the security attributes on the email body and the security attributes on each of the files attached to that email message.

2.2.3 Security Attribute Value Domains

Following the design of prior implementations of the DCA information sharing model, an information asset is transformed at the national border:

• Converting local security attribute values to their coalition equivalents on egress; and

• Converting coalition security attribute values to their local equivalents on ingress.

In prior implementations, these security attribute equivalents were defined as part of the eISA. For CWIX2017, this data modelling approach was to be extended to manage value domains and eISAs as separate concepts.

A value domain is a defined set of security elements and attributes that can be used to define an eISA and, subsequently, be used to express the contents in a STANAG 4774 confidentiality label on an information asset. That is:

• A value domain can be thought of as a dictionary that defines all the valid security attributes that can be used within an information management domain;

• An eISA uses a subset of the value domain to express a set of security attributes that can be used in a certain context (the reason for the sharing agreement); and

• A confidentiality label uses a subset of the eISA to assign specific security attributes to an information asset.

For CWIX2017, the set of security elements that needed to be included in a value domain were:




• an ordered set of valid classifications,

• a set of additional sensitivities (caveats) and

• a list of nations that could be used to express the releasability of the asset.

An organization can have multiple value domains in use at a given time but an eISA can only be derived from a single value domain.

In a DCE, the rules that dictate what can be placed in a confidentiality label is known as the data labelling policy. Part of the data labelling policy is the value domain, that is, the set of allowable security attribute values that can be used when expressing a confidentiality label.

An organization can have many value domains active and available for use at a given time (e.g. national policies, department specific policies, etc.).

A value domain can also be used to express external security attributes that reflect a set of security attributes that have been agreed upon for the exchange of assets in a coalition environment. When expressing a value domain, the set of attributes and elements can be viewed as having a morphology: a defined set of elements and ordered set of values in each element. Where two value domains have the same morphology, it is possible to transform a confidentiality label based on one value domain to another.

In the DCA information sharing model, an eISA must specify two value domains: the local value domain and the coalition value domain. When acting on the asset at the border, the eISA dictates the transformation of security values in the confidentiality label from one value domain to the other. For example, when an asset is leaving the local domain, the eISA is used to turn the local confidentiality label on the asset into an equivalent coalition confidentiality label.

This separation of the management of value domains (data labelling policies) and eISAs was made for several reasons:




1. In this approach, the responsibility for defining eISAs could be delegated down to lower privileged DCA administrators but the responsibility for managing security attributes and their equivalents is an issue of national concern and must remain a high privilege action.

2. Modelling per-attribute equivalents in an eISA results in a non-normalized data model.

3. It becomes possible for a nation to alter security mapping values without the need to alter existing eISAs.

2.2.4 Binding of Assets Exchanged with Coalition Partners

For black box testing, there was a strong requirement to use STANAG 4778 and its supporting profiles to exchange information assets with partner nations in order to gain experimental knowledge of the binding mechanisms to associated labels with asset and the cryptographic mechanisms to apply integrity to these associations.

As part of the experiment efforts, testing partners attempted to verify the cryptographic bindings between information assets and their label using the documented mechanisms provided as NATO profiles. Once the data to label associations were verified, it was expected that a partner would be able to extract the security attributes values from the confidentiality label on the asset. Similarly, the security attributes in the confidentiality label on information assets received from testing partners should be able to be verified and extracted.

These binding mechanism test procedures were expected to be performed on email messages using the SMTP binding profile and file attachments using the OOXML profile. Cryptographic bindings based on HMAC and X509 signatures were also expected to be able to be created and interpreted by testing partners.




2.2.5 DCA-based Auditing of Policy Decisions

In support of evidence collection, a DCA-based Audit Service was to be deployed as part of the Canadian DCS solution at CWIX2017. This service would collect:

• Transactional information: Information that identified the actual transaction being made against data (e.g. message ID for email, file name for file attachments);

• Policy Query information: all the relevant security attributes that were used to make the policy decision;

• Policy Response information: the decision rendered by the policy engine; and

• Audit meta-data: source modules, addresses, timestamps.

The audit data would be available for review through the administrative interface.




2.3 Technical to Programmatic Test Objective Coverage

As shown in Figure 1: Traceability from High Level Objectives to CWIX2017 Demonstrator, the TIDCE and CWIX2017 DCA FA objectives led to the selection of a set of technology programmatic goals. These goals, in turn, were used to select specific technology capabilities to be brought to, tested at and validated through the CWIX2017 experiment.

As a summary of the testing objectives, it is possible to map the technical objectives to the programmatic test objectives and identify the degree to which the technology target is advancing the DCA program goals. The following table, Table 2: Mapping Experiment Capability Target to Technology Capability, shows the traceability of the experiment goal to technology capability at the CWIX2017 experiment.

Table 2: Mapping Experiment Capability Target to Technology Capability

Experiment Capability Target

Technology Capability

Black Box Testing with NATO Partners

(ECT1)

Enhanced

interoperability with NATO partners using the STANAGs (ECT2)

Improvements to information sharing using eISAs (ECT3)

MAPI Proxy Intercept (TC1)

N/A Fully Relevant Partially Relevant: eISAs applied to MAPI transactions

Cross Coalition Policy Enforcement (TC2)

Partially Relevant: Only one side of the exchange


Security Attribute Value Domains

(TC3)

Partially Relevant: Only one side of the exchange


STANAG 4778 Label Binding (TC4)

Fully Relevant Fully Relevant Partially Relevant: eISAs not directly tied to binding




Auditing of DCA Operations (TC5)





3.0 CWIX2017 System Components

This section provides an overview of the new and extended system components that were introduced for CWIX2017 in support of the exercise’s TIDCE objectives, DCA FA objectives and experiment goals.

A more comprehensive description of these capabilities is provided in the CWIX2017 Capability Architecture Document.

Figure 4: CWIX2017 DCS Component Diagram provides an overarching view of each of the main DCA components, their role in the architecture and their interconnections.




Figure 4: CWIX2017 DCS Component Diagram

New and updated system components fall into one of three technology targets:

1. Security Service Technology Target;

2. Application Integration Technology Target; and

3. Management Service Technology Target.

Each of these technology targets is discussed below.




3.1 Security Service Technology Target

The security service technology target for CWIX2017 includes changes to the way policy decisions are made, how and when assets are protected and how transactions against data assets are audited.

3.1.1 Policy Decision Logic and Supporting Functions

As seen in Figure 4: CWIX2017 DCS Component Diagram, the policy decision logic and supporting functions are collocated within the orange service grouping and include the PDP, the assetPIP, and the userPIP. As described in section 2.2.2:Cross Coalition Policy Enforcement, policy decisions must be enforced on both:

• user actions that take place locally (that is, within a nation’s information management domain); and

• actions that involve users in another national domain.

For example, when sending an email to a user in another national domain (i.e. an external network):

1. the sending user must have the policy right to send the asset; and

2. the asset must be able to be released to the receiving domain.

It is part of the Canadian approach to DCS information sharing that partner nations are each trusted to handle sensitive information appropriately within the confines of the established eISA. As such, this model assumes that nations are responsible custodians of the shared information and will ensure that information assets are only disclosed to users that have a need-to-know.

In this model, therefore, there are two types of policy decisions that must be made:

1. A decision made for local users that enforces the local information management domain’s policy rules (a local decision); and

C WI X 2 0 1 7 E x p eri m e nt

E x p eri m e nt S u m m ar y R e p ort

J ul y 2 6, 2 0 1 7 B ell C a n a d a / C or d 3 I n n o v ati o n P a g e 3 3 of 7 5

2. A d e cisi o n m a d e t o r el e as e ass et s t o p art n er d o m ai ns t h at e ns ur e s t h at t h er e is a n eI S A i n

pl a c e t h at s u p p ort s t h e s h ari n g of t his i nf or m ati o n wit h t h at p art n er (a s h ari n g d e cisi o n) .

Fi g ur e 5 : P oli c y E nf or c e m e nt i n t h e C a n a di a n D C S A p pr o a c h

T hi s s c e n ari o is s h o w n i n Fi g ur e 5 : P oli c y E nf or c e m e nt i n t h e C a n a di a n D C S A p pr o a c h w h er e a s e n d er

is att e m pti n g t o s e n d a n e m ail t o b ot h a l o c al r e ci pi e nt a n d a r e m ot e r e ci pi e nt. At t h e p oli c y

e nf or c e m e nt p oi nt ( P E P), t hr e e s e p ar at e p oli c y c h e c ks ar e m a d e:

1. A c h e c k t o e ns ur e t h at t h e s e n d er h as t h e ri g ht t o s e n d t h e e m ail.

2. A c h e c k t o e ns ur e t h at t h e l o c al r e ci pi e nt c a n r e c ei v e t h e e m ail.

3. A c h e c k t o e ns ur e t h at t h e e m ail c a n b e r el e as e d t o t h e e xt er n al p art n er d o m ai n.

It is si g nifi c a nt t o n ot e t h at o n c e t h e e m ail h as p ass e d all p oli c y v erifi c ati o n c h e c ks at t h e n ati o n al

p oli c y e nf or c e m e nt p oi nt it is pr ot e ct e d w hil e i n st or a g e at t h e E x c h a n g e S er v er u ntil s u c h ti m e as

t h e m e ssa g e is d eli v er e d t o t h e i nt e n d e d r e ci pi e nt s.

A si n gl e tr a ns a cti o n a g ai nst d at a m a y i n v ol v e a n y n u m b er of l o c al a n d s h ari n g d e cisi o n s d e p e n di n g

o n t h e n u m b er of l o c al us ers, e xt er n al d o m ai n s a n d ass et s i n v ol v e d i n t h e tr a ns a cti o n.




Regardless of the type of policy decision being made, the same kind of information is collected and presented to the policy engine for a decision. All policy decision requests begin with the following information:

• Information about the target user: identity and network domain;

• Information about the asset: either a file asset filename or the confidentiality label extracted from the information asset; and

• Information about the transactional operation: (i.e. a ‘read’ or a ‘write’).

This information forms the basis for a policy decision request which is formulated by the PEP and submitted to a Policy Decision Point (PDP) that will vet the transaction against the overarching security policy. PEPs are discussed in more detail in section 3.2:Application Integration Technology Target but it suffices to describe a PEP as a logical amalgamation of:

1. An application proxy which intercepts the information asset exchanges between a user and a data service; and

2. A Service Integration Point (SIP) which draws upon DCS components to ensure that the asset is processed and protected in accordance with DCA principles.

The positioning of a PEP between the user and the data service is shown as the National Policy Enforcement Point (nPEP) in Figure 5: Policy Enforcement in the Canadian DCS Approach. For CWIX2017, the PEP deployment positioning followed a network architecture as shown in Figure 8: Sample DCS Test Network Environment.

This initial request is processed by a PEP which coordinates the calls to supporting services provided the Policy Information Points (PIPs), including:

1. The user policy information point (userPIP) service which obtains policy relevant information about the requesting user such as: clearance and group membership.




2. The asset policy information point (assetPIP) service which obtains policy relevant information about the asset and/or confidentiality label on the asset such as: the eISA under which the asset was created (known as the asset’s context), the asset’s classification, and any additional sensitivity values (caveats).

This complete set of security attributes is used in the policy decision:

• For local decisions, this means that:

o The user must have the policy right to use the eISA;

o The user must have the policy right to use the caveats;

o The user’s clearance must be at or above the classification of the asset;

o The classification of the asset must be supported by the eISA; and

o The caveats in the asset’s confidentiality label must be supported by the eISA; and

• For sharing decisions, this means that:

o The network domain to which asset is being sent must be associated with a nation that is a participant in the eISA.

Note that the local policy decisions are much more granular than sharing policy decisions; a characteristic which reflects the nature of the DCA information sharing model.

Based on this policy decision logic, the policy engine will return a permit or deny value to the PEP which will, in turn, allow or prevent the asset from continuing to its target data service.

3.1.2 Cryptographic and Keying Services

As seen in Figure 4: CWIX2017 DCS Component Diagram, the cryptographic and keying services (key escrow) are co-located within the green service grouping.




The cryptographic service, and its supporting keying mechanism, is unchanged from prior exercises. The operation of these services is summarized below:

• Each information asset is protected using a unique symmetric key;

• A DCA protected asset is only decrypted when that operation is in compliance with the overarching security policy;

• Attempts to bypass the PEPs to gain access to information objects directly at the data services will only return encrypted assets;

• The PEP that exists between the local user community and the local data services calls upon the cryptographic services to protect and unprotect information assets in in response to a policy permitted action against data;

• The PEP that exists at the national boundary (the Border Policy Enforcement Point or bPEP) calls upon the cryptographic services to protect and unprotect policy vetted information assets as they ingress and egress the national domain, respectively.

3.1.3 Security Label Equivalency Service

As assets transit the national boundary, the content of the confidentiality labels on those assets must be modified for the information domain to which they being sent. As assets leave a national domain, the local security attributes in the confidentiality label must be translated to their coalition equivalents in accordance with the established eISA. Similarly, as assets are received at national domain, the coalition security attributes must be translated to their local equivalents.

This translation function is performed by the Security Label Equivalency Service (SLES). The SLES accepts a set of security attributes taken from a confidentiality label and:

• Obtains the eISA unique identifier (i.e. context);




• Determines the original and target value domains that are in effect for this eISA; and

• Determine, for each security attribute, the correct mapped attribute value.

The SLES then returns this updated set of security attributes to the calling process; these security attributes form the basis for a new confidentiality label that can be applied to the asset.

3.1.4 Trusted Audit Service

Audit records represent one of the significant evidence gathering artifacts for the CWIX2017 experiment. Audit records are submitted by a PEP in the course of vetting transactions on information assets against the overarching policy. As previously stated, the policy enforcement process collects information from the original transaction, extends the policy decision request with supplementary information about the user and asset and submits this request to the policy decision point which renders a policy decision. At the time a policy decision is made, a complete representation of the policy vetting process has been created and forms the data set that is submitted as an audit record to the Trusted Audit Service (TAS).

This data set includes:

• Transactional data that is relevant to the data request itself (e.g. the email subject);

• The full policy decision request with the original and supplemental attributes;

• The policy decision; and

• Metadata related to the generation of the audit record itself.

A similar audit record data set is generated to track the transformation of security attributes on assets as they enter and leave the national security domain. The TAS is thus capable of producing evidence of both the policy decisions and the sharing actions on information assets within a national domain.




Figure 6: Sample DCA Audit Record provides an example of the raw information submitted as an audit record after processing by the PEP. This information can be filtered through the administration GUI to isolate specific audit records of interest to an audit analyst.

Figure 6: Sample DCA Audit Record

For the CWIX2017 experiment, audit records are stored in a database co-located with the audit service itself. The DCA administration GUI queries and displays audit records from this database.




These audit records were part of the data collection process to prove that the Canadian DCS solution was properly protecting information assets and was dynamically adjusting its policy enforcement in response to changes in the overarching security policy rules. The CWIX2017 Test Report provides screen captures of the administrative GUI Audit information.

3.1.5 Service Integration Point

As stated in section 3.1.1:Policy Decision Logic and Supporting Functions, the Service Integration Point (SIP) is the DCA component responsible for accepting calls from the application proxy intercepts and drawing upon the supporting DCA services to correctly process information assets in response to policy decision and asset transformation requests. The SIP can thus be considered a coordinating service rather than a service that provides a specific capability in and of itself. The types of coordination functions provided by the SIP includes:

• Policy decision requests, where the SIP would:

o Acquire supplemental information the PIPs (userPIP and assetPIP);

o Request a policy decision for the transaction (PDP); and

o Audit the transaction (TAS); and

• Transformation requests where the SIP would:

o Acquire the security attributes in the asset’s confidentiality label (assetPIP);

o Acquire the eISA-based equivalents for those attributes (SLES);

o Apply a new confidentiality label to the asset (assetPIP);

o Bind the confidentiality label to the asset (assetPIP); and

o Audit the transaction (TAS).




To reiterate, a PEP is a logical amalgamation of an application proxy and a SIP. An application proxy is needed to act as an intermediary between the user and the data server and is network service and data object specific. The application proxy calls upon the SIP which, in turn, interfaces with other DCS components. In this way, the two PEPs deployed at CWIX2017 used the same SIP software implementation but separate SIP instantiations. That is, since two application proxies were deployed on separate machines, two SIPs were deployed with a SIP co-located to service an application proxy. These two SIPs, each operating within the logical construct of a PEP, can be seen in Figure 4: CWIX2017 DCS Component Diagram acting between the user and the local data service (for CWIX2017 this was the Exchange Server) and between the data service and the national network boundary.

The topics of PEPs and application proxies is discussed in more detail in the following section.

3.2 Application Integration Technology Target

As shown in Figure 4: CWIX2017 DCS Component Diagram there are two components in the CWIX2017 experiment that are not part of the DCA software deployment: the endpoint and the Exchange mail server. The manner by which these two solution elements were integrated with the deployed DCA services are described in this section.

The standard deployment model that was used for each DCE national network is shown in Figure 8: Sample DCS Test Network Environment and this diagram illustrates how DCS components were situated between the user, the data service (Exchange) and the coalition networks.

3.2.1 Asset Labelling at the Endpoint

In keeping with the CWIX2017 experiment technology objectives, the endpoints within the Canadian DCA domain were deployed with Microsoft Windows 7 and Microsoft Office 2010 Professional. The two Office software applications that were used in the test procedures were Microsoft Outlook 2010 and Microsoft Word 2010.

In order to support the execution of the test cases, confidentiality labels were required to be added to all information assets created by these applications. Asset labelling was provided by the Cord3




Security Labeller for Office (version 17.6.2); an add-in for the Office suite of applications. Using this add-in users could:

• Retrieve from the DCA administrative interface the latest set of eISAs and associated security attributes (i.e. eISA context, classification, and additional sensitivities);

• Select from these security attributes to define the security metadata to be associated with an information asset;

• Apply this security metadata as a STANAG 4774 compliant confidentiality label to the information asset; and

• View the current security attributes as specified in the STANAG 4774 compliant label on the information asset.

How this confidentiality label was added to an asset depended on the nature of the asset:

• Labels on Email messages were placed in a message header (SI0-label) on the message in accordance with STANAG 4778 and its SMTP profile; whereas

• Labels on Office documents were stored as third party XML extensions in accordance with STANAG 4778 and its OOXML profile.

The CWIX2017 Test Report provides detailed examples of STANAG compliant confidentiality labels and the associated bindings of labels to assets.

3.2.2 MAPI Proxy Intercept

The Microsoft Mail Application Programming Intercept (MAPI) is a proprietary message format protocol created by Microsoft to express email objects and interact with Microsoft Exchange email services. In Exchange 2010, MAPI messages are exchanged between Outlook clients and the server in order to provide users with a rich and dynamic messaging experience. These messages are




exchanged using Microsoft’s proprietary implementation of Distributed Computing Environment / Remote Procedure Calls (DCE/RPC), their Email transport protocol.

At CWIX2017, a proxy architecture was used to intercept MAPI over DCE/RPC. This architecture allowed email messages sent from and received by an Outlook user to be first processed by the DCA security overlay prior to delivery. This MAPI proxy intercept, together with its co-located SIP, formed the national PEP.

Figure 7: National and Border PEPs

As shown in Figure 7: National and Border PEPs, this PEP was responsible for ensuring that:

• All messages, whether destined for internal or external recipients, were in compliance with the overarching security policy;




• All messages were protected when in storage at the Exchange server; and

• All email transactions were submitted to the DCA audit component.

3.2.3 SMTP Proxy Intercept

In the Microsoft Outlook/Exchange architecture, messages intended for external users are received first at the local Exchange Server and then routed by the Exchange Message Transfer Agent (MTA) to the intended email domain. These routed messages are formed and sent as SMTP exchanges; SMTP being the universal language of Internet based email.

Similar to the protection of local messages, a proxy architecture for intercepting SMTP messages was used at CWIX2017 and email messages destined for external domains routed through this proxy. This SMTP proxy intercept together with its co-located SIP comprised the border PEP. Since messages received by the border PEP were already policy vetted as they were submitted (via the MAPI PEP residing between the user and the Exchange mail server) there was no need to further validate these messages for compliance with policy. That is, messages intercepted at the national border did not need to be vetted by the information protection model, however, they did need to be processed in accordance with the information sharing model.

The border PEP was responsible for ensuring that:

• National protections are removed from the information asset;

• The confidentiality label on the asset is transformed to reflect the coalition agreed upon values as per the eISA represented in the label; and

• Integrity on the label was applied (e.g. digital signature) in accordance with the STANAG 4778 binding profiles.

The SMTP Proxy Intercept was also deployed with a third-party MTA which provided the mail relaying function to ensure that messages were delivered to their intended target network. For the purposes of the CWIX2017 experiment, the deployed DCA solution managed the name resolution that associated email network domains with the correct mail server addresses.




Figure 7: National and Border PEPs illustrates the deployment configuration and role of each of the PEPs deployed at the CWIX2017 experiment.




3.3 Management Service Technology Target

The administrative GUI at CWIX2017 was a web-based service that allowed mission managers to configure, monitor and manage the operation of the various DCA components, data objects and policies. Many of the management interface options remain unchanged from prior exercises, specifically allowing administrators to perform the following functions:

• Management the DCA system configuration, including:

o Specifying which DCA services can be run on specific machines;

o Setting per-service configuration options; and

o Associating networks with specific national identifiers; and

• Managing user security attributes, such as their clearance and group membership.

However, the administrative GUI was extended for CWIX2017 to allow for the management of the new capabilities introduced to support the exercise testing objectives. These added management functions included:

• Value Domain Management: Through the GUI, an administrator was able to create and manage value domains. As previously described, value domains are the set of allowable values that can be expressed in an eISA and, therefore, be represented in a confidentiality label. The administrative GUI allowed an administrator to create a new value domain with:

o An ordered set of classifications;

o A set of additional sensitivities (caveats); and

o A set of national identifiers.




A value domain, once defined through the administrative GUI, could be:

o Extended in order to create a new value domain based on the original one; or

o Cloned in order to create an equivalent value domain with the same morphology, such as an external representation of an interval value domain.

• eISA Management: Through the administrative GUI, the mission manager could:

o Define a new eISA based on the existing set of value domains;

o Select a subset of security attributes from that value domain that is in accord with the purpose of the eISA; and

o Exchange eISAs with partners to establish cross coalition information sharing communities.

• Policy Rule Management: Through the administrative GUI, a mission manager could:

o Set policy rules to allow/deny users or group the right to use an eISA; and

o Set policy rules to allow/deny users or group the right to use caveats.

• Audit Analysis: Through the administrative GUI, an audit analyst could query and review audit records.




4.0 Experiment Configuration and Execution

This section describes the deployment, integration, connectivity and security metadata management strategies that were used during the CWIX2017 exercise.

4.1 Experiment Deployment and Configuration Strategy

The following resources were made available to the CWIX2017 DCA experiment:

• JFTC vCloud resources for hosting virtual systems;

• The JFTC network for connecting networks that have been assigned to the Canadian DCA execution team and DCA testing partners; and

• 3 Lenovo ThinkPad laptops to serve as endpoints for the testing efforts.

The following protocols were integrated with the deployed DCS solution:

• MAPI over DCE/RPC: The national PEP intercepted this traffic to apply DCS protections to email messages within a national domain; and

• SMTP over TCP: The border PEP intercepted this traffic to apply DCS protections to email messages exchanged between coalition partners.

In support of the testing strategy, 3 DCA test networks were deployed, with each test network composed of the elements shown in Figure 8: Sample DCS Test Network Environment.




Fi g ur e 8 : S a m pl e D C S T e st N et w or k E n vir o n m e nt

I n a D C S T e st N et w or k E n vir o n m e nt, t h e d e pl o y e d s ol uti o n el e m e nt s i n cl u d e d t h e f oll o wi n g:

1. A Wi n d o ws S er v er 2 0 0 8 R 2 s y st e m h o sti n g A cti v e Dir e ct or y;

2. A Wi n d o ws S er v er 2 0 0 8 R 2 s y st e m h o sti n g E x c h a n g e 2 0 1 0;

3. A d e pl o y m e nt of t h e C a n a di a n D C S s ol uti o n t o h ost t h e m e ss a gi n g s er vi c e, c o nfi g ur ati o n

s er v er, P D P, k e yi n g s er vi c e, us er s e c urit y attri b ut e s er vi c e ( us er PI P) a n d t h e a d mi nistr ati o n

G UI;

4. A d e pl o y m e nt of t h e C a n a di a n D C S s ol uti o n t o h ost t h e M A PI pr o x y i nt er c e pt, c oll o c at e d

SI P, cr y pt o gr a p hi c s er vi c e a n d ass et s e c urit y attri b ut e s er vi c e ( ass et PI P);

5. A d e pl o y m e nt of t h e C a n a di a n D C S s ol uti o n t o h ost t h e S MT P pr o x y i nt er c e pt, c oll o c at e d

SI P, cr y pt o gr a p hi c s er vi c e a n d ass et PI P; a n d




6. A test laptop running Microsoft Windows 7, Microsoft Office 2010 and the Cord3 Security Labeller Add-in for Office.

The 5 systems that comprised the Windows and DCA infrastructure were hosted as virtual machines in the JFTC virtual cloud. The JFTC networking group provided the network connectivity for each DCA test network. Network drops within the DCA working group lab, linked to the JFTC virtual network infrastructure, allowed the test laptops to connect to the DCA test domains.

Three separate DCA test environment were deployed by the CWIX2017 execution team.

1. The CAN domain (network address space P.Q.250.0/24) which also served as the testing endpoint for black box testing with other NATO partners (i.e. NATO Communications and Information Agency (NCIA) and ITA). This network space used the FQDN of dca.cwix.can

2. The USA domain (network address space P.Q.251.0/24) which used the network name of dcausa.cwix.usa.

3. The NLD domain (network address space P.Q.252.0/24) which used the network name of dcanld.cwix.nld.

For each of these DCA domain environments,

• The Windows Active Directory was configured to host the FQDN for that domain;

• The Exchange Server was configured to provide email services for that domain;

• The test laptop was joined to that domain; and

• Test user accounts were set up for that domain and email mailboxes configured for those users.

The configuration of the testing accounts is described in the CWIX 2017 Test Report.




T h e c o n n e cti vit y of t h e t hr e e D C A t e st e n vir o n m e nt s, o nc e e st a blis h e d a n d c o nfi g ur e d, ar e s h o w n i n

t h e n et w or k di a gr a m Fi g ur e 9 : D e pl o y e d D C S T est E n vir o n m e nts .

Fi g ur e 9 : D e pl o y e d D C S T e st E n vir o n m e nt s

T h e D C A t est e n vir o n m e nt s w er e li n k e d b y t h e n et w or ki n g i nfr astr u ct ur e pr o vi d e d b y J F T C.

It is n ot e w ort h y t h at w hil e a D C A T e st E n vir o n m e nt w as s et u p f or N L D t o p erf or m w hit e b o x t e sti n g

at t h e st art of t h e e x er cis e t h e y o pt e d t o d o bl a c k b o x t e sti n g fr o m t h eir n o n -D C S n ati o n al n et w or k.

4. 2 I nt e gr ati o n a n d C o n n e cti vit y Str at e g y




This section describes how the DCA services integrated with locally deployed data services, and how connectivity for information asset exchange was established in support of white box and black box testing.

Within a DCA test environment, the following integration activities were performed to enable DCA protection of email within a national domain and configure the DCA services with the Windows infrastructure services.

1. A low privilege Windows domain account was set up at the Active Directory to store, manage and retrieve user security attributes. This account and AD LDAP configuration information was used to configure the userPIP service. The userPIP service was then able to manage user security attributes by both:

a. Supplying user security attributes to the PEP for policy decisions; and

b. Acting as a proxy service between the administration GUI and the AD LDAP service.

2. The MAPI Proxy Intercept was configured to both:

a. proxy MAPI connections to the Exchange Server; and

b. perform delegated authentication of user email sessions.

3. At the Outlook client, a new mail profile was created for each test user. This connection profile ensured that Outlook connected to MAPI proxy rather than Exchange directly. Also, registry settings that instructed the Outlook client to automatically discover the location of the Exchange server were disabled.

Enabling the exchange of emails between DCA test environments was done through email relay configurations. In order to direct email to another DCA test environment the following changes were made to the mail and network service configuration:

1. At the Exchange Server, a smart host relay rule was set to direct email traffic destined for another DCA test network through the local border PEP.




2. A Domain Name Service (DNS) entry was defined that instructed the MTA at the border PEP to direct outgoing emails intended for that external network to the appropriate SMTP-based mail service:

a. For white box testing, this target mail service was the border PEP in the target DCA

test environment;

b. For black box testing, this target was the testing partner’s mail server or border gateway that permitted email traffic to transit the network.

4.3 Operational Testing Strategy

Different testing strategies were employed to support white box versus black box testing.

4.3.1 White Box Testing Strategy

White box testing used the Canadian DCS solution at both ends of the data exchange. That is, the Canadian-supplied data centric services were deployed in both the sending network environment and the receiving network environment. Establishment of the DCS coalition information sharing community followed the principles described in section 1.1:DCS Information Protection Model Principles.

In order to enable white box testing, all participants in the testing procedures required access to an eISA under the auspices of which information assets could be exchanged; the creation and exchange of eISAs follows the process shown in Figure 10: eISA Creation and Exchange.




Figure 10: eISA Creation and Exchange

1. A value domain (the set of allowable security attributes for each supported element in a STANAG compliant confidentiality label) was defined for assets as they traversed the coalition network. One coalition member initiated this process by creating the initial coalition value domain.

2. The initiating coalition member created a local value domain equivalent for the coalition value domain; this equivalent used security attribute values that were meaningful for the initiating nation’s information management domain. For example, the additional sensitivity value of RED in the coalition value domain may be represented with the value CRIMSON in the local value domain. RED and CRIMSON each reflect the same semantic significance but use a different value to express that information.

3. This initiating coalition member defined an eISA under which information assets could be exchanged with testing partners. In accordance with the DCA information sharing model, this eISA used a subset of values from the coalition value domain.

4. This eISA was then shared with all coalition partners that were referenced in the eISA; the contents of this eISA could be interpreted by coalition partners since it was expressed using the coalition value domain whose security attributes were understood by all coalition partners. However, in case a coalition partner did not have the coalition value domain, a copy of it was sent with the eISA.

5. Each partner nation received a copy of the eISA; for the CWIX2017 exercise eISAs were automatically shared via email. If the eISA referenced a coalition value domain that was not




previously known by the receiving nation, the coalition value domain included in the eISA was added to the receiving partner’s DCA configuration.

6. Once the receiving domain had a local working copy of the coalition value domain used by the eISA, the DCA administrator selected the appropriate local value domain equivalent for the coalition value domain that should be used when processing eISA assets locally. For example, the additional sensitivity value of RED in the coalition value domain could have been represented with the value BURGUNDY in the local value domain. In this case RED, CRIMSON and BURGUNDY each reflect the same semantic significance but are expressed using different values in each domain.

At this point each nation was in possession of a copy of the eISA and could use that agreement to create and label information assets that could be shared with the coalition community, subject to the enforcement of the policy:

a. Users had to have the policy right to use the new eISA; and

b. Users had to have the policy right to act on the asset, given the security attributes present in the confidentiality label on the asset (e.g. adequate clearance, membership in the right communities, etc.).

Under the DCS information sharing model, emails exchanged between national domains were automatically handled as per the agreement and enforcement policies, as shown in

Figure 11: Email Exchange using eISAs.




Figure 11: Email Exchange using eISAs

At the sending domain, a user crafted an email message and applied a confidentiality label to the asset that reflected the local value domain values (seen in the blue labelled asset). At the border PEP, this confidentiality label was automatically transformed in accordance with the eISA in the label which specified the “local value domain to coalition value domain” mapping equivalents (seen in the red labelled asset). At the receiving network’s border PEP, this confidentiality label was again transformed in accordance with the eISA in the label which specifies the “coalition value domain to local value domain” mapping equivalents (seen in the gold labelled asset). This newly transformed asset then had a confidentiality label that reflected security attribute values that could be acted upon by the local DCA information protection services.

With the establishment of the testing environment, the Windows service environment and the DCA labelling, sharing and access control policies, the white box tests could be performed between participating partners. These testing procedures are described in section 5.1.1:White Box Testing Scenarios and the CWIX2017 Test Report.

4.3.2 Black Box Testing Strategy

Unlike the white box testing strategy, in black box testing only one side of the email exchange used the Canadian DCS solution. In this testing strategy, the external partner domains did not have the information sharing model concept of value domains or eISAs. How email messages were protected in these target test domains was not known as it fell under the responsibility of the individual nations to protect these assets, as shown in Figure 12: Testing with Black Box Environments.




Fi g ur e 1 2 : T e sti n g wit h Bl a c k B o x E n vir o n m e nt s

N e v ert h el e s s, t h e C a n a di a n D C A t e st e n vir o n m e nt, w hi c h s er v e d as t h e D C A F A e n d p oi nt f or bl a c k

b o x t e sti n g, still e nf or c e d t his i nf or m ati o n s h ari n g m o d el. T h e r e s ulti n g t e st s c e n ari o d e m o nstr at e d

h o w a D C S -e n a bl e d n ati o n al d o m ai n c o ul d b e m a d e t o s h ar e i nf or m ati o n wit h a n o n -D C S

e n vir o n m e nt:

• E m ail ass et s l e a vi n g t h e C a n a di a n t e st e n vir o n m e nt h a d t o b e i n c o m pli a n c e wit h t h e

s h ari n g p oli c y as d efi n e d i n a n eI S A; a n d

• E m ail ass et s e nt eri n g t h e C a n a di a n t e st e n vir o n m e nt h a d t o h a v e c o nfi d e nti alit y l a b els t h at

i n cl u d e d r ef er e n c e t o d at a el e m e nt s t h at c o ul d b e ass o ci at e d wit h a n eI S A




In support of black box testing, the following DCS configuration, data objects and policies were established, as detailed in Figure 13: Black Box Testing eISA Creation.

Figure 13: Black Box Testing eISA Creation

Note that since non-DCA domains did not have the concept of value domains or eISAs, there was no effort to send that information to those domains.

1. A value domain (the set of allowable security attributes for each supported element in a STANAG compliance confidentiality label) was created that matched the NATO Security Policy Information File (SPIF) used at CWIX2017.

2. An equivalent local value domain to this NATO SPIF value domain was created; however, this local value domain used security attribute values that were understood by the Canadian test environment information management domain.

3. An eISA was created that permitted information assets to be sent to NATO partner domains. This eISA used the full set of values from the coalition value domain.

At this point, an eISA that could be used to generate email messages that would reflect security attributes values that were known to the black box testing partner was available, all that remained was to ensure that:

a. Canadian test users had to have the policy right to use the new eISA; and




b. Canadian test users had to have the policy right to act on the asset, given the security attributes present in the confidentiality label on the asset (e.g. adequate clearance, membership in the right communities, etc.)

This eISA in operation is shown in Figure 14: Email Exchange to non-DCA Partners.

At the Canadian domain, a user crafted an email message and applied a confidentiality label to the asset that reflect the local value domain values (seen in the blue labelled asset). At the border PEP, this confidentiality label was automatically transformed in accordance with the eISA in the label which specified the Canadian value domain to NATO SPIF value domain mapping equivalents (seen in the grey labelled asset). Since there was no DCS label mapping function at the receiving domain, this NATO SPIF value domain labelled message was received by the NATO partner. It follows that since the value in the label reflected the NATO SPIF security attribute values, the label was expected to be comprehensible by the receiving domain, so long as both the sender and the receiver interpreted and implemented the labelling standards in a manner that supported interoperability. Evaluating this degree of interoperability was a primary testing objective at CWIX2017.

Figure 14: Email Exchange to non-DCA Partners

This same process was followed to support black box testing with all non-DCA testing partner:

• creating a value domain that reflected that nation’s SPIF,

• creating a local eISA that allowed messages to be sent to that domain;




• creating and sending emails with confidentiality labels based on that eISA; and

• assessing the degree to which the confidentiality labels could be understood by the receiving partner.




5.0 Testing Methodology and Results

This section summarizes the testing that took place at the CWIX2017 exercise. This section provides a review of the actual test sessions that were conducted with NATO partners, a linkage to show where the testing scenarios supported the technology test objectives and a summary of the results that were obtained from the exercise.

More comprehensive information related to the exercise execution can be found in the CWIX2017 Test Report.

5.1 Testing Objectives and Scenarios

The following tables show the association of the test scenario and the technology test objectives that were supported by the scenario.

5.1.1 White Box Testing Scenarios

As described in section 4.3.1:White Box Testing Strategy, white box testing partners were provided with access to a dedicated DCS deployment where they were able to execute the test procedures. The following test scenarios were used by white box test partners to validate the DCS deployment against the CWIX2017 test objectives (the numbers reflect the scenario numbers as enumerated in the CWIX2017 Test Report).

1. Nation to nation email was sent, the transaction was permitted by the DCA security policy and the label on the email was transformed according to the eISA.

2. Nation to nation email was sent but blocked as the email was not associated with an eISA and the context under which the asset was being exchanged could not be determined.

3. Nation to nation email was sent but blocked as the email was being sent to a nation that was not part of the eISA.

4. Nation to nation email was sent but blocked as the email being sent used a caveat that was not supported by the eISA.




5. Nation to nation email was sent but delivery to the intended recipient was blocked at the receiving end as the target user did not have the policy right to access the data.

6. Nation to nation email with a Word attachment was sent, the transaction was permitted by the DCA security policy and the labels on the email and the file were transformed according to the eISA.

7. Nation to nation email with several Word attachments was sent, the transaction was denied by the DCA security policy because one of the attachments used a caveat that was not supported by the eISA.

Table 3: White Box Test Scenario to Technology Capability Coverage shows how each of the scenarios described above are relevant to the Technology Capability Target, as described in 2.2:CWIX2017 Technology Capability Specification.

Table 3: White Box Test Scenario to Technology Capability Coverage




(TC3)

STANAG 4778 Label Binding

(TC4)

Auditing of DCA Operations

(TC5)

Scenario 1 (Permitted email)

Fully Relevant Fully Relevant Fully Relevant Partially Relevant:

In white box testing no crypto

bindings were applied to the 4778 associations exchanged between domains.

Fully Relevant

Scenario 2 (Missing eISA)

Fully Relevant Fully Relevant Fully Relevant Fully Relevant

Scenario 3 (Incorrect destination)


Scenario 4 (Invalid caveat)


Scenario 5 (DCA denial at endpoint)





Scenario 6 (Permitted attachment)


Scenario 7 (Denial bad attachment)


5.1.2 Black Box Test Scenarios

For black box testing, the following scenarios were used to test nation-to-nation testing with NATO partners that supplied their own STANAG 4778/4774 components in support for cross coalition information exchanges (the numbers reflect the scenario numbers as enumerated in the CWIX2017 Test Report).

8. (Scenario#8) Email received from test partner with a STANAG 4774 label within an X509 digitally signed STANAG 4778 binding.

9. Email received from test partner with a STANAG 4774 label within a loosely bound (non-cryptographic) STANAG 4778 binding.

10. Email received from test partner with a STANAG 4774 label within an HMAC-based digitally signed STANAG 4778 binding.

11. Email with attachment received from test partner with a STANAG 4774 label within a loosely bound (non-cryptographic) STANAG 4778 binding on both email and attachment.

12. Email sent to test partner with a STANAG 4774 label within a loosely bound (non-cryptographic) STANAG 4778 binding.

13. Email sent to test partner with a STANAG 4774 label within an HMAC-based digitally signed STANAG 4778 binding.




14. Email sent to test partner with a STANAG 4774 label within an X509 digitally signed STANAG 4778 binding.

15. Email with attachment sent to test partner with a STANAG 4774 label within a loosely bound (non-cryptographic) STANAG 4778 binding on both email and attachment.

Table 4: Black Box Test Scenario to Technology Capability Coverage shows how each of the scenarios described above are relevant to the Technology Capability Target, as described in 2.2:CWIX2017 Technology Capability Specification.




Table 4: Black Box Test Scenario to Technology Capability Coverage




(TC3)

STANAG 4778 Label Binding

(TC4)

Auditing of DCA Operations

(TC5)

Scenario 8 (Recv X509 signed label)

Partially Relevant:

MAPI proxy only used on one side of the information exchange

Partially Relevant:

DCA policy enforcement

only applied on one side of the information exchange


Scenario 9 (Recv loosely bound label)


Scenario 10 (Recv HMAC signed label)


Scenario 11 (Recv loosely bound file)


Scenario 12 (Sent loosely bound label)


Scenario 13 (Sent HMAC signed label)


Scenario 14 (Sent X509 signed label)


Scenario 15 (Sent loosely bound file)


The remaining black box tests were variations of the test scenarios described above. The test scenario variations were performed in support of NATO partners’ specific testing objectives and are described in the following section.




5.2 Test Sessions with Partners

Four separate test sessions were conducted with test partners, as described in the following sections.

5.2.1 White Box Testing with the US SPAWAR Team

The US SPAWAR team performed a complete set of white box test procedures. The US test team were provided with remote access to the USA DCA Test Environment laptop, as shown in Figure 9: Deployed DCS Test Environments.

The US test team executed test scenarios 1 through 7 with the Canadian DCA test environment as the sending domain and the USA DCA Test Environment as the recipient domain.

5.2.2 Black Box Testing with the NCIA Team

The NCIA team performed a complete set of black box test procedures. The NCIA test team supplied the network location of their externally facing mail server and the Canadian DCA test team configured their test environment to support black box testing with the NCIA domain as per the procedure defined in 4.3.2:Black Box Testing Strategy.

The NCIA test team executed test scenarios 8 through 15 with the Canadian DCA test environment.

5.2.3 Black Box Variation with the Italian Team (ITA)

The ITA testing team performed a variation on a subset of the primary black box test procedures. The ITA test team supplied the network location of their externally facing mail server and the




Canadian DCA test team configured their test environment to support black box testing with the ITA domain as per the procedure defined in 4.3.2:Black Box Testing Strategy.

This test variation was intended to not only provide the Canadian DCA test team with additional evidence in support of their programmatic goals, but also to provide the ITA team with evidence to prove the interoperability of their Internet Exchange Guard (IEG). The variations on the black box testing that were performed are as follows (the numbers reflect the scenario numbers as enumerated in the CWIX2017 Test Report):

16. Email sent to the ITA domain with a STANAG 4774 label within a loosely bound STANAG 4778 binding where the ITA IEG was running in transparent mode (no assessment or analysis on email content)

17. Email sent to the ITA domain with a STANAG 4774 label within a loosely bound STANAG 4778 binding where the ITA IEG was running in view mode (examine the email for a first-line-of-text security label)

18. Email sent to the ITA domain with a STANAG 4774 label within a loosely bound STANAG 4778 binding where the ITA IEG was running in inspection mode (act on the first-line-of-text security label and only allow email to be delivered if it is compliance with the ITA policy)

From a Canadian DCA standpoint, scenarios 16 through 18 are identical to test scenario 12 since the only variation is the interpretation of the received asset in the ITA domain by their IEG service.

5.2.4 Black Box Variation with the Netherlands (NLD) Team

The NLD testing team performed a subset of black box test procedures. The NLD test team provided the network location of their externally facing mail server and the Canadian DCA test team configured their test environment to support black box testing with the NLD domain as per the procedure defined in 4.3.2:Black Box Testing Strategy.

The NCIA test team executed the following test scenarios (the numbers reflect the scenario numbers as enumerated in the CWIX2017 Test Report):




19. Email sent to the NLD domain with a STANAG 4774 label within a loosely bound STANAG 4778 binding. This is a repeat of test scenario 12 but with the results interpreted by the NLD labelling service to extract security attributes from the label.

20. Email received from the NLD domain with a confidentiality label sent with the message. This is a repeat of test scenario 9 but with the email asset created with the NLD labelling service to set security attributes on the label.

21. Email with attachment sent to NLD domain with a STANAG 4774 label within a loosely bound STANAG 4778 binding on both email and attachment. This is a repeat of test scenario 15 but with the results interpreted by the NLD labelling service to extract security attributes from the label.

22. Email with attachment received from NLD domain with a confidentiality label on both email and attachment. This is a repeat of test scenario 11 but with the results interpreted by the NLD labelling service to extract security attributes from the label on the email and the attachment.

5.3 CWIX2017 Testing Result Summary

This section summarizes the results that were obtained from the CWIX2017 exercise. More detail about the actual observation, variation and exceptions noted during the testing procedures can be found in the CWIX2017 Test Report.

1. All white box testing was successful. White box testing was only conducted with the US SPAWAR group so this result only reflect result gathered from one data source. However, since white box testing used the same Canadian DCS solution at both ends of the deployment interoperability issues were not expected. The only notable observation was sporadic long latency times. This behavior was attributed to the fact that the US test team was operating out of Pearl City, HI, USA and the network configuration to allow that team access to the JFTC network was complex.

2. Black box testing with the NCIA group was partially successful. The NCIA team was able to retrieve and extract security attribute information from the STANAG 4774 and STANAG 4778 artefacts attached to email messages using the SMTP binding profile.




a. However, the digital signatures (both X509 and HMAC based) applied by the Canadian DCS solution could not be verified by the NCIA implementation. Each solution is based on a different set of libraries that implement the STANAG 4778 cryptographic binding mechanism’s directive to use XMLDsig. The Canadian solution leveraged a Linux based XMLsec library whereas the NCIA solution used a SignedXML library. Although both libraries are supposed to implement the XMLDsig standard, differences in implementation within these libraries led to an inability for objects cryptographically bound in one domain to be verified in the other.

b. In order to apply local DCA protections on an information asset, the Canadian implementation requires that the security attributes in a confidentiality label on that asset to include a reference to the eISA under which the asset is to be shared and handled. Assets sent from the Canadian test environment to the NCIA test environment included this eISA value and did not prevent the NCIA services from processing the label. However, assets received from NCIA did not include this eISA value since the NCIA group does not use this information sharing model. Although the Canadian DCA implementation was able to interpret labels on assets received from NCIA, it was not able to protect the asset in accordance with its DCA information protection processes.

3. Black Box testing with the ITA test group (ITAF) was successful in that STANAG 4774/4778 labelled messages were able to pass through their IEG without interrupting the flow of messages. The CWIX2017 ITA team did not have the ability to process, parse and act on STANAG 4774 labels. However, they were supplied with some test artefacts that they could use to develop a STANAG 4774/4778 aware analysis module for their IEG solution in the future.

4. Black Box testing with the NLD Army was not successful. The software that the NLD test team brought to the exercise was not configured to generate or interpret STANAG 4774, 4778 or binding profile objects attached to emails or files. After verifying that the NLD software was not able to act on STANAG 4774/4778 objects, testing with the NLD team was terminated.

5.4 Summary of CWIX2017 Exercise

This section summarizes the CWIX2017 exercise experience from the perspective of how it:




• Furthered the DCA programmatic goals; • Demonstrated interoperability between coalition partners; and • Advanced the underlying technological approach to DCA.

5.4.1 Observations Relating to the DCA Programmatic Goals

1. The Canadian DCS solution continued to be a reliable design approach to delivering data centric services. No defects or limitations to the testing environment related to the how the DCA security overlay was implemented, deployed or integrated with the IT environment. New and enhanced services were able to be added to the information protection model with minimal rework to the existing implementation. There is a clear path forward for delivering additional extensions to improve upon the existing capability in terms of enhanced services, scalability and robustness. The results from CWIX2017 demonstrate a validation of the security overlay approach to integrating DCS into an existing environment; a stated TIDCE objective.

2. The Canadian DCS solution was able to be adapted to include the necessary changes that reflect updates to how policy decisions were to be made and enforced. This included: changes to the policy decision logic, changes to where policy decisions were enforced and changes to the use of data objects that represent value domains, agreement and security metadata. This again demonstrated the flexibility of the security overlay approach to broadly applying a dynamic security policy across an existing IT environment.

3. The Canadian DCS solution included a significant improvement over the CWIX2016 technology target in its handling of STANAG 4774 and 4778 objects. The confidentiality labels that were created and bound to assets used a more comprehensive set of elements, attributes and profiles. The completeness of the use of these standards was a factor in meeting the interoperability objectives for the exercise, as stated in the TIDCE requirement for enabling information sharing and the DCA FA objective of experimentation with emerging NATO standards for DCS-based information exchange.

4. The information sharing model used by the Canadian DCS solution was demonstrably flexible in how it could be adapted for use in both white box and black box testing. The fact that a value domain that matched the NCIA SPIF (CWIX17 SPIF) could be quickly established, eISAs using that value domain could be created using that value domain and assets could immediately use that eISA to share with the NCIA test environment was proof of the value of the approach taken to model these relationships. The successful use of these standards was a validation of the dynamic data centric information sharing environment promoted in




the DCA FA objectives and the ability for this environment to be supported by the emerging standards and coalition sharing models.

5. Black box testing was successfully conducted with NATO partners and revealed useful information in how the standards could be improved. This was a successful result of experimentation with these standards as was a stated objective of the DCA FA for CWIX2017.

5.4.2 Observations Relating to the Interoperability Issues

6. Not all NATO partners were using STANAG 4774/4778 compliant software. It was not clear that commercial software that supports these standards is readily available. The two testing participants that were able to work in STANAG-based objects were either using custom built software or non-commercial engineering builds supplied by third parties.

7. The fact that the Canadian DCA information sharing model has not been adopted by other nations points to a need to document and share these concepts. Assets provided by NCIA had properly formed STANAG 4774 labels, but without the eISA contextual information, the Canadian test environment was not able to apply DCA information protection rules to those assets.

8. Differences in the implementation of underlying libraries used by various partners to deliver interoperability capabilities were a challenge to interoperability. For example, digital signatures applied to assets in one domain could not be verified in another domain due to differences in the interpretation/implementation of the XMLDsig standard.

9. Some challenges in the interpretation of binding profiles led to interoperability issues. For example, one partner assumed that certain email message headers would always be present in a message whereas another partner generated email objects that did not have that message header (due to difference in the underlying mail server and relay functions). A review of the binding profiles to clarify ambiguities and identify unwarranted assumptions is recommended.




5.4.3 Technology and Implementation Issues

10. The MAPI proxy intercept occasionally caused the Outlook client to become non-responsive. The Outlook client had to be restarted when this occurred. The cause of this issue is not known at this time but has been raised for technical evaluation.

11. The Outlook client occasionally reset its configuration and would connect directly to the Exchange server, bypassing the MAPI proxy intercept. More investigation into the auto discovery services offered by Exchange and used by Outlook is required.

12. There is a network deployment conflict in that the MAPI proxy intercept must use the AD DNS server whereas the bPEP must use the DNS services offered by the DCA infrastructure. This issue was resolved at the exercise by having these two capabilities hosted on separate machines but a long-term solution is needed to address this conflict.

13. The MAPI proxy intercept was adding a spurious file attachment “attachedFile.txt” to message for its own internal processing. This file attachment should be removed when a message is being released to a recipient or external domain.

14. An email message with an attachment, which has a policy deny action, does not prevent the email message being received by the recipient.




6.0 Lessons Learned

Canadian participation in the DCA FA at CWIX2017 was successful in that it:

• Allowed Canada to further establish its leadership role in the emerging field of data centric security by assuming responsibility for demonstration, testing and validation within the DCA FA; and

• Provided an opportunity to validate and demonstrate new capabilities in the DCA information protection and information sharing models; models that enable the protection and sharing of information assets within and between NATO partners’ information architectures.

The following list provides a summary of the lessons learned through participation at CWIX2017.

1. The STANAG 4774 and 4778 standards, and their supporting profiles, do not guarantee interoperability as there is still some ambiguity in interpretation of the specification during implementation.

2. Differences in the underlying libraries on which the STANAG 4774 and 4778 standards are built can lead to interoperability issues.

3. A strategy is needed to deal with the fact that the Canadian DCA information sharing model is not used by other nations. Either this model should be encouraged for adoption by other nations or a method to bridge with nations that do not use the eISA concept should be developed.

4. DNS continues to be a challenge in exercise deployment; there are many different requirements that conflict with the use of DNS services. Certain services need local DCA DNS resolution, others need to use the Windows AD DNS resolution and the ability to leverage the JFTC DNS services would help simplify and validate interoperability testing. A strategy for DNS use in future exercises is recommended.




5. In addition to the STANAGs and the profiles that dictate how these standards should be used, the maturation of these standards could benefit from:

a. Implementation Guidance documents; b. A list of compatible third party software (community supported); c. A set of defined artefacts and test procedures to verify the correctness of an

implementation; d. Regular meetings with coalition partners to discuss clarifications and improvements

to the standards; and e. A permanent forum in which to conduct interoperability testing outside of the

formal CWIX exercise setting.

6. The maturity of the information sharing model used by the Canadian DCA FA suggests that it is an appropriate time to begin the work on a STANAG to express, share and process eISAs. Without a formal specification of eISAs, there is insufficient context to educate other NATO partners on the role and value of these artefacts in support of data centric information protection and information sharing.

6.1 Recommended Next Steps

In preparation for the next series of exercises, it is recommended that the following programmatic and technology objectives be considered to advance the DCA information protection and information sharing models.

1. Further DCA support for application and application protocols in order to extend the capability and scope of the security overlay to protect IT infrastructures, including support for:

a. Outlook Anywhere (MAPI/RPC/HTTP);

b. Mobile email protocols;

c. Instant Messaging (XMPP); and

d. GeoFencing.




2. A greater focus on gathering performance metrics and a measure of the scalability of the Canadian DCS solution.

3. Red-teaming and penetration testing on a hardening deployment of DCA capabilities.

4. Enhancements to the architectural trust model to show:

a. secure start up and shut down (zeroization);

b. self-protecting role-based installation and configuration; and

c. disaster recovery.

5. Improved self-monitoring and load balancing.

6. Policy-based protection of the administrative GUI services (self-protection).




References

[1] TIDCE Experiment Campaign Plan, August 2016

[2] CWIX2017 Capability Architecture Document, December 2016

[3] CWIX2017 Capability Design Document, March 2017

[4] CWIX2016 Exercise Summary Report, August 2016

[5] CWIX2017 Consolidated Development Plan, Sept 2016

[6] STANAG 4774, Confidentiality Label Syntax, Jan 2017

[7] STANAG 4778, Metadata Binding Mechanism, Jan 2017

[8] CWIX2017 Test Report, August 2017

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 Innovation 900 Morrison Drive Suite 206 Ottawa, Ontario 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.) Technical Interoperability in a Data Centric Environment (TIDCE): CWIX 2017 Experiment


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

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

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

81

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

8 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 Security Science NDHQ (Carling), 60 Moodie Drive, Building 7 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.)

15BS

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-C251

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.)

In June 2017, the Canadian Department of National Defence (DND) participated in the Coalition Warrior Interoperability eXploration, eXperimentation and eXamination (CWIX2017) exercise. This exercise was hosted at the Joint Forces Training Facility (JFTC) in Bydgoszcz, Poland in cooperation with coalition testing partners. The decision to participate at this exercise was, as stated in the TIDCE Experiment Campaign Plan, to mature the technical interoperability for information sharing and safeguarding in a Data Centric Environment (DCE). Additionally, it was expected that participation at CWIX2017 would refine technical interoperability understanding through testing and demonstration with coalition partners. The TIDCE Experiment Campaign Plan defined three overarching objectives for validation and demonstration at exercise venues, including CWIX2017, to address the following aspects of the technical interoperability capability: Security Overlay, Information Sharing and Information Safeguarding. The results of this experiment are presented in this report. En juin 2017, le ministère de la défense nationale a participé à l’exercice Coalition Warrior Interoperability eXploration, eXperimentation and eXamination (CWIX2017). Cet exercise s’est déroulé au Joint Forces Training Facility (JFTC) à Bydgoszcz en Pologneen collaboration avec des partenaires membres de la coalition de l’OTAN. Le but de cette participation, tel que défini dans le TIDCE Experiment Campaign Plan, est de mûrir l’interopérabilité technique pour le partage et la protection d’information dans un environnement centré sur les données. Un objectif additionnel était qu’en participant à CWIX2017, il serait possible d’augmenter les connaissances via des expériences avec des partenaires de coalition. Le TIDCE Experiment Campaign Plan définit trois objectifs stratégiques pendant l’exercice CWIX2017. Soit : La sécurité comme une couche protocolaire additionnelle, le partage d’information ainsi que la protection d’information. Les résultats de cette expérience sont présentés dans ce rapport.

Technical Interoperability in a Data Centric Environment ... · Prateek Srivastava . Cord3...

Documents

Transcript of Technical Interoperability in a Data Centric Environment ... · Prateek Srivastava . Cord3...