Secure Access Management for Secure Operational ...Le projet SAMSON a démontré son approche de la...

Secure Access Management for Secure Operational Networks (SAMSON) Project Management Closeout Report

Darcy Simmelink Daniel Charlebois DRDC – Ottawa Research Centre Bruce Carruthers Sypherna Glen Henderson Bell Security Solutions

Defence Research and Development Canada Reference Document DRDC-RDDC-2016-D008 March 2016

IMPORTANT INFORMATIVE STATEMENTS This publication has been published by the Editorial Office of Defence Research and Development Canada, an agency of the Department of National Defence of Canada. Inquiries can be sent to: [email protected] This S&T document is provided for convenience of reference only. Her Majesty the Queen in right of Canada, as represented by the Minister of National Defence ("Canada"), 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.

Template in use: (2010) SR Advanced Template_EN (051115).dotm

© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2016

© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2016

DRDC-RDDC-2016-D008 i

Abstract

This report documents the final status of the Secure Access Management for Secure Operational Networks (SAMSON) project.

Initial demonstration of the SAMSON was planned for the lab, but in order to bring in more operational experience to the project team, a live operational environment was demonstrated in September 2010. The final demonstration, with SAMSON fully integrated into an exercise, was at the Coalition Attack Guidance Experiment (CAGE) in November 2012.

SAMSON has achieved the majority of its demonstration goals despite the roadblocks it encountered. SAMSON has demonstrated:

data-centric protection of files, email, chat, web, C2 and database;

file, email and chat on an accredited, live operational environment;

certification and accreditation of SAMSON for an operational network; and

created exploitation options for capital project, exploitation is currently ongoing.

SAMSON has demonstrated data-centric information protection on an existing unmodified operational network. The integration of access management technologies and protection mechanisms can lead to hosting multi-caveated information on a single network. Adopting SAMSON data-centric security results in: an improved security posture; enhanced auditing; enhanced information sharing; and minimal impact to the operator. SAMSON can collapse caveats onto an existing classified network and significantly reduce costs of the Canadian Armed Forces maintaining multiple independent Canadian Eyes Only (CEO) networks.

The exploitation manager (Director of Joint Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (DJC4ISR) has activities ongoing to exploit SAMSON and stand up a capital project. The activities to kick off a capital project are being supported with existing SAMSON project support contracts. The prime contractor, Bell Security Solutions, has licenced the Intellectual Property to a start-up company to create a product based on the SAMSON architecture and resulting standards.

The most significant lesson learned from the project is: 1) using a sizeable contract to bridge-to-capital is an excellent way to exploit the project deliverables; and 2) projects include demonstration on a live operational network.

Significance to defence and security

The SAMSON TD project has been successful from a number of perspectives:

It has advanced the state of information protection to create an enterprise-wise approach to data-centric security.

ii DRDC-RDDC-2016-D008

It has demonstrated the viability of the solution in SECRET operational contexts.

It has been shown to adhere to security catalogues associated with protection profiles for similar solution in this data-centric security space.

It has demonstrated the innovative use of technologies to create a security overlay that can both integrate seamlessly with existing operational environment while providing an extensible architecture to which new security services can be added.

It has shown that it is possible to build a unified security architecture based on open standards and open protocols.

It has supplied the artefacts in support of these points in a certification and accreditation context.

DRDC-RDDC-2016-D008 iii

Résumé

Le projet SAMSON a démontré son approche de la protection de l’information centrée sur les données sur un réseau opérationnel existant auquel on n’a apporté aucune modification. L’intégration de technologies de gestion d’accès et de mesures de protection peut entraîner l’hébergement d’information comportant de multiples restrictions sur un même serveur. L’adoption de cette approche, axée sur les données, entraîne une amélioration de la sécurité, de la vérification et du partage d’information, tout en ayant une incidence minimale sur l’exploitant. SAMSON est en mesure de réduire ces restrictions sur un réseau classifié existant, en plus de diminuer considérablement les coûts associés au maintien de nombreux réseaux secrets réservés aux Canadiens (RAC), coûts assumés par les Forces armées canadiennes.

Ce rapport documente l’état final du projet de gestion de l’accès sécuritaire aux réseaux opérationnels secrets (SAMSON). Celui-ci a atteint la majorité de ses objectifs de démonstration, malgré les obstacles qu’il a dû surmonter. Plus précisément, il a démontré :

la protection, axée sur les données, des fichiers, courriels, sessions de clavardage, du Web des éléments de C et C et de bases de données;

celle de fichiers, de courriels et de sessions de clavardage dans un environnement d’exploitation agréé;

la certification et l’accréditation du projet SAMSON pour un réseau opérationnel;

la création de possibilités d’exploitation pour un projet d’immobilisation. Cette exploitation est en cours.

Ce projet a été approuvé en mars 2005 et s’est terminé en octobre 2013. On avait prévu de procéder à la démonstration initiale des capacités de SAMSON en laboratoire. Toutefois, on a réalisé celle-ci dans un environnement d’exploitation en septembre 2010, afin que l’équipe de projet acquière plus d’expérience opérationnelle. La démonstration finale, au cours de laquelle SAMSON était pleinement intégré à l’exercice effectué, consistait en l’Expérience d’exécution de l’attaque de la coalition (CAGE) qui s’est déroulée en novembre 2012.

On a maintenu le budget du projet qui comportait un ensemble d’activités de R et D moins nombreuses que prévu. Au final, le projet SAMSON a coûté 6,753 M$, comparativement au budget de 6,616 M$. L’effectif du projet étant généralement insuffisant, il a donc fallu faire appel à des entrepreneurs en supplément aux ressources de l’équipe de projet. Il manquait environ une AP par année.

Aucune activité de suivi n’est prévue dans le cadre du cyber programme de science et technologie. Le gestionnaire d’exploitation actuel (Directeur-Commandement, contrôle, communications, informatique, renseignement, surveillance et reconnaissance, C4ISR) dirige les opérations afin d’exploiter la solution SAMSON et de mettre sur pied un projet d’immobilisation. On utilise les contrats de soutien du projet SAMSON existants afin de soutenir ces activités de mise sur pied. L’entrepreneur principal, Bell Security Solutions, a octroyé une licence de propriété intellectuelle à une entreprise en démarrage en vue de créer un produit fondé sur l’architecture de SAMSON et sur les normes qui en découlent.

iv DRDC-RDDC-2016-D008

Les plus importantes leçons apprises au cours de ce projet sont : 1) de faire appel à un contrat important de jonction vers l’immobilisation constitue un excellent moyen de tirer parti des livrables du projet; 2) de suivre la recommandation d’inclure, dans les projets de démonstration de technologies (PDT) à venir, une démonstration effectuée sur un réseau opérationnel en permanence. Selon ces deux approches, il faut assurer la répartition suffisante des ressources en personnel (de l’entrepreneur ou de l’État), du budget et du temps de façon à gérer les processus d’acquisition ou d’accréditation du ministère de la Défense nationale (MDN). Ceux-ci nécessitent tous deux des documents et livrables particuliers en vue d’exploiter la technologie.

Importance pour la défense et la sécurité

Cette section présente l’importance de SAMSON.

Le projet SAMSON n’a aucune incidence sur les applications existantes : nous employons des serveurs de fichiers commerciaux, l’environnement de courrier électronique Exchange (non modifié) ainsi que la fonction de messagerie instantanée de Microsoft (services fondés sur les protocoles XMPP conservés tels quels). De plus, nous avons démontré qu’il est également possible d’utiliser Google Earth, le GCCS et des bases de données.

Il ne modifie pas les points terminaux ou les serveurs au sein d’une infrastructure existante. Il s’agit d’une technologie d’interception figurant entre les points terminaux (ordinateur portatif ou de bureau, etc.) et le service utilisé.

Il sert à contrôler l’accès aux ressources de données en fonction des justificatifs de l’utilisateur, de la classification de sécurité de la ressource et d’une politique en matière d’accès (c.-à-d. si l’utilisateur possède les justificatifs adéquats pour y accéder et si les données connexes sont récupérées, déchiffrées, puis transmises à l’appareil de l’utilisateur).

Toutes les ressources de données sont chiffrées à l’aide de clés symétriques différentes (norme AES [236-1024-2048], que l’on peut configurer en fonction des exigences en matière de protection). Chaque courriel, fichier, salle de clavardage, etc., possède sa propre clé (autrement dit, ils en possèdent tous une qui leur est exclusive. Donc, en cas de vol, le voleur doit déchiffrer par force brute chaque fichier individuellement).

Les clés de chiffrement ne se trouvent jamais au même endroit que les données, sauf lorsqu’on chiffre ou déchiffre celles-ci. Ces données sont donc sécurisées lorsqu’on ne les utilise pas ou qu’elles sont en transit. Un journal des transactions inviolable nous permet de relever toute falsification de la piste de vérification.

On a réalisé les essais de C et A afin de s’assurer de respecter les critères communs EAL3. Ces contrôles de sécurité ont également été mis en correspondance avec la norme ITSG-33 du CSTC.

On a effectué la démonstration de SAMSON au cours de deux exercices (Empire Challenge 2010 et 2011), lors du CWID 2011 ainsi qu’au cours d’une expérience (celle d’exécution de l’attaque de la coalition de 2012).

DRDC-RDDC-2016-D008 v

Table of contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Significance to defence and security . . . . . . . . . . . . . . . . . . . . . . i Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii Importance pour la défense et la sécurité . . . . . . . . . . . . . . . . . . . . iv

Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Project mandate . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Project accomplishments . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Project demonstrations . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Project accreditation . . . . . . . . . . . . . . . . . . . . . 6

1.2.3 Project exploitation . . . . . . . . . . . . . . . . . . . . . 6

1.3 Project challenges . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Project management performance summary . . . . . . . . . . . . . . . . . 9

2.1 Project management performance (final) . . . . . . . . . . . . . . . . 9

2.2 C&A testing . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Comparison of project to other TDPs . . . . . . . . . . . . . . . . . 16

3 Recommendations for follow on activity . . . . . . . . . . . . . . . . . . 18

3.1 Remaining unfinished work packages . . . . . . . . . . . . . . . . . 18

3.2 Recommended action plan for follow on R&D activity . . . . . . . . . . . 21

3.3 Recommended research priorities . . . . . . . . . . . . . . . . . . . 24

4 Lessons learned . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Lessons learned from scope change . . . . . . . . . . . . . . . . . . 26

4.2 Lessons learned from the bridge-to-capital mandate . . . . . . . . . . . . 27

4.3 Lessons learned from Intellectual Property (IP) . . . . . . . . . . . . . 28

