This article was downloaded by: [Laurentian University]

On: 09 October 2014, At: 19:57

Publisher: Taylor & Francis
Informa 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 Perspective

Publication details, including instructions for authors and subscription information:
http://www.tandfonline.com/loi/uiss20

Security and Control in the Cloud

a

Klaus Julisch & Michael Hall

a

IBM Research GmbH , Rschlikon, Switzerland

Forbes Sinclair , Madrid, Spain

Published online: 19 Nov 2010.

To cite this article: Klaus Julisch & Michael Hall (2010) Security and Control in the Cloud, Information Security Journal: A
Global 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) contained
in the publications on our platform. However, Taylor & Francis, our agents, and our licensors make no
representations or warranties whatsoever as to the accuracy, completeness, or suitability for any purpose of the
Content. Any opinions and views expressed in this publication are the opinions and views of the authors, and
are not the views of or endorsed by Taylor & Francis. The accuracy of the Content should not be relied upon and
should be independently verified with primary sources of information. Taylor and Francis shall not be liable for
any losses, actions, claims, proceedings, demands, costs, expenses, damages, and other liabilities whatsoever
or howsoever caused arising directly or indirectly in connection with, in relation to or arising out of the use of
the Content.
This article may be used for research, teaching, and private study purposes. Any substantial or systematic
reproduction, redistribution, reselling, loan, sub-licensing, systematic supply, or distribution in any
form 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:299309, 2010

Copyright Taylor & Francis Group, LLC
ISSN: 1939-3555 print / 1939-3547 online
DOI: 10.1080/19393555.2010.514654

Security and Control in the Cloud

Downloaded by [Laurentian University] at 19:57 09 October 2014

Klaus Julisch1 and Michael

Hall2
1IBM Research GmbH,
Rschlikon, Switzerland
2Forbes Sinclair, Madrid, Spain

ABSTRACT Cloud computing is a new IT delivery paradigm that offers

computing resources as on-demand services over the Internet. Like all forms
of outsourcing, cloud computing raises serious concerns about the security of
the data assets that are outsourced to providers of cloud services. To address
these security concerns, we show how todays generation of information security management systems (ISMSs), as specified in the ISO/IEC 27001:2005,
must be extended to address the transfer of security controls into cloud environments. The resulting virtual ISMS is a standards-compliant management
approach for developing a sound control environment while supporting the
various modalities of cloud computing.
This article addresses chief security and/or information officers of cloud
client and cloud provider organizations. Cloud clients will benefit from our
exposition of how to manage risk when corporate assets are outsourced to
cloud providers. Providers of cloud services will learn what processes and controls they can offer in order to provide superior security that differentiates their
offerings in the market.
KEYWORDS cloud computing, Security, ISMS, IS027001

1. INTRODUCTION TO CLOUD
COMPUTING
Cloud computing is a new formula of delivering computing resources, not a
new technology. Specifically, cloud computing provides computing resources
as 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 computing
resources that have been provided in the cloud:

Address correspondence to
Klaus Julisch, IBM Research GmbH,
Sumerstrasse 4, 8803 Rschlikon,
Switzerland. E-mail: kju@zurich.ibm.com

Software as a Service (SaaS): This is application software that is hosted

by third parties and provided as a service over the Internet. Examples of
SaaS include Google Docs, Salesforce.com, and Web mail services such as
hotmail.com.
Platform as a Service (PaaS): These are platforms consisting of development tools and a runtime environment. Cloud customers use the
development tools to program their own applications against the
Application Programming Interface (API) of the runtime environment.
299

Downloaded by [Laurentian University] at 19:57 09 October 2014

Subsequently, the applications are deployed to

the runtime environment where they are executed. Examples of PaaS include Microsoft Azure,
Force.com, and Google Apps.
Infrastructure as a Service (IaaS): These are lowlevel computing resources such as virtual machines
or storage which are provided on-demand over
the Internet. Examples include Amazons Elastic
Compute Cloud (Amazon EC2) and Carbonites
backup service.
Many additional examples of SaaS, PaaS, and IaaS vendors and offerings can be found in the cloud taxonomy
by OpenCrowd (2009).
Cloud computing is a type of outsourcing. As such,
it is similar to classic information technology (IT) outsourcing, where a client transfers the custody of parts of
its information system to a service provider. The service
provider assumes responsibility for the clients information system and operates it in accordance with the
contractual terms that the client and provider agreed
upon (Cullen & Willcocks, 2003; Gewald & Helbig,
2006). These contractual terms, which define the cooperation between outsourcing clients and providers, are
called Service Level Agreements, or SLAs.
The defining characteristic of classic IT outsourcing
(compared to cloud computing) is that the outsourcing
provider offers a customized and unique service that does
exactly what the client requests at the clients terms, in
a well-controlled and discrete environment. Cloud computing, by contrast, offers highly standardized services
that are provided cheaply by serving multiple customers from a shared IT infrastructure (Brunette &
Mogull, 2009; Datamonitor, 2009). Of course, cloud
services offer some degree of customizability, but cloud
services are basically commoditized one-size-fits-all
offerings. Further, the use of a shared IT infrastructure across clients destroys any clients ability to afford
the same level of control known from classic IT
outsourcing.
Cloud computing is a sizeable and rapidly growing
market. According to International Data Corporation
(IDC), a leading provider of the market intelligence
and advisory services, the worldwide market for cloud
computing was approximately $17.4 billion in 2009
and is estimated to reach $44.2 billion by 2013
(Gens, Mahowald, & Villars, 2009). This rapid market growth is driven by the following benefits of cloud
computing:
K. Julisch and M. Hall

