Cloud security guidance

Although it may be tempting to dive straight into configuring your chosen SaaS application, before you start you should make sure you have a good understanding of its purpose. With this understanding, you will be better placed to make informed and sensible decisions.

Goals

• Understand the features and capabilities of the application.
• Understand your user and security needs for the application.
• Align yourself with the intended design of the application.
• Balance usability and security in your configuration (to avoid shadow IT).

Context

Your first step should be to understand the application and your needs for it. For example, identifying who will be using the application, the sensitivity of the data it may handle, and the regulatory requirements it may need to comply with. Once you understand this, you can identify the current best practices for how the application should be configured and used securely to meet these needs. SaaS providers often publish support resources, such as online help guides, blog posts, and documentation that can help with this.

Some providers offer a trial and testing environment where you can both familiarise yourself with the application and test the configuration options without impacting your production tenancy. If possible, you should take this opportunity to build and maintain a practical and up-to-date understanding of the application.

Your administrators should understand their responsibilities and the impact of the configuration that they choose. A good way to achieve this is to involve users that are familiar with the application in its administration, or by consulting experienced users (sometimes called ‘user champions’ or ‘power users’) in decisions regarding configuration and use of the application.

When deciding on configuration options, you should avoid locking down an application too much ‘for the sake of security’ as this can frustrate users into using shadow IT. However, if there are features that provide no value to your users, we recommended disabling them to reduce the risk of misuse and reduce your attack surface. This includes current features and new features released (as explained in 13. Maintain your security posture over time).

Further reading

• Define user needs - GOV.UK
• Asset Management

You should restrict access to the application to only those users that need access to it. In some cases, only certain teams or users in your organisation may need access, whilst in other cases all users in your organisation or some external users may need access too.

Goals

• Only approved users can access (or be given access to) your tenancy of the application.
• Apply a Joiners, Movers, and Leavers (JML) process for adding and removing your users' access, using your trusted source(s) of identity.
• Apply a JML process for any external users' access to the application.

Context

You should know who needs access to the application based on your user’s needs. This includes the appropriate users inside your organisation and any users outside of it, such as your providers, partners, and customers. Once you know who needs access, you should use access controls to accurately manage their ability to access the application. This includes how you will:

• onboard each of them so that they can access the application
• offboard each of them when they no longer need access to it

You should control access by using a single, well-managed system for user identity where possible. This ‘single source of truth’ makes it easier to manage which users have access to the application in a consistent and authoritative manner. A common method of achieving this is to connect the application to your trusted identity provider(s). For example, connecting your organisation’s digital identity provider so you can integrate with your existing staff JML process.

You should favour managing users' lifecycle using automation as it reduces the effort required and provides consistency. If you have an organisational identity provider, you should use automated tooling (such as tools using SCIM) to apply a JML process. For example, automatically granting a user access when they begin an appropriate role and automatically disabling a user’s access when they leave that role (or leave your organisation entirely). If this can’t be managed with automation tooling, you should periodically review their access to the application and revoke it if it is unnecessary.

You should not make it difficult for your users to request addition and removal of other users as they need. This means they should not face long delays or checks (unless the application is handling exceptionally sensitive data). If users face unnecessary security friction, they are more likely to find another way, such as attempting to circumvent the security you have set up or avoiding it entirely by using shadow IT.

Further guidance

• Introduction to identity and access management
• Cloud Security Guidance: Principle 9 (Secure user management)
• Zero trust architecture: Principle 2 (Know your user, service and device identities)

In contrast to most traditional on-premises applications, SaaS applications are accessed directly from the internet. This means you need to build a high degree of confidence in a user’s identity before allowing them access. You should be appropriately confident that each user accessing the application is truly who they claim to be.

User identities should not be given to service workloads, such as integrations and connections with other services and systems. More advice on this can be found in 10. Manage the use of service identities.

Goals

• Users are uniquely identified in the application.
• User identities contain useful attributes about them (such as their team, department, organisation, and region) that aid applying robust access controls (such as zero trust authorisation policies).
• Modern authentication best practices are applied, including single sign-on (SSO), requiring completion of multi-factor authentication (MFA), and using a modern password policy.
• Prevent bypass of modern user authentication controls (such as MFA) by disabling unused and legacy authentication protocols and interfaces.

Context

Users of the application may include:

• your own staff
• users in other organisations (such as partners and providers)
• and users not attached to any organisation (such as those using online consumer accounts)

