Cloud computing is the latest trend that has the industry abuzz. Everywhere you go, there are cloud services for every functionality imaginable. Many believe that cloud computing can deliver massive business and operational efficiencies. There is even a movement at the national level: Vivek Kundra, the country’s recently named federal CIO, is being tasked to push the adoption of cloud-based services across the federal IT landscape.
Cloud computing differs from traditional outsourcing because in the latter model, it is still very much standalone computing — either you take your server and put in someone else’s data center, or you have a MSP managing your devices. In many cases, you know exactly where your data/host is and what resources, if any, you share with others. Cloud computing decouples data from infrastructure and obscures low-level operational details, such as where your data is and how it’s replicated. Multitenancy, while it is rarely used in traditional IT outsourcing, is almost a given in cloud computing services. These differences give rise to a unique set of security and privacy issues that not only impact users’ risk management practices, but have also stimulated a fresh evaluation of legal issues in areas such as compliance, auditing, and eDiscovery.
I’ve had many conversations recently with IT security and compliance professionals about cloud security, and the universal concern seems to be that there is a lack of visibility and standards across cloud providers. Users of cloud services are therefore left to fend for themselves, especially in terms of understanding and addressing security risks associated with outsourcing to the cloud.
Virtual infrastructure has become the backbone of cloud computing, particularly in the area of infrastructure-as-a-service. This is why the latest attack on EC2 demonstrated by MIT researchers garnered a fair amount of attention in the press.
This is an attack against virtual computing resources, not necessarily against EC2 per se. In fact, this attack can potentially work against any virtual infrastructure, private cloud included.
Does this mean that there is a security vulnerability within EC2? Yes.
Should you be concerned? Not really.
This is an example of a "side-channel" attack. For this attack to be feasible, certain conditions must be true a priori. These conditions include that the attacker has knowledge of when the victim virtual machines would be launched. Some of these conditions, though not entirely impossible, are on the impractical side. While the author concedes that it is possible that an espionage attack with high-valued stakes may very well undertake such a method, it is hardly a concern for run-of-the-mill computing tasks running in EC2.