i) I like cloud computing so much I wrote a book on securing cloud services;
ii) I worked client-side at a Government agency helping them to move all of it's IT delivery over to G-Cloud services; and
ii) I was the Industry security subject matter expert on the original Intellect/CIO Council project team that first floated the idea of a Government cloud (the HMG Data Centre Consolidation project). I was there at the start.
The reason for resuscitating my blog is the changing approach towards assuring cloud services.
In the earlier iteration of the G-Cloud framework, cloud services were assured by the Pan-Government Accreditors prior to being deployed by individual departments. This is now changing. G-Cloud providers can now simply assert their security credentials and it's up to each G-Cloud customer to decide whether this is sufficient to meet their needs. This is plainly silly. We've moved from a single body providing a consistent level of assurance to all of Government - do it once, do it right - to an approach that requires *each* department to perform it's own assurance.
If the centre was struggling to hire/train enough resource to assure the G-Cloud services, I'm wondering where the skilled resources will come from to staff each of the individual HMG bodies that now need to conduct their own assurance activities? Clearly it's not going to happen. I haven't even touched on the folly of relying on self-assertion of security controls by service providers. This is similar to boarding a Trans-Atlantic flight and hearing the pilot on the tannoy stating "Don't worry folks, we're not doing any safety checks before take-off as I know you're keen to get going. But we will of course do some checks when we land. Or otherwise cease to be in the air...".
But this is a post about a thought experiment. So, here we go...
Department A has traditionally relied upon Pan-Government Accreditation to assure cloud services before they adopt them. Given the change in approach, the Department has now decided that it won't rely simply upon self-assertion but will also require any cloud provider to hold an appropriately scoped ISAE3402/SSAE16 SOC 2 or CSA STAR certification. This ruled out Cloud Provider X which only had the self-asserted statements.
Department B has a higher appetite for risk than Department A. They are happy to accept self-assertion. They've therefore adopted Cloud Provider X because it offers extremely cheap services (for some reason).
Department A needs to share data with Department B. Department A knows that Department B makes use of Cloud Provider X - a cloud provider that Department A has explicitly already decided is not sufficiently assured to host their data.
What happens now? Does Department A go explicitly against it's own local risk management and share the data regardless? Does Department A share the data with Department B alongside a "common sense" "plain English" set of handling conditions that state that the data must not be processed on Cloud Provider X? If so, where does that leave Department B? With a need to have an alternative to Cloud Provider X or simply ignore the handling conditions, that's where. Not a good place to be.
This could all have been avoided by having a more sensible approach to cloud provider assurance, one which encouraged a common level of assurance and so facilitated data sharing.
Unfortunately, HMG security policy is moving away from a usable set of common taxonomies and standards and towards a more flexible, locally risk-managed approach which sounds great in theory but is destined to fail horribly in practice as departments each go their own way, adopting different interpretations of "commercial best practice" and making data sharing much, much harder...
If the centre was struggling to hire/train enough resource to assure the G-Cloud services, I'm wondering where the skilled resources will come from to staff each of the individual HMG bodies that now need to conduct their own assurance activities? Clearly it's not going to happen. I haven't even touched on the folly of relying on self-assertion of security controls by service providers. This is similar to boarding a Trans-Atlantic flight and hearing the pilot on the tannoy stating "Don't worry folks, we're not doing any safety checks before take-off as I know you're keen to get going. But we will of course do some checks when we land. Or otherwise cease to be in the air...".
But this is a post about a thought experiment. So, here we go...
Department A has traditionally relied upon Pan-Government Accreditation to assure cloud services before they adopt them. Given the change in approach, the Department has now decided that it won't rely simply upon self-assertion but will also require any cloud provider to hold an appropriately scoped ISAE3402/SSAE16 SOC 2 or CSA STAR certification. This ruled out Cloud Provider X which only had the self-asserted statements.
Department B has a higher appetite for risk than Department A. They are happy to accept self-assertion. They've therefore adopted Cloud Provider X because it offers extremely cheap services (for some reason).
Department A needs to share data with Department B. Department A knows that Department B makes use of Cloud Provider X - a cloud provider that Department A has explicitly already decided is not sufficiently assured to host their data.
What happens now? Does Department A go explicitly against it's own local risk management and share the data regardless? Does Department A share the data with Department B alongside a "common sense" "plain English" set of handling conditions that state that the data must not be processed on Cloud Provider X? If so, where does that leave Department B? With a need to have an alternative to Cloud Provider X or simply ignore the handling conditions, that's where. Not a good place to be.
This could all have been avoided by having a more sensible approach to cloud provider assurance, one which encouraged a common level of assurance and so facilitated data sharing.
Unfortunately, HMG security policy is moving away from a usable set of common taxonomies and standards and towards a more flexible, locally risk-managed approach which sounds great in theory but is destined to fail horribly in practice as departments each go their own way, adopting different interpretations of "commercial best practice" and making data sharing much, much harder...