4.4 Lessons learned from contractor size . . . . . . . . . . . . . . . . . 29

5 Observations and recommendations . . . . . . . . . . . . . . . . . . . . 31

5.1 Personnel costs . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2 Technology costs . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

TDP significant events . . . . . . . . . . . . . . . . . . . . . . 37 Annex A

vi DRDC-RDDC-2016-D008

Document deliverables . . . . . . . . . . . . . . . . . . . . . . 39 Annex B Accreditation evidance . . . . . . . . . . . . . . . . . . . . . . 41 Annex C

List of symbols/abbreviations/acronyms/initialisms . . . . . . . . . . . . . . . . 43

DRDC-RDDC-2016-D008 vii

List of figures

Figure 1: SAMSON concept. . . . . . . . . . . . . . . . . . . . . . . . . 1

Figure 2: SAMSON data access process. . . . . . . . . . . . . . . . . . . . . 2

Figure 3: Milestones as reported to SRB by Fiscal Year (FY). . . . . . . . . . . . 13

Figure 4: Cash flow of the project against allocated total. . . . . . . . . . . . . . 14

Figure 5: Projected vs. actual yearly cash flow. . . . . . . . . . . . . . . . . . 14

Figure 6: Planned personnel on project. . . . . . . . . . . . . . . . . . . . . 15

Figure 7: Comparison of schedule to other completed projects to completion. . . . . . 16

Figure 8: Comparison of schedule for individual phase to other completed projects. . . 17

Figure 9: Future-work remaining. . . . . . . . . . . . . . . . . . . . . . . 21

Figure 10: Prioritized SAMSON unfinished work packages. . . . . . . . . . . . . 25

Figure C.1: CSEC ITSG-33 comparison. . . . . . . . . . . . . . . . . . . . . 42

viii DRDC-RDDC-2016-D008

List of tables

Table 1: Exploitation partners. . . . . . . . . . . . . . . . . . . . . . . . 6

Table 2: Project objectives throughout project lifecycle. . . . . . . . . . . . . . 10

Table 3: Excluded work throughout project lifecycle. . . . . . . . . . . . . . . 11

Table 4: Project risks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Table 5: Action response. . . . . . . . . . . . . . . . . . . . . . . . . . 22

Table 6: Future work packages action plan. . . . . . . . . . . . . . . . . . . 24

Table 7: Research priorities. . . . . . . . . . . . . . . . . . . . . . . . . 25

Table B.1: SAMSON DID/CDRL document list. . . . . . . . . . . . . . . . . . 39

DRDC-RDDC-2016-D008 ix

Acknowledgements

The following is to acknowledge that SAMSON is the work of a great many people contributing their skills when required. In addition to the authors named on the title page, significant contributions come from:

Scientific Support

Dr. Steve Zeber

Project Support

Klaus Kollenberg

Norbert Hache

Paul Beland

Procurement

Mark Thorsley

Andreas Psarras

Keri-lee Horrocks

Mark Diotte

Exploitation

LCol John Blythe

LCol Gilbert Thibault

LCol Rick Johnston

Certification and Accreditation

Doug Smith

Bill Dziadyk

Alan Clason

Contractor Team

Eugen Bacic

Dan Seguin

Brent Nordin

Bill Pace

x DRDC-RDDC-2016-D008

This page intentionally left blank.

DRDC-RDDC-2016-D008 1

1 Introduction

Secure Access Management for Secure Operational Networks (SAMSON) applies a data-centric security model; the granularity upon which security protection is applied is taken to the individual information asset. As shown in Figure 1, the SAMSON information protection model applies a single security policy across all information objects (e.g., files, email messages, chat room sessions, and web objects). SAMSON also provides the ability to apply a wide range of security protection services in a unified protection model so that:

access to information assets is gated by policy (access control);

assets are stored in encrypted form (information protection); and

all requested actions against information assets are recorded in a tamper-resistant audit trail (trusted audit).

Figure 1: SAMSON concept.

Figure 2 illustrates the SAMSON information protection model in operation. In this example, a SAMSON user requests a copy of a file that is secured through the SAMSON information protection model.

2 DRDC-RDDC-2016-D008

Figure 2: SAMSON data access process.

1. A SAMSON user requests access to a file.

2. SAMSON examines the security attributes in the metadata of the requested file (e.g., classification, caveats).

3. With the security attributes of the requesting user and the file object, SAMSON makes a policy decision to determine if the user can have access to the target file.

4. If the user is permitted to access the file, it is decrypted for the user.

5. An audit record of this transaction is submitted to the trusted audit store.

It is significant to note that this example of a SAMSON enforced transaction is equally applicable to any operation on files (e.g., storing files, deleting files) and this concept can be applied to any kind of data object (e.g., email messages, chat rooms sessions) in an operational environment.

1.1 Project mandate

The original objectives, mandated changes and final achievements for SAMSON are shown in Annex A, Technology Demonstration Project (TDP significant events). The original objectives were to:

1. demonstrate the data centric capability;


2. integrate with existing endpoint services;

3. demonstrate on DND test environment; and

4. leverage other existing work.

The SAMSON Technology Demonstration (TD) planned for three demonstrations as part of the Project Implementation Plan:

1. demonstration in year one on the DRDC – Ottawa Research Centre Laboratory;

2. demonstration in year two on the Test and Development Centre; and

3. demonstration in year three on a Classified Network (C-NET).

The original project charter from 2006 specifically excluded Certification and Accreditation (C&A) on an operational network. The original plan was to demonstrate SAMSON on a DND test bed, such as a testing exercise or at the Test and Development Centre (TDC) in Tunney’s Pasture.

1.2 Project accomplishments

The significance of SAMSON is:

Existing applications are not impacted: we use COTS file servers, MS Exchange email (unmodified), Instant Messaging (unmodified XMPP-based services), and have demonstrated that we can also deal with Google Earth, GCCS and databases;

SAMSON does not modify the endpoint or servers in an existing infrastructure. SAMSON is an intercept technology that sits on the wire between the end-point (laptop, desktop, etc.) and the service;

SAMSON mediates access to the data assets based on user credentials, data asset security classification and an access policy (i.e., if the user has the appropriate credentials to access the data asset, it is retrieved, decrypted and delivered to the user’s appliance);

All data assets are encrypted with different symmetric keys (AES [236-1024-2048], configurable based on protection requirements). Each email, file, chat room, etc., has its own key (i.e., if the file store is stolen, each file has a different key—if you decrypt one file brute-force, that is all you get, you must brute-force decrypt the next file, and the next, etc.);

The encryption keys are never with the data unless it is being decrypted or encrypted–data is secure at rest and in transit. A tamper-proof transaction log allows us to detect any tamper of the audit trail;

C&A testing was completed to ensure compliance with Common Criteria EAL3. These security controls were also mapped onto CSEC’s ITSG33 standard; and

SAMSON was demonstrated in two exercises (Empire Challenge 2010 and 2011), a demonstration (CWID 2011) and an experiment (Coalition Attack Guidance Experiment 2012).


Data centric security services can be used in cross domain, multi-level and multi-caveat information protection. The scope of the SAMSON project was deliberately contained to the protection of information within a single security domain (multi-caveat). The results of this project have proven that a data-centric security solution can be integrated as a security overlay onto an existing Information Technology (IT) architecture. SAMSON has been successfully demonstrated enhancing the information protection and information sharing capabilities for operational environments. While demonstrating the success of the SAMSON project, external demand has been generated from NATO and other coalition partners for a similar data-centric capability.

To meet this demand for the SAMSON capability, and increase the applicability for the data centric approach, R&D support for cross-domain information sharing and protection is seen as the largest remaining area of research for the SAMSON data-centric capability. Research into this expanded capability set will include the need for: interpretation of security metadata across domains, expression and interpretation of multi domain security policies, maintaining the trust model as data is exchanged between domains and enhancements to trusted auditing.

The SAMSON TD project can service not only as a demonstration of innovative security architecture for the next generation IT environments, but also as an example of the structure and execution of how research projects should aim for exploitation and success.

The SAMSON application and security services were tested using end-to-end systemic test scenarios run from user workstations and unmodified user applications. Test coverage was addressed by carrying out a full set of file services, instant messaging, and email functional tests. In addition, all audit records associated with the tests were recorded and analysed for correctness and accuracy in reporting policy violations. Performance and Scalability testing carried out as part of the Classified Test and Development Centre (CTDC) Trial (SD-006) indicated that a SAMSON deployment based on the CTDC baseline configuration could support a user community size and performance levels as defined below.

File services: A user community size of 1000 users, where 400 are active in transferring a 1 MByte file every five minutes;

Instant message services: A user community of 1000, where 150 are active and carrying out a chat session every 20 seconds; and

Email services: A user community size of 1000 users, where 150 are active in sending and receiving an email every five minutes.

1.2.1 Project demonstrations

The SAMSON TD was successfully deployed to four operational military exercises. Due to the project cancellation in September 2009, and subsequent re-initiation, the project team decided to demonstrate the utility of SAMSON in operational exercises instead of demonstrating it in a lab and a test centre. Each exercise is described below.

Empire Challenge (EC) 2010: This military engineering exercise took place during the summer of 2010. EC2010 was a coalition deployment of emerging military sensor and information management tools. The centres to which SAMSON was deployed included:


the DND Complex at the Louis St Laurent Building, Gatineau; and

the military proving grounds at Fort Huachuca, Arizona.

A separate SAMSON deployment was installed at both locations. These Information Technology (IT) environments were classified SECRET and SAMSON was demonstrated providing caveat separation for Canadian Eyes Only (CEO) and releasable Canada, USA (rel CANUS) communities. Data centric access control for file sharing, email and Instant Message (IM) session was successfully demonstrated at both locations.

This exercise was the first ever operational deployment for the project team, and provided an opportunity to learn about the operational environment and be part of the planning and scenario development process. SAMSON was a standalone capability and demonstrated internally only.

Empire Challenge (EC) 2011: SAMSON was invited to return to the subsequent EC military exercise. The SAMSON TD project extended the capability of the solution by demonstration information protection through use of per-asset symmetric key encryption.

This exercise built on the previous EC 2010 experience. This exercise was intended to bring in operational users; however was not part of the main exercise. SAMSON was a full technical solution, demonstrating on a standalone network. Operational data was brought over to SAMSON to demonstrate to the operational community, but not integrated into the overall exercise.

Coalition War fighter Interoperability Demonstration (CWID): SAMSON was deployed to the SECRET facility at the DRDC Canadian Forces Electronic Warfare Centre (CFEWC). For these exercises, SAMSON was used by DND personnel working directly with the technology, but not integrated into the overall exercise.

