An e-mail exchange with Kay Kinton, a spokesperson for Amazon, on the subject of Amazon and its recent run-in with the Zeus botnet controller, raised two very interesting and valid points. First, there is a fine balance that must be maintained by providers – cloud or traditional hosting – regarding the privacy of applications and data deployed by customers and monitoring/security. Second, Kay points out that it’s easier in the EC2 environment, at least, to disable botnets once they are discovered.

The second point is one that appears on the surface to be true but I’m not entirely convinced. A cloud provider has complete control over its environment (even if you don’t, making this somewhat of a double-edged sword) and thus they can act immediately to terminate the offending application. True. But in any environment in which you have physical or management network access to an offending application/system it should be easy to terminate an offending application. Perhaps more important about this point is that a cloud computing provider can prevent the launch of another offending application, but again – I’m not sure it’s any easier or more difficult in a cloud computing environment than it would be in a traditional hosting or data center environment.

Now the first point is a bit more subtle and definitely deserves some attention as it potentially pits one customer’s privacy against one (or more) other customers’ security and raises some interesting questions regarding how deeply in the sand such a line should be drawn in a cloud computing environment.

Here is Kay’s complete response clarifying several points regarding the recent incident and subsequent coverage:

There have been numerous reports of this finding as well as speculation as to what this means to EC2 security so we appreciate the opportunity to clarify for your readers. Reports have stated that this software was run after a website in EC2 was compromised. While isolating the abusive instance, we found no evidence of a compromised website.

We were able to locate a Zeus botnet controller and promptly shut it down. We take all claims of misuse of our services very seriously and investigate each one. When we find misuse, we take action quickly and shut it down. Our terms of usage are clear and we continually monitor and work to make sure the services aren’t used for illegal activity. It’s important to note that we take the privacy of our customers very seriously, and don’t inspect the contents of instances. This is part of the reason that legitimate customers of all types are comfortable running production applications on Amazon EC2. However, when abuse is detected, we are able to act swiftly to isolate the abusive behavior.

In general, users of Amazon EC2 use the same precautions to secure and protect their websites as they do with traditional hosting solutions. It is no easier for would-be abusers to compromise EC2 based websites than other publicly available websites.

Finally, many articles have asserted that services like Amazon EC2 will be useful tools for would-be abusers. Abusers who choose to run their software in an environment like Amazon EC2, make it easier for us to access and disable their software. This is a significant improvement over the Internet as a whole where abusive hosts can be inaccessible and run unabated for long periods of time. We will continue to improve our abuse detection and response. We also encourage our community to report suspected misuse of Amazon EC2 to ec2-abuse@amazon.com.

The question this raised for me was: at what point does – or should – a provider cross the privacy line in the interests of security? In a shared resource environment, where a botnet / controller / malicious software may be impacting the availability and security of other applications, which is more important to the customers: privacy or security?

The answer may be different depending on your location and by what laws you are ultimately governed, and one could argue that privacy is a subset of security (and some would argue just the opposite) but I can’t imagine anyone would argue that a customer’s privacy should be violated on the premise that the provider is simply “looking for” a violation of its terms of service. As Amazon notes, once a violation – such as using “the cloud” as a means to launch an attack or control an attack on an application – has been discovered, i.e. it is known to be running, it is completely within their rights – and ability – to terminate the offending application. But until it is detected, when the provider is simply monitoring for the existence of such a violation, the “rights” of the provider to secure the environment may clash with the “rights” of the customer to privacy. But that may clash with the rights of other customers who may be sharing the same network and thus could see their application adversely affected by the existence of malware that hasn’t yet been detected.

Because providers must balance privacy against the security of its customers (and its own, as well) applications and networks, its only real option is to monitor the environment for tell-tale signs of an infected and/or malicious instance. That means primarily watching for specific patterns of traffic on the network and identifying those that appear to be indicators of viruses, worms, and botnets. In some cases that means sudden spikes in traffic, for others it means slow, gradual increases over time. For some it means specific types of traffic – UDP, TCP – and for others it means attempts to connect to sites known to host malware or parts of existing botnets. In some cases, specifically when the malware is new and unknown, the only way the provider will know for sure what’s going on is for it to be reported to them. They may see suspicious patterns in traffic and types of traffic that lead them to make an inquiry, but based on Kay’s note regarding privacy and customer data/applications, it won’t dig too deeply in order to preserve the privacy its customers value unless it’s pretty sure it knows what’s going on. Given the length of time that some instances of malware have rattled around in popular social networking sites, the speed with which Amazon was able to isolate and remediate the situation involving the Zeus botnet controller is an indicator that Amazon’s assertion that they are “able to act swiftly to isolate the abusive behavior” certainly rings true.

Amazon’s response is fairly clear and it appears that in many cases it – and other cloud providers as well – are caught between a rock and a hard place. There still seems to be room for “enterprise-class” clouds as a means to try to avoid the possibility of an infected/malicious application so casually deployed via credit-cards wreaking havoc in the first place, though at a minimum this response provides insight into the reasons why reality is the way it is for public cloud computing environments. As always, the risk of such an occurrence needs to be weighed against the benefits, and it’s surely the case that many organizations will find the scales tipped heavily on the side of the benefits.

Related blogs & articles:

• Botnets, Worms, and “Open” Clouds: Can Enterprise-Class Clouds Be Far Behind?
• Putting a Price on Uptime
• Amazon Elastic Load Balancing Only Simple On the Outside
• Virtual Private Cloud (VPC) Makes Internal Cloud bursting Reality
• The Virtual Public-Private Cloud Connection
• Amazon Compliance Confession About Customers, Not Itself
• Securing the Other Side of the Cloud
• Control, choice, and cost: The Conflict in the Cloud