Cloud Computing Security in the Enterprise

Bottom Line: Cloud computing is a strong economic and technical force transforming IT, but
enterprise customers are concerned about security. Cloud computing creates significant risks and
requires a rethink—but not a reinvention—of security programs and architectures. To the extent they
leverage public or private (community) clouds, organizations must accommodate themselves to
security postures emphasizing risk transfer, deterrence, monitoring, feedback, and audit more than
preventive control. Large enterprises should generally avoid placing sensitive information in public
clouds, but concentrate on building internal cloud and hybrid cloud capabilities in the near term.

Context: Cloud computing—which Burton Group defines as the set of disciplines, technologies, and
business models used to render IT capabilities as an on-demand, scalable, elastic service—is evolving
rapidly. Many organizations are considering externalizing lesser-value, commoditized IT functions in
order to lower costs, increase agility, and create a competitive advantage. In turn, cloud computing
vendors have developed on-demand IT services using some old concepts (e.g., utility computing) and
some new technologies (e.g., server virtualization) that may solve many of the business issues IT
organizations face.

Takeaways:

Enterprises have a number of concerns about cloud computing security:

• Cloud’s multi-tenant, dynamic characteristics may put sensitive or regulated data at risk.
• The relationship with cloud vendors, and in some cases, their viability creates strategic risk.
• A lack of transparency and accountability about security from cloud vendors contributes to
customer anxiety.
• Surveys show approximately 75% of respondents are concerned about cloud computing
security.
• Enterprises are not all rushing to embrace low-cost public cloud offerings; many are
investigating internal cloud deployment, as well as hybrid cloud architectures that balance low
costs with risk mitigation.

Cloud computing demands a rethink, but not a reinvention, of enterprise security programs and
architectures:

• Third-party audit/assessment, incident response, and operations/change management are

particular pain points.
• Customers have less preventive control of the infrastructure with cloud and must seek instead
to transfer risks (where possible) or improve detection and deterrence through monitoring,
feedback, and audit.
• Activities once carried out on organization-owned endpoints, data centers, and networks
move across open, untrusted networks.
• Network perimeters are becoming less effective:
o More complex virtual machine and virtual network separation mechanisms are in their
early stages.
o Data in motion should be encrypted to/from cloud environments.
• Encryption would also be desirable for data at rest in multi-tenant cloud environments, but the
performance cost is currently very high and the key management difficult.
• Tightly coupled domain access control is not suitable for identity and privilege management in
the cloud; standards-based identity services are more appropriate.
• Data is not only difficult to control in the cloud, it is also difficult to classify, discover, analyze,
protect, retain, and destroy.
• Security management must enforce separation of duty, monitor events, and cover staged
deployment and change management workflows for hybrid clouds.
Notwithstanding the challenges, there are silver linings and green shoots of opportunity in cloud
computing’s security landscape:

• Done correctly, and in the long run, cloud computing can improve availability.
• Good managed security services are available.
• Private (community) clouds can support secure collaboration with external partners.
• Platform-as-a-service (PaaS) offerings could bake proactive security into the software
development lifecycle.
• Application virtualization, desktop virtualization, and identity federation are transformational
cloud services with positive security impact.

Recommendations:

• Mind the gap: Enterprises should not, in general, use public clouds for medium to high risk
(i.e., sensitive) applications.
• Take out a life insurance policy for the security department:
o Where necessary, obtain written risk acceptance from business unit leaders and/or
strong assurances from all vendors involved.
o Put security “hooks” into appropriate processes to get visibility and control over
business cloud initiatives.
• Build internal clouds; take baby steps toward public cloud with low-risk or low- (variable-)
volume applications; and develop service-oriented hybrid cloud architectures.
• Consider private (community) clouds in concert with vertical industry affinities.
• Demand greater vendor transparency around cloud security, better assessment criteria and
ecosystems for third-party audit, and industry standards to enhance interoperability and security.

Conclusion: Cloud computing creates significant risks and requires a rethink—but not a reinvention—
of security programs and architectures. Large enterprises should avoid placing sensitive information in
public clouds unless they can obtain strong assurances of appropriate protection from all the vendors
involved. To use public clouds, organizations must change their security postures; to use internal or
hybrid clouds, they must change architectures.

Analysis
Cloud computing is transforming IT perceptions and usage models. Driven by market forces (i.e., the
economy) and advancements in cloud vendor capabilities, organizations are questioning the wisdom
of owning and operating all of the resources necessary to create IT services. Cloud computing’s on-
demand, pay-as-you-go IT service model may enable IT organizations to reduce complexity, lower
costs, increase agility, improve service to mobile or transient workers, and increase capacity or
availability by outsourcing IT capabilities to service providers.

The scale of this transformation is large. Burton Group is tracking the following trends in cloud
computing:

• Computing (i.e., infrastructure as a service [IaaS])

• Storage (IaaS)
• Applications (i.e., software as a service [SaaS])
• Desktops (i.e., virtual desktop infrastructure [VDI])
• Development (i.e., platform as a service [PaaS])
• Identity (i.e., federated identity hubs)
• Security (i.e., managed security service providers [MSSPs])
Burton Group defines cloud computing as “The set of disciplines, technologies, and business models
used to render IT capabilities as on-demand services.”

“Cloud” or “cloud computing” (used interchangeably) can take a number of forms depending on the
architectural level of a service and whether services are delivered publicly or privately. Burton Group’s
root document “Cloud Computing: Transforming IT” provides detailed explanations of SaaS, PaaS,
and software or hardware IaaS forms of cloud, as illustrated in Figure 1.

Figure 1: Cloud Computing Tiered Architecture

Dark Clouds
Cloud computing has several drawbacks. As described in Burton Group’s root document, customers
are confused by:

• Multiple, conflicting “cloud” definitions

• Incomplete usage models
• Vendor hype

And customers are apprehensive of:

• Inadequate, inflexible, or nonexistent service level agreements (SLAs)

• Lack of interoperability
• Vendor lock-in
• Poor transparency on security from the vendors
• Inability (in some cases) to audit and assess the many risks of cloud computing

With these concerns and after a growing number of incidents,1 it’s a small wonder that surveys show
roughly 75% of IT managers are concerned about security!2 The very location independence and
economies of scale in shared resources that lower cloud costs may put customers afoul of laws
restricting certain types of data to certain jurisdictions and contracts demanding separation or other
controls over data. Other new issues and vulnerabilities will arise; for example, who would pay for a
usage engendered by a distributed denial-of-service (DDoS) attack on a public cloud vendor’s
customers?

Silver Linings
However, there are silver linings and green shoots of opportunity in today’s bleak cloud computing
security landscape. Cloud offerings may, in some cases:

• Improve availability through massive and redundant compute, storage, and backup facilities
capable of handling bursts or spikes in utilization.

• Offer better security than some small to medium-size businesses (SMBs) could afford to
deploy themselves.

• Provide, in some respects, simpler and better security architectures and operations than
complex enterprise software packages.

• Relieve customers from the burden of patching and other security chores.

• Include powerful outsourced security services, such as reputation, multiple engine malware
scanning, and other offerings that have potential scale economies or that benefit from cost
sharing across multiple customers.

In general, large organizations aren’t engaged in a lemming-like rush to risk acceptance of the lowest–
common-denominator public cloud offerings. (See the “Risk Appetites and the Salesforce Question”
section of this overview for an apparent exception.) Instead, customers concerned with risk and
compliance will demand a “long tail” of cloud formats with different cost/risk tradeoffs. Many more
choices will emerge. But during the initial years of cloud computing, enterprises will find relatively low
security maturity levels, considerable churn among public cloud providers, and a tendency to shy away
from assuming any liability and risk.

What’s the Same, What’s Different from Traditional IT?

In some ways, cloud computing is an expansion of server hosting, outsourcing, web-based computing,
managed security services, and other past and present offerings. New and different are cloud’s:

• Scale of adoption
• Dynamic characteristics (per the Cloud Security Alliance):3
o Abstraction of infrastructure
o Resource democratization
o Service oriented architecture (SOA)
o Elasticity/dynamism of resources
o Utility model of consumption and allocation
• Multi-tenancy in which multiple customers and their information share applications and/or
infrastructure
• New kinds of services, such as IaaS virtual machine (VM) hosting and PaaS
development/integration services hosting

Burton Group distinguishes between a private cloud delivered by a service provider to an exclusive
community of customers (perhaps within a vertical industry) and an internal cloud that is delivered by
IT for the use of its organization.
Private clouds are similar to services from a small, but mature, market niche filled by providers, such
as Exostar, Covisint, and NeuStar, who already offer browser-based, shared collaborative
environments for closed communities of organizations. These services are essentially private SaaS
offerings. They cater to competing organizations that need to work together on endeavors such as the
Joint Strike Fighter project. Often, regulatory or other security drivers require strong information
protection. Going forward, IaaS (and perhaps PaaS) will also be provided via private formats to vertical
industry communities, such as nScaled’s LegalCloud offering.

Internal clouds are essentially data center consolidation initiatives within an organization that heavily
leverage virtualization in dynamic ways—architecturally akin to some IaaS deployments. Dynamic data
centers make compute and storage capacity available on demand to many applications.

But organizations such as Bechtel4 have taken the internal cloud idea farther; Bechtel studied the
architectures of Amazon, Google, and Salesforce and then rationalized applications—by reducing
some duplicate programs and refactoring others—to provide web-based delivery, just like SaaS. With
internal deployment, organizations such as Bechtel, with the size and resources to scale, can have
their cloud and secure it too.

Public clouds in some ways resemble earlier on-demand computing initiatives and may involve
multiple providers working together to provide maximum capacity to customers. In the future, public
cloud providers may share capacity with one another in a dynamic, brokered manner. As the
outsourcers outsource recursively, the ability to scale and handle spikes in demand increases.
Customer data and processing needs find the available capacity, wherever it may be. But customers
can’t be too discriminating about where or by whom their data is stored and how it is controlled. That’s
the beauty of the public cloud—and the (significant) risk.

SaaS offerings in some ways resemble older application service providers (ASPs), but are browser
based and use multi-tenant hosting models. MSSPs providing monitoring (e.g., Riptech or BT
Managed Security Solutions Group [formerly Counterpane]), message filtering (e.g., MX Logic or
Symantec’s MessageLabs), or other functions may term themselves SaaS offerings or, perhaps,
software infrastructure as a service (SIaaS) in Burton Group’s parlance.

IaaS offerings are like hosting services on steroids; customers rent computing capacity in terms of
VMs (or other units) rather than physical units. PaaS, in which customers rent application development
and integration facilities as well as runtime infrastructure, is a new thing under the sun for IT.

Vendor Camps
The vendors of cloud computing fall into three camps:

• Large, disruptive entrants from the consumer/small business space

• Established enterprise IT vendors
• Smaller vendors providing various cloud computing offerings

Google, Amazon, and Salesforce (the big three) are emerging out of, and are still heavily focused on,
consumer and SMB markets more than the enterprise market. For enterprises accustomed to offerings
with security and manageability built in, the newcomers often bring unattractive terms and conditions,
no warranties or representations, and opaque security practices.

It is hard for customers to get much security information from Google, Amazon, or Salesforce, let alone
have a service’s terms or controls customized. Incredibly, Salesforce told Burton Group it has a policy
of not giving security briefings. Even representatives of the U.S. National Institute of Standards and
Technology (NIST, a proxy for the U.S. government) could not learn all they wanted to know. However,
NIST did indicate that vendors have become more forthcoming over the past months. And one
marquee Fortune 50 company we spoke to said a cloud provider agreed to customize its offering so
that only U.S. data centers and U.S. administrators would touch the customer data elements that are
legally required to stay in the United States.

Customers generally find few features they can control within public cloud vendors’ domains. For
example:

• Among the big three, only Amazon offers a packet-filtering firewall, and none of these vendors
offers an application firewall as of early 2009.

• A representative of a manufacturing company that wanted to provide an “enterprise Hotmail”

type of service for tens of thousands of workers not currently equipped with company PCs told us
that Microsoft would only commit to 99.9% availability.

• Google App Engine’s terms and conditions appropriately state “THE SERVICE IS NEITHER
DESIGNED NOR INTENDED FOR HIGH-RISK ACTIVITIES.”

These brash young giants of cloud computing, and others like them, need to up their level of enterprise
engagement to become more suitable for medium-risk activity (i.e., involving the possibility of
significant negative consequences), let alone that of high risk (i.e., with the possibility of loss of human
life or limb, bankruptcy, or the total destruction of an enterprise).5

Established IT vendors and telco service providers—such as AT&T, BT, HP, IBM, Microsoft, Oracle,
Sun Microsystems, and Verizon—are also moving into cloud computing. These vendors are used to
dealing with enterprise customers and are moving to provide enterprise-class cloud offerings. Although
their offerings may be relatively enterprise friendly—and some, such as Microsoft Hosted Exchange or
Lotus Live, have good market share—most lack the newer entrants’ first-mover advantage.

Finally, of the smaller vendors that offer a broad menu of choices tailored for security needs, some are
consumer or small-business oriented, but others are enterprise oriented. For example, SAVVIS
provides both dedicated Payment Card Industry (PCI)-compliant hosting solutions and cloud offerings.
Various security service providers outsource security functions, such as antispam or monitoring and
response services. Dataline is developing an encrypted cloud storage solution for the U.S. Federal
Emergency Management Agency (FEMA). System integration and deployment services from Apptis
also focus on U.S. government cloud security needs. Appirio’s Cloud Connector products add security
features to Salesforce, Amazon, and Google clouds for document management and other use cases.

Vendor offerings must converge to offer enterprises better choices, with more security on the menu. If
one were to picture a market landscape diagram for enterprise cloud security today, none of the major
vendors would be in the “magic quadrant.” In time, that will change and the vendor(s) that can fit
security into the puzzle without losing the opportunity for cost savings and business agility will reap
rewards.

Implications for security vendors are apparent as well. Phillipe Courtot, CEO of Qualys, predicts
security software vendors and suites will be decimated in a coming battle with security services; more
likely, both will coexist for quite some time.

Rethinking Security for Cloud

Cloud is transformational to IT security as well as IT, but it is more of a rethink than a reinvention of
security. Organizations should certainly consider cloud security offerings (e.g., as managed web
filtering services) to replace or complement some functions traditionally performed in-house. But more
broadly, organizations should consider what cloud computing means to various aspects of their
security programs.
With cloud in mind, security practitioners are walking “conceptual trees” of security architecture. The
Cloud Security Alliance white paper covers 15 domains of knowledge.3 A lead security architect at a
large Fortune 100 company used a variation of the Jericho Forum cloud computing cube model6 to
decompose cloud offerings into six layers and eight deployment dimensions. He is now working to
describe the security evaluation factors for all 48 scenarios, while suspecting most of them will
collapse into common sets of requirements. Burton Group takes its own approach with a systematic,
comprehensive security program rethink, which is provided in “The Details” section, but is,
nonetheless, a core “must read” section of this overview.

For the rethink, it is important to distinguish between different types of risks and manage them
appropriately. Cloud computing may, in some cases, reduce availability risk. However, risks to
confidentiality, integrity, accountability, and use control security objectives (typically involving
compliance issues as well as loss potential) are difficult to resolve in the public cloud at present. It is
also important to consider changing security program implications over time as cloud computing
offerings become more diverse and dynamic.

Organizations must understand the potential consequences of outsourcing in general and the cloud in
particular. Simply put, the public cloud’s location independence and dynamic characteristics are on a
direct collision course with today’s legal and regulatory requirements and practices. In addition, the
cloud is subject to threats and vulnerabilities above and beyond what many organizations are now
exposed to. On the other hand, cloud computing could (in theory, in the future) take some risks or
liabilities away from enterprises. Opportunities for risk transfer to the cloud should be explored in
regulatory frameworks and through private (community) cloud arrangements.

Cloud computing brings a paradigm shift as information and processes once under the organization’s
control move to service providers. This changes security postures, thus granting less opportunity for
preventive measures and creating a greater need for detection, deterrence, and response.

Most of the large enterprise customers we spoke with for this overview already have policies and
processes covering vendor and contract management. By and large, organizations are attempting to
fine-tune these policies and processes, not reinvent them. However, assessments, investigations, and
monitoring are more difficult to perform with cloud vendors than in traditional hosting and outsourcing
relationships. Although very large, marquee customers can sometimes get special treatment from
cloud vendors, other organizations are not so fortunate. Policies need to take special account of these
issues based on the:

• Realistic expectations of an organization’s clout with the vendors

• Type of cloud offering (more control and monitoring possible in PaaS or IaaS layers than
SaaS)
• Guidelines and standards covering choices between traditional IT, internal clouds, split/hybrid
clouds, or public clouds

Compliance, incident response, and other processes, as well as changing technical safeguards, all
pose challenges in the transition to cloud computing.

Compliance Casts a Long Shadow, but Audit Falls Short

Perhaps the biggest risk in cloud adoption is a lack of due diligence. In a PricewaterhouseCoopers
(PwC) study, just over half (51%) of financial services respondents admitted they do not require third-
party service providers to comply with their company’s privacy policies.7

Cloud vendor control over all or part of the IT infrastructure does not, in general, absolve organizations
from compliance responsibilities. As the level of control decreases, organizations need fewer security
technical staff, but more auditors and lawyers. The problem is compounded by a lack of audit
standards for cloud and the speed at which business models and technologies are evolving.
Audit options include accepting the cloud vendor’s self-assessment, reviewing a third-party
assessment, or sending staff to conduct the organization’s own assessment. Although many
organizations do dispatch their own audit teams to vendor sites, reviewing a third-party Statement on
Auditing Standards (SAS) 70 Type 2 audit (and sometimes an International Organization for
Standardization [ISO] 27001 certification or PCI audit as well) is the most common approach.
However, the control objectives tested in a third party don’t necessarily match enterprise requirements.

The “Audit and Compliance” section of this overview highlights a number of issues with third-party
audits and the challenge of applying conventional security wisdom to dynamic, multi-tenant cloud
offerings.

Not Just Audit; Other Processes Change

Other important processes impacted by cloud computing (and covered in “The Details” section rethink)
include:

• Investigation, e-discovery, and incident response that are particularly difficult in cloud
environments (where the enterprise lacks the necessary access)

• Development and operational procedures including change control and testing that may be
helped or hindered in the cloud

• Legal and vendor management processes that may be able to achieve some risk transfer
through contracts, partnerships, and understanding incentive structures

Security Management: A New Focus Needed

In traditional IT environments, organizations generally share control over the network with service
providers, but for the most part control the applications, servers, and storage for their IT environments.
In an internal cloud environment, the architecture changes, but not the complexion of control. But, as
illustrated in Figure 2, for public or private (community) cloud offerings the control architecture changes
profoundly.
Figure 2: Comparative Control Models in Typical Environments

With the service provider taking the lion’s share of control, most of the public cloud customer’s security
focus shifts to monitoring and feedback. Even so, the enterprise has limited visibility and considerable
work will be needed on event/log separation, protection, and correlation.

A silver lining in this case is that many security functions may themselves be simplified and pushed out
into the cloud. Some services (such as scanning files for malware using multiple engines or massive
reputation systems) work especially well in the cloud. The following kinds of managed security services
are already available (and, in some cases, mature):

• Third-party monitoring and response (for vulnerabilities, configurations, intrusions, and

incidents)
• Antispam and web filtering
• Endpoint antimalware (management)
• Web application firewall
• Authentication and federated identity
• Third-party assessment

Customers and cloud vendors alike will be able to leverage “professional” security services and may
be able to supplement standards to impose a kind of order in the cloud through their partnerships and
alliances.

Technical Architecture Implications

In a cloud environment, activities once carried out on organization-owned endpoints, data centers, and
networks move across open, untrusted networks into large, dynamic data centers operated by the
vendors. Although network perimeters are still necessary at data center boundaries, they are not
widely used within data centers and are becoming less effective.

Public cloud service providers are not deploying network firewalls between multi-tenant customer
facilities. However, they are leveraging IDS systems, and some are starting to deploy network behavior
analysis systems that may also provide early warning against ruinous distributed denial of service
(DDoS) attacks. For more information, see the Security and Risk Management “Network Behavior
Analysis: Moving Beyond Signatures.”

To compensate, vendors and customers are encrypting data in transit and starting to attempt
separation strategies at the VM, virtual network, endpoint, identity, and application layers. Over time,
the desktop itself will be driven partway into the cloud with the aid of desktop virtualization as a coping
strategy for consumerization. In the long run, storage layer encryption should be used more heavily to
protect against accidental disclosure of information, hack attempts, and insider risks. Unfortunately,
multi-tenancy makes encryption more complex, and performance issues make bulk data encryption
run counter to cloud’s drive for higher capacity at lower cost. Some cloud vendors have compensated
for a lack of encryption by strengthening access control and application layer security. With PaaS and
IaaS, customers can encrypt for themselves, but only after resolving difficult key management
challenges. Over time, the issues of complexity, performance, and key management must be tackled;
storage encryption will become more common in the cloud as a way to mitigate many multi-tenancy
risks.

Identity management in the cloud is also needed for administrator access control, use control, and
accountability. Federated identity for end user cloud access and role-based administration for cloud
management are both important. Given the ubiquity of browser-based applications, cloud services may
benefit from anti-phishing and device identification mechanisms such as those used for online banking
systems.

Cloud provider and consumer organizations must also find models for managing the accounts of
individuals whom neither party employs. An opportunity exists for identity providers (IdP’s), with the
right business models. “Identity clouds” may help manage identities in clouds. At the same time, cloud
computing will accelerate the need to move from tightly coupled, domain-specific privilege
management mechanisms to loosely coupled, standards-based identity services. Vendors should be
supporting—and customers demanding—a number of mature standards, such as Security Assertion
Markup Language (SAML). Advanced reputation and dynamic trust management mechanisms remain
too immature, however, to be of much assistance for dynamic cloud service brokering.

Application security is a serious problem in the industry, and cloud computing brings both additional
risk and some new opportunities to the fray. Use of SaaS vendor offerings could reduce complexity,
and PaaS vendors could bake proactive security measures into the development process. However,
vendors are not there yet; lowest-common-denominator approaches (e.g., username and password or
minimal roles for administration) and security by obscurity prevail on the SaaS side, and PaaS
offerings are still in the very early stages of maturity.

Finally, widespread use of public cloud computing would deal some serious blows to the hopes for
security at the data level. Customers will not only lose much of the control over their data, they will also
have greater difficulty classifying, discovering, analyzing, retaining, protecting, and destroying it.
Encryption, data leakage prevention, and e-discovery processes would all suffer. It will be imperative
for the industry to develop—and cloud vendors to support—standards for log data and SOA data
services.

Recommendations
The following sections include recommendations for enterprises and for industry.

Recommendations for Enterprises

Organizations should be wary of serious consequences that might result from putting sensitive data
into the hands of cloud service providers. Figure 3 illustrates a bell curve wherein most customers will
likely adopt internal or hybrid cloud models to balance the benefits of cloud technology against the
risks.

Figure 3: The Bell Curve: Most Large Organizations Will Move Cautiously

Take Out a “Life Insurance Policy” for the Security Department

