Guideline on Cloud Authentication

1.1 Background

Authentication is the process of verifying the identity of a user, process or device, often before allowing access to resources in an information system.^{Footnote 1} In the context of cloud, and as outlined in the Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN), organizations are responsible for ensuring that individuals and devices are uniquely identified and authenticated before being granted access to information and information systems hosted in a cloud service provider (CSP) environment. Effective authentication is essential to keeping accounts secure.

1.2 Purpose and Scope

This document provides advice and recommendations on how internal users, namely privileged and non-privileged Government of Canada (GC) users (such as employees and contractors) should be authenticated when accessing GC services hosted in the cloud. This document does not address authentication of external users accessing online GC services hosted in the cloud (or otherwise).

This document replaces the Guidance on Cloud Authentication for the Government of Canada document, dated August 23, 2018. Over time, recommendations made in this document may be updated and/or subsumed by other policy instruments, and this document will be updated accordingly.

1.3 Applicability

This document applies to GC organizations that are adopting cloud services. Specific applicability statements are made where appropriate (for example, where recommendations may differ depending on the organization’s service delivery model).

1.4 Audience

This guide is for Information Technology (IT) practitioners and IT security practitioners who are acting in any of the following roles:

• project manager
• business analyst
• requirements analyst
• enterprise, security and solution architect
• system and software designer
• security design specialist
• system and system security engineer
• system, software, and security integrators and testers
• security assessors

1.5 Requirements

The following are authentication requirements from various Treasury Board policy instruments:

• 1.5.1 Deputy heads are responsible for identifying security and identity management requirements for all departmental programs and services, considering potential impacts on internal and external stakeholders (section 4.1.4).
  Reference: Policy on Government Security [1]

• 1.5.2 Implement measures to ensure that individuals and devices are uniquely identified and authenticated to an appropriate level of assurance before being granted access to information in information systems, in accordance with Appendix A: Standard on Identity and Credential Assurance of the Directive on Identity Management (section B.2.3.1)
  Reference: Appendix B: Mandatory Procedures for Information Technology Security Control of Directive on Security Management [2]

• 1.5.3 Program and service delivery managers are responsible for using mandatory enterprise services for identity management, credential management and cyber authentication (section 4.1.9).
  Reference: Directive on Identity Management [3]

• 1.5.4 Organizations must identify and authenticate individuals and devices to an appropriate level of assurance before being granted access to information and services hosted in cloud services. Such authentication is in accordance with the Standard on Identity and Credential Assurance and aligns with GC enterprise identity and authentication services (section 6.2.3).
  Reference: Direction on the Secure Use of Commercial Cloud Services: Security Policy Implementation Notice (SPIN 2017-01) [4]

• 1.5.5 Deputy heads are responsible for using enterprise or shared IT solutions, assets and services to avoid duplication, when available and appropriate (section 4.4.2.3).
  Reference: Policy on Service and Digital [5]

• 1.5.6 Authentication hardening:

  • 1.5.6.1 Authenticate users before they are granted access to a system and its resources, leveraging approved Government of Canada authentication services, in accordance with the Directive on Identity Management and associated guidelines. Exceptions are to be assessed through the GC Enterprise Architecture Review Board.

  • 1.5.6.2 Implement strong authentication mechanisms such as multi-factor authentication (MFA) for all accounts that have privileged or enhanced access, in accordance with Canadian Centre for Cyber Security guidance in ITPS.30.031 v3, User Authentication Guidance for Information Technology Systems. Additional information regarding the GC enterprise approach with respect to MFA is provided in Multi-factor Authentication Considerations and Strategy for GC Enterprise IT Services. At a minimum, MFA is used to authenticate:

    • 1.5.6.2.1 All users accessing information systems with an Assurance Level Requirement of 3 or higher;
    • 1.5.6.2.2 All privileged users performing privileged actions; and
    • 1.5.6.2.3 All users of remote access solutions.

  • 1.5.6.3 Where passwords are used, implement a password policy in accordance with the GC Password Guidance.

  • 1.5.6.4 Systems are configured with a session or screen lock.

  • 1.5.6.5 Systems have an approved log-on banner that requires users to acknowledge and accept their security responsibilities before access is granted.

  Reference: Account Management Configuration Requirements of Appendix G: Standard on Enterprise Information Technology Service Common Configurations [6] of the Directive on Service and Digital [7]

