A worm in the cloud ...

[Stefan]

Having been battling all sorts of malware, lately, with - many times -
very creative scripts to identify infected systems as they communicate
at different network layers (e.g. DNS payload identification in
tcpdump/tshark, snort rules with all sorts of byte offsets, TCP and
UDP ports, application monitoring, etc), I couldn't not think for a
minute about what the implications of a "worm in the cloud" would be,
vs. one in a network I (more or less) fully control ... or who would
need to have visibility in "the cloud" (and how far/deep) to debug
such: *overall* cloud owner(s), clients, infrastructure/network vs.
application vs. OS (if any such concept) experts ...

Stefan

[Paulo Calcada]

Helo,

Stefan, I think that worms in the cloud are already a reality.


As an example  take a look in this new phishing attack. Regard how it's sophisticated and how it uses the Internet (or cloud services) to achieve its goals.

http://news.netcraft.com/archives/2009/02/17/new_phishing_attacks_combine_wildcard_dns_and_xss.html

2009/2/18 Stefan <netfo...@gmail.com>

[C Wegrzyn]

I've wondered the same thing, almost. Not so much about "worms" but how
I am going to stress test out my cloud application (since it is expected
to run on thousands of machines) and how I am going to debug the problem
that appears unexpectedly! There don't seem to be any useful tools
except to add in logging, routing it to a syslogd and pray I can see
what is happening. Has anyone else thought about how to debug some of
these massive applications?

Peace,
Chuck Wegrzyn

[Lori Mac Vittie]

Isn't the point of stress testing (largely) to find the upper bounds of
capacity/performance? Isn't part of the promise of the cloud that we don't
have to worry about that?

This doesn't really address the troubleshooting problem - I think that's a
separate issue and don't have a good answer for that at the moment - but the
need for "massive stress testing" seems a moot point for cloud...

Lori

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Cloud Computing Interoperability Forum (CCIF)" group.
> To post to this group, send email to cloud...@googlegroups.com
> To unsubscribe from this group, send email to
> cloudforum+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/cloudforum?hl=en
>
> -----
> Join our Twitter Group at www.twitter.com/cloudforum
> Or Our Linkedin Group at http://www.linkedin.com/e/gis/927567
> -~----------~----~----~----~------~----~------~--~---

[Reuven Cohen]

A worm in the cloud is called a botnet. By far some of the most cutting edge cloud "command and control" work is coming out of the eastern European criminal technology syndicates. The technology behind some of the latest fastflux C&C approaches are amazing to say the least.  What worries me most is a "blue pill" sitting along side my hypervisor utilizing chip level VT features.

r/c

[Hoff]

My upcoming security presentation talks about this very thing with
lots of interesting spins -- mostly new perspectives on old problems
--
but it really just highlights the need for a much more synergistic
exchange
of telemetry and correlation capability across all nodes...

Ultimately, we already have worms 'in the Cloud' that is if you define
the "Cloud"
interchangeably with "the Internet," and we have the same sorts of
issues with
detection and prevention; we haven't solved them yet, either.

We have lots of interesting tools to help us do that,
but since we don't share intelligence uniformly, it's very difficult
to head these things off
at the early stage.

It's a little unnerving that people are interchanging an Internet
based service
with "THE Cloud," rather freely but we've got other venues to debate
that issue...

I wrote a piece about this sort of thing last year that may be
interesting to you:

http://rationalsecurity.typepad.com/blog/2007/12/thinning-the-he.html

"Cloud" providers will selfishly protect their own infrastructure, but
the Spockism
of "the needs of the many outweigh the needs of the one" doesn't
really apply, sadly.

/Hoff

[C Wegrzyn]

Lori,

I don't know if I believe the capacity/performance issue just goes
away. I've been working on a "cloud storage" application for a number
of years now. While I've been working on the assumption that new nodes
can be easily added/removed/replaced, the problem still exists that
there is a physical limit. You can't easily add more nodes if you run
out of space, money or equipment - those things all take time.

