IT Security Directive for the Management of CSE …...UNCLASSIFIED IT Security Directive for the...

UNCLASSIFIED

IT Security Directive for the Management of

CSE-Approved Cryptographic Equipment and Key to Secure a Telecommunications Network

ITSD-04A

UNCLASSIFIED

IT Security Directive for the Management of CSE-Approved Cryptographic Equipment and Key to Secure a Telecommunications Network (ITSD-04A)

January 2017

Foreword The IT Security Directive for the Management of CSE-Approved Cryptographic Equipment and Key to Secure a Telecommunications Network (ITSD-04A) is an UNCLASSIFIED publication issued under the authority of the Chief, Communications Security Establishment in accordance with the Treasury Board of Canada Secretariat (TBS) Policy on Government Security.

This publication supersedes ITSD-04, which must be destroyed in accordance with departmental procedures for the disposal of government information.

General inquiries and suggestions for amendments are to be forwarded through departmental and enterprise communications security channels to COMSEC Client Services at the Communications Security Establishment.

The Communications Security Establishment will notify users of changes to this publication.

Effective Date This directive takes effect on date of signature.

Original signed on January 30, 2017 by Scott Jones, Deputy Chief, Information Technology Security

Reproduction and Distribution Physical or electronic copies of this publication, in part or in whole, may be made for official Government of Canada use only.

UNCLASSIFIED


January 2017 iii

Summary of Changes from ITSD-04 to ITSD-04A Although all users of cryptographic networks should read this Information Technology Security Directive (ITSD) in its entirety, the following articles are highlighted as major changes to the management, control and use of cryptographic equipment and key approved by the Communications Security Establishment (CSE) and used to secure telecommunications networks.

Reference Change

Throughout directive Change to the title

The introduction of the following: • Network Communities

• Controlling Authority (ConAuth)

• Command Authority (CmdAuth)

• Product Requester (PR)

• “Enterprise” cryptonets

• Cryptonet Management vs Key Management

• IT Security Directive for Cryptographic Key Ordering (ITSD-09) (replacement for ITSG-13)

• Government of Canada Key Management Infrastructure (GC KMI) terminology

• Symmetric and asymmetric terminology to identify cryptographic key formats

• Updated Key Material Support Plan (KMSP) direction

Article 1.9 New article providing clarity on the Distribution of Information and Data about CSE-Approved COMSEC Systems and Services.

NOTE: It is the responsibility of the user to apply all applicable security requirements identified in this ITSD.

UNCLASSIFIED


January 2017 iv

Table of Contents Foreword ............................................................................................................................................. ii

Summary of Changes from ITSD-04 to ITSD-04A ............................................................................ iii

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

1.1 Purpose ........................................................................................................................... 1 1.2 Scope .............................................................................................................................. 1 1.3 Context ............................................................................................................................ 1 1.4 Network Communities ..................................................................................................... 1 1.5 Compliance ..................................................................................................................... 2 1.6 Conflict Resolution .......................................................................................................... 2 1.7 Requests for Exception or Waiver ................................................................................... 2 1.8 Contact Information ......................................................................................................... 2 1.9 Distribution of Information and Data about CSE-Approved COMSEC Systems and

Services .......................................................................................................................... 2

2 Roles and Responsibilities...................................................................................................... 3

2.1 Communications Security Establishment ........................................................................ 3 2.2 Departmental COMSEC Authority/Enterprise COMSEC Authority .................................. 4 2.3 Cryptographic Network – Controlling Authority/Command Authority ............................... 5 2.4 Product Requester........................................................................................................... 6 2.5 Role Assignment Restrictions .......................................................................................... 6 2.6 Cryptographic Network – Members ................................................................................. 6

3 Cryptographic Networks .......................................................................................................... 6

3.1 General ............................................................................................................................ 6 3.2 COMSEC Service Models ............................................................................................... 6 3.3 Types of Cryptographic Networks.................................................................................... 7

4 Establishing and Closing a Cryptographic Network ............................................................. 8

4.1 Establishing a Cryptographic Network ............................................................................. 8 4.2 Key Material Support Plan ............................................................................................... 9 4.3 Closing a Cryptographic Network .................................................................................. 11 4.4 Creating a Compound Cryptonet ................................................................................... 12

5 Cryptographic Network Management ................................................................................... 12

5.1 General .......................................................................................................................... 12 5.2 Cryptoperiod Extension ................................................................................................. 13 5.3 Supersession Rate ........................................................................................................ 14 5.4 Compromise Recovery and Risk Management ............................................................. 15 5.5 COMSEC Emergency Plan ........................................................................................... 16

6 Audit Requirements ............................................................................................................... 16

7 Cryptographic Network Support Training ............................................................................ 16

7.1 General .......................................................................................................................... 16

UNCLASSIFIED


January 2017 v

8 COMSEC Incident Reporting ................................................................................................. 16

9 References .............................................................................................................................. 17

9.1 Abbreviations, Acronyms and Initialisms ....................................................................... 17 9.2 Glossary ........................................................................................................................ 18 9.3 COMSEC User Portal .................................................................................................... 21 9.4 Communications Security Establishment Web Site....................................................... 21 9.5 Bibliography ................................................................................................................... 22

Annex A Developing and Updating the Key Material Support Plan ..................................... A-1

A.1 General ........................................................................................................................ A-1 A.2 Prerequisites................................................................................................................ A-1 A.3 Roles and Responsibilities .......................................................................................... A-2

Appendix A – to Annex A Key Material Support Plan Template ............................................... A-4

List of Tables Table 1 – Contact Information for COMSEC Offices ............................................................................ 2 Table 2 – KMSP Roles and Responsibilities ..................................................................................... A-2

List of Figures Figure 1 – Compound Cryptonet ......................................................................................................... 12

UNCLASSIFIED


January 2017

1 Introduction

1.1 Purpose This directive provides the minimum security requirements for the management, control and handling of cryptographic equipment and key approved by Communications Security Establishment (CSE) and used to protect classified and PROTECTED C information and data on a telecommunications network.

1.2 Scope This directive focuses on the management and security of high-assurance cryptographic equipment and key used to cryptographically secure a telecommunications network for classified and Protected C information or data. For the purpose of this directive, a telecommunications network secured with CSE-approved cryptography will be called a cryptographic network (cryptonet).

Business intake activities (i.e. organization, management and operations) of an Information Technology (IT) network are out the scope of this directive and remain the responsibility of the network’s Information Technology Security Coordinator (ITSC).

NOTE: Throughout this document, the term “cryptographic key” will be referred to as “key”. The term “key” is used to refer to all forms of physical or electronic cryptographic key. It is used as a singular and plural term.

1.3 Context This directive supports the Policy on Government Security (PGS) and the Directive on Departmental Security Management (DDSM) and should be read in conjunction with the following publications:

• IT Security Directive for the Control of COMSEC Material in the Government of Canada (ITSD-03A);

• IT Security Directive for Cryptographic Key Ordering (ITSD-09); and

• Directive for Reporting and Evaluating COMSEC Incidents Involving Accountable COMSEC Material (ITSD-05).

1.4 Network Communities Cryptonets are based upon a requirement to communicate in closed groups. For the purposes of this directive, a cryptonet community is a set of users with a common interest and a need-to-know who share information securely using the same interoperable cryptographic key.

The simplest cryptonet is established servicing a single operational activity and is implemented using End Cryptographic Units (ECUs) with a specific symmetric key “short title” or asymmetric key “partition code”.

In some complex environments where Controlling Authorities (ConAuths) or Command Authorities (CmdAuths) need to establish information sharing between two or more cryptonets, a third negotiated linking key can be used. This linking of cryptonets is referred to as a “compound cryptonet” and in such a case, one of the participating members must take formal management control of the link as the ConAuth/CmdAuth.

Cryptonets may also be established as telephony cryptonets where mobile or fixed voice/data exchange between individuals is required.

UNCLASSIFIED


January 2017 2

1.5 Compliance Compliance with this directive is the responsibility of Government of Canada (GC) departments and enterprise services organizations requiring CSE-provided key in support of CSE-approved cryptographic solutions. Non-compliance may result in a delay of key delivery and support services.

1.6 Conflict Resolution Any conflict encountered between this ITSD and other national (e.g. other ITSDs, PGS and DDSM) or international (e.g. International Traffic in Arms Regulations [ITAR]) publications must be submitted to COMSEC Client Services (CCS) for resolution.

