A recent article in ACM Queue highlights the importance of scalability to help distinguish what a Cloud really is against hype and all the confusion that has been around for some time.From this blog, we feel we have contributed to reducing the hype around the Cloud definition with or ACM CCR article back in 2009. Also, a series of books devoted to the topic. This paperwork has recently been crowned with the release of an actual open source implementation for automatically scaling services on the Cloud, Claudia.Also from this humble corner, we have been trying to build awareness on the importance on Cloud Security to help delivering the vision of the Cloud.The article by Dustin Owens (from BT Americas) combines our two most significant research and development lines into a single one, emphasizing the relevance of security for elasticity and, thus, for the Cloud itself.In order to maintain our well-gained reputation as writing-hype curmudgeons, we would like to criticize the link established in the article between virtualization as a key enabler for elasticity. Even when it is true that virtualization and the subsequent multitenancy helps to reduce TCOs, scalable systems have been there for a while, even before virtualization reached the mainstream. In addition, scaling VMs is still very cumbersome for service providers, a higher degree of automation and abstraction is still required (see Rodero-Merino et al. for further details).
In a very recent post, Craig Balding, founder of cloudsecurity.org, highlights the fact that we are all concern about the security implications derived from the bunch of new and old technologies labelled as Clouds.“The problem is that there are many donkeys, and even more tails. Worse, we’re all trying to stick different tails on the same donkeys”, he claims.Indeed, he proposes security experts to join the A6 group in order to start building a common interface that allows providers to automate the Audit, Assertion, Assessment, and Assurance of their environments and allow authorized consumers of their services to do likewise via an open, extensible and secure API across SaaS, PaaS, and IaaS offerings.We believe this kind of efforts are very valuable and need strong industrial and academic support in order to become something close to a success. Success here does not come in the form of a widely used standard, but in the sense that the Cloud does not really include any disruptive technology to be afraid of with regards to its security. It is the usage we make of the combination of already existent technologies that makes the difference.From this website we will be following the progresses and contributing our two cents for such a needed API to become a reality.
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 .
Cloud Security Alliance has recently released their second edition of the Cloud Security Guide, defining security recommendations for Cloud security at different architectural levels.
We’d like to highlight one important issue raised by the authors: the abstraction level provided by the CLoud, which hides the underlying heterogeneity of resources, makes it specially hard to integrate classical security controls, such as for instance those dealing with network security.
We agree that having these recommendations handy would result in a secure Cloud environment. However, as we highlighted in a previous post, we still miss a detailed architectural state of the art for tools helping to enforce the proposed recommendations.
As stated in a well-known Cloud security blog, it is the time for Cloud security resolutions, not just recommendations or predictions.
A few weeks ago, the European Network and Information Security Agency (ENISA) released a document highlighting relevant topics for Cloud security.
In their “Cloud Computing: Benefits, risks and recommendations for information security” report, European experts analyze the main threats for Cloud security adoption.
Stating that the “major conclusion of the report is that cloud’s economies of scale and flexibility are both a friend and a foe from a security point of view. The massive concentrations of resources and data present a more attractive target to attackers, but cloud-based defences can be more robust, scalable and cost-effective” is, at best, a short outcome for 123 pages.
The report lacks a detailed state of the art, its results being partially based on the perception as obtained in a survey to SMEs whose sample space is very very limited and can hardly reflect the diversity of SMEs in the EU. Lacking appropriate state of the art resulted in very general research recommendations for investigators and somewhat vague indications for Cloud users. We missed more concrete mechanisms and a specific section for Cloud providers to increase their provided security levels, which cold certainly help European companies to engage more clients to their CLoud businesses.