G-Cloud security process: others can learn from UK improvements

The UK government's security accreditation process was initially clunky, but it improved through the framework's nine iterations – a tenth is due to go live in June 2018. Good security is essential for a cloud framework to work, but so is a process that is suitable for vendors.

The evolution of security accreditation under G-Cloud contains some useful object lessons for any party considering operating a cloud marketplace at scale. The initial approach to accreditation was very resource-intensive, costly and slow for all concerned. The self-assertion approach subsequently developed under G-Cloud is far more practicable.

Security accreditation for G-Cloud 1 – a rough beginning

The history of the G-Cloud accreditation process provides some interesting insights into the early approaches adopted for the purpose of accrediting multiple suppliers across the framework as a whole. The process was quite involved.

G-Cloud security accreditation was originally conducted centrally by the Pan Government Accreditation service (PGA) at CESG, the UK’s National Technical Authority for Information Assurance, which is now part of the UK's National Cyber Security Centre (NCSC).

At that stage, security accreditation was required for suppliers wishing to win G-Cloud contracts where they would be handling certain information depending on the nature of the risks posed to the information's confidentiality, integrity or availability.

Generally, there was reliance on the ISO/IEC 27001 information security management standard. After the scope of the certification had been agreed with the PGA, the certification had to be conducted by recognised certification bodies. A supplier with an existing ISO 27001 certification still had to go through the accreditation process so that the PGA could check that the scope of the existing certification was appropriate.

Some contracts available to suppliers on the G-Cloud did not require security accreditation due to the low risk levels of the information, while there were different certification schemes or information security standards that suppliers could meet to win accreditation to make them eligible for contracts where there were greater information security risks, from ISO data security standards certification, to meeting the government's own information risk management standards.

The precise scope of the certification had to be agreed by the PGA, and this initially led to a capacity crunch as proposals for certification requirements by suppliers were processed.

Suppliers were asked to "document how they provide a service and how the service is supported and from where with details of the security measures employed", and in many cases submit extra documents such as Data Protection Act compliance checklists, risk registers, details of external certifications with ISO standards and information about their security operating procedures.

The process of accreditation was therefore slow – five months after G-Cloud 1 went live, no supplier had completed the accreditation process.

Security accreditation was particularly complex where some cloud suppliers were reliant on other cloud providers for the nature of the services they were offering, such as in the case where a SaaS provider relies on the infrastructure or platform provided by another cloud provider. In those cases, the SaaS provider was not be able to rely solely on certifications obtained by their IaaS provider, and often the underlying IaaS or PaaS provider would need to complete security accreditation themselves to support the accreditation that the SaaS providers was seeking.

Where services were accredited, they were acknowledged, and badged, as such on the CloudStore.

This administrative headache and costly process of obtaining industry standard certifications and winning security accreditation more generally made many suppliers question whether the benefits of G-Cloud accreditation were worth the hassle.

Particular questions were raised by suppliers including where inspections were required for security accreditation, and whether an independent audit certificate might suffice - the answer being that the PGA could not waive a right of inspection if required.

Suppliers were also unclear whether the hosting had to be in the UK. Offshoring was not specifically prohibited, but has been mentioned as a barrier to public sector use of cloud generally. The physical location of data has historically been considered a technical security issue; however it is apparent that the decision to avoid the offshoring of data is often based on compliance with stringent regulations, political pressures, or legacy preferences. The perceived risk is often greater than the real one.

The security accreditation regime for G-Cloud has radically changed, however, since those early days. With most of today's major hyperscale cloud providers investing heavily to ensure the confidentiality, security, accessibility, and integrity of their customer’s data, whether data is kept in the UK or offshored, it seems some of the perceived concerns have been addressed.

Improvements in security accreditation

Two things in particular helped to simplify the accreditation process.

First, the UK government, through the Cabinet Office and CESG, established 14 cloud security principles to help steer organisations towards compliant adoption of cloud services. The principles have been supplemented with further guidance, including on cloud users' IaaS responsibilities and secure usage, and separation in cloud, as well as detailed assistance on implementing the principles themselves. Although the documents regarding the security principles have gone through several incarnations, including being reworded for non-technical readers, the principles remain broadly the same.