Burton Group spoke with a pharmaceutical company CISO who requires business units to sign a risk
acceptance sheet before using SaaS or other types of cloud offerings. This CISO regards the
procedure as a life insurance policy for the security department. Ideally, it causes executives to
understand and consider the risks. At the very least, it protects the security department from being
blamed for a decision that is out of its control and against which it has warned. Organizations should
also ensure that risk management processes have “hooks” into project management, budgeting,
purchasing, and contracting processes such that business users don’t make an end run around
security toward cloud computing.

Mind the Gap

Mind the gap before putting medium and high risk data or applications—especially ones with
regulatory connotations—into public clouds. Be prepared to work through challenging legal,
compliance, investigation, audit, key management, and other issues. As Jim Greavis of the Cloud
Computing Alliance likes to say, “Some of the cost savings from cloud computing need to be put back
into security.” Where compliance concerns are strong, data and applications may have to be excluded
from public clouds. Instead, large enterprises with the resources to maintain IT skills and build dynamic
data centers should start out with internal cloud and hybrid cloud strategies.

At the same time, give cloud computing a fair comparison. There is often a gap between what the
organization’s security policy describes and what its real-world implementation provides. If this is the
case, it may not make sense to hold cloud to standards that cannot even be met internally, especially if
cloud offers any opportunities to actually improve the situation.
Consider Building Internal Clouds

Large organizations maintaining data center capacity should take a leaf out of the public cloud
vendors’ book. They can make certain aspects of their internal IT environments look more like public
clouds by:

• Consolidating data centers

• Rationalizing applications

• Refactoring applications for browser-based access and SOA where appropriate

• Building up endpoint security for managed desktops

• Leveraging cloud-friendly security overlays (e.g., Secure Sockets Layer virtual private network
[SSL VPN] or other secure protocols)

• Deploying presentation virtualization or desktop virtualization solutions for unmanaged

desktops

• Standardizing and rationalizing the identity management environment for both users and
privileged users

Enhance Cloud Readiness and Maturity over Time

Some large organizations may be able satisfy all their needs using internal clouds, but most should
take a mixed, or hybrid, approach with an eye to improving their cloud readiness over time. To
accomplish this:

• Update policies and processes: Start by understanding the risks; then, update vendor
management, legal/contract, audit, incident response, identity management, information
classification, and other processes to take account of public and private (community) clouds.

• Used a mixed approach: Enjoy the best of both worlds through a combination of internal
clouds for medium- to high-risk functions and public clouds for applications that pose low (or
tractable) risks that can easily be outsourced to SaaS vendors or leverage the massive
scalability of IaaS.

• Build hybrid cloud capabilities: Refactor applications into services such that the low-
volume, less-sensitive functions can stay internal while higher- (variable-) volume, lower-risk
functions potentially move out to a public cloud. Consider disaggregating risk by employing
multiple vendors where functional tasks or workloads can be reasonably divided.

• Take baby steps into IaaS or PaaS environments: Some major cost savings may be
possible without much risk. Learning how to leverage public cloud offerings is important to
maturing cloud-ready security programs over the long haul. Over time, cloud providers will
improve their ability to satisfy enterprise security requirements, but don’t expect them to bend to
your requirements overmuch. Also look for opportunities to proactively enhance security in the
software development lifecycle (SDLC) where PaaS offerings have the right project
management, code scanning, separation of concerns, and testing features.

• Consider private (community) clouds: Consider private clouds with appropriate security for
sharing collaborative environments with external organizations. Engage like-minded vertical
 industry partners in a discussion of ways to coalesce demand and specify requirements for
private cloud offerings. Given enough size and simplicity (achieved through mass participation
and clearly specified requirements), private cloud cost savings might start to approach those
offered by public clouds. NIST is investigating private clouds for the U.S. government; the U.S.
Department of Defense (DoD) will likely contract out for its own instances of SaaS offerings.
Exostar and SecuritiesHub today provide trusted collaborative environments even among
competitors in the aerospace/defense and financial industries, respectively.

Simply put, organizations must prepare their architecture and governance processes for cloud. As
cloud transforms IT, it becomes part of the leveraged capability building that puts organizations on the
path to competitive advantage. A systematic, comprehensive security program rethink is an essential
part of the maturation process. So is architecture. As one CISO put it at a recent Jericho Forum
meeting, “We have to envision what multiple organizations collaborating together in the future look like,
and what ‘Lego blocks’ a generic organization must have to be part of that collaboration.”8

Start the architecture rethink with a look at Burton Group’s Reference Architecture principles. Evaluate
how cloud impacts your organization’s stance on outsourcing, second sourcing, degree of autonomy,
standards, and other questions, such as risk management and compliance.

As an organization’s architecture and governance mature to take better account of cloud, so should
consumer and small-business-oriented vendor camps improve their enterprise offerings. Hasten the
process by pushing the vendors toward greater transparency, disclosure, and standards support—all
of which have been found to improve security and increase the size of markets, which should be in the
vendors’ enlightened self-interest. Also, work with like-minded customers and vendors (through forums
such as the Cloud Security Alliance and Jericho Forum) to enhance industry readiness for cloud,
especially if your organization wants to move more aggressively on putting parts of medium risk
applications into public clouds than is suggested here.

Recommendations for Industry

Cloud vendors and customers should work to promote:

• More transparency and disclosure from cloud providers

• Greater jurisdictional uniformity of IT privacy, discovery, and investigations; potentially, cloud-

specific regulatory frameworks

• Third-party audit/assessment criteria (and qualified assessors) that are well scoped to specific
types of cloud computing services

• Better Internet security (e.g., secure Domain Name System [DNS], secure Border Gateway
Protocol [BGP], and secure identity)

• Better virtualization security and key management to separate customer data in cloud
environments

• Successful completion and adoption of log standards, identity standards, VM standards,

metadata standards, and so on

The Details
Cloud computing demands a rethink, though not a reinvention, of traditional security programs and
architecture. The following details that walk through the rethink are nontrivial and a core part of this
overview.

A Systematic, Comprehensive Security Program Rethink

Burton Group’s Security and Risk Management Strategies overview “A Systematic, Comprehensive
Approach to Information Security” (see Figure 4) and Reference Architecture template “Information
Security Technology Model” provide conceptual frameworks for considering (or rethinking) security
programs and security architecture.

Figure 4: A Systematic, Comprehensive Approach to Security

Business Risk Management

Business risk management is front and center in the systematic, comprehensive approach to security.
Risk is a function of threats, vulnerabilities, and consequences.

Understanding the Consequences

Organizations should be aware of potential consequences from the increased use of virtualization,
outsourcing, and possible dynamic interactions across cloud providers:

• Data location may be more dynamic and changing than in traditional hosting or outsourcing.

• Administration personnel (i.e., insider) assignments may also be more dynamic.

The dynamic characteristics of cloud services, combined with multi-tenancy, may hurt information
confidentiality, integrity, use control, and accountability objectives, thus increasing the likelihood of
legal, financial, or reputational consequences such as:

• Personally identifiable information (PII), classified, or export-controlled information going to

the wrong country, making an organization responsible for the data’s being noncompliant with
EU Data Protection, Canadian privacy legislation, or other national privacy or secrecy regulations

• Contractual obligations for information separation or licensing being violated

• Sensitive information being lost or damaged or suffering impeded access

• Sensitive information unnecessarily released to legal process by a provider leading to a loss

of Fourth Amendment protection (in the United States) against search and seizure

• Legal exposure due to degraded ability to manage or search data in the cloud for e-discovery
purposes

• Liability if facilities are compromised and used as attack bots or spam bots or to aid/abet other
harmful activities against third-party targets

• Lawsuits or penalties from a cloud vendor for violating service agreements

Use control failures can be especially consequential due to the cloud’s pay-as-you-go business model.
Every user, every cycle, and every bit stored or backed up gets counted. A distributed denial-of-
service (DDoS) attack could ring up large costs and disputes over who will pay.

