Concepts and structure

On this page

• Requirements, controls, and activities
• Controls and assurance activities, structure, and organization
• Implementation approaches
• Security and privacy controls and assurance activities
• Robustness

This section presents the fundamental concepts associated with security and privacy controls and assurance activities, including the relationship between requirements, controls, and activities, as well as their structure, implementation approaches for systems and organizations, the relationship between security and privacy controls and activities, the importance of the robustness concept and the effects of the controls and activities on achieving a robust and secure solution.

Requirements, controls, and activities

Security and privacy requirements generally arise from obligations imposed on organizations. Indeed, organizations need to comply with applicable laws, regulations, and generally accepted industry standards. Controls are a standardized way of expressing security and privacy requirements for organizations and systems.

The term “requirement” can also be used in a broader sense to refer to an expression of stakeholders’ business needs for security and privacy for a particular system or organization. These business needs for security and privacy and the corresponding security and privacy requirements can be derived from many sources (e.g., laws, Orders in Council, regulations, policies, directives, standards, mission or business needs or risk assessments) and will drive the selection of appropriate controls and activities.

In this document, the term “requirement” includes both legal and policy requirements, as well as an expression of the broader set of stakeholder business needs for security and privacy that may be derived from other sources.

All these requirements, when applied to a system, help determine the necessary characteristics of the system, encompassing cyber security, privacy and assurance.

Controls

Controls are a description of safeguards and protection capabilities appropriate for achieving the particular cyber security and privacy objectives of the organization, as well as for reflecting the business needs for security and privacy of organizational stakeholders. They are selected, allocated, designed and implemented by the organization to satisfy the system requirements. Controls can include administrative, legal, policy, operational, technical and physical aspects.

In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for particular controls within the system development lifecycle.

Assurance activities

Assurance activities are a description of tasks, such as engineering tasks, documentation content requirements, and assessment tasks, to be completed as part of a project that increases the confidence that controls are appropriately implemented. Pre-selected sets of security and privacy assurance requirements are grouped into security assurance levels (SALs), that provide an increasing level of rigour in the creation of assurance evidence. See System lifecycle cyber security and privacy risk management activities (ITSP.10.037) for further discussion on assurance levels.

Controls and assurance activities, structure, and organization

Security and privacy controls and assurance activities described in this publication have a well-defined organization and structure. They are organized into 20 families to make it easier to select and specify security and privacy controls and activities. Each family contains controls and activities that are related to the specific topic of the family. A 2-character identifier uniquely identifies each family (e.g., PS for personnel security). Controls and activities may involve aspects of policy, oversight, supervision, manual processes, and automated mechanisms that are implemented by systems or actions by individuals.

The following lists the security and privacy controls and assurance activities families and their associated identifiers:

• AC: Access control
• AT: Awareness and training
• AU: Audit and accountability
• CA: Assessment, authorization, and monitoring
• CM: Configuration management
• CP: Contingency planning
• IA: Identification and authentication
• IR: Incident response
• MA: Maintenance
• MP: Media protection
• PE: Physical and environmental protection
• PL: Planning
• PM: Program management
• PS: Personnel security
• PT: Personal information handling and transparency
• RA: Risk assessment
• SA: System and services acquisition
• SC: System and communications protection
• SI: System and information integrity
• SR: Supply chain risk management

Families contain base controls or activities and enhancements. Enhancements are directly related to their base controls or activities. Enhancements either add functionality or specificity to a base control or activity or increase the strength of a base control or rigour of the activity. Enhancements are used in systems and operational environments that require greater protection than what is provided by the base control or activity. The selection of enhancements always requires the selection of the base control or activity.

The families are arranged in alphabetical order, while the controls and activities and their enhancements within each family are in numerical order. The order of the families, controls and activities, and enhancements does not imply any logical progression, level of prioritization or importance, or order in which they are to be implemented. Rather, it reflects the order in which they were included in the catalogue. Control and activity designations are not reused when one is withdrawn. Security and privacy controls and activities have the following sections: base control or activity, discussion, GC discussion when applicable, related controls and activities, enhancements and references.

All security and privacy controls, activities or enhancements starting at 400 (e.g., SA-400, IA-04(400)) are Canada-specific controls and activities. Figure 1 illustrates the structure of a typical control or activity.

The control or activity (C/A) section provides a description of the security or privacy control or activity to be implemented, through one or more concise statements of the specific security or privacy capability needed to protect an aspect of the system. They are achieved by the actions, whether automated or non-automated, carried out by information systems and organizations. Each statement in the control or activity section is assigned a separate alphabetic designator ( A., B., etc.) and must be complied with to implement the security or privacy control or activity. All statements starting at AA (e.g., CP-09 AA.) are Canada-specific. Organizations have the flexibility to implement the controls or activities selected in whatever manner satisfies organizational mission or business needs consistent with law, regulation, and policy.