You should identify which source(s) you will trust for providing user’s digital identity and authenticating them. Our Zero trust principles contains advice on what you should expect from a modern source of user identity. This includes whether you will take our recommended approach of connecting your corporate identity provider for single sign-on or choosing another method (such as directly using the application’s native user identity management system).

For users outside of your organisation, you should decide whether you will trust identities sourced from external providers or require them to use the native identity management system. For example:

• adding their external identity to your corporate identity provider for unified management
• trusting federated identity claims from their own corporate identity provider
• accepting claims from a third-party consumer login provider

Authentication of users should mitigate the risk posed by common credential-based attacks against user identities, including password spraying and credential stuffing. This means that users should not be allowed to authenticate using only a single factor; you should require completion of modern multi-factor authentication. Your identity provider(s) should also apply a modern password policy, including banning the use of weak passwords. If this is not done by default, you should enable this.

Single sign on (SSO)

You should use SSO for authentication of your users to SaaS applications where possible. Using SSO with a SaaS application allows you to:

• consistently apply current authentication best practices for your user identities in one place
• simplify management of individual user identities and groups of users (such as ‘all staff’ and ‘IT admins’)
• remove security friction as users only need to remember one familiar, secure set of credentials

These benefits of SSO scale with the number of applications configured to use it.

You should favour SSO, using industry-accepted standards such as OpenID Connect and SAML, rather than synchronising the user’s credentials to the application. Federated authentication reduces the exposure of your user’s credentials and simplifies their management. However, it also introduces a large single point of failure. See 11. Plan for incident response & disaster recovery for our advice on reducing the impact of this kind of incident.

When configuring SSO between an identity provider and the application, you should:

• avoid conflicts by using a user attribute that is unique to each user to bind their organisational identity with their identity in the application (such as the user’s staff ID number*)
• as much as possible, avoid complexity and compatibility issues by using user attributes that are native to the identity provider instead of custom attributes
• include membership of groups in the attributes shared from the identity provider to aid robust access controls
• verify the authenticity of the identity issuer to mitigate spoofing attacks
• verify the integrity of the identity sent by the identity provider to mitigate tampering attacks
• encrypt content to protect the confidentiality of sensitive identity information (if it is not already protected by an encrypted bearer such as a TLS connection)

* You should choose an attribute that will remain consistent and unique to each user over time. This includes if a user changes their name and if you choose to change your organisation’s identity provider in the future. For example, a staff ID number will usually stay the same when migrating to a new identity provider, but their user object ID (sometimes called a ‘GUID’ or ‘UUID’) will. By choosing a consistent and unique attribute, the friction caused by future changes should be minimal.

Direct authentication

Direct authentication to the application can be necessary, such as when an application does not support SSO. An application can also require you to directly authenticate when accessing a tier 0 administrative user or break-glass identity so you retain administrative access even if your SSO identity provider is unavailable. For users authenticating directly to the application, you should apply modern secure authentication practices, including MFA and a modern password policy, using the application’s native identity provider.

An application may support legacy user authentication protocols for compatibility. If not already disabled, you should disable authentication through legacy protocols to prevent ways of bypassing modern security controls. For example, disabling POP and IMAP access to online mailboxes and disabling FTP access to online file storage.

Further reading

• Introduction to identity and access management
• Cloud Security Guidance: Principle 10 (Identity and authentication)
• Zero trust architecture: Principle 2 (Know your user, service and device identities)
• Password administration for system owners
• Multi-factor authentication for online services

Administrative users have privileged access to your application, including the ability to change its configuration for all users and access other users' resources. This makes them a popular target for attack. You should manage administrative users and their privilege to mitigate the risk of compromise and the impact of misuse. Administrative users include those in your organisation and third parties, such as managed service providers.

Goals

• Minimise the number of administrative users to reduce the attack opportunities exposed for gaining high-risk access.
• Apply the principle of least privilege to reduce the impact of a compromised administrative identity, such as using mechanisms like role-based access control (RBAC).
• Access control is applied to groups of users, instead of individuals.
• Only use privileged access when necessary, including using separate identities for administrative and day-to-day use.
• Log and monitor privileged access to aid detection and response to a security incident.

Context

The more administrative users that you have in the application, the greater the risk that an attacker can compromise privileged access. You should begin by identifying the users that need privileged access to the application. Once you know who these users are, you should ensure that only they have privileged access (which includes removing administrative access when a user’s role or responsibilities change). You should apply the principle of least privilege to minimise the impact of account compromise or misuse. RBAC is a common mechanism for achieving this and is built-in to most applications.

Group-based access control and automated tooling can help you manage privileged access at scale. This can commonly be achieved by federating membership of groups from your corporate identity provider to the application. For example, using membership of IT and finance team groups to manage who is given privileged roles to manage those aspects of the application. This group-based method also makes managing access over time easier (as explained in 2. Manage user onboarding and offboarding).

For high-risk access to applications storing or processing sensitive data, you should use Privileged Access Management (PAM) to remove administrator's standing privilege in the application. This should mitigate the impact of malicious insider and lone compromised administrator activity.

You should create separate user identities for administrative and day-to-day responsibilities to reduce the risk of compromise to administrative access. These administrative identities should not be used for normal activity (like responding to regular, avoidable email and signing up to other services) to reduce their exposure to attacks like phishing and malicious email attachments. Administrative activity should only be performed on a trusted administrative device, such as a Privileged Access Workstation (PAW). You should not browse-up for administration. More advice on this can be found in 6. Use trusted devices to access the application.

Further reading

• Secure system administration
• Introduction to identity and access management
• Cloud Security Guidance: Principle 9 (Secure user management)
• Zero trust architecture: Principle 2 (User identity)

You should use access control to ensure standard users have the permissions that they need to do their job but no more, ensuring that they cannot perform high-risk access. This includes any non-administrative users in your organisation and any external users, such as collaboration partners and consumers from outside of your organisation. Appropriate access control should protect your sensitive information without obstructing legitimate need for users to collaborate.

Goals

• Users have appropriate default privilege to access (and manage access to) their resources.
• Access control is applied effectively, using a robust mechanism such as role-based access control (RBAC) and zero trust authorisation policies.
• Access control is applied to groups of users, instead of individuals.
• Structure your data in your tenancy to work with the application’s access control system.

Context

Use cases for SaaS applications often have a range of security needs. For example, an application storing internal policy documents (that need to be readable by all users in your organisation) and sensitive contracts (that only a specific group of users should be allowed to access). You should use access control that gives users an appropriate level of access to the data in the application by default. 9. Secure how access to resources is shared provides more advice on securely sharing access to resources.

RBAC is a common method of controlling user’s access and permissions in SaaS applications. Most applications provide built-in roles for common sets of user responsibilities, such as owning, contributing to, and consuming a resource. For example:

• an Owner or Member for a private resource may view and manage all its contents and invite other users access to it
• a Contributor or Guest may view and edit the content that they have been invited to contribute to
• a Reader may only view the content that they have been invited to consume

If possible, you should take this a step further by applying a zero trust approach to access control. Zero trust authorisation policies should be used to apply more robust contextual access control based on more than just who the user is. For example, you may require the use a corporately-managed device connecting from a trusted network to access high sensitivity resources, while allowing your users to consume and/or contribute to low sensitivity resources from their BYOD device (if you support this). Our Zero trust guidance provides more advice on this.

You should design the structure of your repositories and data in the application so that access controls can be managed and applied simply, effectively, and consistently at scale. This design should allow you to apply access control to groups and individuals as appropriate. For example, using separate repositories for resources that are owned by different teams or groups and for resources that have different confidentiality requirements so that different access control policies can be applied.

Further reading

• Cloud Security Guidance: Principle 9 (Secure user management)
• Introduction to identity and access management
• Zero trust architecture: Principle 4 (Use policies to authorise requests)

An insecure user device can be used to compromise access to the service. For example, by stealing credentials, such as tokens and cookies, and resources that are stored or rendered on the device. You should make sure that the devices used to access the application are appropriately secure and trusted. This includes devices used by your users and users outside of your organisation.

Goals

• Follow Device Security Guidance to build and monitor the trustworthiness of your devices.
• Use appropriately trustworthy devices for the sensitivity of data in the application.
• Use trusted administrative devices for high-risk access to the application.
• Try to gain appropriate confidence in the security of devices and software being used by external users.

Context

Follow the Device Security Guidance to securely configure the devices used by your users to access the application. This includes protecting software used to access the application, such as mobile applications and web browsers. By following this guidance, you should be able to apply a zero trust approach by using the trustworthiness of a device as a signal in a contextual authorisation policy.