This exercise brought in operational users to test and evaluate the technology. Live operational data was injected into SAMSON and operational users evaluated the technology.

Coalition Attack Guidance Experiment (CAGE) II: The CAGE II exercise was the final operational exercise, as mandated in the charter, in which the full architecture and capability was demonstrated. Again held at the CFEWC, SAMSON was an integrated partner in the exercises and was fully utilized during the course of the event. Full information protection across the sphere of access management, information protection and auditing was in place for all relevant applications (file sharing, email, IM and web session protection). CAGE II was again performed by DND personnel who provided useful feedback to the SAMSON team in terms of performance, ease of use and visibility. Performance metrics and data validation were collected by the SAMSON team and used as part of the C&A evidence gathering process. CAGE was the first exercise where SAMSON was integrated fully into operations and part of the operational scenario. During the exercise, the use of SAMSON within the CAGE II exercise was increased due to operator demand. Operators asked for access to SAMSON protected servers in order to create CEO data within the exercise. This helped prove the use and utility in providing CEO caveat protection inside the existing operational network.

In summary, SAMSON has participated in operational environments to successfully deliver data-centric information protection. In all deployments, SAMSON was deployed and integrated into the exercise environment classified to SECRET. In each deployment, additional capabilities


were added to the SAMSON architecture to deliver the data centric protection capability. The final instantiation of SAMSON, deployed at CAGE II, has become the reference architecture for the C&A activities that have taken place.

1.2.2 Project accreditation

The original proposed SAMSON project had no formal C&A component. The importance of transitioning a R&D project to a DND capability was first identified at the Second SRB in May 2007. This SRB mandated that SAMSON include an “exploitation to capital”, which included some formal C&A. In September of 2008 this was expanded again to include a formal C&A board and a C&A analyst to be assigned to the project. This change added $300K of funds to the project to address the increased PY’s required.

SAMSON formally posted the Request for Proposal (RFP) on MERX1 in April of 2008. This RFP included three phased demonstrations. The first phase in the laboratory, the second phase in the Classified Test and Development Centre (C-TDC) and the final demonstration on an enclave within the classified Domain.

This design included that the contractor perform all C&A necessary to achieve a C-Net demonstration, including specific Data Item Deliverables (C&A Documentation, SD 008) for all experiments and Trials (SD 005 Experiment Report, SD 006 Trial Report) using the “Common Criteria for Information Technology Security Evaluation” (Common Criteria) and existing DND standards (Threat and Risk assessment, Statement of Sensitivity).

1.2.3 Project exploitation

The status of the original Exploitation Partners, as shown by calendar year, is shown in Table 1. Most information technology related projects were absorbed by Shared Services or cancelled outright. SAMSON exploitation is currently residing with the Directorate of Joint C4ISR (DJC4ISR). DJC4ISR resides under the Director General Cyber (DG Cyber).under the purview of Chief of Force Development (CFD). The description of each of the legacy projects below can be found in the DND Capabilities Investment Database (CID) on the DWAN. These are all major crown projects (between $40M and $100M).

Table 1: Exploitation partners.

1 Now www.buyandsell.ca.

Related Projects FY 0

5/0

6

FY 0

6/0

7

FY 0

7/0

8

FY 0

8/0

9

FY 0

9/1

0

FY 1

0/1

1

FY 1

1/1

2

FY 1

2/1

3

Notes

DND

cfcsII -> IC2S -> XENA x x x x x x x Cancelled (XENA)

EISE x x x x x x Cancelled

Identity Management System x x x x x postponed - opperational priorities

PSECP (SCIP) x x x x x x x absorbed by Shared Services

DJC4ISR x x x Ongoing

http://www.buyandsell.ca/


Directorate Joint C4ISR is currently exploiting the SAMSON technology by standing up a project called Data Centric Security Services (DCSS). This project is currently awaiting Project Management Board (PMB) approval to become a full capital project and enter in Definition Phase with ADM(IM).

1.3 Project challenges

The project lifecycle and significant events can be found in Annex A. Of these events, the three most significant are (in order of importance):

1. Bridge-to-capital increase of scope:

This scope change had the largest impact on the project—both positive and negative. During an initial Senior Review Board (SRB), the client wanted the project to be able to exploit the project directly—by delivering a complete solution to the Canadian Armed Forces (CAF). The cost to do this was then estimated to be $50M with significant risk and delays. Both the DND contracting authority and the PWGSC procurement authority recommended keeping the project under $20M signing authority level to minimize procurement risk and delays. This then resulted in a contract with a $6M R&D core contract with $14M in unfunded options for client exploitation. The change from a TDP ($6M project budget) to a project capable of delivering to capital ($6M TDP +$14M exploitation options) brought up significant changes. This involved changes to: 1) contracting strategy; 2) amount of time to prepare the contract and evaluation criteria; 3) approval process; and 4) contractual oversight.

2. Capital exploitation projects closed:

The impact of Shared Services Canada (SSC) was felt over a series events spread over a few years. The original impact was the cancellation of IT related projects within National Defence. This included both SAMSON exploitation partners—Enterprise Information Security Environment (EISE) project and Cross-Domain Exchange Network Architecture (XENA), as well as related work that SAMSON was assisting with—Identity Credential and Access Management (ICAM). This also resulted in reductions in the cyber initiatives within Director Information Management Engineering and Integration (DIMEI), Assistant Deputy Minister (Information Management (ADM(IM)) and Director of Information Management Security (DIM Secur).

3. Project required external certification and accreditation:

The other significant challenge for the project was change of the demonstration environment from “operational exercise” to “Live operational Network—CSNI”. This significant impact was also not accounted for in the project budget or schedule.

With the planned deployment on an operational network, SAMSON required approval of the Operational Authority (OA) of the network in order to deploy. This included formal Certification and Accreditation (C&A) with sufficient testing, as defined by the DIM Secur C&A processes, against a recognized standard. During the testing process the C&A standard was changed from Common Criteria to an IT Security Guidance—revision 33 (ITSG-33) based compliance. This C&A standard change is a process and documentation change only, and required very little change in testing. In order to complete any C&A testing, under either the old or new standard, the


project must be prepared to have: 1) a stable build environment; 2) well defined and understood security controls; and 3) sufficient documentation to support the operational use, technical description and security compliance testing.

The C&A testing brought a level of complexity to SAMSON that a typical research project was not accustomed to. With SAMSON, a research area was completed and a operational demonstration built. The team would then move to the next research area and continue development. This often resulted in re-work of the original code and demonstration based on new lessons learned. A stable build environment was not achieved until late in the project, when the project could continue working on research problems, but had to stop in order to allow accreditation to proceed. Second, the security controls required are well understood, but often conflict with the work required to perform new research. For example, two factor authentication is a well understood security control to authenticate a user. SAMSON needed to pass the authentication through the PEP to the security service, which is not a typical supported use case for this protocol. The research environment can often extend security controls and use them in new ways. This adds to the complexity of the C&A process and technical development team in understanding the difference, developing the code and documenting sufficiently for accreditation. Finally, documenting for an operational environment goes far beyond the typical technical design and build documentation a research project receives. The documentation required includes operational use, roles and responsibilities and formal testing against existing security profiles. The final documentation for the project ended up being two 3" binders of paper, most of this paperwork was the security profile and evidence that SAMSON meets the specified security control.

To the authors’ knowledge, no TDP has delivered an operational capability that includes full accreditation on an operational network. SAMSON, as a network security project, had significant C&A challenges to operationally demonstrate full accreditation. Normally TDPs demonstrate a capability, and leave the operationalization and commercialization to a capital project or vendors. SAMSON’s mandate to perform C&A became a TDP activity.


2 Project management performance summary

Project performance was tracked during the execution of the project. As the project progressed, the requirements were refined through the Senior Review Board (SRB) with the scope, cost and schedule of the project updated in order to provide an after action report and track performance. This included increase in scope, changes to the excluded items, tracking of project risks, milestone reporting vs. actual, budget vs. actual, testing results and finally a comparison against other projects for future baseline.

2.1 Project management performance (final)

Table 2 shows the SAMSON deliverables from the approval of the charter in March 2006 to the final produced TDP in September 2013. Red shows the increase in scope or incomplete deliverable at the end of the project. Yellow shows a partially complete deliverable with a green as fully completed. Each of the ‘x’ indicates when this function or feature was part of the charter at that reporting milestone.

From Table 2, we can see the original scope and changes in scope through the various project review boards and deliverables. The red marked items in the objectives show the increase in scope and when they occurred. The final colouring in the right hand column (at the closeout SRB) shows: accomplished (green); partially accomplished (yellow); or incomplete (red).


Table 2: Project objectives throughout project lifecycle.

Unfinished/incomplete work in Table 1 included: 1) strong authentication. Work partially complete includes: 1) database service; 2) web service; 3) leverage DND PKI; establish standards and finally 4) create C&A management board.

Multi factor authentication was excluded from the final deliverable as it was felt this could be met by existing commercial off the shelf (COTS) products, and provided low research value to the final demonstration. SAMSON consumed the Windows credentials, including multi-factor authentication. SAMSON demonstrated with each client/server using two factor authentications, but excluded the deployment of a PKI system to the endpoint. Purchasing a COTS product to perform the two factor authentication (smart card) was expensive, but easy to perform. It was removed from scope in order to satisfy other more pressing R&D issues.

Ap

pro

ved

Ch

arte

r

PIP

SS T

D (

EPA

)

SRB

SRB

SRB

(re

d c

ard

)

SRB

SRB

SRB

Clo

seo

ut

SRB

Ap

r-0

5

Mar

-06

Mar

-06

Jun

-06

May

-07

Sep

-08

Mar

-09

Oct

-09

Dec

-10

Dec

-11

Sep

-13

Objetives ACCOMPLISHED

1. Demonstrate caveat separation x x x x x x x x x x

2. Integrate and demonstrate

strong authentication x

Policy based access control x x x x x x x x x x

trusted labelling x x x x x x x x x x

centralized identity management x x x x x x x x x x

trusted audit capabilities x x x x x x x x

3. Integrate and demonstrate secure access control and

dissemination capabilities for:

Policy based access control x x x x x x x x x x

file sharing x x x x x x x x x x

email exchange x x x x x x x x x x

database access x x x x x x x x x x

web services x x x x x x x x x x

selected collaboration tools x x x x x x x x x

4. Demonstrate capabilities on a DND test bed. x x x x x x x x x x

