NCSC IT: There's confidence and then there's SaaS

My colleague Jamie H has previously explained why we advocate building digital services using serverless components rather than doing so using Infrastructure as a service (IaaS). For similar reasons, we also reckon that a well designed and operated SaaS service will be more secure than one you have to deploy and maintain yourself.

The key point is that they do all of the hard stuff for you – whether that be configuring the full software stack, promptly applying security patches or running tailored protective monitoring.

As we’ve discussed before, the NCSC takes pride in following the Government Cloud First policy. This includes listening to the needs of our users as described in the GDS service manual, and using SaaS where possible.

The tricky bit is figuring out whether a service is secure enough to meet our various needs.

In most cases to date, we’ve followed the NCSC’s due-diligence approach to SaaS, finding ways of getting a bit more confidence in the security of the service, from reports, whitepapers, and terms & conditions published by the vendors.

This has, however, left us with the awkward question of whether that’s good enough for more sensitive data. And I hear from other parts of government that it’s not just us with that dilemma.

Here's an example of a sensitive situation where SaaS provides a genuine benefit.

Our incident responders sometimes use Slack to communicate with the victims of cyber crimes. In many cases, the victim’s email service has been compromised, so an entirely separate web-based chat service with a built-in identity is an ideal way of keeping the comms channels open.

Obviously, the simple fact that an organisation has been compromised is very sensitive. So it’s important to us that we can trust the SaaS platform enough to protect the confidentiality of those involved, as well the conversations themselves. Our Cloud security principles give us a tool for assessing this, but this whole process is much easier to manage when the service in question publishes their own response to all 14 principles. You can read Slack's recent response on their website.

This assessment gives us all the confidence we need to continue using Slack for these sensitive duties. This is great because, in times of stress, people have a reduced capacity for learning new things and remember new ways of working, without making potentially costly errors. Allowing them to use that tool they’re already used to is likely to make things more secure and efficient. This frees up as much brainpower as possible for the really demanding and important work. 

Each of our cloud security principles defines a number of security goals that we think a good cloud service should aim to meet. If they do, then the service should be good enough to defend pretty much all government data classified as OFFICIAL, including the more sensitive stuff.

We’re intentionally not prescriptive about how the goals should be met, so we need to look to cloud service providers to help explain how they think they meet those goals. Individual users could do this analysis themselves, but a much more scalable approach is if the service provider writes, publishes and updates their own response.

That then just leaves it to you, as the customer, to decide whether the response gives you enough confidence that the service meets your goals or not.

Claims may be backed up by independent audit. Some ways of meeting goals are literally better than others, as detailed in some of the individual cloud security principles.

My favourite (yet entirely unscientific measure) is that I’m more likely to trust a precise explanation of how a service meets a goal, instead of a long waffling one that uses lots of buzzwords. A good example of this is the response published by GOV.UK's PaaS a couple of months ago - it's nice and concise, and makes good use of links to evidence already on their website.

I couldn’t talk about us using SaaS without taking the opportunity to remind you how important it is to configure your services well. I’m not going to repeat what we’ve said before, but I’d like to highlight a couple of things we’ve done with our Slack configuration that I think are particularly important:

• We’ve enabled and enforced single sign-on for all of our users, meaning that the identity from our laptops and phones will be carried straight through into Slack with just a few clicks. I can’t remember when I last used a password (I use a PIN or biometric on my devices) as the SaaS services I use are all automagically authenticated for me
• Our internal users can only sign in from a corporately managed device, which means that the device itself can act as a mandatory second factor (enforced by AAD’s conditional access, in case you’re interested)
• Invited guest users are required to register a second factor when they sign in for the first time. And yes, we allow people from other organisations in as guests – it’s more secure and audited than the shadow IT we’d otherwise have to use to collaborate with them.
• We use the cross-organisation collaboration features that are natively built into the platform (such as shared channels), rather than trying to turn off the things that don’t look like our traditional ways of working.

The NCSC is going to continue down the path of embracing managed SaaS services, as part of an ongoing quest to minimise our IaaS footprint.

For services that need to hold more sensitive data, it’s going to be easier for us to make a decision whether a service meets our needs if they’ve published clear and transparent responses to the Cloud Security Principles.

Andrew A
NCSC Cloud Security Lead