The 14 cloud security principles are:

• Data in transit protection – user data transiting networks should be adequately protected against tampering and eavesdropping
• Asset protection and resilience – user data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure
• Separation between users – a malicious or compromised user of the service should not be able to affect the service or data of another
• Governance framework – the service provider should have a security governance framework which coordinates and directs its management of the service and information within it. Any technical controls deployed outside of this framework will be fundamentally undermined
• Operational security – the service needs to be operated and managed securely in order to impede, detect or prevent attacks. Good operational security should not require complex, bureaucratic, time consuming or expensive processes
• Personnel security – where service provider personnel have access to your data and systems you need a high degree of confidence in their trustworthiness. Thorough screening, supported by adequate training, reduces the likelihood of accidental or malicious compromise by service provider personnel
• Secure development – services should be designed and developed to identify and mitigate threats to their security. Those which aren’t may be vulnerable to security issues which could compromise your data, cause loss of service or enable other malicious activity
• Supply chain security – the service provider should ensure that its supply chain satisfactorily supports all of the security principles which the service claims to implement
• Secure user management – your provider should make the tools available for you to securely manage your use of their service. Management interfaces and procedures are a vital part of the security barrier, preventing unauthorised access and procedures are a vital part of the security barrier, preventing unauthorised access and alteration of your resources, applications and data
• Identity and authentication – all access to service interfaces should be constrained to authenticated and authorised individuals
• External interface protection – all external or less trusted interfaces of the service should be identified and appropriately defended
• Secure service administration – systems used for administration of a cloud service will have highly privileged access to that service. Their compromise would have significant impact, including the means to bypass security controls and steal or manipulate large volumes of data
• Audit information for users – you should be provided with the audit records needed to monitor access to your service and the data held within it. The type of audit information available to you will have a direct impact on your ability to detect and respond to inappropriate or malicious activity within reasonable timescales
• Secure use of the service – the security of cloud services and the data held within them can be undermined if you use the service poorly. Consequently, you will have certain responsibilities when using the service in order for your data to be adequately protected

The simplification of the UK's data security classifications scheme has also helped make it clearer how government information is to be treated. Now, there are only three UK government security classifications for information: OFFICIAL, SECRET and TOP SECRET. The reforms came after the government identified that the previous way information risk impact was rated had "led to negative outcomes".

Together, these two developments have stood the test of time.

An example of how the guidance and new classification scheme has helped is evidenced in the greater clarity that has been provided in relation to the 'offshoring' of data.

Guidance on asset protection and resilience – to which principle two of 14 refers – makes clear that organisations need to understand "in which countries [their] data will be stored, processed and managed" and further consider "how this affects [their] compliance with relevant legislation", such as the Data Protection Act. The buyers are also invited to consider "whether the legal jurisdiction(s) within which the service provider operates are acceptable to [them]".

Further guidance from the Cabinet Office also clarified that offshoring at the OFFICIAL level is permitted in principle, subject to appropriate approvals.

However, it made clear that "just because a country is generally considered geopolitically appropriate for information to be offshored, [this] does not negate the need for a full security assessment of the service to be offshored". It said "the location is no guarantee of security" and that "the technical security controls around a service may mean that the solution is appropriate despite hosting data in countries not recognised as generally acceptable". The guidance, however, prohibits off-shoring information that relates to or supports national security.

The new classification and cloud security principles saw changes made to the G-Cloud accreditation process. It meant, among other things, that PGA accreditations were no longer required for G-Cloud. The G-Cloud team anticipated that most OFFICIAL information could be managed through G-Cloud-accredited services, "and any stated residual risks should be managed in line with local risk appetites".

The focus therefore switched to meeting specified requirements for handling OFFICIAL information recognitions based on the cloud security principles. Information classed as SECRET and TOP SECRET would have little impact on cloud services, as cloud infrastructure for these would either be private clouds or "small, specific community clouds".