Only allow your users to access the application from a trusted and healthy device. This should avoid the ‘browse-up’ anti-pattern where a trusted system is accessed from a lesser-trusted system. Using trusted devices protects your data while it is stored on the device and the way that data is accessed, such as user’s credentials and cookies used for authentication. You may be able to do this using an application’s native zero trust security controls, or you may have to use other means. For example, checking the device’s health as part of the SSO authentication flow before granting access to the application. This reduces the risk of an attacker compromising one of your organisation’s devices to gain access to the application, such as using malware to steal a user’s credentials. This configuration should also give you another source of activity logs related to your users' activity that will help during investigation of a security incident.

For an application that processes or stores sensitive data, you should require use of a Privileged Access Workstation (PAW) for high-risk access. This should be technically enforced using a contextual authorisation policy if possible. Using a PAW reduces the risk of an attacker gaining privileged access to the application by compromising a management device.

For the devices that you do not know the security condition of (such as the devices of external users), you should try to verify their security condition using the information that is available to you. This should reduce the risk of insecure devices being used to compromise their access to your application. For example, using access controls to check that they (at least) appear to be using an up-to-date app or web browser to access your data. These device controls build upon the secure sharing practices explained in 9. Secure how access to resources is shared and our blog post on securely collaborating using cloud services.

Further reading

• Device Security Guidance
• Secure system administration
• Zero trust architectures

The data that is put in a SaaS application will be processed and stored on infrastructure that your provider is responsible for managing. You should configure controls to ensure your data is appropriately protected and handled by the application and its provider.

Goals

• The application appropriately encrypts and protects data at-rest and data in-transit.
• Your data is stored and processed in appropriate locations and legal jurisdictions.
• You have visibility and control over the provider’s access to your data, such as requiring your consent prior to their personnel accessing your data.

Context

Your data should be encrypted following best practices for data at-rest and in-transit. This should encrypt your data to protect it across the application stack. For example, using full disk encryption to mitigate the impact of disk theft and using key management that creates a security boundary between you and other customers' data. If you have chosen a good application provider, they should be doing this by default in all appropriate components of their stack. However, if encryption is not enabled by default in some aspect of the application, you should turn it on. Industry-approved protocols with secure settings should be used to protect data in-transit (such as requiring that HTTP and mail-based traffic is sent over a secure TLS connection).

An application may have more than one place for managing data encryption settings. You should identify where any configuration settings for encryption are managed for your tenancy and ensure that these settings protect all confidential data that is received, stored, and transmitted. For example, data sent to users outside of your tenancy should be protected to the same level as data sent inside it, but this may be managed by different settings.

As stated in our guidance on secure key management in the cloud, cryptographic key material should be created and managed by your service provider, unless applicable regulations require otherwise. The key management protecting your data should give you the confidence that:

• another customer or tenant of the application cannot read it (unless you explicitly allow them)
• provider personnel cannot access your data without appropriate authorisation
• your data is irretrievable after you terminate your use of the application

If the application allows you to designate jurisdictions where your data is stored and/or processed, you should ensure that this is configured with the setting that is appropriate for your use case. For example, specifying that your data is stored in UK or European-based regional data centres if required by applicable regulations. You should be aware of how this setting affects the resilience and availability of the application. For example, strictly limiting storage and processing to UK data centres will increase the impact of a localised service disruption.

Ensure the application is configured so that you have visibility of when and how the provider’s personnel perform activity related to your tenancy and your data. For example, when the provider’s support personnel require access to your user data to diagnose an issue. This should mitigate the risk of abuse of their access. For particularly sensitive use cases, you should require administrative approval before the provider’s personnel is allowed to access your data to further mitigate this risk. Note this may impact the level of service you receive when vendor support is required.

Further reading

• Cloud Security Guidance: Principle 1 (Data in transit)
• Cloud Security Guidance: Principle 2 (Asset protection and resilience)
• Secure key management in the cloud
• Cloud Security Guidance: Principle 5 (Operational security)
• Cloud Security Guidance: Principle 6 (Personnel security)

SaaS applications can be used by attackers to try and deliver malicious content to users. You should ensure that the application checks content received and stored is not known to be malicious.

Goals

• Configuration mitigates the risk of an attacker delivering malicious content to your users using the application.
• Tooling checks content in your tenancy to mitigate the risk of an attacker using it to host and serve malicious content.

Context

