This article was downloaded by: [Laurentian University]On: 09 October 2014, At: 19:57Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,37-41 Mortimer Street, London W1T 3JH, UK

Information Security Journal: A Global PerspectivePublication details, including instructions for authors and subscription information:http://www.tandfonline.com/loi/uiss20

Security and Control in the CloudKlaus Julisch a & Michael Hall ba IBM Research GmbH , Rüschlikon, Switzerlandb Forbes Sinclair , Madrid, SpainPublished online: 19 Nov 2010.

To cite this article: Klaus Julisch & Michael Hall (2010) Security and Control in the Cloud, Information Security Journal: AGlobal Perspective, 19:6, 299-309, DOI: 10.1080/19393555.2010.514654

To link to this article: http://dx.doi.org/10.1080/19393555.2010.514654

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the “Content”) containedin the publications on our platform. However, Taylor & Francis, our agents, and our licensors make norepresentations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of theContent. Any opinions and views expressed in this publication are the opinions and views of the authors, andare not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon andshould be independently verified with primary sources of information. Taylor and Francis shall not be liable forany losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoeveror howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use ofthe Content.

This article may be used for research, teaching, and private study purposes. Any substantial or systematicreproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in anyform to anyone is expressly forbidden. Terms & Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

Information Security Journal: A Global Perspective, 19:299–309, 2010Copyright © Taylor & Francis Group, LLCISSN: 1939-3555 print / 1939-3547 onlineDOI: 10.1080/19393555.2010.514654

Security and Control in the CloudKlaus Julisch1 and MichaelHall21IBM Research GmbH,Rüschlikon, Switzerland2Forbes Sinclair, Madrid, Spain

ABSTRACT Cloud computing is a new IT delivery paradigm that offerscomputing resources as on-demand services over the Internet. Like all formsof outsourcing, cloud computing raises serious concerns about the security ofthe data assets that are outsourced to providers of cloud services. To addressthese security concerns, we show how today’s generation of information secu-rity management systems (ISMSs), as specified in the ISO/IEC 27001:2005,must be extended to address the transfer of security controls into cloud envi-ronments. The resulting virtual ISMS is a standards-compliant managementapproach for developing a sound control environment while supporting thevarious modalities of cloud computing.

This article addresses chief security and/or information officers of cloudclient and cloud provider organizations. Cloud clients will benefit from ourexposition of how to manage risk when corporate assets are outsourced tocloud providers. Providers of cloud services will learn what processes and con-trols they can offer in order to provide superior security that differentiates theirofferings in the market.

KEYWORDS cloud computing, Security, ISMS, IS027001

Address correspondence toKlaus Julisch, IBM Research GmbH,Säumerstrasse 4, 8803 Rüschlikon,Switzerland. E-mail: kju@zurich.ibm.com

1. INTRODUCTION TO CLOUDCOMPUTING

Cloud computing is a new formula of delivering computing resources, not anew technology. Specifically, cloud computing provides computing resourcesas on-demand services that are hosted remotely, accessed over the Internet,and generally billed on a per-use basis (Chong & Carraro, 2006; Catteddu& Hogben, 2009; Datamonitor, 2009). There are three types of computingresources that have been provided in the cloud:

• Software as a Service (SaaS): This is application software that is hostedby third parties and provided as a service over the Internet. Examples ofSaaS include Google Docs, Salesforce.com, and Web mail services such ashotmail.com.

• Platform as a Service (PaaS): These are platforms consisting of devel-opment tools and a runtime environment. Cloud customers use thedevelopment tools to program their own applications against theApplication Programming Interface (API) of the runtime environment.

299

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

• Subsequently, the applications are deployed tothe runtime environment where they are exe-cuted. Examples of PaaS include Microsoft Azure,Force.com, and Google Apps.

• Infrastructure as a Service (IaaS): These are low-level computing resources such as virtual machinesor storage which are provided on-demand overthe Internet. Examples include Amazon’s ElasticCompute Cloud (Amazon EC2) and Carbonite’sbackup service.

Many additional examples of SaaS, PaaS, and IaaS ven-dors and offerings can be found in the cloud taxonomyby OpenCrowd (2009).

Cloud computing is a type of outsourcing. As such,it is similar to classic information technology (IT) out-sourcing, where a client transfers the custody of parts ofits information system to a service provider. The serviceprovider assumes responsibility for the client’s infor-mation system and operates it in accordance with thecontractual terms that the client and provider agreedupon (Cullen & Willcocks, 2003; Gewald & Helbig,2006). These contractual terms, which define the coop-eration between outsourcing clients and providers, arecalled Service Level Agreements, or SLAs.

The defining characteristic of classic IT outsourcing(compared to cloud computing) is that the outsourcingprovider offers a customized and unique service that doesexactly what the client requests at the client’s terms, ina well-controlled and discrete environment. Cloud com-puting, by contrast, offers highly standardized servicesthat are provided cheaply by serving multiple cus-tomers from a shared IT infrastructure (Brunette &Mogull, 2009; Datamonitor, 2009). Of course, cloudservices offer some degree of customizability, but cloudservices are basically commoditized “one-size-fits-all”offerings. Further, the use of a shared IT infrastruc-ture across clients destroys any clients’ ability to affordthe same level of control known from classic IToutsourcing.

