In previous posts, we discussed some of the ways in which clouds are built, and major ways in which they differ—and don’t differ—from non-cloud infrastructures from a security perspective. In this post, we’ll discuss some of the security challenges that are more or less unique to a cloud environment. These include privacy and data separation issues, isolating operational impacts, and dealing with well-meaning but uninformed courts and law enforcement.

A major issue that comes up in cloud conversations is privacy. Multi-tenancy on shared hardware necessarily implies a logical, rather than a physical, separation of customer data. At a fundamental level, this means that various pieces of software must be entrusted to keep different environments inaccessible from each other.

The key piece of software is the underlying hypervisor software, which has evolved over time, so the core technology is fairly well trusted. The biggest risk comes from configuration management—it’s imperative that a cloud provider implements the virtual environments without any errors or oversights in the isolation settings.

For example, when a cloud provider collects performance data, or performs any kind of forensics, it’s critical that the provider not accidentally access and potentially reveal other customers’ data. The possibility of mistakenly revealing data creates a need for multiple logical control layers to compensate for the potential human error. Nevertheless, a single setting in the control configuration can prevent data leakage, so it’s important for providers to have strong operational discipline and change management practices.

Another related security challenge in a cloud environment is the need to isolate operational impacts. There are various ways in which a single customer can impact the performance of the underlying cloud infrastructure and the other customers sharing it, creating a potential denial of service situation. Malicious activity by the customer is an obvious one, but cloud-users should understand that an external entity might compromise a virtual server within a customer’s environment, and take malicious actions without the knowledge or consent of the customer. This malicious activity could be designed to impact the cloud infrastructure, as in the case of a packet flood, or the damage to the cloud infrastructure could be collateral, as in the case of a spam flood, which could cause the cloud’s IP subnets to be placed on various blacklists.

Even in the absence of malicious intent, a single customer might unwittingly create a denial of service situation. A simple example—during the normal operation of a (poorly behaved) application virtual infrastructures can be susceptible to IO-intensive activities, such as forensic data gathering and analysis for incident response, subpoena service, etc. For these reasons, it’s important for a cloud provider to implement robust workload distribution across clusters, and to consider the impacts of specialized activities. There is no room for operational fragility.

Finally, an often-overlooked area in cloud management is collaborating effectively with courts and law enforcement. Courts and agencies are often used to dealing with non-cloud environments. They may be trained in the use of physical disk imaging tools that are recognized by the courts, and these tools may not deal efficiently with virtual storage technologies used in cloud environments.

What’s more, these agencies often don’t understand the impact of their requests within the context of a cloud infrastructure. We’ve seen overly specific subpoenas that describe steps to be taken—steps that simply won’t work in a cloud infrastructure, or would take an entire cloud cluster offline while every drive in that cluster is imaged for forensic analysis! There are often more effective and more efficient techniques available, and cloud providers should cultivate relationships with local, state, and federal agencies to encourage the use of improved tools and techniques in a cloud environment.

In the next article in the series, we’ll discuss some solutions to the issues that underlie these challenges.

This week we’re going to talk about the key cloud infrastructure design elements that impact security. The two most important design decisions are full versus partial resource allocation, and physical versus virtual-only instrumentation. It’s hard to say which is most important—they are both critical to cloud security.

When a cloud provider chooses to run a full resource allocation model, they’re choosing to deploy enough physical capacity to run all customers at 100% utilization simultaneously. In other words, there are enough physical resources to cover 100% of the virtual resources sold to every customer. In most cases, there is some additional physical capacity available in excess of what has been sold to customers, and this excess capacity is often used for “burst” capacity on a best-effort basis.

This approach allows the cloud provider to deliver some guarantees about minimum performance thresholds. The target market for this kind of environment tends to value uptime and security, so the providers tend to build more robust infrastructures, including more investment in instrumentation, monitoring, etc. They also tend to be more full-service providers; with packages covering a selection of managed services layered over the base cloud offering.

