Implementing the U.K. Cloud Security Principles

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.

Note: CESG’s Cloud Security Guidance is currently in ALPHA.

This section of the Cloud Security Guidance describes various ways a cloud service can demonstrate how it meets the different Cloud Security Principles. Some of the mechanisms described provide greater assurance than others. This means that the level of residual risk that a particular cloud service has – and that a consumer of this service will need to be aware of – will vary depending on the mechanisms used.

Introduction

For each of the Cloud Security Principles, this document provides:

  • A description of the principle – what it is and why it is important
  • A number of implementation objectives – how the principle should be satisfied
  • A number of approaches that can be taken to meet the implementation objectives, attracting different residual risks

There are a number of common approaches which can be used to support many of the principles. These are described below and referenced where appropriate under each principle heading.

Approach Description Guidance
Service provider assertion The service provider describes how their service complies with the implementation objectives but is unwilling or unable to provide independent validation of their assertions. Consumers are reliant on the honesty, accuracy and completeness of the service provider’s assertions.
Depending on the evidence made available by the service provider, a consumer may be able to make a judgement about how well the implementation objectives have been met.
The service provider’s level of maturity around security, the existence of an in-house security team, proactive testing and historical evidence of responding to security issues can increase confidence consumers may place in a provider’s assertions.
Contractual commitment The service provider contractually commits to meet the implementation objectives. The contract should have specific and measurable requirements in order to be effective. Using clauses which are too generic will potentially add cost, have limited value and may be unenforceable.
Independent validation of assertions An independent third party has reviewed and confirmed the service provider’s assertions. The third party certifies that the service meets the objectives associated with the given principle. Since the third party review may not be performed to a recognised standard it is possible that the review does not thoroughly assess the security delivered by implementation of the principle. Similarly it is difficult to assess whether the third party has the necessary skills to carry out the review.
Consumers relying on such a review should assure themselves that the third party has carried out adequate testing and had the right skills to undertake such a review.
A certificate of compliance with a recognised standard is presented by the service provider. Depending on the standard and certification process, it may be possible to achieve certification with a scope that does not address the implementation objectives. Also, in order to achieve certification against some standards it is only necessary for an auditor to verify that controls exist, or even just that an organisation policy on their use exists, rather than to validate that they are present and effective.
Guidance on specific standards referenced often in this document is given below in Table 2.
A certificate of compliance with a recognised standard is presented by the service provider.
Additionally, the scope of certification and implementation of controls are also reviewed by a suitably qualified individual, such as a CCP certified ‘Accreditor’ or ‘IA Auditor’ at the Senior or Lead level or a recognised subject matter expert.
Assuming the skills and experience of the reviewer are adequate, this approach provides a higher degree of confidence that the service meets the stated objectives. This is achieved through certification against an appropriate standard where the certification covered the appropriate scope, and that the controls implemented are appropriate.
Guidance on specific standards referenced often in this document is given below in Table 2.
Independent testing of implementation Independent testers are used to demonstrate that controls are correctly implemented and that the objectives are met in practice.
Testers should have appropriate industry recognised qualifications for the testing they are carrying out. For example, where penetration tests are used, they should be performed by certified companies, such as those registered in the CHECK, CREST or Tiger schemes.
For some principles, if scoped properly, independent testing can give confidence that the implementation achieves the objectives and reduces the reliance on supplier assertions.
The results of testing will represent a service at a particular moment in time. As a service evolves, it will need to be regularly re-tested or the findings may no longer be accurate.
Scope of testing reviewed by a suitably qualified individual, such as a CCP certified ‘Accreditor’ or ‘IA Auditor’ at the Senior or Lead level or a recognised subject matter expert. Validation should ensure that all service impacting controls are within scope of the testing.
The skills and experience of the reviewer will affect the confidence that can be placed in the review.
Assurance in the service design A qualified security architect is involved in the design or review of the service architecture.
Qualifications such as CCP certified ‘IA Architect’ at the Senior or Lead level can be used to gain confidence in the reviewer’s ability.
Review of the design (and implementation of its recommendations) will give confidence that the architecture defends against common attacks, that the proposed security controls are appropriate and the proposed architecture would allow effective secure operation of the service. It does not verify that components have been properly configured, or that the components are correctly or robustly implemented.
Assured components Independent assurance in the components of a service (such as the products, services, and individuals which a service uses) can provide significant confidence in specific security principles or functions of the overall service.
Foundation Grade assurance represents a good commercial level of security with a well-defined scope of evaluation for security products.
Misconfiguration or misuse the product can undermine any assurance gained. Independent testing can be used to address this issue.
The assurance of the component needs to be relevant to its use within the service. Not all assurance schemes ensure that the scope of assessment is necessarily relevant to the likely use of the entity being tested.

Table 1: Common approaches to implementing objectives

Note that the approaches referred to in Table 1 can often be used in combination to provide greater assurance. Throughout this guide, if an approach results in a particularly high risk remaining, the risk is identified by an exclamation mark (“!”).

There are a number of standards referenced frequently in this document. Specific guidance on each of these is provided below:

Standard Guidance on certification
ISO/IEC 27001:2005
or ISO/IEC 27001:2013
It is possible to be certified as compliant with ISO/IEC 27001:2005 or ISO/IEC 27001:2013. Since the scope of the certification can be specified by the organisation being certified, when using this mechanism to demonstrate implementation of one of more Cloud Security Principles it is recommended that the scope be verified as covering the right aspects. The individual performing this review should have the qualifications referenced in Table 1.
ISO/IEC 27001 certification will not verify that the controls implemented by the service provider are effective.
When relying on ISO/IEC 27001 certification, consumers should note that the United Kingdom Accreditation Service (UKAS) is the only national accreditation body recognised by government to assess organisations that provide certification services. ISO/IEC 27001 audits performed by bodies not recognised by UKAS may reduce the confidence that consumers can place in their quality.
Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) v3.0 CSA CCM v3.0 compliance is achieved through CSA’s STAR scheme.
Consumers are advised that the first level of STAR is ‘self-assessment’ – service providers referencing STAR at this level should be considered to fall into the ‘Service provider assertion’ category above.
The remaining levels of STAR (‘certification’, ‘attestation’ or ‘continuous’) should be considered to fall in the ‘Independent validation of assertions’ category. As with ISO/IEC 27001:2005 or ISO/IEC 27001:2013 it is recommended that a qualified individual verify the scope and implementation of controls to ensure they support implementation of the Cloud Security Principles claimed. The individual performing this review should have the qualifications referenced in Table 1.

Table 2: Standards frequently referenced in this guidance

1.Data in transit protection

Consumer data transiting networks should be adequately protected against tampering and eavesdropping (integrity and confidentiality). This should be via a combination of network protection (denying your attacker access to intercept data) and encryption (denying the ability to for an attacker to read data).

If this principle is not implemented then the integrity or confidentiality of data may be compromised whilst in transit.

Implementation

Objectives:

  • Data in transit is protected between the consumer’s end user devices and the service
  • Data in transit is protected internally within the service
  • Data in transit is protected between the service and other services (e.g. where APIs are exposed)
Approach Description Guidance
Assured components – community WAN service A service such as the Public Services Network (PSN) ‘assured service’ (unencrypted) can provide community or private connections. No cryptographic protections are provided by the service provider, meaning that a compromise of WAN infrastructure would result in the loss of confidentiality and integrity of consumer data.
For PSN, although there are no cryptographic protections, services have been certified through the CESG Assured Service (Telecoms) scheme which provides some assurance in the protections of the network.
Legacy TLS The service is accessed using legacy versions of TLS – versions earlier than 1.2 (!) TLS versions earlier than 1.2 contain vulnerabilities which could be used by an attacker to obtain or interfere with consumer data.
TLS (version 1.2 or later) Use of TLS, configured to use cipher suites and certificate sizes recommended by CESG. This approach is considered to provide adequate protection for most OFFICIAL scenarios, however, the lack of formal assurance in TLS implementations means it is important to gain some confidence in how well the TLS implementation is developed and how well it implements the TLS standard.
Only currently supported TLS implementations developed by reputable organisations should be used.
Assured components – encrypted community WAN service A service such as the PSN ‘protected service’ (encrypted) can provide assured network layer encryption for a community. See Table 1
Assured components – VPN gateway The service can expose a VPN Gateway which has Foundation Grade certification (against an appropriate Security Characteristic, such as the IPsec Security Gateway). See Table 1
Service provider assertion – bonded fibre optic connections Bonded fibre optic connections between physically protected locations can be used to provide private connections between data centres. See Table 1
Independent validation of assertions – bonded fibre optic connections Bonded fibre optic connections between physically protected locations can be used to provide private connections between data centres.
The implementation is validated by a suitably qualified individual, such as a CCP certified ‘Accreditor’ or ‘IA Auditor’ at the Senior or Lead level or a recognised subject matter expert.
The security of these links is dependent on provision for monitoring them – this should be one of the factors covered by an independent review of the implementation.

Additional notes

To compromise data in transit the attacker would need access to infrastructure which the data transits over, this could either take the form of physical access, or logical access if the attacker has compromised components within the transit infrastructure. It is more likely attackers would be able to access infrastructure between the consumer and the service, rather than access infrastructure within the service, though the impact of an attacker accessing communications internal to the service is significantly greater.

It will often be desirable to use TLS protection in addition to network layer protections across internal or community networks, particularly if additional confidentiality of data within an organisation or community is required, or to support application user authentication and access control. This may be especially important where the data being accessed or transmitted is particularly sensitive.

Onboarding and offboarding of consumers into the service may involve the transfer of bulk data into or out of the service. In this scenario, consumers should consider the protection of data during transit either using one of the approaches described above, or through protection of storage media during transit in line with Principle 2.3 (Data at rest protection).

Whilst this principle focuses on confidentiality of data, when considering potential implementation approaches, suppliers should consider their service availability requirements. Some assured WAN services, such as the PSN, have been designed and tested to provide high availability.

2.Asset protection and resilience

Consumer data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure.

The following topics are considered in relation to the protection and resilience of assets within the service:

  • Physical location and legal jurisdiction
  • Data centre security
  • Data at rest protection
  • Data sanitisation
  • Equipment disposal
  • Physical resilience and availability

It is important that the locations in which consumer data is stored, processed and managed from are known as organisations will need to understand the legal circumstances in which their data could be accessed without their consent.

Public sector organisations will also need to understand how data handling controls within the service are enforced, relative to UK legislation. Inappropriate protection of consumer data could result in legal and regulatory sanction or reputational damage.

Implementation

Objective:

  • Service providers make available the following information to consumers:
    • The geographic location(s) where consumer data is stored, processed or managed from (to country level).
    • The applicable legal jurisdiction(s) that the service provider operates within.
    • Consumers are informed of any planned changes to the above.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions No recognised standard available See Table 1
Contractual commitment See Table 1 See Table 1

Additional notes

Any central government department wishing to offshore data, or make use of a cloud service with data storage, processing or management offshore, needs agreement from Cabinet Office. The Office of the Government SIRO (OGSIRO) should be contacted for information (OGSIRO@cabinet-office.gsi.gov.uk).

Where personal data is to be processed in a cloud service then data protection legislation will apply. The ICO has published guidance on compliance with the Data Protection Act (DPA) in relation to using cloud services. The DPA requires that personal data “shall not be transferred to any country or territory outside the European Economic Area (EEA) unless that country or territory ensures an adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data.” There is a list of countries considered by the EU Commission to be adequate.

Understanding the legal jurisdiction(s) to which data within the service is subject to may be more complex than simply understanding the physical locations where data is stored, processed or accessed from. It also includes the legal base and operating locations of the service provider, the governing legislation of any contracts, terms of use or other agreement between consumers or suppliers and the provider. It is important for consuming organisations to consider this topic and to seek legal advice as necessary.

Consumers should consider the the implications of any rights the service provider will have relating to data stored within the service. Some usage agreements for cloud services may allow the service provider to make use of consumer data within their service for marketing or other purposes. Consumers should check whether any agreements with the service provider relating to use of their data by the service provider are acceptable to them and also not contrary to relevant legislation, such as the DPA.

2.2 Data centre security

The locations used to provide cloud services need physical protection against unauthorised access, tampering, theft or reconfiguration of systems used to deliver the service. Inadequate protections may result in the disclosure, alteration or loss of data.

Implementation

Objectives:

  • Access to those locations within the service that allow access to consumer data is protected.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Contractual commitment See Table 1 See Table 1
Independent validation of assertions A number of physical security standards with supporting certification mechanisms exist. These include:
- CSA CCM v3.0
- ISO/IEC 27001
- SSAE-16/SAS-70
Different physical security standards differ in terms of the levels of physical controls. The scope of the assessment must be relevant to those locations where consumer data can be accessed.

2.3 Data at rest protection

Consumer data should be protected when stored on any type of media or storage within a service to ensure that it is not accessible by local unauthorised parties. Without appropriate measures in place, data may be inadvertently disclosed on discarded, lost or stolen media.

Implementation

Objectives:

  • Storage media containing consumer data is protected from unauthorised access – this includes removable and fixed storage media.
Approach Description Guidance
Service provider assertion The service provider asserts that they control access to media and storage devices holding consumer data. Errors in handling of unencrypted media may expose consumer data.
Independent validation of assertions A number of standards are appropriate to validate procedures surrounding physical security of media with supporting certification mechanisms exist. These include:
- CSA CCM v3.0
- ISO/IEC 27001
- SSAE-16/SAS-70
Different physical security standards differ in terms of the levels of physical controls. The scope of the assessment must be relevant to those locations where consumer data can be accessed.
Assured components A product assessed to Foundation Grade configured and used in accordance with the appropriate Security Procedures can provide assured data at rest protection.
The service provider demonstrates that key management procedures are in place to prevent unauthorised access.
See Table 1

Additional notes

To support onboarding and offboarding processes it may be necessary for storage media to be transferred between the consumer and the service provider. If this is the case the storage media should be protected using one of the approaches above.

2.4 Data sanitisation

The process of provisioning, migrating and deprovisioning resources should not result in unauthorised access to consumer data being possible. Inadequate sanitisation of data could potentially result in:

  • Consumer data being retained by the service provider indefinitely
  • Consumer data being accessible to other consumers of the service as resources are reused
  • Consumer data being lost or disclosed on discarded, lost or stolen media.

Implementation

Objectives:

  • Service providers inform consumers how long it will be before consumer data (and any backups) is securely sanitised following the termination of the contract or exit from the service.
  • Service providers securely erase consumer data when resources are moved or reprovisioned, when the consumer leaves the service and upon request by the consumer.
  • Storage media which has held consumer data is sanitised or securely destroyed at the end of its usable lifetime.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Contractual commitment See Table 1 See Table 1
Independent validation of assertions See Table 1 Validation of assertions should be used to verify robust processes are in place to ensure all media is subject to a sanitisation process.
Independent testing of implementation Independent testers are used to demonstrate that consumers are not able to access remnants from other consumers when using the service.
Specialists with forensic skills and qualifications should be used.
Testing should demonstrate the sanitisation process ensures data cannot be recovered.
Assured components A Foundation Grade assured product is used to perform sanitisation of media before disposal. Products should have Foundation Grade certification against the relevant Data Destruction Security Characteristic available here.
Alternatively, a certified destruction service, such as thosecertified under the CESG Assured Service (Destruction) scheme, could be used.
The product must be used in accordance with the relevant Security Procedures.
Any constraints on the destruction service – such as the type of media it is approved to handle – should be appropriate to its use.

2.5 Equipment disposal

Once equipment used to deliver a service reaches the end of its useful life it is important it should be disposed of in a way that does not compromise the security of the service or consumer data stored in the service.

Implementation

Objectives:

  • All equipment potentially containing consumer data, credentials, or configuration information for the service is identified at the end of its life or prior to being recycled.
  • Any components containing sensitive data are sanitised, removed or destroyed as appropriate.
  • Accounts or credentials specific to redundant equipment are revoked to reduce their value to an attacker.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Contractual commitment See Table 1 See Table 1
Independent validation of assertions A number of security standards with supporting certification mechanisms exist which are relevant to the objectives. These include:
- ISO/IEC 27001
- CSA CCM v3.0
See Table 1
Assured components A certified destruction service, such as those certified under the CESG Assured Service (Destruction) scheme, could be used. Any constraints on the destruction service – such as the type of media it is approved to handle – should be appropriate to its use.

2.6 Physical resilience & availability

Services have varying levels of resilience, which will affect their ability to operate normally in the event of failures, incidents or attacks. A service without guarantees of availability may become unavailable, potentially for prolonged periods, with attendant business impacts.

Implementation

Objectives:

  • The service provider should clearly articulate the availability capabilities and commitments of the service, including their stated availability and their ability to recover from outages. The service provider should demonstrate to consumers how the solution is designed to be available.
Approach Description Guidance
Service provider assertion See Table 1 The service provider may provide historical evidence of the availability of the service. Consumers should evaluate the evidence and draw their own conclusions on whether the historical evidence, the service provider’s assertions and reputation of the service provider give them sufficient confidence.
Having no contractual commitment in place could mean there is no penalty for service providers in the case of an outage, or obligation for the service provider to promptly resolve the issue.
Contractual commitment See Table 1 Contractual commitments or Service Level Agreements (SLAs) provide a mechanism for compensation in event of outages, but outages will not be prevented if the service design is not appropriate.
Consideration of the suppliers technical resilience and historical performance is still recommended.
Independent validation of assertions See Table 1 Validation of claims should be used to verify the service provider has designed a service to satisfy the objectives.

Additional notes

Consumers should evaluate whether the service provider can meet the availability and resilience requirements of their application. Services procured with ‘best endeavours’ support should be considered to have no guaranteed support.

3.Separation between consumers

Separation should exist between different consumers of the service to prevent one malicious or compromised consumer from affecting the service or data of another.

Some of the important characteristics which affect the strength and implementation of the separation controls are:

  • The service model (e.g. IaaS, PaaS, SaaS) of the cloud service
  • The deployment model (e.g. public, private or community cloud) of the cloud service
  • The level of assurance available in the implementation of separation controls

An additional Separation Guide is in development which will explain the importance of the deployment and service models in understanding the strength of separation of cloud services.

Implementation

Objectives:

  • Service providers make available the following information to consumers:
    • The consumers the service is shared with. This should include whether the service is a public, private or community cloud service. For community cloud services, the groups which the community includes should be specified
    • The connectivity requirements or terms and conditions the consumers are bound by
    • How consumers are separated within the service
  • Separation between consumers of the service prevents one consumer affecting the confidentiality or integrity or another consumer’s data or service.
  • For IaaS services separation is enforced across the service, including at the compute, storage and networking layers.
  • For PaaS and SaaS services separation between consumers is enforced at all points within the service where the service is exposed to consumers.
  • Separation within the consumer service management interface is also an important consideration. This is covered separately as part of Principle 9.
Approach Description Guidance
Service provider assertion See Table 1 (!) See Table 1
Independent testing of implementation Penetration testing is used to determine whether one consumer can affect the service of another consumer.
Appropriately qualified penetration testers should be used. For example, individuals certified under the CHECK, CREST or Tiger schemes.
A well-scoped penetration test (and implementation of its recommendations) can give confidence that products and security controls tested have been configured in accordance with good practice and that there are no common or publicly known weaknesses or vulnerabilities in the tested components, at the time of the test.
Independent review of the scope of a penetration test, and review of the mitigations to issues it identified, will provide a higher degree of confidence that penetration testing successfully achieved the objectives set out above.
A penetration test will not normally assess products or components for previously unknown vulnerabilities.
Assurance in the service design See Table 1 See Table 1
Assured components Products assured to Foundation Grade are used to separate consumers within the service. Products should be certified against a relevant Security Characteristic. Server Virtualisation Security Characteristics are available, but there are no Security Characteristics available yet for virtualised separation of networking or storage environments. Therefore this approach should be used alongside other assurance mechanisms.

Notes on the above table:

  • Combinations of the above approaches can be complementary and provide greater confidence in the strength of separation within the service.
  • SaaS and PaaS services built upon IaaS offerings may inherit some of the separation properties of the underlying IaaS infrastructure. For further guidance on this concept see Layered Service Delivery.
  • Due to the bespoke nature of most PaaS and SaaS offerings it is unlikely that assured components will be available to provide separation within those services, meaning that bespoke assurance may be required in order for a PaaS or SaaS offering to claim it uses assured components.

Additional notes

The most important factors informing the level of assurance required in the separation of a service are likely to be the consumer’s intended use of the service and the deployment model of the service. The following advice may help inform the separation requirements of consumers:

  • For private cloud services only limited assurance in the separation of the service is likely to be necessary, as a single organisation should be able to have a good understanding of all of their applications for their cloud environment.
  • For community cloud services, where the community is trusted by the consumer, and the community members are known to practice a good level of hygiene (perhaps even bound by a code of practice), then it is envisaged that a well scoped penetration test is likely to be sufficient assurance for most consumers.
  • For public cloud services, consumers should consider the strength of separation required, given that other consumers of the service may be actively hostile towards them. In addition to penetration testing, it may be desirable to gain assurance in the design of the service, or to choose public cloud services which make use of assured components where these are available.

It is important to note that consumers have the ability to use a service securely or insecurely. Sometimes they are also able to provide additional protections on top of those that can be offered by the service provider. For example, if necessary, they could use their own encryption components to provide networking separation within an IaaS offering. The [Consumer Guide] provides recommendations on this topic.

4.Governance

The service provider should have a security governance framework that coordinates and directs their overall approach to the management of the service and information within it.

When procuring a cloud service it is important to ensure that the supplier has a suitable security governance framework in place for the service. Regardless of technical controls being deployed by the supplier, they will be fundamentally undermined if they cannot be operating in an effective risk management and governance regime. Successful implementation of governance is an enabler for ensuring that procedure, personnel, physical and technical controls remain effective through the lifetime of the service in response to changes in the service, changes in threat and technology developments.

Implementation

Objectives:

  • The service provider has a clearly identified, and named, board representative (or a person with the direct delegated authority of) who is responsible for the security of the cloud service. This is typically someone with the title Chief Security Officer, Chief Information Officer or Chief Technical Officer.
  • The service provider’s security governance framework is formally documented, as are policies governing key aspects of information security relating to the service.
  • Information security is incorporated into the service provider’s financial and operational risk reporting mechanisms for the service.
  • The service provider has processes in place to identify and ensure compliance with applicable legal and regulatory requirements relating to the service.
Approach Description Guidance
Service provider assertion See Table 1 (!) See Table 1
Independent validation of assertions A number of security standards with supporting certification mechanisms exist. These include:
- ISO/IEC 27001
- CSA CCM v3.0
See Table 1

5.Operational security

The service provider should have processes and procedures in place to ensure the operational security of the service.

The service will need to be operated and managed securely in order to impede, detect or prevent attacks against it. The following are important aspects of this principle:

  • Configuration and change management – ensuring that changes to the system do not unexpectedly alter security properties and have been properly tested and authorised
  • Vulnerability management – ensuring that security issues in constituent components are identified and mitigated
  • Protective monitoring – taking measures to detect attacks and unauthorised activity on the service
  • Incident management – ensuring the service can respond to incidents and recover a secure available service

Good operational security should not require complex, bureaucratic, time consuming or expensive processes. In conjunction with good development practices (see Principle 7) it is possible to combine agile and responsive development with appropriate security controls.

5.1 Configuration and change management

Good configuration management processes should ensure that knowledge of the assets which make up the service, along with their configuration and dependencies, are known and accurate. Good change management processes should ensure any changes to the service which could have an affect on its security are identified and managed. They should also lead to detection of unauthorised changes. In a service where change is not effectively managed, changes may introduce, or fail to fully mitigate security vulnerabilities in the service, without those responsible for the security of the service being aware.

Implementation

Objectives:

  • The status, location and configuration of service components (including hardware and software components) are tracked throughout their lifetime within the service.
  • Changes to the service are assessed for potential security impact. Changes are managed and tracked through to completion.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions A number of standards are appropriate to support configuration and change management processes in line with the objectives. These have their own supporting certification mechanisms. Appropriate standards include:
- CSA CCM v3.0
- ISO/IEC 27001
Good change and configuration management processes reduce (though do not eliminate) the chance of vulnerabilities being introduced in the configuration of a service.
Change and configuration management is closely tied to good governance. Without good governance of the service (see Principle 4 it is likely that change and configuration management practices will not be effective.

Additional notes

Although it is important for there to be effective change and configuration management of services, services with insufficiently agile change processes may expose their service to security risks for longer periods of time than those with robust prioritisation processes.

5.2 Vulnerability management

From time to time vulnerabilities will be discovered which, if left unmitigated, will pose an unacceptable risk to the service or information within the service. Therefore robust vulnerability management processes should exist for the service to identify, triage and mitigate vulnerabilities. Effective vulnerability management is fundamental in providing a secure service, services which do not have effective vulnerability management processes will quickly become vulnerable to attack leaving them at risk of exploitation using publicly known methods and tools.

Implementation

Objectives:

  • Potential new threats, vulnerabilities or exploitation techniques which could affect the service are assessed and corrective action is taken.
  • Relevant sources of information relating to threat, vulnerability and exploitation technique information relevant to the service are monitored by the service provider.
  • The severity of threats and vulnerabilities relevant to the service are considered within the context of the service and this information is used to prioritise implementation of mitigations.
  • Known vulnerabilities within the service are tracked until suitable mitigations have been deployed through a suitable change management process.
  • Service provider timescales for implementing mitigations to vulnerabilities found to be present within the service are made available to consumers.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions A number of standards are appropriate to support vulnerability management in line with the objectives. These have their own supporting certification mechanisms. Appropriate standards include:
- ISO/IEC 30111:2013
- CSA CCM v3.0
- ISO/IEC 27001
The different standards provide facility to support the objectives to differing extents.
No vulnerability management process can defend against unknown (‘zero day’) vulnerabilities.
Consumers are advised to seek services which support patching or vulnerability management within the timescales set out below.

Additional notes

Exploits for known vulnerabilities are now frequently widely available within hours or days of release. Services which mitigate and patch vulnerabilities in their services quickly have smaller windows of vulnerability. If there is evidence to suggest that a vulnerability is being actively exploited in the wild, service providers will need to act quickly to put mitigations in place to protect their consumers. If there is no evidence that the vulnerability is being actively exploited, then the following timescales should be considered minimum good practice:

  • ‘Critical’ patches deployed within 14 calendar days of a patch becoming available
  • ‘Important’ patches deployed within 30 calendar days of a patch becoming available
  • ‘Other’ patches deployed within 90 calendar days of a patch becoming available

‘Critical’, ‘Important’ and ‘Other’ are aligned to the following common vulnerability scoring systems:

  • National Vulnerability Database Vulnerability Severity Ratings, ‘High’, ‘Medium’ and ‘Low’ respectively (these in turn are aligned to CVSS scores as set out by NIST)
  • Microsoft’s Security Bulletin Severity Rating System ratings ‘Critical’, ‘Important’ and the two remaining levels (‘Moderate’ and ‘Low’) respectively.

Consumers are advised to understand whether service provider’s vulnerability management processes apply available patches within acceptable timescales.

Consumers should be aware that no service is likely to be free from vulnerabilities. Within most cloud services there are likely to be areas where a single vulnerability discovered in the service would break the separation protections within the service, making it possible for one malicious or compromised consumer to gain access to data or disrupt the service of another. Therefore the deployment model for the service (essentially, who it is shared with) will be an important consideration, as will the service provider’s ability to detect malicious activity and also quickly mitigate emergent vulnerabilities.

5.3 Protective monitoring

Effective protective monitoring allows a service provider to detect and respond to attempted and successful attacks, misuse and malfunction. A service which does not effectively monitor for attacks and misuse will be unlikely to detect attacks (both successful and unsuccessful) and will be unable to quickly respond to potential compromises of consumer environments and data.

Implementation

Objectives:

  • Events generated in service components required to support effective identification of suspicious activity are collected and fed into an analysis system.
  • Effective analysis systems are in place to identify and prioritise indications of potential malicious activity.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions A number of standards are appropriate to support protective monitoring in line with the objectives. These have their own supporting certification mechanisms. Appropriate standards include:
- CSA CCM v3.0
- ISO/IEC 27001
See Table 1

Additional notes

Services which do not collect relevant accounting and audit information are unlikely to detect and respond quickly and effectively to attacks, or attempted attacks. Where attacks are detected through other mechanisms, it will be difficult to identify the extent, duration and severity of compromise if relevant audit data is not available.

Services which collect accounting and audit information but do not have effective analysis of that information are unlikely to detect and respond quickly and effectively to attacks, or attempted attacks. Audit data which has been collected but not analysed may be found to be incomplete or inadequate when examined during investigation of an incident.

Service providers are only likely to be able to effectively monitor for the service they have designed and are managing. In IaaS and PaaS services, where consumers are running their own applications or software on top of the service, service providers are unlikely to be able to provide effective protective monitoring for the applications or software unless the consumer and service provider have worked together to design appropriate protective monitoring. More typically in these scenarios it is the consumer who will be responsible (and often best placed) to identify attacks against their applications or software e.g. through their own application monitoring.

5.4 Incident management

An incident management process allows a service provider to respond to a wide range of unexpected events that affect the delivery of the service to consumers. Unless carefully pre-planned incident management processes are in place, poor decisions are likely to be made when incidents do occur.

Good incident management minimises the impact to consumers of environmental, security and reliability issues with the service. These processes need not be complex or require large amounts of description, but a service which does not have effective processes in place may be more vulnerable to outages and security incidents. Delayed response to any incident is likely to increase its duration and impact to consumers.

Implementation

Objectives:

  • Incident management processes are in place for the service and are enacted in response to security incidents. Pre-defined processes are in place for responding to common types of incident and attack.
  • A defined process and contact route exists for reporting of security incidents by consumers and external entities
  • A definition of a security incident in the service is published to consumers, along with the triggers and timescales for sharing such incidents with service consumers
  • The content and format of security incident notifications for sharing information with consumers is published
  • The maximum timescales by which an incident will be investigated is published to consumers
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions A number of standards are appropriate to support protective monitoring in line with the objectives. These have their own supporting certification mechanisms. Appropriate standards include:
- ISO/IEC 27035:2011
- CSA CCM v3.0
- ISO/IEC 27001
See Table 1

Additional notes

Using services that can demonstrate robust, well tested and rehearsed incident management procedures, is likely to be desirable for departments publishing online services which may be the subject of significant (in terms of volume or capability) attack. Denial of service attacks against public facing infrastructure by ‘hacktivist’ groups and attacks by serious criminals for financial gain can be a particularly demanding test of incident response processes especially for consumers with a high availability requirement.

6.Personnel security

Service provider staff should be subject to personnel security screening and security education for their role.

Personnel within a cloud service provider with access to consumer data and systems need to be trustworthy. Service providers need to make clear how they screen and manage personnel within any privileged roles. Personnel in those roles should understand their responsibilities and receive regular security training. More thorough screening, supported by adequate training, reduces the likelihood of accidental or malicious compromise of consumer data by service provider personnel.

Implementation

Objectives:

  • Service provider staff that have access to the service (physically or logically) or potential ability to access consumer’s data or affect the service, are subjected to adequate personnel security screening for their role. As a minimum these checks include identity, unspent criminal convictions, and right to work checks.
Approach Description Guidance
Service provider assertion If personnel are checked against a recognised personnel security standard then this should be specified. Alternatively, service providers should describe the personnel security screening carried out on staff with access to consumer data or ability to affect the service of consumers. The different personnel security standards provide different levels of confidence in the trustworthiness of individuals. BS7858:2012 for individuals in privileged roles would meet the objective above.
Independent validation of assertions A number of standards are appropriate to support personnel security screening in line with the objectives. These have their own supporting certification mechanisms. Appropriate standards include:
- BS7858:2012
- SC clearance
As above

Additional notes

It is difficult to design systems to defend data against a skilled and motivated privileged user. Consumers should understand that privileged users within the service provider are likely to be able to gain access to their data or affect the reliability of their service.

Where service providers are unable to meet the objectives, consumers are advised to understand why that is the case and use that information within their risk management decision.

CPNI provides guidance on pre-employment screening.

7.Secure development

Services should be designed and developed to identify and mitigate threats to their security.

Services which are not designed securely may be vulnerable to security issues which could compromise consumer data, cause loss of service or enable other malicious activity.

Implementation

Objectives:

  • New and evolving threats are regularly reviewed. Development tasks are initiated to improve and reinforce the security of the service in line with changing threats.
  • Software development is carried out in line with industry good practice regarding secure design, coding, testing and deployment.
  • Software configuration management processes are in place to ensure the integrity of the solution through development, testing and deployment.
Approach Description Guidance
Service provider assertion A number of security standards exist which service providers could claim conformance with in support of their assertions of compliance with the above objectives. These include:
- Safecode ‘Fundamental Practices for Secure Software Development’
- ISO/IEC 27034.
See Table 1
Independent validation of assertions A number of security standards with supporting certification mechanisms exist which could be used to demonstrate conformance with the above objectives. These include:
- CESG CPA Build Standard
- ISO/IEC 27034
- ISO/IEC 27001
- CSA CCM v3.0
See Table 1

Additional notes

Secure development does not mean that all development must be done in-house, in secure facilities or by highly vetted personnel. Whilst these approaches may be appropriate for specialised components, it will often be better to choose mature, independently supported, off the shelf components. Security is something that should be considered throughout the design and development of the service. For example, during development of new features, potential attacks that would be brought to bear against those features should be considered. Effective mitigations should be designed to address these potential attacks, whilst finding the right balance of security, cost and needs of the users.

Service providers should ensure that where they purchase services, software components or development services from third parties that the secure development practices of the supplier match their requirements through their supply chain process (see below).

8.Supply chain security

The service provider should ensure that its supply chain satisfactorily supports all of the security principles that the service claims to implement.

Cloud services often rely upon third party products and services. Those third parties can have an impact on the overall security of the services. If this principle is not implemented then it is possible that supply chain compromise can undermine the security of the service and affect the implementation of other security principles.

Implementation

Objectives:

  • The service provider informs consumers how much of their information is shared with, or accessible by, third party suppliers and their supply chains.
  • The service provider’s procurement processes ensure that security requirements on third party suppliers and delivery partners are explicitly documented. These security requirements should include relevant requirements from the Cloud Security Principles.
  • The risks to the service from third party suppliers and delivery partners are regularly assessed by the service provider and appropriate security controls implemented.
  • The service provider monitors the conformance of their suppliers with security requirements and initiates remedial action where necessary.
  • The service provider’s procurement processes ensure that all assets relating to the service are returned, removed (or appropriately destroyed) and accesses to the service terminated.
  • The service provider has the necessary information and processes to verify that hardware and software used in the service is genuine and has not been obviously tampered with.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions A number of security standards with supporting certification mechanisms exist. These include:
- ISO/IEC 27001
- ISO/PAS 28000:2007
See Table 1

Additional notes

Layered service delivery

Cloud service providers can deliver services using underlying IaaS or PaaS services from another provider. This is a valuable opportunity to reuse assurance work, but it is important in this situation to identify which of the two parties is responsible for implementing the different security principles.

These layered services may result in a more complex description of the service separation. For example a public sector-only email hosting service (community SaaS) could be built on a public IaaS offering.

In the majority of cases, applications requiring a high degree of assurance should ensure that assurance is provided right through the underlying stack of services. It will be difficult to gain a high degree of confidence if building on foundations which you do not also have a high degree of confidence in.

9.Secure consumer management

Consumers should be provided with the tools required to help them securely manage their service.

Management interfaces and procedures are a vital security barrier in preventing unauthorised people accessing and altering consumers’ resources, applications and data.

The following aspects of secure consumer management are considered below:

  • Authentication of consumers to management interfaces and within support channels
  • Separation and access control within management interfaces

9.1 Authentication of consumers to management interfaces and within support channels

In order to maintain a secure service, consumers need to be securely authenticated before being able to conduct management activities, report faults or request changes to the service. These activities may be conducted through a service management web portal, or through other support channels, such as telephone or email and are likely to facilitate functions such as provisioning new service elements, managing user accounts and managing consumer data. It is important that service providers ensure any management requests which could have a security impact are performed over secure and authenticated channels. If consumers were not strongly authenticated then an attacker posing as them could perform privileged actions undermining the security of their service or data.

Implementation

Objective:

  • Only authorised individuals from the consumer organisation are able to authenticate to and access management interfaces for the service.

Approach:

  • Principle 10 should be used to assess the risks of different approaches to meet this objective. Since privileged accounts have can have a greater value to attackers it will normally be appropriate to implement stronger controls than for standard users of the service.

Objective:

  • Only authorised individuals from the consumer organisation are able to perform actions affecting the consumer’s service through support channels.
Approach Description Guidance
Service provider assertion See Table 1 See Table 1
Independent validation of assertions See Table 1 See Table 1
Independent testing of implementation Social engineering techniques can be used to test the effectiveness of consumer administrator authentication in support channels. This form of testing will exercise authentication mechanisms in support channels at a point in time.
No recognised standards exist to assess the quality of social engineering testing.

9.2 Separation and access control within management interfaces

Many cloud services are managed via web applications or APIs. These interfaces are a key part of the service’s security. If consumers are not adequately separated within management interfaces then one consumer may be able to affect the service, or modify data belonging to another.

Consumers’ privileged administrative accounts are likely to have access to large volumes of data. Constraining the permissions required by individual users to those absolutely necessary can help to limit the damage that could be caused by a malicious user, compromised credentials or device. Role-based access control provides a mechanism to achieve this. It is likely to be a particularly important capability for consumers managing larger deployments.

Exposing management interfaces to less accessible networks (e.g. community rather than public networks) makes it more difficult for attackers to reach and attack them, as they would first need to gain access to the systems of one of the consumers or networks. Guidance on assessing the risks of exposing all interfaces to different networks is provided under Principle 11.

Implementation

Objectives:

  • Consumers can only manage their own service, and cannot access, modify or otherwise affect the service of other consumers via management tools and interfaces.
  • The service supports consumers in implementing the ‘principle of least privilege’ through providing the ability to constrain permissions given to consumer administrators.
  • The service provider informs consumers which networks management interfaces are exposed to and what functionality is available via those interfaces.
Approach Description Guidance
Service provider assertion See Table 1 See Principle 11 for guidance on the risks of exposing the management interface to different networks.
Independent validation of assertions See Table 1 See Table 1
Independent testing of implementation Penetration testing is used to assess the strength of separation within the consumer management interface.
Appropriately qualified penetration testers should be used. For example, individuals certified under the CHECK, CREST or Tiger schemes.
A well-scoped penetration test (and implementation of its recommendations) can give confidence that management interfaces prevent one consumer from managing the service of another consumer. It will also normally detect common or publically known weaknesses or vulnerabilities in the tested components, at the time of the test.
A penetration test will not normally assess products or components for previously unknown vulnerabilities.

10.Identity and authentication

Consumer and service provider access to all service interfaces should be constrained to authenticated and authorised individuals.

All cloud services will have some requirement to identify and authenticate users. Weak authentication or access control may allow unauthorised changes to a consumer’s service, theft or modification of data or denial of service.

It is also important that authentication occurs over secure channels. Use of insecure channels such as email, HTTP or telephone can be more vulnerable to interception or social engineering attacks.

Implementation

Objective:

  • Identity and authentication controls provide an appropriate level of confidence that a user has authorisation to access a specific interface.
Approach Description Guidance
User name and two factor authentication Users authenticate using a username and hardware or software token or ‘out of band’ challenge (e.g. SMS). There may be vulnerabilities in the authentication scheme or implementation which allow unauthorised access.
Standardised or assured authentication schemes give independent confidence the design and implementation is robust.
User name and TLS client certificate The service supports authentication using a TLS 1.2 client certificate, issued by the service or by the consumer organisation. Security is reliant on consumer end user devices to securely manage certificates, there will be a need for processes to revoke lost or compromised credentials.
There may be vulnerabilities in the authentication scheme or implementation which allow unauthorised access.
Authentication federation The service supports federating to another authentication scheme, such as a corporate directory, or an OAuth or SAML provider. Federated identity solutions acquire the risks of the source identity solution. Compromise of the source identity solution will give access to any resources protected by federated identities.
Limited access over dedicated link, enterprise or community network Access to a service is limited to a protected network such as PSN, a corporate network with physical or cryptographic protection, or a dedicated physical or encrypted tunnel. The opportunity to exploit stolen credentials is reduced if the interface is only accessible over a private or community network.
Users of the network, or attackers who gain access can still reach the service, so some authentication is still likely to be required.
The larger the network, the greater the potential attack population and the stronger the authentication requirements, very large networks should normally be treated as though they are public.
Even if access is to be granted to all legitimate users of a network, it may still be appropriate to identify users for audit purposes.
Username and password Authentication is via basic username and password with no capability for consumers to enforce the use of strong password selection. (!) Without the ability to enforce selection of strong passwords or passphrases, users may select passwords which are vulnerable to brute force attack.
(!) Usernames and passwords are susceptible to compromise through phishing or malware on end user devices. The lack of a second factor of authentication means they can be used later by an attacker to gain access to the service.
Credentials passed over unencrypted channels are at particular risk of interception on insecure networks, such as public wi-fi hotspots.
Username and strong password/passphrase enforcement Authentication is with username and password/passphrase with the service supporting enforcement of strong password selection by users.
(!) Usernames and passwords are susceptible to compromise through phishing or malware on end user devices. The lack of a second factor of authentication means they can be used later by an attacker to gain access to the service.
Credentials passed over unencrypted channels are at particular risk of interception on insecure networks, such as public wi-fi hotspots.
Service provider assertion – other See Table 1 See Table 1

Additional notes

The risks associated with a compromised user account will vary depending on the privileges and access that user has been granted. Highly privileged accounts, with access to large volumes of consumer data, or the ability to alter service configuration and security are of high potential value to an attacker. Weak authentication of these privileged accounts is normally a higher risk than that of regular service users.

Very long passwords, complexity requirements or change frequencies can increase the chances of users handling password badly, by storing them insecurely, sharing or reusing them. Alternative protections (such as two-factor authentication) are often a better choice than requiring very long passwords.

Active monitoring and protection can be a valuable authentication risk mitigation. The detection and prevention of brute force attacks through locking, blocking or rate limiting attempts provides useful mitigation and detection.

Providing risk-based triggers (such as asking for re-authentication for significant actions, or demanding additional authentication information from unknown locations or devices can also help to detect and mitigate the threat from compromised credentials.

Limiting the lifetime of login sessions is also good practice, but this should not be at the expense of usability. Rendering a service difficult to use through short timeouts can encourage users to use less secure alternatives.

11.External interface protection

All external or less trusted interfaces of the service should be identified and have appropriate protections to defend against attacks through them.

Interfaces exposed to consumers or outsiders, which are not sufficiently robust, could be subverted by attackers in order to gain access to the service or data within it. If the interfaces exposed include private interfaces, such as management interfaces, then the impact may be more significant.

Consumers can use different models to connect to cloud services which expose their enterprise systems to varying levels of risk. The risks of some of the potential approaches are considered in the Consumer Guide (coming soon).

Implementation

Objectives:

  • The service provider informs consumers which networks the service is accessible from and what interfaces are exposed to those networks
  • The service provider has protections in place to prevent unauthorised access to the service via any exposed interfaces by consumers or outsiders
  • The service provider publishes guidance to consumers on how to safely connect to the service whilst minimising risk to the consumer’s systems
Approach Description Guidance
None Objectives not met The risks relating to exposing the service to different networks are described in the table below.
Penetration test The service provider provides evidence that external interfaces have been tested and that all interfaces exposed from the service are robust and necessary for the operation of the service.
Appropriately qualified penetration testers should be used. For example, individuals certified under the CHECK, CREST or Tiger schemes.
A well-scoped penetration test (and implementation of its recommendations) can give confidence that products and security controls tested have been configured in accordance with good practice and that there are no common or publically known weaknesses or vulnerabilities in the tested components, at the time of the test.
A penetration test will not normally assess products or components for previously unknown vulnerabilities.
Assurance in the design of the service See Table 1 See Table 1
Network which the cloud service is accessible from Risk associated
Internet Since the service can be accessed from any other internet connected device it means that attackers can launch their attacks at the service from anywhere. Internet-connected services therefore need to have strong authentication and access control measures in place.
Since connectivity to the service is not via a protected network, then all responsibility for authentication and encryption needs to be provided by the service itself.
Community network Some cloud services, particularly community cloud services, may connect directly to a private community network, such as the PSN or via a protected tunnel onto the community network. This model supports easier data sharing within the community.
If the cloud service is dedicated for the community, and only accessible via the community network, then the service is likely to be less exposed to remote attackers. However, to support remote access, the consuming organisations or the community would need to put in place a remote access solution for their users.

Authentication relating to external interface protection

Connections to a service, whether from end users or other services may need users to identify themselves so that decisions can be made on what information they are permitted to access.

Implementation

Objective:

  • Services can determine the identity of connecting services and users to a level of confidence appropriate for the data or function being accessed.

Approach:

  • Principle 10 identifies possible approaches to meeting identification and authentication requirements.

Additional notes

Services can protect their data by limiting the attacker’s opportunity to connect to it, by providing the service only to a limited set of networks, locations or devices. Internet accessible services, particularly those which will accept connections from any location, are more exposed to attackers, so having high confidence in the strength of authentication and access control will be particularly important. For internet-connected services, consumers can reduce the risks associated with username and password authentication by implementing stronger authentication mechanisms. For more information see Principle 10.

Cloud services which are only exposed to a trusted community are much harder for attackers to access, as they would typically need to have already compromised one of the consumers of the service in order to gain access to the service. Community cloud services without direct internet connectivity are therefore likely to be preferable to services with internet connections for higher risk applications.

Finally, it is important that consumers consider the way in which they connect their enterprise systems to the cloud service. The Consumer Guide (coming soon) discusses this topic in more detail.

12.Secure service administration

The methods used by the service provider’s administrators to manage the operational service should be designed to mitigate any risk of exploitation that could undermine the security of the service.

The security of a cloud service is closely tied to the security of the service provider’s administration systems. Access to service administration systems gives an attacker high levels of privilege and the ability to affect the security of the service. Therefore the design, implementation and management of administration systems should reflect their higher value to an attacker.

A service administration network is a specialised form of enterprise network. There are a wide range of options for how this can be designed, delivered, managed and secured. It is expected that standard enterprise good practice be followed in the design and operation of these systems, but at a level reflecting their higher value. The service management systems are likely to have the most privileged access to the internals of the service. Compromise of them would have significant impact, including the means to bypass security controls and steal or manipulate large volumes of data.

If the service management model is not known, then it should be assumed that the high risk ‘direct service management’ model described below is used.

Implementation

Objectives:

  • End user devices used for administration are enterprise managed assets and are securely configured. CESG’s End User Device Security Guidance provides recommended good practice for configuration of a range of different end user device platforms which can be used to inform the configuration of these devices.
  • The model used for service management (see table below) is made known to consumers.
Approach Description Guidance
Service provider assertion See Table 1 The risks associated with the specified service management model should be considered.
Independent validation of assertions The assertions of the service provider, along with the service management model in use, are validated through a recognised audit scheme. The include:
- ISO/IEC 27001
- CSA CCM v3.0
The risks associated with the specified service management model should be considered.

The following table describes different typical service management models, and their associated risks:

Management Model Description Risks associated with this model
Dedicated devices on a segregated network Dedicated devices for service management purposes are used to manage the service from a segregated management network.
The devices are used solely for service management, and not for general purpose use, such as email and web browsing.
Using this approach, the management devices and segregated network is difficult to attack.
This approach may also help support personnel security measures for higher security systems. For example, where the service provider wishes to demonstrate that only SC cleared staff have access to system administration functions.
Dedicated devices for community service management Devices are dedicated to managing services for a single community (e.g. UK public sector). The management network is segregated from all other networks.
The devices are used solely for service management, and not for general purpose use, such as email and web browsing.
When managing multiple services there is a risk that a more vulnerable service could be compromised and used as a staging platform to attack the management network. Managing services with similar security properties will help reduce this risk.
This approach may also help support personnel security measures for higher security systems. For example, where the service provider wishes to demonstrate that only SC cleared staff have access to system administration functions.
Dedicated devices for multiple community service management Devices are dedicated to service management, but are used to manage multiple services across multiple communities of users.
The devices are used solely for service management, and not for general purpose use, such as email and web browsing.
In this model the devices themselves remain difficult targets to attack, but the larger and wider ranging scope of the management network may make it more exposed to attacks.
Service management via bastion hosts This model, also known as “browse up”, is where a service is managed using devices from a less trusted network (such as a corporate business network), but only by authorised management staff. Those staff have access to specific management hosts, known as bastions, from which all management actions on the service are conducted. Corporate systems tend to process a wide range of content types and are more vulnerable to attack using typical techniques.
Bastion hosts provide some protection against threats from the corporate networks, but attackers with access to corporate devices used by service administrators are likely to still be able to access the service management environment as if they were legitimate administrators. Malware capable of performing session hijacking is becoming increasingly common, so the risks associated with this model are increasing.
Direct service management The service is managed directly from devices which are also used for normal business use (web browsing, viewing external email, etc.) In this model, there is little protecting the service from unauthorised access to management interfaces. Services managed in this way are at a significant risk of compromise.

Additional notes

The End User Device Security Guidance recommends the use of assured data in transit protection and assured data at rest protection. Use of assured security technologies is particularly important for management systems given the significant impact of them being compromised.

Principle 10 provides guidance on identity and access controls. Strong authentication for access to service management functions is particularly important. In addition to providing strong identity and authentication, it is good practice for privileged administrative accounts to be different to an administrator’s ‘regular’ account for non-privileged work. This reduces the exposure of privileged accounts and reduces their risk of compromise.

13.Audit information provision to consumers

Consumers should be provided with the audit records they need to monitor access to their service and the data held within it.

The type of audit information available to consumers will have a direct impact on their ability to detect and respond to inappropriate or malicious usage of their service or data within reasonable timescales.

Implementation

The information necessary for customers to audit usage of their service will vary depending on the nature of the service being provided.

Objective:

  • The service provider makes consumers aware of the audit information that will be provided to them, how and when it will be made available to them, the format of the data, and the retention period associated with it.
Approach Description Guidance
None The service provider does not provide audit information to consumers Failure to provide audit information prevents consumers from identifying misuse of their service and data.
Depending on the nature of the data in question, a lack of audit information could result in legal or regulatory sanction.
Data made available The service provider makes available specific audit data available to consumers. The timetable, method, format and retention period of the data is specified. Consumers should consider whether the audit data provided by the service provider is adequate to support their needs.
The provision of audit information does not in itself provide any protection to the consumer. The information will require analysis to uncover evidence of compromise or misuse.
Data made available by negotiation The service provider offers consumers limited audit information as a result of negotiation. As above.

Additional notes

Audit data is of limited value unless it is used as part of an effective monitoring regime. Good monitoring requires a good understanding of the expected service usage. When considering third party analysis services, consider what support the third party provider would need to deliver an insightful monitoring service.

Consumers should consider whether they require audit records to be held to specific standards or be suitable for specific circumstances (e.g. such as being legally admissible in a UK court).

14.Secure use of the service by the consumer

Consumers have certain responsibilities when using a cloud service in order for their use of it to remain secure, and for their data to be adequately protected.

The security of cloud services and the data held within them can be undermined by poor use of the service by consumers. The extent of the responsibility on the consumer for secure use of the service will vary depending on the deployment models of the cloud service, specific features of an individual service and the scenario in which the consumers intend to the use the service. IaaS and PaaS offerings are likely to require the consumer to be responsible for significant aspects of the security of the service. These responsibilities are covered in the Consumer Guide (coming soon).

End user devices used access to the service

As well as risks to the cloud service and consumer applications and data within it, consumers should consider the risks relating to their enterprise networks and end user devices used to access the service. Depending on how the consumer is using the cloud service, it may be accessible to a range of end user populations and devices.

For some applications it may be appropriate (indeed required) to allow citizen owned devices to connect to the service via a public web interface. However users from the consumer’s organisation (e.g. case workers in a government department accessing citizen data) may require the use of enterprise issued and managed devices with an appropriate configuration to provide sufficient security.

Approach Description Guidance
Corporate/enterprise devices The service is accessed from devices under the direct control of the consuming organisation. A single compromised device would have access to any data, functionality or credentials accessible to authorised users of that device.
The End User Device Security Guidance provides risk management and configuration guidance for a range of platforms for processing OFFICIAL data.
Partner devices The service is accessible from devices over which the consuming organisation has some understanding and/or control over. For example, via contractual clauses or via conformance with an agreed security requirements. A single compromised device would have access to any data, functionality or credentials accessible to authorised users of that device.
The compliance mechanism is being relied upon to transit security requirements. If it is not well designed it will be ineffective.
Unknown devices The service is accessible from devices of unknown status (e.g. citizen/public devices). It is impossible for consumers to be able to identify compromised devices, so the service should be designed to assume the devices are hostile.
Citizens can be directed towww.getsafeonline.org for practical advice on securing their devices.
Be Sociable, Share!