Everyone in the DC area is going Cloud crazy. The government and industry believes they can throw whatever problem they have into the cloud and everything will be better. Fortunately, the security folks mentioned that throwing all your data and code into an unknown whole and hoping for the best might not be the best idea. So of course, the next wave of security guys came in and are “securing the cloud”.
You can’t secure the cloud.
Why not? Because the reason everyone loves “cloud computing” is that it’s a nebulous concept that claims it will solve all problems. Therefore, it has undefined functional requirements and use cases. You can’t build real security into something that doesn’t have a definite form. As it is, every party involved in building cloud systems blames the other guy.
The security engineers yell at the developers saying “of course you can’t secure a system if you don’t write secure code”.
The developers respond “why would I secure user interfaces to my application when I accept and trust the user”. This sounds a little crazy but realistically if you’re running Word you don’t sandbox it from Powerpoint. Having written high throughput code I’ve seen a single if statement have large performance impacts. So writing your code to trust nothing will severely diminish performance and increase development time.
To emphasize the security risks, Immunity (in a very private release and very public video demo) released their Cloudburst exploit to pop out from a guest to the host. This exploits represents huge risks to many organizations that use VMware extensively. In many cases VMware is the host, guest, network, firewall, switch, and change management system all in one so an exploit that traverses from an untrusted guest to management networks and/or restricted assets is huge.
I like scientific computing, parallel processing, and virtualization. So the components that make up cloud computing are great. But realistic solutions aren’t ubiquitous. If organizations want to secure cloud systems, they need to restrict cloud environments to security groups and functional requiments. Trusted scientific processes aren’t meant to run next to malware. Likewise, disk bound processes aren’t generally well suited to the same environments as cpu bound processes. As with everything else in the world, cloud computing needs a realistic engineering solution.
As an analogy, the military doesn’t secure a mountain pass from artilary the same way it secures a city block from insurgents. Similarly, a Hadoop cloud for internal use by a search engine has entirely different security objectives of a public cloud meant to run web services. The hadoop cluster requires mainly perimeter security, code review, and sanity checks, the latter requires a complicated infrastructure to ensure your clients aren’t stealing data, running a bot, or performing other nefarious actions.
Wrapping this up, you can’t secure the generic cloud. You can of course secure particular cloud implementations given that functional requirements and use cases are enumerated and feasible. The root problem may be that the technologies have yet to adequately mature. Therefore the term cloud has different meanings to different individuals. What is likely and necessary to occur is that the cloud computing industry will increase specialization so that one can build security recommendations for classes of cloud systems. Specialization will likely cut into projected profit margins in the short term. But as industries turn to cloud implementations they’re going to require better security around their data — which represents real dollars to most organizations, and will require real security.