5. Leverage previous DRDCand Canadian industry

collaboratively developed technology. x x x x x x x x x x

6. Leverage international efforts in secure access management, x x x x x x x x x x

7. Leverage the current DND infrastructure including the DND

PKI, and the deployed server/workstation baseline, and x x x x x x x x

8. Demonstrate these capabilities on an operational network x x x x x x x x x

9. Establish data and service interface and standards x

10. Explore the benefits of sharing information between

international, national and local network operations centres; and x x x x x x x x x

11. Demonstrate the advantages of sharing information (with

different levels of detail) between various levels of command x x x x x x x x x

12. Exploitation bridge to capital project x x x x x x x

13. Governance for C&A: risks, breakout risks and add analyst x x x x x x

14. Create C&A management board: CSEC, SJS, DRDC x x x

!


The two SAMSON services, database and web—were demonstrated, but not on a fully accredited system. The database services was demonstrated to work in the lab with test data and at a test trial, but was not considered robust enough to demonstrate in an operational setting. The web services provided a rudimentary web proxy/pep that provided mediation to the SAMSON web interfaces for audit, administration and policy. This provided the mediation and access control but not the data centric security. The project team considered the database solution complete, with further engineering (robustness) required, while the web PEP required further R&D effort for full demonstration. Since these two services were not functionality demonstrated, the objective #8, Demonstration on an operational network was also not fully completed. All other aspects of SAMSON were demonstrated.

SAMSON also continued to work on establishing a data centric protection standard within the standards body of: Organization for the Advancement of Structured Information Standards (OASIS). The data centric security protection profile standard was created and proposed; It continues to be a work in progress. The C&A board was created for oversight into the certification and accreditation of SAMSON. This board met twice during the project, but due to delays was not convened again. The lack of closure and use of this board makes this objective a yellow deliverable as well.

Work that was specifically excluded from the SAMSON charter is shown in Table 3. This includes audit, C&A, operational deployment, server specific hardware and modeling policy framework. During the course of the project, three of these exclusions were mandated to be “in scope” for the project by a formal Senior Review board. The impacts of these mandated changes were not well planned, as can be seen by the lack of cost or schedule changes corresponding with the approved Project Implementation Plan (PIP) in March 2006. This are marked in red, as they were significant scope and cost increases without a corresponding increase in schedule or budget.

Table 3: Excluded work throughout project lifecycle.

The project risks, as presented to senior management over time, are shown in Table 4. These do not include the technical development risks of the contractor, only risks as reported at each Senior Review Board. As can be seen in Table 4, none of the original projected risks adversely affected the project. The biggest impacts of events that affected the project were mandated scope changes (C&A activities) and unforeseen external risks from the impact of Shared Services Canada (SSC).

Excluded work Mar

-06

Mar

-06

Jun

-06

May

-07

Sep

-08

Mar

-09

Oct

-09

Dec

-10

Dec

-11

Sco

pe

Imp

act

policy managemetn framework modeling NM x x x x x x x x

PEP's for hardware x x x x x x x x x

Audit presentation and manipulation x x x x x x x x

C&A x x x

Operational Deployment NM x x


Table 4: Project risks.

Significant delay was encountered with the mandated scope change to “Find a way to bridge-to-capital”. This mandate brought in Public Works and Government Services Canada (PWGSC) and DND Procurement staff to develop and implement a proposed solution. The solution recommended was for SAMSON to create an unfunded contract option in order to create the bridge. A capital project would then fund the option. The project milestones for project approval and delivery are shown in Figure 3. These milestones are traditional to any capital project: Request for Interest (RFI), Request for Proposal (RFP), project start, and the project phases: options analysis; definition; implementation; demonstration and closeout. The use of the unfunded option caused roughly a two year delay in the approvals process. Mostly due to the increased contract value requiring significantly higher signing authority to authorize a contract of this size and thus much greater detail in the Statement of Work (SoW)—evaluation criteria and review process. Once the contract was awarded in December 2008 (FY 07/08 in Figure 3), the planned four year prime contract to build-test-develop (based on the original charter) was completed in 4.8 years.

The original Charter called for SAMSON to complete by the 15th of January 2010 for a total of 57 months of project time. SAMSON completed in October 2013 for a total of 102 months of actual project time—an increase of 79%. The majority of this delay was due to contracting with PWGSC and the increase in signing authority.

FY 0

5/0

6

FY 0

5/0

6

FY 0

6/0

7

FY 0

7/0

8

FY 0

8/0

9

FY 0

8/0

9

FY 0

9/1

0

FY 1

0/1

1

FY 1

1/1

2

FY 1

2/1

3

Notes

Technical

1. SAMSON requires no major research

breakthrough

2. Number of opensource / cots require

modification

Techncial C&A

OperatorAcceptance of Risk ECI from DIMEI completed similar

Cost / Schedule

5. DND will use PKI with

Certification and Accreditation Based on testing results

Programatic

3. DJFC will assign 1.2 PY (military Liaison) SRB closed

4. CFCS support and DNDICF operators for

demonstrations Operators for Exercises

5. Scope creep

Contractual delays in awardarding Contract Awarded

Project size and complexity

Exploitation

Loss of key personnel

Policy change to allow CEO caveats on CSNI ECI from DIMEI completed similar

Impact of Shared Services

!


Figure 4: Cash flow of the project against allocated total.

In Figure 5 is the projected vs. actual cash flow that was done every year. The discrepancy is due to the project forecasting a prime contract award, with the large payments required once awarded, while delays in the procurement process prevented this from happening.

Figure 5: Projected vs. actual yearly cash flow.

Once the contract was awarded, the projected vs. actual was much more accurate. There is little that a project manager can do for this situation, as the procurement process is owned by PWGSC


and is opaque to the project team. If possible the cash flow risk should be spread across multiple projects, (centre level allocation), or a project is 0 funded until it is posted to BuyAndSell.ca. Once posted, the award date can be projected much more accurately.

Shown in Figure 6 are the planned vs. actual resources for the project. 1.4 PY’s per year were planned for a total of 8.7 PY’s over the project life. These resources were a project manager (0.5 PY), Scientific Authority (0.6 PY), and some scientific support (0.2 PY). Due to delays in procurement and accreditation, this project lifetime was drastically increased, with a total of 12.5 PY’s over the project eight year lifecycle. In addition, more project management would be required if future TDPs adopt the SAMSON exploitation model. Figure 6 shows a persistent shortfall in the allocated PY’s. The shortfall was covered by bringing in contractor support. The net effect for the project was that the shortfall drove up contracting costs due to the delays in the overall contracting process.

Figure 6: Planned personnel on project.

2.2 C&A testing

Although unit and system testing was part of the Rapid Application Development (RAD) approach for the creation of SAMSON, formal accreditation was not started due to C&A limitations until the end of the formal code development. The C&A testing was done in the Classified Test and Development Centre (CTDC) which is an unclassified representation of the Consolidated SECRET Network Infrastructure (CSNI).

This formal testing that took place under this effort examined the installation, configuration, acceptance testing, performance, scalability, and stress testing on SAMSON to:

Define the SAMSON configuration for the CTDC;

Define the SAMSON roles specific to the CTDC environment;

Determine the time and effort required to install and configure SAMSON from “bare” machines;


average delays. It is recommended that these be accounted for by the project team, or the team uses a simple competitive process to minimize delays.

Comparing each of the project individual milestones for their duration is shown in Figure 7 and Figure 8. Each milestone, as shown in the y axis in Figure 8 can be compared to other typical projects to see where the delays are occurring and used for comparison of future projects.

Figure 8: Comparison of schedule for individual phase to other completed projects.

As can be seen in Figure 4, significant schedule delay is typical of all the projects. SAMSON has the longest delay among the TDPs, but not atypical. For the SAMSON project, this delay can be accounted for by the significant scope change in the bridge-to-capital mandate and the resulting change in contract size and complexity.


3 Recommendations for follow on activity

During the course of the SAMSON TD project, certain aspects of the implementation were identified during development meetings, through After Action Reports (AARs), and during C&A discussions that pointed to gaps, needed functionality and general areas of improvement for the SAMSON architecture. These items are presented here as a road map for future work to extend the capability and improve the trust model for the SAMSON solution.

The first section below discusses the difficulty vs. the operational need for the remaining work areas. This gives exploitation projects a rough idea of the remaining work and complexity. The second section below divides up the outstanding work areas into research, demonstrate or develop activities. This section gives an exploitation project a rough idea as to which areas can be easily built in-house or contracted and which areas require further research. The third section below then summarizes the work packages in terms of a senior scientist required to finish researching the work package.

3.1 Remaining unfinished work packages

