Cloud Attack: Economic Denial of Sustainability (EDoS)
Reuven Cohen
economic viability of cloud computing. Christofer Hoff, a popular
security blogger and Chief Security Architect at Unisys has coined a
new approach to the use of so-called "cloud based denial-of-service
attacks" or what he calls an "Economic Denial of Sustainability"
(EDoS).
The general idea of an EDoS attack is to unitilize cloud resources to
disable the economic drivers of using cloud computing infrastructure
services. In an EDoS attack the goal is to make the cloud cost model
unsustainable and therefore making it no longer viable for a company
to affordability use or pay for their cloud based infrastructure.
In Hoff's post he says "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. "
Adam O'Donnell, the Director of Emerging Technologies at Cloudmark,
points out that "The billing models that underlie cloud services may
not be mature enough to properly account for an EDoS like attack."
What this means is that just using the cloud for the purposes of
easily scaling your environment may soon not be enough. Traditional
scaling and performance planning may quickly be giving way to cost
based scaling methodologies. These new cost centric approaches to
scaling cloud infrastructure will look at more then just monitoring
the superficial aspects of your applications load time but instead
focus on how much it's actually costing you.
The ability to adjust based on realtime economic factors may soon play
an equally critical role in a company's decision to use "the cloud" or
potentially continuing to use the it. This is particularly true of
infrastructure as a service offerings such as Amazon or Gogrid, where
the cost are passed directly onto the users of the service in a pay
per use fashion.
In the platform-as-a-service world, this may not be as big of an issue
because of the economies of scale that companies like Google and
Microsoft bring to bear. But for the smaller guys or DIY clouds, this
could pose a major problem.
The classic example Amazon and others use is that of Animoto, but what
if 50% of Animoto's traffic was purely that of an upset customer
looking to break the bank? Never under estimate the power of a upset
customer or ex-employee's vendetta. Worse yet, what if that irate
customer used the very cloud as the method to create a denial of
sustainability attack? It's become easier then ever to acquire fake
credit card numbers.
For a while it seems the cloud computing was advancing more quickly
then criminals, but this is probably going to be a short lived trend,
a trend which may have already passed. In the very near future the
next generation of cloud based capacity planning and scaling may start
to focus more on building cost based strategies along with the load
and user experience. A strategy capable of being able to determine the
optimal cost while also providing comparisons along with everything
else you need to be competitive.
Original Post >
http://www.elasticvapor.com/2009/01/cloud-attack-economic-denial-of.html
--
--
Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.
blog > www.elasticvapor.com
-
Open Source Cloud Computing > www.enomaly.com
tmor...@gmail.com
time thinking about too.
At the end of the day, this problem really comes down to identity!
You say it yourself, here: "but what if 50% of Animoto's traffic was
purely that of an upset customer".
I don't see this as a cloud problem, at all. It's a very old internet
problem, one powerful enough to make email increasingly less and
less useful. If identity were a larger part of the internet, SPAM
would
not exist, and what you're describing here is, effectively, HTTP
spam, assuming we're talking about HTTP requests.
Internet scale federation and identity are one of the reasons that
based Vertebra on XMPP.
--
-- Tom Mornini
-- CTO and founder
-- Engine Yard, Inc.
Bert Armijo
In the early days of PCs, when business was still done primarily over the phone using toll free 800 numbers, hackers would get even with companies offering bad support by publishing their 800 sales numbers as free sex lines. The phone lines would be choked with traffic, effectively shutting the company off from the world.
Cloud computing will have to develop methods for dealing with this issue just as previous technologies have.
Srinivas Vedula
the internet will have to think about this and deal with it. I don't
think adding the moniker Cloud to it makes it new.
Srinivas
Jonathan Lambert
It definitely represents some risk, and being able to get access to a large pool of resources lets your hide yourself pretty well, but in many ways it's the same problem confronted with botnets and frankenpc attacks - they look highly legitimate and are hard to guard against.
The gov't in the US has identified 'patriotic hacking and hacktivism' as two main sources of attacks on their sites, which include some really similar attack styles to that described here. Not much damage has been done so far, but tiger teams and expensive security appliance won't guard against sophisticated attackers.
However, if cloud infrastructure isn't secure, it does open the possibility of some major man in the middle exploitations. But the core of any public infrastructure is that way.
I think the only argument I can think of that does make sense here is this: the main source of attacks are internal to a company; but cloud (or any other large scale infrastructure) does raise the point that an employee could do damage on a massive scale. The same goes for any company that touches large datasets. These are questions companies need to seriously consider as risk mitigation points before doing any kind of outsourcing.
Jonathan Lambert
Jonathan Lambert
CEO | WorkHabit, Inc.
Office: 866-WORKHABIT (967-5422)
Fax (direct): 253-295-2353
Skype: jonathan-lambert
Email: j...@workhabit.com
Web: http://www.workhabit.com
Reuven Cohen
I suppose the real difference now, is that the tools that enable this sort of network centric attack have become much more easily acquired. Given the current macro-economic environment, a prolonged eDoS could be easily the tipping point which puts a start-up out of business.
Reuven
Subra K
eDoS does raise an interesting angle and running the bill up and putting small startups out of biz ; This is very similar to click fraud that Google/Yahoo Ad engines encounter. However, the key difference is that Yahoo/Google is responsible(liable) for mitigating those attacks and have factored that into the cost of doing business (similar to credit card fraud) ; In the case of EC2, Amazon has not accepted the risk and it is upto customers to protect themselves from this type of attacks.
Also, in click frauds, you only loose the $$ that you have prepaid. In the case of EC2, I am presuming that you cannot set rate limits on bandwidth as well as on the CPU/Storage?
Cheers
--Subra
Bert Armijo
In a recent speech in San Diego Verner indicated that the majority of times aws users launched large numbers of instances it was caused by a software error. So perhaps the real danger isn't DoS, but code that suddenly has access enormous resources. After all, how many developers have ever QA'd for that before.
From:
cloud...@googlegroups.com [mailto:cloud...@googlegroups.com] On Behalf
Of Subra K
Sent: Monday, January 26, 2009 6:26 PM
To: cloud...@googlegroups.com
Subject: Re: Cloud Attack: Economic Denial of Sustainability (EDoS)
DoS could be due to
economical or political or simply nonsensical reasons to make a point.
Subra K
--Subra
Reuven Cohen
reuven
Hoff
I've had lots of interesting conversations with people of the last
couple of weeks
regarding the concept of eDoS. In many cases, rather than focusing on
the potential
attack vector that the cloud -- and cloud utility billing -- provides,
the conversation
trails off on debating the "newness" (or lack therein) of this
particular vector.
It's not particularly new. DDoS and EDoS are certainly related, but
they are also
different. Tilting your head to one side and looking at things from a
slightly different
angle often yields interesting results. Sometimes it doesn't.
I found the angle very interesting. Others' mileage may vary...
The reality is that for me, issues of transactional instrumentation
tied to identity
management and business logic ARE old problems; ones that continue to
dog
us.
Combined with the ubiquity and elasticity of the cloud, they represent
an emerging
threat that I can tell you people who are rushing to the cloud are
ignoring.
The response that "Yahoo and Amazon and eBay" have all had to deal
with this
sort of thing for ages is IRRELEVANT from my perspective because the
majority
of businesses are not Yahoo, Amazon or eBay. They don't have the
resources to
put in place capabilities to detect (let alone prevent) things like
this and simply
expect their "provider" to do it for them.
In environments such as AWS where the abstraction between application
and
infrastructure is clear and the instrumentation and transactional
integrity doesn't
exist (and probably won't -- at least not integrated into AWS'
offerings) instead
of talking about how this vector is not new, I'd like people to tell
me how folks
ARE defending against this beyond the Amazon's, eBay's and Yahoo's...
If I hear another startup or midrange company basically admit they are
abandoning
capacity planning and architecture scalability to the extreme because
they just
expect the cloud to handle it whilst simultaneously ignoring
transactional/identity
integrity from a security/resilience perspective, I'm going to, well,
burp.
At any rate, the point of eDoS wasn't to invent (or claim to) a new
term just to
confuse people, but rather start a conversation. It's done that to a
point. I hope
we have more of them.
Thanks very much for the discussion. I'm not looking to be right
about eDoS --
I don't really care whether anybody ever uses the term or not -- I
just want people
to talk about the issues without simply saying "Oh, that's an OLD
problem. We've
known about it forever..."
Yup. Just like we knew about Kaminsky's DNS flaw, the BGP black-
holing/mirroring, the
MD5 SSL CA cert. spoofing, etc...just because it's not "new" doesn't
mean it's not
worth discussing ;)
/Hoff
On Jan 26, 3:12 am, Jonathan Lambert <j...@workhabit.com> wrote:
> I have to second that opinion. We had a lot of similar discussions (low
> level DDOS attacks to drive up traffic, some of which can get pretty
> sophisticated) around Cloud when it was called Grid four years ago.
>
> It definitely represents some risk, and being able to get access to a large
> pool of resources lets your hide yourself pretty well, but in many ways it's
> the same problem confronted with botnets and frankenpc attacks - they look
> highly legitimate and are hard to guard against.
>
> The gov't in the US has identified 'patriotic hacking and hacktivism' as two
> main sources of attacks on their sites, which include some really similar
> attack styles to that described here. Not much damage has been done so far,
> but tiger teams and expensive security appliance won't guard against
> sophisticated attackers.
>
> However, if cloud infrastructure isn't secure, it does open the possibility
> of some major man in the middle exploitations. But the core of any public
> infrastructure is that way.
>
> I think the only argument I can think of that does make sense here is this:
> the main source of attacks are internal to a company; but cloud (or any
> other large scale infrastructure) does raise the point that an employee
> could do damage on a massive scale. The same goes for any company that
> touches large datasets. These are questions companies need to seriously
> consider as risk mitigation points before doing any kind of outsourcing.
>
> Jonathan Lambert
>
>
>
>
>
>
> > This is what google and yahoo deal with all the time. Any service on
> > the internet will have to think about this and deal with it. I don't
> > think adding the moniker Cloud to it makes it new.
>
> > Srinivas
>
xfer_rdy
How does one discriminate between third party SLA auditing agencies or
customer's SLA auditing applications and DoS attacks. Depending on the
complexity of the SLA audit, it could be substantial traffic, at least
for large service farms.
-gary
>
> read more »