- (Image: ‘Cloudy with a Chance of Meatballs’ – Sony Pictures Animation)
In my previous blog I talked about some approaches we’ve found to getting assurance against our 14 Cloud Security Principles, and how you can use the information that providers publish to assess how they run a service.
On a recent project, the preferred cloud provider didn’t publish much to describe the security properties of their services. Given the cost and potential risk involved (the system stored a large amount of personal data), the project team decided that it was worth exploring the service face-to-face to jointly work out how well the service met the project’s security requirements. As part of that they asked the NCSC to support the conversation and bring our approach to cloud security to the table.
Exploring the cloud
The presentation started with an initial claim that the service met all 14 of NCSC’s Cloud Security Principles; a rather confident statement which prompted us to explore a number of topics. This included seeking confidence that their protective monitoring actually detects malicious activity, that they apply all security patches promptly, and finding out how they go about hiring people who can be relied upon to build and operate the service securely.
For some of the discussion, their sales team focused on how a topic (patching, for example) wasn’t our problem, as we were buying into a managed service. They were probably trying to give us confidence in how much easier it would be to use their service (rather than run our own), but it actually had the opposite effect. We couldn’t help but assume the worst; that if the cloud provider avoided questions then they must have something to hide.
It’s useful to compare the responses given by different providers concerning patching. Do you think one gives more confidence than the other?
- Provider 1 commits on their public website to applying critical patches within 30 days of their publication. These patches are usually published monthly. Data from the service’s threat model, and feeds from internal audit and monitoring systems are used to prioritise which patches to test and deploy first. These security patches are often applied across the service within a day or two of their publication (but the service provider isn’t in a position to guarantee that, and therefore doesn’t).
- Provider 2 patches their service ‘in line with industry standards’, and actual figures would be defined in a contract. We’d anecdotally heard that security patches for the product used by the provider were published on a fixed schedule, and once released they would be applied to the cloud service within 90 days. This stance was acknowledged but not confirmed by the vendor.
If I had found those two providers, and they both met my needs in other ways, I would without question prefer Provider 1.
You don’t need perfection
Of course, focusing on a specific aspect of 1 of the 14 Security Principles will only ever be a small part of the your wider decision. However, the style of conversation (and resulting openness for that 1 facet) makes me think that that one provider cares more about my data than the other. This openness can lead to finding a few skeletons in the closet. So far we’ve found these admissions to be – for the most part – positive, as they demonstrate that the service provider acknowledges issues or incidents, which leads to discussions around their aspirations and commitments to improve in the future. And of course, we’re not seeking perfection; real services will tend be good at some things and less good at others.
In the case I touched on earlier, we ended talking a different team inside the service provider’s organisation. It allowed us to focus on some specific areas of concern to work on together, and that did include a commitment to patching. The customer was able to get confidence in those proposed improvements by stating expectations in contracts, and they will continue to engage with the vendor to manage expectations. It might end up being a long journey, but the decision to buy that service now relies on the vendor holding up their end of the deal.
The value of transparency
This sort of approach isn’t scalable, as the conversations were had behind closed doors. Even the more general ‘lessons learned’ can’t be easily applied elsewhere, as different projects and organisations have different risk profiles and types of data. If we could have obtained more information from published sources, we’d have been able to share some of the details with others looking to make similar technology decisions. It would also make it possible to include the product in any repeatable assessment framework for SaaS security.
I’m hoping this blog highlights the value of cloud providers being transparent with customers about their approach to security. It’s bit like a cirrostratus cloud – it might be a sign that change is coming, but most of the time you can see what’s going on behind it. Whether you’re selling services to the public sector, industry or individuals, that transparency gives much more confidence than the exact details of how the service is run. We’d love to hear in the comments about other cloud service providers that publish relevant and easy to understand information about how they secure their services!
Andrew A
Cloud Security Research Lead – NCSC
Source: National Cyber Security Centre