Low cost: Typical enterprises dedicate 5070% of

their IT budgets to routine system maintenance
tasks (Datamonitor, 2009; States & Lindquist, 2008).
This overhead can be reduced by outsourcing nonstrategic services to cloud providers, which use their
scale economies and experience curve effects (Hax
& Majluf, 1982) to provide commoditized services
more cheaply (Reeves, 2009A).
On demand: In a recent Goldman Sachs (2009) survey, 51% of respondents saw the key benefit of
cloud computing in the ability to elastically scale to
meet peak workloads and future demand. A related
benefit is the usage-based pricing model where customers only pay for compute resources consumed
(Datamonitor, 2009; Reeves, 2009A).
Short time-to-market: It is faster to procure
cloud services than develop the same functionality
in-house. The ability to deliver results fast is another
benefit of cloud computing (Roth, 2008).
Inhibitors to the adoption of cloud computing
include security, business continuity and control concerns, reliability concerns, fears of vendor lock-in,
migration costs, reduced customizability, integration
difficulties, as well as uncertainties about the business
case and the legal implications (Catteddu & Hogben,
2009; Datamonitor, 2009; Roth, 2008; Reeves, 2009A).
This article addresses the security and control concerns
and shows how information security management systems (ISMSs) can be extended to overcome them.

2. STATE OF THE ART IN CLOUD

SECURITY
Section 1 defined cloud computing as a new IT
delivery model. This definition by itself does not imply
any new security challenges. For example, an organization could task its internal IT departments to deliver
all computing resources as cloud services. From a security and control point of view, this is very much akin
to classic in-house IT delivery. New security challenges
arise, however, in the public cloud (Brunette & Mogull,
2009; Reeves, 2009A) where a cloud provider offers
cloud services to any (paying) client. Some of these
clients may be internal business units of the cloud
provider, but most clients will be external legal entities,
for example, other companies. The defining characteristic of public clouds is that SLAs are used to stipulate
the legal accountability between cloud providers and
300

Downloaded by [Laurentian University] at 19:57 09 October 2014

their clients. This article focuses on security in public clouds, and the term cloud is henceforth used
synonymously with public cloud.
In using (public) cloud services, a Cloud Client (CC)
places select organizational assets in the custody of a
Cloud Provider (CP). In doing so, the CC cedes control over these assets to the CP, and yet the CC retains
accountability for the security and regulatory compliance of these assets. This creates risks, which have
made some enterprises hesitant to sign up for cloud
services (Catteddu & Hogben, 2009). CPs understand
this 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, some
CPs such as Intacct.com or Google offer Service Level
Agreements to facilitate a risk transfer (Intacct, 2010;
Google, 2010A; Amazon, 2008). All of these schemes
are important, but taken in isolation, they have important shortcomings:
1. Formal Registrar Security Certification audits have
the problem of being infrequent (typically every
three years). The CC therefore receives infrequent
snap shots of the CPs control environment and
has to trust that everything is OK between certifications. This setup is increasingly unacceptable
to many CCs who, at any moment, may be held
accountable by their stakeholders for the security
and compliance of their own information systems.
2. It is important to understand that SAS 70 certification is not a stamp of approval (even though it is
sometimes marketed that way). This is because SAS
70 is a framework for conducting audits. It does not
certify any specific controls or control objectives.
Rather, each CP defines for itself the controls and
control objectives that it wants to be certified for
(AICPA, 1992). These controls and control objectives 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 their
requirements (Brunette & Mogull, 2009). SSAE 16
and ISAE 3402, the successor standards of SAS 70,
improve on these issues by requiring the CP to more
fully disclose its system and control environment
(Thompson, Griffin, & Bialick, 2010).
3. The SLAs offered by CPs tend to be conservative in the sense that they offer only small
301

penalty payments and their commitments are

