So far in the series discussing how the NCSC built its IT we’ve talked about our design principles, the resulting architectural principles and some of the practicalities of building our network in the cloud.
I’ve blogged recently to talk about some approaches we’ve taken to getting confidence in cloud services, and why transparency is important. Following on from that I want to give a few examples of how we got enough confidence to use our chosen cloud providers. You’ll notice that a lot of this relied on the cloud providers being open with us about how they run and maintain those services. We haven’t found a good answer to how to engage with less-transparent services, beyond avoiding them.
User needs come first
One of the things you’ll often hear our Chief Architect say is “a highly secure solution that no-one uses isn’t secure at all”. There’s an extra nuance to this too; people will only choose to use a system that helps them get their job done. Therefore we needed to focus on providing the right tools and ways of working.
We’ve learned a lot from how the Government Digital Service goes about collecting user needs – as they describe in their Service Manual – and so chose to take a similar approach. A selection of the things we heard from our users included:
- I want to collaborate on documents with my colleagues so that we can work more efficiently
- I want to be confident that my files are backed up somewhere else in case I break my device
- I want the Internet to work as well as it does on my computer at home
- I want the same services to be available both on my laptop and my phone
- I want to be able to collaborate with an external organisation using the web platform they’re already using
We also have a duty of care to protect our users from some of the nastier bits of the web, and to make sure that we apply certain controls (such as retention of documents for our corporate record and to comply with theFreedom for Information Act).
Protecting the keys to the kingdom
We quickly realised that we’d need quite a lot of confidence in at least some of the cloud services we’re using. We reckoned that the most sensitive datasets would be in our emails and our document management system. To protect this data, we’d also need similar confidence in identity providers that make the decisions about who can access what data, and anything used to manage our devices. This meant that for the NCSC IT, we needed to focus on Office 365 and our two IaaS providers; Amazon Web Services and Microsoft Azure.
We turned to the NCSC Cloud Security guidance to assess each of the services, looking for good answers to each of the 14 security principles. We wanted to carry out the full assessment as suggested in the guidance as were looking for confidence in some of the less measurable aspects of the service. This included:
- the amount of effort the providers put into maintaining and securing the services
- the odds of them detecting an intrusion
- understanding how our data would be separate from other users of the service
We acquired this confidence in a few different ways:
- The providers had produced formal responses to our 14 security principles. These meant we didn’t need to search lots of documents to get the answers to our main questions.
- Many of the responses to our security principles were backed up by independently auditable international standards, which meant we didn’t need to blindly trust the claims being made.
- The providers had published good-practice guides to help security conscious enterprises get their initial configuration right.
- We’ve been fortunate enough to work closely with Microsoft and Amazon Web Services over the last few years. Their openness in those conversations including imperfections and future aspirations has given us confidence that each of them know how to run a service that is good enough to secure the data in question. It’s also meant that when they make security claims we have reason to believe them.
Traditionally someone would have spent a lot of time analysing the answers to the 14 principles to come up with a multi-coloured bespoke spreadsheet describing exactly why we chose to trust the service at that moment. We didn’t do that. Instead we looked at the vendor responses to the principles, used some of the other sources to figure out if the answers were believable then decided whether the responses met our needs.
They did.
Then we simply got on with using the services, following the vendors’ blueprints and good-practice guides during setup and configuration.
And that amount of security was just right
Our users told us quite a lot about how they wanted to do their work and the types of tools that would help. One of the common themes was that we wanted to use much of the same software and cloud services as the rest of the tech sector, rather than us sticking to the more legacy or bespoke ways of working that we’d had to use in the past.
One of the challenges of wanting to use a variety of SaaS services is that it’s time-consuming and often difficult to do a full security assessment against the service in the way we’ve done for AWS, Azure and Office 365. We quickly realised though that we didn’t need to get that same level of confidence in some of the other services we’re using, because the reputational risk of something going wrong in those services was much lower.
In a previous blog post I discussed some of the ways you can get confidence in security promises of a cloud service, and uncoincidentally, some of the products we’re now using were the ones mentioned. Some of our preferred services didn’t publish as much info about their service online as we’d liked. We used those services to do some discovery work on an ‘due diligence’ approach for SaaS services designed to ensure that the services at least got the basics right.
Let me talk you through some examples:
- Our technical writers wanted to use Atlassian Confluence to collaboratively draft the guidance and blogs before they’re published on our website. As the majority of that data will end up being published on the web anyway, we were happy to rely on the claims made in Atlassian’s published security white papers.
- As we started to develop services to support our Active Cyber Defence strategy, we wanted to use the industry-standard Git to manage our source code. As the people responsible for the Git, GitHub.com seemed like an obvious choice for our public and private repositories. We applied the previously mentioned SaaS guidance to the service to check that it did some sensible security things. To mitigate the risk of us not knowing a lot about the service, we make sure we scan our code for credentials, SSH keys etc. before it’s checked in, which in any case is good practice for code that may in the future be made open source.
- Stuart G mentioned in his recent blog that we use Windows Defender’s cloud backed protections as recommended in NCSC’s EUD Security Guidance for Windows 10. We have configured the product suite so that it avoids sending sensitive data (such as documents or emails) to the Defender cloud service. As long as we’re willing to trust that Defender acts as described then we don’t need to do any further work to build trust in the associated cloud service as our sensitive data won’t be uploaded. You can read more about applying this philosophy to other products in our recent guidance about managing the risk of cloud-enabled products.
Here’s the silver lining
I’ve talked about a few of the SaaS options we use, and you can see that we’ve put more effort into getting confidence in the security of some services than others. We’re hoping that you can similarly identify which of your cloud services you need to focus your time and effort on, and just as importantly which ones you don’t.
We’d love to hear what’s given you the confidence to use certain SaaS services – please drop us a line using the comments below.
Source: National Cyber Security Centre
