The UK government issued some concise but fairly comprehensive cloud service security principles (edit: available in the preceding link, in HTML format only), in mid-December 2013, as guidance for UK public sector organisations when considering the use of cloud services to process official information. They were described by Government Digital Service COO Tony Singleton and on a related webpage (edit: see the preceding link for associated info) as being in public beta, although this is not stated on the page containing the principles itself. (Feedback should be sent to [email protected])
Below I set out the text of these security principles (licensed under the Open Government Licence), but adding some suggestions, highlighting and comments of my own with deletions and insertions marked (eg I've highlighted the sentence regarding a named senior executive being responsible for security).
These principles apply to proposed UK public sector use of cloud services and are not limited to personal data, of course. It is interesting that there is much use of 'should', rather than 'must', and no recommendations are explicitly made on whether obligations on the part of the service provider regarding these issues should be made legally-binding by embodying them in the contract terms.
Guidance
Cloud Service Security Principles
The UK government issued some concise but fairly comprehensive cloud service security principles, in mid-December 2013. They were described by Government Digital Service COO Tony Singleton and on a related webpage as being in public beta, although this is not stated on the page containing the principles itself. (Feedback should be sent to [email protected])
Below I set out the text of these security principles (licensed under the Open Government Licence), with some suggestions, highlighting and comments of my own added (eg I've highlighted the sentence regarding a named senior executive being responsible for security).
These principles apply to proposed UK public sector use of cloud services and are not limited to personal data, of course. It is interesting that there is much use of 'should', rather than 'must', and no recommendations are explicitly made on whether obligations on the part of the service provider regarding these issues should be made legally-binding by embodying them in the contract terms.
Guidance
Cloud Service Security Principles
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.
Some service providers will be able to offer higher levels of confidence in how they implement the different security principles. Consumers[1] will need to decide how much, if any, assurance they require in the different security principles which matter to them.
These principles apply equally to Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) as defined by NIST.
1. Data in transit protection
The confidentiality and integrity of data should be adequately protected whilst in transit.
The following aspects should be specifically considered:
• Consumer to service
• End user to service [ie individual citizens using the service]
• Within the service (for example, between data centres)
2. Asset protection and resilience
Data should be physically secure as it is processed by and stored within the service. This security should be based on suitable physical security controls within data processing, storage and management locations.
The business requirements for availability of the service should be an important consideration when choosing a cloud service. The consumer should ensure that a contractual agreement is in place with the service provider which adequately supports their business needs for availability of the service.
The legal jurisdiction of the service will be an important consideration[2] for many consumers, especially if they wish to use the service to store or process personal data. This principle dependsmay depend on the physical locations of processing, storage, transit and/or management of the service. as well as jurisdictions where the service provider or any relevant sub-provider(s) is incorporated or established or where it has operations and/or assets
The following aspects should be specifically considered:
• Location of data centres hosting the service
• Security surrounding those data centres
• Location of service management facilities
• Countries of relevant service providers’ establishment or incorporation, and where they may have operations or assets
• How the confidentiality and integrity of data-at-rest will be maintained as appropriate to the nature of the data and service concerned (eg encrypting or tokenising data before upload to the service, bearing in mind the importance of adequate key access and key management; and paying for backups by the service provider if not included in the service, or for backups to another service provider, or even backing up to internal systems)
• Availability of the service
3. Separation between consumers
SeparationLogical separation between different consumers of a service (guaranteed to a level appropriate to the requirements of the [consumer]) should be achieved at all points within the service, including across compute, storage and networking resources.
An important consideration will be whether the service is a public, private, or community, shared cloud service; if all tenants[3] of the service are known to be trustworthy then less confidence in the separation properties of the service may be acceptable.
4. Governance
The service provider should have a security governance framework that coordinates and directs their overall approach to the management of IT systems, services and information. A clearly identified, and named, senior executive should be responsible for security of the cloud service.
5. Operational security
The service provider should have processes and procedures in place to ensure the operational security of the service.
The following aspects should be specifically considered:
• Configuration and change management
• Vulnerability management
• Protective monitoring
• Incident management
6. Personnel security
Service provider staff and any relevant sub-contractor staff should be subjected to adequate personnel security screening for their role. At a minimum this should include identity, unspent criminal convictions, and right to work checks. For roles with a higher level of service access, the service provider should undertake and maintain appropriate additional personnel security checks. Each individual’s access to [consumer] data, including metadata, should be limited to only data they are required to access to perform their role.
7. Secure development
The service should be developed in a secure fashion and should evolve to mitigate new threats as they emerge.
8. Supply chain security
Cloud services often rely upon third party services. Those third parties can have an impact on the overall security of the services. The service provider should ensure that its supply chain satisfactorily supports all of the security principles that the service claims to deliver[4] .
9. Secure consumer management
Consumers should be provided the tools they need to securely manage their usage of the service.
The following aspects should be specifically considered:
• Authentication of consumers to management interfaces
• Separation of consumers within management interfaces
• Authentication of consumers within support channels
• Separation of consumers within support channels
10. Secure on-boarding and off-boarding
The service should be provisioned to consumers in a known good state, and their data must be satisfactorily deleted when they leave the service. What is ‘satisfactory’ may vary with the requirements of the [consumer] as regards the nature (eg sensitivity) of the data and usage concerned, eg number of passes, confirmation of deletion from all duplicates and backups etc. When physical storage components reach their end of life, the service provider should make appropriate arrangements to securely destroy or purge any consumer data they held.
11. Service interface protection
All external or less trusted interfaces of the service should be identified and have appropriate protections to defend against attacks through them.
The following aspects should be specifically considered:
• Connections to external services on which the service depends
• Dedicated connections to tenants[5]
• Remote access by service provider
• Publicly exposed services
12. Secure service administration
The methods used by the service provider’s administrators to manage the operational service (monitor system health, apply patches, update configuration etc.) should be designed to mitigate any risk of exploitation which could undermine the security of the service. The security of the networks and devices used to perform this function should be specifically considered.
13. Audit information provision to tenants[6]
Consumers should be provided with the audit records they need in order to monitor access to their service and the data held within it. [What’s meant by ‘audit’ here? Just access to logs? Or formal annual audit reports by independent third party security experts? It would be helpful to have more detail on what kind of logs should be required, eg logs of accesses to metadata as well as data, and what kind of formal audits should be required.]
14. Secure use of the service by the consumer
Consumers will have certain responsibilities when using the service in order for their use of it to remain secure, and for their data to be adequately protected.
Depending on the type of service, the consumer will have responsibilities relating to the following topics:
• Audit and monitoring
• Storage
• Networking
• Authentication
• Development security
• End user devices used to access the service
• Secure configuration of the service
• Patching
15. Glossary
| Management interface | a service exposed to consumers or service provider administrators to allow administrative tasks to be performed. |
| Support channel | an online, or out of band (e.g. telephone), communication channel which consumers can use to obtain support from the service provider. |
| On-boarding | the process of a consumer moving on to the service. |
| Off-boarding | the process of migrating a consumer away from a service. |
| Public, private and community cloud | refer to the NIST definitions of these terms. |
| Consumer |
[1]May be confusing to use the term ‘consumer’, which many think of as individual end users, eg citizens who use a government department’s service that the department provides using a cloud service. ‘Customer’ of cloud service?
[2]Absolutely. This is the critical point. I argue that, legally, physical location should be relevant not per se but only because it may determine legal jurisdiction and/or IT security.
[3]See comment on Glossary below on use of ‘tenant’
[4]What if the provider makes no or limited claims regarding its service’s security?
[5]As before.
[6]Or ‘consumer’?
[7]‘Tenant’ applies to IaaS but less so to PaaS and SaaS. And see previous comment on ‘consumer’.