1.7 Requests for Exception or Waiver A request for an exception (substitution) or a waiver (temporary exemption from a specific requirement) must be submitted by the Departmental COMSEC Authority (DCA) or Enterprise COMSEC Authority (ECA) in writing, and with a justification, to CCS for approval.

NOTE: CCS periodically (annually, at a minimum) reviews exceptions for operational suitability and risk, and assesses progress towards the elimination of waivers.

1.8 Contact Information The following table contains contact information for offices that provide COMSEC support to users.

Table 1 – Contact Information for COMSEC Offices

COMSEC Client Services

Telephone: 613-991-8495

Secure Fax: 613-991-8565 [email protected]

Crypto Material Assistance Centre (CMAC) and National Central Office of Record (NCOR)

Telephone: 613-991-8600

Fax: 613-991-7440

Secure Fax: 613-998-5686

[email protected]

NOTE: Unless otherwise specified, CSE’s telephone and secure fax contact numbers listed are attended Monday to Friday, from 8 a.m. to 4 p.m. Eastern Time.

1.9 Distribution of Information and Data about CSE-Approved COMSEC Systems and Services

Information and data, in part or in whole, about CSE-approved COMSEC systems and services controlled by the GC or by a GC sponsored organization may be distributed electronically or physically.

NOTE: In all cases, distributed extracts must be labelled with the appropriate security classification.

mailto:[email protected]


UNCLASSIFIED


January 2017 3

1.9.1 Electronic Distribution Information and data about CSE-approved COMSEC systems and services must be distributed as follows:

• PROTECTED C and CONFIDENTIAL up to TOP SECRET – disseminated electronically on GC networks using CSE-approved encryption capabilities. This includes secure telephony, facsimile and network services where the communications service must be accredited to a level commensurate with the classification of the information being processed;

• PROTECTED B – disseminated electronically on GC networks, including secure facsimile, or on a public network when protected minimally with GC Public Key Infrastructure (PKI) encryption;

• PROTECTED A – disseminated electronically on GC networks or on a public network when protected minimally with GC PKI encryption, or a HyperText Transfer Protocol Secure (HTTPS) encrypted connection, or unclassified point-to-point facsimile that originates and terminates in an Operations Zone.

1.9.2 Physical Distribution Physical (mail or courier) distribution of protected and classified information and data about CSE-approved COMSEC systems and services must be in accordance with the direction in ITSD-03A and ITSD-06A.

2 Roles and Responsibilities

2.1 Communications Security Establishment As the national COMSEC authority, CSE has the mandate to approve the certification, acquisition and use of cryptographic equipment and key used to protect GC classified and PROTECTED C information and data. CSE is also responsible for developing the related COMSEC policy instruments for the management and control of cryptographic equipment as well as developing related service management procedures for the ordering, safeguarding and delivery of key in support of CSE-approved cryptographic solutions.

In addition to serving as ConAuth/CmdAuth for specified key on national and international cryptonets, CSE also performs the following cryptonet oversight functions:

• taking or recommending appropriate actions when Accountable COMSEC Material (ACM) has been subjected to compromise and informing the appropriate authorities of those actions (refer to Article 8);

• assisting ConAuths/CmdAuths in the development of cryptonet Key Material Support Plans (KMSPs), including annual KMSP reviews, when requested;

• advising ConAuths/CmdAuths of the logistic impact of compromise, key supersession and changeover, or decisions by ConAuths/CmdAuths of other cryptonets;

• providing ConAuth, CmdAuth, and Product Requester (PR), key ordering training (refer to Article 7);

• verifying CSE’s ability to support the KMSPs, where required (refer to Article 4.2.2); and

• authorizing cryptoperiod extensions of more than seven days.

UNCLASSIFIED


January 2017 4

2.2 Departmental COMSEC Authority/Enterprise COMSEC Authority A DCA/ECA may be appointed (COMSEC Staff Appointment or Termination of Appointment Certificate [CSE/CST ITS-012]) by the Departmental Security Officer (DSO) or Enterprise Security Officer (ESO) to act in his or her stead to manage the departmental or enterprise COMSEC program.

The DCA/ECA is responsible for developing, implementing, maintaining, coordinating and monitoring a departmental COMSEC program consistent with the PGS and its operational standards. The DCA/ECA’s cryptonet responsibilities include:

• appointing a departmental or enterprise ConAuth/CmdAuth (Cryptonet Staff Appointment or Termination of Appointment Certificate [CSE/CST ITS-032]) for each cryptonet managed by the department or enterprise services organization;

NOTE: While the DCA/ECA must appoint the ConAuth/CmdAuth, the CSE/CST ITS-032 form must only be submitted to CMAC after the KMSP has been completed and validated.

• approving the departmental or enterprise cryptonet KMSP;

• ensuring adherence to the measures put into place by the ConAuth/CmdAuth where the department or enterprise services organization is an outstation on the network and not the managing authority;

• appointing PRs (Cryptonet Staff Appointment or Termination of Appointment Certificate [CSE/CST ITS-032]), in consultation with the responsible ConAuth/CmdAuth, which are then submitted to CMAC to order key for cryptonets;

• appointing PRs (Non-Cryptonet Product Requester Appointment or Termination of Appointment Certificate – CSE/CST ITS-037) which are submitted to CMAC to order key for non-cryptonet requirements as follows:

o for Secure Communications Interoperability Protocol (SCIP) network requirements – the DCA must, in addition to the ITS-037 form, assign the PR key ordering privileges, which are submitted to CMAC as Privilege Establishment Requests (PERs);

NOTE: The SCIP PER is called the SCIP Privilege Establishment/Termination of Privilege Request – Secure Communications Interoperability Protocol (SCIP) Key – CSE/CST ITS-034.

o for In-Line Network Encryptors (INE) test, training, maintenance and laboratory requirements – the DCA must, in addition to the ITS-037 form, assign the PR key ordering privileges, which are submitted to CMAC as PERs;

NOTE: The INE PER is called the INE/LEF Privilege Establishment/Termination of Privilege Request – Secure Data Network System (SDNS) In-Line Network Encryptor and Link Encryption Family (INE/LEF) – CSE/CST ITS-003.

o for symmetric test, training, maintenance and laboratory requirements – the DCA must, in addition to the ITS-037 form, assign the PR key ordering privileges, which are submitted to CMAC as PERs; and

NOTE: The Symmetric PER is called the Symmetric Key Privilege Establishment Request – CSE/CST ITS-014.

o for other non-cryptonet requirements (e.g. Data at Rest [DAR], Message Signature Key [MSK]), PERs are not required in addition to the ITS-037 form.

UNCLASSIFIED


January 2017 5

• ensuring that appointment/termination forms (CSE/CST ITS-032) are completed whenever there is a change in personnel performing the roles of ConAuth or CmdAuth.

For detailed information on the roles and responsibilities of the DCA and ECA, refer to ITSD-03A.

2.3 Cryptographic Network – Controlling Authority/Command Authority The appointed ConAuth/CmdAuth, including their alternates, must have a reporting relationship to the DCA or ECA which permits the individual to exercise proper jurisdiction in fulfilling his or her ConAuth/CmdAuth responsibilities, including:

• identifying the cryptographic equipment and key requirements;

• identifying and requesting partition codes (refer to Article 4.1.1.1);

• each CmdAuth has PR privileges for all cryptonets under his/her control; however, in consultation with the DCA/ECA, he/she can request that additional PRs be appointed by the DCA/ECA;

• each ConAuth has PR privileges for all cryptonets under his/her control; however, in consultation with the DCA/ECA, he/she can request one other PR besides himself/herself be appointed by the DCA/ECA;

NOTE: Symmetric key ordering requires that only one PR can order key for a specific cryptonet; therefore, coordination is essential where a ConAuth and an additional PR has been appointed to the same cryptonet.

• assigning cryptonet key ordering privileges (PERs) to appointed PRs and submitting the PERs to CMAC;

• maintaining registration of ECUs and network architecture information necessary to manage the cryptonet outstations, including:

o the Security Assessment and Authorization (SA&A) letter,

o the Threat and Risk Assessment (TRA), and

o the telecommunications security Concept of Operation (CONOP);

• managing the cryptonet activities as for Article 5 of this publication;

• developing and maintaining the KMSP (Annex A and Appendix A);

• liaising with other departmental technical support offices (e.g. change management, configuration management and information system security management offices);

• consulting with PRs and COMSEC Custodians to ensure key is provided in sufficient quantities to support mission requirements;