focused on availability rather than data integrity
or confidentiality (Amazon, 2009; Google, 2010A;
Maiwald, 2009; Mather, Kumaraswamy, & Latif,
2009). Further, cloud-SLAs are typically standardized and unable to meet the specific security requirements of individual customers (Goertzel et al.,
2009).
4. SLAs are an intrinsically imperfect risk treatment
strategy. In theory, they transfer the risk to the
CP. In practice, however, the CPs responsibility
ends with a (frequently small) penalty payment and
the potential loss of the customer(s) affected by
a control failure. The CC, by contrast, remains
accountable towards its own customers, regulators,
and directors for any failures, and there are few
limits to the cost that such accountability can entail.
While generally insufficient by themselves, SLAs,
certifications, and audits are important building blocks
of cloud security. In this article, we show how these
and other risk treatment methods can be combined
into a single consistent framework, called the virtual
ISMS. An ISMS is the set of processes, policies, and
mechanisms that an organization uses to establish,
implement, operate, monitor, and improve information security (ISO, 2005A). A virtual ISMS extends this
concept so it becomes suitable for virtual enterprises
where IT services are partially outsourced to CPs.
This article is targeted at CIOs and CSOs of cloud
client and cloud provider organizations. CCs will find
that the virtual ISMS offers a structured way for managing risk and protecting corporate assets that are
outsourced to CPs. This benefit is shared by CPs. As CPs
use shared and standardized infrastructures to deliver
cloud services cheaply, they cannot offer customized
provisions to individual clients. Using the virtual ISMS
to manage security in a standardized and scalable way is
of real benefit to CPs. In addition, CPs will draw value
from our discussion of ways to improve security and
thereby differentiate their offering in the marketplace.

3. THE CONVENTIONAL ISMS

The ISO/IEC Standard 27001:2005 defines an
ISMS as the set of processes, policies, and mechanisms that are used to establish, implement, operate,
monitor, review, maintain, and improve information
security (ISO, 2005A). The standard further prescribes
Security and Control in the Cloud

Downloaded by [Laurentian University] at 19:57 09 October 2014

that ISMSs follow the Plan-Do-Check-Act (PDCA) process, or Deming Cycle. The PDCA cycle acknowledges
that information security is not a product that once
installed, makes a system secure. Rather, information security is achieved by a process of continuous
improvement and adjustment to the inevitably changing threats, technologies, and business processes. The
four steps of the PDCA process are as follows:
The Plan step defines the scope of what is to
be protected; it further performs a risk assessment
and defines the security policies and the control
objectives that are to be achieved.
The Do step implements and operates controls to
achieve the stated control objectives and to comply
with the stated security policies.
The Check step monitors and assesses the achieved
information security relative to the stated control
objectives and security policies.
The Act step derives improvements and new security requirements from the results of the check step.
This provides the input for the next iteration of the
PDCA cycle.
In a conventional ISMS, the IT assets (i.e., hardware,
infrastructure, software, and data) and the security management of these assets are owned and controlled by the
same organization. This changes in cloud computing.

4. RESPONSIBILITY FOR CONTROLS IN

CLOUD COMPUTING
A prerequisite for understanding cloud security is
to understand the difference between responsibility and
accountability. Accountability is ultimate responsibility; it is the state of being where the buck stops.
Responsibility is an obligation to do something according to certain parameters. For example, a manager who
delegates a task to a subordinate makes this subordinate responsible for the task but remains accountable
in case something goes wrong. In other words, the
manager can delegate responsibility but not accountability.
While cloud computing is a major paradigm shift,
it does not change the assignment of accountability.
Companies are accountable for their assets, including any assets that were outsourced to CPs. Cloud
computing only transfers the responsibility to perform compute task according to certain parameters,
K. Julisch and M. Hall

but accountability remains with the CC. The central

challenge therefore becomes how a CC can define
and monitor the security controls for which the CP is
responsible.
The decision of whether the CC or the CP is responsible 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 CPs controls;
3. Legislations, which may dictate the assignment of
responsibilities and thereby overrides the previous
two factors.
Before exploring these factors, it is important to note
that the CC is always responsible for securing the computing resources it retains. In fact, all other security
controls become void if the CC fails to deploy controls
to protect the servers, notebooks, and networks that it
uses to access the CP. This retained IT is shown at the
top of Figure 1, and it is entirely the CCs responsibility
to implement suitable controls to prevent client-side
threats such as the Web browser vulnerabilities, theft
of authentication credentials, virus attacks, or data theft
by rogue employees.
The assignment of responsibilities is less clear cut
for the data and software assets that physically reside
on the CPs site and infrastructure. As previously mentioned, the cloud model plays an important role in this
case. The general rule is that the party that manages

FIGURE 1 Responsibility for controls in the IaaS, PaaS, and

SaaS cloud models.
302

Downloaded by [Laurentian University] at 19:57 09 October 2014

and controls an asset is also responsible for providing suitable security controls to protect it. Figure 1
uses grey shading to show who manages and controls
a given asset. Consequently, we obtain the following
(still preliminary) responsibilities:
In all three cloud models, the CP manages, and controls the infrastructure, which comprises the servers,
networks, electricity, human resources, and site services. As such, the CP is responsible to implement
and operate suitable infrastructure controls such as
employee training, physical site security, network
firewalls, and others. Infrastructure controls are of
fundamental importance. For example, if physical
access control is weak and people can steal entire
servers then it does not matter that network access to
these servers is protected by firewalls and encryption
(Archer et al., 2010).
In IaaS, the CC manages and controls all software
that runs on the CPs infrastructure. As such, the
CC is responsible for all software security controls,
including software patching, anti-virus protection,
application access control, user identity management, and others. If, for example, an attacker successfully guessed an application password, then this
reveals a control failure by the CC to properly
protect its assets.
In PaaS, the CC manages and controls the application software, while the CP manages and controls
the operating system, middleware, and infrastructure.
Accordingly, the CC is responsible for all application controls, while the CP is responsible for the IT
general controls (Bayuk, 2004).
In SaaS, the CP manages and controls all layers
of the software stack and is accordingly responsible
for their security. In other words SaaS providers are
responsible for implementing suitable security controls in their infrastructure, operating systems and
middleware, as well as application software. If, for
example, unpatched application software is compromised by attackers then the CP failed to meet its
responsibilities.
This assignment of responsibilities still needs to
be modulated by a second factor, namely the extent
to which the CP allows the CC to configure the
controls it provides. This factor is most easily understood in the case of SaaS: While SaaS providers
303

implement the entire software stack, they do not necessarily configure all of it. Specifically, many SaaS
providers let their CCs configure their own accounts
and password policies. This partially moves the responsibility for these controls back to the CC: The CC
becomes responsible for configuring the appropriate security policy, and the CP remains responsible
for enforcing this policy via its controls. This configuration option is illustrated by the C interface
in Figure 1. In practice, it is quite common for
CPs to provide a configuration interface C because
it allows them to partially delegate responsibility
back to the CC. Examples of configuration interfaces
include:
Amazons Elastic Compute Cloud (EC2) allows
the CC to configure the network firewall that
controls access to CCs resources on EC2 (Amazon,
2009).
Customers of Amazons Simple Storage Service (S3)
can configure the access rights that control who can
access their data on the S3 cloud (Amazon, 2009).
Google Apps offers a SAML-based Single Sign-On,
where the CC authenticates users and then sends
a token to Google Apps to vouch for the users
identities (Google, 2010B).
In summary, the assignment of responsibilities is
more complex in cloud computing because it depends
on the cloud model as well as the extent to which
CCs can configure the controls provided by CPs. This
brings us back to the topic of this article the virtual
ISMS whose purpose we can now define as (a) supporting the CC and the CP in negotiating and defining
their respective responsibilities and (b) enabling the
CC to monitor and audit the effectiveness of the
controls that are under the CPs responsibility.

5. THE VIRTUAL ISMS

The virtual ISMS follows the PDCA-cycle defined
in the ISO 27001 standard, but the specifics of each
step are different. These differences affect both, what
is done and by whom it is done. Table 1 summarizes
the PDCA-cycle of the virtual ISMS. The planning and
control steps are the most complex and involved steps
of the virtual ISMS. The remainder of this section is
therefore focused on these two steps.
Security and Control in the Cloud

TABLE 1

The PDCA-cycle of the Virtual ISMS

Cloud Client (CC)

Plan

Downloaded by [Laurentian University] at 19:57 09 October 2014

Do

Check

Act

Cloud Provider (CP)

Identify all data and software assets as well as their

values.
Derive the control objectives that have to be met
and the controls that have to be implemented to
protect these assets.
Identify the service that is to be outsourced and
use the rules of responsibility (Section 4) to
define the controls and control objectives that
the CP is responsible for.
Review the controls implemented by potential CPs
and assess their suitability.
Select the most suitable cloud provider and
contract its services.
Work with the CP to migrate the contracted service
to the CPs infrastructure. Aside from transferring
data and software, this also includes the so-called
on-boarding, that is, the creation of user
accounts for CCs employees on the CPs
infrastructure.
Use the assurance provided by the CP to verify the
correct, secure, and compliant operation of the
CPs controls and to detect SLA violations.

Decide if any contractual changes are necessary.

Such changes may affect provider-side controls,
SLAs, price, legal terms, or any other aspect of
the contract.
Assess if the contract should be terminated.
Inform the CP about desired changes, e.g.
improvements in the control environment, and
negotiate the specifics of their implementation.