Cloud computing is a sizeable and rapidly growingmarket. According to International Data Corporation(IDC), a leading provider of the market intelligenceand advisory services, the worldwide market for cloudcomputing was approximately $17.4 billion in 2009and is estimated to reach $44.2 billion by 2013(Gens, Mahowald, & Villars, 2009). This rapid mar-ket growth is driven by the following benefits of cloudcomputing:

• Low cost: Typical enterprises dedicate 50–70% oftheir IT budgets to routine system maintenancetasks (Datamonitor, 2009; States & Lindquist, 2008).This overhead can be reduced by outsourcing non-strategic services to cloud providers, which use theirscale economies and experience curve effects (Hax& Majluf, 1982) to provide commoditized servicesmore cheaply (Reeves, 2009A).

• On demand: In a recent Goldman Sachs (2009) sur-vey, 51% of respondents saw the key benefit ofcloud computing in the ability to elastically scale tomeet peak workloads and future demand. A relatedbenefit is the usage-based pricing model where cus-tomers only pay for compute resources consumed(Datamonitor, 2009; Reeves, 2009A).

• Short time-to-market: It is faster to procurecloud services than develop the same functionalityin-house. The ability to deliver results fast is anotherbenefit of cloud computing (Roth, 2008).

Inhibitors to the adoption of cloud computinginclude security, business continuity and control con-cerns, reliability concerns, fears of vendor lock-in,migration costs, reduced customizability, integrationdifficulties, as well as uncertainties about the businesscase and the legal implications (Catteddu & Hogben,2009; Datamonitor, 2009; Roth, 2008; Reeves, 2009A).This article addresses the security and control concernsand shows how information security management sys-tems (ISMSs) can be extended to overcome them.

2. STATE OF THE ART IN CLOUDSECURITY

Section 1 defined cloud computing as a new ITdelivery model. This definition by itself does not implyany new security challenges. For example, an organiza-tion could task its internal IT departments to deliverall computing resources as cloud services. From a secu-rity and control point of view, this is very much akinto classic in-house IT delivery. New security challengesarise, however, in the public cloud (Brunette & Mogull,2009; Reeves, 2009A) where a cloud provider offerscloud services to any (paying) client. Some of theseclients may be internal business units of the cloudprovider, but most clients will be external legal entities,for example, other companies. The defining character-istic of public clouds is that SLAs are used to stipulatethe legal accountability between cloud providers and

K. Julisch and M. Hall 300

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

their clients. This article focuses on security in pub-lic clouds, and the term “cloud” is henceforth usedsynonymously with “public cloud.”

In using (public) cloud services, a Cloud Client (CC)places select organizational assets in the custody of aCloud Provider (CP). In doing so, the CC cedes con-trol over these assets to the CP, and yet the CC retainsaccountability for the security and regulatory compli-ance of these assets. This creates risks, which havemade some enterprises hesitant to sign up for cloudservices (Catteddu & Hogben, 2009). CPs understandthis problem and have responded by offering SAS-70,ISO-27001, or other security certifications to “proof”the quality of their risk-mitigating controls (Salesforce,2008; Schadler, 2009; Amazon, 2010). Further, someCPs such as Intacct.com or Google offer Service LevelAgreements to facilitate a risk transfer (Intacct, 2010;Google, 2010A; Amazon, 2008). All of these schemesare important, but taken in isolation, they have impor-tant shortcomings:

1. Formal Registrar Security Certification audits havethe problem of being infrequent (typically everythree years). The CC therefore receives infrequent“snap shots” of the CP’s control environment andhas to trust that everything is “OK” between cer-tifications. This setup is increasingly unacceptableto many CCs who, at any moment, may be heldaccountable by their stakeholders for the securityand compliance of their own information systems.

2. It is important to understand that “SAS 70 certifica-tion” is not a stamp of approval (even though it issometimes marketed that way). This is because SAS70 is a framework for conducting audits. It does notcertify any specific controls or control objectives.Rather, each CP defines for itself the controls andcontrol objectives that it wants to be certified for(AICPA, 1992). These controls and control objec-tives are documented in the SAS 70 audit report.Prospective clients should always consult this report(rather than relying on the “SAS 70 compliant”label) to determine if the controls of a CP meet theirrequirements (Brunette & Mogull, 2009). SSAE 16and ISAE 3402, the successor standards of SAS 70,improve on these issues by requiring the CP to morefully disclose its system and control environment(Thompson, Griffin, & Bialick, 2010).

3. The SLAs offered by CPs tend to be conser-vative in the sense that they offer only small

penalty payments and their commitments arefocused on availability rather than data integrityor confidentiality (Amazon, 2009; Google, 2010A;Maiwald, 2009; Mather, Kumaraswamy, & Latif,2009). Further, cloud-SLAs are typically standard-ized and unable to meet the specific security require-ments of individual customers (Goertzel et al.,2009).

4. SLAs are an intrinsically imperfect risk treatmentstrategy. In theory, they transfer the risk to theCP. In practice, however, the CPs’ responsibilityends with a (frequently small) penalty payment andthe potential loss of the customer(s) affected bya control failure. The CC, by contrast, remainsaccountable towards its own customers, regulators,and directors for any failures, and there are fewlimits to the cost that such accountability can entail.

While generally insufficient by themselves, SLAs,certifications, and audits are important building blocksof cloud security. In this article, we show how theseand other risk treatment methods can be combinedinto a single consistent framework, called the virtualISMS. An ISMS is the set of processes, policies, andmechanisms that an organization uses to establish,implement, operate, monitor, and improve informa-tion security (ISO, 2005A). A virtual ISMS extends thisconcept so it becomes suitable for virtual enterpriseswhere IT services are partially outsourced to CPs.

This article is targeted at CIOs and CSOs of cloudclient and cloud provider organizations. CCs will findthat the virtual ISMS offers a structured way for man-aging risk and protecting corporate assets that areoutsourced to CPs. This benefit is shared by CPs. As CPsuse shared and standardized infrastructures to delivercloud services cheaply, they cannot offer customizedprovisions to individual clients. Using the virtual ISMSto manage security in a standardized and scalable way isof real benefit to CPs. In addition, CPs will draw valuefrom our discussion of ways to improve security andthereby differentiate their offering in the marketplace.

3. THE “CONVENTIONAL” ISMSThe ISO/IEC Standard 27001:2005 defines an

ISMS as the set of processes, policies, and mecha-nisms that are used to establish, implement, operate,monitor, review, maintain, and improve informationsecurity (ISO, 2005A). The standard further prescribes

301 Security and Control in the Cloud

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

that ISMSs follow the Plan-Do-Check-Act (PDCA) pro-cess, or Deming Cycle. The PDCA cycle acknowledgesthat information security is not a product that onceinstalled, makes a system secure. Rather, informa-tion security is achieved by a process of continuousimprovement and adjustment to the inevitably chang-ing threats, technologies, and business processes. Thefour steps of the PDCA process are as follows:

• The “Plan” step defines the scope of what is tobe protected; it further performs a risk assessmentand defines the security policies and the controlobjectives that are to be achieved.

• The “Do” step implements and operates controls toachieve the stated control objectives and to complywith the stated security policies.

• The “Check” step monitors and assesses the achievedinformation security relative to the stated controlobjectives and security policies.

• The “Act” step derives improvements and new secu-rity requirements from the results of the check step.This provides the input for the next iteration of thePDCA cycle.

In a “conventional” ISMS, the IT assets (i.e., hardware,infrastructure, software, and data) and the security man-agement of these assets are owned and controlled by thesame organization. This changes in cloud computing.

4. RESPONSIBILITY FOR CONTROLS INCLOUD COMPUTING

A prerequisite for understanding cloud security isto understand the difference between responsibility andaccountability. Accountability is “ultimate responsibil-ity”; it is the state of being “where the buck stops.”Responsibility is an obligation to do something accord-ing to certain parameters. For example, a manager whodelegates a task to a subordinate makes this subordi-nate responsible for the task but remains accountablein case something goes wrong. In other words, themanager can delegate responsibility but not account-ability.

While cloud computing is a major paradigm shift,it does not change the assignment of accountability.Companies are accountable for their assets, includ-ing any assets that were outsourced to CPs. Cloudcomputing only transfers the responsibility to per-form compute task according to certain parameters,

but accountability remains with the CC. The centralchallenge therefore becomes how a CC can defineand monitor the security controls for which the CP isresponsible.

The decision of whether the CC or the CP is respon-sible for a given control depends on three factors:

1. The cloud model (SaaS, IaaS, or PaaS) chosen;2. The extent to which the CC is allowed to configure

the CP’s controls;3. Legislations, which may dictate the assignment of

responsibilities and thereby overrides the previoustwo factors.

Before exploring these factors, it is important to notethat the CC is always responsible for securing the com-puting resources it retains. In fact, all other securitycontrols become void if the CC fails to deploy controlsto protect the servers, notebooks, and networks that ituses to access the CP. This “retained IT” is shown at thetop of Figure 1, and it is entirely the CC’s responsibilityto implement suitable controls to prevent client-sidethreats such as the Web browser vulnerabilities, theftof authentication credentials, virus attacks, or data theftby rogue employees.

The assignment of responsibilities is less clear cutfor the data and software assets that physically resideon the CP’s site and infrastructure. As previously men-tioned, the cloud model plays an important role in thiscase. The general rule is that the party that manages

FIGURE 1 Responsibility for controls in the IaaS, PaaS, andSaaS cloud models.

K. Julisch and M. Hall 302

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

and controls an asset is also responsible for provid-ing suitable security controls to protect it. Figure 1uses grey shading to show who manages and controlsa given asset. Consequently, we obtain the following(still preliminary) responsibilities:

• In all three cloud models, the CP manages, and con-trols the infrastructure, which comprises the servers,networks, electricity, human resources, and site ser-vices. As such, the CP is responsible to implementand operate suitable infrastructure controls such asemployee training, physical site security, networkfirewalls, and others. Infrastructure controls are offundamental importance. For example, if physicalaccess control is weak and people can steal entireservers then it does not matter that network access tothese servers is protected by firewalls and encryption(Archer et al., 2010).