Cloud computing improves availability primarily for organizations without the resources to build internal
high-availability, redundant solutions. But should a vendor fail to provide or maintain service level
agreements (SLAs), an organization could face operational and financial consequences: a loss of
service, supply chain degradation, and so on. For more ideas on how to analyze potential
consequences, see the Security and Risk Management Strategies overview “An Objectives-Based
Assessment Framework for Security Solutions.”

Beyond the risks to security objectives, cloud computing creates the same kinds of strategic risks as
outsourcing: dependency, a lack of knowledge transfer, and the potential for the vendor to emerge as
a competitor. On the flip side, however, if cloud computing is truly transforming IT, not becoming cloud-
ready may pose a greater strategic risk.

Risk Appetites and the Salesforce Question

Potential consequences, industry perceptions of how likely consequences are to occur, variations in
how aggressively regulations are enforced, and organizations’ risk appetites all affect risk
management.

Large organizations have been cautious in embracing public cloud computing offerings where
regulated information is involved. The exception to this so far has been the surprisingly wide adoption
of Salesforce, an application that often contains PII but does nothing to help enterprises comply with
European, Canadian, or other privacy regulations that attempt to restrict PII’s location to privacy-
friendly countries.

In some cases, Salesforce slipped in under the radar before enterprise security and risk managers
were aware of it, and some such organizations have since adapted their processes. (For example, a
CISO from a large pharmaceutical company described meeting with a CIO in panic after the
Salesforce phishing breach;9 fortunately, PII had not yet been loaded in the service so no incident
response was required. Today, the security policy in that company requires business managers sign a
risk acceptance sheet before using cloud or software-as-a-service [SaaS] services, and the CISO has
found that, in most cases, managers back away from adoption.) In other cases, organizations may
judge that Salesforce’s controls are adequate or that the PII being reposed in Salesforce is relatively
low risk (i.e., comprising mostly work contact information that some countries either do not consider PII
or regulate much less aggressively than home contact, financial, or medical information).

Threats and Vulnerabilities

One must also rethink threats and vulnerabilities in light of cloud computing. In addition to the vendor’s
own outsourcing, physical, and personnel vulnerabilities are the technical vulnerabilities covered in the
“Technical Safeguards” section of this overview. For example, cloud vendors could be infiltrated for
industrial espionage on a large scale. They could also be the targets of DDoS attacks conducted to
blackmail the vendor and/or its customers. Like power plants, clouds could be targets for sabotage or
abuse on a large scale; Amazon’s Elastic Compute Cloud was exploited by spammers,10 and innocent
customers’ machines may have been compromised.

Security Program, Posture, and Policies over Time

Cloud computing leaves organizations with less opportunity for preventive measures and a greater
need for detection, deterrence, and response (as discussed in the “Rethinking Security for Cloud”
section of this overview). See the Security and Risk Management Strategies overview “Implementing
Security Controls in Outsourced and Offshore Environments” for additional analysis and insight.

For public or private cloud services—as with other outsourcing arrangements—the fact that an
organization may not control all or part of the protection mechanisms usually does not absolve it from
compliance responsibilities. Although an organization’s level of control will decrease and public cloud
security offerings will mature, increasingly dynamic interactions among numerous vendors’ offerings
will continue to clash with regulatory compliance. Over time, this has the following implications for
security programs:

• In general, organizations may need fewer security technical staff but more auditors or lawyers.
• During the early years of transition to cloud, more operational security cloud specialist staff
may be required for strong service oversight.
• In the medium term, security organizations must emerge with the skills and training to
negotiate, monitor, and enforce agreements with cloud providers.
• In the long term, fundamental technical architecture changes at the data security and
monitoring and detection layers will be needed and will impact both the security organization and
the nature of cloud offerings.

Audit and Compliance

Cloud has no audit standards due to the breadth of cloud formats, and because audit and compliance
always tend to lag technology. For example, as described in the Security and Risk Management
Strategies overview “Audit and Attestation in Virtual Environments,” the Payment Card Industry Data
Security Standard (PCI DSS) currently contains “one function per server” verbiage that has been
construed by some auditors to forbid virtualization. But the PCI DSS established a working group to
clarify this point. Cloud’s audit uncertainties will mostly like also correct over time. The audit community
will catch up with the technology and specify appropriate requirements for the various types of cloud
vendors to meet. In the meantime, when confronted with Federal Information Security Management
Act (FISMA) reporting and National Institute of Standards and Technology (NIST) control objectives,
for example, cloud vendors such as Google claim “we meet them, but in a different way.” However,
customers and auditors need documentation, demonstration, and proof that this is true.
Audit options include accepting a cloud vendor’s self-assessment, reviewing a third-party assessment,
or sending staff to conduct an organization’s own assessment. Although many organizations do
dispatch their own audit teams to vendor sites, reviewing a third-party Statement on Auditing
Standards (SAS) 70 Type 2 audit (and sometimes an International Organization for Standardization
[ISO] 27001 certification or PCI audit as well) is the most common approach.

When it comes to SAS 70, your mileage will vary. The audit reports are often outdated, and the scope
of the control objectives they cover may or may not be appropriate to the customer’s needs or
intended use of the service. Sometimes to protect sensitive or proprietary details, a vendor only lets a
customer see the Statement of Findings; but even if the customer can see the whole report, it often
does not describe enough information about the control activities to satisfy assessment requirements.

Security architects and auditors alike often have trouble applying conventional security wisdom to
dynamic, multi-tenant cloud offerings. Vendors have optimized these public clouds for maximum
performance at the lowest cost. Typically, public clouds do not deploy network firewalls or application
firewalls (as required for PCI and other security regimes) between IT facilities used by multiple
customers. Technologies like virtualization are themselves hard to deal with in an audit because the
controls are immature and the auditors’ interpretations nonstandard. Although there are niche service
providers that claim PCI compliance or certification, it is hard to see how a customer could deploy or
build a PCI-compliant solution within Amazon’s Elastic Compute Cloud (EC2) or Google App Engines
today.

PCI vulnerability scanning requirements raise another audit question: Should customers contract with
an external resource to perform penetration testing or ethical hacking against cloud providers or simply
require that a provider conduct such tests and provide reports? If a customer performs a scan, must it
inform the cloud provider it is doing so? Without legal protection, liability may be incurred if the test
goes wrong.

Incident Response, E-Discovery, and Investigations

Investigation, e-discovery, and incident response are particularly difficult in cloud environments. Not
only must processes be coordinated between an organization’s teams and the teams of one or more
outsourcers, but the organization may lack access to the necessary systems and logs. A customer
may not even find out about an incident whose consequences might have been nipped in the bud.
Given a vendor’s contractual requirements to protect other customers’ assets existing cheek by jowl in
the same multi-tenant systems and logs, investigations are particularly touchy. Dealing with these
issues depends on the vendor’s:

• Architectures for separating customer data

• Internal separation-of-duty mechanisms
• Forensics, log management, and reporting mechanisms

. . . as well as the vendor’s ability to:

• Respond to a customer’s investigation request by investigating any failures in the vendor’s

own staff, systems, or process
• Produce the data relevant to one customer only
• Provide an appropriate level of oversight to the customer
• Defend its investigation process and conclusions in court

If cloud services are used for sensitive applications or data that may fall under investigative and
disclosure requirements, it is important to assess a vendor’s investigative abilities and to ensure that
its contract defines:

• What an incident is
 • How the customer is notified
• What rights the customer will have to access the resources (and staff) necessary for response
to incidents, e-discovery requests, or other investigations

Development and Operational Procedures Including Change Control and

Testing

Organizations often have requirements for separating research and development (R&D) from the
testing and production environments. SaaS environments take all or most of this burden, but platform-
as-a-service (PaaS) and infrastructure-as-a-service (IaaS) environments do not and may, in fact, make
changes outside of change control that have ripple effects on their customers.