5.1. Planning
The first activity in planning is that the CC establishes its control objectives. To do so, the CC identifies
its corporate assets (data or software) and their values. The asset value is the monetary impact that a loss
of availability, confidentiality, or integrity has on the
clients business. From the asset values, the CC can
then determine its protection requirements. These protection requirements are documented in the form of
control objectives as well as specific controls that have
to be implemented. The CC also must define its assurance requirements, that is, the evidence that it requires
to be collected during the Check step to proof that
the control objectives are met. So far, this is no different from the risk-based planning step performed in
conventional ISMSs.
K. Julisch and M. Hall

Assist the CC by providing information about the

security controls implemented.
Negotiate responsibilities, prices, SLAs, and
contracts.

Work with the CC to migrate the dedicated service.

Operate the IT infrastructure and provide the
contracted service to the CC.

Provide the CC with the assurance that was

contractually agreed in the Plan step.
Forms of assurance include third-party audits, the
permission for the CC to audit the CP, detailed
security incident reports, as well as real-time
audit logs and activity monitoring.
Negotiate with the CC any contractual changes
they want to perform.
Collaborate with the CC in improving the control
environment.

At this point, the CC must identify the cloud service it wants to procure from CPs. Using the rules of
responsibility derived in section 4, the CC can then
identify the controls and control objective that the CP
is responsible for. The CC can further determine the
assurance information that the CP is responsible for
providing. Taken together, these responsibilities define
the requirements catalog that the CC imposes on the CP.
Using the requirements catalog, the CC can assess
potential CPs with respect to their ability to satisfy
it. This clearly presupposes that CPs disclose their
security controls to determine if they meet the CCs
requirements. Unfortunately, most CPs are not very
open with regards to their security controls (Reeves,
2009B; Archer et al., 2010). Obviously, CPs that keep
their security controls secret destroy the CCs ability
304

Downloaded by [Laurentian University] at 19:57 09 October 2014

to perform a sound risk treatment. Accordingly, such

CPs should only be considered for low-valued assets,
or when strong SLAs provide a clear risk transfer.
Throughout the planning phase, the CPs role is
to assist the CC in obtaining required information.
Further, the CP negotiates with the CC to determine
responsibilities, legal clauses, and prices. Even though
the CC is in charge of the planning process, it is important for the CC to remain sensitive to the CPs constraints. These constraints arise from the fact that some
parts of the CPs IT infrastructure are shared among all its
clients. So, for example, if one client requests a firewall
configuration that blocks all IP addresses but its own,
then the CP simply cannot accommodate this request
because it would block all its other clients. Similarly, a
SaaS provider cannot accommodate individual clients
requests for particular anti-virus products because the
CP will run the same anti-virus product across its entire
infrastructure.
The final step in the planning phase is to select
the most suitable CP and to contract its services. The
contract should address at a minimum the following
points:
A list of controls implemented by the CP. To further clarify roles and responsibilities, it is advisable to
document the controls the CC is responsible for and
the controls where responsibility is shared (because
the CC configures them and the CP implements
them). Section 6 further discusses the selection of
controls that the CP has to implement.
A description of the assurance that the CP provides
during the Check step. Possible forms of assurance include third-party audits, the permission for
the CC to audit the CP, detailed security incident
reports, as well as real-time audit logs and activity
monitoring.
Service level agreements and penalties for their nonfulfillment. As part of the SLAs, it is essential to
define the metrics and procedures that are used to
decide if SLAs are fulfilled.
Legal clauses addressing the use of iterative outsourcing, that is, the rules according to which the CP may
use other third-party cloud providers to implement
its services.
A description of the joint security governance process; we recommend that the virtual ISMS presented
here is used for security governance.

305

Legal clauses addressing the terms and conditions of

contract termination. This specifically must describe
how software and data assets are migrated from the
CP to another hosting environment.

5.2. Check
At 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 differentiated value for their clients. CPs who want to do
so must address several challenges. First, CCs want to
monitor their CPs so they can demonstrate their own
compliance, drive continuous improvement in the
Act step, and enforce penalty payments for SLA violations. CPs will find opportunities for improvement
in all three areas, but the most imminent improvement
potential exists in the first two areas. The third area,
that is, SLAs, sill faces many technical challenges that
will take time to overcome.
On the challenges associated with security SLAs: SLA
violations concerning confidentiality or integrity are
difficult to ascertain, and even then, the question arises
of whether the CC or the CP was responsible in the sense
of section 4. Obviously, CPs do not want to pay penalties
for failures that were the CCs fault. Consequently,
thorough forensic investigations of security failures are
required to ascertain responsibility. Will CCs and CPs
agree to participate in such investigations, and what
happens if the forensic results are not conclusive? A
further hurdle is that CPs would assume very large risks
if they were to offer SLAs that compensated CCs for
their losses from potential security incidents. Therefore,
CPs choose to offer SLAs that compensate CCs for
services not provided (e.g., by refunding hours of uptime not delivered). This is a controllable risk to the
CP but hardly covers the true cost to CCs. In summary,
these are difficult challenges and it will take years before
security SLAs become practicable.
With any meaningful risk transfer using SLA being
years away, CPs would be well-advised to support
their clients risk management processes. The simple
truth is that CCs have to manage their risks, and CPs
whose secrecy policies (Reeves, 2009B; Archer et al.,
2010) hinder such risk management will see their customers go elsewhere. CPs consequently must offer
transparency with respect to the controls they implement and the effectiveness of these controls. CPs who