• In IaaS, the CC manages and controls all softwarethat runs on the CP’s infrastructure. As such, theCC is responsible for all software security controls,including software patching, anti-virus protection,application access control, user identity manage-ment, and others. If, for example, an attacker suc-cessfully guessed an application password, then thisreveals a control failure by the CC to properlyprotect its assets.

• In PaaS, the CC manages and controls the applica-tion software, while the CP manages and controlsthe operating system, middleware, and infrastructure.Accordingly, the CC is responsible for all applica-tion controls, while the CP is responsible for the ITgeneral controls (Bayuk, 2004).

• In SaaS, the CP manages and controls all layersof the software stack and is accordingly responsiblefor their security. In other words SaaS providers areresponsible for implementing suitable security con-trols in their infrastructure, operating systems andmiddleware, as well as application software. If, forexample, unpatched application software is compro-mised by attackers then the CP failed to meet itsresponsibilities.

This assignment of responsibilities still needs tobe modulated by a second factor, namely the extentto which the CP allows the CC to configure thecontrols it provides. This factor is most easily under-stood in the case of SaaS: While SaaS providers

implement the entire software stack, they do not nec-essarily configure all of it. Specifically, many SaaSproviders let their CCs configure their own accountsand password policies. This partially moves the respon-sibility for these controls back to the CC: The CCbecomes responsible for configuring the appropri-ate security policy, and the CP remains responsiblefor enforcing this policy via its controls. This con-figuration option is illustrated by the “C” interfacein Figure 1. In practice, it is quite common forCPs to provide a configuration interface “C” becauseit allows them to partially “delegate responsibilityback” to the CC. Examples of configuration interfacesinclude:

• Amazon’s Elastic Compute Cloud (EC2) allowsthe CC to configure the network firewall thatcontrols access to CC’s resources on EC2 (Amazon,2009).

• Customers of Amazon’s Simple Storage Service (S3)can configure the access rights that control who canaccess their data on the S3 cloud (Amazon, 2009).

• Google Apps offers a SAML-based Single Sign-On,where the CC authenticates users and then sendsa token to Google Apps to vouch for the users’identities (Google, 2010B).

In summary, the assignment of responsibilities ismore complex in cloud computing because it dependson the cloud model as well as the extent to whichCCs can configure the controls provided by CPs. Thisbrings us back to the topic of this article – the virtualISMS – whose purpose we can now define as (a) sup-porting the CC and the CP in negotiating and definingtheir respective responsibilities and (b) enabling theCC to monitor and audit the effectiveness of thecontrols that are under the CP’s responsibility.

5. THE VIRTUAL ISMSThe virtual ISMS follows the PDCA-cycle defined

in the ISO 27001 standard, but the specifics of eachstep are different. These differences affect both, whatis done and by whom it is done. Table 1 summarizesthe PDCA-cycle of the virtual ISMS. The planning andcontrol steps are the most complex and involved stepsof the virtual ISMS. The remainder of this section istherefore focused on these two steps.

303 Security and Control in the Cloud

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

TABLE 1 The PDCA-cycle of the Virtual ISMS

Cloud Client (CC) Cloud Provider (CP)

Plan Identify all data and software assets as well as theirvalues.

Assist the CC by providing information about thesecurity controls implemented.

Derive the control objectives that have to be metand the controls that have to be implemented toprotect these assets.

Negotiate responsibilities, prices, SLAs, andcontracts.

Identify the service that is to be outsourced anduse the rules of responsibility (Section 4) todefine the controls and control objectives thatthe CP is responsible for.

Review the controls implemented by potential CPsand assess their suitability.

Select the most suitable cloud provider andcontract its services.

Do Work with the CP to migrate the contracted serviceto the CP’s infrastructure. Aside from transferringdata and software, this also includes the so-called“on-boarding,” that is, the creation of useraccounts for CC’s employees on the CP’sinfrastructure.

Work with the CC to migrate the dedicated service.Operate the IT infrastructure and provide the

contracted service to the CC.

Check Use the assurance provided by the CP to verify thecorrect, secure, and compliant operation of theCP’s controls and to detect SLA violations.

Provide the CC with the assurance that wascontractually agreed in the “Plan” step.

Forms of assurance include third-party audits, thepermission for the CC to audit the CP, detailedsecurity incident reports, as well as real-timeaudit logs and activity monitoring.

Act Decide if any contractual changes are necessary.Such changes may affect provider-side controls,SLAs, price, legal terms, or any other aspect ofthe contract.

Negotiate with the CC any contractual changesthey want to perform.

Collaborate with the CC in improving the controlenvironment.

Assess if the contract should be terminated.Inform the CP about desired changes, e.g.

improvements in the control environment, andnegotiate the specifics of their implementation.

5.1. PlanningThe first activity in planning is that the CC estab-

lishes its control objectives. To do so, the CC identifiesits corporate assets (data or software) and their val-ues. The asset value is the monetary impact that a lossof availability, confidentiality, or integrity has on theclient’s business. From the asset values, the CC canthen determine its protection requirements. These pro-tection requirements are documented in the form ofcontrol objectives as well as specific controls that haveto be implemented. The CC also must define its assur-ance requirements, that is, the evidence that it requiresto be collected during the “Check” step to proof thatthe control objectives are met. So far, this is no dif-ferent from the risk-based planning step performed inconventional ISMSs.