• ensuring COMSEC incident reporting procedures are followed, as detailed in ITSD-05;

• assisting the DSO, ESO, DCA, ECA and COMSEC Custodian in evaluating the security impact of a compromise;

• ensuring that the minimum key is provided in high risk operational environments (e.g. a geographical area or specific location in which there is insufficient security to fully ensure the safeguarding of installed cryptosystems); and

• closing the cryptonet to which the ConAuth/CmdAuth has been appointed.

UNCLASSIFIED


January 2017 6

NOTE 1: Throughout this directive, the terms, roles and responsibilities identified for the ConAuth/CmdAuth will include the Alternate (A)/ConAuth and A/CmdAuth when performing any of the identified duties.

NOTE 2: The national DCA at CSE will appoint the CmdAuth for SCIP secure telephony services.

2.4 Product Requester The primary role of the PR is to order key from CMAC in support of a specific cryptonet, as described in the KMSP. Refer to ITSD-09 for further information on key ordering. Refer to Article 7 for required PR training.

A PR may also be appointed by the DCA/ECA to manage key ordering requirements for more than one cryptonet; however, separate appointment certificates and PERs are required for each cryptonet.

2.5 Role Assignment Restrictions To ensure the highest level of command and control separation within the cryptonet, current COMSEC Custodians, Local Element Managers, or their alternates who support a specific cryptonet must not concurrently be appointed the role of ConAuth or CmdAuth.

Private sector companies or Other Levels of Government (OLGs) must not be assigned the role of ConAuth, CmdAuth or PR for any cryptonet.

2.6 Cryptographic Network – Members Cryptonet members must be authorized (within the KMSP) by a ConAuth/CmdAuth to belong to a specific cryptonet. While the cryptonet members must adhere to the minimum security requirements for accessing, handling, safeguarding and using ACM, they must also follow the direction of the ConAuth/CmdAuth and comply with the cryptonet KMSP.

A cryptonet member is an entity (e.g. individual, GC department or enterprise services organization, OLG, private sector company, foreign government department or agency) that meets the access requirements for ACM (refer to ITSD-03A).

3 Cryptographic Networks

3.1 General A GC cryptonet is a telecommunications network for which a department or enterprise services organization has full technical and operational authority and is thereby responsible for the management of the SA&A (refer to Article 1.2). The cryptonet also requires specific appointed personnel (refer to Article 2) and uses CSE-approved cryptographic equipment, which is detailed and managed using a department/enterprise KMSP (refer to Article 5, Annex A and Appendix A).

3.2 COMSEC Service Models The GC operates cryptonets using one of two COMSEC service models: departmental and enterprise. In the departmental model, COMSEC services and cryptographic assets are the responsibility of each of the individual departments. In the enterprise model, COMSEC services and cryptographic assets are the complete responsibility of the enterprise services organization. Refer to ITSD-03A for specific detail for each model.

All cryptonets must be controlled using one of these COMSEC service models.

UNCLASSIFIED


January 2017 7

3.3 Types of Cryptographic Networks There are typically five types of networks:

• national

• interdepartmental

• departmental

• international, and

• Canadian private sector.

3.3.1 National A national cryptonet is established to fulfil secure communications requirements for either of two CSE-controlled communities:

• GC Electronic Key Management System (EKMS); and

• Secure Telephony: SCIP.

The national ConAuth/CmdAuth at CSE is responsible for the development of the KMSP for these national cryptonets.

3.3.2 Interdepartmental An interdepartmental cryptonet is established to fulfil secure communications requirements between two or more independent federal organizations. The department/organization that is the operational authority for the network must also appoint the ConAuth/CmdAuth for the supporting cryptonet.

3.3.3 Departmental A departmental cryptonet is established to fulfil secure communications requirement specific to a single federal organization. A departmental cryptonet may include the sponsorship of links to non-federal or OLG and private sector partners. Specific OLG and private sector partner cryptonet requirements are detailed in ITSD-01A, ITSD-03A and ITSD-06A.

3.3.4 International An international cryptonet is established to fulfil secure communications requirements for a cryptonet between a GC department and an allied nation. The use of any encryption capabilities, domestic or foreign, that carry classified or PROTECTED C traffic must be coordinated with CCS. In the case of international cryptonets, this is especially important since the National Authority must broker the transfer of any equipment or key through the National Distribution Authority (NDA) at CSE (refer to Article 4.2.1.2 for additional information regarding key ordering).

Where an international cryptonet is established by a foreign nation, the foreign national cryptonet authorities will be responsible for coordinating Canadian membership. However, coordination and management of the ACM support for such cryptonets must be done with CCS to ensure delivery of material from the foreign ConAuth/CmdAuth.

UNCLASSIFIED


January 2017 8

3.3.5 Canadian Private Sector Any foreign or domestic private sector company that has a requirement for membership in a GC-controlled cryptonet must have a GC contract in place and have a federal sponsor before CCS will be able to approve the transfer of ACM. Private sector companies must also meet the requirements to hold and manage ACM, as detailed in ITSD-06A. The sponsoring GC department’s DCA or enterprise services organization’s ECA must be the authority that appoints the ConAuth/CmdAuth and the PR; however the private sector company personnel must not be assigned the ConAuth/CmdAuth or PR role (refer to Article 2.5).

4 Establishing and Closing a Cryptographic Network

4.1 Establishing a Cryptographic Network All cryptonets must have a ConAuth/CmdAuth appointed by the DCA or ECA of the department or enterprise services organization managing the network. Cryptonets are based upon common communities of interest (refer to Article 1.4).

4.1.1 Cryptographic Network Planning Considerations The ConAuth/CmdAuth requires accurate information on all aspects of the cryptonet and must have the capability to communicate with all of its members. The ConAuth/CmdAuth must be familiar with all requirements for managing their cryptonet’s cryptographic equipment and key. Before contacting CCS to establish a cryptonet, the specific items to consider include:

• Concept of Operations (CONOP);

• SA&A requirements:

o TRA,

o Statement of Sensitivity – classification of the information to be transmitted over the cryptonet, and

o cryptonet security requirements (e.g. confidentiality, integrity and availability);

• general network characteristics:

o cryptonet size – number of members,

o cryptonet geographical footprint,

o risk environments for the deployment of the COMSEC material (e.g. a geographical area or specific location in which there is insufficient security to ensure the safeguarding of installed cryptosystems),

o expected services required, voice, network, data at rest,

o operating environment – domestic, international, static, mobile, austere, bandwidth demands, etc.,

o cryptographic interoperability requirements with membership – cryptographic equipment mandatory software releases, and

o limitations in physical access that may affect cryptoperiods for rekey, supersessions, and changeovers;

• cryptographic equipment and key distribution logistical issues;

• expeditious means of informing cryptonet members of both administrative requirements and emergency key supersession;

• requirement for contingency key and equipment to deal with operational needs to expand the cryptonet;

UNCLASSIFIED


January 2017 9

• emergency information and execution of compromise and recovery plans; and

• in addition to equipment-specific Canadian Cryptographic Doctrines (CCDs), CSE provides additional assistance in developing secure networks in the following IT Security Guidance publications:

o Emission Security (EMSEC) Guidance (ITSG-11A),

o Government of Canada Facility Evaluation Procedures (ITSG-12),

o IT Security Risk Management: A Lifecycle Approach (ITSG-33), and

o High Assurance Network-Layer Encryption Security Solutions (ITSG-52).

4.1.1.1 Security Segregation Using Cryptonets A cryptonet is a network that allows members to use the same cryptographic key to communicate with each other. Cryptonets can be divided into smaller interoperable communities or sub-communities. The method of segregation is based on the type of key used within the cryptonet.

A cryptonet secured with symmetric key is segregated from other cryptonets by using a specific key short title and edition. Symmetric key may also be used to encrypt non-network key (e.g. Transfer Key Encryption Key [TrKEK]) or to protect DAR (e.g. ECLYPT key).

A cryptonet secured with asymmetric key is segregated from other cryptonets by using an open or closed partition code:

• An open partition code allows an authorized PR to order Secure Data Network System (SDNS) key for all users with the same partition code to communicate with each other. Open partition codes are typically used in SCIP and also in Type 0 key distribution for EKMS Key Processors (KPs).

• A closed partition code allows an authorized PR to order SDNS key for a select set of users, as determined by the CmdAuth, to communicate within the network (e.g. used in In-Line Network Encryptor/Link Encryption Family [INE/LEF] networks). A closed partition code can be further segregated with access controls (refer to equipment-specific doctrine for more information).

