So I was able to shoot to the Arbor-con today and I'm posting my
comments here.
Arbor's product (for those of you who haven't seen a demo) is based on
the following use case (note: I don't speak for Arbor. I'm just
replaying the demo as my misguided brain saw it for you in case you want
to read them):
1. Arbor's network engine sits on various points of your network or
recieves netflow data for a while, recording normal traffic
2. It corrolates that traffic and models it, so it can say "this host
talks to this host on this port". It can group hosts, etc.
3. You can use a really slick web-based portal (IE only, I think) to
view/search/etc this data (this is pretty cool in and of itself) (parts
of the product are python, but I'm not sure what parts)
4. If you are getting hit by a worm, you can say:
o For service getting hit by worm, make the network look like it did
last week (i.e. only hosts that should talk to each other are allowed to
talk to each other)
o This is done by automatically generating ACLs and shoving them out
to your network infrastructure (switches, firewalls, etc)
o You can manually review and edit these ACLs, but imo, this is a
management nightmare waiting to happen, so most likely you'll just click
"go" to make your network start working again as if there was no worm
o You can whitelist hosts and say "never block our trading server no
matter what"
5. They have a learning mode and a learned mode. If a new host pops up,
its actions are unrestricted by the host behavior heuristics
6. There is also a flow-rate heuristics engine for doing worm detection.
The interactions between these two heuristic engines are somewhat lost
to me, however, and a likely place for someone to poke at.
7. Like any enterprise product, the cost is highly variable. I'm
assuming 6-7 figures.
The use case is fairly interesting, and obviously applicable to
traditional intrusion detection/prevention. I think there are other
avenues that wern't discussed, of course, like automated attack/worm
packet signature development and deployment. (hmm. This host A seems
infected, it spewed string ABCD at host B. Then host B started doing the
same thing. Let's block all packets with string ABCD on that port from
any host to any host). I quite like the idea of doing packet-size (or
flows of packet sizes) recording as well, and using that as attack
signatures, since it's really easy. Sizes are cheap hashes usually.
After Jose talked, and Arbor demonstrated their product, there was a
panel discussion with Dug Song (Arbor), Greg Shipley (Neohapsis), and
Dave Meltzer (Intrusec).
One other thing I was thinking about is that (as Jose Nazario noted)
there are actually very few worms coming out, given the number of
wormable exploits that come out every day. In Jose's model
"exploitability" comes into play to determine that exploits. I'm not
going to debate his model. Any model is fine. But what I would like him,
or someone else to do, is to say that for X exploits on Windows last
year, we had Y worms. The model should "predict" this, at least
reasonably closely. Then all you have to do to predict a post-SP2 world
is drive exploitability down a lot. My intuition is a 0-worm world
post-SP2 (assuming SP2 gets ported around to the other OS platforms,
which it no doubt will.) Of course, getting SP2 (and the chips it needs
to run N^X) into significant acceptance is a 5-year job, optimistically.
Linux, of course, is already there. I predict no worms which affect
Fedora or any host running execshield (a watered down version of PaX,
but it comes by default!). You can still write exploits for them, but
worms, as predicted by the model, are unlikely to happen.
When I say worms, of course, I'm not talking about things that need
people to click on them, or client side attacks. For that, you'd need
grsec-level capabilities, which isn't scheduled until longhorn. Mail
worms are easily filtered on the mail server anyways.
Anyways, hopefully this was at least moderately interesting to someone. :>
-dave
P.S. When worms go, so do IT security budgets. I predict a collapsing
market.
_______________________________________________
Dailydave mailing list
Dailydave_at_lists.immunitysec.com
http://www.immunitysec.com/mailman/listinfo/dailydave
Received on Jul 20 2004
Intro