We present a summary of nine recommendations (work items #1 to 9 below) in Figure 11 where each is mapped to its corresponding Operational Requirement (OR) and Level of Effort (LOE). The work items are grouped using a risk management approach. This approach looks at each work item remaining and evaluates it for the LOE (Low, Moderate, High) required to bring the work item to an operational level against the OR and CAF Needs (Rare, Unlikely, Possible, Likely, Certain). LOE in this approach includes both the research required and engineering effort to define the problem space, design solution, test and demonstrate a solution that will meet the Canadian Armed Forces (CAF) needs. LOE also includes the degree to which the solution will pose a technical challenge for implementation and integration within the SAMSON architecture.

Note that the work items below are a set of SAMSON extensions and enhancements that are seen as the next logical steps towards maturing the technology. This set is not an exhaustive list of potential improvements and it is anticipated that new priorities for SAMSON enhancements will be defined as the technology is adopted.

1. Cross-domain data exchanges: The current SAMSON implementation is meant for a single domain exclusively. An investigation into the challenges of supporting multiple domains would be a logical setup towards greater SAMSON uptake. These issues would include: cross domain security label interpretation, cross domain policy evaluation, extending the trust model to disclose of data between domains and the requirements for enhanced auditing. This enhancement will require a high degree of research and a moderate-high degree of development for implementation.

Level of effort: High.

Operational requirement: Certain.


2. Native exchange support: The current SAMSON implementation intercepts email using the SMTP and POP3 protocols. While sufficient for a demonstrator, an intercept that can work directly on the native Microsoft Exchange MAPI/RPC protocols is deemed to be necessary in operational environments. While this is at odds with the SAMSON philosophy of working on open standards and protocols, native Exchange support is seen as essential to the acceptability of the solution. This enhancement will require a low-moderate degree of research and a moderate degree of development for implementation.

Level of effort: Moderate.


3. Encrypted file search: Since data files are encrypted when protected by SAMSON, there is no way to search through file content. A means is needed by which searches could be performed against files without compromising the confidentiality or integrity of the data. While the SAMSON team has performed some initial investigation into encrypted search indices; a more in-depth examination of this challenge is needed. This enhancement will require a moderate degree of research and a moderate-high degree of development for implementation.

Level of effort: Moderate-High.

Operational requirement: Likely.

4. Data-centric database protection: Data-centric information protection of databases has been identified as being of significant interest to DND/CAF and the GoC. Some preliminary work with CryptDB (a MIT research initiative) has identified a path to a SAMSON solution for database support. By leveraging advanced cryptographic concepts such as homomorphic encryption, a SAMSON complaint PEP for databases could be created, but more research would be required to progress this solution. This enhancement will require a moderate degree of research and a high degree of development for implementation.

Level of effort: Moderate-High.


5. Logic-based policy engine: It is the belief of the development team that a policy engine based on a predicate calculus is a better approach to creating PDPs. A simple Prolog-based PDP was created and demonstrated during the project but a complete solution that is fully-compliant with eXtensible Access Control Markup Language (XACML) expressions would be an improvement over the existing PDP implementation. Human readable policies can be more easily expressed using logic-based policy engines leading to more accurate and flexible policy expressions. As result, however, this effort will also require the development or integration of a policy editor that will be able to create logic-based policy expressions. This enhancement will require a moderate degree of research and a moderate degree of development for implementation.

Level of effort: Moderate.

Operational requirement: Possible.


6. Improved labelling of data objects: The approach taken to label certain data objects needs to be re-visited to ensure that the created labels conform to a labelling standard, are bound to the asset, and support the trust model. For example, Office documents can embed XML into the document properties. The embedding of metadata into the original data does not work for real time systems such as Chat servers or database tables. Each data type must be examined to define a labeling standard that will work with the client/server being used. This enhancement will require a moderate degree of research and a low-moderate degree of development for implementation.

Level of effort: Low-Moderate.


7. Policy enforcement extensions: While the XACML standard includes the ability to comprise environmental conditions in policy expressions and policy requests, the existing deployment does not leverage this capability. The existing PEPs can be enhanced to include: time of day and location information as part of the policy decision process supporting the creation and enforcement of more sophisticated security policies. This enhancement will require a moderate degree of research and a low-moderate degree of development for implementation.


Operational requirement: Unlikely.

8. Improvements to the intercept technologies: Both the file and IM PEP exist as modifications to existing data intercept technologies. While useful for a demonstration, a standalone PEP that can be more easily supported and deployed would add to the robustness of the SAMSON solution. This enhancement will require a low degree of research and a low-moderate degree of development for implementation.


Operational requirement: Possible.

9. More SAMSON services: In addition to the services defined above, there has been an identification of additional security services that could be of benefit in a SAMSON deployment, including: PKI-based encryption of data assets when disclosed to users and digital watermarking of disclosed data assets. Similar to enhanced labelling, this recommendation will have differing levels of effort depending on the type of service to be added to the SAMSON architecture. Assuming that the nature of the services to be deployed is well defined, this enhancement will require a low-moderate degree of research and a low-moderate degree of development for implementation.




The LOE defined above indicates that the remaining research and development components required for a fully operational deployment. Shown in Figure 9 is the level of research effort by a scientific authority for each of the nine items above against the operational need by the Canadian Forces. This figure shows the prioritization of the remaining work, and rough amount of effort.

Figure 9: Future-work remaining.

The y axis defined in Figure 9 define the level of effort (both R&D and engineering/demonstration) by the project team (L, M, H), while the x axis categories each capability in terms of operational need (L, M, H). In order to further understand what SAMSON remaining work areas need scientist time, and what areas can be pushed to industry for development, the nine work areas were further divided by maturity level (i.e., evaluate the maturity between pure theoretical research and simple engineering development). Each of the nine work packages are looked at individually and evaluated as to the scientific needs (i.e., long term research vs. transfer to industry). This action response for each work areas will assist a capital project exploiting SAMSON, define the work required, and general capital project activities to be completed in preparing for a Request for Proposal to industry.

3.2 Recommended action plan for follow on R&D activity

Figure 9 illustrates a rough estimate for the level of effort, and gives a prioritization for each of the remaining work packages. Each work package was then evaluated for its scientific content remaining—which work packages were researched. Each work package outlined above is assigned an action response in Table 5 below. These action-responses range from a long-term R&D project (low Technology Readiness Level) to a technology watch (industry to address issue). Table 5 defines what work should be kept within DRDC as a long term R&D effort, what work should be pushed to industry for demonstration (pilot projects/demonstrations), and what work should be left solely to industry.


Table 5: Action response.

ACTION RESPONSE RESPONSE DESCRIPTION

Long Term Research

There is a conscious decision, based on documented acceptance rationale, that this work package cannot be accomplished in a reasonable time frame (4–6yrs). A longer term R&D effort must be initiated.

Near Term Research This work package is sufficiently mature that a Technology Demonstration Project type of effort is required to mature the work package and demonstrate the capability.

Development/Implementation Effort

This work package has been partially demonstrated, but portions of this are insufficiently developed to be transferred to industry. This work package requires a specific focused Development effort that will reduce the risk exposure, by reducing either the overall R&D effort remaining or mitigate the operational need.

Transfer Transfer the work package to a third party. This party can be a prime contractor, sub-contractor, existing DND expertise or other government department.

Technology Watch

Conscious decision, based on documented acceptance rationale, to accept the associated level of work can be accomplished by industry, without engaging in any active R&D efforts to control it.

For each work package outlined in Section 3.1, these were examined with a specific focus on research effort required, and an action response was assigned:

1. Cross-Domain Data Exchanges: Near Term Research

The current SAMSON implementation has demonstrated a primitive cross-domain capability in the CAGE exercise. From this work certain issues have been identified but not addressed. This work requires significant R&D effort as input and incremental capability demonstration in order to address the work package. This work should remain within DRDC as a research project.

2. Native Exchange Support: Transfer

The current SAMSON implementation has demonstrated MAPI/RPC protocols in a lab setting for specific demonstrations; those are insufficient for an operational deployment. This effort will be required by National Defence, but requires minimal R&D support from the Scientific Authority. This work should be given to the capital project, with minimal oversight by the SA.

3. Encrypted File Search: Develop

Specific DND operational communities require this file search capability. This is a moderate to high amount of R&D effort, and requires a dedicated R&D task to accomplish this work.


This work requires minimal amount of Scientific Authority support and moderate contractor support. This work should remain within DRDC, but be developed by in-house contractors. Moderate oversight by the SA is required.

4. Data-Centric Database Protection: Transfer

This work has been demonstrated on a test database within a lab environment. The basic R&D concepts have been demonstrated, with a large amount of development work remaining. This work should be pushed to the contracting community, either by DRDC or a capital project that is exploiting the technology. This would require moderate oversight by the SA.

5. Logic-Based Policy Engine: Technology Watch

This work is nearly a commercial capability, and is being worked on by various commercial entities. This may need modification to work within a military environment, but can be transferred to a capable third party for implementation. This should not be done by DRDC or contractor supported by DRDC. Any capital project should require the COTS vendor to support this capability or something similar.

6. Improved Labelling of Data Objects: Develop

This work will depend on the operational needs assessment for a deployed SAMSON capability. Some R&D work is required because new labels and label standards have broad-spectrum impacts across the entire SAMSON infrastructure. This work should remain within DRDC, but be developed by in-house contractors. Moderate oversight by the SA is required.

7. Policy Enforcement Extensions: Technology Watch

This work will depend on the operational need for a deployed solution. This requires minimal Scientific Authority expertise and can be transferred to a capable third party to perform the work. This should not be done by DRDC or contractor supported by DRDC. Any capital project should require the COTS vendor to support this capability or something similar.

8. Improvements to the Intercept technologies: Technology Watch

This work will depend on the operational need for a deployed solution. This requires minimal Scientific Authority expertise and can be transferred to a capable third party to perform the work. This should not be done by DRDC or contractor supported by DRDC. Any capital project should require the COTS vendor to support this capability or something similar.

9. More SAMSON services: Develop

This work will depend on the operational needs assessment for a deployed SAMSON capability. Some R&D effort is required because new services will require slightly modified SAMSON capability for support. This work should remain within DRDC, but be developed by in-house contractors. Moderate oversight by the SA is required.


From this classification, an action plan table can be created for the defined SAMSON activities. This action plan is to define what pieces require scientist input, and what pieces can be contracted out. The action plan for SAMSON is shown in Table 6.

Table 6: Future work packages action plan.

Work Package

Policy-based Logic Engine

(5)

Policy Extensions

(7)

Improved Intercepts

(8)

Native Exchange Support

(2)

SAMSON Database Protection

(4)

Encrypted File Search

(3)

Improved Data Labeling

(6) More SAMSON

Services (9)

Cross Domain Data Exchange

(1)

Watch Transfer Develop/Implement

Near Term Research

Long Term

Research

As can be seen in Table 6, there is no remaining R&D component that is considered long term (Low Technology Readiness Level—TRL) R&D effort. The SAMSON team has matured the majority of risks and work packages over the last four years of development and demonstration. However, there are short to mid-term investment priorities that can serve to expand upon the work already demonstrated and will position the solution to meet immediate operational needs. These priorities and the level of GoC-sponsored Scientific Authority investment are identified in the next section.

3.3 Recommended research priorities

Figure 12 summarizes the defined areas of future work for the continued maturity of the SAMSON data-centric information protection model in the context of research priorities, defined in Table 7. The areas of research investment are presented in terms of high, medium, low and very low priority.


Table 7: Research priorities.

Research Priority Rationale

HIGH

High priority research items are defined as having a high operational need and a moderate-to-high level of effort. Specifically, high priority research items have a significant research component that will involve significant participation by the Scientific Authority assigned to guide the effort.

MODERATE Moderate priority items have a high operational need coupled with a moderate level of effort. The research commitment to the effort is low to moderate and a moderate involvement of the Scientific Authority is required.

LOW Low priority items have a moderate likelihood of meeting an operational need and have a low to moderate level of effort. There is minimal need for Scientific Authority involvement in the effort.

VERY LOW Very Low priority items have no anticipated operational need in the mid-level time frame. There is a low-to-moderate level of effort to implement the item and no Scientific Authority involvement is required.

The following diagram recreates the Figure 9, but with the recommended research priorities overlaid on the existing level of effort / operational priority.

Figure 10: Prioritized SAMSON unfinished work packages.

From this diagram, the remaining research priorities that require Scientific Authority support are:

1. Cross domain data exchange (1);

2. Data-centric database protection (4); and

3. Encrypted file search (3).


4 Lessons learned

The four primary lessons learned from SAMSON are: 1) the underestimation of secondary impact of mandated changes from Section 2.1; 2) the impacts of a TD project bridging to capital; 3) the impacts of capital approach to Intellectual Property (IP); and 4) a realistic expectation for project managers and the technical team of the time required to implement a technical solution.

