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.
--------------------------------------------------------------------------