At this point, the CC must identify the cloud ser-vice it wants to procure from CPs. Using the rules ofresponsibility derived in section 4, the CC can thenidentify the controls and control objective that the CPis responsible for. The CC can further determine theassurance information that the CP is responsible forproviding. Taken together, these responsibilities definethe requirements catalog that the CC imposes on the CP.

Using the requirements catalog, the CC can assesspotential CPs with respect to their ability to satisfyit. This clearly presupposes that CPs disclose theirsecurity controls to determine if they meet the CC’srequirements. Unfortunately, most CPs are not veryopen with regards to their security controls (Reeves,2009B; Archer et al., 2010). Obviously, CPs that keeptheir security controls secret destroy the CC’s ability

K. Julisch and M. Hall 304

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

to perform a sound risk treatment. Accordingly, suchCPs should only be considered for low-valued assets,or when strong SLAs provide a clear risk transfer.

Throughout the planning phase, the CP’s role isto assist the CC in obtaining required information.Further, the CP negotiates with the CC to determineresponsibilities, legal clauses, and prices. Even thoughthe CC is in charge of the planning process, it is impor-tant for the CC to remain sensitive to the CP’s con-straints. These constraints arise from the fact that someparts of the CP’s IT infrastructure are shared among all itsclients. So, for example, if one client requests a firewallconfiguration that blocks all IP addresses but its own,then the CP simply cannot accommodate this requestbecause it would block all its other clients. Similarly, aSaaS provider cannot accommodate individual clients’requests for particular anti-virus products because theCP will run the same anti-virus product across its entireinfrastructure.

The final step in the planning phase is to selectthe most suitable CP and to contract its services. Thecontract should address at a minimum the followingpoints:

• A list of controls implemented by the CP. To fur-ther clarify roles and responsibilities, it is advisable todocument the controls the CC is responsible for andthe controls where responsibility is shared (becausethe CC configures them and the CP implementsthem). Section 6 further discusses the selection ofcontrols that the CP has to implement.

• A description of the assurance that the CP providesduring the “Check” step. Possible forms of assur-ance include third-party audits, the permission forthe CC to audit the CP, detailed security incidentreports, as well as real-time audit logs and activitymonitoring.

• Service level agreements and penalties for their non-fulfillment. As part of the SLAs, it is essential todefine the metrics and procedures that are used todecide if SLAs are fulfilled.

• Legal clauses addressing the use of iterative outsourc-ing, that is, the rules according to which the CP mayuse other third-party cloud providers to implementits services.

• A description of the joint security governance pro-cess; we recommend that the virtual ISMS presentedhere is used for security governance.

• Legal clauses addressing the terms and conditions ofcontract termination. This specifically must describehow software and data assets are migrated from theCP to another hosting environment.

5.2. CheckAt the time of this writing, the state of the art in

monitoring CPs is still immature. As such, the “Check”step offers significant potential for CPs to create differ-entiated value for their clients. CPs who want to doso must address several challenges. First, CCs want tomonitor their CPs so they can demonstrate their owncompliance, drive continuous improvement in the“Act” step, and enforce penalty payments for SLA vio-lations. CPs will find opportunities for improvementin all three areas, but the most imminent improvementpotential exists in the first two areas. The third area,that is, SLAs, sill faces many technical challenges thatwill take time to overcome.

On the challenges associated with security SLAs: SLAviolations concerning confidentiality or integrity aredifficult to ascertain, and even then, the question arisesof whether the CC or the CP was responsible in the senseof section 4. Obviously, CPs do not want to pay penaltiesfor failures that were the CC’s fault. Consequently,thorough forensic investigations of security failures arerequired to ascertain responsibility. Will CCs and CPsagree to participate in such investigations, and whathappens if the forensic results are not conclusive? Afurther hurdle is that CPs would assume very large risksif they were to offer SLAs that compensated CCs fortheir losses from potential security incidents. Therefore,CPs choose to offer SLAs that compensate CCs forservices not provided (e.g., by refunding hours of up-time not delivered). This is a controllable risk to theCP but hardly covers the true cost to CCs. In summary,these are difficult challenges and it will take years beforesecurity SLAs become practicable.

With any meaningful risk transfer using SLA beingyears away, CPs would be well-advised to supporttheir clients’ risk management processes. The simpletruth is that CCs have to manage their risks, and CPswhose secrecy policies (Reeves, 2009B; Archer et al.,2010) hinder such risk management will see their cus-tomers go elsewhere. CPs consequently must offertransparency with respect to the controls they imple-ment and the effectiveness of these controls. CPs who

305 Security and Control in the Cloud

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

accept this fact need to address the following issuesrelated to monitoring:

• CPs must decide what type of monitoring to provide.Options are: real-time event monitoring, intermit-tent status reporting, or audits.

• For audits, CPs must decide if they accept tobe audited by their clients or if they will onlysubject themselves to audits by independent thirdparties.

• For real-time monitoring, CPs must take precautionsthat they do not leak events that pertain to otherclients. As all clients are served from the same sharedcloud infrastructure, there is a risk that one clientreceives event information that pertains to otherclients.