Mandated changes from the Senior Review Board and Project Leader were challenging and difficult to implement, yet the changes produced key success factors of this project. The largest (and most important) of these mandated changes was the demand to accredit SAMSON for an operational network. Accrediting a research project for an operational system is difficult and time consuming. The accreditation process requires a stable baseline of hardware/software to accredit against, while research activities continue developing addressing problems. However this accreditation gave the credibility and demonstration platform to show the operational community the maturity and impact that SAMSON could offer. All of the mandated changes were critical to the success of SAMSON, despite the difficulties these changes caused.

Bridge-to-capital was a scope change that was underestimated in the project. The primary effects were planned for—increase in contract, project support required—but the secondary effects were not. The increase in signing authority, scrutiny by lawyers and detailed requirements for the contract of this size was significantly underestimated.

Bridging to capital brought out IP issues. Capital projects typically purchase commercial off the shelf (COTS) or military off the shelf (MOTS) products, where the IP is in the background and owned by the contractor. R&D projects build new items in which IP is in the foreground; typically DRDC pays for, and owns, the IP. The fair splitting of the IP for a contractor and R&D entity is one lesson learned by the project team in order to bridge-to-capital.

As the schedule was pressed in time, due to contracting delays from mandated changes in scope, the SAMSON team kept the original schedule and felt the development could be compressed to the first year of the TD, with the remaining years set aside for accreditation and testing. Due to programmatic reasons, this one year of development time was stretched out over three years, while the time required for accreditation and testing was not changed. This resulted in a large benefit to the project as sufficient time was inadvertently allowed a better technology solution to mature.

4.1 Lessons learned from scope change

Scope changes were typically the source of the largest budget and cost impacts and were carefully controlled during the project life cycle with formal scope and change management. Scope changes were mandated during the SAMSON project lifecycle and the impacts were seen within the figures previously shown. To be clear, the mandated changes were beneficial to the project, and helped provide greater impact to the CAF and exploitation opportunities to the project. The greatest mandated changes were: 1) demonstrate on a live operational network; 2) bridge-to-capital; and 3) full C&A is required.


Although the changes did not result in an adjustment to personnel or budget2, they were all key success factors for the project, and were highly recommended for future TDPs. The secondary effects of these changes must be planned for future TDPs with sufficient personnel (or contractors) and budget to achieve their goals.

In order to keep on budget, $1.2M was reallocated from the original SAMSON TDP R&D activities, towards contractor support to help manage the procurement process and C&A changes. These new mandates also resulted in delays.

In order to meet the mandated SAMSON project scope, the schedule was allowed to slip in order to address the increased procurement overhead. The bridge-to-capital requirement resulted in meeting with PWGSC and Directorate of Common Procurement System (DCPS) from DND (now Dil Proc). From these agencies a strategy was devised to allow an R&D project to bridge-to-capital using a contract that capital could exploit (instead of typically purchasing a product from a contractor). This resulting contract was for $20M, of which $3.6M was for R&D, $12M for Capital and the remainder as pre-authorized amendments. This increased contract value required higher level signing authorities, more detailed requirements and documentation, more legal scrutiny and much larger delays than what a TDP should encounter. A different approach would have been to use the user pay system at PWGSC; however, this would have only brought in marginal improvements. The contract SOW must be well written, with resulting evaluation criteria suitable for a $20M contract.

The C&A was another scope modification that resulted in increased expenses and delays. The C&A contractors required their own set of documents, testing had to be done in an approved lab, and changes managed. In addition, C&A could only occur against a known baseline, so all R&D activities had to stop in order to be stable for C&A (and its pre-requisite testing) to occur. This testing could not have been compressed or run in parallel with the development stage.

Nevertheless, the mandated modifications resulted in a much better project deliverables, documentation and technology maturity. One of the current success factors is the ability to show an accredited stable, tested system in an operational environment used by real operators where they can tangibly experience the benefits from the TDP. Since the technology is accredited, the project can be deployed on classified exercises in operational settings. With the contractual options, operators can look forward to other procurement options than purchasing MOTS/COTS.

4.2 Lessons learned from the bridge-to-capital mandate

Once the contractual and process issues were worked out, issuing an RFP on MERX (now BuyandSell.ca) was streamlined. With the contractual options, R&D was affected both positively and the negatively. Success or failure of R&D projects have little stake in operations. Typically the CAF is interested in collecting requirements, seeing the possibilities of the technology and purchasing the relevant capability from industry. Any other R&D project set to deliver to the same requirements could have been a threat to SAMSON. The benefit of the SAMSON contractual option is that capital can be used to address deficiencies which need to be exploited. SAMSON provides the vehicle to help transition the technology to the client.

2 19th September 08, C&A resulted in 1.5 worth of extra PY funding for PM support and C&A.


The project team had to first understand the capital project process and its constraints; that in addition to the key drivers for R&D. This revealed the R&D “products” that could be transitioned to capital, and those that could be purchased as COTS/MOTS. Procurement and Operations and Maintenance (O&M) costs were samples of the overhead one must consider when faced with the dilemma of purchasing R&D technology or a fully supported COTS/MOTS solution.

The project team had to repeatedly communicate and justify SAMSON as a R&D project, how it was different from, yet worked with, existing technology to produce a better overall security solution. Senior Review Boards criticised the weakness of the project because its components were already built by industry. The criticisms were against testing, standards, accreditation evidence, technical shortcomings and lack of clear, strong sponsor support. From this, a key learned lesson is to avoid competing with industry. Industry has larger budgets, resources and better marketing. Clear delineation between R&D efforts and COTS products must be established. Any appearance of overlap will be questioned by PWGSC, procurement and management. If a COTS product exists, then we should be using it and leaving that portion to industry to develop. Another learned lesson is to develop a trust relationship and partner with a capital project. Capital projects tend to leverage and spread the cost among multiple partners. For the TDP, the project team had to market and communicate the advantages of the SAMSON project over and above what the team could purchase off-the-shelf, including addressing any O&M cost increases. At an operational exercise, the R&D advantages must then be demonstrated and highlighted as enhancements to current industry abilities.

Another learned lesson is that future TDP projects should give points/preference to contractors who have delivered products when selecting a prime contractor. The ability of a contractor to support exploitation through a COTS product is greatly enhanced when using a vendor that has experience in MOTS or COTS products. The selection of a vendor to develop SAMSON without a product base eventually resulted in an excellent technical system, but not a COTS product with existing, demonstrated C&A deliverables that could be supported in a product lifecycle.

4.3 Lessons learned from Intellectual Property (IP)

Intellectual property is treated in different ways by capital and R&D projects. Typically capital projects purchase MOTS/COTS where the background IP is owned by the contractor. R&D projects, on the other hand, create IP and pay for its development; therefore the R&D entity will own the IP. SAMSON split the IP in to two: one where the architecture, design and interfaces were owned by the crown; and the other where the specific code base was owned by the contractor. In this model, any contractor could build a version of SAMSON, even if the contractor were bidding on a capital project.

This model has worked well for the SAMSON research efforts, as it allows the project team to share the architecture with our NATO allies to continue the R&D effort, while the codebase could be turned into a product. The SAMSON Prime contractor has “first developer” advantages to building product code over others that receive the architecture documentation.

This IP model has not worked well for contractors that own products that are similar to SAMSON capabilities. A prime contractor that has a product which provides similar functionality would be less likely to bid on a contract where it had to give up a portion of its IP or undermine an existing


product base. For example, a contractor with a network based protection product is less likely to build an open source data centric protection product that may compete with their existing product base. A prime contractor that only provides professional services has no interest in productizing or commercialization and will bid on a SAMSON contract. Their interest lies with selling professional services, and will be interested in selling the IP after they have delivered the professional services. Companies with products were willing to invest to extend their product base (i.e., Titus Labs desktop classification), companies that felt SAMSON may replace their existing products (by DRDC publishing architecture and design documents) were not interested or hostile to participating in SAMSON.

Overall the IP lessons learned should be refined for any follow-on projects. It is recommended for future large projects that DRDC maintain control of the architecture, design, interfaces and software/hardware configuration and any implementation configuration documentation, and give away much of the remaining IP, such that anyone can build a solution and exploit the technology. This can be contradictory to the previous stated goal in Section 4.2 of future TDP projects should give points/preference to contractors who have delivered products when selecting a prime contractor. If COTS/MOTS product boundaries align with DRDC-owned interface specification, then this requirement is easily met. If COTS/MOTS product boundaries cross over DRDC owned interface specification, then product companies will be protective of their IP, and this IP split must be re-evaluated.

SAMSON provided a novel way of protecting data—at the data asset level. Companies that provided services within the network boundary were willing to work with DRDC, where companies that saw potential threat of the technology replacing their products were not.

4.4 Lessons learned from contractor size

The project team had planned to spend the first year to design and build SAMSON, and then the remaining two years to demonstrate and accredit its technology. The project plan showed the first year was to use a large cash phase to demonstrate the project quickly, and then two smaller years to accredit and transition the project. This resulted in a large team of contractors and a heavy project management overhead when the project kicked off.

For a firm fixed price project, this strategy would have been acceptable, as the contractor could manage the costs of the project and deliver to the SOW/contract specifications. However, the strategy with a large team of contractors was not acceptable with an R&D contract that was based on progress payments and a ceiling price on deliverables. During the first year, with an overall budget of the project reduced, a much smaller team of key people were formed. This resulted in a more agile development environment in which the Scientific Authority could look at the various options. It is recommended that projects aim to have a small (contractor) project team of key people and deliver over a longer schedule. This allows various components of the project plan to mature, be tested and evaluated by operators.

In addition, C&A process requires time and a set of boundaries (documents, architecture, detailed design, test plan, description of what is being built) against which to test and certify. Any changes to the baseline boundaries results in the C&A process to be re-performed. For an R&D project whose development may change, the C&A process could become a difficult process. The


