A few months ago, we tested Amazon’s IaaS offer, concluding that machines deployed closely in time were closely located. We were also able of pinging machines in the same subnetwork which did not belong to us.

A recent article by UCSD and MIT researchers has much further expanded our initial observations on Cloud’s security implications.

The authors use several “probing” techniques such as enumerating public EC2-based web servers using hping2, nmap, or wget, translating responsive public IPs to internal Amazon’s IPs (via DNS queries within Amazon), and launching several EC2 instances of varying types, analyzing the resulting IP address assignment.

Having these  tools handy, the authors are capable of extracting the following heuristics:

• All IPs from a /16 are from the same EC2 availability zone (e.g. US).
• A /24 inherits any included sampled instance type (e.g. small, large, x-large etc).
• A /24 containing a Dom0 IP address only contains Dom0 IP addresses. We associate to this /24 the type of the Dom0’s associated instance (recall that Dom0 is the first domain started by the hypervisor after booting)
• All /24 between two consecutive Dom0 /24’s inherit the former’s associated type.

This topic is often overlooked by Cloud networking providers. “Simple” means can be set up, like, for instance, making local IP assignment random across instance types and availability zones and/or restricting the customers view of this process.

The paper deals with an important issue, preventing the determination of whether or not a VM is located on the same physical machine that other VMs (”colocation”). Three checkpoints are proposed: 1) matching Dom0 IP address; 2) small packet RTT; 3) numerically close internal IP addresses.  The authors conclude that “even a very naive attack strategy can successfully achieve co-residence against a not-so-small fraction of targets” and “instance flooding” (spinning up numerous VMs) immediately after the target has booted to “take advantage of the parallel placement locality exhibited by the EC2 placement algorithms”.

Having colocated VMs implies the possibility of preforming side attack channels. Several of these are discussed: Denial of Service (shared physical resources imply covert channels that can be employed for implementing cross VM attacks), measuring cache usage (creating covert channels between cooperating processes belonging to different VMs), detection of  co-residence without relying on sending any network probes (injecting load on an alien VM and monitor our own in order to correlate load increases in the other VM with performance decreases in our), or estimating traffic rates to deduce targets’ activity patterns in order to determine the most painful moment for an attack to be done.

The paper is a MUST read for both, IaaS Cloud providers and those aiming at moving some services to the Cloud .

vCloud is an initiative led by VMware and counts with the collaboration of more than 100 partner including  BT, Rackspace, SAVVIS, Sungard, T-Systems and Verizon Business. The main aim of vCloud is to provide a complete solution to deliver enterprise cloud services based on VMware technologies. The vCloud API will allow application providers to deploy their application among a cloud service provided by one of the vCloud partners.

The vCloud API is based on the principles of Representational State Transfer (REST).

The vCloud resource model includes next entities: the Organization that owns the applications, the Virtual Data Centre where different Resource Entities (Virtual Applications Templates, Media devices, and the Virtual Application) and Networks are instantiated. A Virtual Application is an aggregation of one or more Virtual Machines.

There are number of operations to query existing resources or summary of the Organiztation’s resources (GET <entity-uri>) and to delete an specific resource from a Virtual Application (DELETE <vapp-entity-uri>).

There is a Catalog  where users can register, get a summary, down/upload or delete a catalog item (vApp templates, media files such as ISO images, etc.).

vCloud application lifecycle model defines a number of steps where a number of operations can be performed:

• Provisioning: creation of clonning of VApps, instantiation of the vApp templates, upload or facilitate the location of vApp parts and instantiation of VApps defined in an OVF package.
• Configuration:  a client can reconfigure vApps by adding, removing or modifying OVF sections.
• Deployment: Reservation of all the resources requested by the vApp (POST <vapp-uri>/action/deploy)
• State Operations: once the resources are reserved the vApp have to be started by powering on all the resources (POST <vapp-uri>/power/action/powerOn), and later on it can be powered off, reset, suspended, shutdown, rebooted, etc.

As some of the previous operations can take time,pending task can be retireved (GET <task-list-uri>/<task-uri>) and cancelled (POST <task-uri>/action/cancel).

