Relaunching the NCSC's Cloud security guidance collection
This week we have launched the updated NCSC’s cloud security guidance. It’s more evolution than revolution, as it collates and refreshes all of the NCSC’s existing cloud guidance (and blogs) into a single collection.
The cloud collection includes a new section on choosing the right cloud provider to suit your security needs. There are two approaches to doing this.
- Applying the 14 Cloud Security Principles. This will help you build confidence in the cloud service, the company that runs it, the way that it’s operated, and whether it gives you an effective set of security features. We recommend this approach when you are hosting ‘sensitive’ data in the cloud (such as personally identifiable, commercially sensitive and government OFFICIAL data).
- Using the Lightweight Approach to Cloud Security, which helps you identify whether a service has the most important security features that will help you defend against common attacks. This approach is suitable for smaller organisations looking to do some due diligence in their online services, as well as larger organisations that are not processing sensitive data.
Many of the cloud services used in government have produced a written response to our 14 cloud principles. These older responses are still useful, although there are some additional goals in the updated principles that are not covered. We’d expect vendors to review their responses at least every couple of years to best reflect how their evolving services address these additional goals. And of course, any new or updated responses from now on should use the latest version of the principles.
The cloud has evolved since the launch of the UK government Cloud First Policy in 2013 (which we supported in the first version of principles). The new collection reflects these changes, whether it’s the language we use, how a service could meet our expectations, or even what we now think of as the cloud.
However, we also know that some of you use our guidance as part of your own standards or contracts. You can be reassured that we haven’t changed the structure or intent behind the 14 cloud security principles. It’s still a goal-based framework to help you determine whether a cloud service meets your security needs, with tweaks and additions through all of the principles.
The NCSC cloud philosophy
The responsibility for the security of any data or services stored in the cloud will always be shared between you and your cloud service provider. It’s a sliding scale that moves back and forth, depending on the features you’re using, how you’re using it, and what you’re trying to achieve. It’s something we now talk about in more depth in our new guide to the cloud shared responsibility model. Wherever that scale lies, there are a few things that are pretty much always true:
- it’s always your responsibility to understand your (security) requirements, and to choose a cloud provider that meets them
- the security of anything that you host in the cloud can be undermined by both the cloud service itself being insecure, and you doing something insecure with the service
It’s useful to pause for a moment on words like ‘joint’ and ‘shared’. It’s too easy to write a list of responsibilities and decide that each thing is either the responsibility of the cloud provider ('is the service secure?') or your responsibility ('am I using it in a secure way?'). We suggest putting a slightly different spin on it by focusing on how the responsibility is shared for all aspects:
We - as the customer - are fully responsible for all of our data in the cloud.
Of course, we expect our cloud providers to do things like patch services, implement secure administration, and keep the service itself up and running. However, it’s up to us - as data owners - to gain enough confidence in the providers so we’re satisfied that they’re actually doing this.
It’s also our responsibility to make sure that the workloads and data we’re hosting in a cloud service have been set up and configured with security in mind. This is hard, so we encourage you to make this something that - as much as is possible - your provider has to worry about (for example by embracing SaaS and building services using serverless components).
Secure by design and by default
We think that the cloud provider has a responsibility for services to be ‘secure by design and by default’. Providers should also make it easy for you to see how you’ve got things configured, and let you know when you’re not following good security practice. The ‘secure by default’ message is one that you’ll now see throughout the cloud guidance. This includes highlighting where a secure by default approach can be used to differentiate between a ‘good-enough service’, and a ‘better service’. It's also explicitly highlighted in the updated cloud security principle 14, and is something I’ll talk more about in my next blog.
Where did the SaaS guidance go?
We have brought the content from previous ‘SaaS guidance’ into the main cloud collection and it’s now called the lightweight approach to cloud security. To find out if this is the right approach for you, you’ll need to read our guide to choosing a cloud provider. As part of this change, we have removed the dozen worked examples (which were being treated as ‘approved products’, rather than the original intent of simply being worked examples).
What else is new?
The collection now talks more about the security implications of different service models including hybrid cloud, multi-cloud, and how the use of a Managed Service Provider affects the cloud shared responsibility model.
We’ve said for some time that it’s important that the mechanisms that separate your cloud services from those of others is ‘good enough’. So we now also explain the different types of separation mechanism, and identify what types of separation you should expect to see in different types of cloud services.
While individuals can use the cloud security principles to assess a cloud provider based on information on their website, what’s preferable is when a vendor explains to their customers how they (and their services) meet the goals of those principles. To help with this, we have written a guide to help vendors write a response to the principles. This includes how you (as the customer) should then use those responses. We suggest asking vendors to provide a response whenever you put a commercial tender out, so you can use the assessment as part of the service selection.
You’ll also notice that we have removed some previously published content. We felt that the IaaS security principles weren’t meeting the needs of people looking to ‘lift and shift’ into the cloud, and we’re looking to replace that with something more targeted shortly. We have also removed content about gaining assurance and handling risk, as that is now covered more thoroughly in our technology assurance and risk management collections respectively.
What’s next?
Over the next few weeks, we will be talking more about updates to the guidance to explain the thinking behind it. The new guidance talks about the ‘philosophy’ of cloud security, and how to pick a good-enough provider, but we haven’t said much about how to use those services well. The next major release of our cloud guidance (due in a few months) will cover some of the more common use cases that we hear about (including ‘lift and shift’, SaaS, and configuring your underlying cloud platform).
If you've any feedback on the updates, we'd love to hear from you as it will help us to further improve the guidance. If you're in government and have a friendly NCSC contact, please reach out to them. Otherwise, our Enquiries team would be pleased to pass your comments on to us.
Andrew A
Cloud Security Research Lead, NCSC
Share and print this article
Written by