SAMSON TDP is essentially a set of security ‘blocks’—one uses in the components one needs. Flexibility does not work well for the C&A process. SAMSON succeeded because we designed a modular, service oriented architecture on a security bus so that each component could be removed, revised and a new version could be built and upgraded—all in one documented architecture (Annex B Document deliverables [1], [2]). This allowed development to continue on specific components of SAMSON, while testing/accreditation progressed on other components. In addition, any component of SAMSON can be replaced by a similar product from another vendor with no impact to the remaining infrastructure (products would have their own C&A evidence and process). The use of modular service oriented architecture allowed the development to be flexible to the capital project’s needs with minimal impact to the approved baseline. It is recommended that other TDPs use a modular, service oriented architecture in order to minimize impacts of accreditation, change requests, and maximize flexibility. For SAMSON, the security bus, PEP’s and unique SAMSON components were accredited. The COTS products that connected to SAMSON were not touched.


5 Observations and recommendations

To implement the bridge to a capital project mandate, an integrated product team of capital project, procurement and R&D experts was assembled. The team shaped the project scope during the identification, development and procurement stages of the project. SAMSON had one procurement officer and one Public Works and Government Services Canada officer to help with the contracting strategy and procurement package in addition to the DRDC project officers (one Project Manager (PM), one Deputy/PM contractor and one Scientific Authority). The team produced a unique contract model that capital projects could use for integrating R&D projects. The contract model has a side effect of budget inflation for project management by as much as + 20%3 and a longer-term and more formal C&A during the development stages of the project. It is recommended that this contractual exploitation model be extended further to include any contractors supporting the project to continue their support during the exploitation phase. This includes:

1. Prime: company employed to build SAMSON;

2. Sub: any company/person who reports directly to the prime; and

3. Support (PM, technical, accreditation): any person/company that reports to DRDC.

The biggest risks and impacts to SAMSON were externally generated, for whom one could not have planned. The project was delivered on budget and met the mandated scope of work but at the expense of delaying the schedule. This also reduced the scientific R&D planned during the project development phase, with the savings re-allocated to cover the scope modifications and added contractor support. A contract option with duration of at least 50% of the originally planned activities could have been included to allow for exploitation and support during a (potentially delayed) development cycle.

The impact of C&A and the resulting change in scope was a long term benefit to the project. The scope changes added delays and costs to the project, however the longer term benefits of the formal C&A process greatly added to the client support and acceptance of the technology. It is highly recommended for future TDPs to add formal accreditation on an operational network (exercise or live) with a live demonstration to its final project deliverables. This change may likely add six months to one year C&A delay to a TDP schedule and 1.5 PY cost for testing, accreditation and documentation to the resources.

The bridge-to-capital also resulted in an increase in scope, with delays and costs added to the project. The addition of $13M in contract options resulted in the following changes: 1) delayed the contracting approval process; 2) increased number of signing authorities; 3) increased the number of vendors looking at the PWGSC solicitation and the overall scrutiny by the vendors of the bid; 4) increased the PWGSC contracting authority and legal scrutiny; and 5) increased the

3 This estimate comes from: 1) ongoing contractor support cost; 2) delay’s due to high value contract approvals; 3) increased PWGSC oversight due to dollar value; and 4) increased internal management oversight.


DRDC management signing authority and number of people reviewing the proposal. The next TDP that is mandated to go through the process of “exploit to capital via a contracting vehicle” mandate should include in its plan a 1–2 year extension to the approval process with a 1 PY increase in project management overhead for a $20M contract size.

5.1 Personnel costs

A bridge-to-capital requires more development and less research. Capital projects require low risk procurement, with well-defined long-term maintenance and support costs. This means a significant portion of the research project, at the end of the development phase, is needed to define the maintenance and support costs. The Scientific Authority’s role becomes less relevant once the C&A process starts and the research portion ends. This does not mean there is no remaining research, only that the C&A process requires a firm stable baseline (hardware and software) where no further modifications are allowed. Any further R&D work must be on a new version that is not part of the C&A process.

5.2 Technology costs

Technology progresses as a TDP develops from TRL 5–6 to TRL 7–8. This is both a risk and an opportunity for the project team. A periodic review of technology relevant to the TDP is required to ensure the TDP remains relevant; what additional technologies can be taken advantage of and what is the industry doing with the science of the TDP.

An example of a risk, as the technology matures the project team could see ideas directly from the TDP demonstrations feed into industry. For example in SAMSON, a company took the proposed data centric protection approach and used this for its endpoint enforcement of labeling. The endpoint labeling was specifically excluded from the SAMSON scope, but due to the contractor’s product, this was seen as replacing SAMSON. The endpoint (desktop) enforcement was seen as replacing SAMSON, as this is what the user experienced when using any endpoint. This distinction must be watched and clarified with stakeholders as it happens.

As an example of an opportunity, during the development of SAMSON, new technologies were discovered that supplemented the SAMSON capability. The SAMSON database protection leveraged research out of Massachusetts Institute of Technology (MIT) that was published as open source code. SAMSON database protection leveraged this code, inserted SAMSON policy access control and key management and demonstrated database protection within months. A technology review conducted yearly is recommended for TDPs to see what our allies and industry are doing and in what areas industry has progressed.

5.3 Time

Large contractual options will scale up processes such as procurement, relations with capital projects, PWGSC approvals, and DND approvals. This requires increased government or contractor resources to manage the processes and to create the necessary documents and briefs. Since any one of these process could delay a project, each process has to be monitored and managed diligently. The SAMSON options and its approval processes were underestimated and


under staffed. Contractor resources were used to provide the extra manpower to compensate for lack of resources in managing the process and documenting development, but the schedule slip could not be compensated.




References

[1] D. Charlebois, G. Henderson, “SAMSON Technology Demonstrator Architectural Design Document”, March 2013, DRDC – Ottawa Research Centre, DRDC-RDDC-2012-C3.

[2] D. Charlebois, G. Henderson, “SAMSON Technology Demonstrator Detailed Design Document Phase IV SD004”, August 2013, DRDC – Ottawa Research Centre, DRDC-RDDC-2013-C5.

[3] D. Charlebois, G. Henderson, “SAMSON Technology Demonstrator Final Report”, October 2013, DRDC – Ottawa Research Centre, DRDC-RDDC-2014-C101.




TDP significant events Annex A

During the course of the project, the TDP experienced many significant events that impacted project Scope, Budget or Schedule. These events are arranged chronologically below. Project milestones are bolded.

1. April 2005—Project approved as TDP

2. March 2006—PIP, Charter signed

3. March 2006—Scope change: Demonstrate to operational network

4. September 2006—Scope change: Bridge-to-capital mandate change4

5. December 2008: Contract Award5

6. March 2009—Scope change: Include external C&A

7. July 2009—Budget (schedule) change: Drastic cash phasing redistribution:

a. September 2009—Budget change: Termination of project for convenience; and

b. October 2009—Budget change: Reduced cash phasing of deliverables.

8. September 2009—Scope change: Increased operational demonstrations/exercises:

a. September 2010—Empire Challenge (EC) 2010 exercise;

b. June 2011—Coalition Warrior Interoperability Exercise (CWID);

c. July 2011—Empire Challenge (EC) 2011 exercise; and

d. November 2012—Coalition Attack Guidance Experiment (CAGE).

9. August 2010—Phase 2 start

10. December 2010—Scope change—Audit event generation added to scope

11. June 2011—Scope change: Capital exploitation projects closed:

a. August 2011—Shared Services mandate announced6;

4 Based on briefing note in September 2006: Scope changed from 6M TDP to a 6M TDP + 14M unfunded option contract. 5 Three month delay due to election/signing authority of SAMSON at minister level. 6 Shared Services appeared as a risk item to the EISE capital project SRB in April 2007.


b. June 2011—Enterprise Information Security Environment (EISE) project cancelled; and

c. February 2012—Cross Domain Exchange Network Architecture (XENA) project cancelled.

12. July 2011—Phase 3 start

13. Summer 2012: Schedule change: Strategic Review and Deficit Reduction Action Plan:

a. Scope change: Information Protection and Assurance (IPA) program cancelled; and

b. Scientific Authority re-assigned.

14. November 2012: Final demonstration of SAMSON at CAGE exercise

15. December 2012: Phase 4 start

16. March 2012: End of core contract

17. October 2013: Final deliverables submitted, including C&A


Document deliverables Annex B

SAMSON defined documents as part of the Data Item Deliverable (DID) and Contact Deliverable Requirements List (CDRL) as part of the contract are defined in Table B.1. Interim deliverables are project management documents under the PM xxx series, while formal technical documents are SD xxx and demonstrations are DM xxx.

Table B.1: SAMSON DID/CDRL document list.

# DID Title Delivered

1 PM 001 Project Management Plan X

2 PM 002 Meetings agendas and minutes X

3 PM 003 Progress Review Report X

4 SD 001 System Requirements Specification document <N/A>

5 PM 004 Configuration Management Plan X

6 PM 005 Requirements Management Plan X

7 SD 002 Architectural Design Document [1] X

8 SD 003 Test Design document X

9 SD 004 Detailed Design Document [2] X

10 PM 006 Development Phase Plan X

11 SD 005 Experiment Reports X

12 SD 006 Trial Reports X

13 SD 007 System HW, SW and documentation X

14 SD 008 C&A Report X

15 DM 001 Demonstration Material X

16 PM 007 Final Report [3] X

17 PM 008 Transition Plan <N/A> 18 PM 009 Designated Transition Plan <N/A>

19 SD 009 Implementation Document X




Accreditation evidance Annex C

Testing was done at each stage, with the original Statement of Sensitivity and Threat and Risk assessment done through the Canadian Security Establishment (CSE). The final C&A evidence folder included:

1. SAMSON_SD-003_TD_FinalVersion_31Mar13.doc

2. SD002 SAMSON Architectural Design Document_v3 06.docx

3. SAMSON Conops 2013 v1.03 .doc

4. SAMSON_TD_Conceptual_TRA_v2.0_Final_30-06-09-1.doc

5. SAMSON_TD_SoS_v1.0_30-06-09.doc

6. SAMSON CA Plan Nov2011 V1.3.1.doc

7. DRDC_SAMSON_ST_1April13.docx

8. CAGE II - Canadian AAR.ppt

9. CONSOLIDATED AAR - EC 11 (18 Sept 11).pdf

10. CWID 2011 = Final Report (less trial Info) = Final Draft (06 Oct 11).doc

11. sd_006_trial_report_002.pdf

12. CAGE II Cyber LOE final_v5.doc

C&A, as of October 3, 2013 is ongoing. It includes a refresh of the TRA/SoS and final accreditation of the C&A document set by a Security Analyst at DIM Securdir.

The test results are part of the formal deliverable SAMSON_SD-003: “Secure Access Management for a Secret Operational Network (SAMSON) Technology Demonstrator (TD) SD-003 Test Design Document”.

