ITSP.10.171: Overview

Protecting Specified Information is of paramount importance to Government of Canada (GC) departments and agencies and can directly impact the GC’s ability to successfully conduct its essential missions and functions. This publication provides GC departments and agencies with recommended security requirements for protecting the confidentiality of specified information when it resides in non-GC systems and organizations. These requirements apply to the components of non-GC systems that handle, process, store or transmit specified information, or that provide protection for such components. The security requirements are intended for use by GC departments and agencies in contractual vehicles or other agreements established between those departments and agencies and non-GC organizations.

This publication is a Canadian version of the National Institute of Standards and Technology NIST SP 800-171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. The Cyber Centre will produce a companion publication to use in conjunction with this publication, based on NIST SP 800-171A Assessing Security Requirements for

Controlled Unclassified Information. That publication will provide a comprehensive set of procedures to assess the security requirements. In the interim, NIST SP 800-171A can be used as a reference.

Acknowledgments

The Cyber Centre wishes to acknowledge and thank Dr. Ron Ross and Victoria Pillitteri from the Computer Security Division at NIST for allowing the Cyber Security Guidance (CSG) team to use their guidance and modify it to the Canadian context.

1. Introduction

This publication is a Canadian version of NIST SP 800-171 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. There are no substantial technical changes between this publication and NIST SP 800-171. The primary modifications arise from differences in laws, policies, directives, standards and guidelines. In other words, the changes reflect the distinct Canadian regulatory and compliance landscape; there are no changes to the underlying technical context.

The controls are aligned with Security and privacy controls and assurance activities catalogue (ITSP.10.033), which is a version of NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations adapted to the Canadian context.

Specified information includes any information, other than classified, that a GC authority identifies and qualifies in a contract as requiring safeguarding. Protected information, as well as the safeguarding and dissemination requirements for such information, is defined by the Treasury Board of Canada Secretariat TBS Directive on Security Management, Appendix

J: Standard on Security Categorization and is codified in the TBS Policy on Privacy Protection. We use the term “specified information” in place of “controlled unclassified information” (CUI) which is used in the US document.

GC departments and agencies are required to follow the policies and directives published by TBS when using federal systems to handle, process, store, or transmit information.

The responsibility of GC departments and agencies to protect specified information remains the same when sharing it with non-GC organizations. Therefore, a similar level of protection is needed when non-GC organizations using non-GC systems handle, process, store or transmit specified information. To maintain a consistent level of protection, the security requirements for safeguarding specified information in non-GC systems and organizations must comply with the TBS Policy on Government Security, TBS Policy on Service and Digital, and TBS Policy on Privacy Protection.

The security controls and activities presented in this publication outline requirements for federal contracting.

This publication does not contain the complete set of privacy-related controls and activities described in ITSP.10.033.

Rather, it contains a subset of privacy-related controls that are shared with confidentiality-related controls.

1.1 Purpose

This publication provides GC departments and agencies with recommended security requirements for protecting the confidentiality of specified information when it resides in non-GC systems and organizations and where there are no specific safeguarding requirements prescribed by the authorizing law, regulation, or government-wide policy for the specified information category..

The security requirements in this publication are only applicable to components of non-GC systems that handle, process, store, or transmit specified information or that provide protection for such components. The requirements are intended to be used by GC departments and agencies in contractual vehicles or other agreements established with non-GC organizations.

It is important that non-GC organizations scope requirements appropriately when making protection-related investment decisions and managing security risks. By designating system components for handling, processing, storing or transmitting specified information, non-GC organizations can limit the scope of the security requirements by isolating the system components in a separate security domain. Isolation can be achieved by applying architectural and design concepts (e.g., implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms). Security domains can use physical separation, logical separation, or a combination of both. This approach can provide adequate security for specified information and avoid increasing the non-GC organization’s security posture beyond what it requires for protecting its missions, operations and assets.

1.2 Audience

This publication is intended for various individuals and organizations in the public and private sectors, including:

  •  GC departments and agencies responsible for managing and protecting specified information

  •  non-GC organizations responsible for protecting specified information

  •  individuals with system development lifecycle (SDLC) responsibilities

  •  individuals with acquisition or procurement responsibilities

  •  individuals with system, security, privacy or risk management and oversight responsibilities

  •  individuals with security or privacy assessment and monitoring responsibilities

1.3 Publication organization

The remainder of this publication is organized as follows:

  • Section 2 Fundamentals describes the assumptions and methodology used to develop the security requirements for protecting the confidentiality of specified information, the format of the requirements, and the tailoring criteria applied to the Cyber Centre guidelines to obtain the requirements

  • Section 3 Requirements lists the security requirements for protecting the confidentiality of specified information in non-GC systems and organizations

The following sections provide additional information to support the protection of specified information:

  • Annex A: Tailoring criteria

  • Annex B: Organization-defined parameters

2. Fundamentals

This section describes the assumptions and methodology used to develop the requirements to protect the confidentiality of specified information in non-GC systems and organizations. It also includes the tailoring criteria applied to the controls in ITSP.10.033.

