Re: How to choose an IDS/FW MSS provider

[Mark Teicher <mht3 () earthlink net>]

This is why most IDS/IPS vendors have an either licensed db, run-time db or freeware db on the backend where all alerts 
can be saved.  Some IDS/IPS backend db have a very complicated db schema, as other do not.  There are some companies 
who specialize just in recording the network stuff (i.e. SandStorm, Network General) with terrabyte drives and leave it 
up to the admin or MSP to sift through the stuff and separate into different buckets (interesting stuff, very bad 
stuff, unknown, not so interesting stuff, stuff that we really don't care about).  If you look at most of the IDS/IPS 
vendors in the appliance form or software form, they have a either a two-tier or three-tier architecture in order for 
the stuff to be looked at on the wire, passed to a console for human to look at or just dumped into a database.  The 
problem is really the human part since most IDS/IPS vendors can't know everything about a particular network that is 
passing lots of network traffic whether good or b
 ad. 

/m

-----Original Message-----
From: "David W. Goodrum" <dgoodrum () nfr com>
Sent: Mar 12, 2005 5:29 PM
To: Richard Bejtlich <taosecurity () gmail com>
Cc: focus-ids () securityfocus com
Subject: Re: How to choose an IDS/FW MSS provider

First, "recording everything" is not what IDS's were EVER meant for, 
IMHO.  If you want to record everything try tcpdump with lots of hard 
disk space.  :)

However, I hear what you are saying... Many IDS vendors have implemented 
some form of auditing function, just like you're talking about.  The 
issue becomes one of how fast can data be parsed and stored, and how 
long can you afford to keep it.  For example, NFR, ISS, SourceFire and 
others can create "audit" trails of every web request, every mail, every 
ftp request, etc.  The inline products offered by these companies can 
still perform those audit functions.   We do have customers who use our 
product entirely for the purpose of simply recording every web request 
on the wire.  However, that's not what most people want these days. 
Customers want the attack stopped, not a gig of post mortem evidence 
they have to sift through to figure out why they got hacked.  They want 
better alerting, and that is what all IDS/IPS vendors are trying to 
provide, whether it's by reducing false positives by using vulnerability 
correlation (via correlating with Nessus or other products), using OS 
fingerprinting correlation built into the Sensor (or via some third 
party scanning system), or using application fingerprinting.  _Most_ 
customers would rather have more high fidelity detection/prevention, and 
less data.

to comment on your comment about having separate audit devices and acl 
devices, I agree and disagree with you.  You say that if they beat the 
inline device (i.e. it doesn't alert of prevent), that it also beat it's 
auditing functionality.  This isn't true.  If we record every web 
request, but fail to alert, we've still audited the events 
successfully.  However, I would like to see auditing moved off to 
another device as it takes some of the load off of IDS/IPS systems.  
People keep adding more feature requests (not just intrusion detection, 
but security  policy management), and want it to go faster and faster.  
When customers break up the roles, it allows vendors to focus more on 
specific tasks, such as alerting smarter.  It would be great if 
everybody just ran tcpdump on terabyte drives, and let IPS systems stop 
worrying about those things.  I just don't think it's ever going to happen.

-dave

Richard Bejtlich wrote:

> On Sat, 12 Mar 2005 10:11:44 -0500, David W. Goodrum <dgoodrum () nfr com> wrote:
>  
>
> > But, you're missing the point.  What I'm saying is that the two
> > technologies are merging where appropriate, and that it is a GOOD thing,
> > even for large enterprises, not just small ones.   
> >    
>
> David,
>
> I'm not missing the point.  I'm making an entirely new one.  (In
> reality, my viewpoint is a decade or more old, but vendors and pundits
> have apparently forgotten it.)
>
> You have to be able to detect an attack to stop it.  Layer 3 firewalls
> detect attacks by inspecting layer 3 headers for prohibited IP
> addresses or other IP header features.  Layer 4 firewalls detect
> attacks by inspecting layer 4 headers for prohibited ports, flags, and
> so on.  "Layer 5" firewalls detect attacks by tracking sessions. 
> Layer 7 firewalls (aka IPSs) detect attacks by inspecting layer 7
> information for prohibited content, protocol inconsistencies, etc. 
> Once detected, firewalls block attacks.
>
> I welcome all advancements that make smarter access control decisions.
> We certainly need them in a world where most hosts (often Windows)
> can't independently defend themselves!
>
> Attack detection, whether for alerting ("IDS") or blocking ("IPS"),
> can be circumvented.  This is not a slam on vendors (much smarter than
> me), but an acknowledgement of the difficulty of the problem set.
>
> Almost every incident response I have performed took place at a
> facility with an IDS or IPS deployed.  Often, neither device had
> anything useful to say about the incident.
>
> When you realize this, the natural next step is to use an access
> control device to limit what you can and deploy an audit device to
> keep track of everything else.  Forget about "intrusion" or "attack"
> detection -- simply record everything that happens.  You never know
> what piece of information will yield the clue to investigating an
> incident.
>
> I have not seen a single commercial IDS or IPS perform the sort of
> network audit needed for post-mortem incident response.  If either
> device is bypassed, the security staff has nowhere to turn.
>
> I do not want a single device responsible for both access control and
> network audit.  When an intruder beats a "converged" device, the
> defender becomes completely blind.
>
> These realities form the heart of my network security monitoring
> theory.  I don't think about "intrusion detection" or "intrusion
> prevention."  I think in terms of indications and warnings (usually
> via an "IDS") and policy enforcement (via an access control device).
>
> Sincerely,
>
> Richard
>  

-- 
David W. Goodrum
Senior Systems Engineer
NFR Security
703.731.3765


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------





--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------