Security and Control in the Cloud

Downloaded by [Laurentian University] at 19:57 09 October 2014

accept this fact need to address the following issues

related to monitoring:
CPs must decide what type of monitoring to provide.
Options are: real-time event monitoring, intermittent status reporting, or audits.
For audits, CPs must decide if they accept to
be audited by their clients or if they will only
subject themselves to audits by independent third
parties.
For real-time monitoring, CPs must take precautions
that they do not leak events that pertain to other
clients. As all clients are served from the same shared
cloud infrastructure, there is a risk that one client
receives event information that pertains to other
clients.
CPs must decide what to measure and report. In general, CCs are interested in knowing whether the
CPs controls are operational and effective. A control
is operational if it is up and running; it is effective if
it achieves its control objective.
In particular for manual controls, CPs should provide measurements to show that they are operational.
For example, if a guard is to inspect the server room
once an hour, it is advisable to measure how frequently the guard uses her badge to access the server
room. This frequency measures whether or not the
control is operational. For automated controls, such
measurements of being up and running are less
cogent as automated controls typically run flawlessly
as result of being automated.
In general, CPs cannot measure if controls are effective at achieving their objectives. For example, we
do not know if a virus scanner really preempted all
viruses. In other cases, the effectiveness of controls
can be measured. For example, one can measure the
number of accounts with root privileges; if this number is too large, it is indicative of ineffective management controls. Wherever possible, CPs should
measure and report the effectiveness of their controls. In addition, they should report control failures
whenever they are detected. It is disputed whether
CCs should be informed about all incidents on the
CPs shared platform or if they should only learn
about the incidents that arguably affected their assets.
In summary, a genuine risk transfer using SLAs is
not possible with todays technologies. From the CCs
point of view, this makes it all the more important that
K. Julisch and M. Hall

CPs offer sound monitoring and reporting capabilities.

Using these capabilities, CCs can perform their own
risk management and thereby satisfy their auditors and
stakeholders.

6. STATEMENT OF APPLICABILITY
The Statement of Applicability (SOA) is a specific
requirement of the ISO 27001 and documents which
controls have been chosen by the risk assessment process and which ones have been justifiably excluded.
The controls in a SOA are chosen in order to protect
both, the data assets owned by an organization and
any data assets that are under the custody of that organization. In this section, we take the perspective of a
CP who asks: What controls do I have to implement
in my own infrastructure in order to protect my clients
assets? The answer to this question depends on the
cloud model (IaaS, PaaS, or SaaS) adopted.
Table 2 shows part of the CPs statement of applicability for protecting its clients assets. A complete
SOA would show for each control cited in Annex A
of the ISO 27001 (ISO, 2005A) if and how it has to be
implemented. Table 2 is less detailed and only discusses
control groups rather than individual controls. Also
different from a complete SOA, Table 2 only offers
general guidance on control exclusions because dependent on the specifics of an environment, the CP may
have to implement additional controls.
In general, CPs are best advised to implement
all controls necessary to meet the expectations and
requirements of their most demanding customers. This
recommendation makes sense because the shared delivery platform used by CPs makes it prohibitively expensive to tailor special controls to individual clients.
Therefore, CPs either have to accommodate the security needs of their most demanding customers or risk
losing them.

7. SUMMARY AND CONCLUSION

Cloud computing is a new IT delivery paradigm that
offers computing resources as on-demand services over
the Internet. Cloud computing has become a large
and growing market because of its value propositions
of low costs, increased flexibility, and shorter timeto-market. Cloud providers deliver those benefits by
serving multiple clients from a single highly standardized and shared infrastructure. As a consequence, most
306

TABLE 2 Statement of Applicability for Protecting Outsourced Assets

Clause
A.5, Security Policy
A.6, Organization of
Information Security
A.7, Asset Management

Downloaded by [Laurentian University] at 19:57 09 October 2014

A.8, Human Resource

Security
A.9, Physical and
Environmental Security
A.10, Communication and
Operations Management
A.11, Access Control

Control Group
Control A.5.1
Controls A.6.1 & A.6.2
Controls A.7.1 & A.7.2

Controls A.8.1 A.8.3

Controls A.9.1 & A.9.2

In PaaS and SaaS, the CP is responsible for providing