The alternative to full resource allocation is partial resource allocation. Compared to full allocation, this approach targets a more optimized use of physical resources, which leads to fewer unused compute and storage capacities in the overall infrastructure. This may lower costs. Of course, this optimization requires some ad-hoc resource allocation, which, in turn, leads to complex data isolation issues (it’s hard to know which piece of hardware is housing or processing which customer’s information).

The target market for the partial resource allocation model is cost-sensitive, such as developers, startups, incubators, and so forth. Many well-funded customers also use these inexpensive kinds of clouds for quick proof-of-concept deployments. Bottom line, the user communities for these kinds of clouds have more of a “Wild West” feel. It is also important to remember that cyber thieves and other “bad guys” fit this target market description.

Besides the full vs. partial allocation question, providers need to decide whether to use physical or virtual instrumentation for security visibility. Last week, we discussed how cloud infrastructure is in many ways a lot like non-cloud infrastructure—there are racks of compute and storage capacity connected by network pipes. In a cloud environment, there is also a virtualization layer, on top of the physical infrastructure.

When a provider chooses to deploy security instrumentation at the physical level, what they’re really doing is using instrumentation that isn’t necessarily aware of the virtualization layer. The provider can leverage the same instrumentation for their services, whether in the cloud or otherwise. Usually, any host-based instrumentation is done at the operating system level, both with the virtual machines comprising customer infrastructure as well as the physical machines that host all the virtualization.

Benefits of this approach include the large array of well-tested commercial off the shelf (COTS) instrumentation available and it’s also easier to guarantee that there’s no impact to customers from the instrumentation deployments. However, depending on the details of the compute and network infrastructure, some additional work is often necessary for the provider to make sure all relevant data is visible to the physical instrumentation deployment.

In contrast with physical instrumentation, virtual-only instrumentation leverages the hypervisor for visibility. There is a complex interaction between the virtualization layer and the instrumentation tools to make network traffic available to the security tools, as well as the contents of disk and memory. The benefits of this kind of instrumentation are clear: the provider doesn’t have to design the infrastructure specifically to enable visibility at the physical level. That said, these appliances rely on hypervisor access methods that are varied and ever changing, tying the cloud provider to a particular virtualization technology. Many of these tools are also unable to function outside a virtual environment, forcing the provider to use a different technology for non-cloud instrumentation.

Next week, I’ll present some of the security challenges that are more (or less) unique to cloud environments. Stay tuned!

In order to understand cloud security, we must first understand clouds. How are they built?  How are they managed?  What makes clouds different from a security point of view?

Let’s look at the infrastructure first. It turns out that cloud infrastructures are not entirely different from large non-cloud infrastructures; cloud providers build big clusters, with racks of computational and storage capacity. The biggest difference is the presence of ubiquitous virtualization in a cloud infrastructure.

The value-add of this virtualization is in the multi-tenancy feature. A cloud is all about using the same hardware resources for multiple purposes. A cloud provider must deploy some front-end software for the various users to manage their slice of the hardware, and some back-end hardware for support staff to manage the physical hardware, the virtualization layer, and the network plumbing that connects it all.

Though multi-tenancy of hardware resources is what all cloud providers have in common, they compete in many ways, including:

   – Features and usability of the front-end user interface

   – Robustness and uptime guarantees of the underlying infrastructure

   – Integrated security, backup and other services

   – Better network plumbing, support, and overall flexibility

In the same way that the back-end infrastructure looks a lot like non-cloud infrastructures, similarly cloud security looks a lot like non-cloud security. Providers still need to solve the classic problems, such as patching, firewalls, intrusion detection system (IDS), A/V, etc. At a high level, these problems include the visibility and instrumentation to detect malicious activity, as well as the staffing and operational integration to respond appropriately.

Here again, the big difference lies in multi-tenancy. When cloud providers are also security service providers, they can leverage shared instrumentation and staffing for greater ROI. They can also leverage analysis across multiple customers for enhanced situational awareness when a sophisticated attack might otherwise look like a simple, low-urgency event.