• CPs must decide what to measure and report. In gen-eral, CCs are interested in knowing whether theCP’s controls are operational and effective. A controlis operational if it is “up and running”; it is effective ifit achieves its control objective.

• In particular for manual controls, CPs should pro-vide measurements to show that they are operational.For example, if a guard is to inspect the server roomonce an hour, it is advisable to measure how fre-quently the guard uses her badge to access the serverroom. This frequency measures whether or not thecontrol is operational. For automated controls, suchmeasurements of being “up and running” are lesscogent as automated controls typically run flawlesslyas result of being automated.

• In general, CPs cannot measure if controls are effec-tive at achieving their objectives. For example, wedo not know if a virus scanner really preempted allviruses. In other cases, the effectiveness of controlscan be measured. For example, one can measure thenumber of accounts with root privileges; if this num-ber is too large, it is indicative of ineffective man-agement controls. Wherever possible, CPs shouldmeasure and report the effectiveness of their con-trols. In addition, they should report control failureswhenever they are detected. It is disputed whetherCCs should be informed about all incidents on theCP’s shared platform or if they should only learnabout the incidents that arguably affected their assets.

In summary, a genuine risk transfer using SLAs isnot possible with today’s technologies. From the CC’spoint of view, this makes it all the more important that

CPs offer sound monitoring and reporting capabilities.Using these capabilities, CCs can perform their ownrisk management and thereby satisfy their auditors andstakeholders.

6. STATEMENT OF APPLICABILITYThe Statement of Applicability (SOA) is a specific

requirement of the ISO 27001 and documents whichcontrols have been chosen by the risk assessment pro-cess and which ones have been justifiably excluded.The controls in a SOA are chosen in order to protectboth, the data assets owned by an organization andany data assets that are under the custody of that orga-nization. In this section, we take the perspective of aCP who asks: “What controls do I have to implementin my own infrastructure in order to protect my clients’assets?” The answer to this question depends on thecloud model (IaaS, PaaS, or SaaS) adopted.

Table 2 shows part of the CP’s statement of appli-cability for protecting its clients’ assets. A completeSOA would show for each control cited in Annex Aof the ISO 27001 (ISO, 2005A) if and how it has to beimplemented. Table 2 is less detailed and only discussescontrol groups rather than individual controls. Alsodifferent from a complete SOA, Table 2 only offersgeneral guidance on control exclusions because depen-dent on the specifics of an environment, the CP mayhave to implement additional controls.

In general, CPs are best advised to implementall controls necessary to meet the expectations andrequirements of their most demanding customers. Thisrecommendation makes sense because the shared deliv-ery platform used by CPs makes it prohibitively expen-sive to tailor special controls to individual clients.Therefore, CPs either have to accommodate the secu-rity needs of their most demanding customers or risklosing them.

7. SUMMARY AND CONCLUSIONCloud computing is a new IT delivery paradigm that

offers computing resources as on-demand services overthe Internet. Cloud computing has become a largeand growing market because of its value propositionsof low costs, increased flexibility, and shorter time-to-market. Cloud providers deliver those benefits byserving multiple clients from a single highly standard-ized and shared infrastructure. As a consequence, most

K. Julisch and M. Hall 306

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

TABLE 2 Statement of Applicability for Protecting Outsourced Assets

Clause Control Group Responsibility of the CP

A.5, Security PolicyA.6, Organization of

Information Security

Control A.5.1Controls A.6.1 & A.6.2

In PaaS and SaaS, the CP is responsible for providingthese controls; in IaaS, the CP is responsible for allcontrols except A.10.4 and A.10.9.

A.7, Asset Management Controls A.7.1 & A.7.2 Several controls (e.g., 10.6, Network SecurityManagement) are implemented by the CP but they areconfigured in collaboration with the CC.

A.8, Human ResourceSecurity

Controls A.8.1 – A.8.3 As many of these controls are manual, it is advisable toprovide measures of their effectiveness and

A.9, Physical andEnvironmental Security

Controls A.9.1 & A.9.2 operational performance to CCs.

A.10, Communication andOperations Management

Controls A.10.1 – A.10.10

A.11, Access Control A.11.1 BusinessRequirements

The CC defines the access control policy for its assets.

A.11.2 User AccessManagement

The CP is responsible for controlling all access byadministrative users.

A.11.3 User Responsibilities For all other users, the CP has to provide the controls,but the CC configures them;

A.11.4 Network AccessControl

In PaaS and SaaS, the CP is responsible for providingnetwork access control;

In IaaS the CP provides the controls, but the CCconfigures them (see the examples at the end ofSection 4).

A.11.5 Operating SystemAccess Control

In PaaS and SaaS, the CP is responsible for providing OSaccess control;

In IaaS, OS access control is entirely the responsibility ofthe CC.

A.11.6 Application andInformation AccessControl

In SaaS, the CP provides the controls, but the userconfigures them;

In PaaS and IaaS, application level access control isentirely the responsibility of the CC.

A.11.7 Mobile Computingand Teleworking

The CP is responsible for these controls if it uses mobilecomputing or teleworking in the delivery of its cloudservices. Otherwise, this control does not apply.

A.12, Information SystemsAcquisition Developmentand Maintenance