A good provider should already be identifying abuse of their service, such as detecting tenancies hosting and/or serving malicious content. If an application does not do so by default, you should ensure that your tenancy has security controls that check for malicious content, including when it is received and accessed in your tenancy.

These security controls should be configured to mitigate attempts to attack your users by detecting known- or suspected-malicious content. This includes attacks by other users outside of your tenancy and lateral movement from compromised users within your own tenancy. For example, an application should check for malware in uploaded files and check URLs in messages for threats, such as identifying suspected phishing attempts. These controls should also protect your reputation by reducing the risk that your tenancy is used to host and serve malicious content if it is temporarily compromised by an attacker.

The detection and remediation of malicious content should be part of your security monitoring and incident response processes. More advice on this can be found in 11. Plan for incident response & disaster recovery and 12. Monitor for security incidents.

Further reading

• Cloud Security Guidance: Principle 5 (Operational security)
• Cloud Security Guidance: Principle 14 (Secure use of the service)
• Mitigating malware and ransomware attacks

Misconfiguration when sharing access can lead to unintended disclosure of your data. You should manage how access to resources is shared and managed so that users can share what they need to share, with who they need to share with, in a secure and effective manner. This should enable your users to choose to collaborate with small and large groups of users from inside and outside of your organisation as appropriate.

If you prevent users of an application from sharing when they need to share, they will use shadow IT instead.

Goals

• Resources are confidential by default to reduce the risk of unintended disclosure.
• Users can choose to share access as necessary using a "default-allow, explicit-deny" approach.
• Each resource’s sensitivity is clearly evident so that users and tooling can appropriately manage sharing of access.
• Recipients are robustly authenticated before accessing confidential resources.
• Permissions management is applied to shared access, such as preventing a recipient from sharing access further.
• Owner(s) of a resource retain control of access to it, including the ability to revoke or modify a recipient’s access.
• Your users understand how to securely share and manage access, including using guides and training to stay up-to-date with best practices.
• You have appropriate visibility and control of shared access to effectively respond to unintended disclosure of information.

Context

You should make it easy for users to share access to resources securely when they need to. You can do this by helping users to understand the impact of their sharing and using security controls to mitigate the risk of accidental oversharing. For exceptionally sensitive data, this may include preventing sharing.

You should configure the application so that resources are not shared with anyone else by default, unless a trusted user has explicitly allowed it. This could be:

• a file in a storage service should only be visible and accessible to its owner(s) unless they choose to share access further
• a personnel record in a HR management service should only be accessible to users in their management chain unless they have chosen to share access further
• messages in an instant messaging service should only be accessible to the users invited by the conversation’s owner(s)
• a call in a video conferencing service can only be attended by users invited by the call’s creator or delegate
• a post in an intranet service is only published to a group or organisation unless the publisher intentionally shares it wider

Shared access should clearly identify each recipient. In SaaS applications, this is commonly a username in the form of an email address as these are usually associated with only one user and they are easy for users to understand and remember. If you wish to share access with a trusted group of users, such as external partners and suppliers, you can often use their trusted domain. For example, “Share with all invited users from ncsc.gov.uk”.

You can reduce the risk of accidental oversharing by using a consistent, user-friendly indicator of a resource’s sensitivity. This indicator should advise users of whether a resource is suitable for sharing, and with who it is or is not appropriate to be shared with. For example, using a labelling or naming convention policy to clearly differentiate a resource that:

• can only be shared with users inside your organisation on a need-to-know basis
• can be shared with any user inside your organisation but not outside of it
• can be shared with users from a partner organisation or community outside of your organisation

Automated tooling should be used to help users securely and responsibly share access. This includes using tooling to inform users of the impact when they are about to share something and ask them to confirm their intent when they are sharing access to a sensitive resource. Tooling should also prevent inappropriate and unwanted sharing based on a resource’s indicated sensitivity. For example, preventing “Internal” files from being shared with recipients outside of your organisation. This should mitigate the risk of users mistakenly oversharing and leaking data.

Tooling should help users manage what they have previously shared to make it easier for them to revoke access that is no longer needed. For example, periodically prompting a user to review access that they have shared and automatically notifying an owner when a recipient’s access hasn’t been used for a while.

Effective user training should complement this tooling to reduce the risk of mistakes being made when sharing access. This training should make sure that your users understand how to securely share access and how they should manage it afterwards with available tooling.