2.1 Security requirements assumptions

The security requirements in this publication are based on the following assumptions:

  • GC information designated as specified information has the same value regardless of whether such information resides in a GC or a non-GC system or organization

  • statutory and regulatory requirements for the protection of specified information are consistent in GC and non-GC systems and organizations

  • safeguards implemented to protect specified information are consistent in GC and non-GC systems and organizations

  • the confidentiality impact value for specified information is no less than low , but will be medium for most large GC datasets

  • non-GC organizations can directly implement a variety of potential security solutions or use external service providers to satisfy security requirements

2.2 Security requirement development methodology

Starting with the ITSP.10.033 controls in the ITSP.10.033-01 Medium impact profile, the controls are tailored to eliminate selected controls or parts of controls that are:

  • primarily the responsibility of the GC

  • not directly related to protecting the confidentiality of specified information

  • adequately addressed by other related controls

  • not applicable

ITSP.10.171 security requirements represent a subset of the controls that are necessary to protect the confidentiality of specified information. The security requirements are organized into 17 families, as illustrated in Table 1. Each family contains the requirements related to its general security topic. Certain families from ITSP.10.033 are not included because they do not directly contribute to confidentiality. For example, the Personal information handling and transparency (PT) family is not included because it is about handling personal information (PI), not about the confidentiality of the PI. The Program management (PM) family is not included because it is not related to confidentiality. Finally, the Contingency planning (CP) family is not included because it addresses availability.

The following are the security requirements families:

  • Access control

  • Awareness and training

  • Audit and accountability

  • Configuration management

  • Identification and authentication

  • Incident response

  • Maintenance

  • Media protection

  • Personnel security

  • Physical protection

  • Risk assessment

  • Security assessment and monitoring

  • System and communications protection

  • System and information integrity

  • Planning

  • System and services acquisition

  • Supply chain risk management

Organization-defined parameters (ODPs) are included in certain security requirements. ODPs provide flexibility through the use of assignment and selection operations to allow GC departments and agencies and non-GC organizations to specify values for the designated parameters in the requirements. Assignment and selection operations allow security requirements to be customized based on specific protection needs. The determination of ODP values can be guided and informed by laws, Orders in Council, directives, regulations, policies, standards, guidance, or mission and business needs. Once specified, ODP values become part of the requirement. When present in a control or activity statement, the square brackets indicate that there is an ODP that needs to be inserted by the reader in order for an organization to tailor the control to their context.

ODPs are an important part of specifying a security requirement. ODPs provide both the flexibility and the specificity needed by organizations to clearly define their CI security requirements according to their particular missions, business functions, operational environments and risk tolerance. In addition, ODPs support consistent security assessments to determine if specified security requirements have been satisfied. If a GC department or agency, or a group of departments or agencies, does not specify a particular value or range of values for an ODP, non-GC organizations must assign the value or values to complete the security requirement.

Each requirement includes a discussion section, derived from the control discussion sections in NIST SP 800-53. These sections provide additional information to facilitate the implementation and assessment of the requirements. They are informative, not normative. The discussion sections are not intended to extend the scope of a requirement or to influence the solutions that organizations may use to satisfy a requirement. Examples provided are notional, not exhaustive, and do not reflect all the potential options available to organizations. The “References” section provides the source controls or assurance activities from ITSP.10.033, and a list of relevant publications with additional information on the topic described in the requirement.

Because this is the first iteration of the Canadian publication, controls that were withdrawn in NIST SP 800-171 Revision 3 have been labelled as “not allocated” to keep the same numbering for interoperability purposes.

The structure and content of a typical security requirement is provided in the example below.

The term “organization” is used in many security requirements, and its meaning depends on context. For example, in a security requirement with an ODP, an organization can refer to either the GC department or agency or to the non-GC organization establishing the parameter values for the requirement.

Annex A describes the security control tailoring criteria used to develop the security requirements and the results of the tailoring process. It provides a list of controls and activities from ITSP.10.033 that support the requirements and the controls and activities that have been eliminated from the Medium impact profile in accordance with the tailoring criteria.

3. Requirements

This section describes 17 families of security requirements for protecting the confidentiality of specified information in nonGC systems and organizations. In this section, the term “system” refers to non-GC systems or system components that handle, process, store or transmit specified information, or that provide protection for such systems or components. Not all

security requirements mention specified information explicitly. Requirements that do not mention specified information explicitly are included because they directly affect the protection of specified information during its processing, storage or transmission.

There may be limitations to how some systems, including specialized systems (e.g., industrial/process control systems, medical devices, or computer numerical control machines) can apply certain security requirements. To accommodate such issues, the system security plan — as reflected in requirement System security plan 03.15.02 — is used to describe any

enduring exceptions to the security requirements. Plans of action and milestones are used to manage individual, isolated or temporary deficiencies, as reflected in requirement Plan of action and milestones 03.12.02.

The security requirements in this section are only applicable to components of non-GC systems that process, store or transmit specified information or that provide protection for such components.