But even that as an aside, you still need to stress test your cloud
applications. When I built my first 16 node system I announced it
worked! Of course I still had that little nagging doubt in my gut that I
didn't believe it. Having designed and built two other "cluster" systems
(one being the Vonage voice mail system that had 11 processors and the
first data storage system which had 32), I knew that at the worst
possible time my stuff would stop working (Murphy's law). It was when
there were peaks of demands that things stopped. So back to my 16 node
system: I ran some tests, beat the heck out of it and it stopped! It
took me two days to figure out what was going on. To test it I needed to
feed it over 50,000 messages/minute (SOAP messages), for hours and
hours, to find what I didn't get right the first time.

So, while stress testing might seem useless in the "cloud" it isn't.

Chuck Wegrzyn

[Lori Mac Vittie]

Chuck,

Good point. I keep forgetting that there's a cost associated with the cloud
and there are other limits.

Lori

[Stefan]

This to me sounds like "pentesting" of a (D)DoS nature.

In any case, after having sent the previous message I realized that I
may have had some sort of an answer in my earlier years of "toying"
with security: tarpits and honeypots (or combination of both) - i.e.
maybe instead of assuming that a cloud could be stress-tested for
anything conceivably possible to "throw at it" (based on the nature of
"X" in the XaaS), we could - instead - look into dampening the effects
of any possible abuse by installing "X"-level tarpits to be available
for as soon as something comes around (a-la firewall rules on the fly
... I know, with their own drawback of DDoS in themselves) ...
basically "throwing on the floor" everything that surpasses a specific
threshold (*cloud threshold*, that is). It will be up to us to decide
which level ("X") that is required to be implemented, in every type of
cloud.

Stefan

[Tom Deckers]

I believe this illustrates how important it is that application engineers and infrastructure engineers go hand in hand on this one.  There should be a fine balance between the constraints introduced by the infrastructure and the fact that you want virtually any application to run in your environment.

This requires you look at application decomposition, translate that into a piece of meta data and provide that to the infrastructure provider.  Being able to capture the multitude of application architectures, requires a thorough study of the application domain.  Or are we only supporting a standard 3 tier application in our newly developed interoperable stack?

Regards,
Tom.

[Michael Richardson]

>>>>> "Lori" == Lori Mac Vittie <L.Mac...@F5.com> writes:
Lori> Isn't the point of stress testing (largely) to find the upper
Lori> bounds of capacity/performance? Isn't part of the promise of
Lori> the cloud that we don't have to worry about that?

No. The point of stress testing is to identify what the constraints to
performance are so that you can either remove or harness that
constraint.

Unless you do stress testing, you won't know which part of your
infrastructure to elastically expand to get more capacity, so you'll
expand everything, spending far more than you need to.

--
] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[C Wegrzyn]

I would also add to validate your system can handle high loads.

Chuck Wegrzyn

[Lori Mac Vittie]

Absolutely. There are plenty of scenarios in which an application works fine
until under heavy load. Memory leaks is an obvious case as it rarely shows
up until the stress of high load/long term use uncovers them.

Lori

> -----Original Message-----
> From: cloud...@googlegroups.com [mailto:cloud...@googlegroups.com]
> On Behalf Of C Wegrzyn
> Sent: Thursday, February 19, 2009 9:01 AM
> To: cloud...@googlegroups.com
> Subject: Re: A worm in the cloud ...
>
>

[Hoff]

It seems we're all hung up on definitions these days, so let me excise
my wordhammer:

A worm is not the same thing as a botnet. A worm is self-propagating
application that replicates itself over a network and a botnet is a
collection
of compromised networked nodes controlled from a C&C infrastructure.

The former can be delivered by the latter, but they are mutually
exclusive.

Don't make me draw a diagram, you know I'll do it! ;)

Further you were being melodramatic for emphasis when you said:
"What worries me most is a "blue pill" sitting along side my
hypervisor

utilizing chip level VT features." Right? I mean that was for effect,
ya?

Assuming your speaking in the present tense, If you're biggest
concern
is hypervisor subversion, then you must
have VM lifecycle management, generic security visibility,
monitoring,
change management/control, intrusion detection/prevention,
firewalling,
federated strong authentication, data segmentation and encryption and
multi-tenant compartmentalization licked and haven't told the rest of
us.

...just to name a few.

Just sayin'

[Jonathan Davis]

On 18 Feb 2009, at 18:53, Reuven Cohen wrote:

>
> A worm in the cloud is called a botnet. By far some of the most
> cutting edge cloud "command and control" work is coming out of the
> eastern European criminal technology syndicates. The technology
> behind some of the latest fastflux C&C approaches are amazing to say
> the least. What worries me most is a "blue pill" sitting along side
> my hypervisor utilizing chip level VT features.
>
> r/c

Joanna Rutkowska's bluepilling the Xen hypervisor in August last year
gave me a fright at the time. Like you, it still worries me.

One man assiduously tracking the phenomenon of Botnets and their
Russian Business Network controllers is Sci-fi author Bruce Sterling.
Here are some of his blog posts on the subject:

http://www.wired.com/search?query=botnets+sterling&siteAlias=blog&x=0&y=0

I also keep an eye on the Zero Day security blog on ZDnet. They are
also very up to speed on this:

http://blogs.zdnet.com/security/

Kind regards,

Jonathan Davis
Chief Technical Officer
DNS Europe - http://www.dnseurope.net