Further, mapping of SAMSON to the ITSG-33 security controls catalogue was completed to produce the table in Figure C.1.


Figure C.1: CSEC ITSG-33 comparison.

Numbers of Controls in ITSG-33 and related profiles:

Total 619

PA Profile 276 (profile PA, L, L)

PB Profile 391 (profile PB, M, M)

Secret Profile 433 (profile Secret, M, M)


List of symbols/abbreviations/acronyms/initialisms

AAR After Action Report

C&A Certification and Accreditation

C-Net Classified Network

C2 Command and Control

C4ISR Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance,

CAF Canadian Armed Forces

CAGE Coalition Attack Guidance Experiment (CAGE)

CANUS Canadian/USA

CDRL Contact Deliverable Requirements List

CEO Canadian Eyes Only

CFD Chief of Force Development

CFEWC Canadian Forces Electronic Warfare Centre

COSW Cyber Operations and Signals Warfare

COTS Commercial Off The Shelf

CryptDB Cryptographic Database

CSE Canadian Security Establishment

CSNI Consolidated Secret Network Infrastructure

CTDC Classified Test and Development Centre

CWID Coalition Warrior Interoperability Exercise

DAR Directorate of Air Requirements

DCPS Directorate of Common Procurement System

DG Cyber Director General Cyber

DID Data Item Deliverable

DJC4ISR Director Joint C4ISR Requirements

DLR Directorate of Land Requirements

DMR Directorate of Maritime Requirements

DND Department of National Defence

DRDC Defence Research & Development Canada

DSTKIM Director Science and Technology Knowledge and Information Management


EC Empire Challenge

EISE Enterprise Information Security Environment

FTE Full Time Equivalent

IA Information Assurance

ICAM Identity Credential and Access Management

IM Instant Messaging

IP Intellectual Property

IPA Information Protection and Assurance

IT Information Technology

ITSG-33 IT Security Guidance

LOE Level of Effort

MAPI Messaging Application Programming Interface

MIT Massachusetts Institute of Technology

MOTS Military Off The Shelf

NATO North Atlantic Treaty Organization

OR Operational Requirements

PEP Policy Enforcement Point

PIP Project Implementation Plan

PKI Public Key Infrastructure

POP3 Post Office Protocol 3

PWGSC Public Works and Government Services Canada

R&D Research & Development

RAD Rapid Application Development

RFP Request for Proposal

RPC Remote Procedure Call

SA Scientific Authority

SAMPOC Secure Access Management Proof of Concept

SAMSON Secure Access Management for SECRET Operational Networks (FY05 to FY10)

SAMSON Secure Access Management for Secure Operational Networks (FY10 to FY15)

SMTP Simple Mail Transfer Protocol

SOW Statement of Work

SRB Senior Review Board


SSC Shared Services Canada

SS (EPA) Synopsis Sheet Effective Project Approval

TD Technology Demonstration

TDC Test and Development Centre

TDP Technology Demonstration Project

TRL Technology Readiness Level

VCDS Vice Chief of Defence Staff

XACML eXtensible Access Control Markup Language

XENA Cross Domain Exchange Network Architecture



DOCUMENT CONTROL DATA (Security markings for the title, abstract and indexing annotation must be entered when the document is Classified or Designated)

1. ORIGINATOR (The name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g., Centre sponsoring a contractor's report, or tasking agency, are entered in Section 8.) DRDC – Ottawa Research Centre Defence Research and Development Canada 3701 Carling Avenue Ottawa, Ontario K1A 0Z4 Canada

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

UNCLASSIFIED

2b. CONTROLLED GOODS

(NON-CONTROLLED GOODS) DMC A REVIEW: GCEC DECEMBER 2013

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S, C or U) in

parentheses after the title.) Secure Access Management for Secure Operational Networks (SAMSON) : Project Management Closeout Report

4. AUTHORS (last name, followed by initials – ranks, titles, etc., not to be used) Simmelink, D.; Charlebois, D.; Carruthers, B.; Henderson, G.

5. DATE OF PUBLICATION (Month and year of publication of document.) March 2016

6a. NO. OF PAGES (Total containing information, including Annexes, Appendices, etc.)

62

6b. NO. OF REFS (Total cited in document.)

3 7. DESCRIPTIVE NOTES (The category of the document, e.g., technical report, technical note or memorandum. If appropriate, enter the type of report,

e.g., interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.) Reference Document

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development – include address.) DRDC – Ottawa Research Centre Defence Research and Development Canada 3701 Carling Avenue Ottawa, Ontario K1A 0Z4 Canada

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

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

10a. ORIGINATOR’S DOCUMENT 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-2016-D008

10b. OTHER DOCUMENT NO(s). (Any other numbers which may be assigned this document either by the originator or by the sponsor.) 05BS, W7714-08FE01

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by security classification.)

Unlimited

12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspond to the Document Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcement audience may be selected.)) Unlimited

13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), (R), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual.)

This report documents the final status of the Secure Access Management for Secure Operational Networks (SAMSON) project.

Initial demonstration of the SAMSON was planned for the lab, but in order to bring in more operational experience to the project team, a live operational environment was demonstrated in September 2010. The final demonstration, with SAMSON fully integrated into an exercise, was at the Coalition Attack Guidance Experiment (CAGE) in November 2012.

SAMSON has achieved the majority of its demonstration goals despite the roadblocks it encountered. SAMSON has demonstrated:

data-centric protection of files, email, chat, web, C2 and database;

file, email and chat on an accredited, live operational environment;

certification and accreditation of SAMSON for an operational network; and

created exploitation options for capital project, exploitation is currently ongoing.

SAMSON has demonstrated data-centric information protection on an existing unmodified operational network. The integration of access management technologies and protection mechanisms can lead to hosting multi-caveated information on a single network. Adopting SAMSON data-centric security results in: an improved security posture; enhanced auditing; enhanced information sharing; and minimal impact to the operator. SAMSON can collapse caveats onto an existing classified network and significantly reduce costs of the Canadian Armed Forces maintaining multiple independent Canadian Eyes Only (CEO) networks.

The exploitation manager (Director of Joint Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (DJC4ISR) has activities ongoing to exploit SAMSON and stand up a capital project. The activities to kick off a capital project are being supported with existing SAMSON project support contracts. The prime contractor, Bell Security Solutions, has licenced the Intellectual Property to a start-up company to create a product based on the SAMSON architecture and resulting standards.

The most significant lesson learned from the project is: 1) using a sizeable contract to bridge-to-capital is an excellent way to exploit the project deliverables; and 2) projects include demonstration on a live operational network.

---------------------------------------------------------------------------------------------------------------

Le projet SAMSON a démontré son approche de la protection de l’information centrée sur les données sur un réseau opérationnel existant auquel on n’a apporté aucune modification. L’intégration de technologies de gestion d’accès et de mesures de protection peut entraîner l’hébergement d’information comportant de multiples restrictions sur un même serveur. L’adoption de cette approche, axée sur les données, entraîne une amélioration de la sécurité, de

la vérification et du partage d’information, tout en ayant une incidence minimale sur l’exploitant. SAMSON est en mesure de réduire ces restrictions sur un réseau classifié existant, en plus de diminuer considérablement les coûts associés au maintien de nombreux réseaux secrets réservés aux Canadiens (RAC), coûts assumés par les Forces armées canadiennes.

Ce rapport documente l’état final du projet de gestion de l’accès sécuritaire aux réseaux opérationnels secrets (SAMSON). Celui-ci a atteint la majorité de ses objectifs de démonstration, malgré les obstacles qu’il a dû surmonter. Plus précisément, il a démontré :

la protection, axée sur les données, des fichiers, courriels, sessions de clavardage, du Web des éléments de C et C et de bases de données;

celle de fichiers, de courriels et de sessions de clavardage dans un environnement d’exploitation agréé;

la certification et l’accréditation du projet SAMSON pour un réseau opérationnel;

la création de possibilités d’exploitation pour un projet d’immobilisation. Cette exploitation est en cours.

Ce projet a été approuvé en mars 2005 et s’est terminé en octobre 2013. On avait prévu de procéder à la démonstration initiale des capacités de SAMSON en laboratoire. Toutefois, on a réalisé celle-ci dans un environnement d’exploitation en septembre 2010, afin que l’équipe de projet acquière plus d’expérience opérationnelle. La démonstration finale, au cours de laquelle SAMSON était pleinement intégré à l’exercice effectué, consistait en l’Expérience d’exécution de l’attaque de la coalition (CAGE) qui s’est déroulée en novembre 2012.

On a maintenu le budget du projet qui comportait un ensemble d’activités de R et D moins nombreuses que prévu. Au final, le projet SAMSON a coûté 6,753 M$, comparativement au budget de 6,616 M$. L’effectif du projet étant généralement insuffisant, il a donc fallu faire appel à des entrepreneurs en supplément aux ressources de l’équipe de projet. Il manquait environ une AP par année.

Aucune activité de suivi n’est prévue dans le cadre du cyber programme de science et technologie. Le gestionnaire d’exploitation actuel (Directeur-Commandement, contrôle, communications, informatique, renseignement, surveillance et reconnaissance, C4ISR) dirige les opérations afin d’exploiter la solution SAMSON et de mettre sur pied un projet d’immobilisation. On utilise les contrats de soutien du projet SAMSON existants afin de soutenir ces activités de mise sur pied. L’entrepreneur principal, Bell Security Solutions, a octroyé une licence de propriété intellectuelle à une entreprise en démarrage en vue de créer un produit fondé sur l’architecture de SAMSON et sur les normes qui en découlent.

Les plus importantes leçons apprises au cours de ce projet sont : 1) de faire appel à un contrat important de jonction vers l’immobilisation constitue un excellent moyen de tirer parti des livrables du projet; 2) de suivre la recommandation d’inclure, dans les projets de démonstration de technologies (PDT) à venir, une démonstration effectuée sur un réseau opérationnel en permanence. Selon ces deux approches, il faut assurer la répartition suffisante des ressources en personnel (de l’entrepreneur ou de l’État), du budget et du temps de façon à gérer les processus d’acquisition ou d’accréditation du ministère de la Défense nationale (MDN). Ceux-ci nécessitent tous deux des documents et livrables particuliers en vue d’exploiter la technologie.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus, e.g., Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified. If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.) SAMSON; Project Closeout Report; data-centric; Secure Access Management; PBAC; ABAC; SAMPOC

Date post:	07-Jul-2021
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

Secure Access Management for Secure Operational ...Le projet SAMSON a démontré son approche de la...

Documents