Government of Canada Security Control Profile for Cloud-based GC Services

Note to Readers

Appendix A provides the list of security controls selected. Due to length, it is not included in this web-document. If you would like to receive the full document, including appendix A, (or if you would like to receive a PDF version of the Government of Canada's Cloud Adoption Strategy or the Government of Canada Right Cloud Selection Guidance), please send your request to Public Enquiries.

This document (version 1.1) has been updated on , based on the feedback received during the IT Strategic Plan and Cloud consultations that took place in the fall 2016.

Foreword

Cloud computing has the potential to deliver agile and flexible IT services. Under the cloud computing paradigm, the Government of Canada (GC) relinquishes direct control over many aspects of security and privacy, and in doing so, confers a level of trust onto the cloud service provider. At the same time, GC departments and agencies using cloud services remain accountable for the confidentiality, integrity, and availability of the GC information systems and related information hosted by the cloud service provider. GC departments and agencies therefore need to understand cloud security and ensure risks are effectively addressed. To enable the adoption of cloud computing, an integrated risk management approach will be leveraged to establish cloud-based GC services.

The risk management framework used by the GC for managing IT security risks of cloud-based GC IT services consist of activities to:

  • Perform security categorization (in terms of confidentiality, integrity, and availability) of each GC service being deployed on a cloud service;
  • Select an appropriate set of security controls based on the GC service’s security category;
  • Select the right cloud deployment model and cloud service model for the GC service;
  • Assess the implementation of the security controls in the supporting cloud service;
  • Implement the required security controls in the GC service;
  • Assess the implementation of the security controls in the GC service;
  • Authorize operations of the resulting cloud-based GC service;
  • Continuously monitor the security of the cloud-based GC service during the operation phase; and
  • Maintain the authorization state of the cloud-based GC service.

To support these activities, the GC maintains cloud security control profiles suitable for GC programs and services of various sensitivities. Because of the shared nature of cloud computing, each party in a cloud-based GC service is responsible for the implementation, operation, and maintenance of a subset of the security controls in a profile. Cloud service providers use the security controls allocated to them for building and operating conformant cloud services. GC departments and agencies use the security controls allocated to them for procuring suitable cloud services and building, operating, and using GC services on top of conformant cloud services.

Executive Summary

The CSE Information Technology Security Guidance (ITSG) 33 Footnote 2 on IT security risk management includes recommended security control profiles for information systems. These profiles have been used to develop the GC cloud profile documented herein.

This GC cloud profile is also heavily influenced by the security control profile for moderate impact information systems developed by NIST under the Federal Risk and Authorization Management (FedRAMP) program.

FedRAMP Footnote 19 is the US Federal Government risk management program that provides a standardized approach for authorizing and monitoring the security of cloud services. By aligning the GC cloud profiles to the FedRAMP profiles, the GC can maximize both the interoperability of cloud services and the reusability of the authorization evidence produced by cloud service providers.

Cloud computing has introduced a fundamental shift in the way IT services are delivered and the Government of Canada (GC) has established a strategy Footnote 1 that will position itself to leverage this new IT service delivery model. Cloud adoption will ensure that the GC can continue to sustain IT service excellence during a period of increased demand by Canadians for online services and timely access to accurate information.

A key element to the GC's successful adoption of cloud computing is to ensure that an essential set of standardized security controls are properly implemented by cloud service providers (CSPs) to protect their cloud services, and by GC departments and agencies to protect the GC services and related information that are hosted on these cloud services. The level of security must be commensurate with the specific security needs of each GC service. By adhering to a standardized set of security controls, the GC, and more specifically departments and agencies, can identify and assess risks and develop strategies to appropriately mitigate them.

This document identifies the baseline security controls that must be implemented by CSPs and GC departments and agencies in order to appropriately protect cloud-based GC services and related information having a security category of Protected B, medium integrity, and medium availability. It also documents the context in which these security controls are expected to be implemented.

This security control profile was developed by GC lead security agencies based on current IT security risk management guidance from the Communications Security Establishment (CSE) Footnote 2 and the US National Institute of Standards and Technology. Footnote 3

Table of Contents

List of Abbreviations and Acronyms

CIO
Chief Information Officer
CSE
Communications Security Establishment
FedRAMP
Federal Risk and Authorization Management Program Footnote 19
IM/IT
Information Management/Information Technology
ITSG
Information Technology Security Guidance
MOU
Memorandum of Understanding
NIST
National Institute of Standards and Technology
PBMM
Protected B, Medium Integrity, Medium Availability
RFP
Request for Proposal
SDLC
System Development Lifecycle
SLA
Service Level Agreement
SSC
Shared Services Canada
TBS
Treasury Board of Canada Secretariat

1. Introduction

1.1 Background

The Government of Canada (GC) develops and maintains security control profiles for the implementation of cloud-based GC services in support of the GC cloud adoption strategy Footnote 1. A cloud-based GC service is a GC information system that is deployed over a cloud service. A security control profile is a set of IT security controls that an organization establishes as minimum mandatory requirements for their information systems.

The GC cloud security control profiles satisfy Treasury Board of Canada Secretariat (TBS) baseline security controls applicable to a generic set of departmental security needs, with due consideration for a GC technical context and threat context.

1.2 Scope and applicability

This document describes the security control profile for cloud-based GC services and related information having a security category of Protected B, medium integrity, and medium availability (PBMM). It specifies the security controls that need to be implemented in these information systems, and summarizes the context for which they apply.

The GC cloud PBMM profile is generally applicable to cloud-based services supporting a variety of non-national interest GC programs and services (e.g. programs or services that support sensitive government operations not including international affairs and defence, or federal-provincial affairs). It should only be reused in a similar context and only after performing an appropriate analysis.

1.3 Purpose

This document is to be used as the primary source of guidance for GC departments and agencies and cloud service providers (CSPs) to deploy, authorize, and operate cloud-based GC services.

1.4 Audience

This document is to be used by:

  • CSPs to build cloud services suitable for use by the GC;
  • GC program and service managers, business owners, IT project managers,and IT and IT security practitioners to procure suitable cloud services and implement GC services over these cloud services; and
  • GC and departmental IT security authorities to assess, authorize, and monitor cloud-based GC services.

2. Context and Assumptions

This section summarizes the business contexts for which cloud security controls were selected and tailored.

Confidentiality:

The state of being disclosed only to authorized principals. [PGS Footnote 21, adapted]

Note: In IT security, confidentiality generally applies to information assets.

Integrity:

The state of being accurate, complete, authentic, and intact. [DDSM Footnote 20]

Note: In IT security, integrity generally applies to information assets. Integrity can also apply to business processes, software application logic, and hardware.

Availability:

The state of being accessible and usable in a timely and reliable manner. [PGS Footnote 21, adapted]

Note: In IT security, availability generally applies to information assets, application software, and hardware infrastructure and its components. Availability can also apply to processes.

2.1 Business Context

The GC cloud PBMM profile is suitable for cloud-based services supporting a wide range of GC business activities of medium sensitivity and criticality involving information to a maximum level of PROTECTED B, which is particularly sensitive information as described in the TBS Standard on Organization and Administration Footnote 4. Examples of such business activities include, but are not limited to, the delivery of social services, taxation, Receiver General functions, departmental finance and administration, human resources, public service pay and benefits, and providing common and shared services to a broad client base.

Departments that are candidates for using the GC cloud PBMM profile will perform business activities with a maximum security category marking of PROTECTED B / Medium Integrity / Medium Availability, as defined in ITSG-33, Annex 1, Section 6 Footnote 2. Business activities with such a marking have the following general characteristics:

Confidentiality

A compromise of the confidentiality of PROTECTED B information is reasonably expected to cause a medium level of injury to non-national interests

Integrity

A compromise of the integrity of supporting IT assets is reasonably expected to cause a medium level of injury to non-national interests

Availability

A compromise of the availability of supporting IT assets is reasonably expected to cause a medium level of injury to non-national interests

Acceptable residual risks

The business activities require the support of an information system operating with the lowest achievable residual risks for the security objectives of confidentiality, integrity and availability in a threat environment as described in Section 2.3 below.

Table 2-1 characterizes in greater detail suitable business contexts using confidentiality, integrity, and availability objectives. It also includes examples of consequences of compromise, business processes, and related information.

Table 2-1 Characterization of Applicable Business Contexts
Characteristics Descriptions and Examples
Confidentiality Objective The business activities involve the processing, transmission, and storage of PROTECTED B information that needs to be adequately protected from unintentional disclosure.
Integrity and Availability Objective The expected injury from compromise of the integrity and availability of IT assets is assessed as medium. IT assets therefore need to be adequately protected from integrity and availability compromise.
Acceptable Residual Risks The business activities require the support of an information system operating with the lowest achievable residual risks for the security objectives of confidentiality, integrity and availability.
Examples of Injuries
  • Serious civil disorder or unrest
  • Physical pain, injury, trauma, hardship, or illness to individuals
  • Psychological distress or trauma to individuals
  • Financial loss to individuals that affects their quality of life
  • Financial loss to Canadian companies that reduces their competitiveness
  • Inability to conduct criminal investigations or other impediments to effective law enforcement
  • Disruption of government business activities that would seriously inconvenience Canadians
Examples of Business Processes
  • Payments of benefits, to Canadians, whose disruption or delay could cause psychological harm to people
  • Police services whose disruption could cause physical harm to people or lead to civil disorder or unrest
  • Financial and reporting processes whose disruption could lead to serious financial losses to people or Canadian companies
  • Processing of large financial transactions and payments
  • Processes involving health care records
Examples of Information Assets
  • Personal medical and financial information
  • Personal income tax information
  • Large financial transactions and payments
  • Information that could be used for criminal purposes (e.g., false identity or impersonation)
  • Information compiled as part of a criminal investigation
  • Information about an individual's eligibility for social benefits

Table ‎2-2 lists the business needs for security that were accounted for in developing the GC cloud PBMM profile. Business needs for security are a fundamental element of the IT security risk management process. Statements of business needs for security are used to influence the selection and tailoring of security controls, and serve to establish assurance that information systems implement these security controls in a way that fully satisfies legislative and regulatory requirements.

Because of its genericity, the GC cloud PBMM profile may be used to support any GC business activity having a security category of PBMM or lower, which could be regulated by any of the thousands of legislative and regulatory requirements currently in effect in the GC. To limit the scope while maintaining the profile’s genericity, the statement of business needs for security is limited to the following instruments:

Table ‎2-2 Statement of Business Needs for Security
ID Ref. Topic Business Need for Security Statement Interpretation in the Context of Cloud-based GC Services Supporting Security Controls
(most significant)
BNS-1 Footnote 5, 6.1.4 Authentication
Integrity
Non-repudiation
Deputy heads must ensure the authenticity of information for as long as it is required to meet operational needs and accountabilities.

Cloud-based GC services must ensure the authenticity and integrity of the information resources that they manage.

Note: Where signed records or documents are stored, “information about the digital signature and its validation should be recorded within the metadata" Footnote 11.

Note: Where signed records or documents are stored, “information about the digital signature and its validation should be recorded within the metadata" [11].

  • AC-3 Access enforcement
  • AC-5 Separation of duties
  • AC-6 Least privilege
  • AU-10 Non-repudiation
  • SC-8 Transmission confidentiality and integrity
  • SC-28 Protection of information at rest
BNS-2 Footnote 6, 6.2.2 Authentication
Integrity
Non-repudiation
Managers must ensure the authenticity and integrity of the information of programs and services for which they are responsible. See under BNS-1. See under BNS-1.
BNS-3 Footnote 7, 5.1.1 Integrity
assurance
The integrity of information resources must be protected. See under BNS-1. See under BNS-1.
BNS-4 Footnote 8, 13(1) Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Subsection 13(1) (Information obtained in confidence) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. Cloud-based GC services must protect the confidentiality of protected information resources that they manage.
  • AC-3 Access enforcement
  • AC-5 Separation of duties
  • AC-6 Least privilege
  • SC-8 Transmission confidentiality and integrity
  • SC-28 Protection of information at rest
BNS-5 Footnote 8, 13(2) Authorization To disclosure non-public information exempted from the general right of access under Subsection 13(1) (Information obtained in confidence) of the Access to Information Act, the head of a government institution must first obtain the authorization from the government, organization, or institution from which the information was obtained. This process could be built into a cloud-based GC service.
  • AC-3 Access enforcement
  • AC-5 Separation of duties
  • AC-6 Least privilege

Note: This process would need to be implemented through an authorization function.

BNS-6 Footnote 8, 16(2) Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Subsection 16(2) (Security) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-7 Footnote 8, 16(3) Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Subsection 16(3) (Policing services for provinces and municipalities) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-8 Footnote 8, 17 Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Section 17 (Safety of individuals) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-9 Footnote 8, 19(1) Privacy (confidentiality of personal information) The head of a government institution must protect the confidentiality of information exempted from the general right of access under Subsection 19(1) (Personal information) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-10 Footnote 8, 19(2) Authorization To disclosure non-public information exempted from the general right of access under Subsection 19(1) of Access to Information Act (Personal information), the head of a government institution must first obtain authorization from the person to whom it relates.  See under BNS-5. See under BNS-5.
BNS-11 Footnote 8, 20(1) Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Subsection 20(1) (Third party information) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-12 Footnote 8, 21(1) Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Subsection 21(1) (Advice, etc.) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-13 Footnote 8, 22 Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Section 22 (Testing procedures, tests, and audits) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-14 Footnote 8, 23 Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Section 23 (Solicitor-client privilege) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-15 Footnote 8, 24(1) Confidentiality The head of a government institution must protect the confidentiality of information exempted from the general right of access under Section 24(1) (Statutory prohibitions against disclosure) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-16 Footnote 8, 68(1) Confidentiality The head of a government institution must protect the confidentiality of information excluded from the general right of access under Subsection 68(1) (Canadian Broadcasting Corporation) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-17 Footnote 8, 68(2) Confidentiality The head of a government institution must protect the confidentiality of information excluded from the general right of access under Subsection 68(2) (Atomic Energy of Canada Limited) of the Access to Information Act at a level commensurate with the expected level of injury from compromise. See under BNS-4. See under BNS-4.
BNS-18 Footnote 9, 5(1) Authorization To collect personal information from any source other than directly from the individual to whom it relates, a government institution must first obtain the authorization from that individual. See under BNS-5. See under BNS-5.
BNS-19 Footnote 9, 6(2) Integrity
assurance
A government institution must establish and maintain the integrity of personal information. See under BNS-1. See under BNS-1.
BNS-20 Footnote 9, 7 Authorization To use personal information for purposes other than those for which it was collected, a government institution must first obtain the authorization from the individual to whom it relates. See under BNS-5. See under BNS-5.
BNS-21 Footnote 9, 8(1) Authorization To disclosure personal information for purposes other than those specified in Section 8, a government institution must first obtain the authorization from the individual to whom the information relates. See under BNS-5. See under BNS-5.
BNS-22 Footnote 9, 14 Timeliness Where access to personal information is requested under Subsection 12(1) of the Privacy Act, the head of the government institution to which the request is made must give the individual who made the request access to the information within 30 days after the request is received. Cloud-based GC services must ensure the availability of information to support this BNS.
  • CP-9 Information system backup
  • CP-10 Information system recovery and reconstitution
BNS-23 Footnote 10, 10(1)(b) Timeliness The publisher of an electronic publication made available in Canada shall provide the contents of that publication to the Librarian and Archivist 7 days after receiving a request from the Librarian and Archivist or as specified in the request. See under BNS-22. See under BNS-22.
BNS-24 Footnote 10, 12(1) Authorization The Librarian and Archivist, or a person duly delegated by the Librarian and Archivist, must authorize the disposal of government and ministerial records. IM solutions must support authorized disposition of information.
  • AC-3 Access enforcement
  • AC-5 Separation of duties
  • AC-6 Least privilege
BNS-25 Footnote 10, 12(3) Authorization The head of a government institution shall authorize access by the Librarian and Archivist to a record under the institution's control to which Subsection 24(1) (Statutory prohibitions against disclosure as set out in Schedule II) of the Access to Information Act applies. See under BNS-5. See under BNS-5.
BNS-26 Footnote 10, 15.1 Timeliness A department shall send to the Librarian and Archivist the written report referred to in Subsection 40(2) of the Financial Administration Act within six months after the completion of any data collection done for the purposes of public opinion research carried out under a contract at the request of the department and for the exclusive use of Her Majesty in right of Canada. See under BNS-22. See under BNS-22.

2.2 Technical Context

The technical context for the GC cloud PBMM profile is defined by the cloud services and the GC services that are operating over these cloud services.

For cloud services, the GC cloud PBMM profile applies to:

  • All existing CSP offerings;
  • All cloud deployment models (public cloud, community cloud, private cloud, hybrid cloud) as defined by NIST Footnote 12; and
  • All cloud service models (infrastructure as a service, platform as a service, software as a service) as defined by NIST Footnote 12.

For GC services, the technical context is dictated largely by the cloud service offerings and there are no limits to what that context may be. The GC cloud PBMM profile neither prescribes nor proscribes any particular technologies and it should generally be suitable for any technical context provided by CSPs in their cloud service offerings.

2.3 Threat Context

The GC cloud PBMM profile has been developed to protect departmental business activities from IT-related threats that are relevant to both the business context and the technical context. In addition to the objective of protecting GC business activities, the profile aims to protect the cloud-based GC services. This approach is necessary as threats may be directed towards IT assets for no other reasons than to compromise technical components and benefit from their resources, irrespective of the type of business activities being supported by these IT assets.

For example, many attackers are not interested in GC information or in disrupting GC business activities; rather, they are interested in compromising cloud and non-cloud information systems in order to perform illegal acts, such as storing illegal data (e.g., images or movies) and covertly sharing that data with other criminals, performing denial of service attacks on commercial websites, extorting money, sending spam, or infecting computer systems with malware.

Threat information has been analyzed from multiple sources, including TBS and departmental threat and incident reports, in addition to analysis performed by CSE. As a result, the GC cloud PBMM profile, when correctly implemented, mitigates to a low residual level the risks from exposure to deliberate threat agents of categories from Td1 to Td4, and accidental threats and natural hazards of categories Ta1 to Ta3, as described in Table 2-2. As threat agent capabilities evolve over time, this profile will be updated to ensure that the selection of security controls is appropriately adjusted to mitigate new capabilities.

While this profile was developed by GC lead security agencies considering generic departmental requirements as a starting point, departments will still be required to ensure that the threat context is applicable to their environment. Where the threat context differs, it is possible that further tailoring will be necessary, or that the department will have to accept higher levels of residual risk. If the differences are significant, a different security control profile may need to be selected, if available. Further guidance can be obtained from departmental IT security authorities if needed.

Table 2-3 Summary of Mandatory Threats to be mitigated (by Threat Category)
Deliberate Threats Accidental Threats
Category Typical Threat Actors Selected Category Typical Threat Events Selected
Td1 Non-malicious adversary Yes Ta1
  • Minor accidental events (e.g., trip over a power cord, enter wrong information)
Yes
Td2 Passive, casual adversary with minimal resources who is willing to take little risk (e.g., listening, script kiddie) Yes Ta2
  • Moderate accidental events (e.g., render server inoperable, database corruption)
  • Minor hardware or software failures (e.g., hard disk failure)
  • Minor natural hazards (e.g., localized flooding, earthquake compromising part of a facility)
Yes
Td3 Adversary with minimal resources who is willing to take significant risk (e.g., unsophisticated hackers) Yes Ta3
  • Serious inadvertent or accidental events (e.g. fire in a facility, large scale database corruption)
  • Moderate mechanical failures (e.g., long term facility power failure)
  • Moderate natural hazards (e.g., localized flooding or earthquake compromising a facility)
Yes
Td4 Adversary with moderate resources who is willing to take little risk (e.g., organized crime, sophisticated hackers, international corporations) Yes Ta4
  • Serious mechanical failures (e.g., long term, city-wide power failure)
  • Serious natural hazards (e.g., earthquake with city-wide devastation)
  • Serious inadvertent or accidental events
No
Td5 Adversary with moderate resources who is willing to take significant risk (e.g., organized crime, international terrorists) No Ta5
  • Very serious mechanical failures (e.g., long term, regional power failure)
  • Very serious natural hazard (e.g., earthquake with regional or national devastation)
  • Very serious inadvertent or accidental events
No
Td6 Adversary with abundant resources who is willing to take little risk (e.g., well-funded national laboratory, nation-state, international corporation) No      
Td7 Adversary with abundant resources who is willing to take extreme risk (e.g., nation-states in time of crisis) No      

3. IT Security Approaches

3.1 Alignment with other Cloud Security Control Profiles

It is part of the GC cloud adoption strategy Footnote 1 to align GC cloud profiles with those of the Federal Risk and Authorization Management Program (FedRAMP) and other cloud-related initiatives, notably, the Cloud Security Alliance (CSA), the US Defense Information System Agency (DISA) Footnote 13, and the International Organization for Standardization (ISO) Footnote 14. This strategic alignment will help ensure interoperability between cloud service offerings, and the reusability of the IT security evidence used by other programs to certify or authorize cloud services.

3.2 Holistic Approach to IT Security

Unlike other cloud security control profiles, the GC cloud PBMM profile covers not just the CSP cloud service infrastructure but all of the CSP and GC infrastructure components that are used to both provide and consume cloud-based GC services. This holistic approach to IT security provides a stronger foundation to identify and mitigate risks to cloud-based GC services and related information from both a service or information hosting perspective and a service consumption or information use perspective.

As illustrated in Figure 3-1 Footnote 22, the coverage of the GC cloud PBMM profile includes the CSP’s cloud services infrastructure (consisting of people, processes, and technology), the GC service or information that is hosted on CSP’s cloud services, the GC user devices and networks that are used to consume the cloud-based GC service or access GC information, and any other infrastructure components where related GC information may reside.

Figure 3-1 Scope of GC Cloud PBMM Profile
Figure 3-1. Text version below:
Figure 3-1 Scope of GC Cloud PBMM Profile - Text version

Representative allocation of the security controls of the GC cloud PBMM profile to the CSP's cloud services infrastructure (consisting of people, processes, and technology), the GC IT service or information that is hosted on CSP's cloud services, on the GC user devices and networks that are used to consume the GC IT service or access GC information, and on other infrastructure components where related GC information may reside (which include external systems, external users, citizens, alternate sites, and other end user devices). More details is provided in the text below.

The scope of the GC cloud PBMM profile can be demonstrated using the following use cases:

  1. 1A GC user accesses a cloud-based GC service from a GC local network.
  2. A GC user accesses a cloud-based GC service from a GC local wireless network.
  3. A GC user accesses a cloud-based GC service from the internet.
  4. A CSP user accesses the cloud service environment from the CSP’s local network.
  5. A CSP user accesses the cloud service environment from the CSP’s local wireless network.
  6. A CSP user accesses the cloud service environment from the internet.
  7. A GC user stores cloud-hosted information on a portable storage media.
  8. A CSP user stores GC or CSP information on a portable storage media.
  9. A GC system administrator creates a backup of cloud-hosted information and sends the backup media at an alternative facility.
  10. The CSP uses an alternate facility to support their cloud service contingency plan.

In this holistic approach to cloud security, the majority of the security controls in the GC cloud PBMM profile needs to be implemented by both the CSP and GC departments and agencies, while some security controls need to be implement only by one or the other. The presence of these party-specific security controls is a direct result of the GC cloud adoption strategy (discussed in Section 3.1). It reflects the delta between cloud-based security control profiles and the generic ITSG-33 PBMM profile that GC departments and agencies are recommended to implement (in current GC IT Security Risk Management guidance) for all information systems supporting their GC programs and services.

3.3 IT Security Engineering Principles

In addition to the business, technical, and threat contexts documented in previous sections, the selection of security controls for the GC cloud PBMM profile was also influenced by the choice of security engineering best-practices applied to the implementation of dependable information systems. This profile is meant to address the IT security needs of a broad range of business activities, from day-to-day office work to citizen-facing service delivery applications to common and shared service infrastructure support. The protection of business activities call for security approaches where, at a minimum, the following main security engineering best-practices are applied:

  • Defence-in-depth: technical, operational (including personnel and physical), and management security controls are used in a mutually supportive manner to mitigate risks (e.g., technical access controls used to protect sensitive databases, and additional physical security to prevent unauthorized personnel to physically access the database servers).
  • Least-privilege: users are provided only the minimum access necessary to perform their duties (e.g., day-to-day tasks are performed using limited user accounts only, not administrative accounts).
  • Prevent-detect-analyze-respond-recover (PDARR): prevents attacks from being successful to the maximum extent feasible and then ensures that successful attacks can be detected and contained, IT assets can be restored to a secure and authentic state, and lessons learned are documented and used to improve the security posture of information systems.
  • Layered defence: ensures that the various layers of an information system such as applications, databases, platforms, middleware, and communications are adequately protected. This approach reduces the risk that a weakness in one part of the information system could be exploited to circumvent safeguards in other parts (e.g., SQL injection application-layer attacks bypassing network-layer boundary protection).

The broad range of applicability of this profile does not lend itself easily to the use of a set of IT security approaches where strict boundary protection and strong physical and personnel security are used as the main protection measures (this approach could potentially afford the use of weaker internal security controls). In contrast, this profile suggests a balanced set of security controls to reduce the risks of compromised internal elements of an information system being used to easily compromise additional elements. This profile also suggests security controls to detect, respond, and recover gracefully from security incidents. Many of these controls are operational controls that a mature CSP should have in place, not only for security reasons, but also for the efficient and cost-effective day-to-day operations and management of information systems.

Note: While selecting security controls is somewhat subjective, considerable effort was made to include security controls that mitigate real threats, and that can be implemented using readily available COTS products. As well, the selection of security controls was aligned to existing cloud security best practices and international cloud security certifications. Security controls that specify a specialized or advanced capability not required for all information systems were excluded from this security profile. Furthermore, every effort was made to achieve the appropriate balance between usability and security.

3.4 Multi-tenant Separation

There are threats specific to cloud computing that may not necessarily be mitigated to a sufficient degree by conforming to a standard set of security controls developed for non-cloud IT environments. In the absence of additional security controls to mitigate these cloud-specific threats, it is reasonable to expect a conforming cloud service to be operating at higher levels of residual risk than what would normally be expected in a more-traditional IT environment.

The most-significant increase in risk comes from the presence within cloud environments of multiple tenants, which may be operating under very different security requirements. A tenant operating under a less-stringent set of security controls could expose another tenant to unacceptable levels of risk because their respective cloud-based services are operating within a common logical environment over a common physical platform. One way to reduce this exposure is to separate the tenants whereby tenants with similar security requirements are grouped together and each group is provided with separate logical environments over a common physical platform, or completely separate physical environments. The physical separation reduces exposure more than logical separation. However, the downside of physical separation is a decrease in the hardware consolidation ratio, and a corresponding increase in costs to CSPs and, ultimately, to their consumers.

CSE provides network security zoning recommendations in ITSG-22 Footnote 15 and ITSG-38 Footnote 16, that, if implement correctly in a cloud environment, would result in relatively strong multi-tenant separation Footnote 23. GC departments and agencies will need to determine if and how authorized CSPs have implemented multi-tenant separation and must ensure that related threats and risks are taken into account when provisioning cloud services for their cloud-based GC service implementation initiatives.

3.5 Security Control Tailoring

The GC cloud PBMM profile specifies a baseline of security controls suitable to protect business processes and information as described in Section 2.1. The profile aims to ensure the appropriate mitigation of threats that could compromise through cloud-based GC services the confidentiality, integrity, and availability of IT assets supporting GC programs, services, and business activities.

Further tailoring of this profile for specific departmental security needs may be required.  However, GC organizations may need to limit tailoring to security controls that are within their scope of responsibility, as their ability to influence change in public cloud service offerings will likely be limited. This may apply to a lesser degree in private cloud service offerings, where the ability to negotiate changes to security controls is greater. This analysis is critical as it will define which deployment model can best meet a department's requirement. If deemed necessary, further tailoring of this profile to satisfy  specific departmental security needs will have to take into account the complex and subtle relationships between cloud consumers and CSPs as well as their scope of responsibility within the cloud service infrastructure.

To assist with tailoring and implementation, the GC cloud PBMM profile includes a suggested allocation of security controls and enhancements to the consumer and provider organizations and the cloud computing architecture layers defined in the NIST cloud computing reference architecture Footnote 17.

3.6 Procurement Considerations

Cloud service offerings are being acquired following the standard GC procurement process. This means that CSPs are subject to the Public Services and Procurement Canada (PSPC) Industrial Security Program. Through this program, the GC will include an appropriate set of security clauses in request for proposals (RFPs) for inclusion in cloud services contracts, while CSPs establish a strong personnel and physical security foundation for correctly implementing the IT security controls in the GC cloud PBMM profile.

4. GC Cloud PBMM Security Control Profile

Appendix A lists the security controls and control enhancements that constitute the GC cloud PBMM profile. This list is also maintained in other forms that are more suitable for use by IT and IT security practitioners as input to requirements engineering and other system development lifecycle (SDLC) activities.

While the entire GC cloud PBMM profile applies to a cloud-based GC service, neither the CSP’s nor the GC’s scope of responsibility extends to all of the security controls in the profile. This is illustrated in Figure 3-1. On the one hand, the profile includes GC-specific security controls that the CSP is not expected to implement. On the other hand, the profile includes cloud-specific security controls that GC organizations are not expected to implement. This variation in security control responsibility is a direct result of the GC cloud strategy taking a holistic approach to IT security (as outlined in Section 3.2), conforming to CSE’s recommended security controls, and maintaining an alignment with other cloud security initiatives for reasons of compatibility and reusability. The allocation of security control responsibility is included in Appendix A.

Figure 4-1 Scope of Responsibility
Figure 4-1. Text version below:
Figure 4-1 Scope of Responsibility - Text version

Scope of responsibility for security controls implemented at the different architectural layers as it applies to the Cloud service models.

Infrastructure as a Service:

  • Consumer Managed:
    • User Access/Identity
    • Data
    • Applications
    • Platforms
  • Service Provider Managed:
    • Resource Abstraction and Control
    • Hardware
    • Facility

Platform as a Service:

  • Consumer Managed:
    • User Access/Identity
    • Data
    • Applications
  • Service Provider Managed:
    • Platform
    • Resource Abstraction and Control
    • Hardware
    • Facility

Software as a Service:

  • Consumer Managed:
    • User Access/Identity
    • Data
  • Service Provider Managed:
    • Applications
    • Platform
    • Resource Abstraction and Control
    • Hardware
    • Facility

From the perspective of the CSP's infrastructure (delimited in Figure 3-1 by the CSP facilities component), the scope of responsibility also varies depending on the cloud service model. Figure 4-1 is a simplified view of the architectural layers to support the depiction of the scope of responsibility as it applies to the service models, using the NIST cloud reference architecture Footnote 17 and the cloud computing layers in NIST 500-299 Footnote 18 as the basis of the illustrations. An organization view was added to the cloud computing layers for security controls that are implemented by people, for example the development of policies and procedures, the execution of access control procedures, personnel security, security assessment and authorization, and risk management.

Under SaaS, the consumer has the capability to provision fundamental computing resources such as operating systems, storage, and networking, as well as the application software operating over these resources Footnote 17. Consequently, the consumer may be responsible for some of the security controls of the virtualization infrastructure layer and all of the security controls of the consumer organization, platform, and application layers. The consumer has no responsibility for the security controls of the hardware and facility layers.

Figure 4-2 Scope of Responsibility for IaaS
Figure 4-2. Text version below:
Figure 4-2 Scope of Responsibility for IaaS - Text version

Scope of responsibility for security controls in an Infrastructure as a Service (IaaS) service delivery model.

Consumer Organization

  • Applications
  • Platform
  • Resource Abstraction and Control (partial)

Service Provider Organization

  • Resource Abstraction and Control (partial)
  • Hardware
  • Facility

Under PaaS,the consumer has the capability to implement commercial software products over and custom business applications over CSP-provided operating systems, servers, and networks, application frameworks, and other program libraries and tools Footnote 18. As a result, the consumer may be responsible for some of the security controls of the platform layer and all the security controls of the consumer organization and application layers.

Figure 4-3 Scope of Responsibility for PaaS
Figure 4-3. Text version below:
Figure 4-3 Scope of Responsibility for PaaS - Text version

Scope of responsibility for security controls in an Platform as a Service (PaaS) service delivery model.

Consumer Organization

  • Applications
  • Platform (partial)

Service Provider Organization

  • Platform (partial)
  • Resource Abstraction and Control
  • Hardware
  • Facility

Under SaaS,the consumer has the capability to use CSP-provided software products and applications. In some cases, the consumer may also have the capability to configure certain aspects of a software product or application, for example, manage user accounts, create folder structures, or select and deselect optional functions. Consequently, the consumer may be responsible for some of the security controls of the application layer.

Figure 4-4 Scope of Responsibility for SaaS
Figure 4-4. Text version below:
Figure 4-4 Scope of Responsibility for SaaS - Text version

Scope of responsibility for security controls in a Software as a Service (SaaS) service delivery model.

Consumer organization

  • Applications (partial)

Service Provider Organization

  • Applications (partial)
  • Platform
  • Resource Abstraction and Control
  • Hardware
  • Facility

The allocation of the GC cloud PBMM profile to the the cloud computing archectural layers is included in Appendix A. Table 4-1 provides a summary of the allocation mapped to the following security control families:

AC

Access control

AT

Awareness and training

AU

Audit & accountability

CA

Security assessment and authorization

CM

Configuration management

CP

Contingency planning

IA

Identification and authentication

IR

Incident response

MA

Maintenance

MP

Media protection

PE

Physical and environmental

PL

Planning

PM

Program management

PS

Personnel security

RA

Risk assessment

SA

System and services acquisition

SC

System and communications protection

SI

System and information integrity

Table 4-1 Summary of Security Control Responsibility
  Cloud Service Model Architectural Layers Security Control Families
Consumer SaaS Application AC, AU, IA, SC, SI
PaaS Platform AC, AU, CM, CP, IA, MA, SC, SI
IaaS Virtualization Infrastructure AC, AU, CM, CP, IA, MA, SC, SI
All Facility & Hardware Not applicable
All Organization AC, AT, AU, CA, CM, CP, IA, IR, MA, PL, PS, RA, SA, SC, SI
Cloud Service Provider SaaS Application AC, AU, IA, SC, SI
PaaS Platform AC, AU, CM, CP, IA, MA, SC, SI
IaaS Virtualization Infrastructure AC, AU, CM, CP, IA, MA, SC, SI
All Facility & Physical PE
All Organization AC, AT, AU, CA, CM, CP, IA, IR, MA, MP, PE, PL, PM, PS, RA, SA, SC, SI
Report a problem or mistake on this page
Please select all that apply:

Thank you for your help!

You will not receive a reply. For enquiries, contact us.

Date modified: