Foreword

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the IT standards adopted by the Treasury Board Secretariat (TBS) for use across the government’s IT infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario.

In particular, GO-ITS describe where the application of a standard is mandatory and specify any qualifications governing the implementation of standards.

This standard describes principles and security requirements for business areas (or other organizations) that are selecting, procuring, adopting, operating, and/or managing Cloud Services on behalf of the Government of Ontario. This document draws some organization and controls from ISO/IEC 27002:2013, ISO/IEC 27018:2014, ISO/IEC FDIS 27017:2015, and NIST SP 800-53, and supports control 5.23 per ISO/IEC 27001:2022 and ISO/IEC 27002:2022.

1. Introduction

1.1. Cloud First

Cloud computing is fundamentally changing how I&IT services are delivered and used to build user-centered digital services. Adoption of cloud computing helps to ensure timely access to modern technologies, improve efficiencies, and increase value of I&IT services.

Cloud computing benefits include:

  • Cost reduction
  • Improved collaboration
  • Improved security integration
  • Increased workforce mobility
  • Greater agility
  • Greater resiliency

When procuring new or upgrading existing services, Ministries, Clusters, and agencies should consider and fully evaluate potential cloud solutions before considering traditional I&IT systems. Cloud computing can provide fast and competitive options for the Government of Ontario. Cloud Services are a mainstream technology choice for the Ontario Public Service (OPS), which is digitally transforming itself through the Simpler, Faster, Better Services Act, 2019, S.O. 2019, c. 7, Sched. 56.

The key principle that promotes a cloud first approach is Cloud-by-Default. The cloud market offers a broad range of services, and use of Cloud Services should be considered as the default option for the OPS provided that appropriate risk management, assessments, and consultations for identifying and addressing privacy and security concerns are aligned with the criticality of services, and the sensitivity of information to be stored, transferred, or processed.

This standard provides guidance on technical and security requirements for the adoption and use of Cloud Services. The Government of Ontario is currently working towards a more comprehensive suite of strategic policy tools that will further promote and accelerate adoption of Cloud Services. These policies will embrace the following principles, and offer a comprehensive cloud governance framework that will address procurement, finance, security, privacy, risk management, and other functional considerations important for cloud adoption:

Cloud First Principles

  1. Use Cloud Services as the default
  2. Adopt a risk-based approach for cloud adoption and cloud security
  3. Design and architect for the cloud, and avoid customization
  4. Take full advantage of Cloud Service functionality, automation practices, cloud-based security, and other features
  5. Monitor the health and usage of Cloud Services in real time
  6. Understand and comply with applicable legal and regulatory requirements

Each organization needs to evaluate potential cloud adoption options for their specific services, systems, and information based on the security requirements laid out below in this standard.

1.2. Background and rationale

Cloud computing refers to the rise and widespread use of metered, on-demand, elastic, pooled, and networked resources that enable I&IT infrastructure and services. The US National Institute for Standards and Technology (NIST) defines cloud computing as follows:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This Cloud model is composed of five essential characteristics, three service models, and four deployment models. (NIST SP 800-145)

Cloud computing presents opportunities for the Government of Ontario – including self-service, flexibility, elasticity, reduced capital costs, and value for I&IT spend. The purpose of this standard is to help ensure that the selection and use of Cloud Services does not result in undue levels of risk, and that Cloud Services are adopted within a risk-based model where security requirements, and requirements for evidence of controls, are geared to clear and appropriate criteria.

The Government of Ontario, per Freedom of Information and Protection of Privacy Act (FIPPA) regulations, has obligations to protect the security of certain information both in use (Regulation 460) and upon destruction (Regulation 459). Additional obligations exist under the Personal Health Information Protection Act (PHIPA) and the Archives and Recordkeeping Act. While this document describes minimum requirements for Cloud Service selection, adoption, and ongoing use, it does not (with the exception of some jurisdictional considerations in section 2.3) preclude Government of Ontario business areas from applying a stronger standard to protect information, or selecting enhanced controls for services they seek to acquire or have previously procured.

This document acknowledges several industry-standard cloud audit and reporting frameworks, for the purpose of evaluating, selecting, and adopting Cloud Services. This approach enhances the Government of Ontario’s ability to access the cloud marketplace, by embracing existing models for security and controls within Cloud Services. While this document leverages industry frameworks for selection and procurement, and does not explicitly apply all GO-ITS 25.x security requirements to broadly-defined Cloud Services and adoptions in all cases, individual instances, workloads, components, etc. operated by the OPS within cloud environments must comply with those requirements where they are relevant. Examples include, but are not limited to:

  • Operating system instances that may require security hardening, ongoing maintenance, backup
  • The need for malware controls within OPS-managed instances, components, etc.
  • Access control requirements
  • Specifications for cryptography used by the OPS

In situations where potential gaps in controls are determined to exist regarding Cloud Service adoption or ongoing operation, GO-ITS requirements should also be consulted.

1.3. Target audience

This standard applies to all Government of Ontario technology solutions providers, and all application development and integration initiatives that intend to acquire, procure, deploy, and/or operate/manage, Cloud Services on behalf of Government of Ontario business areas or other organizations within the scope of this document.

1.4. Scope

1.4.1. In scope

All Cloud Services meeting the definitions in section 2.1 of this document that are adopted by or provided to the Government of Ontario, or on its behalf, are within the scope of this document and its requirements. This includes Cloud Services that store and/or process Government of Ontario information (including data at rest, in use, and in transit). In this document, “customer” refers to any program area or other business entity within the Government of Ontario that is adopting Cloud Services, or an entity adopting Cloud Services on behalf of the Government of Ontario.

1.4.2. Out of scope

N/A

1.5. Applicability statements

1.5.1. Organization

All Ministries and Clusters are subject to Government of Ontario IT Standards.

All adjudicative and advisory agencies are subject to Government of Ontario IT Standards.

All other agencies that are using OPS information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to either the Management and Use of I&IT Directive OR Government of Ontario IT Standards by memorandum of understanding.

As new GO IT Standards are approved, they are deemed mandatory on a go-forward basis (go-forward basis means at the next available project development or procurement opportunity).

When implementing or adopting any Government of Ontario IT standards or IT standards updates, Ministries, I&IT Clusters and applicable agencies must follow their organization’s pre-approved policies and practices for ensuring that adequate change control, change management, and risk mitigation mechanisms are in place and employed. For the purposes of this document, any reference to Ministries or the Government includes applicable agencies.

1.6. Contact information

If you have questions or require further information about this document or the GO-ITS 25 series, please contact the following Cyber Security Division staff:

Contact informationContact 1Contact 2
Name/TitleAlex Fanourgiakis, Senior ManagerTim Dafoe, Senior Security Policy Advisor
Organization/MinistryMinistry of Public and Business Service DeliveryMinistry of Public and Business Service Delivery
DivisionCyber Security DivisionCyber Security Division
BranchCyber Security Strategy, Risk Management & Architecture BranchCyber Security Strategy, Risk Management & Architecture Branch
Section/UnitSecurity Policy and Standards UnitSecurity Policy and Standards Unit
Office Phone(647) 982-5216(416) 327-1260
E-mailAlex.Fanourgiakis@ontario.caTim.Dafoe@ontario.ca

2. Technical specification

This section describes the context for Government of Ontario cloud adoption, and states technical, operational, and procedural requirements for both the Government of Ontario as a customer of Cloud Services, and Cloud Service Providers (CSPs) that provide Cloud Services to program areas.

2.1 Deployment and service models

The US National Institute of Standards and Technology (NIST) definition of cloud computing includes the following four Cloud Deployment Models:

  • Public Cloud: a Cloud Service Infrastructure intended for use by the general public that resides on the premises of the Cloud Service Provider, and may be owned/operated by an organization, private company, or a combination thereof
  • Private Cloud: a Cloud Service Infrastructure intended for exclusive use by business areas within a specific organization, that resides on or off the premises of the customer, and may be owned/operated by a third party, the organization, or a combination thereof
  • Community Cloud: a Cloud Service Infrastructure intended for exclusive use by business areas from a specific group of organizations with shared concerns, that resides on or off the premises of the customer organizations, and may be owned/operated by a third party, one or more organizations, or a combination thereof
  • Hybrid Cloud: a Cloud Service Infrastructure composed of two or more Cloud Service Infrastructures that remain discrete and independent, but have been bound as an environment through technology, portability goals, and interoperability

Each Cloud Deployment Model above presents its own security implications and challenges; for example, the multi-tenant nature and public accessibility of Public Cloud is sometimes raised as a concern within specific sectors that deal with extremely confidential information and/or high integrity requirements.

Three Cloud Service Models are also defined by NIST:

  • Software as a Service (SaaS): The customer uses the Cloud Service Provider’s applications, which along with the accompanying Cloud Service Infrastructure are managed by the Cloud Service Provider and/or its subcontractor(s)
  • Platform as a Service (PaaS): the customer deploys created or acquired applications, supported using languages, APIs, etc. within a Cloud Service Infrastructure supplied and managed by the Cloud Service Provider and/or its subcontractor(s)
  • Infrastructure as a Service (IaaS): the customer provisions, deploys, and manages system, network, and storage resources within a Cloud Service Infrastructure supplied and managed by the Cloud Service Provider and/or its subcontractor(s)

While the components managed by the customer vary substantially per Cloud Service Model, many, but not all, information security controls apply to all Cloud Service Models. Each Cloud Service Model also carries both unique security benefit and potential for risk; for example, while IaaS may allow program areas to configure, harden, and operate system instances and operating system software to a customized and robust degree, the Cloud Service being provided may not offer support for information backup. Security and service level considerations/limitations such as this must be understood by program areas adopting Cloud Services prior to the provision of services.

Cloud Service Brokers (CSBs) may also play a role in adoption and management. These organizations act as intermediaries between customers and Cloud Service Providers, providing support with integration, interoperability, and orchestration of disparate services – or offering security features and policy enforcement, as in the case of Cloud Access Security Brokers (CASBs). In the OPS, partnerships between the I&IT organization and business owners / program areas will provide opportunities to better ensure OPS services integration, embedded/integrated security controls, reusability and generation of patterns/artifacts, shared learning, and alignment with the Digital Service Standard.

2.2. Deployment decisions

To address risk and ensure adequate protection of Government of Ontario I&IT assets, appropriate decisions must be made regarding the suitability for each Cloud Service Model given differing levels of potential business impact.

The Corporate Policy on Information Sensitivity Classification (ISC) and ISC Guidelines describe the classification and labelling of sensitive information stored or processed within the Government of Ontario. Classification and labelling are performed based on injury tests and potential impact in the event of a security incident or privacy breach; while an incident or breach that compromises the confidentiality of Unclassified information would be unlikely to result in impact, compromise and disclosure of High Sensitivity information could result in extremely serious impact to individual citizens and/or the Government of Ontario.

The possible impacts resulting from a potential breach of either or both confidentiality (as per ISC), and the business or service “criticality” of a given service, are therefore key criteria that must inform the decision to select and adopt Cloud Services. For the purposes of this document, service criticality is defined according to one or both of the following considerations:

  • The time-sensitivity associated with the service, as expressed through (but not limited to) known/documented quality level or service level metrics, availability, time to recover, and susceptibility to latency
  • The degree of data integrity associated with or required for (but not limited to) successful processing of information, records, transactions, etc. within the service

Service criticality can be understood to indicate the likely degree of business impact, injury, or harm that would result should the service suffer a serious failure regarding one or more of time-sensitivity, availability, or data/transaction integrity.

The following table applies to both processing of OPS information and data-at-rest security considerations for all Cloud Services within the scope of this document:

Deployment classification

Low Criticality

Medium Criticality

High Criticality

High Sensitivity

  • OPS internal hosting
  • Case-specific assessment
  • OPS internal hosting
  • Case-specific assessment
  • OPS internal hosting
  • Case-specific assessment

Medium Sensitivity

  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Case-specific assessment

Low Sensitivity

  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting

Unclassified

  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting
  • Public Cloud
  • Private Cloud
  • Community Cloud
  • OPS internal hosting

Fig. 1 – Deployment classification matrix

For the purposes of the table above, potential for Hybrid Cloud adoption should be understood to apply to any Deployment Model. For example, a Low Sensitivity, Low Criticality Hybrid Cloud deployment involving a Public Cloud Service Provider and a Community Cloud would be permissible. A similar proposal involving Medium Sensitivity records at the High Criticality level would be bound to a Public Cloud in a manner that contravenes Fig. 1 deployment options, however, and requires case-specific assessment that may support or preclude such a direction.

Cloud deployments that leverage internal I&IT environments and/or Private or Community Cloud Services, in conjunction with Public Cloud Services, however, must not be permitted if information sensitivity and data-at-rest considerations would have precluded the adoption of Public Cloud Services without a case-specific assessment. It should also be noted that in-scope internal OPS services must be fit for use at this level of sensitivity if used or leveraged in part.

2.3. Cloud Services and jurisdictions

While some organizations have high-level requirements that limit which jurisdictions can store, process, or transact information on behalf of a public service, the reality of a global Cloud Service market requires that program areas contemplating new adoption and deployment will likely have to consider that:

  • A given Cloud Service Provider’s supply chain may include sub-contractors and/or infrastructure components in one or more jurisdictions; and
  • Risk assessment per the program area and the specifics of the service under consideration (and/or consultation with the applicable Cloud Service Broker, procurement, etc.) may determine any exposure is within the program area’s risk tolerance and legal/legislative/regulatory obligations.

The following table therefore indicates areas where business owners should perform their own risk assessment for their programs/services, and applies to both processing of OPS information and data-at-rest security considerations for Cloud Services within the scope of this document:

Jurisdictional decision

Low Criticality

Medium Criticality

High Criticality

High and Medium Sensitivity

As determined by program area/risk

As determined by program area/risk

As determined by program area/risk

Low Sensitivity

No restriction

No restriction

As determined by program area/risk

Unclassified

No restriction

No restriction

As determined by program area/risk

Fig. 2 – Jurisdictional Decision Matrix

While jurisdiction, in and of itself, should not be an overriding concern for deployed services within the scope of this document, it should be noted that certain trade, export, security, or other agreements (at the provincial, federal, and international level) may impose constraints on program areas with regard to some jurisdictions (i.e., limits on trade or trade sanctions). Some trade agreements may also preclude limitations based on jurisdiction, or require justification. Program areas should consult resources including, but not limited to, the applicable Ministry’s legal counsel and procurement specialists, the Ontario/Quebec Internal Trade Secretariat, the Ontario Ministry of Economic Development and Trade, and relevant departments within the Government of Canada to ensure services in all jurisdictions are permissible under applicable agreements and law.

2.4. Requirements for customers

To acquire and operate Cloud Services in a manner that provides for security and reliability, Government of Ontario Cloud Customers must adopt minimum requirements for the selection and evaluation of Cloud Services, plans for their use, and their ongoing maintenance, operation, and monitoring. These requirements should be understood to be an adjunct to those controls and requirements described in existing GO-ITS 25.x security standards that align with ISO/IEC 27002:2013.

Review of any Cloud Service Provider audit and/or certification reports, policies, procedures, and other documentation described within this section must occur prior to procurement and provisioning of the Cloud Services.

The following requirements apply to Government of Ontario program areas, or other groups, adopting or maintaining Cloud Services within the scope of this document. Government of Ontario Cloud Customers:

Adoption of services

2.4.1. Must obtain reports, evidence, certifications, or assurance from the Cloud Service Provider regarding the presence of security controls within the Cloud Services (and consistency of security claims) according to the requirements in this document;

2.4.2. Must continue to apply ISC classification and labelling to Government of Ontario assets within Cloud Services, where applicable based on the Cloud Service Model, and make use of and/or evaluate Cloud Services features that can protect I&IT assets and/or records in support of this requirement;

2.4.3. Must confirm the major roles, responsibilities, and accountabilities described in this standard;

2.4.4. Must treat the Cloud Service Provider as a “supplier” of services to the Government of Ontario in all policy, contracts, and agreements that relate to supply chain security, integrity of services, and relationship with the customer;

2.4.5. Must account for all assets to be operated in or migrated to Cloud Services, including information, with care taken to denote any resulting or service-derived information as an asset (as relevant to the Cloud Service Model);

2.4.6. Must review and understand Cloud Service Provider documentation, policies, and procedures, regarding information backup (where applicable given the relevant Cloud Service Model) with a clear division of roles, responsibilities, and accountabilities documented in any contract or agreement and based on the Cloud Service Model, including the duty to secure (e.g., by cryptographic means) backup information and/or media, restoration of backups, testing, disposal/destruction, and applicable timelines for any or all of the above;

2.4.7. Must review and understand Cloud Service Provider documentation, policies, and procedures, to ensure they are acceptable, to obtain details regarding redundancy, failover, failure modes, and availability, determine any potential impact (positive or negative) to business continuity and disaster recovery plans, ensure any negative impact is acceptable (or can be mitigated), identify any applicable penalties/remedies (e.g., per SLA), and amend relevant customer documentation where required;

2.4.8. Must review and understand Cloud Service Provider documentation, policies, and terms that may affect interoperability, portability, and/or return of I&IT assets, ensuring that APIs, data formats (e.g., CSV, TSV, XML), and related options are sufficient to provide for service migration and/or asset return; and

2.4.9. Must define and maintain policy, procedures regarding requests for audit information and/or evidence from the Cloud Service Provider, ensuring contracts or agreements reflect mutually agreeable requirements regarding the division of audit roles and responsibilities, the format of audit requests, latitude for access, relevant timeframes, and compliance with legal, legislative, and/or regulatory requirements.

Risk management

2.4.10. Must consult this standard when determining security requirements and performing risk assessments (including case-specific assessment, if required) related to their cloud adoption or ongoing operations, and determine at an early stage if the documentation, controls, and capabilities demonstrated by a given Cloud Service Provider will meet customer security requirements, including both information and physical security;

2.4.11. Must perform due diligence and risk assessments for programs and projects, including the use of Threat and Risk Assessments (TRAs), Privacy Impact Assessments (PIAs), Business Impact Assessments (BIAs) (and, where feasible, Security Testing & Evaluation [ST&E]) regardless of cloud adoption or Cloud Service use;

2.4.12. Must create any required service-specific or platform-specific policy and procedures required to document appropriate management of risk, requirements for security and required degree of assurance in multi-tenant and/or virtualized environments relying on logical separation, and user/privilege management;

2.4.13. Must review and understand Cloud Service Provider services, documentation, policies, and procedures regarding the use, re-use, and disposal/destruction of I&IT assets with the context of the Cloud Service, ensuring that sensitive information (as defined by ISC) can be protected during decommissioning or upon service/contract termination, that I&IT assets and media that may contain such information are still treated as sensitive, and that disposal/destruction procedures are appropriate;

2.4.14. Must avoid the use of Medium and High sensitivity information (as per ISC classification and labelling) for test and development instances and/or applications within Cloud Services; where this is not technically feasible, determine exposure via customer risk assessment, and deploy an appropriate mitigation technique (e.g., additional safeguards, tokenization, strong industry standard de-identification techniques, etc.); and

2.4.15. Must abide by the deployment and jurisdictional guidance stated in this standard, and address both ISC classification/labelling and Cloud Service Provider jurisdiction in policy, procedures, and planning materials.

Service management and operations

2.4.16. Must address the important variances within Cloud Service Models as they pertain to both relevant security controls, and the division of roles, responsibilities, and accountabilities between the customer and the Cloud Service Provider, documenting these (e.g., within an approved and unambiguous RACI matrix), and any relevant agreements;

2.4.17. Must avoid any ambiguity in the documented division of roles, responsibilities, and accountabilities between customer and the Cloud Service Provider, particularly in the areas of information ownership, patch/vulnerability management, cryptography, ongoing maintenance, backup, continuity/recoverability, incident response, compliance, audit, and monitoring;

2.4.18. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding patch and vulnerability management with respect to the division of roles and responsibilities between the customer and the Cloud Service Provider, the relevance of the Cloud Service Model to these processes, resources required or consumed by these processes, and associated timelines and other considerations that influence the security of the customer;

2.4.19. Must determine, through contractual agreement and procedures, how any physical media will be transferred to or from the Cloud Service Provider, how details of such transfers will be recorded (e.g., sender, recipient, type of media, ISC labelling, date, time, the total number of physical media items, etc.), and how security in transit and authorized receipt will be ensured;

2.4.20. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding secure application development, if relevant to the Cloud Service Model, to determine these are acceptable and enforce an appropriate degree of rigour within the approach;

2.4.21. Must determine if the presence of utilities, APIs, etc. within the Cloud Services may interfere with intended controls or subvert the desired degree of security, depending on the Cloud Service Model;

2.4.22. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding change control, and the mechanism by which changes that may impact the security of customer I&IT assets are disclosed in advance, ensuring these are adequately addressed within service/contractual agreements;

2.4.23. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding capacity/workload management and related service levels, and ensure the capacity (or the capacity that can be made available on-demand) in all service/contractual agreements will be adequate to meet anticipated needs;

2.4.24. Must monitor, where relevant, both customer needs and Cloud Services capacity, to ensure capacity remains adequate during the contract or agreement, forecast any requirement for increased service levels, obtain full value from the services, and avoid impact to performance (e.g., lag, latency, bandwidth or storage capacity exhaustion, etc.);

2.4.25. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding the synchronization of network time or clocks, including (where relevant to the Cloud Service Model) any requirements to synchronize specific customer components with a Cloud Service Provider clock or shared third-party clock, and technical details to facilitate configuration; and

2.4.26. Must monitor, where relevant, third-party vendor software licencing, technical limitations, and other details to ensure expansion of Cloud Services capacity or increased service levels (e.g., an increase in the number of available processor cores) will not result in impact to the performance of the software, or compliance with the terms of the vendor software licence.

Access control

2.4.27. Must define and maintain policy, procedures regarding access control for both system and network environments within the Cloud Services (where relevant to the Cloud Service Model), and where possible, retaining the ability to administer and audit user access and privileges, including those required for administrative duties, either directly or through third-party support/integration;

2.4.28. Must determine, through planning, policy, and procedures, how users with elevated privileges and/or I&IT management roles will securely authenticate to the Cloud Services, including the use of sufficiently strong authentication methods based on ISC sensitivity, customer risk assessment, and the IAA Policy;

2.4.29. Must verify the password and authentication schemes (i.e., secure logon) in place, including underlying processes and ability to assign such requirements to accounts within the Cloud Services, determining their suitability with regard to customer risk assessment and the IAA Policy;

2.4.30. Must verify the ability to control/restrict access to information within the Cloud Service, using controls relevant to the Cloud Service Model, and consistent with customer risk assessment and information/asset value;

2.4.31. Must review and understand the Cloud Service Provider’s use of the security principles of least privilege and separation of duties within the design and operation of the Cloud Service, with contracts and agreements to reflect divisions of roles and responsibilities that incorporate these principles where possible; and

2.4.32. Where possible, must work with Cloud Service Providers to identify and leverage opportunities for integration with existing OPS and/or federated identity, authorization, and authentication services.

Incident management

2.4.33. Must address roles and responsibilities between the customer and the Cloud Service Provider (based on the Cloud Service Model) with regard to security incidents and privacy breaches, including the mutual ability and/or commitment to comply with relevant legislation/regulations, within contracts, policies, procedures, and planning materials;

2.4.34. Must incorporate information security and privacy details regarding the Cloud Services into customer awareness/training material where relevant, making staff aware of proper use/operation of the service, and potential consequences in the event of security incidents, privacy breach, or breach of terms related to contracts or agreements;

2.4.35. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding the division of roles and responsibilities when responding to security incidents or privacy breaches, ensuring the documented roles and responsibilities will be adequate to support customer requirements;

2.4.36. Must review and understand Cloud Service Provider documentation, policies, and procedures to ensure any notifications, detail within notifications, promptness and timeframes for notification and response, internal review requirements, and, if applicable, any remedies provided in response to security incidents or privacy breaches will be adequate; and

2.4.37. Must review and understand Cloud Service Provider services, documentation, policies, and procedures to determine the process (and obtain relevant contact information) to promptly report and/or track the status of a security event, security incident, or privacy breach it discovers, or that is reported to the customer by the Cloud Service Provider or a third party.

Logging and audit

2.4.38. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding logging and monitoring requirements (with review based on baseline logging requirements stated in GO-ITS 25.0), including roles and responsibilities for generating logs, ensuring that sufficient detail will be logged, that anomalous events are noted and reviewed (including the cause of such events, where possible), and that customer logs potentially containing sensitive information are subject to access control and management (i.e., not available for review by unauthorized staff or other customers);

2.4.39. Must review and understand the technical capacity and behaviour of any logging or audit functionality within the Cloud Service, ensuring that logging information required for organizational or legislative compliance can be stored in a permanent manner and with a degree of access and retention appropriate for services operated by or on behalf of the Government of Ontario;

2.4.40. Must review and understand the technical capacity and behaviour of any logging or audit functionality within the Cloud Service, ensuring that the use of elevated privileges are recorded (even within the customer’s environment or services by the customer’s authorized users); and

2.4.41. Must arrange (e.g., by contractual agreement) for regular/scheduled Cloud Service Provider security and audit reporting for Cloud Services operating in support of Medium Sensitivity information, and/or any services operating at the High Criticality level.

Cryptography

2.4.42. Must verify that any required cryptographic controls within the Cloud Service permit for the Government of Ontario to maintain ownership and control over key material used to protect Government of Ontario I&IT assets, and are based on cryptographic implementations that satisfy GO-ITS 25.12 requirements;

2.4.43. Must confirm that conflicts do not exist between the design of cryptographic services or their capabilities, as provided by the Cloud Service Provider or operated by the customer, and any legal requirements or limitations regarding encryption on the part of those jurisdictions within the scope of the Cloud Service; and

2.4.44. Must review and understand Cloud Service Provider documentation, policies, and procedures regarding cryptographic controls, how the Cloud Service Provider intends to use such controls to deter security incidents or privacy breaches, key management support and limitations (e.g., integrity of customer keys, different keys for service vs. management functions, lifecycle management, etc.).

Compliance

2.4.45. Must identify and document any relevant legal, data protection, or other authorities relevant to Cloud Service Provider (or subcontractor) jurisdiction(s), with the understanding that the regulatory context of such jurisdictions may apply to some or all of the contract or agreement associated with the Cloud Service; and

2.4.46. Must determine, and obtain documentation regarding, the protections within the Cloud Service for public records throughout their lifecycle, to prevent unauthorized destruction and ensure public records are only disposed of in accordance with the Archives and Recordkeeping Act.

2.5. Requirements for Cloud Service Providers

Cloud Service Providers providing Cloud Services to the Government of Ontario will share some roles and responsibilities regarding the ongoing operation of their services. The following requirements apply to all Cloud Service Providers providing Cloud Services to, or on behalf of the Government of Ontario program areas per the scope of this document, and complement those controls and requirements described in existing GO-ITS 25.x security standards that align with ISO/IEC 27002:2013.

The definition of “must” and/or “should” within this document should be consulted to provide context for these requirements; it is expected that Cloud Service Providers will endeavour to both meet the requirements and provide evidence (including from audit reports or other forms of assessment/attestation) regarding how specific controls and/or security functions are addressed within relevant environments and services. Cloud Service Providers:

Provision of services

2.5.1. Must provide the Government of Ontario with evidence, in the form of audit reports, certifications, or other assurance, that the presence of security controls within the Cloud Service is consistent both with the requirements stated within this document, and any claims or representations made regarding the degree of security provided by the Cloud Service, supporting infrastructure, and physical facilities;

2.5.2. Must provide the Government of Ontario with unambiguous, documented details regarding the ownership of information within the Cloud Service, including ownership of resulting or service-derived information created through the use of the Cloud Service;

2.5.3. Should provide the Government of Ontario with unambiguous, documented details regarding the division of roles, responsibilities, and accountabilities associated with provision and ongoing operation of the Cloud Service, including subcontractor roles and responsibilities, if relevant;

2.5.4. Should provide the Government of Ontario with documentation or information regarding the overarching security practices and safeguards within the Cloud Service and supporting infrastructure, including a documented, unambiguous division of security roles and responsibilities relevant to the Cloud Service type, save for details that would compromise sensitive internal information or operational security, or divulge proprietary techniques;

2.5.5. Should provide the Government of Ontario with documentation, including technical and procedural details, regarding the security program and controls intended to protect I&IT assets and records, including but not limited to access control (including authorization and authentication), physical/operational security, user and privilege management, multi-tenant and virtualization security, hardening, isolation/separation of customer instances and/or environments, patch and vulnerability management, insider threat management, mobile device risk, malware controls, and lifecycle management;

2.5.6. Should endeavour to ensure that subcontractors and/or third-parties supporting Cloud Service Infrastructure can make, and provide evidence for, claims to operate at a level of security equivalent to or greater than that of the Cloud Service Provider, and where appropriate, share security metrics or objectives to this end;

2.5.7. Should provide the Government of Ontario with documentation or information regarding redundancy, failover, failure modes, and availability within the Cloud Service, including potential impact (positive or negative) to the security posture and availability of customer information, operations, and/or the Cloud Service as a whole, with guidance should these functions not be provided or part of a given service level;

2.5.8. Should identify to the Government of Ontario the jurisdiction(s) where the Cloud Service or components thereof are located, including those intended as redundant, backup, or failover sites, storage locations, backup and/or media storage locations, and those associated with subcontractors;

2.5.9. Should provide the Government of Ontario with documentation or information regarding access to, and handling and protection of, customer information, including protection of records, acceptable use, employee screening, and separation of duties, demonstrating that sensitive information is safeguarded, so that these details can be used to evaluate the services and educate users;

2.5.10. Should provide the Government of Ontario with documentation or information regarding information and/or record labelling capabilities, where relevant based on Cloud Service type, to assist in compliance with ISC labelling requirements; and

2.5.11. Should provide the Government of Ontario with documentation or information regarding secure disposal and/or destruction of I&IT assets, media, and equipment.

Service management and operations

2.5.12. Must provide the Government of Ontario with notifications of major changes that have the potential to cause impact to service delivery and/or the level of security within the Cloud Service or a supporting environment, and details of such changes (including, but not limited to, the type and category/severity of change, services, assets, and/or environments affected, planned date, time, and duration of the change, and notification of change completion;

2.5.13. Should provide the Government of Ontario with documentation or information that demonstrates the approach taken regarding change management within the Cloud Service or a supporting environment;

2.5.14. Should provide the Government of Ontario with documentation or information regarding patch, flaw remediation, and vulnerability management operations, including a documented, unambiguous division of roles, responsibilities, and accountabilities, processes in use, interactions with change management, and any resources required;

2.5.15. Should enforce (and provide documentation that describes), where relevant to the Cloud Service and Deployment Model, a reliable and/or assured degree of multi-tenant separation within the Cloud Service, a strong degree of separation between the multi-tenant environment and management plane/supporting infrastructure, with evidence provided (e.g., reports, certifications, etc.) that such functionality is reliable to the claimed degree;

2.5.16. Should provide the Government of Ontario with documentation or information regarding information backup, including but not limited to an unambiguous statement regarding the scope, intent, and responsibilities associated with any offered backup service (or lack thereof, depending on the Cloud Service type and specific offering), the methods, scheduling, and supported media formats for backups, type of backups (e.g., full, incremental, or differential) and costs, if these vary by service level, any cryptographic support or protection and related details (e.g., keying), integrity checking, the jurisdiction(s) and physical location of customer backups, test and restore procedures, intervals for backup tests, timeframes for restoration, and retention periods;

2.5.17. Should maintain an asset management capability that permits for the ongoing accounting and tracking of all customer I&IT assets, including information, where relevant based on the Cloud Service type;

2.5.18. Should provide the Government of Ontario with documentation or information regarding network time or clock synchronization within the Cloud Service and/or supporting infrastructure, including potential situations where benefit is obtained or where services require clock synchronization, and details regarding configuration (e.g., protocol versions, cryptography and keys, etc.);

2.5.19. Should provide the Government of Ontario with documentation or information regarding practices and processes used for secure application development, where relevant given the Cloud Service type, save for details that would compromise sensitive internal information or operational security, or divulge proprietary techniques;

2.5.20. Should provide the Government of Ontario with documentation or information regarding the presence of system utilities, APIs, or software etc. within the Cloud Services that may interfere with intended controls, subvert the desired degree of security, or cause multi-tenant impact, depending on the Cloud Service type, or how access to any utilities, etc. have been limited to authorized staff and/or made subject to audit;

2.5.21. Should provide the Government of Ontario with documentation or information that demonstrates the approach taken regarding secure disposal and/or destruction of I&IT assets, media (magnetic and semiconductor/flash), and equipment, including any “sanitization” techniques or specifications in use, and treatment of media that may contain sensitive customer information as if it does;

2.5.22. Should ensure the capacity and related capabilities in any contract or agreement will be monitored to prevent resource or bandwidth exhaustion, performance impact, or any other shortage, disclose any constraints or limitations regarding these aspects of the Cloud Service, and make customer resource usage statistics/reports available; and

2.5.23. Should provide the Government of Ontario with documentation or information regarding physical media, and potential receipt of or transfer to the customer, including, but not limited to how details (e.g., sender, recipient, type of media, names or labels, date, time, the total number of physical media items, etc.) are recorded and tracked, and how security in transit and authorized receipt are to be ensured.

Access control

2.5.24. Should provide the Government of Ontario with documentation or information regarding access control, including physical and logical access, user and privilege management, and user registration and removal, where applicable (demonstrating that access to the Cloud Service can be managed both directly and securely);

2.5.25. Should provide the Government of Ontario with documentation or information regarding support for user access rights management within the Cloud Service, where applicable, including details regarding support of third-party authentication schemes, integration, or APIs;

2.5.26. Should provide for sufficiently strong, or multi-factor, authentication (or “secure logon”) mechanisms (or integration options) that resist known attack vectors, for use in authenticating users with elevated privileges and/or I&IT management roles (and must provide such where required by the IAA Policy or a relevant TRA/PIA); and

2.5.27. Should provide the Government of Ontario with documentation or information regarding the password management policies and processes in place within the Cloud Service, including configuration options, storage, and cryptographic treatment of passwords, so that these details can be used to evaluate the services and educate customer users.

Incident Management

2.5.28. Must provide the Government of Ontario with documentation and unambiguous, documented details regarding the division of roles and responsibilities for incident response procedures to be used in the event of a security incident or privacy breach, and any capacity for assisting or accommodating customers in obtaining evidence, performing investigations, or conducting forensics (relevant to the Cloud Service Model in question);

2.5.29. Must provide the Government of Ontario with documentation or information regarding any definitions for security events, incidents, and privacy breaches, such that these can be understood and/or agreed upon, including, but not limited to methods for detection and prompt notification of security incidents or privacy breaches, including timeframes for notifications, contact information (e.g., contact names, phone numbers, email addresses, etc.), requirements for post-incident review to make determinations if a privacy breach is likely to have occurred, and any applicable remedies; and

2.5.30. Must provide the Government of Ontario with relevant procedures, points of contact, and escalation paths for the reporting of security incidents or privacy breaches.

Logging and audit

2.5.31. Should provide the Government of Ontario with capabilities to perform logging of events within the context of the Cloud Service, a documented, unambiguous division of roles and responsibilities regarding logging, and disclose any constraints or limitations regarding logging, the supporting environment, distinctions where the customer is expected to generate logs, details regarding retention and handling of logs, and/or any general lack of logging features or components within the Cloud Service; and

2.5.32. Should provide the Government of Ontario with documentation or information regarding the type and frequency of routine reviews of log information, a documented, unambiguous division of roles and responsibilities regarding log review, support for notification of integrity changes, for sensitive information, tracking causes of log entries (e.g., what event, user, or process resulted in the entry), correlation of log entries between infrastructure components or the supporting infrastructure (including subcontractors), logging the use of elevated privileges (to detect inappropriate use), and ensuring review can only be performed by authorized staff.

Cryptography

2.5.33. Must support the import and use of key material owned and managed by the Government of Ontario for cryptographic controls intended to protect the confidentiality and/or integrity of sensitive Government of Ontario information, where such controls are required, with security protections, lifecycle support, key management, and key expiry support for such key material;

2.5.34. Must provide the Government of Ontario with evidence (e.g. reports, evidence, certifications, etc.) that any necessary cryptographic requirements can be met within the Cloud Service and the relevant jurisdiction(s), where relevant to the Cloud Service type; and

2.5.35. Should provide the Government of Ontario with documentation or information regarding the specification, implementation, and use of cryptography within the Cloud Service, including (but not limited to) encrypted traffic, encrypted storage, algorithms, modes of operation, key specifications, key exchange, key management, the ability to import and protect customer key material, supported protocols, supported certificate formats, the ability to import certificates, and the intended or suggested use to protect sensitive information.

Compliance

2.5.36. Should provide the Government of Ontario with documentation, including technical and procedural details, regarding legislative compliance and any related controls; and

2.5.37. Should identify to the Government of Ontario any regulatory or legal authorities in the jurisdiction(s) relevant to the Cloud Service, including any known considerations that may relate to stored information (“data at rest”), the use of cryptography, data protection, backups, or similar items.

2.6. Existing audit frameworks and certifications

A number of third-party audit/reporting frameworks and certification schemes exist to help industry determine the security controls in place for a given Cloud Service Provider, and to assist Cloud Service Providers in positioning various offerings. Some frameworks focus on accountability and transparency, in addition to security and assurance.

To encourage adoption while addressing risk, the Government of Ontario recognizes the following audit, attestation, reporting, and certification frameworks provided that certain conditions are met, and compliance is demonstrated both initially and through the ongoing provision of services:

2.6.1. SOC 2/SOC 3

SOC 2 and SOC 3 (Service Organization Controls) reports are based on the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria and supporting guidance. These reports document examination of operational controls relevant to customers and partners, including security (confidentiality, processing integrity, availability, etc.) and privacy. Type I reports examine the design of operational controls for a specified point (or “snapshot”) in time, while Type II reports include testing the operational effectiveness of those controls, and their likely efficacy over a specified period of time.

SOC 2 Type I reports (when current, and appropriately scoped and conducted against all relevant principles and requirements) should constitute adequate evidence for the adoption and provision of Cloud Services for programs and services operating at Unclassified and Low Sensitivity levels, and up to the Low Criticality level.

SOC 2 Type II and SOC 3 reports (when current, and appropriately scoped and conducted against all relevant principles and requirements) should constitute adequate evidence for the adoption and provision of Cloud Services for programs and services operating at the Medium Sensitivity level, and up to the Medium Criticality level.

2.6.2. FedRAMP Moderate

The US Federal Risk and Authorization Management Program (FedRAMP) is a standardized Cloud Service adoption program, jointly operated by the GSA, NIST, OMB, DHS, DOD, and the US CIO Council. FedRAMP includes security assessment and authorization components, and draws on NIST SP 800-53 as a basis for controls. Unlike some Cloud Service adoption models, FedRAMP requires that assessment and authorization be based on independent review and evidence.

FedRAMP Moderate certification should constitute adequate evidence for the provision of Cloud Services for programs and services operating at the Medium Sensitivity level, and up to the High Criticality level.

2.6.3. FedRAMP High

FedRAMP High certification should constitute adequate evidence, when considered within the scope of a case-specific assessment as described in section 2.7, that the provided Cloud Services comply with the section 8.3 controls in this document.

Due to the nature of Cloud Service components and features, Government of Ontario Cloud Customers must use caution when relying on FedRAMP High certification in this manner, ensuring each component and feature intended to meet section 8.3 requirements for a given program/deployment is compliant with and certified to the FedRAMP High Baseline. In instances where this is not possible, conduct the case-specific assessment with internal/independent section 8.3 validation in-scope.

2.6.4. CSA STAR

The CSA Security Trust Assurance and Risk (CSA STAR) program is a Cloud Service assessment and assurance program intended to assist Cloud Service Providers in demonstrating security controls and maturity. CSA STAR is based on the CSA Cloud Controls Matrix (CCM), which maps to a number of existing reporting and certification frameworks.

CSA STAR Level 1 assessments are a free, self-assessment process by which Cloud Security Providers may present security claims, and document their own controls. Submitted Level 1 claims are published on the CSA public website, to encourage accountability in self-assessment.

There are two types of CSA STAR Level 2 claims:

  • CSA STAR Level 2 attestations draw from the AICPA Trust Services Criteria used for SOC 2 and SOC 3 reports, in addition to the CSA Cloud Controls Matrix.
  • CSA STAR Level 2 certifications draw from both the ISO/IEC 27001:2013 standard for security management systems and the CSA Cloud Controls Matrix, and must be performed by a CSA-accredited certification body.

For both types of Level 2 claims, independent assessment of the Cloud Service Provider is required.

CSA STAR Level 1 assessments should constitute adequate evidence for the provision of Cloud Services for programs and services operating at Unclassified and Low Sensitivity levels, and up to the Medium Criticality level.

CSA STAR Level 2 attestations and/or certifications should constitute adequate evidence for the provision of Cloud Services for programs and services operating at the Medium Sensitivity level, and up to the High Criticality level.

2.6.5. Other frameworks and certifications

The Government of Ontario will track the creation and industry adoption of additional audit, reporting, attestation, and certification schemes to determine if they may assist in adoption of Cloud Services.

2.6.6. Multi-party certifications and recognition

As multiple, internationally-recognized audit/reporting frameworks mature, opportunities for mutual recognition and multi-party agreements will arise. The Government of Ontario will track and encourage multi-party recognition, and accept reporting/certifications from other jurisdictions – at their appropriate sensitivity/criticality levels for deployments, and subject to regulatory requirements – should industry-recognized standards bodies and technical authorities (e.g., Cloud Security Alliance, ISO/IEC, etc.) soundly negotiate such arrangements for the betterment of the Cloud Services marketplace.

2.7. Case-specific assessment

In some situations (per Fig. 1 of this document), the information sensitivity and/or criticality associated with a service under consideration for Cloud deployment will require case-specific assessment, beyond the scope of industry audit and reporting frameworks alone, prior to Cloud Services adoption. Such assessments may either support or preclude the delivery of such programs or services by means of Cloud adoption; this is determined on a case by case, risk-assessed basis. The scope of the assessment may also be inclusive of a proposed architecture/design.

Case-specific assessment in this context must include, but is not limited to, an appropriately scoped Threat and Risk Assessment (TRA) completed by a qualified analyst, in accordance with an acknowledged TRA methodology. In instances where the service requiring case-specific assessment additionally processes and/or stores Personal Information (PI), this requirement must be extended to include an appropriately scoped Privacy Impact Assessment conducted by a qualified analyst, in accordance with an acknowledged PIA methodology.

Final decisions and authority to operate/deploy using Cloud Services (further mitigate the accompanying go-live risk identified) at those information sensitivity and/or criticality levels that require case-specific assessment must also be obtained from both senior IT and business management.

For the purposes of this document, the decision/acceptance regarding Cloud Service deployment beyond the scope of permitted models in Fig 1. (i.e., at the Medium Sensitivity and High Criticality level, or the High Sensitivity level), must be obtained from the program ADM level and IT Cluster CIO, unless identified go-live risk is greater than Medium/Moderate. The decision/acceptance for deployment go-live risk greater than Medium/Moderate must be obtained from the program DM level and Corporate CIO.

In instances where significant and/or unusual go-live risk has been identified during IT Cluster CIO decision/acceptance, IT Cluster CIOs should inform Corporate CIO when possible.

Even when case-specific assessment indicates that sensitive programs and services are suitable for cloud deployment, additional or augmented controls, and/or architectural/design elements, may be required to be implemented to ensure that adequate safeguards and operational support will be in place. In cases, these requirements may have significant dependencies on OPS infrastructure, CSP capabilities – or both. These controls and/or parameters are drawn from existing cloud guidance within industry; their application is described in the appendix (section 8.3) of this document.

Related standards

2.8. Impacts to existing standards

Identify any standards that reference or are referenced by this standard and describe the impact.

StandardImpactRecommended action
Digital Service StandardRelevant to guidance re: design, standards, and security, with need for alignment and acknowledgement of opportunities/transformationConsult as recommended
GO-ITS 25.0Reference/complianceConsult as recommended
GO-ITS 25.12Reference/complianceConsult as recommended

2.9. Impacts to existing environment

Impacted infrastructureImpactRecommended action
(Includes common components and other applications)-Not Applicable

3. Compliance requirements

3.1 Implementation and metrics

The intention of the OCCIO is to advertise and promote this standard as being a mandatory component throughout government. However, in order to effectively manage its implementation, Ministries, Clusters and applicable agencies are expected to adopt and monitor compliance to this standard.

4. Roles and responsibilities

4.1. Customers and CSPs

Cloud Customers

Cloud Customers are responsible for:

  • Understanding, acting on, and/or implementing the requirements in this document, and ensuring that agreements that they enter into with Cloud Service Providers will address the requirements in this document;
  • Planning for and completing all required Threat and Risk Assessments and/or Privacy Impact Assessments, and supporting these processes to ensure risk is identified and treated;
  • Determining both initial and ongoing adherence and recognition on the part of a Cloud Service Provider to at least one of the audit, reporting, attestation, and/or certification frameworks described within this document;
  • Conducting case-specific assessments when required, and ensuring implementation of required additional or augmented controls, and/or architectural/design elements; and
  • Monitoring that the deployment, use, and support of security controls and services/features within Cloud Services adhere to these requirements.

Cloud Service Providers

Cloud Service Providers are responsible for:

  • Ensuring that contractual and service level agreements regarding Cloud Services are met, and that security controls and capabilities remain consistent with claims, attestations, etc. provided to the Government of Ontario;
  • Demonstrating adherence to and recognition under at least one of the audit, reporting, attestation, and/or certification frameworks described within this document, both at the onset of service adoption, and continually through the provision of services;
  • Providing routine, periodic security and audit reporting to the Government of Ontario according to the requirements in this document, as determined by the business area, or as recommended by a TRA;
  • Immediately notifying the Government of Ontario or any Cloud Service customer operating or processing information on behalf of the Government of Ontario in the event of a security incident and/or privacy breach; and
  • Where indicated, providing the Government of Ontario with information relevant to the Cloud Services, or associated controls.

4.2. Government of Ontario

Business owners

Business owners (e.g., a program owner having Director or equivalent authority and accountability under legislation, regulation, policy, or other instruments for their business activities and related business records) are responsible for:

  • Understanding, acting on, and/or implementing the requirements in this document where applicable;
  • Understanding and fulfilling their ongoing obligations for the protection of Government of Ontario information and I&IT assets, including but not limited to personal information and business records, and jurisdictional/sub-contractor risk, regardless of Cloud Service adoption and use;
  • Understanding the risk associated with their technology solutions; and
  • Documenting Cloud Services in a transparent and comprehensive manner with regard to architecture, design, interfaces, APIs, network/traffic flow, security features/capabilities, and other relevant considerations in project materials.

I&IT Clusters

I&IT Clusters are responsible for:

  • Understanding, acting on, and/or implementing the requirements in this document where applicable;
  • Understanding and fulfilling their ongoing obligations for the protection of Government of Ontario information and I&IT assets, including but not limited to personal information and business records, regardless of Cloud Service adoption and use;
  • Partnering with and assisting business areas, where appropriate, with Cloud Service architecture/design, integration and documentation, and monitoring Cloud Service adoption; and
  • Documenting Cloud Services in a transparent and comprehensive manner with regard to architecture, design, interfaces, APIs, network/traffic flow, security features/capabilities, and other relevant considerations in project materials.

Corporate Chief Information Officer

The Corporate Chief Information Officer (OCCIO) is responsible for:

  • Setting the overall vision, strategies, and policies for the I&IT organisation to support the government transformation agenda, including policies, guidelines, and tools to accelerate cloud adoption practices within OPS.

Cyber Security Division

MPBSD Cyber Security Division, or a successor division, is responsible for:

  • Understanding, acting on, and/or implementing the requirements in this document where applicable;
  • Performing Threat and Risk Assessments (TRAs) for programs and projects that may acquire/deploy Cloud Services, and monitoring for emerging threats to Cloud Services;
  • Performing case-specific assessments required by this document, and determining required additional or augmented controls, and/or architectural/design elements;
  • Assisting with security integration for Cloud Services;
  • Monitoring the status of industry standards, Cloud Service offerings, and Cloud security/audit frameworks that provide for assessment, attestation, or other forms of assurance or certification on behalf of Cloud Service Providers; and
  • Maintaining this document.

Information, Privacy and Archives Division

Information, Privacy and Archives (IPA) is responsible for:

  • Understanding, acting on, and/or implementing the requirements in this document where applicable;
  • Advising and supporting business owners, programs, and projects to understand their access, privacy and records management obligations in accordance with both the Archives and Recordkeeping Act and Freedom of Information and Protection of Privacy Act, when acquiring and deploying Cloud Services; and
  • Monitoring the development of privacy frameworks and directions for Cloud Services.

Information Technology Services

Information Technology Services (ITS) is responsible for:

  • Understanding, acting on, and/or implementing the requirements in this document where applicable;
  • Working with business owners, Clusters, and I&IT projects, as required and appropriate, to assist them in meeting the security requirements in this document where applicable, and promoting integration/reusability;
  • Acting as a central service provider and Cloud Service Broker for Cloud Services adopted by other Ministries; and
  • Maintaining appropriate OPS internal hosting/technology capabilities to accommodate programs and projects that do not or cannot adopt Cloud Services.

Ontario Digital Service

The Government of Ontario Chief Digital and Data Officer (CDDO) is responsible for:

  • Supporting Ministries and Clusters, per the Simpler, Faster, Better Services Act (2019, S.O. 2019, c. 7, Sched. 56), in identifying opportunities for digital transformation that allow for:
    • Access to high-quality digital services from anywhere and at any time,
    • Digital services that are well-designed and operate effectively,
    • Better access to useful government data,
    • The best use of digital resources and data by eligible/applicable public sector organizations, assisting them in developing and implementing policies, programs, and services;
  • Advising Ministries and Clusters on the use and application of the Digital Service Standard;
  • Conducting Digital First assessments for eligible projects, ensuring alignment with the Digital Service Standard; and
  • Maintaining the Digital Service Standard.

Ontario Internal Audit

The Ontario Internal Audit Division is responsible for:

  • Conducting periodic audits of pertinent activities to test compliance with security standards;
  • Communicating with appropriate management about the risks identified and the severity of those risks; and
  • Working with management to identify the needed management action plans to mitigate the risks noted during the course of an audit and conducting follow-up as required.

5. Acknowledgements

Consulted

Please indicate who was consulted as part of the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: consulted means those whose opinions are sought, generally characterized by two-way communications such as workshops):

Organization consulted (Ministry/Cluster)DivisionBranchDate
MOFOIAD-Apr. 17 2015
Committee/working group consultedDate
ITELCNov. 2019
Architecture Review BoardNov. 2019
Architecture Review BoardOct. 2019
Cloud First Working GroupOct. 2019 – Nov. 2019
Cyber Security Working GroupJun. 2018 – Aug. 2018
Cloud Directors Working GroupFeb. 2015 – Nov. 2015
GC Cloud RFI Working GroupApr. 2015
Architecture Review BoardJul. 2015
Nov. 2015
ITELCJan. 2016
Architecture Review BoardNov. 2022

Informed

Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: informed means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):

Organization Informed (Ministry/Cluster)DivisionBranchDate
TBS - CCIOOCCIO-Apr. 21 2015
Committee/Working Group InformedDate
Cloud Directors Working Group

Feb 2015 – Jan 2016

SDLC/ITSML

July 2015

6. Publication details

All approved Government of Ontario Information Technology Standards (GO-ITS) are published on the OCCIO Intranet web site. Please indicate below if this standard is also to be published on the public, GO-ITS Internet Site.

Publication of GO-ITS standardYes/No
Standard to be published on both the OPS Intranet and the GO ITS Internet web site (available to the public, vendors etc.)

YES

7. Requirements levels

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

Must -This word, or the terms "required", or "shall”, means that the statement is an absolute mandatory requirement.

Should -This word “should”, or the adjective "recommended”, means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, and cost) must be understood and carefully considered before deciding to ignore the recommendation.

8. Appendices

8.1. Normative references

Simpler, Faster, Better Services Act (c. 7, Sched. 56), S.O. 2019
Archives and Recordkeeping Act, S.O. 2006
Freedom of Information and Protection of Privacy Act, R.S.O 1990
Personal Health Information Protection Act, S.O. 2004
Management and Use of I&IT Directive, Aug. 2016
Corporate Policy on I&IT Security, Jun. 2011
Corporate Policy on Protection of Personal Information, Jul. 2011
Corporate Policy on Recordkeeping, Mar. 2015
Corporate Policy on Electronic Identity, Authentication and Authorization, Jul. 2012
Corporate Policy on Information Sensitivity Classification, Aug. 2018
Information Sensitivity Classification Guidelines, Aug. 2018
Digital Service Standard, 2019
GO-ITS 25.0 General Security Requirements, Version 1.3, Mar. 2016
GO-ITS 25.12 Use of Cryptography, Version 1.5, Oct. 2020
Taking the Right Steps – A Guide to Managing Privacy and Privacy Breaches, Apr. 2018
Guidelines for the Protection of Information When Contracting for Services, Dec. 2008

8.2. Informative references

CSA Cloud Controls Matrix, Version 3.0
CSA Cloud Controls Matrix, Version 3.0.1
CSE ITSB-105, Security Considerations for the Contracting of Public Cloud Computing Services, Dec. 2014
DoD Cloud Computer Security Requirements Guide, Version 1, Release 1
DoD Cloud Computer Security Requirements Guide, Draft, Version 1, Release 2
FedRAMP, Rev. 4
ISACA – Cloud Risk: 10 Principles and a Framework for Assessment, 2012
ISO/IEC 27001:2022
ISO/IEC 27002:2013
ISO/IEC 27002:2022
ISO/IEC FDIS 27017:2015 (IHS)
ISO/IEC 27018:2014
NIST SP 800-53, Rev. 3
NIST SP 800-53, Rev. 4
NIST SP 800-145, Sep. 2011
PCI SSC Information Supplement: Third-Party Security Assurance, Aug. 2014
Thinking About Clouds? Privacy, security and compliance considerations for Ontario public sector institutions, Office of the Information and Privacy Commissioner of Ontario, Feb. 2016

8.3. Case-specific assessments and controls

Cloud Service deployments that require case-specific assessment must adopt additional security controls that exceed those specified within most audit and reporting frameworks (or their prescribed/applicable levels) described in section 2.6 of this document, and both customer (section 2.4) and CSP (section 2.5) requirements. These requirements have been derived from NIST SP 800-53 and FedRAMP High Baseline controls, and apply to programs and services with special sensitivity/criticality considerations (per section 2.2) that have not been precluded, by means of case-specific assessment, from cloud deployment/adoption. While these requirements are derived from and should be understood to be CSP controls, depending on the Cloud Service Model, architectural/design specifics, and agreements, some requirements may apply to the CSP, customer, or both.

Subsequent to support from a case-specific assessment, the following controls should be implemented for programs and services operating at the Medium Sensitivity and High Criticality level that require cloud adoption. For all programs and services operating at the High Sensitivity level, these controls must be implemented within the deployed Cloud Services, as understood within the terminology and scope of this document.

8.3.1. Increased frequency of review