these controls; in IaaS, the CP is responsible for all
controls except A.10.4 and A.10.9.
Several controls (e.g., 10.6, Network Security
Management) are implemented by the CP but they are
configured in collaboration with the CC.
As many of these controls are manual, it is advisable to
provide measures of their effectiveness and
operational performance to CCs.

Controls A.10.1 A.10.10

A.11.1 Business
Requirements
A.11.2 User Access
Management
A.11.3 User Responsibilities
A.11.4 Network Access
Control

A.11.5 Operating System

Access Control

A.11.6 Application and

Information Access
Control
A.11.7 Mobile Computing
and Teleworking
A.12, Information Systems
Acquisition Development
and Maintenance

Responsibility of the CP

A.12.1 Security
Requirements of
Information Security
A.12.2 Correct Processing in
Applications
A.12.3 Cryptographic
Controls
A.12.4 Security of System
Files
A.12.5 Security in
Development & Support
Processes
A.12.6 Technical
Vulnerability
Management

The CC defines the access control policy for its assets.

The CP is responsible for controlling all access by
administrative users.
For all other users, the CP has to provide the controls,
but the CC configures them;
In PaaS and SaaS, the CP is responsible for providing
network access control;
In IaaS the CP provides the controls, but the CC
configures them (see the examples at the end of
Section 4).
In PaaS and SaaS, the CP is responsible for providing OS
access control;
In IaaS, OS access control is entirely the responsibility of
the CC.
In SaaS, the CP provides the controls, but the user
configures them;
In PaaS and IaaS, application level access control is
entirely the responsibility of the CC.
The CP is responsible for these controls if it uses mobile
computing or teleworking in the delivery of its cloud
services. Otherwise, this control does not apply.
In IaaS, PaaS, and SaaS, the CP is responsible for
implementing this control in its operations.
In SaaS, the CP is responsible;
In PaaS and IaaS, the CC has to implement these controls.
In SaaS and PaaS the CP should provide these controls;
In IaaS, the CP may provide these controls as an added
services to CCs.
In PaaS and SaaS, the CP is generally responsible for
these controls;
In IaaS it is the CCs responsibility.
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.
In IaaS, PaaS, and SaaS, the CP is responsible for
vulnerability mgmt on the infrastructure, platform,
and application level, respectively.
(Continued)

307

Security and Control in the Cloud

TABLE 2

(Continued)

Clause
A.13 Information Security
Incident Management

Controls A.13.1 & A.13.2

A.14 Business Continuity

Management

A.14.1 Information Security

Aspects of Business
Continuity Management
Controls A.15.1 A.15.3

A.15 Compliance

Downloaded by [Laurentian University] at 19:57 09 October 2014

Control Group

cloud providers cannot offer customized provisions for

individual clients because doing so would break their
financial model which is built on economies of scale.
This article addresses the security and control concerns that CIOs and CSOs have about cloud computing. In particular, in highly regulated industries such as
finance, government, or pharmaceutical, it is paramount
for CIOs and CSOs to establish and maintain a sound
and ISO 27001 compliant information security control
environment. This article demonstrates how this can
be achieved in the face of the continued migration of
legacy services to cloud computing.
When choosing cloud computing, clients remain
accountable for their corporate assets, but they selectively place some of their assets into the custody of
cloud providers. With custody of assets come certain responsibilities for protecting those assets, and we
described the rules that determine whether the cloud
provider, the cloud client, or both jointly are responsible for implementing the controls that protect these
assets. We further introduced the virtual ISMS as a
standards-compliant management process that cloud
clients and providers should follow to manage risks
and protect corporate assets. We finally presented a
high-level Statement of Applicability that should benefit cloud providers in their effort to identify controls
that are applicable to their environments.
A key message of this article for cloud providers is
that they have to reveal their controls to clients and
prospective clients; moreover, cloud providers have to
allow clients to monitor and audit their controls as
part of the virtual ISMS process. This is vital because
cloud providers are unwilling and incapable to accept
the clients risk via rigorous SLAs. Therefore, unless
cloud providers want to limit themselves to uncritical
K. Julisch and M. Hall

Responsibility of the CP
In IaaS, PaaS, and SaaS, the CP is responsible for incident
management on the infrastructure, platform, and
application level, respectively.
In IaaS, PaaS, and SaaS, this control is the responsibility
of the CP.
In IaaS, PaaS, and SaaS, this is a joint responsibility where
the CC generally identifies the applicable laws and
regulations and the CP implements the controls to
assure compliance with them.

low-value compute services, they must provide clients

with the information they need to perform their own
risk management. That means describing the available
controls and allowing clients to monitor them.
For cloud clients, a key message is that they have
to be realistic about what they purchase with cloud
services, namely agility at a competitive price. What
they do not purchase is a risk transfer. It is therefore of paramount importance that cloud clients follow
a rigorous risk management process (as enabled by
the virtual ISMS) and that they insist on obtaining the necessary information from their cloud
providers.