NOTE: A KMSP is submitted by the CmdAuth to CCS for validation. Once validated, CCS provides the CmdAuth with a new partition code, which must then be included in the KMSP.

4.2 Key Material Support Plan

4.2.1 General A primary responsibility of the ConAuth/CmdAuth is the preparation and maintenance of the KMSP.

A KMSP is developed and maintained in order to provide a high degree of assurance that the ACM used on a cryptonet is properly managed throughout its lifecycle. A KMSP must contain sufficient information to enable cryptonet members to support cryptonet logistics (e.g. equipment ordering, key ordering, requesting partition codes, PR recording, distributing, fault finding, system recovery, storing and accounting). Instructions for the development of a KMSP are provided in Annex A and Appendix A.

4.2.1.1 Cryptographic Networks Requiring Key Material Support Plans Except for the direction in Article 4.2.1.2, a KMSP must be developed for all cryptonets that use classified key to secure a telecommunications network (operations, training or functional testing).

UNCLASSIFIED


January 2017 10

4.2.1.2 Cryptographic Networks Not Requiring Key Material Support Plans A KMSP is not required for:

• non-operational cryptonets that use UNCLASSIFIED key (i.e. lab environments);

• non-persistent, short term requirements of less than 90 days using a locally generated key, unless specifically directed by the DCA or ECA; or

• Canadian outstations on international cryptonets where the ConAuth/CmdAuth is a foreign authority. However, the DCA/ECA of the Canadian outstations must appoint a PR to order the foreign key from CMAC.

4.2.1.3 Legacy Cryptographic Networks Whereas all cryptonets are required to be registered and have a valid KMSP, there are cryptonets that have been established without a KMSP prior to the publication date of this directive. In order to mitigate any inconsistency in sustaining cryptographic key delivery for these cryptonets, CCS will engage those GC departments without KMSPs, on a case-by-case basis, as time permits, to assist in resolving the deficiency.

4.2.2 Development and Validation Regardless of the key origin (sovereign, foreign or local), a KMSP must be developed for the use of classified and PROTECTED C key (refer to Annex A). The KMSP must be submitted to CCS for validation of the key requirement and coordination with the national key management practices before the cryptonet is activated. In cases where the client is a member of a foreign network, the KMSP can be significantly abridged since the member is not the ConAuth/CmdAuth.

4.2.3 Classification The minimum security classification of a KMSP must be CONFIDENTIAL. However, higher security classification and handling restrictions may be required based on the TRA or the KMSP’s content.

4.2.4 Review Requirement CCS, in coordination with the ConAuth/CmdAuth, must review the KMSP annually from the date of registration. The annual review must include items listed in Article 4.1.1, as well as any changes to:

• appointments and privileges and required point of contact information;

• key requirements;

• equipment and software versions; and

• key classification.

UNCLASSIFIED


January 2017 11

4.2.5 KMSP Change Controls The KMSP can be modified inside of its annual review cycle (refer to Article 4.2.4) by submitting the appropriate forms and appending a copy to the main KMSP file. The following forms and policy instruments must be used by the ConAuths/CmdAuths to modify the KMSP inside the review cycle:

• for changes of ConAuth/CmdAuth, PR

o INE/LEF Privilege Establishment or Termination of Privilege (PER) Request – Secure Data Network System (SDNS) for In-Line Network Encryptor (INE) and Link Encryption Family (LEF) of Cryptographic Equipment (CSE/CST ITS-003), and

o Symmetric Key Privilege Establishment or Termination of Privilege Request (PER) (CSE/CST ITS-014);

• an IT Security Approval for Use (ITS AFU) for mandatory cryptographic software or hardware upgrade is required; or

• for changes of security classification of the key or partition code:

o CSE/CST ITS-003,

o INE/LEF Key Order Request – Secure Data Network System (SDNS) for In-Line Network Encryptor (INE) and Link Encryption Family (LEF) of Cryptographic Equipment (CSE/CST ITS-002),

o CSE/CST ITS-014, and

o Symmetric Key Order Request (CSE/CST ITS-009).

The ConAuths/CmdAuths are expected to locally track the following and validate with the KMSP during cyclical review:

• the addition, deletion or change in a cryptonet member status; and

• changes to the type or specifications of cryptographic equipment being used at terminal sites.

All other changes such as adding or removing key types require communication with CCS and a reissue of the KMSP.

4.3 Closing a Cryptographic Network With DCA/ECA authority, the ConAuth/CmdAuth is responsible for closing a cryptonet. The ConAuth/ CmdAuth must provide written notice of the cryptonet closure to all cryptonet members and CCS. The notice must include the:

• effective date of closure;

• date when the cryptonet members must provide confirmation to the ConAuth/CmdAuth that the instructions outlined in the notice have been completed;

• procedures to be followed for cancelling key ordering privileges for key identified in the KMSP;

• COMSEC accounting and destruction procedures for key that must be destroyed, zeroized or deleted; and

• instructions for the disposal or redistribution of cryptographic equipment.

UNCLASSIFIED


January 2017 12

4.4 Creating a Compound Cryptonet A compound cryptonet is a cryptonet (referred to as “main” in Figure 1 – Compound Cryptonet) that has a secure connection to a separate cryptonet segregated by its own key and managed under a separate KMSP. This separately-managed cryptonet is designated in the KMSP as the “associated cryptonet”. The key that is used to connect to the associated cryptonet is referred to as the “Link Key”.

In drafting the KMSP, the ConAuth/CmdAuth is responsible to track these connections by the use of a Cryptonet Link Register, as detailed in Article A.A.4. This provides the clarity necessary to manage and coordinate changes within the compound cryptonet. The Cryptonet Link Register provides COMSEC staff (of the compound cryptonet) the minimum information necessary to conduct coordination between the owner or authority of the Link Key and the ConAuth/CmdAuth of the associated cryptonets.

Where a Link Key forms a separate network connecting multiple secure enclaves or cryptonets, the Link Cryptonet forms its own unique cryptonet and requires its own KMSP (managed by a ConAuth/CmdAuth) that is normally one of the associated enterprise partner organizations. For example, in Figure 1 – Compound Cryptonet, there are five unique cryptonets, requiring five separate KMSPs.

Figure 1 – Compound Cryptonet

5 Cryptographic Network Management

5.1 General Cryptographic equipment and key identified in the KMSP will be managed and distributed as detailed in the KMSP and ITSD-03A. Additionally, key identified in the KMSP must be ordered as directed in ITSD-09.

5.1.1 Documentation Along with the KMSP, the ConAuth/CmdAuth must maintain the following documentation throughout the lifecycle of the cryptonet:

• cryptonet member register – a local management document designed to keep track of the names of each cryptonet member, their locations and how to contact them;

• privilege management register – a local management document designed to keep track of the names of each appointed cryptonet PR, their locations and how to contact them. The register must include the privilege protocols (e.g. key ordering thresholds, partition code restrictions) that each can execute;

UNCLASSIFIED


January 2017 13

• local tracking key management distribution register – a local management document designed to keep track of distribution points (e.g. COMSEC Accounts and Local Elements) and how much key each of the distribution points is entitled to receive, store and distribute; and

• Cryptonet Link Register (if required) – a local management document held by the ConAuth/CmdAuth who has been appointed to the link cryptonet (i.e. compound cryptonet) by the department or enterprise services organization assigned as lead agency of the linked cryptonet. This document provides the link cryptonet ConAuth/CmdAuth with the contact information of individual closed cryptonets within the linked network community (refer also to Article 1.4).

NOTE: The linked cryptonet requires close collaboration between the individual cryptonet ConAuths/CmdAuths and the ConAuth/CmdAuth responsible for the linked cryptonet.

5.2 Cryptoperiod Extension A cryptoperiod is the time span during which each key setting remains in effect. Cryptoperiod extensions are restricted to cryptonets using symmetric key.

Where a cryptoperiod extension is operationally required, the following factors need to be considered in determining the length of the extension:

• cryptonet size – A key used on a large cryptonet is usually more vulnerable to compromise than key used on a small cryptonet because it is available at more locations and to more people. Also, large cryptonets generally carry higher volumes of traffic than small cryptonets. The compromise of a key used to secure a large cryptonet could make more intelligence available to an adversary. For this reason, ConAuths and CmdAuths must keep their cryptonets as small as operationally feasible.

• cryptonet member location and operating environment – Cryptonet members located in Canada are normally exposed to less risk than those in other locations. Cryptonet members located in high risk environments (e.g. geographical areas or specific locations in which there is insufficient security to ensure the safeguarding of installed cryptosystems) have an increased risk of physical compromise. Mobile cryptonet members and cryptonet members in hostile environments (sometimes referred to as “tactical environments”) have a greater opportunity for loss (particularly undetected loss) than do fixed plant cryptonet members. In such cases, segregation of higher risk environments must be considered.

• traffic sensitivity and perishability – The ConAuth should consider the classification of the protected information, and whether the information is of long or short term intelligence value. Compromise of key used to secure upper level strategic communications would have a more devastating effect on national security than would the compromise of a key used to secure highly perishable or lower level tactical (hostile environment) communications.

• emergency supersession plan – ConAuths must have a plan for replacing compromised key (refer to Article 5.3.2).

5.2.1 Hostile Environment Situations When cryptoperiod extensions are necessary to maintain critical communications in hostile environment situations, the following guidance should be considered:

• begin all preplanned cryptoperiods with a new key setting; and

• rekey all affected cryptonets as soon as there is a break in activity.

UNCLASSIFIED


January 2017 14

5.2.2 Symmetric Key Subject to equipment-specific doctrine, a symmetric key cryptoperiod may be extended beyond its effective cryptoperiod according to the following authorities:

• cryptonet members – may extend a cryptoperiod by up to two hours without ConAuth authority, but only when necessary to complete a transmission or conversation in process at key change over time.

• ConAuth – may extend cryptoperiods up to seven days unless prohibited by negotiated CONOPs. The ConAuth must inform CCS when a cryptoperiod is extended by more than 24 hours; and

• CCS – on a case-by-case basis, may extend cryptoperiods more than seven days.

5.2.3 Asymmetric Key Asymmetric key may not be extended beyond its yearly cryptoperiod.

NOTE: For unforeseen circumstances, the CmdAuth must contact CCS.

5.3 Supersession Rate

5.3.1 General The supersession rate is the length of time during which an edition of a key is effective. Supersession rates are established by CSE based on the cryptographic equipment type, cryptographic security considerations, operational need and key generation or re-supply constraints. The actual supersession rate for cryptographic key is classified, at a minimum, CONFIDENTIAL unless specified higher by the ConAuth or CmdAuth.

5.3.2 Emergency Supersession Planning ConAuths/CmdAuths will ensure the continuation of the cryptonet by planning for key supersession in advance of key compromise situations. The Emergency Supersession Plan (ESP) must include the following:

• supersession authority – identifies the communication source that the ConAuth/CmdAuth will use to disseminate the supersession instructions to all cryptonet members;

• Hazardous Condition (HAZCON) message – is used to warn cryptonet members that the link is possibly compromised and that exposure of sensitive traffic is at risk. The HAZCON message should precede a supersession when there is a delay in executing the supersession activity;

• contingency key holdings (symmetric key only) – identifies the contingency key holding thresholds and where the key is held;

NOTE: CmdAuths of cryptonets using asymmetric key may, depending upon the type of equipment employed by the cryptonet, preplace symmetric contingency key (also known as Pre-Placed Key [PPK]) to deploy as an interim measure until full asymmetric capability can be restored.

• distribution – identifies the procedures for distributing symmetric contingency key or new asymmetric key to cryptonet members;

• storage (symmetric key only) – identifies the procedures for safeguarding and handling stored contingency key;

• disposal of key – identifies the procedures for the disposal (including destruction) of both the superseded key and the contingency key when they are no longer required.

UNCLASSIFIED


January 2017 15

NOTE 1: In order to obtain a new key, CmdAuths must inform CCS immediately that their cryptonet has been compromised.

NOTE 2: CmdAuths can, depending upon the type of cryptographic equipment employed by the cryptonet and if the compromised cryptonet member is known, employ access control procedures (refer to equipment-specific CCDs) to isolate the compromising member and continue interim operations until complete supersession procedures can be implemented throughout the cryptonet.

5.3.3 Supersession Authorization CCS is the approving authority for supersession rate change.

5.4 Compromise Recovery and Risk Management

5.4.1 General The action required to recover from a compromise situation depends on the nature of the compromise. A known compromise or possible compromise of cryptographic equipment or key used in a cryptonet must be reported as a COMSEC incident, as detailed in ITSD-03A.

It is paramount that the ConAuth/CmdAuth provides immediate and continuous communication about compromise recovery actions to the cryptonet members. It is equally important that cryptonet members immediately inform their ConAuth/CmdAuth when a compromise situation occurs. In all cases, compromise and the subsequent recovery actions must be reported to CCS.

5.4.2 Key Compromise Recovery Options Where evidence exists that key has been compromised, the responsible ConAuth/CmdAuth must take immediate compromise recovery action, as detailed in the KMSP and ITSD-03A. The ConAuth/CmdAuth must not wait for incident reporting and evaluations before taking action. Immediate compromise recovery action must be taken as soon as enough information has been gathered to make an informed decision. Ideally, a ConAuth/CmdAuth will announce a precautionary supersession and disseminate a HAZCON message to all cryptonet members.

When precautionary key edition supersession is not feasible, several options are available. The ConAuth/ CmdAuth, in consultation with the DCA or ECA, the telecommunications network authority and CCS will consider the following options:

• if technically possible, extend the cryptoperiod of uncompromised key currently in use;

• re-establish cryptonet operations excluding those members who do not hold or cannot be supplied with replacement key;

• suspend cryptonet operations until key can be re-supplied; or

• continue using the compromised key under HAZCON provisions. This last resort action is used when:

o normal supersession of the compromised key will take place before emergency supersession can be accomplished,

o where cryptoperiod key changes have a more serious detrimental effect on immediate operations versus compromised communications, or

o where no replacement key is available.

UNCLASSIFIED


January 2017 16

The ConAuth/CmdAuth must alert all cryptonet members (by other means, if possible) that a compromise has taken place and direct that members minimize transmissions using the compromised key.

5.5 COMSEC Emergency Plan The DCA/ECA, in coordination with the COMSEC Custodian, is responsible for the preparation, implementation and annual re-evaluation of departmental or enterprise COMSEC Emergency Plans, as detailed in ITSD-03A. A ConAuth/CmdAuth must ensure the responsible COMSEC Custodian is made aware of any unique circumstances that may affect the COMSEC Emergency Plan. The ConAuth/CmdAuth must also ensure cryptonet members are fully aware of their responsibilities in the event of a COMSEC emergency.

6 Audit Requirements As part of a COMSEC audit, National COMSEC Audit Team (NCAT) will request confirmation that an up-to-date KMSP is on file for each cryptonet that has been endorsed by CCS and that is in use by the department or enterprise services organization. Additionally, NCAT will ensure that the appropriate documentation referred to in Articles 2.3 and 5.1.1 is maintained as well as confirming that the appointment/termination certification and key ordering privileges for appointed personnel are up to date.

7 Cryptographic Network Support Training

7.1 General IT security training must be an integral component of an IT security program. The Information Technology Security Learning Centre (ITSLC) at CSE is responsible for coordinating the development and provision of training and awareness related to IT security and COMSEC.

ConAuths, CmdAuths and PRs must receive CSE training prior to being appointed to the ConAuth/CmdAuth or PR role. If, due to departmental operational requirements, training cannot be provided prior to appointment, contact CCS for guidance.

Contact the ITSLC at [email protected] for current training opportunities.

8 COMSEC Incident Reporting A COMSEC incident occurs whenever there is a situation or activity that jeopardizes or potentially jeopardizes the confidentiality, integrity or availability of COMSEC information, material or services. While custodial staff provide immediate reporting up the COMSEC channels, it is the responsibility of the ConAuth/CmdAuth to report a COMSEC incident to the cryptonet members to ensure Operations Security (OPSEC) action can be initiated within member organizations.

Prompt and accurate reporting of COMSEC incidents minimizes the potential for loss or compromise of COMSEC material.

All COMSEC incidents must be reported as detailed in ITSD-05.


UNCLASSIFIED


January 2017 17

9 References

9.1 Abbreviations, Acronyms and Initialisms

A Alternate ACM Accountable COMSEC Material

CCD Canadian Cryptographic Doctrine CCF Canadian Central Facility CCI Controlled Cryptographic Item CCS COMSEC Client Services CEO Canadian Eyes Only CFD Common Fill Device CMAC Crypto Material Assistance Centre CmdAuth Command Authority COMSEC Communications Security ConAuth Controlling Authority CONOP Concept of Operations COR Central Office of Record Cryptonet Cryptographic Network CSE Communications Security Establishment CUP COMSEC User Portal