There are some other administrative operations to manage Organizations, Virtual Data Centres,  users, etc.

As conclusion, we see that the basic service lifecycle management is very well covered, but advanced features (dynamic scalability, SLA management, monitoring or usage accounting) that has been researched in projects as RESERVOIR are not included but it would not be difficult to extend this API to support them: the RESERVOIR’s OVF extensions could be adopted and some other operations or reporting data should be extended.

We are witnessing a new technology race about the definition  APIs to access to IaaS Cloud services. With this post series, we would like to start a review series of the most relevant specifications trying to to analyse their status outstanding aspects  of them.

We are starting this analysis with two initiatives that follows different specification models: VMware’s vCloud in a vendor-driven model (aiming to be the “de facto” standard), and OGF’s OCCI in a open standardization body-driven model.

vCloud is an initiative led by VMware and counts with the collaboration of more than 100 partner including  BT, Rackspace, SAVVIS, Sungard, T-Systems and Verizon Business. The main aim of vCloud is to provide a complete solution to deliver enterprise cloud services based on VMware technologies. The vCloud API will allow application providers to deploy their application among a cloud service provided by one of the vCloud partners.

The OGF’s OCCI (Open Cloud Computing Initiative) Working Group is aiming to deliver an API specification for remote management of cloud computing IaaS.  The proliferation of IaaS providers with their own APIs (Amazon AWS, GoGrid, Flexiscale, …) requires an standardization effort on defining an common API to avoid vendor-locking and to guarantee interoperability.

As an outcome of our previous post on Cloud security, we received some very interesting critique providing further insight on Cloud security. The received comments harshly dub our assertions as naive and untrue. We love to receive any kind of respectful and polite critique, even when it may contain opinions opposed to ours. This blog was created for that purpose: discussing and sharing views and ideas.

Since this blog is public, we would have appreciated having these comments as a blog comment, and not as an internal cross-post in a private corporate blog.  Anyway, let us sum up the key points of the received critique, for the sake of open discussion:

• Data security.
• Malware infestation and distribution to third parties using cloud virtual premises.
• Local malware infestation (on the application provider premises)
• Vulnerability exploitation on the app-provider’s Cloud virtual computers.
• Can we implement multilevel security on virtual premises? What would be the equivalent of keeping our most precious data on a separate network that doesn’t have external access on a system where, by definition, everything must be accessible over the network?

This critique effectively pinpoints the problem of hosting an application in a public Cloud, when we would never host it in a traditional hosting environment of let open Internet access to it.We believe, however, that the authors of this critique did not finished reading the whole sentence or misunderstood our words, so let us reemphasize some sentences from the previous post:

•  ”these concerns are not inherent to the Cloud underlying technologies themselves“
• “(some security concerns) do not add any security breach to Internet-hosted applications”
  

Thus, what we mean to say is not that the Cloud does not have any security issue, but rather, it is not much different from any outsourcing solution you may already have. In other words, if your application is not ready to go to an external hosting environment (for security reasons), then you should give up going to the “advanced hosting” a public IaaS-Cloud offers. Thus, our statement that the Cloud does not add anything new to already Internet-hosted applications holds 100% true.

These security concerns about the Cloud are not different to those you may have in any hosting environment. Moreover, Clouds are wrongly assumed to be necessarily public and third-party provided. On the contrary, we can already count on some Open source implementations to build our own private Cloud (in our own premises!! and controlling the underlying network!!), such as Eucalyptus and OpenNebula (Spanish technology).

We hope this post helps understand, as we have been saying since the blog was created, that not all the applications are well suited for a public Cloud, security reasons are a factor, but there are way too many to be thoughtfully considered (such as economical factors, forensics, etc ).

Current commercial IaaS (Infrastructure as a Service), like Amazon EC2, Felxiscale, GoGrid, etc., provide hosting clouds solutions based on computing, storage and networking virtualization. Through proprietary APIs and management tools, normally offered on Internet, customers can manage virtual machines images with an specific OS installed, and ask for their deployment in the Cloud. These cloud providers bill for the usage of infrastructure in a pay-per-use way.

But, are current Hosting Clouds enough for deploying Enterprise Services?

Read the rest of this entry »