A.12.1 SecurityRequirements ofInformation Security

In IaaS, PaaS, and SaaS, the CP is responsible forimplementing this control in its operations.

A.12.2 Correct Processing inApplications

In SaaS, the CP is responsible;In PaaS and IaaS, the CC has to implement these controls.

A.12.3 CryptographicControls

In SaaS and PaaS the CP should provide these controls;In IaaS, the CP may provide these controls as an added

services to CCs.A.12.4 Security of System

FilesIn PaaS and SaaS, the CP is generally responsible for

these controls;In IaaS it is the CC’s responsibility.

A.12.5 Security inDevelopment & SupportProcesses

In IaaS, the CC is responsible for this control;In SaaS, the CP is responsible;In PaaS the CP and CC are responsible for controlling

their respective parts of the application.A.12.6 Technical

VulnerabilityManagement

In IaaS, PaaS, and SaaS, the CP is responsible forvulnerability mgmt on the infrastructure, platform,and application level, respectively.

(Continued)

307 Security and Control in the Cloud

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

TABLE 2 (Continued)

Clause Control Group Responsibility of the CP

A.13 Information SecurityIncident Management

Controls A.13.1 & A.13.2 In IaaS, PaaS, and SaaS, the CP is responsible for incidentmanagement on the infrastructure, platform, andapplication level, respectively.

A.14 Business ContinuityManagement

A.14.1 Information SecurityAspects of BusinessContinuity Management

In IaaS, PaaS, and SaaS, this control is the responsibilityof the CP.

A.15 Compliance Controls A.15.1 – A.15.3 In IaaS, PaaS, and SaaS, this is a joint responsibility wherethe CC generally identifies the applicable laws andregulations and the CP implements the controls toassure compliance with them.

cloud providers cannot offer customized provisions forindividual clients because doing so would break theirfinancial model which is built on economies of scale.

This article addresses the security and control con-cerns that CIOs and CSOs have about cloud comput-ing. In particular, in highly regulated industries such asfinance, government, or pharmaceutical, it is paramountfor CIOs and CSOs to establish and maintain a soundand ISO 27001 compliant information security controlenvironment. This article demonstrates how this canbe achieved in the face of the continued migration oflegacy services to cloud computing.

When choosing cloud computing, clients remainaccountable for their corporate assets, but they selec-tively place some of their assets into the custody ofcloud providers. With custody of assets come cer-tain responsibilities for protecting those assets, and wedescribed the rules that determine whether the cloudprovider, the cloud client, or both jointly are responsi-ble for implementing the controls that protect theseassets. We further introduced the virtual ISMS as astandards-compliant management process that cloudclients and providers should follow to manage risksand protect corporate assets. We finally presented ahigh-level Statement of Applicability that should ben-efit cloud providers in their effort to identify controlsthat are applicable to their environments.

A key message of this article for cloud providers isthat they have to reveal their controls to clients andprospective clients; moreover, cloud providers have toallow clients to monitor and audit their controls aspart of the virtual ISMS process. This is vital becausecloud providers are unwilling and incapable to acceptthe client’s risk via rigorous SLAs. Therefore, unlesscloud providers want to limit themselves to uncritical

low-value compute services, they must provide clientswith the information they need to perform their ownrisk management. That means describing the availablecontrols and allowing clients to monitor them.

For cloud clients, a key message is that they haveto be realistic about what they purchase with cloudservices, namely agility at a competitive price. Whatthey do not purchase is a risk transfer. It is there-fore of paramount importance that cloud clients followa rigorous risk management process (as enabled bythe virtual ISMS) and that they insist on obtain-ing the necessary information from their cloudproviders.

ACKNOWLEDGMENTSThe research leading to these results has received

funding from the European Community’s SeventhFramework Program (FP7/2007–2013) under grantagreement No. FP7-216917.

REFERENCESAICPA. (1992). Reports on the processing of transactions by service orga-

nizations (SAS 70). American Institute of Certified Public Accountants,Inc.

Amazon. (2008). Amazon EC2 service level agreement. Available from:http://aws.amazon.com/ec2-sla/

Amazon. (2009). Amazon Web services: Overview of security processes.Available from: http://aws.amazon.com/security

Amazon. (2010). AWS completes SAS70 Type II audit. Available from:http://aws.amazon.com/about-aws/whats-new/2009/11/11/aws-completes-sas70-type-ii-audit/

Archer, J., Boehme, A., Cullinane, D., Kurtz, P., Puhlmann, N., andReavis, J. (2010). Top threats to Cloud computing V1.0. Cloud SecurityAlliance.

Bayuk, J. L. (2004). Stepping through the IS audit: What to expect, howto prepare (2nd edition). ISACA.

K. Julisch and M. Hall 308

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4

Brunette, G. and Mogull, R. (2009). Security guidance for critical areas offocus in cloud computing V2.1. Cloud Security Alliance.

Carr, N. (2008). The big switch: Rewiring the world, from Edison toGoogle. New York: Norton & Company.

Catteddu, D. and Hogben, G. (2009). Cloud computing: Benefits, risks,and recommendations for information security. Heraklion, Greece:ENISA.