DAR Data at Rest DCA Departmental COMSEC Authority DDSM Directive on Departmental Security Management DSO Departmental Security Officer

ECA Enterprise COMSEC Authority ECU End Cryptographic Unit EMSEC Emission Security ESO Enterprise Security Officer ESP Emergency Supersession Plan

FSU Field Software Upgrade

GC Government of Canada GC EKMS Government of Canada Electronic Key Management System GC KMI Government of Canada Key Management Infrastructure

HAZCON Hazardous Condition HTTPS HyperText Transfer Protocol Secure

IP Internet Protocol INE In-Line Network Encryptor IT Information Technology ITAR International Traffic in Arms Regulations ITS Information Technology Security ITS AFU Information Technology Security Approval for Use ITSB Information Technology Security Bulletin ITSC Information Technology Security Coordinator

UNCLASSIFIED


January 2017 18

ITSD Information Technology Security Directive ITSG Information Technology Security Guidance ITSLC Information Technology Security Learning Centre

KMSP Key Material Support Plan KP Key Processor

LEF Link Encryption Family

MSK Message Signature Key

NCAT National COMSEC Audit Team NCIO National COMSEC Incidents Office NCOR National Central Office of Record NDA National Distribution Authority

OLG Other Levels of Government OPSEC Operations Security

PER Privilege Establishment Request PGS Policy on Government Security PKI Public Key Infrastructure PPK Pre-Placed Key PR Product Requester

SA&A Security Assessment and Authorization SCIP Secure Communication Interoperability Protocol SDNS Secure Data Network System

TBS Treasury Board of Canada Secretariat TRA Threat and Risk Assessment TrKEK Transfer Key Encryption Key T3MD Tier 3 Management Device

9.2 Glossary The following glossary contains terms and definitions specific to the COMSEC material identified within this ITSD. For additional definitions, refer to the Glossary of COMSEC-Related Terms Used in CSE’s IT Security Directives (which can be found on the CSE website and on the CSE COMSEC User Portal [CUP]).

UNCLASSIFIED Asymmetric Key Two related cryptographic keys, a public key and a private key that are

used to perform complementary cryptographic operations, such as encryption and decryption or signature generation and verification.

Cryptographic Network (Cryptonet) change over

The time that an operational key is changed on a cryptographic network.

Command Authority (CmdAuth)

The individual appointed by the departmental COMSEC authority or enterprise COMSEC authority to manage the operational use and control of asymmetric encryption keys between members of a specific operational environment.

UNCLASSIFIED


January 2017 19

UNCLASSIFIED Communications Security (COMSEC)

The application of cryptographic security, transmission and emission security, physical security measures, operational practices and controls to deny unauthorized access to information derived from telecommunications and that ensure the authenticity of such telecommunications.

Compound Cryptographic Network (Cryptonet)

A community of unique cryptographic networks securely connected together. The community may be segregated because of risk considerations, network topology constraints or to join two operational environments that wish to share information freely but the associated Controlling Authorities or Command Authority want to maintain technical control.

Compromise The unauthorized access to, disclosure, destruction, removal, modification, interruption or use of COMSEC assets or information.

COMSEC Material Material designed to secure or authenticate telecommunications information. COMSEC material includes, but is not limited to key, equipment, modules, devices, documents, hardware, firmware or software that embodies or describes cryptographic logic and other items that perform COMSEC functions.

Controlling Authority (ConAuth)

The individual appointed by the departmental COMSEC authority or enterprise COMSEC authority to manage the operational use and control of symmetric encryption keys between members of a specific operational environment.

Crypto Material Assistance Centre (CMAC)

The entity within CSE responsible for all aspects of key ordering including privilege management, the management of the National Central Office of Record and the administration of the Assistance Centre.

Cryptographic Pertaining to or concerned with cryptography (often abbreviated as “crypto” and used as a prefix, e.g. cryptonet).

Cryptographic Community The use of one or more cryptographic networks in order to provide the secure telecommunications connectivity necessary for a grouping of individuals deemed to be in a specific mission or operational environment.

Cryptographic Equipment Equipment and systems that perform encryption, decryption, authentication or key generation functions.

Cryptographic Key A numerical value used to control cryptographic operations, such as decryption, encryption, signature generation, or signature validation.

Cryptographic Network (cryptonet)

A telecommunications network in which information is protected by the use of compatible cryptographic equipment using a common cryptographic key.

Cryptographic Network (cryptonet) Member

One of two or more stations on a specific cryptographic network.

UNCLASSIFIED


January 2017 20

UNCLASSIFIED Cryptoperiod A specific period of time during which a cryptographic key setting is in

effect.

High Risk Environment A geographical area or specific location in which there is insufficient security to ensure the safeguarding of installed machine cryptographic systems.

Key See Cryptographic Key.

Key Material Support Plan (KMSP)

The tool used by the Controlling Authority/Command Authority to provide technical direction to the cryptonet membership (outstations) and to the Communications Security Establishment Canadian Central Facility about the secure communications connection practices and to describe any external linkages to other cryptographic networks.

Key Ordering Authority A generic term referring to any of the roles authorized to order cryptographic key (i.e. controlling authority, command authority and product requester).

Network A communication medium and all components attached to that medium, which are responsible for the transfer of information. Such components may include automatic data processing systems, packet switches, telecommunications controllers, key distribution centres and technical control devices.

Product Requester (PR) An individual, appointed by a Departmental COMSEC Authority (DCA), Enterprise COMSEC Authority (ECA), who is assigned key ordering privileges by a DCA/ECA or /Controlling Authority/Command Authority.

Security Assessment (replaces the term Certification)

The process of verifying that the security requirements established for a particular information system are met and that the controls are implemented correctly, work as intended and produce the desired outcome.

Security Authorization (replaces the term Accreditation)

The senior management decision to accept the residual risk of operating an information system, based on the Security Authorization Package.

Supersession Scheduled or unscheduled replacement of a key or COMSEC publication with a different edition.

Symmetric Key A cryptographic key that is used to perform both the cryptographic operation and its inverse, for example to encrypt and decrypt, or create a message authentication code and to verify the code.

Telecommunications The transmission of information over a distance to communicate.

NOTE: Telecommunications includes the use of electrical devices such as telegraphs, telephones and teleprinters, the use of radio and microwave communications, as well as fibre optics and their associated electronics, plus the use of satellites and the Internet.

UNCLASSIFIED


January 2017 21

UNCLASSIFIED Telecommunications Network A collection of information technologies consisting of terminals, links

and nodes which connect together to enable telecommunications between users.

Threat and Risk Assessment (TRA)

A process in which the objective is to identify system assets, to identify how these assets can be compromised by threat agents, to assess the level of risk that the threat agents pose to the assets and recommend the necessary safeguards in order to mitigate effects of the threat agents.

9.3 COMSEC User Portal Authorized users may access the CSE CUP at https://comsecportal.cse-cst.gc.ca. The CSE CUP provides COMSEC-related UNCLASSIFIED and PROTECTED A information, as well as Field Software Upgrades (FSUs) associated with CSE-approved high assurance products, systems and services. For information on becoming an authorized user of the CSE CUP, contact CMAC.

9.4 Communications Security Establishment Web Site COMSEC directives and information (UNCLASSIFIED only) associated with CSE-approved high assurance products, systems and services are available at https://www.cse-cst.gc.ca/en/group-groupe/high-assurance-technologies.

Appointment/Termination certificates, Privilege Establishment Requests (PER), key ordering forms and instructions for their completion are located at https://www.cse-cst.gc.ca/en/page/cryptomaterial-management-and-assistance-centre-cmac.

https://www.cse-cst.gc.ca/en/group-groupe/high-assurance-technologies

https://www.cse-cst.gc.ca/en/page/cryptomaterial-management-and-assistance-centre-cmac

UNCLASSIFIED


January 2017 22

9.5 Bibliography The following source documents were used in the development of this CCD:

• Communications Security Establishment:

o Directive for the Control of COMSEC Material in the Canadian Private Sector Companies (ITSD-06A), June 2016.

o Directive for the Use of CSEC-Approved COMSEC Equipment and Key on a Telecommunications Network (ITSD-04), November 2011.

o Directive for Reporting and Evaluating COMSEC Incidents Involving Accountable COMSEC Material (ITSD-05), April 2012.