Cloud computing can provide a big advantage for software vendors needing to maintain multiple
configurations, but it can, in some cases, be expensive because vendors charge for the usage in all
environments. If hybrid cloud simulation and staging capabilities are present, it may be possible to
perform some low-capacity utilization R&D and test internally before moving functions to the cloud and
conducting final tests.

PaaS environments could provide an opportunity to bake security into the software development
lifecycle (SDLC), but only if a vendor provides the tools and processes described in the “Application
Security” section of this overview.

Legal and Vendor Management

Appropriate legal processes can help identify, mitigate, and perhaps transfer at least some cloud
computing risks. Although cloud computing introduces many new risks and it is clear that the vendors
are in no hurry to take on liability or risk, some opportunities for risk transfer may still exist.

Should a brand name cloud offering experience a breach, the service provider as well as the customer
may suffer reputation damage. “The bigger the brand, the bigger the breach” might be an argument for
transferring risk by selecting a cloud vendor with a strong reputation to protect. Organizations should
transfer risk to cloud computing vendors, where possible, by negotiating shrewd contracts, but also by
analyzing the incentive structure inherent in the business relationship.

Maturing vendor management processes for risk mitigation or risk transfer purposes will be especially
important. Organizations using cloud must effectively trust not only the immediate cloud provider, but,
potentially, an entire supply chain of other providers downstream. An organization may audit and vet
the immediate provider, but still suffer a control failure or breach from an indirect supplier.

Obtaining and enforcing SLAs through the vendor management process is also important to risk
transfer and availability objectives. In general, when outages occur, there is little recourse other than
the possible refund of fees. Few companies have the leverage to demand stringent SLAs with
penalties for major outages. Other customers simply aren’t prepared to forego the cost savings of the
basic package to upgrade to a more costly premium service with better guarantees.

Technical Safeguards

Depending on the nature of the cloud offering, technical safeguards will be needed at various layers of
the information security technology model: network and perimeter; client and server endpoints and
data centers; applications; data or content; and the security management infrastructure.

Network Perimeters’ Declining Role

The Security and Risk Management Strategies overview “Shifting Defenses: Security Futures for
Networks, Applications, and Data” discussed the deperimeterization phenomena wherein many
aspects of an organization’s business are externalized due to telecommuting, outsourcing, and
partnering. Cloud computing is high on the list of externalizing forces.

In a cloud environment, activities once carried out on organization-owned endpoints, data centers, and
networks move across open, untrusted networks into large, dynamic data centers operated by
vendors. Network perimeters are still used at the boundaries of cloud data centers and organization
networks, but few, if any, “hard” network perimeters are within data centers (to separate tenants’ data)
for fear of a negative performance impact. In general, cloud vendors don’t physically separate, or
provide network segmentation for, customer data.

Nor, in most cases, can customers configure their own packet-filtering rules on the cloud vendor’s
firewalls. And, since Internet Protocol (IP) addresses are recycled (i.e., reused) they are becoming less
reliable for filtering.

Transforms can provide some separation, thus furthering confidentiality, integrity, accountability, and
use control security objectives—but not protecting availability. For example, customers can ensure that
their virtual machines (VMs) or applications in IaaS and PaaS clouds sign and/or encrypt data in
transit.

Vendors are deploying separation mechanisms at other layers. With traditional network security’s role
diminishing and data-level security progress being set back (at least in the short term) through cloud
adoption, organizations will need to strengthen endpoint, identity, and application-level security
mechanisms.

Endpoint Security and the User Networks

The desktop is moving into the cloud as unmanaged and mobile client endpoints proliferate. But there
are some silver linings on the emerging technology horizon:

• Smartphones could become a strong authenticator in every pocket11 (through software one-
time password [OTP] technologies and appropriate password protection and other device
security mechanisms).

• Application virtualization or desktop virtualization can mitigate the risk that information sprawl
and unmanaged endpoints pose to organizations (for more information, see the upcoming
Security and Risk Management Strategies document “Endpoint Virtualization: Reducing Costs,
Malware Risk, and Information Sprawl.”).

• Secure personal portable storage devices (PPSDs) can encrypt user information on the move
and perhaps bootstrap endpoint trust.12

As these technologies mature, they may start to compensate for the decline of managed desktops in
the enterprise.

Servers and Data Centers

With a lack of network perimeter segmentation inside dynamic data centers, virtualization is emerging
as the new frontier for network separation. Customer workloads and data can run on separate VMs.
Separation by VM is inherent to an IaaS service that sells capacity by the VM. VM separation may also
be used if SaaS or PaaS services allocate customer workloads to dedicated VMs.
Customers typically need multiple VMs for scalability or to perform multiple roles. These VMs can be
separated from other customers’ VMs into logical zones or subzones using a distributed virtual firewall
and policy infrastructure that is aware of VM identities and can even track the movement of VMs when
technologies such as VMware’s VMotion are used. Smart and dynamic virtual network security is
complex13 and its deployment is in its infancy, however. Vendors may allocate VMs in a static manner,
thus making separation policy easier to describe or enforce—or, more likely, not separate virtual
networks, at least for today.

Cloud Storage

Unencrypted (raw) cloud storage can greatly enhance availability. A large global manufacturing
company we spoke with has investigated public cloud solutions to provide content delivery networks
for rich public (web) media. A large global retailer envisions securely abstracting applications from
encrypted storage using an application programming interface (API) at the virtualization layer. A large
pharmaceutical company envisions multiple, redundant arrays of independent cloud (RAIC) storage,
which will be encrypted in the future. See the Data Center Strategies overview “Cloud Storage: An
Emerging Market” for more information on availability, archival, and disaster-recovery-oriented
offerings.

Encryption of data at rest could provide strong separation. However, due to performance issues, public
cloud vendors generally do not separate the bulk of customer data using encryption. Customers
attempting the encryption themselves run into the complexity of key management. Per the Security
and Risk Management Strategies report “Enterprise Key Management Systems,” key storage and key
management interfaces are already very challenging. Now, key management must be extended to
cover encryption of storage used by applications in VMs (e.g., IaaS) and custom applications (e.g.,
PaaS) deployed and developed in clouds containing PII or other sensitive data.

While some backup systems may be configured with simplistic key management approaches, more
complex application, development, or transaction environments require multiple keys to disaggregate
risk and strengthen the separation of duty across multiple roles. Vendors and service providers will
ultimately make cloud storage encryption work with adequate key management standards interfaces,
caching design, hardware accelerators, and other practices or resources. However, higher storage
encryption costs will be reflected in internal cloud deployment costs or the rates charged to public and
private (community) cloud customers.

Access Control

Access control is critical for separating customer zones and data from one another. Along with audit of
privileged administrator actions, access control is also desirable to control privileged users and
administrators in the cloud. However, separation of duty may not be possible since most providers
don’t offer role-based administration. Also, access control may be ineffective against privileged
administrator accounts, which must be issued to manage services and are themselves prime targets of
privilege escalation attacks. For more information, see the Identity and Privacy Strategies report
“Privileged Account Management: Addressing the Seedy Underbelly of Identity.”

SaaS application containers process transactions from multiple customers, generally separating this
data in use only through access controls in the application logic. Some use isolated database
instances to separate the data at rest for multiple customers. Some providers, such as Google or
Salesforce, have confused customers by claiming they control access by dispersing customer data
across many different systems or storage devices. However, these mechanisms were conceived for
redundancy, not security. They use locator tags rather than encrypted indexes.

Identity Management
Identity management underpins access control mechanisms and provides a vital control point for cloud
usage by business units, groups, and individuals. Customers have shared two cloud-related identity
management concerns:

• Controlling workforce cloud accounts or entitlements to multiple services: Browser-

