RE: Changes in IDS Companies?
From: Rob Shein (shoten@starpower.net)Date: 10/23/02
- Previous message: IDS ?: "Wireless IDS requirments"
- In reply to: Aaron Turner: "Re: Changes in IDS Companies?"
- Next in thread: J. Foobar: "RE: Changes in IDS Companies?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Rob Shein" <shoten@starpower.net> To: "'Aaron Turner'" <aturner@pobox.com>, <focus-ids@securityfocus.com> Date: Wed, 23 Oct 2002 13:45:57 -0400
(All snips are the quotes by Martin Roesch.)
Aaron Turner wrote:
>
> I disagree. The technology really isn't first-gen. NIDS
> detect attacks and firewalls drop packets. NIPS is just a
> firewall which drops packets based on their threat level
> rather than just IP address/port. While it's a different
> concept and the actual implimentations are 1st gen, the
> technology behind both are reasonably developed. Market
> acceptance however is an issue (though IMHO for a very
> different reason which I'll explain later).
<snip>
> A lot of the problems you're talking about right now are the
> same problems that firewalls have faced in the past. What if
> the firewall get's DoS'd? What
> if it crashes? Does it fail open or close? Nothing new
> here. Agreed,
> there are issues with NIPS technology if it's deployed in a
> way that doesn't maintain the network availablity, but
> they're not issues that haven't been solved for already.
Ok, here's problem #1. It sounds like you're saying, "IDS technology
works well enough, and is part of this/DoS isn't that much of an issue."
The two don't work together. Everyone on this list knows (I hope) how
much easier it is to DoS an IDS than it is to do the same to a firewall.
Furthermore, this totally fails to address Marty's excellent point of
"what if" with regards to such a scenario.
<snip>
> This "basic question" is the same question everyone has of
> every NIDS/HIDS. If Hogwash uses the Snort engine, why would
> it fail to find an attack that Snort finds? And just like
> some companies deploy a variety of NIDS solutions for full
> coverage, they can do the same with NIPS.
>
> I would argue that by being inline, the chances of this
> happening are *far*
> less. When a NIPS drops packets because of a bug or it's
> overloaded, it's obvious, when a NIDS (or the switch's SPAN
> port) drops packets, it's
> a lot harder to tell.
>
> Of course, just as the more mature NIDS solutions (such as Snort) are
> incorporating a variety of detection solutions (sigs,
> protocol analysis,
> etc) so can too NIPS. Personally, I think that's the
> critical issue (more on this later).
It would fail to find an attack that Snort fails to find. And there
always will be such attacks, furthermore. Conversely, HIDS has a much
easier time seeing a sudden change to a file that is not supposed to
change, and thus the argument for layers.
> My take on it is that these issues will be handled the same
> way with NIPS as it was for firewalls (which also went
> through a period of
> instability). People will be using H/A & load-balancing
> solutions (either
> hardware or software) to provide the reliability necessary to
> meet their
> SLA's and performance to fend off attacks. Later on, things
> will move
> from software to hardware, to get added performance/reliability just
> like firewalls.
Uh, if one firewall is unstable because its technology is immature, how
is adding the complexity of clustering going to improve the situation?
I don't remember people doing such things back when firewalls "weren't
there" yet...I remember them either implementing less effective ones in
the name of uptime, or passing on them altogether.
<snip>
> I think this political battle is going away. Companies are
> realizing that
> a firewall isn't enough. NIDS are great, but they don't
> solve the basic problem of, "Now that I've been rooted now
> I've got to pull people from
> their current projects to rebuild the servers." Since NIPS takes a
> pro-active rather than reactive methodology, it solves for
> this problem like no other (at least current) solution can.
No, NIPS _could_ solve this problem like no current solution can. It's
not there yet. And still...what about the attack it doesn't know how to
see yet?
> HIDS/HIPS is a *lot* more work to maintain then AV. Nobody
> tunes their AV solution, but people spend a lot of time
> tuning their *IDS solution, and frankly, most of the
> management tools so far suck. Compare Checkpoint's 3 tier
> management solution to the IDS solutions out there and you'll
> understand what I mean.
>
> And again, put a few load balancers around it (even use your existing
> firewall L/B's) or install something like StoneBeat and
> failure issue becomes moot.
Again, HA is not something you can just slap on to an immature and
unstable technology to make it better. And once upon a time, AV used to
be a total nightmare in the enterprise. It matured, just as HIDS has
been doing.
> The political battle you mention IMHO is missplaced. The
> problem with NIPS and NIDS in general is accuracy. Since
> NIPS make policy decisions based on questionably accurate
> methodologies people aren't going to want to
> actually use the preventive measures available. Just think about the
> problems people would experiance if firewalls regularly accidently
> got port numbers or IP addresses wrong.
>
> Nobody is going to drop packets if they're not sure it's
> dropping the right packets. And if you're not going to drop
> packets, why have an NIPS? Of course some people deploy NIDS
> with detection accuracy levels
> that are nearly criminal, so what do I know?
The problem is not with accuracy, but with ambiguity. Normal traffic is
not the white-picket-fence model of conformity it needs to be to be able
to draw black and white distinctions between "good" and "bad" traffic in
a totally reliable way. Furthermore, "bad" traffic can differ only
slightly from "good" traffic, the only difference being a distinction
that is not visible on the wire, and the attack can only be detected
after is passes. A SYN flood looks a hell of a lot like a packet
capture of www.cnn.com every time a major news event breaks. You have
to wait until you get/don't get SYN/ACKs back to know for sure (unless
you've managed to install one of your sensors on the attacking network).
Increased usage of IPSEC encryption will mean increased fragmentation as
packets are decrypted. And there are many other situations, some of
which have probably not even been thought of yet. This is just being
addressed now, in the IDS space...do you really want to let it control
the nature of traffic on your network so soon?
I have to agree 100% with Marty, and say this: "Yes, it's promising.
Yes, it's in demand. Yes, it's worth pursuing, whether for innate value
or because the market wants it. But it's not as good as most IPS
vendors are claiming yet, period."
- Previous message: IDS ?: "Wireless IDS requirments"
- In reply to: Aaron Turner: "Re: Changes in IDS Companies?"
- Next in thread: J. Foobar: "RE: Changes in IDS Companies?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|