8.3.1.1. Service-specific policies reviewed annually

8.3.1.2. Service-specific procedures reviewed annually, or upon major change

8.3.1.3. Service-specific agreements reviewed annually

8.3.1.4. System logs, access records reviewed continuously, audit reports reviewed at least weekly

8.3.1.5. System and service changes:

  1. subject to change control that includes security input
  2. reviewed annually
  3. reviewed upon all major changes
  4. review records for potential unauthorized changes with security impact monthly, responding to any findings

8.3.1.6. System and service baseline configurations and state:

  1. review baseline configurations annually
  2. review baseline configurations upon all major changes
  3. review baseline configurations as otherwise necessary/required
  4. review security assessment reports annually

8.3.1.7. Access authorizations/agreements, physical and logical:

  1. review every six months (for privileged accounts, monthly)
  2. update as required (correlate per 8.3.2.1, 8.3.4)

8.3.1.8. Facility visitor and access records retained at least one year, reviewed every three months

8.3.1.9. Staff position risk assessments/designations:

  1. established, and reviewed annually
  2. updated as required
  3. informed by both internal and external sources
  4. used to inform/revise insider threat strategy/practices annually

8.3.2. Increased visibility, scope, integrity of audit

8.3.2.1. Increased scope of collection to include:

  1. all program/service systems
  2. all cloud environment components and infrastructure
  3. physical access/facilities
  4. identified staff positions and/or individuals associated with an elevated level of risk

8.3.2.2. Secure central collection, analysis, and views, with cryptography used to protect both confidentiality and integrity of audit logs, and enhanced timestamp accuracy (minimum of hourly synchronization, one second granularity)

8.3.2.3. Agreements support audit log collection from partners/vendors

8.3.2.4. Formal structure and requirements for audit log content (e.g., GO-ITS 25.0 logging requirements, per section 3.4 of that document)

8.3.2.5. Transfer of audit logs to central management:

  1. maximum delay of weekly for systems/components
  2. consider real-time transfer upon indication of an elevated level of risk
  3. documented agreement between customer and CSP for co-ordination of audit log handling

8.3.2.6. Audit failure triggers elevated responses:

  1. includes system halt for sensitive systems and/or transactional components
  2. other components to fail in known/safe states upon audit failure, without overwriting previous entries

8.3.2.7. Security assessment plan with annual review of controls and audited events (or upon major change) with regular, frequent review of security and audit exemptions/exceptions

8.3.2.8. Audit log retention recommended for two years, one year at minimum

8.3.3. Increased automation, dynamics, and simulation

8.3.3.1. Automation of audit event collection and integration

8.3.3.2. Automation of I&IT asset management and accounting

8.3.3.3. Automation to be used within incident response training methods/simulations, where possible, according to training schedule

8.3.3.4. Simulation of incidents and contingency situations to enhance testing and planning efforts, where possible, at least every six months

8.3.3.5. Automated tracking and analysis of incidents

8.3.3.6. Automated tracking of maintenance operations, records, etc.

8.3.3.7. Automated tracking and analysis of facility visitor and access records

8.3.3.8. Automated notice of staff termination or role transfer/change within 24 hours

8.3.3.9. Dynamic configuration/response during attack/incidents where possible from:

  1. all program/service systems
  2. all cloud environment components and infrastructure

8.3.3.10. Automated alarm/responses/alerting upon integrity compromise (including failures re: cryptography, certificates, transactions, critical file integrity, integrity of backups, etc.)

8.3.4. Increased event and incident correlation/analysis

8.3.4.1. Correlate results of vulnerability scans, ST&E output, and risk assessment efforts to create holistic view regarding vulnerabilities

8.3.4.2. Correlate audit and event logs with vulnerability scans, ST&E output, threat intelligence, and IoCs to create holistic view regarding threats

8.3.4.3. Correlate incidents and response organization-wide for a more complete situational view

8.3.4.4. Correlate digital/logical and physical security logs, event, reports for a more complete infrastructure/facilities view

8.3.4.5 Correlate relevant incident information, where possible and according to agreements, from:

  1. external sources
  2. partners/vendors

8.3.4.6. Perform trend analytics for logs, events, incidents, etc.

8.3.4.7. Increase/enhance analytics re: anomaly detection, where possible, or upon indication of an elevated level of risk

8.3.5. Decreased time to act/respond

8.3.5.1. Audit and event logs are sent to and reviewed by staff with the authority to act immediately upon incident detection, without escalation

8.3.5.2. Account removal duration for staff due to incidents, termination, risk, etc. is decreased to 8 hours (otherwise 24 hours for typical staff transfers, 35 days for inactive staff accounts, and for emergency use accounts, 24 hours from last use)

8.3.5.3. Minimize response time regarding unauthorized/unapproved changes, if detected

8.3.5.4. Service restoration/resumption to occur within SLA timeframe, even for incidents

8.3.5.5. Central patch management and flaw remediation timelines decreased, where possible

8.3.5.6. Results of relevant vulnerability scans, ST&E findings, risk assessments, etc. to be shared between customer and CSP, where possible and appropriate

8.3.5.7. Alerts, advisories, etc. to staff issued promptly and regularly

8.3.6. Augment existing control strength/rigour

8.3.6.1. Password length for systems/components increased beyond GO-ITS 25.0 minimum (12 character minimum, with recommendation for 14 characters)

8.3.6.2. Multi-factor authentication with positive initiation and indication of session logout/timeout required for:

  1. access to privileged accounts
  2. execution of privileged commands, using appropriate multi-factor methods/devices
  3. access to bulk High Sensitivity information, or other scenarios as per OPS IAA Policy

8.3.6.3. Strongest platform-supported logical isolation settings/configuration

  1. enabled for system/network controls
  2. test/development environments configured to be separate from production
  3. security functions/layers separated from generic production environments/components
  4. cryptographic protection of management and diagnostic methods/communications/telemetry
  5. system firmware and system state integrity protection
  6. CSP security architecture, reviewed annually, or upon major change

8.3.6.4. Production High Sensitivity information without mitigation not used for test/development instances and/or applications within Cloud Services

8.3.6.5. Unique, non-reused customer credentials/identifiers for unrelated systems/services within the cloud environment, with no internal CSP credential/identifier re-use within two years

8.3.6.6. Least privilege principle:

  1. enforced for all systems/components, where possible, including time-delimited access, logical access controls, limits on number of concurrent management sessions, and authorized need for privileged account/command use
  2. explicitly/stringently designed within systems, architecture, etc.
  3. service and system configuration/functionality review at least monthly in support of this principle

8.3.6.7. CSP staff security clearances conducted by CSP in accordance with OPS minimum requirements

8.3.6.8. Decreased intervals for session timeouts/locking:

  1. 10 minutes maximum for internal management sessions with privileges
  2. 15 minutes maximum for user sessions without privileges
  3. for local/desktop session locking, use of screen blanking or similar methods
  4. for web sessions, expire cached credentials/identifiers in accordance with timeout requirements

8.3.6.9. Increased intervals for security delays, account lockouts:

  1. minimum of three hours
  2. or until an authorized individual manually intervenes

8.3.6.10. Augment CSP wireless LAN security:

  1. review controls, and increase if required/appropriate
  2. review AP power level/site survey results, reduce AP power if required/appropriate
  3. limit access to configuration details/files
  4. disable wireless LAN support/coverage if not required

8.3.6.11. Migrate least privilege software access to “whitelisting” model, where possible, with quarterly review of configuration, or upon major change

8.3.6.12. Alternate site for contingencies, continuity, and recovery, with testing every six months to validate support, performance, failover, etc.

8.3.6.13. Enhanced monitoring of CSP physical facility areas where customer information is located/stored, with systems physically positioned within the facility in a manner that reduces risk/impact, review of physical security logs at least monthly

8.3.6.14. Redundant circuit, POTS/PSTN, etc. facility ingress, with telecom security, interfaces, components/configurations, etc. reviewed for security posture every three months, or upon indication of an elevated level of risk

8.3.7. Augment incident detection/response

8.3.7.1. Detection augmented to a “continuous monitoring” level, with ability to adjust and respond to indications or reports of an elevated level of risk

8.3.7.2. C2 specific, exfiltration-specific, and IoC-based optimizations for:

  1. system monitoring
  2. network detection

8.3.7.3. Insider threat detection/alerting/response and enhanced monitoring of privileged accounts

8.3.7.4. Detection of unauthorized services, software, devices, and changes, and exposures (via a combination of accurate, comprehensive monthly asset discovery/management, continuous unauthorized component detection, ongoing vulnerability management / monthly scans, and annual ST&E / risk assessment)

8.3.7.5. Detection, alarms, alerts, etc. tied to meaningful, immediate response from qualified staff, including ability to promptly disable remote access during incidents

8.3.7.6. Cryptographic protection of all related processes and information, integrity/validation checks of firmware, system state protection

8.3.8. Enhanced documentation/training

8.3.8.1. Service-specific documentation:

  1. regularly/frequently updated according to a documented and monitored schedule
  2. policy/procedures communicated/disseminated to the relevant audience

8.3.8.2. Document “high risk” end-user accounts:

  1. based on access, use, and privileges
  2. based on completed staff position risk assessment/designations
  3. informed by both internal and external sources

8.3.8.3. Document content, format, handling of audit logs:

  1. log contents, composition
  2. events in scope

8.3.8.4. CSP documentation includes process, procedures for reporting and handling of audit, events, alerts, etc., and an incident plan, reviewed annually