o Government of Canada Facility Evaluation Procedures (ITSG-12), June 2005.

o Harmonized Threat and Risk Assessment (TRA) Methodology (TRA-1), October 2007.

o IT Security Directive for Cryptographic Key Ordering (ITSD-09), December 2016.

o IT Security Directive for the Application of Communications Security Using CSE-Approved Solutions (ITSD-01A), January 2014.

o IT Security Directive for the Control of COMSEC Material in the Government of Canada (ITSD-03A), March 2014.

• Department of Justice:

o Financial Administration Act (R.S.C., 1985, c.F-11), 1985.

• Treasury Board of Canada Secretariat:

o Directive on Departmental Security Management (DDSM), July 2009.

o Operational Security Standard on Physical Security, February 2013.

o Policy on Government Security (PGS), July 2009.

• U.S. Department of State:

o International Traffic in Arms Regulations (ITAR), April 2013.

UNCLASSIFIED


January 2017

Annex A Developing and Updating the Key Material Support Plan

A.1 General This annex, along with the Key Material Support Plan (KMSP) template, provides direction for developing and updating a KMSP. Minimum KMSP requirements are identified in Appendix A.

Key for a new cryptographic network (cryptonet) must not be produced until:

1. a Controlling Authority (ConAuth) or Command Authority (CmdAuth), as appropriate, has been appointed (COMSEC Staff Appointment or Termination of Appointment Certificate [CSE/CST ITS-012]) by the Departmental COMSEC Authority (DCA) or Enterprise COMSEC Authority (ECA);

2. a KMSP has been developed by the ConAuth or CmdAuth;

3. the KMSP has been approved for implementation by the DCA or ECA; and

4. the KMSP has been validated and registered by COMSEC Client Services (CCS).

A.2 Prerequisites The following prerequisite must be satisfied prior to the development of a KMSP:

• confirmation of a requirement to establish a cryptonet to protect classified or PROTECTED C information and data by the DCA or ECA who is the operational authority for the cryptonet;

• confirmation that all cryptographic equipment and key used by the cryptonet has been approved for use or has an Authorization to Use if it is a non-standard COMSEC configuration (refer to ITSD-03A); and

• CCS has authorized the purchase (refer to ITSD-01A), if required, of the cryptographic equipment to support the cryptonet.

NOTE: Cryptographic equipment that is already held in a department’s or enterprise services organization’s inventory may be used to secure new cryptonets.

UNCLASSIFIED


January 2017 A-2

A.3 Roles and Responsibilities The following table provides the roles and responsibilities for developing and updating a KMSP.

Table 2 – KMSP Roles and Responsibilities

Role Responsibilities

DCA or ECA

• directing the ConAuth/CmdAuth to develop a KMSP to support a new cryptonet;

• providing KMSP development guidance to ConAuths/CmdAuths;

• reviewing and approving (signing) new KMSPs; which indicates that the appropriate documentation (Concept of Operations [CONOP], Threat and Risk Assessment [TRA], Security Assessment and Authorization [SA&A], Compromise Recovery Plan) have been completed or are in the process of being completed. This is the department’s or enterprise services organization’s confirmation to CSE that all necessary mitigations are in place and that they accept any residual risk. This provides CSE with its authorization to release key in support of the cryptonet’s operations;

• reviewing and approving updates (changes) to existing KMSPs;

• seeking concurrence from the Departmental Security Officer (DSO) or Enterprise Security Officer (ESO) to implement new KMSPs.

ConAuth or CmdAuth

• submitting KMSPs to the DCA for approval;

• consulting with CCS, responsible DCAs, ECAs and COMSEC Custodian(s) in the development of a KMSP;

• when required, submitting KMSPs to CCS for validation of key requirements (refer to Article 4.2.2);

• ensuring each member of the cryptonet is in receipt of a current KMSP;

• ensuring that the KMSP is implemented by the cryptonet members.

CCS

• providing COMSEC guidance, as well as KMSP development guidance;

• validating KMSP key requirements (refer to Article 4.2.2);

• authorizing the initial release of key to support the cryptonet once in receipt of the DCA/ECA-approved (signed) KMSP.

PR • responding to ConAuth/CmdAuth direction;

• tracking custodial staff assigned to the cryptonet.

UNCLASSIFIED


January 2017 A-3

Role Responsibilities

Custodial Staff

• liaising with the Product Requester (PR) or ConAuth/CmdAuth for cryptonet member assigned for Accountable COMSEC Material (ACM) logistics;

• tracking and communicating with cryptonet members assigned.

Cryptonet Members (outstations)

• implementing ConAuth/CmdAuth instructions;

• informing custodial staff about all COMSEC incidents;

• responding to home organization for Operations Security (OPSEC).

Enter Security Classification (when completed)

January 2017

Appendix A – to Annex A Key Material Support Plan Template

Key Material Support Plan (KMSP)

for Cryptographic Network (cryptonet)

<enter cryptonet name and ID number>


Key Material Support Plan

January 2017 1

Authorization to Operate This KMSP denotes that appropriate documentation (CONOP, TRA, SA&A, Compromise Recovery Plan) has been completed or is in process of being completed such that the <Enter the Department or Enterprise Services Organization> has mitigated or accepts any residual risk and provides CSE with its authorization to release key in support of the cryptonet’s operations.

Communications Security Establishment Government of Canada

___________________________________

Print Name of COMSEC Client Services Representative

_________________________________

Signature of COMSEC Client Services Representative

__________________________________________

Print Name of Government of Canada (GC) Department or

Enterprise Services Organization

_________________________________________

Print Name of the Departmental or Enterprise Cryptonet Controlling Authority

(ConAuth) or Command Authority (CmdAuth)

_________________________________________

Print Name of the Departmental COMSEC Authority (DCA) or Enterprise COMSEC

Authority (ECA)

_________________________________________

Signature of the DCA or ECA

__________________

Date of Signature

________________

Date of Signature



January 2017 2

Record of Amendment/Update

Amendment

Number Amendment Description Date Authority



January 2017 3

Abbreviations, Acronyms and Initialisms ACM Accountable COMSEC Material ALC Accounting Legend Code

BET Bulk Encrypted Transaction

CCD Canadian Cryptographic Doctrine CCS COMSEC Client Services CEO Canadian Eyes Only CIK Crypto-Ignition Key CmdAuth Command Authority COMSEC Communications Security ConAuth Controlling Authority CONOP Concept of Operation Cryptonet Cryptographic Network CSE Communications Security Establishment

DCA Departmental COMSEC Authority DSO Departmental Security Officer

ECA Enterprise COMSEC Authority ECU End Cryptographic Unit EKMS Electronic Key Management System ESO Enterprise Security Officer

GC Government of Canada

ID Identification ITSD Information Technology Security Directive

KMSP Key Material Support Plan

LCMS Local COMSEC Management Software

NCIO National COMSEC Incident Office

OLG Other Levels of Government OPSEC Operational Security

PER Privilege Establishment Request POC Point of Contact PR Product Requester

SA&A Security Assessment and Authorization SCI Sensitive Compartmented Information SCIP Secure Communications Interoperability Protocol SDNS Secure Data Network System

T3MD Tier 3 Management Device TRA Threat and Risk Assessment TrKEK Transfer Key Encryption Key



January 2017 4

A.A.1 PART 1 – Cryptographic Network Registration The following table describes the minimum information required to identify registration and management attributes for a cryptonet.

Table A.A.1 – Cryptonet Registration Process

1 Cryptonet Identification and Registration

<enter the departmental or enterprise cryptonet name and ID registration number>

• the ID number is provided by COMSEC Client Services when the KMSP is first sent for validation and registration

2 Security Classification <enter the classification level of security that the cryptonet is authorized to handle>

3 Cryptonet Configuration Type

<enter one of these options: national, interdepartmental, departmental, international, or Canadian private sector>

Links to other

cryptonets

<enter a list of linkages to other cryptonet and key management authorities>

OR

<provide a locally tracked Link Register including the cryptonet Link ConAuth/CmdAuth>

In either case <enter the following minimum information to be captured>:

• Cryptonet ID of Associate Network(s)

• Cryptonet ID of link to Associated Networks

• Short Title of the Link cryptonet

• ConAuth/CmdAuth of the Link cryptonet

4 Cryptonet

Management Roles

DCA or ECA

<enter the name and Point of Contact (POC) of the DCA or the ECA>

ConAuth

or CmdAuth

<enter the name and POC of the ConAuth or CmdAuth>



January 2017 5

PRs

<enter the name(s) and POCs of the Product Requester(s) appointed to order key for this cryptonet>

PR: Contact Information Quantity of key that the PR can order.

Cryptonet Connectivity Specifications

5 Cryptographic Equipment

<enter the type (short title, long title and security classification) of cryptographic equipment being used to secure the cryptonet>

<when applicable, enter the version of the firmware being used in the cryptographic equipment>

<enter the version of the software being used in the cryptographic equipment>

<enter the quantity of end cryptographic units (ECUs) that will be used by the cryptonet>

6 Cryptographic Equipment Software Upgrades

<enter how and by whom all software upgrades will be identified and implemented>

Exceptions/Waivers

7 Waivers <enter a list of all waivers authorized by CSE to execute this operating model of the cryptonet (include ID number and expiry dates)>

8 Exceptions/CONOPs <enter a list of all exceptions authorized by CSE to execute this operating model of the cryptonet (include ID number)>

9 Cryptonet Membership

Reference Local Tracking ID for Cryptonet Membership Local Tracking Register

Identify the member organization, location and contact information necessary to provide direction for circuit engineering. Specify the member type as:

a) Federal Government b) Other Levels of Government (OLG) c) Private Sector d) Foreign



January 2017 6

10 Amendment Register

Reference Local Tracking ID for Cryptonet current modification, including:

a) Membership status changes, b) Cryptonet Management changes, c) Engineering changes.

A.A.2 PART 2 – Key Management The following table describes the management of the key and partition codes used by this cryptonet. A separate table must be completed for each key type (i.e. operational and test) that will be used by the cryptonet.

NOTE: Remove the bullets from within the table once the required information has been entered.

<PART 2 must be provided to all distribution centre COMSEC Accounts and their subordinate COMSEC Sub-Accounts/Local Elements and also to all members of the cryptonet.>

Table A.A.2 – Key Management

1 Short Title or Partition Code

<enter the short title and/or partition code of the key that will be used>

• Except for Transfer Key Encryption Key (TrKEK) that will be provided by the COMSEC Account generating them, short titles or partition codes will be provided by the Communication Security Establishment (CSE).

• The CmdAuth must contact CCS to obtain a Partition Code for the cryptonet. NOTE: The short title is dependent upon the delivery method for

the key. If it is via Bulk Encrypted Transaction (BET), the short title would be “CAFAD [partition code] 845550”. If it is delivered via Tier 3 Management Device (T3MD), it would be “CAFAE [partition code] 845550”.

• For symmetric cryptonets, the ConAuth must submit a Symmetric Key Order Request (CSE/CST ITS-009) to obtain an assignment of a short title when used when completing the KMSP.

2 Editions <enter the first edition or edition range that will be ordered>

• Attention: Do not identify the effective dates of the editions in the KMSP.



January 2017 7

3 Classification

<enter the security classification and handling information of the key>

• Handling information includes any caveats (e.g. CRYPTO, Sensitive Compartmented Information [SCI], Canadian Eyes Only [CEO]).

4 Accounting Legend Code

<enter the Accounting Legend Code (ALC) of the key>

• The ALC identifies the minimum level of accounting required for the key (refer to ITSD-03A).

5 Cryptoperiod

<enter the cryptoperiod change time>

• The cryptoperiod is the length of time each setting or segment is authorized for use. Sometimes called the “HJ time”, the cryptoperiod change time is the time (typically midnight) that operators change to new setting or segment.

6 Supersession Rate

<enter the supersession rate of the key “edition”>

• The supersession rate is the length of time during which an edition of key is effective.

7 Distribution Management Instructions

<enter Reference the Local Tracking Key Distribution Register>

• Provide any special distribution instructions required by ConAuth/CmdAuth:

o PR requirements for symmetric key distribution,

o Delivery methodology (e.g. electronic only – Electronic Key Management System [EKMS], electronic/manual hybrid – EKMS/T3MD, manual only – T3MD/T3MD).

8 Destruction <enter how and when the key will be destroyed and zeroized from the cryptographic equipment (ECUs and T3MDs) and which COMSEC Account(s) and COMSEC role(s) will be responsible for these activities>



January 2017 8

9 COMSEC Incident

Management

<enter “COMSEC incidents involving key will be promptly reported to the DCA or ECA as directed in ITSD-05. All confirmed COMSEC incidents, violations or potential violations will be reported within twenty-four (24) hours to the CSE National COMSEC Incident Office (NCIO).”>

• Include specific instruction to cryptonet members and/or custodial staff (e.g. reporting path between cryptonet members and the cryptonet DCA/ECA for departmental cryptonets).

• Include specific instruction to cryptonet members and/or custodial staff (e.g. reporting path between cryptonet members and organization DCAs, including ConAuths/CmdAuths, for other than departmental cryptonets).

10 Key Compromise

<enter the process that will be used to determine if a key has been compromised or potentially compromised>

<enter the COMSEC roles that will be involved in the process>

• The above descriptions need to be comprehensive and include all immediate actions, e.g. shutting down the cryptonet or a particular link.

11 Compromise Key Recovery

<enter the procedures that will be enforced for restoring secure communications in the event of key compromise>

• CmdAuths must contact COMSEC Client Services for assistance in describing restoration procedures for cryptonets using asymmetric key.

• Identify the COMSEC roles that will be involved in the recovery and their responsibilities.



January 2017 9

A.A.3 PART 3 – Key Distribution The following table, along with the Key Material Support Plan (KMSP), provides direction for developing and updating a Local Tracking Key Distribution Register.

<PART 3 must be provided to all distribution centre COMSEC Accounts and their subordinate COMSEC Sub-Accounts/Local Elements.>

Table A.A.3 – Key Distribution

Serial Product Requester

Distribution Plan* * Modifications require stakeholder advisement before implementation.

1

<enter identity of PR and

contact information>

Distribution Centre(s) Quantity Cryptonet

Members Effective Date

<enter COMSEC Account>

<enter the number of keys

distributed to this Distribution

Centre>

<enter a list of cryptonet members

supported by this Distribution

Centre>

<enter the date that this

information became effective>




Centre>



Centre>



2








Centre>



Centre>






Centre>



Centre>





January 2017 10

3








Centre>



Centre>






Centre>



Centre>



A.A.4 PART 4 – Cryptonet Link Register The following table, along with the Key Material Support Plan (KMSP), provides direction for developing and updating a Cryptonet Link Register with associated cryptonet authority(ies) with <enter your cryptonet/ KMSP ID>.

The Cryptonet Link Register will describe the Link cryptonet and all cryptonets associated with it. At a minimum, the description of the Link cryptonet must identify:

• the partition code or the short title;

• the ConAuth/CmdAuth, his/her organization and contact information;

• the cryptonet/KMSP ID provided by COMSEC Client Services; and

• the PR for the cryptonet’s key.

At a minimum, the description of the associated cryptonets must identify:

• the associated cryptonet/KMSP ID; and

• the organization and contact information of the ConAuth/CmdAuth for the associated cryptonet.

NOTE 1: The ConAuth/CmdAuth should include the Link cryptonet KMSP as an attachment to this KMSP.

NOTE 2: The Link cryptonets require their own KMSP which will identify the staff appointments (i.e. ConAuth/CmdAuth and PR) and attributes associated with the Link cryptonet.

Table A.A.4 – Cryptonet Link Register

Serial Description of the Link Cryptonet(s) Description of all Associated Cryptonets

1 <enter Link cryptonet/KMSP ID>

<enter Link cryptonet short title>

<enter the associated cryptonet/KMSP ID>

<enter the organizational identity and contact



January 2017 11

<enter Link cryptonet partition code if assigned>

<enter the identity and contact information of the ConAuth/CmdAuth of the Link cryptonet>

information of the ConAuth/CmdAuth for the associated cryptonet>

2

<enter Link cryptonet/KMSP ID>

<enter Link cryptonet short title>

<enter Link cryptonet partition code if assigned>

<enter the identity and contact information of the ConAuth/CmdAuth of the Link cryptonet>

<enter the associated cryptonet/KMSP ID>

<enter the organizational identity and contact information of the ConAuth/CmdAuth for the associated cryptonet>

Date post:	26-Mar-2020
Category:	Documents
Upload:	others
View:	29 times
Download:	0 times

IT Security Directive for the Management of CSE …...UNCLASSIFIED IT Security Directive for the...

Documents