Cloud computing environments are just as suited to illegitimate use as legitimate use. Do providers need a way to separate the chaff from the wheat to reassure enterprise-class customers that they’re doing everything they can to eliminate the hijacking of cloud computing resources for nefarious purposes?

One of the negatives of being the technology darling du jour is that every misstep, problem, and outage is immediately jumped on and reported everywhere. Amazon is particularly susceptible to such coverage, being recognized as one of the leaders in public cloud computing. Last week Amazon suffered yet another outage, true, but more interesting may be the discovery that it had been infected by the Zeus bot, a password-stealing banking Trojan.

On Wednesday, security researchers for CA found that a variant of the infamous password-stealing Zeus banking Trojan had infected client computers after hackers were able to compromise a site on EC2 and use it as their own C&C (command and control) operation.

The Zeus bot has been loose for quite some time and Amazon is certainly not the first – nor likely the last – organization to be infected by this nasty little trojan. In October social  networking giant Facebook was targeted by miscreants attempting to spread some Zeus-bot love around as well. The bot is a Windows-specific trojan that, like so many others, attempts to lure its victims into installing it via phishing and drive-by attacks.

The bot itself is nothing new, nor is the targeting of Windows-specific machines, or the use of phishing. Neither is the attempt to leverage the large scale nature of specific services on the Internet as a means to spreading a virus around. And as Carl Brooks pointed out via Twitter, the use of cloud computing as on-demand bot-net farms is no surprise to the security community at large. But what isn’t being discussed – and probably needs to be – is what can be done about the situation? Is there a solution at all or will we just have to live with it?

It may be that the only remediation available is the establishment of enterprise-class clouds.

With Amazon FPS, you can build innovative payment applications with a new level of flexibility in how you execute payments. Amazon FPS supports the processing of payments using credit cards, bank accounts and Amazon Payments account balances to send or receive money.

According to an article in the Register, “"We believe this was a legitimate service that was purchased and compromised via a vulnerability" such as a weak password, Don DeBolt, CA's director of threat research, told The Reg. "It could have been any vulnerable system on the internet."

It could have been any vulnerable system on the Internet. True, very true. What makes this incident particularly troubling is that the compromise of a single machine inside a public cloud computing environment necessarily raises questions about the fact that the vulnerability was likely shared either across all similar virtual images or the management system itself. That doesn’t mean all like systems were infected, but it does mean that if they shared the vulnerability they could have been infected. The compromise of even a single machine inside the environment necessarily leads to the possibility that every other machine like it inside the environment could be compromised – and possibly by the original infection.

Public cloud computing environments are like the human body; if a virus gets inside it can easily and rapidly multiply, infecting other like machines (cells) with relative ease. The efficiency for the provider comes in part from offering base “images”; these images are the same across all customers, which includes any possible vulnerabilities in the operating system and software deployed via the image. And like the body, it’s often not noticeable until the patient has a fever. It doesn’t really matter whether this infection was, in fact, introduced via the purchase of a legitimate service. What the possibility that it was has done – or should do – is raise the question whether “open” public cloud computing is too open, at least for enterprise-class use.

Providers are likely to respond in a manner similar to Amazon’s response to this event, which is to say “we take these things seriously, as soon as we know we do something about it, yada, yada, yada.” The problem is that these responses are just that – reactive responses to something that’s already occurred. What the enterprise needs – and deserves – is some proactive measures to guard against the legitimate use of cloud computing resources for illegitimate purposes. The negative to employing stricter control on utilization is, of course, that it removes the ability to “immediately begin using” a cloud computing instance. Without the ability to simply “swipe your card here” providers may be concerned that fewer people and organizations will take advantage of its offerings. But in many cases the additional layer of security added by authenticating legitimate use in some way – as far as that can be authenticated – may reassure organizations that the cloud computing environment in question is safer than perhaps one that continues to require no more authentication than your local gas station.

Vulnerable systems would remain vulnerable, yes, but removing the ease with which a miscreant can drive in, deposit a virus, and leave would certainly not hurt the overall security posture of the environment. If “open” public clouds cannot or will not address the issue, it is likely that someone will see the need and fill it with more “enterprise-class” cloud computing offerings that do.

Related blogs & articles:

• Cloud Computing Public Service Announcement – Please Read
• Scaling Security in the Cloud: Just Hit the Reset Button
• Putting a Price on Uptime
• Cloud Computing versus Cloud Data Centers
• Securing the Other Side of the Cloud
• WILS: Cloud Changes How But Not What
• The Virtual Public-Private Cloud Connection
• Cloud Changes Cost of Attacks