It was with some trepidation that, over the Christmas break, I clicked on links to the newly published Government Cloud Security Principles. Trepidation because my contact with such principles goes back a long way and, in government, principles tend to hide more than they reveal.
Some three years ago whilst looking at G-Cloud in its early days, I proposed that, as part of the procurement process, we publish a detailed set of guidelines that explained not only what was meant by IL0, IL2 and IL3 (I skipped IL1 on the basis that in over a decade, I have never heard anyone use it) but also what would be required if, as a vendor, you were trying to achieve any of those accreditation levels. My thinking was if government was truly going to encourage new players to get involved, few would commit to building out infrastructure if there wasn’t specific guidance on what they would need to do.
I produced a short document – some 4 pages – which I thought would act as a starter. I’ve published it on Scribd so that you can see how far I got (which wasn’t all that far, I admit – I’d say it’s a beta at best). Some weeks later, after chasing to see if it could be developed further, in partnership with some new suppliers so that we could test what they needed to know, I was told that such a document would not be viable as, and I quote, “it would encourage a tick box attitude to security compliance”. Some thing in me tells me that would be no bad thing – definitely better than a no box attitude, no?
So here we are, in early 2014, and someone else – perhaps some brave person in Cabinet Office – has had another go. Is this just a tick box exercise too? Or would I find seriously useful principles that would help both client and supplier – the users – achieve what they both need?
Sadly, the answer is that these principles do not help. Perhaps in a desire to ensure that there was definitely no encouragement of a tick box approach, they say as little as possible using words that are unqualified and without any context or examples that would help. It strikes me as unlikely that any security experts in departments will find a need to refer to them and that any supplier seeking some clues as to the fastest route to an accredited service will linger on them no more than a moment.
– The word “adequate” or “adequately” is used four times. As in “The confidentiality and integrity of data should be adequately protected whilst in transit”. Can’t disagree with that. Though, of course, I don’t know what it means in delivery terms
– “Appropriate” crops up three times. As in “All external or less trusted interfaces of the service should be identified and have appropriate protections to defend against attacks through them”. Excellent advice, everything should always be appropriately protected. No more and no less. But how exactly?
– Or how about this: “The service should be developed in a secure fashion and should evolve to mitigate new threats as they emerge”. No one would want you to develop an insecure service but what exactly is meant by this?
– Or this one: “The service provider should ensure that its supply chain satisfactorily supports all of the security principles that the service claims to deliver”; so now the service provider needs to decide what is meant by the principles and ensure that anyone it users also complies with their very vagueness.
Of course, there’s a rider at the front of the document, which says:
This document describes principles which should be considered when evaluating the security features of cloud services. Some cloud services will provide all of the security principles, while others only a subset. It is for the consumer of the service to decide which of the security principles are important to them in the context of how they expect to use the service.
So not only do we have to decide what is adequate and appropriate, we have to decide which of the principles we need to adopt adequately and appropriately so that we have adequate and appropriate security for our service, lest it be seen as inadequate and/or inappropriate perhaps. How appropriate.
This is hardly academic. If you want commodity services, then you need to provide commodity standards and guidelines. Leaving vast areas open to interpretation only furthers the challenges for new suppliers (and entrenches the capabilities of those who already supply) and means that customers are unable to evaluate like for like without detailed (and likely continuing) reviews.
To give an example, I recently sat with great people from three different government departments to look at the use of mobile devices. One was using WiFi freely throughout their building (connected to ADSL lines) to allow staff with department issued iPads and Windows tablets to access the Internet. Another had decided that WiFi was inherently untrustworthy and so insisted that staff use the 3G or 4G network, even issuing staff with Windows tablets a dongle that they needed to carry around (and pair via bluetooth – which is, I assume, for them more secure than WiFi) to access the Internet.
If three departments can’t agree on how to configure an iPad so that they can read their email (this wasn’t about using applications beyond Office apps), what hope is there for a supplier offering such a service? Where is the commodity aspect that is necessary to allow costs to be driven down? And how would a new supplier, with a product ready to launch, know how it would be judged by the security experts so that it could be sold to the public sector?
Principles such as these encourage – perhaps even direct – departments to come to their own conclusions about what they need and how they want it configured, just as they have done for the last three decades and more.
With today’s protective markings – IL0, IL2 and IL3 etc – that is one thing. With tomorrow’s “OFFICIAL”, there is a real need for absolute clarity on what a supplier needs to do and that can only come from the customer being clear about what they will and won’t accept – it cannot be that one department’s OFFICIAL is another department’s UNACCEPTABLE.
Fingers crossed that this pre-Alpha document is allowed to iterate and evolve into something that is useful.