ACKNOWLEDGMENTS
The research leading to these results has received
funding from the European Communitys Seventh
Framework Program (FP7/20072013) under grant
agreement No. FP7-216917.

REFERENCES
AICPA. (1992). Reports on the processing of transactions by service organizations (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/awscompletes-sas70-type-ii-audit/
Archer, J., Boehme, A., Cullinane, D., Kurtz, P., Puhlmann, N., and
Reavis, J. (2010). Top threats to Cloud computing V1.0. Cloud Security
Alliance.
Bayuk, J. L. (2004). Stepping through the IS audit: What to expect, how
to prepare (2nd edition). ISACA.

308

Downloaded by [Laurentian University] at 19:57 09 October 2014

Brunette, G. and Mogull, R. (2009). Security guidance for critical areas of

focus in cloud computing V2.1. Cloud Security Alliance.
Carr, N. (2008). The big switch: Rewiring the world, from Edison to
Google. 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 the
long tail. Microsoft Corporation.
Cullen S. and Willcocks, L. P. (2003). Intelligent IT outsourcing: Eight
building blocks to success. Butterworth-Heinemann.
Datamonitor (2009). Can cloud computing help enterprises weather the
economic storm? Gauging the disruptive potential of a new model of
IT consumption. Report DMTC2267, Datamonitor.
Gens, F., Mahowald, R. P., and Villars, R. L. (2009). IDC cloud computing
2010 an IDC update. Doc #TB20090929. IDC.
Gewald, H. and Helbig, K. (2006). A governance model for managing outsourcing partnerships. Proceedings of the 39th Hawaii
International Conference on System Sciences, 47 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. New
York: 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 Google
Apps. 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: The
experience curve. Interfaces, 12, 5061.
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 information security management systems requirements. ISO/IEC,
27001.
ISO/IEC. (2005B). Information technology security techniques information security management systems guidelines. ISO/IEC, 27002.
Maiwald, E. (2009). The issue of SaaS security. Burton Groups Security
and Risk Management Blog. Available from: http://srmsblog.burtongroup.com/2009/09/the-issue-of-saas-security.html
Mather, T., Kumaraswamy, S., and Latif, S. (2009). Cloud security and
privacy: An enterprise perspective on risks and compliance (theory in
practice). CA: OReilly Media.
OpenCrowd. (2009). Cloud computing cloud landscape. Available from:
http://www.opencrowd.com/views/cloud.php
Reeves, D. (2009A, April). Cloud computing: Transforming IT. Burton
Group.
Reeves, D. (2009B, July 8). Cloud infrastructure secrecy: A competitive
advantage or disadvantage. Burton Group Blog.
Roth, C. (2008). SaaS implementation survey: Where, when, and how to
use SaaS. Burton Group.
Salesforce. (2008). Saleforce.com is first major SaaS vendor to achieve
ISO 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 comparative
cost analysis. Forrester Research.

309

States, L. and Lindquist, D. (2008). IBMs perspective on cloud computing.

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

BIOGRAPHIES
Klaus Julisch has a Ph.D. in Computer Science from
the University of Dortmund, Germany, and more
than 10 years of experience in information security.
In 1999, he joined the IBM Research Lab in Zurich,
Switzerland, where he developed new security alert correlation techniques for IBMs commercial divisions.
From 2005 to 2007, Dr. Julisch was on assignment to
the Research Headquarters in Yorktown, where he was
instrumental in launching IBMs secure ID card business. Since 2008, Dr. Julisch has been leading a major
research project aimed at improving the security and
compliance of cloud computing.
Michael Hall is the Practice Development Partner
at Forbes Sinclair, an international risk management
advisory company with offices in Madrid, Spain, and
Tampa, Florida. Forbes Sinclairs projects focus on the
implementation of ISO/IEC 27001, ISO/IEC 20000,
BSI 25999, ISO 14001, PAS 99, IT risk analysis, IT
contingency and business continuity planning, training, and application reviews. Hall is one of the initial
founders of Forbes Sinclair in 1998 and is presently
responsible for business development and the overall leadership of work teams in information security
and audit projects. Aside from his activities with
Forbes Sinclair, Hall is an ISO/IEC 27001, ISO/IEC
20000, BSI 25999, ISO 9001 instructor for the British
Standards Institution. He is the author/editor of the
Risk Management Knowledgebase, an electronic encyclopedia of Standards BSI 27001, BSI 20000, Basel II
and Legal Compliance. Halls professional certifications include CISSP (Certified Information Systems
Security Professional) and British Standards Institute
Registered Auditor in the ISO/IEC 27001, ISO/IEC
20000, BSI 25999, ISO/IEC 9001, ISO 14000. He also
holds BS Advanced Auditing Skills Certificates.

Security and Control in the Cloud