To ensure a common quality level across suppliers and allow search result filtering on the digital marketplace, set questions were provided based on the principles. To answer them the supplier had to choose from a list of certain predefined assertions (yes/no or a short menu), and also a predefined list of supporting approaches to managing security risks – these had to reflect the mechanism and evidence the supplier was to use.

Under this new approach, it was for suppliers to decide on their own supporting approach and the level of evidence provided to assure their assertions – third party certifications could be used as independent validation of assertions.

The self-assertion security statements for each service were included in suppliers' digital marketplace service description entries, to provide more transparent and better information for buyers to use when assessing and comparing services against their specific requirements, and make it easier for buyers to review security aspects. It was made clear to buyers that the responsibility to understand their own security requirements fell squarely to them.

Suppliers had to agree to complete assertions truthfully and, their assertions, supporting approaches and services were also subject to random sample checks or audits. Buyers could report for audit any "over represented" suppliers or services. Where changes were identified as being required, suppliers faced potential removal from the G-Cloud if they did not make those amendments by a specified deadline.

The changes were not without issues. Some suppliers balked at the sheer number of questions which had to be completed for each service separately. By the time G-Cloud 7 was introduced, plain English was used for the security assurance questions.

Security accreditation under G-Cloud 9

The approach to security requirements for G-Cloud 9 evolved further.

The security assurance questions were rewritten with technology and security experts from GDS and the NCSC, making them more specific to the technology concerned, better aligned with the cloud security principles, whilst allowing suppliers to answer in more detail.

The changes reflected feedback the government received from workshops with security and technology professionals, which highlighted issues such as a lack of understanding among buyers as to how to clearly communicate the security details they needed, and a lack of understanding of the procurement language used by buyers among suppliers' technical teams.

The workshops also found that suppliers wanted to know about buyers' security requirements, how risk averse they were and any specific technical blockers earlier in the buying process, while buyers wanted to know how to understand and assess suppliers’ security assertions.

These issues were considered and fed into the G-Cloud 9 process. Draft security questions were also shared with suppliers a few weeks in advance of G-Cloud 9 opening.

Lessons learned

The evolution of security accreditation under G-Cloud, moving from the initial PGA approach to accreditation to the self-assertion approach, is far more practicable for all concerned.

That being said, it is possible that the UK's self-assertion model could raise the risk of buyers insisting on their own internal accreditations each time; with some possibly seeing cessation of PGA accreditation as a step backward.

On the other hand, backing up assertions with industry standard certifications such as ISO27001 or CSA STAR should mitigate this risk, and it makes sense for buyers to rely on such certifications as a half-way house – it is not as time-consuming for government as PGA accreditation, but more trustworthy than pure self-assertions alone.

Any party seeking to establish a similar G-Cloud model would be wise to spend time focussing on this issue in some detail in order to achieve the desired optimal balance between convenience and confidence.

Certainly it has been suggested that some SaaS suppliers that had not won G-Cloud business lacked must-have credentials such as ISO 27001. Obtaining industry standard certifications will obviously involve further time/costs for SMEs, which may result in increased prices all round, but one hopes also better, more transparent security information for buyers.

More broadly, at least at central government level it is recognised that 'security says no' won't cut it anymore in procuring cloud – transparency and auditing are important, and a nuanced, proportionate approach is needed as appropriate to the type of data and use concerned.

Government guidance on public sector use of cloud has clearly stated that it is "possible for public sector organisations to safely put highly personal and sensitive data into the public cloud", but that "it may not be appropriate to use cloud services for specific systems or data". This includes "when there are specific legislative requirements around data sovereignty", it said.

It seems clear that, while attitudes are changing, in the UK there is room for yet more education of potential G-Cloud buyers regarding cloud security risk assessment, assurance and mitigating measures. Any party considering establishing a similar model to G-Cloud elsewhere would be well advised to consider investigating whether this theme resonates as strongly in their environment, and allocating appropriate resources accordingly.

Claire Edwards is an expert in technology contracts at Pinsent Masons, the law firm behind Out-Law.com.