Chong, F. and Carraro, G. (2006). Architecture strategies for catching thelong tail. Microsoft Corporation.

Cullen S. and Willcocks, L. P. (2003). Intelligent IT outsourcing: Eightbuilding blocks to success. Butterworth-Heinemann.

Datamonitor (2009). Can cloud computing help enterprises weather theeconomic storm? Gauging the disruptive potential of a new model ofIT consumption. Report DMTC2267, Datamonitor.

Gens, F., Mahowald, R. P., and Villars, R. L. (2009). IDC cloud computing2010 – an IDC update. Doc #TB20090929. IDC.

Gewald, H. and Helbig, K. (2006). A governance model for man-aging outsourcing partnerships. Proceedings of the 39th HawaiiInternational Conference on System Sciences, 4–7 January 2006.

Goertzel, K. M., Schmidt, H. L. M., Winograd, T., and Mosteller, K. (2009).Cloud computing security. Booz Allen Hamilton.

Goldman Sachs. (2009). Independent insight: IT spending survey. NewYork: Goldman Sachs.

Google. (2010A). Google Apps service level agreement. Available from:http://www.google.com/apps/intl/en/terms/sla.html

Google. (2010B). SAML single sign-on (SSO) service for GoogleApps. Available from: http://code.google.com/intl/ja/googleapps/domain/sso/saml_reference_implementation.html

Hax, A. C. and Majluf, N. S. (1982). Competitive cost dynamics: Theexperience curve. Interfaces, 12, 50–61.

Intacct. (2010). Intacct buy with confidence. Available from: http://us.intacct.com/why_intacct/buy_with_confidence.php

ISO/IEC. (2005A). Information technology – security techniques – infor-mation security management systems – requirements. ISO/IEC,27001.

ISO/IEC. (2005B). Information technology – security techniques – infor-mation security management systems – guidelines. ISO/IEC, 27002.

Maiwald, E. (2009). The issue of SaaS security. Burton Group’s Securityand Risk Management Blog. Available from: http://srmsblog.burton-group.com/2009/09/the-issue-of-saas-security.html

Mather, T., Kumaraswamy, S., and Latif, S. (2009). Cloud security andprivacy: An enterprise perspective on risks and compliance (theory inpractice). CA: O’Reilly Media.

OpenCrowd. (2009). Cloud computing – cloud landscape. Available from:http://www.opencrowd.com/views/cloud.php

Reeves, D. (2009A, April). Cloud computing: Transforming IT. BurtonGroup.

Reeves, D. (2009B, July 8). Cloud infrastructure secrecy: A competitiveadvantage or disadvantage. Burton Group Blog.

Roth, C. (2008). SaaS implementation survey: Where, when, and how touse SaaS. Burton Group.

Salesforce. (2008). Saleforce.com is first major SaaS vendor to achieveISO 27001 certification. Available from: https://www.salesforce.com/uk/company/news-press/press-releases/2008/05/080507-2.jsp

Schadler, T. (2009). Should your email live in the Cloud? A comparativecost analysis. Forrester Research.

States, L. and Lindquist, D. (2008). IBM’s perspective on cloud computing.Presentation, October.

Thompson, C., Griffin, J., and Bialick, T. (2010). New Level of Trust andTransparency. Pricewasterhousecoopers.

BIOGRAPHIESKlaus Julisch has a Ph.D. in Computer Science fromthe University of Dortmund, Germany, and morethan 10 years of experience in information security.In 1999, he joined the IBM Research Lab in Zurich,Switzerland, where he developed new security alert cor-relation techniques for IBM’s commercial divisions.From 2005 to 2007, Dr. Julisch was on assignment tothe Research Headquarters in Yorktown, where he wasinstrumental in launching IBM’s secure ID card busi-ness. Since 2008, Dr. Julisch has been leading a majorresearch project aimed at improving the security andcompliance of cloud computing.

Michael Hall is the Practice Development Partnerat Forbes Sinclair, an international risk managementadvisory company with offices in Madrid, Spain, andTampa, Florida. Forbes Sinclair’s projects focus on theimplementation of ISO/IEC 27001, ISO/IEC 20000,BSI 25999, ISO 14001, PAS 99, IT risk analysis, ITcontingency and business continuity planning, train-ing, and application reviews. Hall is one of the initialfounders of Forbes Sinclair in 1998 and is presentlyresponsible for business development and the over-all leadership of work teams in information securityand audit projects. Aside from his activities withForbes Sinclair, Hall is an ISO/IEC 27001, ISO/IEC20000, BSI 25999, ISO 9001 instructor for the BritishStandards Institution. He is the author/editor of theRisk Management Knowledgebase, an electronic encyclo-pedia of Standards BSI 27001, BSI 20000, Basel IIand Legal Compliance. Hall’s professional certifica-tions include CISSP (Certified Information SystemsSecurity Professional) and British Standards InstituteRegistered Auditor in the ISO/IEC 27001, ISO/IEC20000, BSI 25999, ISO/IEC 9001, ISO 14000. He alsoholds BS Advanced Auditing Skills Certificates.

309 Security and Control in the Cloud

Dow

nloa

ded

by [

Lau

rent

ian

Uni

vers

ity]

at 1

9:57

09

Oct

ober

201

4