8.3.8.5. System roles, actions, boundaries documented to assist in defining anomalies

8.3.8.6. Train incident response staff:

  1. practical, relevant training
  2. training in established incident response plan and anomaly detection
  3. training completed within ten days of hiring into incident response role/team (with refresher/expanded training conducted annually)
  4. retain training records

8.3.8.7. Annual training:

  1. anomaly detection/analysis and response (including used of simulation)
  2. system use and boundaries
  3. developer training – both for developer audiences (in terms of application security practices and secure SDLC), and by developers for other audiences (in terms of conveying application/security design and engineering detail)
  4. contingency, backup, recovery, and resumption (for contingency staff, within ten days of hiring into a contingency role, with refresher/expanded training conducted annually)
  5. retain training records

8.3.9. Cryptographic support and review

8.3.9.1. Full documentation of all cryptographic specifications, functionality, and operations requirements/procedures, indicating GO-ITS 25.x compliant algorithms, operating modes, key lengths, etc.

8.3.9.2. Independent review of all cryptographic documentation

8.3.9.3. Independent review of key management capability/procedures

8.3.9.4. Independent validation of

  1. cryptographic implementation
  2. supporting hardware, modules

8.3.9.5. Requirement for cryptographic “sanitization” controls/processes to comprehensively/authoritatively delete sensitive information (or substitutes that rely on proven overwriting methodologies)

8.3.9.6. Requirement for cryptographic storage and backup support, with ongoing management, to protect sensitive information when off-premises

8.3.9.7. Non-repudiation support for key/critical transactions, transfers, etc.

8.3.9.8. No go-live/authority to operate without outstanding concerns/considerations regarding encryption features, processes/procedures, supply chain security, etc. addressed, and change control that includes security input for all cryptographic changes

Glossary

The following terms and/or acronyms are used in this document:

Access:
The ability to enter an area or use a resource, which may include viewing, adding, modifying or deleting data, and/or executing applications.
Access controls:
Procedures/devices designed to restrict entry to a physical area (physical access controls) or to limit use of a computer/communications system or stored data (logical access controls).
AICPA:
American Institute of Chartered Professional Accountants
API:
Application Programming Interface
Attestation:
A representation of reasonable assurance made regarding the presence and correct operation of security controls within a service (e.g., such as those within a Cloud Service and/or Cloud Service Infrastructure), based on an assessment of evidence, and in some cases, testing of controls.
Authentication:
A process of testing assertions to establish a level of confidence (assurance) in their reliability as an indication of identity.
Availability:
The degree of readiness expected of information systems and IT resources to deliver an appropriate and timely level of service, regardless of circumstances.
Business Owner:
Any program director or equivalent having authority and accountability under legislation, regulation or policy or other instrument for particular business activities, and the business records relating to those activities.
C2:
Command and Control
Certificate:
The public key of an entity, together with other information, made authentic when digitally signed with the private key of the CA that issued it. Certificate formats are described within the X.509 and RFC 2459 specifications.
Cloud:
“… a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” – NIST SP 800-145
Cloud Access Security Broker:
An organization that acts as an intermediary for Cloud Services adoption, integration, and orchestration, providing for additional security features, policy enforcement, authentication/identity services, and/or related functionality.
Cloud Deployment Model:
The deployment style and physical location of Cloud Service Infrastructure associated with the Cloud Service, typically associated with public access to the Cloud Service, multi-tenant vs. dedicated services, and where the Cloud Service Infrastructure resides relative to the customer.
Cloud Environment:
General infrastructure, networks, service planes, etc. that support the Cloud Service (see: Cloud Service Infrastructure).
Cloud Service:
A specific service offering and computing, networking, application, or storage function intended to be adopted and consumed by the customer.
Cloud Service Broker:
An organization that acts as an intermediary for Cloud Services adoption, integration, and orchestration, sometimes between disparate services.
Cloud Service Infrastructure:
The systems, networks, and management functions that provide the basis to operate and offer the Cloud Service, owned and managed by the Cloud Service Provider.
Cloud Service Provider:
The party, possibly a third party and/or vendor, operating, maintaining and providing a Cloud Service to a customer.
Cloud Service Model:
The service offering style of Cloud Services made available to customers, typically associated with which computing, networking, application, or storage functions are owned and managed by the Cloud Service Provider, and the layer which customers consume and/or operate their portion of the services.
Compromise:
To expose, jeopardize or otherwise make I&IT assets vulnerable to negative impact or danger.
Confidentiality:
Ensuring that information is accessible only to those authorized to have access. Unauthorized disclosure of the information constitutes a loss of confidentiality. The protection of confidentiality must be consistent with the sensitivity of information and legislative requirements (e.g., FIPPA, PHIPA).
Cryptography:
The discipline which embodies principles, means and methods for the transformation of data in order to hide its information content, detect unauthorized modification, or prevent its unauthorized use. Cryptography is commonly used to provide confidentiality, integrity, message authentication, identity authentication and digital signatures.
CCM:
Cloud Controls Matrix
CSA:
Cloud Security Alliance
CSE:
Communications Security Establishment (Canada’s national cryptologic and information assurance agency)
Customer:
For the purposes of this document, the consumer of a Cloud Service.
Data:
Any recorded information stored on computerized devices or digital storage media. In all cases, the word “data” also means “information”.
FedRAMP:
US Cloud Adoption Program, including security control baselines and a vendor qualification/certification process that requires evidence of controls (vs. attestation).
FISMA:
US Federal Information Security Management Act
IaaS:
Infrastructure as a Service
IEC:
International Electro-technical Commission
Information:
Recorded information in any form, in any medium, and at all stages of its life cycle including information created, recorded, transmitted or stored in digital form or in other intangible forms by electronic, magnetic, optical or any other means, but does not include a mechanism or system for creating, sending, receiving, storing or otherwise processing information.
Integrity:
The property that information has not been modified or deleted in an unauthorized and undetected manner.
IoC:
Indicator of Compromise
ISO:
International Organization for Standardization
ISC:
Information Sensitivity Classification
NIST:
US National Institute for Standards and Technology
PaaS:
Platform as a Service
Password:
A string of characters (letters, numbers and other symbols) that are used to authenticate an identity or to verify access authorization.
Personal Information:
Recorded information about an identifiable individual.
POTS:
Plain Old Telephone Service
Privacy:
The ability of an individual or group to control personal information and prevent it from being used by people or for purposes other than those they consented to when they provided the information. Organizations must have controls to restrict the collection, use and/or disclosure of personal information to that authorized by the individual or group. In the case of Government organizations, legislative authority is required to collect, use, and disclose the personal information needed for the delivery of a specific program or service.
Privacy breach:
A security incident that results in a breach of confidentiality, with the result that personal information is disclosed to unauthorized individuals, or made public.
Privacy Impact Assessment (PIA):
A process that assists program managers in fulfilling their responsibilities to protect privacy and for privacy risk management; PIAs are used to:
  • Identify and analyze privacy-related risks;
  • Avoid, eliminate or minimize negative impacts on privacy;
  • Make informed policy, business, procurement, architecture and security decisions; and
  • Comply with relevant privacy legislation, and meet privacy-related corporate governance requirements.
PSTN:
Public Switched Telephone Network
Public record:
A record made or received by a public body in carrying out the public body’s activities (does not include constituency records of a minister of the crown, or published works).
Record:
A record of information in any form, including a record made, recorded, transmitted or stored in digital form or in other intangible form by electronic, magnetic, optical or any other means, but does not include a mechanism or system for making, sending, receiving, storing or otherwise processing information.
Responsibility:
The obligation to perform a given task or tasks associated with a specific role.
Risk:
An estimation of the likelihood and impact of potential events on an organization’s ability to meet its business objectives.
SaaS:
Software as a Service
SDLC:
Software Development Life Cycle
Security event:
An anomalous event with potential relevance to security operations that indicates a possibility of undesirable or unauthorized activity, but is either benign or not yet demonstrated to have resulted in the negative impact or compromise associated with a security incident.
Security incident:
A breach of confidentiality, integrity, or availability that causes a compromise of I&IT assets, including, but not limited to, disclosure or interception of sensitive information, modification or destruction of information, malware propagation, or denial of service.
SSAE:
Statement on Standards for Attestation Engagements
STAR:
(CSA) Security Trust Assurance and Risk (program/registry)
ST&E:
Security Testing & Evaluation
Supporting infrastructure:
The infrastructure used to support a given Cloud Service Deployment Model, but that is not integral to the Cloud Service Infrastructure – typically operated in a subcontract arrangement with another I&IT vendor and/or Cloud Service Provider.
Threat and Risk Assessment (TRA):
A tool to assist program managers in fulfilling their responsibilities for security risk management and the development of security plans. A Threat and Risk Assessment (TRA) is used to:
  • Assess the sensitivity of program assets and information;
  • Identify and analyze potential threats and vulnerabilities;
  • Assess the level of risk taking into consideration the effectiveness of current security measures; and
  • Recommend appropriate measures to protect assets and information from loss, theft, destruction, modification, or misuse.

Document history

DateSummary
2016-04-14IT Executive Leadership Council (Version 1.0)
2019-11-06Architecture Review Board
2019-11-07IT Executive Leadership Council (Version 1.1)
2022-11-23Architecture Review Board endorsement
2023-01-19,
2023-02-16
IT Executive Leadership Council approvals – Approved version set to 1.2