• 1.5.7 Protect user accounts and identities. (Guardrail #1).

  Manage access (Guardrail #2).

  Reference: Version 2.0 of the GC Cloud Guardrails [8] of Appendix G: Standard on Enterprise Information Technology Service Common Configurations [6] of the Directive on Service and Digital [7]

2.1 Enforce multi-factor authentication for all users

To keep credentials secure and prevent unauthorized access to cloud-based services, user access is expected to be protected with strong multi-factor authentication (MFA), in accordance with the Account Management Configuration Requirements [6] and related guidance documents. Wherever and whenever possible, phishing-resistant MFA options should be used.

2.2 Adopt appropriate authentication solutions

The section outlines considerations for authentication solutions depending on the following operating context, including:

• hybrid environments with a combination of on-premises and cloud-based resources
• environments with cloud-only resources

The GC is exploring additional identity modernization approaches and the related models for using a hybrid identity architecture. Guidance will be updated as this work proceeds.

2.3 Ensure adequate protection of cloud administrator accounts

As with on-premises privileged accounts, protecting against unauthorized access to cloud privileged accounts is essential and is subject to the following configurations:

• 2.3.1 Support privileged access to cloud services through appropriate security controls, in accordance with the Communications Security Establishment’s (CSE’s) User Authentication Guidance for Information Technology System (ITSP.30.031v3) [9]
• 2.3.2 restrict access to personnel based on the principles of least privilege, need to know, and segregation of duties
• 2.3.3 protect access to all privileged accounts (whether in the cloud or on-premises) using strong MFA solutions, and phishing-resistant MFA is strongly recommended^{Footnote 5}
• 2.3.4 use different credentials to access privileged accounts in the cloud from those used for administrating on-premises resources
• 2.3.5 to reduce the blast radius of credential attacks between on-premise and cloud environments, ensure that highly privileged cloud administrative users, groups and roles (such as global administrator/root) are not included within scope for synchronization from on-premises environments, and are not used with federated SSO, but instead rely on cloud-native authentication;^{Footnote 6} however, this is not meant to preclude the use of federation for less privileged administrators such as application/SaaS administrators, particularly when the benefits of federation outweigh cloud-native authentication
• 2.3.6 disable cloud based self-service password reset (SSPR) capabilities for cloud administrators
• 2.3.7 where available, configure admins to be “eligible” for a role and request activation for the least privilege role required, only when the role is needed and only for a limited period of time
• 2.3.8 do not allow self-approval of activation requests for highly privileged cloud administrative roles (for example, root, Global admin)^{Footnote 7}
• 2.3.9 where available, enforce attribute-based access control (ABAC) to restrict access based on a combination of authentication factors (such as MFA), managed devices, device compliance, sign-in and user risks, and location
• 2.3.10 audit, review and monitor all privileged access and actions in accordance with the sensitivity of the access
• 2.3.11 implement applicable requirements as specified in Appendix G: Standard on Enterprise Information Technology Service Common Configurations of the Directive on Services and Digital [7]

2.4 Understand the implications of using cloud-based self-service password reset

SSPR method(s) gives users the ability to change or reset their password, with no administrator or help desk involvement. If a user’s account is locked or they forget their password, they can follow prompts to unblock themselves and get back to work.

This ability reduces help desk calls and loss of productivity when a user cannot sign into their device or an application. However, the SSPR must be at least as secure and robust as the method(s) used to obtain the primary authenticator to be recovered.

Based on section 2.3, it is recommended that cloud-based SSPR capabilities be disabled for all cloud administrators. This also applies to all privileged accounts, whether on-premises or in the cloud. Furthermore, cloud-based SSPR is not recommended for resetting on-premises passwords even for non-privileged users, since this exposes the GC to a higher level of risk, which can be avoided through federation.

Alternatives to cloud-based SSPR include one or more of the following:

• 2.4.1 continue to use existing internal password reset methods
• 2.4.2 reset passwords using video conferencing with help desk personnel to demonstrate the user is who they claim to be (for example, using a valid GC-issued picture ID, such as a building pass, over MS Teams or other video chat capability, preferably using a GC-managed device if possible)
• 2.4.3 follow GC Password Guidance [10], which includes recommendations that will make passwords easier to remember and eliminate password expiration (passwords should only be changed when compromise is suspected or known)

For additional information related to Azure AD SSPR, refer to the discussion paper for Considerations for Using Microsoft Azure AD SSPR within the GC (available upon request by contacting the TBS Cyber Security Division).

2.5 Monitor authentication events for security threats

Security monitoring, alerts and machine learning–based reports that identify inconsistent access patterns will help to identify possible security risks. An active identity monitoring system can quickly detect suspicious behaviour and trigger an alert for further investigation. This includes monitoring events such as:

• 2.5.1 anomalous access patterns
• 2.5.2 brute force attacks against a particular account
• 2.5.3 attempts to sign in from multiple locations
• 2.5.4 sign-ins from infected devices
• 2.5.5 suspicious IP addresses
• 2.5.6 use of weak/legacy authentication protocols
• 2.5.7 lateral movement patterns
• 2.5.8 privilege escalation
• 2.5.9 persistence techniques

Without knowing that suspicious activities are taking place through these credentials, it will be hard to mitigate this type of threat. The GC Event Logging Guidance [11] provides additional guidance on events to configure to support security operations and monitoring.

A-1 Federation Services

Federation with any environment depends on trust in the components that perform user authentication and digitally sign the federation protocol (SAML or OpenID Connect) messages. If these components are compromised, they can be exploited to obtain unauthorized access to resources. Therefore, it is critical that all federation components and services are properly configured for secure operation. At a minimum, this includes:

• A-1.1 configure all federation components and services in accordance with available guidance (vendor supplied or otherwise^{Footnote 8})
• A-1.2 continuously monitor for anomalous activity both on-premises and in the cloud
• A-1.3 store private keys used to digitally sign SAML and OpenID Connect assertions/claims in a FIPS 140-2 or FIPS 140-3 Level 2 overall (with Level 3 physical security) or higher validated hardware security module (HSM)^{Footnote 9}
• A-1.4 treat all federation components as critical assets and adhere to secure privilege access best practices

Exploitation of on-premises identity services could lead to unauthorized access of cloud environments. Therefore, it is recommended that highly privileged accounts in the cloud identity service and SaaS public cloud applications be excluded from federation and remain as “cloud-only” accounts to limit lateral movement from a compromised on-premises environment to the cloud, therefore reducing the blast radius.

Based on section 2.2.1 of this document, organizations are encouraged to use existing GC enterprise federation services. However, in exceptional circumstances, an organization may choose to deploy a bespoke federation solution to satisfy specific business or departmental requirements that may not be available with enterprise solutions. In this scenario, organizations should ensure that the authentication solution:

• A-1.5 provides a positive user experience
• A-1.6 adheres to applicable security requirements, including those identified in this section
• A-1.7 adheres to industry best practices
• A-1.8 uses existing capabilities for authentication wherever possible to minimize the proliferation of bespoke solutions
• A-1.9 follows all relevant GC policies and guidance, including the requirements specified in this guidance document

Organizations must contact Treasury Board of Canada Secretariat (TBS) Cyber Security Division before using a bespoke cloud authentication solution.

A-2 Password Synchronization Authentication

Password synchronization authentication, such as Microsoft’s Password Hash Synchronization (PHS) feature supported by Microsoft Azure Active Directory (AD) [12], is another configuration option for authentication.

For organizations that fall under the category of section 2.2.2 of this document, the following outlines additional considerations when using password synchronization authentication, including:

• A-2.1 when syncing passwords, the use of hashing mechanisms and encryption is paramount to preserving the confidentiality and integrity of account credentials, in alignment with the Canadian Centre for Cyber Security’s guidance Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information (ITSP.40.111) [13]
• A-2.2 ensure that MFA is enforced for all users prior to enabling password synchronization
• A-2.3 exclude the synchronization of any accounts that are not required to be used in the cloud, including service accounts used on-premises or IaaS-based servers, or highly sensitive administrative accounts used to administer on-premises or IaaS-based servers (such as domain admins, global admins, root, and any domain admin equivalent access)
• A-2.4 ensure SSPR and password writeback are disabled (see guidance in section 2.4 of this document)
• A-2.5 take steps to synchronize expired on-premises AD accounts with Azure AD. The account Expires attribute of Windows AD accounts is not synchronized to Azure AD. As a result, an expired on-premises AD account configured for password synchronization authentication (PHS) will still be active in Azure AD. If the account expiration feature is used, it is recommended that organizations implement a service desk workflow or an automated process to also disable the user’s Azure AD account (use the Set-AzureADUser cmdlet)
• A-2.6 use the default “never expire” password setting; this is consistent with GC Password Guidance [10] and should not be overridden
• A-2.7 ensure that MD5 is enabled in accordance with applicable Microsoft documentation [14]^{Footnote 10}

In addition, organizations that use AD FS to federate with Microsoft Azure AD may be aware that PHS can be enabled to support certain security features such as credential leakage detection. This guidance does not preclude the use of PHS for this purpose. In other words, it is possible to implement federated authentication via AD FS and enable PHS to support credential leakage detection (but not for user authentication). 

Furthermore, for resiliency purposes, organizations that are operating their own AD FS infrastructure may be contemplating the use of PHS as a backup for their primary authentication method (federation). However, as discussed in section 2.2.1 of this document, the benefit of using federated authentication for hybrid environments is to minimize the risk of exposing on-premises credentials in the cloud during the user authentication process.

Organizations should perform an options analysis and risk assessment that consider the trade-offs between security and availability based on the organization’s business, technical and threat context. If an organization does elect to use PHS as a backup, any users who have logged on directly to Azure AD should be required to reset their passwords once the AD FS infrastructure components have been restored.