IDS mailing list archives

Re: ROI (ROSI?) on IDP devices


From: "\"Zow\" Terry Brugger" <zow () acm org>
Date: Fri, 6 Mar 2009 09:26:32 -0800

Ravi,

I found the case you shared with us quite interesting:

taken permission from the responsee to give gist of explanation.  It
is a Microsoft house, ie mostly Microsoft products are used in the
organization.

Mmm humm. So they use Microsoft's PDF reader, and Microsoft's Flash
player? I'm being flippant, of course, because too many organizations
seem to think that they only have to worry about the OS, whereas
vulnerabilities go all the way up the application stack.

IDP device vendor they went with provides protection
measures (rule updates) only when Microsoft releases patches.  Some
times rules update with Microsoft vulnerabilities are being given
after 2 to 7 days by IPS vendor.

Well, thar's their problem! I'd say that's a useless IDP system, and I
hope that anyone who uses such a system fails to see the value in IDP
systems. I see three key problems with this system:
1. This does nothing to protect you against vulnerabilities that there
are no patches for. No matter how many times you tell people not to
click on links in their email, they still do.
2. Signatures should be provided for more than just Microsoft products
-- they should be available for every application and protocol that a
business might conceivably use -- at least on Windows, if that's going
to be your focus (and there's nothing wrong with that). That means
vulnerabilities in non-MS applications such as Adobe Reader, Flash,
Firefox, AIM, etc. Rules to detect traffic which may be a policy
violation (such as various IM and P2P protocols) would be useful as
well.
3. The signatures are lagging too far behind the vulnerabilities.
There is usually sufficient public discussion of these vulnerabilities
for people to develop Snort signatures in advance of MS providing a
patch, or at worst a few hours after the patch comes out. The really
good (and that's quite subjective) IDS/IPS vendors have established
relationships with the large software vendors to develop signatures in
advance of public announcement of vulnerabilities, and any IDS/IPS
vendor worth their salt has a vulnerability research team to find
vulnerabilities and develop signatures that none of the other IDS/IPS
vendors have to give them a competitive edge. Some of them even make
it sound like a protection racket: "If you used our IDP, you would
have been protected against this vulnerability two years ago."

Patch Management systems would have
patched the systems and software by that time rendering IPS protection
useless. Client side attack detection by IDP devices is not really
effective and anti virus software on desktops seems to do better job.

No wonder -- they're probably actually using an antivirus system from
a respectable vendor who has the three above points covered. While
there are actual, dedicated HIDS (Host-based Intrusion Detection
Systems) in the marketplace, in practice, antivirus serves as a fairly
effective HIDS for most organizations. The value in NIDS/IPS is
covering your systems without AV, or without up-to-date AV signatures,
or when an attacker manages to disable AV on the host. It's defense in
depth. If you have a very strong, well managed AV deployment, NIDS/IPS
will be of less value to you.

The responsee seems to feel that IDP devices are good only if legacy
software is used for which software vendor does not provide patches.

That's only a justification if the IDP vendor produces signatures for it.

It appears that this house has some web applications.  To protect from
web application attacks, they seem to use web application firewall.

If these are custom built web-apps, the IDP/IDS will only be able to
detect the same generic XSS / SQL injection attacks that the webapp
firewall can. Now if they're running some popular webapps, like forum
and wiki sites, there are probably a number of attacks that the webapp
firewall is not going to protect them against that a decent NIDS/IPS
should have signatures for.

With protection  provided by "Patch Management System", "Web
application firewall"  and traditional firewall devices,
justification for continuation of IDP devices seem to be on slippery
slope. At the end he mentioned that other types of  deployments might
see value of IDP devices.

Honestly, based on what I've heard here, I agree that their IDP is
useless, and they should 86 it. Any environment where such a device
would be useful has probably ignored security so badly that they
wouldn't buy such a device anyway. I think if they took a look at IPS
offerings from other vendors, they might see more value in it. Most
vendors will lend you an eval unit, especially if you've demonstrated
that you're serious enough that you've already got one and are just
looking to replace it with something better. Some will even give you a
credit if you send them your old unit.

Other response I got is vague on details and seem to suggest that many
buy these devices out of fear, but realize eventually that they are
not as effective as they thought.

The bigger problem I have with IPS is that with the false positive
rate we get on our IDS, it would kill us if the device started
blocking everything it alerts on. A lot of this is just because I'm
working in a very large, diverse environment. It's not a question of
tuning -- I've only seen a handful of signatures that have a 0% false
positive rate.

I hope I will get some responses with positive experiences of using
IDS/IPS devices.

My fear of overblocking with IDP aside, the organization I work for
has found IDS to be very useful. We have numerous sensors both at the
borders and inside the networks across the enterprise. While I can't
discuss exact metrics, I can say that we detect a lot of our incidents
this way. We're currently working on expanding our IDS coverage. While
we try to address the root causes, the fact is in an organization as
large as ours, there will always be systems that stop talking to the
patch server, or grabbing AV updates, or emails that don't get
blocked, or a host of other things that go wrong, so IDS will always
have value.

My two bits,
Terry

#include <stddisclaim.h>



Current thread: