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&usg=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&usg=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.