As for reactive security operations—that is, incident response and forensics—these also rest on solid fundamentals that apply to cloud and non-cloud environments alike. Providers need to identify relevant data, from disk and log data to memory forensics and other emerging disciplines. Then they need to perform forensically sound acquisition and analysis of that data.

There are some important differences, though. Multi-tenancy can make forensics and IR in a cloud environment a little different. There are privacy implications, for example, as well as potential performance impacts from IO-heavy data acquisition and analysis efforts. Side effects matter, too. One obvious side-effect is that, with ubiquitous virtualization, a whole host of additional tools and techniques become available. For example, snapshots of the virtual environment can be an invaluable forensic resource. With centralized log aggregation, integrated backup data, and other services integrated into the Cloud fabric, the incident responder or forensic analyst may need to coordinate in ways that are different from non-cloud environments.

In the end, you can think of cloud as a kind of outsourcing. Consider classical approaches to full-service outsourcing—essentially, an outside firm provides Service Level Agreements for performance and security. Benefits to the customer include reduced cost and better access to expertise, while challenges include agreeing on clear priorities and responsibilities. Cloud computing is fundamentally similar, but since ubiquitous virtualization is the core enabler, there is a lower entry barrier for providers, so the market has exploded with multiple vendors, feature sets, and price points available.

Two weeks from today, we’ll talk about practical application of these principles in popular cloud operating models.

In many ways, a cloud computing operator deals with the same information security issues as any other computational infrastructure provider.  Patching, firewalls, IDS and the whole host of familiar security tools and processes are an essential foundation for effective security.  Likewise, the forensic capabilities of a cloud provider stand on familiar foundations, including classic log and disk forensics, as well as memory forensics and other emerging or rapidly evolving disciplines.

However, the underlying enabling technology of cloud computing brings with it some new factors that must be folded into the classic approaches to security and forensics.  With ubiquitous virtualization come unprecedented possibilities to capture and analyze machine states in forensically sound ways.  Along with those opportunities, however, come some unique challenges around privacy and operational continuity.

This series of posts will begin with a short overview of cloud computing and the operational environments that build and manage “The Cloud,” as well as typical approaches to security by today’s cloud operators.  We’ll also quickly review some correlations with business and compute model of classic outsourcing and the typical approaches to security by today’s providers of classic outsourcing.

With that foundation, we’ll discuss some of the unique challenges to security and forensics that differentiate cloud computing operations from both in-house and classic outsourcing models.  These challenges include: managing privacy in an environment where data is separated by logical, rather than physical, isolation; managing operational continuity for innocent customers in the face of degraded performance caused by a single party; dealing with legal requests while working with courts and law enforcement that understand neither the impact of their request nor the alternative means to achieve their end goals.

With an understanding of the challenges, we’ll discuss some possible solutions, including the controls, documentation, training and skillsets necessary to keep cloud operations running smoothly in the face of these challenges.  We’ll also discuss tools to deal with some of the more troublesome aspects of sharing physical infrastructure among discrete customers, including fraud detection, resource constraints, and how to give law enforcement the comfort level to explore other options besides confiscating an entire cloud environment to respond to a single subpoena.  Some of these tools take the form of technology, such as monitoring systems, other tools take the form of contract language that allows the operator to remedy situations where a single customer is impacting the overall environment, and some of these tools take the form of processes designed to allow the environments to operate gracefully in a temporarily degraded state – for example, during the service of a subpoena or other forensic capture process.  In all cases, the case is made for instrumentation to track these states and provide enough information to support forensic investigators in drawing confident conclusions about root causes and responsible parties.

We’ll discuss some additional considerations along the way.  Competing cloud providers today implement different operational models based on different business assumptions, including projections about supply and demand, details about resource consumption based on popular use cases, etc.  These assumptions, in turn, drive operational decisions such as whether to invest in fully-vested cloud resources that allow every customer to consume all the resources they’ve contracted for, versus optimizing their investment so that fewer cloud resources go unused and arguably wasted.  All of these operational decisions impact the security posture of the cloud infrastructure. Stay tuned, Part II will be posted one week from today, on February 28.