based administration and use of cloud services is seductively easy. But cloud providers generally
do not provide role-based administration, strong authentication, network admission and access
control (NAC), and audit features that are commonly used for remote access to enterprise
resources. Without remote access security, potentially anyone could masquerade as a master of
the organization’s clouds exactly as occurred during the Salesforce phishing breach.9 By putting
centralized access control for cloud services in place (perhaps requiring users to go through
administrative portals or federate login to all cloud services), an organization would gain several
advantages. Doing so would provide reduced sign-on; mitigate risk of administrator
impersonation; gain knowledge of which business units, groups, and individuals are using cloud;
and optimize the number of cloud “seats.” Identity is an important control point to cloud.
• Managing the credentials, entitlements, and attributes of individuals whom neither the
enterprise nor the cloud vendor employs: It may be a critical success factor for organizations
and their cloud vendors to personalize services, protect privacy, and manage service lifecycles
for third-party users (such as consumers, citizens, or students) even though neither the
organization nor the vendor employs or has custodial relationships with those users. Managing
this problem is something that itself can be outsourced either to a neutral third party or other
identity provider able to concentrate on developing an ongoing relationship with the user and
keep digital identity fresh and strong. A number of identity providers, such as Covisint and
Exostar, already are effectively private clouds. VeriSign is working to position its OTP-managed
identity service as a cloud offering. Identity clouds may help manage identities in clouds.

Given the ubiquity of browser-based access to cloud services, anti-phishing becomes a major concern.
Service providers should consider implementing anti-phishing services and device identification or
other controls to detect warning signs that a user’s computer or credentials may have been
compromised. For information on how such controls have been used in the browser-based online
banking environment, see the Identity and Privacy Strategies “Consumer Authentication and the
FFIEC Guidance.”

Organizations that outsource the hosting of data, VMs, applications, and even application development
to the cloud remain responsible for access controls to these environments. Users, resources,
entitlements, and policies must be defined, evaluated, and enforced for cloud just as for internal
networks using the same kind of artifacts (e.g., rules, roles, and groups) that are used on internal
networks. But access control technologies (e.g., Active Directory) that have worked well within
domains don’t scale well to cloud environments where resources are distributed across physical
networks and domains of control. On the other hand, entirely new proprietary privilege management
frameworks from the cloud vendors (e.g., Amazon’s Access Policy Language) will create new identity
management silos and add to the provisioning work organizations have to do.

A more standards-based, service-oriented approach to access control is needed. Cloud customers,

cloud vendors, and identity service providers all require standards to increase the professionalism,
interoperability, and reusability of the identity management functionality, including:

• Security Assertion Markup Language (SAML) that provides federated authentication, attribute
queries, authorization decisions, and claims
• Service Provisioning Markup Language (SPML) that provides federated provisioning
• Extensible Access Control Markup Language (XACML) that provides a standard for
authorization and policy information
• Standards for security token services from Information Cards, OAuth, OpenID, and others that
may also support cloud computing use cases
• The Liberty Identity Assurance Framework (LIAF) standard for auditing and accrediting first-,
second-, or third-party identity services
Today, only some of the cloud providers support SAML, SPML, or XACML in their customer-facing
services, and their interface profiles vary. Organizations still require integration middleware services
from web access management vendors or solutions from vendors, such as Symplified, that specialize
in proxying access credentials and site-specific logins to cloud providers.

The Jericho Forum Collaboration Oriented Architecture (COA)8 has examined aspects of identity
management beyond user authentication and authorization. The COA envisions reputation brokers
and contract databases as ways to manage the identities of organizations and the cloud services
themselves, as well as the identities of the users. But reputation and dynamic management of trust
relationships are both difficult concepts, and the industry needs to put more meat on the conceptual
bones of these ideas before they can be broadly applied.

Application Security

Software security is a serious problem in the industry:

• Per the Open Web Application Security Project (OWASP) Top Ten, web applications have
numerous vulnerabilities, such as cross-site scripting.
• There are significant “patch gaps” between the time researchers or other organizations find
vulnerability information and the time vendors make patches available and organizations deploy
them.
• The browser is sick,14 with plug-ins, mashups, and user generated content breeding ever more
vulnerability.
• There’s no viable “Underwriter’s Laboratory (UL)” for software, and application whitelisting is
problematic.

Enter SaaS. On the downside, SaaS comprises multi-tenant applications running on shared
infrastructure and storage. Generally, SaaS vendors don’t support application firewalls (which can
cover many of the problems from the list above) nor can customers deploy them. Vendor lock-in and
lowest-common-denominator security abounds. On the other hand, some SaaS offerings are fairly
purpose specific and allow limited degrees of user organization customization. The virtue of relative
simplicity could be less vulnerability.

PaaS, however, opens a Pandora’s box of threats and vulnerabilities at the application layer that
includes:

• Tech savvy, creative users

• Developers requiring and getting administrator-level privileges, or more privilege than the
standard user
• Complex, user-generated content input to a system during development
• Integration and plug and play of applications, services, and databases
• All of the above may play out in a rich multi-tenant soup of patented IP (and interesting test
data)

What could possibly go wrong?

On the positive side, vendors have the opportunity to help themselves (and customers) get proactive
about security in PaaS environments. PaaS APIs, integration options, and tools can be set up as
“secure by design” and “secure by default” to:

• Enforce a separation of concerns by standardizing and externalizing security functions, such

as authentication, authorization, cryptographic operations, and logging.
• Enforce consistent service orientation by enabling hybrid cloud architectures that can move
sensitive functions into an internal cloud.
 • Enforce a consistent SDLC—with security built in—and perform code scanning and
vulnerability scanning.

Data Security

There’s no getting around the issue that with cloud computing, customers lose control of their data, at
least to some degree. Even their ability to read their own data is limited to the interfaces that the cloud
vendor provides. Encryption, data leakage prevention, and e-discovery all become more difficult as
customers lose visibility as well as control.

Cloud customers have the following difficulties:

• Organizations may be required by contracts or laws to keep data in or out of particular

jurisdictions.
• Data location is hard to control, even at a coarse level (e.g., “Europe” or “not Europe”) and
many cloud offerings will not guarantee data location.
• Data location and data retention will be hard to control at a fine-grained level:
o It may be impossible to agree on industry standard semantics for metadata (data
about the data) that could be used to tag data with type, location, and other attributes or
requirements for fine-grained control.
o With limited visibility, data classification may be more difficult to perform
retrospectively with data mining tools.
• Data origin, or lineage, will be more difficult to determine.
• Data destruction (sanitization) may be more difficult to ensure.

Although organizations such as Microsoft have made impressive strides with enterprise digital rights
management (DRM), the industry still lacks an open, interoperable, royalty-free, and scalable DRM
standard by which organizations can cement controls directly onto the data on a wide scale. Just as
industries are slow or unable to agree on metadata semantics, jurisdictions may be unlikely to agree
on privacy, discovery, and liability issues.

In the end, it’s all about the data. There is a theory (explained in the Security and Risk Management
Strategies overview “Shifting Defenses: Security Futures for Networks, Applications, and Data”) that
data security will become the most important information security layer someday. But cloud computing
poses challenges to an organization’s ability to pursue this vision. Organizations might make some
gains by insisting on multiple, service-oriented interfaces and standards-based access to their cloud-
resident data.

Control Layer: Monitoring and Detection

Considering the weakness of separation in cloud environments (i.e., few perimeters or storage
encryption mechanisms), intrusion detection is an important compensating control. A CISO from a
large, early-adopter company was impressed when Amazon notified his staff that one of the
company’s Amazon Machine Images was compromised; he said, “That wouldn’t have happened on
our internal network.”

Cloud vendor support will be needed because it’s unlikely that enterprise intrusion detection systems
(IDS) or security information and event management (SIEM) systems will be put on the cloud
premises. At best, an organization can collect logs or alerts from its own IaaS or PaaS applications;
otherwise, the organization sees only what the vendor wants it to see. The vendor will need to
separate events from different customers and clean sensitive data from the logs. And until the industry
develops common event and log standards (see the Security and Risk Management Strategies
overview “Leveraging Event and Log Information: A Strong Case for Standards”), correlating
information between the enterprise and the cloud will be an uphill struggle.
Control Layer: Security Management