The optional discussion section provides additional information to facilitate the implementation of a security or privacy control or activity, including any other associated controls and activities. The discussion section does not contain any statements that organizations must comply with to implement the control or activity. Organizations can use the information as needed when developing, tailoring, implementing, assessing, or monitoring controls or activities. Additionally, if applicable, the discussion is divided into a general discussion and a GC discussion. GC discussion is specifically directed to a GC audience as it addresses requirements derived from laws, policies, directives, and standards that GC departments and agencies need to comply with.

The related controls and activities section provides a list of controls and activities from the catalogue that impact or support the implementation of a particular control, activity, or enhancement; address a related security or privacy capability; or are referenced in the discussion section. Enhancements are inherently related to their base control or activity. Thus, related controls and activities that are referenced in the base control or activity are not repeated in the enhancements. There may be related controls and activities that are only associated with the specific enhancement and therefore do not appear in the base-related controls and activities.

The optional enhancements section defines, through concise statements, additional security or privacy capabilities used to increase the strength of a control or the rigour of an activity. Each enhancement is assigned a separate numeric designator ((01), (02), etc.). All enhancements starting at 400 (e.g., AC-17(400)) are Canada-specific. The enhancements are numbered sequentially within each control or activity so that they can be easily identified when selected to supplement the base control or activity. Each enhancement has a short subheading to indicate the intended function or capability it provides. In the CP-09 example above, if an enhancement is selected, the control designation becomes CP-09(01). The numerical designation of an enhancement is used solely for identification purposes; it is not indicative of the strength of the enhancement, level of protection, degree of importance, or any hierarchical relationship among the enhancements. Enhancements are not intended to be selected separately; if one is selected, then the corresponding base control or activity is also selected and implemented.

The references section includes a list of applicable laws, policies, directives, standards, guidelines, publications, and other useful references that are relevant to a specific control, activity, or enhancement. The purpose of this section is to provide additional information or context that the reader may find useful in selecting and implementing the control or activity. A reference can be broad or narrow in scope depending on the nature of the control or activity (e.g., GC guidelines on authentication versus a technical security configuration standard).

For some controls and activities, additional flexibility is provided by allowing organizations to define specific values for designated parameters. Flexibility is achieved as part of a tailoring process using assignment and selection operations embedded within the controls and activities and enclosed in brackets. The assignment and selection operations give organizations the capability to customize controls and activities based on organizational security and privacy requirements. In contrast to assignment operations, which allow complete flexibility in the designation of parameter values, selection operations narrow the range of potential values by providing a specific list of items for organizations to choose from.

These parameters may be derived from many sources, including laws, Orders in Council, policies, directives, regulations, jurisprudence, standards, guidance, and mission or business needs. Organizational risk assessments and risk tolerance are also important factors in determining the values for parameters. Once specified by the organization, the values for the assignment and selection operations become a part of the control or activity. Organization-defined parameters (ODPs) used in the base control or activity also apply to the enhancements associated with those. The implementation of the control or activity is assessed for effectiveness against the completed control or activity statement. 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 for an organization to tailor the control to their context.

In addition to assignment and selection operations embedded in a control or activity, additional flexibility can be achieved through iteration and refinement actions. Iteration allows organizations to use a control or activity multiple times with different assignment and selection values, perhaps applying it in different situations or when implementing multiple policies. For example, an organization may have multiple systems implementing a control or activity, but with different parameters established to address different risks for each system and operation environment. Refinement is the process of providing additional implementation detail to a control or activity. Refinement can also be used to narrow the scope of a control or activity in conjunction with iteration to cover all applicable scopes (e.g., applying different authentication mechanisms to different system interfaces). Combining assignment and selection operations with iteration and refinement actions when applied to controls and activities provides the needed flexibility to allow organizations to satisfy a broad base of security and privacy requirements at the organization, mission and business process, and system levels of implementation.

The security and privacy controls in the catalogue are expected to change over time, as they are withdrawn, revised, and added. Controls, activities, and enhancements will not be renumbered each time security and privacy plans are withdrawn; this maintains stability in security and privacy plans and automated tools supporting the implementation. Notations of controls, activities and enhancements that have been withdrawn will be maintained in the catalogue for historical purposes.

Implementation approaches

There are 3 approaches to implementing the controls and activities in Section 3: a common (inheritable) implementation approach, a system-specific implementation approach, and a hybrid implementation approach. The implementation approaches define the scope of applicability for the control or activity, its shared nature or inheritability, and the responsibility for control or activity development, implementation, assessment, and authorization. Each implementation approach has a specific objective and focus that helps organizations select the appropriate controls and activities, implement them in an effective manner, and satisfy security and privacy requirements. A specific implementation approach may achieve cost benefits by leveraging security and privacy capabilities across multiple systems and operational environments.

A common control or activity is deployed as a shared service to the organization. Implementing common controls or activities results in a capability that is inheritable by multiple systems or programs. A control or activity is deemed inheritable when the system or program receives protection from its implementation, but the control or activity is developed, implemented, assessed, authorized, and monitored by an internal or external entity other than the entity responsible for the system or program. The security and privacy capabilities provided by common controls and activities can be inherited from many sources, including mission or business lines, organizations, enclaves, operational environments, sites, or other systems or programs. However, implementing common controls and activities can introduce the risk of a single point of failure.

