Cloud Computing Security: From DDoS (Distributed Denial Of Service) to EDoS (Economic Denial of Sustainability)
It's Thanksgiving here in the U.S., so in between baking, roasting and watching Risk Astley rickroll millions in the Macy's Thanksgiving Day Parade, I had a thought about how the utility and agility of the cloud computing models such as Amazon AWS (EC2/S3) and the pricing models that go along with them can actually pose a very nasty risk to those who use the cloud to provide service.
That thought — in between vigorous whisking during cranberry sauce construction — got me noodling about how the pay-as-you-go model could be used for nefarious means.
Specifically, this usage-based model potentially enables $evil_person who knows that a service is cloud-based to manipulate service usage billing in orders of magnitude that could be disguised easily as legitimate use of the service but drive costs to unmanageable levels.
If you take Amazon's AWS usage-based pricing model (check out the cost calculator here,) one might envision that instead of worrying about a lack of resources, the elasticity of the cloud could actually provide a surplus of compute, network and storage utility that could be just as bad as a deficit.
Instead of worrying about Distributed Denial of Service (DDos) attacks from botnets and the like, imagine having to worry about delicately balancing forecasted need with capabilities like Cloudbursting to deal with a botnet designed to make seemingly legitimate requests for service to generate an economic denial of sustainability (EDoS) — where the dyamicism of the infrastructure allows scaling of service beyond the economic means of the vendor to pay their cloud-based service bills.
Imagine the shock of realizing that the outsourcing to the cloud to reduce CapEx and move to an OpEx model just meant that while availability, confidentiality and integrity of your service and assets are solid, your sustainability and survivability are threatened.
I know there exists the ability to control instance sprawl and constrain costs, but imagine if this is managed improperly or inexactly because we can't distinguish between legitimate and targeted resource consumption from an "attack."
If you're in the business of ensuring availability of service for large events on the web for a timed event, are you really going to limit service when you think it might drive revenues?
I think this is where service governors will have to get much more
intelligent regarding how services are being consumed and how that
affects the transaction supply chain and embed logic that takes into
account financial risk when scaling to ensure EDoS doesn't kill you.
I can't say that I haven't had similar concerns when dealing with scalability and capacity planning in hosted or dedicated co-location environments, but generally storage and compute were not billable service options I had to worry about, only network bandwidth.
Back to the mashed potatoes.
/Hoff
I've thought about this with web hosting before. Some web hosts will kindly bump your usage budget up a level for free for a few days if your bandwidth etc goes over a limit – and send you an email letting you know what's happening – before they start billing you excess charges. I guess if $Evil_person manipulates usage gradually, it could be tricky to detect though.
This is an example of how a DDoS attack is no different in its effect than a flash crowd. Current DDoS defence products have no way of handling this, so a new method of traffic management is needed such as the one by IntelliGuard
We've already seen this model with click-fraud, FYI – click-fraud to artifically drive up one's impressions, and thus revenues, and click-fraud to drive up the impressions for which another party must pay, thereby eating up his advertising budget.
Also, note that enterprises and SPs who buy transit generally have to pay for DDoS traffic (inbound or outbound), unless they detect and stop it themselves, or pay someone to do so; peering ratios are also affected by DDoS, and enough DDoS traffic can end up skewing one's peering ratio, costing one money and perhaps even leading other networks to de-peer from one's own network, as a result.
VoIP theft-of-service incidents have resulted in the same kinds of issues.
And of course the OPEX of dealing with even relatively dumb packet-flooding DDoS attacks can be quite large.
This is where layer-7 baselining and anomaly-detection technology can come in handy.
Ken Baker – note that products/services capable of handling flash-crowd-type DDoS (deliberate or incidental) have been on the market for the last five years or so, FYI.
Roland makes some informative comments. But for flash crowds I've looked everywhere and I can't find any products or services that handle flash crowds, nor anything that can definitely tell the difference between a flash crowd and a DDoS attack – particularly if the DDoS attack does not contain signatures or so-called fingerprints or anomalies (i.e. all the traffic looks like legitimate traffic but maybe is not). Could you please tell us which products and services you are referring to.
None cloud based methods such as Webscreen have been around for 5 years plus….
It's a third of the price of a typical cloud based solution and works forever once it's turned on…perfick!!!
Have a look at IntelliGuard
Jack – I suggest you have a look at IntelliGuard if you want to see a DDoS defence that does manage flash crowds and DDoS attacks, and does it at line speed handling the smallest packets.
Ken Baker – take a look at the Cisco Anomaly Guard Module (full disclosure – I work for Cisco), and the Arbor TMS. Many SP offer 'Clean Pipes' DDoS mitigation services based on this type of technology.
Hello Roland. I'm familiar with Cisco Guard and Arbor and why they aren't able to defend many DDoS attacks. If you have a good look at IntelliGuard Web site you will readily see why they don't and why IntelliGuard does.
*** Dear Mr. Baker: I've unpublished 3 of your advertisements already. Do me a favor and add something of value versus blantant advertising to drive eyeballs to your website or I'll just keep deleting them. Thanks. /Hoff ***
OK Hoff I'm new to this and apologise for what you say is advertising. I guess the suggestion to look at Cisco and Abor is not blatant advertising because of the full disclosure from Roland that he works for Cisco. I assume it's OK with you if I say the same thing with full disclosure that I work for IntelliGuard. I thought the forum participants might like to look at both and compare them.
Actually I have submitted a journal paper on Anti-virus in-the-cloud the other day, and cited Christofer's blog article. I discussed one problem called “weak-entrance-node”, which can be used to launch so called EDoS attacks.
If anyone is interested, please email to me, and I will send you the draft.
section C: DDoS and EDOS
…
For AV In-the-Cloud, DDoS can also negatively affect QoA by significantly delaying virus-scan-request packets in traversing the anonymous communication network. To protect cloud server clusters from DDoS, efficient DDoS detection and mitigation solutions have been offered by ISPs or security vendors. On the other hand, currently cloud data centers are built on virtualization technologies across the world. Scalable virtual imaging technologies are low cost by mounting new server virtual images to replace old ones corrupted by attacks.
Instead of launching large-scale DDoS attacks, a recent new counterpart, called Economic Denial of Sustainability (EDoS)[8], has emerged. Nowadays, some vendors pay ISPs by traffic volumes or bandwidths. By controlling some desktop machines or using botnets, attackers can deteriorate QoS of the cloud network by generating probing traffic disguised as legitimate requests, and selectively affecting the reliability of a few anonymous nodes. Owing to the “weak-entrance-node” problem, such attacks can be easily staged. Instead of driving users away from the AV cloud systems, EDoS make these systems less reliable, though still functional. As a result, some
customers may naturally attempt the communication again after the timeouts, resulting in more traffic congestions. By initiating stealthy attacks, attackers can subtly increase the traffic loads without triggering DDoS protection thresholds [9],[10]. As a result, the whole cloud networking is still seemingly fine. However, EDoS attacks are eroding the profits because the security software companies, not the customers, pay for the bandwidth for both legitimate and disguised traffics.
…
D. Countermeasures and discussion
…
Security standardization has not addressed the cloud yet; standards need to be made. For examples, currently there exist two kinds of anonymity networks: volunteer-based and commercial networks. The whole infrastructure is maintained
by volunteers all over the world. Commercial companies can either build their anonymous systems by themselves or pay ISPs to maintain the systems. If something goes wrong with the location-hidden service, who will take the responsibility, ISPs or the cloud computing service providers?
To overcome the “weak-entrance-node” vulnerability, agreements regarding QoS, QoA, and SLAs (Service Level Agreements) should be reached between the customers and vendors. Based on the operational models of the customers, in most cases, what kind of specific service level should cloud service providers guarantee? On the customer side, the local network configurations must pass the penetration testing requirements
before connecting to the cloud. A secure and robust desktop environment with low possibility of being compromised will reduce the abusive traffic and actualize economical saving for the providers.
…
[8] C. Hoff, “Cloud computing security: from DDoS (Distributed Denial of Service) to EDoS (Economic Denial of Sustainability),”
http://rationalsecurity.typepad.com/blog/2008/11/… from-ddos-distributed-denial-of-service-to-edos-economicdenial-of-sustaina.html.
I typically don't reference my own work as comments to others, because it drives me nuts when others do it, but in this particular case, I will make an exception. My article A Better Metric for Analyzing the Value of the Cloud (http://www.cioupdate.com/reports/article.php/3849036/A-Better-Metric-for-Analyzing-the-Value-of-the-Cloud.htm) discusses risk as part of the total cost of service metric correlates well with Chris' points made here:
"Imagine the shock of realizing that the outsourcing to the cloud to reduce CapEx and move to an OpEx model just meant that while availability, confidentiality and integrity of your service and assets are solid, your sustainability and survivability are threatened."
I believe my article extends the concept of survivability and sustainability to also include core knowledge for building, maintaining and running the service.