In the event that oversharing does occur, you should already have effective security monitoring and incident response processes in place to detect and respond to it. For example, an administrator should be able to revoke a recipient's access. More advice on this is can be found in 11. Plan for incident response & disaster recovery and 12. Monitor for security incidents.

Further reading

• Introduction to identity and access management
• Engagement and training
• Shadow IT

In addition to users, SaaS applications can also include machine automations and integrations with third-party services. These automations and integrations will also require identities and access in your tenancy. You should manage the use of these service identities to reduce the attack surface created by their use and mitigate the risk posed by an attacker abusing their privilege.

Goals

• You have visibility and control of the service identities being used in your tenancy.
• Service identities with high-risk access require administrative approval to mitigate the risk of abuse.
• Privileges and scope of each service’s access are regularly reviewed to ensure they are still appropriate and proportionate.
• Remove automations and integrations when they are no longer necessary.
• Activity related to these services is included in your auditing and security monitoring process (including actions it has performed and the users that have used it).

Context

You should be confident in how you can see, manage, and investigate service identities. You should familiarise yourself with the interface(s) where you can see these service identities, including any automations, integrations, extensions, or add-ins. These interfaces should provide you with sufficient information for you to effectively manage their use, including permissions that they have in your tenancy, who requested and authorised their use, and when they were last used.

You should manage how new service identities are authorised, including how your users can add or request approval of their use in your tenancy. This approach to service approval should be appropriate for the level of risk created by the service’s access. This risk should be based on the sensitivity of the endpoints and data that it is given access to, including the aggregation of access. For example:

• backup and eDiscovery service integrations that can read all users' data (including sensitive content) are high risk and should therefore require administrative approval before they can be used
• a messaging automation service that can impersonate a user to read and/or send messages on their behalf is high risk, and should therefore require administrative approval before users can opt-in to using it
• a user status integration that can only read the free/busy calendar availability of a user if they have explicitly opted-in to using it, is relatively low risk and should therefore not require administrative approval

This approach should reduce the risk of an attacker using a malicious service to escalate their access and compromise sensitive information, without creating unnecessary administrative overhead. You can make this approach more manageable at scale by creating an allow-list of approved services that users can opt-in to without needing additional approval. For example, pre-approving integrations with other services that your organisation has already chosen to trust and use.

For each service identity, you should review its permissions to ensure that the principle of least privilege is applied. This includes only granting the permissions necessary for it to perform the actions that you need it to. For example; granting a video conferencing integration permission to read a user’s calendar for easier scheduling, but not granting access to their mailbox and personal cloud storage drives (if your users do not use that functionality).

You should regularly check if service identities are still needed. If a service is no longer needed, you should remove its access. If an application is still being used, then you should review its permissions to ensure the principle of least privilege is still being applied.

The activity of service identities should be covered by your auditing and security monitoring process to help detect malicious use of its privilege. This is commonly achieved by collecting the activity logs associated with the services being used. 12. Monitor for security incidents contains more advice on this.

Further reading

• Identity and access management

Planning and preparing your response to a security incident ahead of time is essential to effectively handling it and mitigating its impact. You should have well-defined and tested incident response processes ready for events that could affect your use of the application. These processes should address incidents that only affect your tenancy of the application (such as a breach of a user account) and those affecting the wider service (such as a temporary outage of the application or feature).

Goals

• You know how security notifications are delivered to you by the application.
• You know how you can notify the provider of an incident affecting your use of the application.
• Contact details are valid and accurate so the provider can contact you regarding an incident.
• Your response processes cover incidents affecting your use of the application.
• Critical data is securely backed up.
• You have robust access recovery procedures set up so that you can regain access in the event of a disaster.

See our cyber incident management guidance for more advice on planning for incident response and see our data backups guidance for more advice on preventing permanent data loss.

Context

You should follow our cyber incident management guidance to create response plans and playbooks for reasonably likely categories and severities of incident affecting your use of the application. These plans should be regularly checked to ensure that they still work as expected. This includes incidents directly affecting your use of the application and any onward impact of an incident. For example, compromise of a human resource management or identity provider service that operates as your trusted source of digital identity (or an enterprise password manager that stores access credentials) will have an impact on secure access to other systems.

You should verify that your critical data in the application is stored in at least one resilient backup to ensure you can recover if a data loss incident affects your tenancy, such as an outage (temporary or permanent) and destructive attack like ransomware. If you choose to back up this data to a third-party service, you need to appropriately protect the data in that service as well. This includes ensuring that an incident impacting your data in the application cannot also affect all backups; they should have separate ‘blast radiuses’. For example, using separate identity sources for users accessing the application and the service storing the backup.