Many of the controls and activities needed to protect organizational information systems — including many physical and environmental protection controls, personnel security controls, and incident response controls — are inheritable and, therefore, are good candidates for common control status. Common controls and activities can also be technology-based, such as identification and authentication, boundary protection, audit and accountability, and access control. The cost of development, implementation, assessment, authorization, and monitoring can be amortized across multiple systems, organizational elements, and programs using the common control and activity implementation approach.

System-specific controls and activities are the primary responsibility of the system owner and the authorizing official for a given system. Implementing system-specific controls and activities can introduce risk if the implementations are not interoperable with common controls and activities. Organizations can implement a control or activity as a hybrid if one part of the control or activity is common (inheritable) and the other part is system specific. For example, an organization may implement control CP-02 using a predefined template for the contingency plan for all organizational information systems with individual system owners tailoring the plan for system-specific uses, where appropriate.

The division of a hybrid control or activity into its common (inheritable) and system-specific parts may vary by organization, depending on the types of information technologies employed, the approach used by the organization to manage its controls and activities, and the assignment of responsibilities. When a control or activity is implemented as a hybrid, the common control or activity provider is responsible for ensuring the implementation, assessment, and monitoring of the common part of the hybrid control or activity. The system owner is responsible for ensuring the implementation, assessment, and monitoring of the system-specific part of the hybrid control or activity. Implementing controls and activities as hybrid controls can introduce risk if the responsibility for the implementation and ongoing management of the common and system-specific parts of the controls and activities is unclear.

Context is important when determining which implementation approach (i.e., common, hybrid, or system-specific) is most appropriate. The implementation approach cannot be determined to be common, hybrid, or system-specific simply based on the language of the control or activity. Identifying the implementation approach can result in significant savings to organizations in implementation and assessment costs, and a more consistent application of the controls and activities throughout the organization. Typically, identifying the implementation approach is straightforward. However, the implementation itself requires significant planning and coordination.

It is better to plan for the implementation approach of a control or activity (i.e., common, hybrid, or system-specific) early in the system development lifecycle and to coordinate with the entities providing the control. In other words, this is part of doing enterprise security architecture. Similarly, if a control or activity is to be inheritable, coordination with the inheriting entity is required to ensure that the control or activity meets the inheriting entity’s needs. This is especially important given the nature of control or activity parameters.

An inheriting entity cannot assume that controls or activities are the same and mitigate the appropriate risk to the system just because the identifiers (e.g., AC-01) are the same. It is essential to examine the parameters (e.g., assignment or selection operations) when determining if a common control or activity is adequate to mitigate system-specific risks.

Security and privacy controls and assurance activities

The selection and implementation of security and privacy controls and activities reflect the objectives of cyber security and privacy programs and how those programs manage their respective risks. Depending on the circumstances, these objectives and risks can be independent or overlapping.

Due to permutations in the relationship between cyber security and privacy program objectives and risk management, there is a need for close collaboration between programs to select and implement the appropriate controls and activities for information systems that handle personal information. Organizations should consider how to promote and institutionalize collaboration between the 2 programs to ensure that the objectives of both disciplines are met and that risks are appropriately managed.

GC cyber security programs are responsible for protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction (i.e., unauthorized activity or system behaviour) to provide confidentiality, integrity, and availability. Those programs are also responsible for managing security risk and for ensuring compliance with applicable security requirements. GC privacy programs are responsible for managing risks to individuals associated with the creation, collection, correction, modification, use, retention, disclosure, or disposal (collectively referred to as “handling”) of personal information, and for ensuring compliance with applicable privacy requirements. When a system handles personal information, the cyber security program and the privacy program have shared responsibility for managing the security risks for the personal information in the system. Due to this overlap in responsibilities, the controls and activities that organizations select to manage these security risks will generally be the same regardless of their designation (security or privacy) in control and activity baselines or program or system plans.

For further information on the subject, refer to Organizational cyber security and privacy risk management activities (ITSP.10.036).

Robustness

Robustness is a characterization of the security strength and assurance of a security control. The security strength is related to the control’s potential ability to protect the confidentiality, integrity, or availability of systems. The security assurance of a control is related to confidence that the control is designed and implemented correctly and is operating as intended. Together, these 2 aspects define the requirements that must be met in the implementation of a control to satisfy its security objective.

For example, a security control that is conceptually strong (e.g., an encryption algorithm using the Advanced Encryption Standard (AES)) but comes with no assurance (e.g., there is no evidence to show that the algorithm is coded correctly) will have a lower effective robustness than a similar control that has higher assurance (e.g., the software has been validated).

Security controls that protect more sensitive or critical systems or that are exposed to more significant threats will generally require stronger security solutions, and more assurance in their implementation. Therefore, they will also require higher levels of robustness. The robustness model defines a hierarchy of robustness levels that are based on expected injury levels and the capabilities or magnitude of the threats. A thorough discussion on robustness is presented in System lifecycle cyber security and privacy risk management activities (ITSP.10.037).