Blog post

Cloudy with a chance of transparency

Created:  23 Oct 2017
Updated:  23 Oct 2017
Author:  Andrew A
Cloudy with a chance
(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 up talking to 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

8 comments

Jamie A - 24 Oct 2017
Great article, i'm currently assuring the use of a cloud provider who publishes plenty of compliance statements and assurances. However people may be at risk of assuming that there is nothing to worry about, which upon my research there are a number of considerations or responsibilities for the tenant to make, regardless of the CSPs statements.

Each solution being deployed needs to be assessed against it's own requirements and that of the CSP. There is no one-size fits all unfortunately.

Andrew A - 25 Oct 2017
Hi Jamie. We’ve similarly found that everyone’s requirements are a bit different and there will probably be a few different ways of meeting those requirements. It's the philosophy behind our Cloud Security guidance.

The evidence that backs up compliance statements and assurances are often useful in helping you figure out whether a CSP can meet your requirements, but we tend to find that they’re not an answer on their own.
Stuart Mckean - 27 Oct 2017
Andrew,

Good article, if only more organizations took notice of your points.

What we have done is list what we do and how we do it against the 14 principles as a document for any tender. We have only once been asked to provide this document which is a surprise. We also try to match what the end user wants to achieve from the solution and match that against the Sy principles for the organization.

Very happy with a transparent attitude..
Stuart





David Tomkins - 06 Nov 2017
As a cloud service provider we are happy to provide customers with answers to all of their questions about cyber security, information management, and data jurisdiction etc. However, we cannot agree with the stance Andrew has outlined regarding full and complete transparency on this. In the past we made a number of white papers on our cyber security approach available to the public. These were fairly candid papers which explained where we felt we had strengths and also where we weren’t as strong. Unfortunately a number of security researchers picked these papers to shreds and a number of our competitors used the ensuing tech press feeding frenzy to paint us as incompetent on cyber security.

Unless you have a solution for this sort of reaction to transparency, I am afraid we won’t be publishing information like that again soon.
Andrew A - 10 Nov 2017
We’re sorry to hear that your experience was so negative. I am however really encouraged that you still feel able to share directly with your customers, which ultimately gets them to the same place.
Jonthan - 11 May 2018
Hi Andrew,

Great article - thanks for sharing

I'm curious, did either of these providers appear in the CSA "STAR" registry?

Whilst NCSC guidance is clearly based on sound principles with a whole bunch of experience and knowledge forming them, I'm just not sure the commercial sector will be au fait with the detail and whilst the sales guys will always be "glass half full" types its not helpful when advising HMG customers.

Should we be focussing on more commonly recognised stardards to "long list" then hone in on the HMG stardards wih those that make the cut?

Love to here your thoughts.
Andrew A - 06 Jun 2018
Both of the providers do appear in the CSA STAR registry. It’s my personal observation that it can be difficult to ascertain much about the security properties of entries that have only done self-assessment as the amount of relevant published detail varies per entry.

I have however found it to be a great reference for those companies that have linked to independent audits or attestations.
Max K - 12 May 2018
I'm particularly interested in the automated reporting and verification of things which whoever has decided to be about whatever.

The key to an *ongoing* security stance of any organisation is the ability to be consistent in its approach, hopefully its automated, but that what they say they're going to do, they know if they're not doing it. Things break down, run books get missed, steps fail, things change and need reengineering.

I'd give any vendor major points if they have committed to automation in the verification and then roll that into an ongoing transparency process. I don't need to see the reports automatically but the fact that they exist and can be shared demonstrates a state of mind

Leave a comment

Was this blog post helpful?

We need your feedback to improve this content.

Yes No