Cloud security guidance

The level of confidence you need in the security of a service is directly correlated with the impact to your organisation if your data were to be leaked or corrupted by the service, and the impact of the service being unavailable. The diagram below illustrates this idea.

Impact determination

• The content authoring platform for your website will have a lower confidentiality requirement because the plan is to make most of that content public anyway.
• Your corporate file store may include commercially sensitive data that your business requires access to at all times, resulting in a higher confidentiality requirement.

You will want a lot of confidence in a service if it is being used to store or process sensitive data that is attractive to an attacker, and particularly damaging if it’s stolen or leaked. This will include Special Category Data as defined in Section 10 of the Data Protection Act 2018, and Article 9 of the GDPR.

A service that robustly meets the goals laid out in the cloud security principles (and can provide evidence of this) will usually allow you to meet all these needs, providing that it is appropriate to put that data on an internet-connected service in the first place.

In assessing the suitability of a given service, you will need to consider how confident you can be in the security claims being made by a cloud provider. This includes:

• an appropriate level of assurance that the described processes and mitigations have been implemented correctly
• how well the cloud provider understands the security properties of the technologies that their service relies on
• whether the cloud provider has the expertise, resourcing and operational procedures in place so that they can securely maintain and operate the service

At the low end of the confidence scale, you are after a straightforward promise from the supplier, with no attempt at verification.

At the high end, the service might use independently assured components in a configuration approved by a qualified professional (and independently tested for good measure).

Cloud providers that have written a response to our cloud security principles will usually compile a set of assertions describing how they meet the security goals. You should look out for where the response links out to evidence for those principles and their associated security goals. There will also be some claims where you need more confidence in the assertions being made.

Sometimes, a cloud service may be built on top of another cloud platform or hosting provider. If this is the case, you will need to confirm with your contracted service that the underlying platform has security features that meet your needs. This will usually rely on evidence given by the underlying cloud provider. You will also need to be confident that the cloud service configures and uses the underlying cloud platform in a way that meets the security goals outlined in the principles.

Assertions from the cloud provider

All assessments of cloud providers will involve understanding how the service meets your security objectives. Sometimes, this information will be provided in one place as a response to our cloud security principles. When this isn’t the case, other useful resources include:

• security white papers and blogs published by the cloud provider
• privacy statements made by the cloud provider that explain what they will do with customer data, and how they will protect it
• minimum expectations defined in terms and conditions
• self-assessed claims made against frameworks such as CSA STAR Level 1

Cloud providers may only be willing to offer some answers to your questions under non-disclosure agreement (NDA). However, we recommend putting more trust into publications that are available to all on the vendor’s website. The public accountability that comes from such transparency gives you more confidence in the security claims being made. We explore the value of transparency further in this NCSC blog.

If the provider is unwilling or unable to provide evidence of independent validation, you are, in effect, reliant on the honesty, accuracy and completeness of the supplier’s assertions. We suggest conducting open-source research to help you determine:

• the service provider’s level of security maturity
• whether they have a reputable in-house security team
• their approach to proactive testing
• historical evidence of how they have responded to security issues

Contractual commitments

Off-the-shelf services usually come with terms and conditions, or licence agreements that define expectations of the service. These are particularly useful to help you understand what the cloud provider can and cannot do with the data that you host in their service, as well as minimum standards for availability.

A cloud provider may occasionally update the terms and conditions between you and themselves. You should ensure that you are comfortable with the amount of notice that they are required to give when they do so, and that they commit to alerting you when changes are announced.

Some providers may allow you to negotiate contractual terms which you can use to represent your security needs more accurately. If doing so, make sure that your security requirements are specific and measurable, since clauses that are too generic can add cost, have limited value, and may be unenforceable. Try to build a shared risk proposition with suppliers, so that they are invested in doing the right thing, rather than just what it says in the contract.

Independent validation

You can look to an independent third party to confirm that claims or commitments made by a supplier are true. You should not expect a public cloud provider to allow you to conduct bespoke audits, as such an activity would not scale to all their customers. Validation and auditing activities represent the service at a point in time, and so regular re-testing will be required.

Compliance with a recognised and appropriate standard can give you confidence that the service is meeting certain expectations. The most common ones when considering cloud security are SOC 2 and ISO27001:2013. We also suggest some other standards where relevant in the implementation details section of each of the cloud security principles.

It is the evidence presented with such standards and certifications that can give you confidence in the service, not the fact that a service holds a certification. You should examine the provided evidence to determine how well a service meets your security needs.

You should review the scope of the certification to ensure that the way you will be using the cloud service and where you are hosting it is covered. Some, but not all, certifications will use an auditor to verify that security controls and processes are present and effective. Others may only establish that a control exists or a policy on their use exists.

Ensure that the certification, and hence the evidence for that certification, apply to how and where you are hosting your service. For example, some FEDRAMP certifications only apply to services hosted in a dedicated instance used by the US government.

Cloud services are regularly updated, so you should ensure that any compliance certifications that you rely on are recent and refer to fresh evidence. Evidence of recurring audits will help give you confidence that the cloud provider has a security culture, rather than treating compliance as a one-off activity.

Independent testers validating the implementation of controls builds on an audit or compliance activity. Penetration testing, code review and architectural reviews by a known external party can give you more confidence in security controls and procedures, as they are testing the effectiveness of the security controls which your provider is asserting are in place. You should seek evidence that these activities take place as part of a governed process, rather than asking for visibility of the results of individual activities.

Cloud providers may supply evidence that they use independent validation across their entire service as a part of their secure development lifecycle. This is most useful when these activities cover high impact security-relevant components of the service (such as user authentication, secrets management, Identity and Access Management (IAM) enforcement and the hypervisor).

Once you have built confidence in your cloud provider, you should decide what you trust your cloud provider to do on your behalf.

By choosing to use a cloud service, you are choosing to trust that they as an organisation and service provider are not acting maliciously. You should not try to apply mitigations or security-enabling architectural patterns to defend against a malicious cloud provider. We separately discuss defending against malicious individuals working for a trusted cloud provider in Principle 6: personnel security and Principle 12: secure service administration.

Once you have chosen to use a cloud service, you may need to decide which features or parts of the service you will use. While some SaaS products serve a single, well-defined purpose, enterprise productivity suites and cloud platforms can consist of hundreds of individual services.

You should consider how you will decide which services meet your security and compliance requirements. This will need to be balanced with allowing the cloud to meet your meeting business needs, including offering your developers the flexibility to get the latest innovations in the cloud and deploy agile, secure, and cost-saving services. A common balance is to allow all services from a provider, applying constraints such as limited the geographic locations where data can be stored and processed.

Apply the confidence that you have gained in the cloud service consistently. For example, if you decide to trust your cloud provider to perform encryption using cryptographic keys, then you should also let them take responsibility for managing those keys and how they’re used. The underlying dependencies between components, and hence the required trust between services, may be different to your legacy on-premises applications.

NCSC blogs

 

• How the NCSC chose its cloud services
• Managing the risk of cloud-enabled products
• Brightening the outlook for security in the cloud
• Cloudy with a chance of transparency
• There’s confidence and then there’s SaaS