IPS and IDS (was RE: Changes in IDS Companies?)

["Chris Winter" <Chris.Winter () corbett-tech com>]

(In response to Matt Harris' post about utilizing NIDS to make
modifications to firewall and router ACLs/policies in response to NIDS
events)
Aaron Turner wrote:

~snip~

> 1) Futzing with router ACL's or firewall policies via your IDS is not
granular. They don't drop a specific connection (the attack) but rather
all traffic on a given port for a client/server. This can have very ugly
effects for legit traffic.
> 2) It's too late.  The attack has already reached the target.  Consider
something like jill.c which exploits the IIS-ISAPI buffer overflow and
opens a connection back to the attacker on another port and you'll
quickly understand why this method of "protection" is more hype than
reality.
> 3) Many attacks are internal.  Most firewalls are at the border, hence
there's nothing the firewall can do, unless you (re)deploy more
firewalls.

~snip~

In response to the above:

I do not disagree with Aaron's points above, however I would like to add
some information to his points:

1) It is possible to get fairly granular on Cisco gear by utilizing NBAR
(Network Based Application Recognition) to roughly correspond to IDS
signatures, and then fire and ACL based on this match (see
http://www.cisco.com/warp/public/cc/so/neso/ienesv/cxne/nbar_ov.htm for
an NBAR description, and
http://certcities.com/editorial/columns/story.asp?EditorialsID=76 for a
description of how to utilize NBAR with ACL's).  Of course this has
issues:
        a) It is a Cisco specific solution, and only works on certain
product lines.
        b) You would have to roll this yourself, as no vendors currently
support NBAR in their active response capability (at least to my
knowledge).
        c) NBAR is not an IDS engine, nor is it intended to be (its main
functionality appears to be advanced traffic shaping, for QoS).  It
doesn't have much (if any) in the way of data normalization or
preprocessor capability, the way an IDS does, thus it is susceptible to
many of the past issues which most current IDS vendors have already
addressed (such as obfuscation, etc.).
        d) There will be some performance issues, as NBAR looks all the
way into the packet.  In my experience, during the NIMBDA outbreak, the
performance impact was minimal (on a moderately used 6509), YMMV.
Does this make Active NIDS, via ACL modification a viable alternative to
NIPS? Not in my opinion, however it does add another option, for the
Defense-in-Depth blanket.

2) Active NIDS, as opposed to NIPS, is certainly not real-time.  I would
refrain from calling Active NIDS hype though.  It falls down on initial
attacks, however it does have the potential to mitigate further attacks
using the same attack vector.  Where I see active IDS being more useful
is in other forms of IDS events, such as probes, prolonged attacks, and
policy violation.  Unfortunately, in my experience, active NIDS is
usually used to react to attacks, thus your point is quite valid.

3) This holds true for many organizations from a firewall perspective,
however it does not from an ACL perspective, as most networking gear
supports some form of ACL.  As I mentioned in #1 above the use of NBAR
with Cisco gear has the ability to mitigate some of the weaknesses of
traditional ACL functionality.

Not mentioned in Aaron's points above are the main reason I see for not
utilizing Active NIDS (this was probably covered in an earlier mail):
        - False Positives
        - Applying ACL's or firewall policy changes may call for a
reload of the ACL/policy, thus dropping all current sessions through the
security device.  It may not be a problem to reset the firewall here or
there during the day, however if your IDS is doing it frequently, this
has the potential to seriously disrupt communications across that
device.

With all that said, how many of us are actually using Active NIDS
currently?  In my experience it is used sparingly, and only for
signatures where the need to 'interactively' block certain traffic
vastly outweighs the risks (false positives, and the potential to block
legit traffic).

This brings me to my assessment of NIPS.  I see them as a replacement
for Active NIDS sensors.  You eliminate much of the active IDS issues
mentioned above, as the NIPS itself does the blocking of the offending
traffic.  You still have to deal with the NIPS issues covered
extensively in this thread, however in many cases the need for the
active response may outweigh those issues.

I don't not see NIPS as a replacement for passive NIDS, as they don't
bring any extra functionality to the table, and the issues with it
remain.  I find the argument for placing NIPS inside the network, in ALL
the locations you might place NIDS, a hard argument to make, unless the
following issues are dealt with:
        - Total cost of ownership is inline with NIDS.
        - Bottlenecking.  The NIPS performance must be on par with other
core networking gear utilized on the monitored segment.  By this I mean
it's latency must be the same, or very close to that of a router or
switch.  This really begins to rear it's ugly head where QoS is
important.
        - Fail-Open.  If the NIPS has any problems, packets MUST not be
discarded.  Problems can range from, DoS attack, to performance
degradation, to total hardware failure.  Do not confuse the need to
Fail-Open with the ability to configure the NIPS in a fault-tolerant or
high-availability configuration.


I don't see much difference between HIDS and HIPS.  Many (most?) HIDS
support IPS-like functionality.  I see them blending into a single
designation, whatever the marketing guys want to call it.


Thanks,

-Chris

----------------------------------------------
Christopher Winter 
CISSP, MCSE 
Senior Security Engineer 

Corbett Technologies 
703.519.8639 x286 office 
703.519.8752 fax 
chris.winter () corbett-tech com 
http://www.corbett-tech.com 
----------------------------------------------