In addition to having your data in a resilient backup, some applications provide native capabilities that can create additional protected copies of your data in the application, such as:

• mandatory soft deletion allowing you to recover recently deleted resources and data
• retention policies preserving data for a minimum period before allowing permanent deletion
• minimum version history functionality allowing you to revert unintended or unauthorised modification of data

Note these kinds of controls can usually be over-ridden or bypassed by administrative identities. You should read the sections on protecting administration of the application, robustly authenticating users, and managing the user of service identities to secure the identities with access to attack these copies of your data.

If the application supports configuration-as-code, you should use this to aid in disaster recovery processes. Using configuration-as-code should allow you to automatically rebuild your tenancy after an incident. Your data backup can then be used to restore content into the tenancy to get back up and running.

You should have access recovery procedures - also known as ‘emergency access’ or ‘break glass access'. These procedures should mean you are able to regain access to the application if you lose it during an incident. This emergency access may need to be excluded from normal security controls, such as requirements for MFA and trusted devices, to avoid external dependencies. For example, creating dedicated user accounts that can directly authenticate with the application instead of relying on your corporate single sign-on provider and device management service (as these may be caught up in the incident causing the emergency).

As break glass processes should only be used during an emergency, your security monitoring should alert on any use, with high-priority notifications sent to a range of monitored locations using a range of methods. For example, sending an email alert to a group mailbox, a high-priority message posted to an instant messaging channel, and a security notification to a status monitoring dashboard.

For cases where you need support from the provider to regain access, you should have a process. This is commonly designated contact details, such as a pre-agreed email address or phone number, for the registered owner of each tenancy. You should make sure that access to these contact details does not depend on other systems that may be unavailable during an incident, like your corporate email and identity provider systems. This means that these details can be trusted by the provider to verify you are the legitimate owner (and not an attacker attempting a takeover) before helping you regain access.

You may also choose to create a method of recovering access to the application for yourself, without contacting the provider. This can be achieved by creating a secured emergency access identity. If you choose this method for emergency access, the identity’s credentials should be highly robust to mitigate the risk of abuse or compromise.

You should also familiarise yourself with how the application reports outages and incidents, such as via a status page or administrative portal.

Further reading

• Mitigating malware and ransomware attacks
• Cloud Security Guidance: Principle 10 (Identity and authentication)
• Zero trust architecture: Principle 4 (Use policies to authorise requests)

A SaaS application should provide you with audit data and alerting that allows you to proactively detect and investigate activity that could represent a security incident. You should have an effective security monitoring regime covering your use of the application so that you can detect incidents and enable the most appropriate response. Effective security monitoring should give you confidence in allowing your users the freedom and flexibility to do what they need to in the application.

Goals

• Native security monitoring and alerting capabilities are enabled.
• Security monitoring detects and alerts on unauthorised and anomalous activity in the application.
• Activity logs for security-related activity are created, retained, and protected so you can respond effectively to an incident.
• You are able to identity and revert unsanctioned actions made to your configuration using available activity logs.

Context

If the application provides native detection and alerting tooling, you should make sure that these are turned on in addition to any third-party tooling that you have. Native security monitoring tooling can often have another level of visibility based on the vendor’s own view of all customers using their service (that third-party tooling does not have). You should make sure that these alerts are monitored by people that know how to respond to them appropriately. These alerts should be visible and actionable by the right users and systems (including security administrators and security systems like a SOC).

You should use detection tooling to continuously monitor (or frequently audit) activity logs to increase the chance that you detect unwanted activity. Your security monitoring should allow you to identify incidents and it should produce actionable security alerts for you to investigate. This should include:

• anomalous authentication activity, including sign-in to an emergency access identity and sign-in events from unusual locations and devices and at an unusual time or frequency
• changes to a privileged identity, including administrative users and service integrations being created, altered, and removed
• changes to the application’s configuration, including application-wide and resource-specific settings (such as unusual modification of access controls affecting confidentiality of your data and change of licensing agreement that may impact availability of your data)
• malicious content being received by or hosted in your tenancy
• attempts to access your data by the provider’s personnel

In some cases, the privilege management controls provided by the application cannot perfectly align the principle of least privilege for all your use cases. For example, when the permissions you can assign are broader than you need. Where you must give users more permission than they need, try to monitor for unnecessary use of these permissions.

