Infrastructure as a service (IaaS) is a very appealing concept. Instead of buying, installing, running and maintaining all your own IT equipment, you log into an IaaS service, give them your credit card number, and turn on as much computer power as you need for the job in hand. When the job’s finished, you just close the session and pay for what you’ve used.
But what exactly are you getting when you spin up a few servers in the cloud, and what happens to all that hardware when you’ve finished with it?
These were questions that interested researchers last year at the London-based pentesting company Context Information Security. They wanted to assess the security of servers generated on the fly by cloud service providers (CSPs), and they chose four major providers to test.
Not wanting to do anything underhand, the Context researchers contacted each of the companies and agreed terms for carrying out tests. Now, you would hope the providers would say something like “Do any test you like, because our systems are robust and we trust our own security.” But no, the CSPs placed a number of constraints on the researchers: they were not allowed to conduct any form of DDoS attack or hypervisor breakout attack. And they were also prevented from conducting any kind of test that would disrupt other customers of the service.
Undeterred, the researchers went ahead with all four providers, and even with the tight constraints under which they were working, they made some alarming discoveries. Virtual machines often lacked the latest patches, making them intrinsically insecure, and in some cases, it was possible for virtual machines to address disk space in other neighbouring VMs belonging to other clients of the CSP. Only one of the four provided a virtual firewall to manage traffic in and out of the VM.
None of the providers offered encrypted disk operation by default; none provided anti-virus; and all nodes supplied had default system passwords. Two of the four providers were found to have a fundamental flaw in their implementation of hard disk separation, which allowed the researchers to access other nodes’ data from their own virtual disks.
In one case, a new virtual machine created by one of the services contained information left over from the last customer to occupy that disk space. Michael Jordon, CTO for Context, described the information as “serious and significant unexpected content.” He can’t say more than that at the moment, because of a legal restraining order put on him one of the providers which is clearly worried about the damage it could do to their business.
It’s worth mentioning that the original research was carried out more than a year ago, and the detailed findings were published in a white paper in March 2011 [ http://www.contextis.com/research/white-papers/assessing-cloud-node-security ], but Context did not name the suppliers. Like any responsible security company, it reported the problems back to the providers and gave them six months to fix them. After six months, not much had changed and so Context agreed not to publish the names for yet another six months.
Which brings us up to early March 2012, when Context was planning to speak for the first time about the issues raised, and crucially, to give the names of those involved. At the last minute, one of the CSPs sent their top management and legal teams over from the US to negotiate with Context, and they managed to get a stay of execution on full disclosure till April 24.
The March presentation went ahead as planned, but with a lot of the slides blacked out. It revealed that two of the providers were Amazon and Gigenet, who obviously had no problem about the publicity, but the names of the other two will go public soon, provided no other legal sanctions are applied.
So what are the lessons to be learned from the exercise?
* If the IaaS providers are not 100% sure of their security, then you need to be equally sceptical. Assume that any virtual machine that you spin up will need to be hardened and properly patched before use. Treat it like any other Internet-facing server, and make it secure.
* Think about encrypting all data (at least all sensitive data) that sits on these machines. That way, if the information is not properly deleted and is seen by the next customer to occupy the disk space, it won’t cause a problem. In addition, any neighbouring VM that manages to peer into your system will just see encrypted files.
So does this mean we should avoid IaaS? Of course not. The economic benefits are far too enticing for the solution to be resisted. And for many companies struggling to maintain and back-up their own in-house systems, a hosted service will probably deliver an improvement in overall security.
But customers still need to be very aware of what they are buying. A recent survey by the Computer Trade Industry Association (CompTIA) found that 61% of UK businesses described themselves as moderate to heavy users of cloud services, and yet only 24% said they conducted thorough security reviews of their suppliers, and 24% said they carried out few or no checks at all, and trusted their providers to be secure.
That high level of trust, it seems, could be sadly misplaced.
Posted: March 29th, 2012 under Uncategorized.
No Comments »
No comments yet.