Rejected ISO/IEC 27002 control on cloud computing

Suggested text for a new control on cloud computing

Back in February 2011, I proposed to incorporate a new information security control on cloud computing into ISO/IEC 27002 which was being revised by the committee at the time.

See what you make of the donor text I provided in New Zealand's submission to ISO/IEC JTC1/SC27 ...

----------------------------------

Control objective

To identify and mitigate the information security risks associated with cloud computing.

Implementation guidance

The organization should analyze the information security risks associated with its intended use of cloud computing and specify appropriate risk treatments, normally including specific information security controls such as those outlined below, as part of the process of determining its requirements for cloud services. The following information security controls are not meant to be comprehensive, but suggest typical information security aspects to be taken into account when implementing cloud computing:

a) Selection of cloud service providers: individual cloud service providers may have quite different attitudes and policies towards information security, so the organization’s information security requirements should be taken into account as part of the supplier selection process both specifically (e.g. specifying the information security design as part of the invitation to tender) and generally (e.g. specifying that the providers should have an information security management system certified compliant with ISO/IEC 27001). The organization’s information security control requirements may have to be specified contractually if there is a commercial relationship between the parties, and if not the risks may be substantial. 

b) Technical architecture: the cloud computing architecture (e.g. public, private or hybrid clouds) should be determined as this is likely to affect both the information security risks and the control options available. Security and ownership boundaries and interfaces should be clarified.

c) Security design: the system architecture and design specifications should specify the information security controls necessary to address the identified risks, whether this is documented as a discrete security design specification, or integrated into other system design specifications.

d) Authentication of users, systems and services: authentication controls must be designed to work properly in an essentially untrustworthy shared network and computing environment, normally requiring the use of strong cryptographically-based authentication techniques.

e) Confidentiality controls: suitable logical access controls must be incorporated in order to protect both the data and the cloud services from inappropriate and/or unauthorized access. The design must take account of privileged functions and rôles used to administer, manage and control cloud services, databases, data sets and data files, interfaces, security controls etc., many of which are likely to be within the domain of the cloud and network service providers rather than the user organization. Data encryption or anonymization may be necessary. Access controls must also adequately segregate data belonging to different organizations sharing the same clouds. The right to control access is normally determined by ownership, so ownership of data and cloud services, equipment etc. should be clearly identified.

f) Interfacing: cloud computing may not be appropriate for all the IT systems and processes in an organization, for example if the associated information security risks cannot be sufficiently mitigated, or if there are no suitable cloud services available. Therefore it is likely that information will pass across interfaces between non-cloud and cloud-based IT systems, and possibly between distinct clouds in some architectures. Information security risks associated with the interfaces should be determined and suitable controls specified e.g. applying authentication controls and data integrity checks on both sides of an interface.

h) Availability: while the distributed, geographically dispersed nature of cloud computing may appear to reduce the risks associated with physical security incidents at specific locations, this is by no means certain as there may be critical nodes, servers and network links within or associated with the cloud. Controls such as resilience and reliability, backups, redundancy and failover measures and incident management procedures should be specified and incorporated into the design, and where appropriate agreed with the cloud service providers, in order to achieve sufficient availability. Availability of the cloud services may also be an issue, for example if a service provider pulls out of the market or ceases trading – this is basically the same issue as with all suppliers.  If cloud services are critical for the organization’s operations, business continuity arrangements are probably required.

i) Compliance and assurance: if the organization is subject to information security compliance obligations (such as privacy, governance and other information security-related laws), these may have implications on the cloud services and service providers. Furthermore, although the organization may specify its information security requirements on cloud service providers, compliance or assurance measures (such as security tests, reviews and audits) may be justified in order to ensure that the obligations are being fulfilled. Extended access may be necessary to obtain forensic evidence following information security incidents (e.g. privileged access to system security logs and audit trails in the cloud). Legal and jurisdictional aspects of the arrangements with cloud service providers must be addressed during the contracting/procurement process in order to forestall possible problems later (such as the service provider unilaterally withdrawing or changing the service or excluding the organization, taking control of or deleting or changing the organization’s data, denying responsibility for or failing to notify the organization about information security incidents, failing to license essential intellectual property etc.).

Other information

Cloud computing including SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service), enables convenient, on-demand, network access to a shared pool of configurable computing resources (networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Service providers are able to offer specialist applications to multiple customers on distributed cloud platforms. Offsetting the advantages, cloud computing creates novel information security risks concerning the confidentiality, integrity, availability, control and ownership of information assets, particularly where cloud services are provided by independent and often physically remote organizations through the Internet. 

The business case for adopting cloud services should incorporate information security aspects. Strong information security controls can support the business requirements and enable the organization to reap the benefits of cloud services, but the costs of specifying, providing, using, managing and maintaining the controls must be taken into account in order to avoid them being under-funded and hence inadequate in practice. 

----------------------------------

In the event, the ISO/IEC JTC1/SC27 working group responsible for the standard rejected the proposal, declining to cover cloud computing explicitly in ISO/IEC 27002.  Admittedly, other SC27 projects on the drawing board at the time were destined to produce separate cloud computing security standards, and there was a bit of a bun-fight between the proponents of various approaches. 

As eventually published at the end of last year, ISO/IEC 27002:2013 barely mentions cloud computing as such, apart from a throwaway line casually tagged-on to the end of 15.1.3 "Information and communication technology supply chain as addressed here includes cloud computing services."  

Yes, that's it. Cloud computing security dismissed as a mere example of an ICT supply chain security concern.

Personally, I think SC 27 missed a golden opportunity to at least outline some of the key infosec risks and recommend a few baseline controls for cloud computing, perhaps a cut-down, wordsmithed, committee-approved version of the text I provided but rather more than those 13 blink-and-you'll-miss-em words.

Things have moved on apace since I wrote the suggested control text three years ago. If I was writing it again today I would probably change a few things here and there. This is a perennial problem with developing standards in such a dynamic context, one that highlights the often glacial pace of international standards bodies. The world doesn't stand still for ISO/IEC!

I'm looking forward to the ISO27k cloud computing security standards.  When they eventually emerge, I trust the wait will prove worthwhile.

OK, that concludes my miniseries of bloggings about suggested controls that didn't make it into the 2013 versions of ISO/IEC 27001 and 27002. 

6th April update: I've just been reading through the comments on the Committee Draft of ISO/IEC 27017 - an ISO27k cloud computing security standard.  Although ~100 pages is a lot of feedback on a CD standard, roughly two-thirds of the comments have been accepted, implying that the project is moving along nicely.  I really should check whether the CD takes account of the issues noted above.  So much to do, so little time ...

PS  I also proposed new or changed security controls for:

• SCADA/ICS (industrial control systems)
• The computer suite (mostly physical controls)
• SDLC (software development life cycle) and
• BCM (business continuity management)