You should ensure that activity logging is enabled and that activity logs are retained for security-related activity. If the creation of activity logs is not already enabled, you should turn this on. If there are any additional, optional logging capabilities that provide more useful detail for security-related activity, you may also find it valuable to turn these on too. You should check that the activity logs produced by the application contain sufficient information to investigate an activity and rectify an unsanctioned change. For example, log content for a configuration change could include the original configuration of a setting so it can be correctly re-configured.

You should protect activity logs so that attackers cannot tamper with them, as attackers often do this to hide their activity. You should configure the application so that an attacker cannot delete or modify existing logs, and cannot disable the creation of new logs in the future. If you cannot prevent deletion or modification of these logs, you should protect administration and robustly authenticate users to minimise the risk of an attacker getting access to tamper with logs.

You need to decide where logs for the application will be retained, and how long they will be kept for. Many applications will store logs for you for a limited time. If the application does not store activity logs for as long as you would need them (which is often longer than you think) you should export these logs for retention in another secure storage location. For example, saving them to an external storage service or onboarding the application to your Security Operations Centre (SOC) where they can be analysed.

You should be able to gather activity logs from data sources across your IT system to help you build a clearer picture of what has happened in the application and its connected services. For example, combining activity logs from:

• your corporate identity provider so you can see SSO authentication events for the application (and other SSO-enabled services), such as user sign-in
• the application itself to see activity performed in it, such as a file being downloaded
• user devices to see what happens to your data when it is on your devices, such as after a file is downloaded from the application

Within your monitoring for security incidents, you should ensure that your activity logging and detection tooling works as expected by running exercises periodically. As SaaS applications often get updated, your security monitoring tooling should be updated as well to continue operating as effectively.

Further reading

• Cloud Security Guidance: Principle 13 (Audit information and alerting for customers)
• Introduction to logging for security purposes
• Logging and monitoring
• Transaction Monitoring for online services
• Effective steps to cyber exercise creation

SaaS providers update applications over time to deliver new or improved features and functionality. These updates can change or deprecate security features that you may currently rely on, or provide new features that can bypass existing security controls you have in place elsewhere. You should manage this change so that you continue to maintain an appropriate security posture.

Goals

• You are aware of how and where updates and changes to the application are documented so you can stay up to date and prepare for them.
• You understand how changes impact your use of the application, including configuration necessary to keep your intended security posture.
• Communicate changes and their impact so that all your users can continue to use the application securely and effectively.
• Your security monitoring regime continues to cover activity, including new capabilities introduced by updates.
• Periodically review your use of the application to confirm it is still necessary and appropriate to meet your user and security needs.

Context

A good SaaS provider should announce upcoming updates and changes so that you have time to prepare for them. This may be:

• on help pages and dashboards in the application
• by messaging such as email
• on a public blog or training website

You should be familiar with how the provider publishes these announcements so you have advanced notice, giving you time to prepare for the upcoming updates and changes.

You should be clear on who is responsible for managing changes so that they not overlooked. This includes technical and non-technical changes, such as assessing the security impact of updates in your tenancy(s) and reviewing the security impact of changes to licensing and policy agreements. This may span multiple people or teams, such as finance, IT, and legal.

If an application provides a way of trialling technical updates in a safe environment (such as pilots and beta releases) we recommend opting-in. This should allow you to identify and test upcoming changes and avoid having to disable or withhold useful features from your users.

It is important to engage with your users to make sure they understand the impact of changes. Your users should always feel safe and confident enough that they understand how to use the application safely, securely, and effectively. This includes communicating with your users so that these updates and changes do not come as a surprise to them. For example, explaining a change or new expected behaviour in a message or post on your intranet sent to all users affected.

Updates to applications can create, change, and remove features and functionality. As such, it is necessary to regularly check that your security monitoring regime covers new or updated activity made possible by updates and new configuration. This should include capture of activity logs and creating or adjusting alerts.

You should periodically review your use of the application to make sure that the product still meets user needs and is still secure enough. This should be informed by both your users and administrators. This review should assess whether the application’s features and functionality still meet business needs. If you decide that the application is still necessary and appropriate, you should verify whether its current configuration meets your user’s needs and aligns with good practice guides published by the vendor.

If the application is no longer meeting your user’s needs, or a more suitable one has been chosen, you should begin the process to retire your use of this application.

Further reading

• Engagement and training