Security management will be another cloud challenge. Additional tools will be needed to orchestrate
and control hybrid cloud arrangements. For example, VMware has a product that can move VMs back
and forth between internal dynamic data centers and public clouds. However, more role-based
administration and audit controls, as well cryptographic locks and authorizations on the VMs, are
required to protect against insider abuse. Vordel has a cloud gateway security product with auditing,
monitoring, encryption, and access control functions. Other kinds of products—such as an enterprise
service bus, web services management, business process orchestration, and so on—will be needed
as organizations seek to move low-risk, high-volume parts of applications to public clouds while
keeping medium-risk, low-volume tasks internal.

Operations policies often mandate separate R&D, test, and production environments—but cloud
vendors charge for every bit, cycle, or instance of technology. Vendors such as Configuresoft are
evaluating how to extend operations and change management workflow automation to hybrid cloud
environments.

Conclusion
Cloud computing creates significant risks and requires a rethink—but not a reinvention—of security
programs and architectures. Large enterprises should avoid placing sensitive information in public
clouds unless they can obtain strong assurances of appropriate protection from all the vendors
involved. To use public clouds, organizations must change their security postures; to use internal or
hybrid clouds, they must change architectures.

Notes
1
“CloudComputing:Incidents Database,” Cloud Computing Community.
http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database.

2
“IDC Enterprise Panel, August 2008” found 74% of enterprise customers surveyed concerned about
the security of cloud computing.

3
“Security Guidance for Critical Areas of Focus in Cloud Computing.” Cloud Security Alliance. Apr
2009. http://www.cloudsecurityalliance.org/guidance/csaguide.pdf.

4
Carolyn Duffy Marsan. “The Google-ization of Bechtel.” Network World. 3 Nov 2008. Accessed online
1 Mar 2009. http://www.networkworld.com/news/2008/102908-bechtel.html?fsrc=netflash-rss.

5
Bob Blakley. “Risk Management: Concepts and Frameworks.” Burton Group. 5 Sep 2007.
http://www.burtongroup.com/Client/Research/Document.aspx?cid=282.

6
“Cloud Cube Model: Selecting Cloud Formations for Secure Collaboration.” Jericho Forum. Apr 2009.
http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf.

7
“Global State of Information Security Study.” PricewaterhouseCoopers.
http://www.finextra.com/finextra-
downloads/newsdocs/Safeguarding_the_new_currency_PwC_GISS2008.pdf.

8
“Collaboration Oriented Architecture.” Jericho Forum, Open Group. http://www.google.com/url?
sa=U&start=1&q=http://www.opengroup.org/jericho/COA_v1.0.pdf&ei=RrYGStzBE9TBtwemlLCvCQ&u
sg=AFQjCNHTIyM82dxQGhoTyyZagbikaX1yvw.
9
Tom Espiner. “Salesforce Staff Speared by Phishers.” ZDNet UK. Nov 2007.
http://www.zdnet.com.au/news/software/soa/Salesforce-staff-speared-by-
phishers-/0,130061733,339283594,00.htm.

10
Brian Krebs. “Security Fix: Hey Spammers Get off my Cloud!”
http://voices.washingtonpost.com/securityfix/2008/07/amazon_hey_spammers_get_off_my.html.

11
Saul Hansell. “What’s the Password? Only Your iPhone Knows.” The New York Times. 31 Mar 2009.
http://bits.blogs.nytimes.com/2009/03/31/whats-the-password-only-your-iphone-knows/?
scp=1&sq=password%20generator&st=cse.

12
Mark Diodati. “Potential Market Disruptor: The Personal Portable Security Device.” Burton Group. 17
Feb 2009. http://www.burtongroup.com/Client/Research/Document.aspx?cid=1525.

13
Dan Blum, Eric Maiwald, Drue Reeves. “Virtualization Security.” Burton Group Security and Risk
Management blog. 5 Mar 2009. http://srmsblog.burtongroup.com/2009/03/virtualization-security.html.

14
Ramon Krikken. “The web browser is sick . . . but where’s the cure?” Burton Group Security and
Risk Management blog. 14 Aug 2008. http://srmsblog.burtongroup.com/2008/08/the-web-browser.html.

Related Research and Recommended Reading

“Cloud Cube Model: Selecting Cloud Formations for Secure Collaboration.” Jericho Forum. Apr 2009.
http://www.opengroup.org/jericho/cloud_cube_model_v1.0.pdf.

“CloudComputing:Incidents Database,” Cloud Computing Community.

http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database.

“Collaboration Oriented Architecture.” Jericho Forum, Open Group. http://www.google.com/url?

sa=U&start=1&q=http://www.opengroup.org/jericho/COA_v1.0.pdf&ei=RrYGStzBE9TBtwemlLCvCQ&u
sg=AFQjCNHTIyM82dxQGhoTyyZagbikaX1yvw.

“Global State of Information Security Study.” PricewaterhouseCoopers.

http://www.finextra.com/finextra-
downloads/newsdocs/Safeguarding_the_new_currency_PwC_GISS2008.pdf.

“IDC Enterprise Panel, August 2008” found 74% of enterprise customers surveyed concerned about
the security of cloud computing.

“Security Guidance for Critical Areas of Focus in Cloud Computing.” Cloud Security Alliance. Apr 2009.
http://www.cloudsecurityalliance.org/guidance/csaguide.pdf.

Amazon has developed a white paper on its security practices and technologies for IaaS cloud
computing: “Amazon Web Services: Overview of Security Processes.” Amazon Web Services. Sep
2008. http://s3.amazonaws.com/aws_blog/AWS_Security_Whitepaper_2008_09.pdf.

Bob Blakley. “Risk Management: Concepts and Frameworks.” Burton Group. 5 Sep 2007.
http://www.burtongroup.com/Client/Research/Document.aspx?cid=282.

Brian Krebs. “Security Fix: Hey Spammers Get off my Cloud!”

http://voices.washingtonpost.com/securityfix/2008/07/amazon_hey_spammers_get_off_my.html.

Carolyn Duffy Marsan. “The Google-ization of Bechtel.” Network World. 3 Nov 2008. Accessed online
1 Mar 2009. http://www.networkworld.com/news/2008/102908-bechtel.html?fsrc=netflash-rss.
Dan Blum, Eric Maiwald, Drue Reeves. “Virtualization Security.” Burton Group Security and Risk
Management blog. 5 Mar 2009. http://srmsblog.burtongroup.com/2009/03/virtualization-security.html.

Dan Blum. “Shifting Defenses: Security Futures for Networks, Applications, and Data.” Burton Group.
11 Jul 2008. http://www.burtongroup.com/Client/Research/Document.aspx?cid=1370.

Drue Reeves. “Cloud Computing: Transforming IT.” Burton Group. 20 Apr 2009.
http://www.burtongroup.com/Client/Research/Document.aspx?cid=1681.

Mark Diodati. “Potential Market Disruptor: The Personal Portable Security Device.” Burton Group. 17
Feb 2009. http://www.burtongroup.com/Client/Research/Document.aspx?cid=1525.

Ramon Krikken. “The web browser is sick . . . but where’s the cure?” Burton Group Security and Risk
Management blog. 14 Aug 2008. http://srmsblog.burtongroup.com/2008/08/the-web-browser.html.

Saul Hansell. “What’s the Password? Only Your iPhone Knows.” The New York Times. 31 Mar 2009.
http://bits.blogs.nytimes.com/2009/03/31/whats-the-password-only-your-iphone-knows/?
scp=1&sq=password%20generator&st=cse.

Tom Espiner. “Salesforce Staff Speared by Phishers.” ZDNet UK. Nov 2007.
http://www.zdnet.com.au/news/software/soa/Salesforce-staff-speared-by-
phishers-/0,130061733,339283594,00.htm.