RE: True definition of Intrusion Prevention

["Vigilant Labs" <labs () thevigilant com>]

George you hit the nail on the head, EXPERIENCE. Sharing positive
success stories on this list is by far some of the best security
education we could all receive. 

For the past few years I worked at Top Layer Networks*. While my job
responsibilities varied, I felt that my most important responsibility
was my role on the product planning team for the Attack Mitigator IPS
product. Previously coming from the "user-side" (at ABN-Amro and Datek
Online) I thought it would be easy to design a "high speed in-line
appliance that could look for snort signatures and have the option to
block them". Sounds simple, right? But as it turns out, this was very
difficult. When designing a product like this there are fundamental
approaches to consider that could make or break the product. For
example, do you build an IPS product that "augments" detection
technology (aka IDS) like Top Layer's approach or do you build an IPS
product that "replaces" IDS like Intruvert or Netscreen's IDP**
approach. While I'd rather not have tons of replies with the supposed
answer to this question, I wanted to throw it out there so that people
can start to understand and appreciate the thought that goes into these
products. 

Another difficult decision is how does the product ship? Does it ship
with all checks (i.e. signatures, prevention mechanisms, etc...) turned
on? If that was the case the product would break 99% of the networks
that it was installed into. Should the product be shipped with some of
the checks turned on? How is the vendor to know which checks are even
contextually relevant to the customers environment? Does Nimda matter
when protecting a production Unix/Apache environment? Ok, ok so we'll
ship the product with all the check's off? Now the product does nothing
when you put it inline and the user is required to "turn things on" to
secure their environment. This third option is the safest choice from
the vendor's perspective but assumes three important details to consider
the implementation of the product successful.

1. The user knows their environment extremely well. 
2. The user knows what assets they are trying to protect with the
product.
3. The user knows the product well enough to configure it properly to
protect those assets. 

As with any security tool, (Firewall, IDS, Policy thingamig-er) what
matters is how the product is used and configured. Often times people
don't understand how the product is intended to use, they just think
"Whelp, I paid a lot for this it better secure me when I put it in." As
we all know, network security is a difficult problem that is unique to
every environment. Networks are uniquely designed, assets carry
different risks, and what is important to one organization may not be as
important to another. Proper planning is the key to having a successful
IPS implementation. While this step may seem obvious, it almost always
overlooked. 

Most people don't understand what how they intend to protect themselves
with the product. The most common (Doh!) I've repeatedly seen is an IPS
deployed on the internet gateway, while no protection exists after the
VPN endpoints. (with 100+ users connected to the core of the network
sitting behind cable modems of course) ; )

To attempt to answer the subject line of this question...

Definition:
Network Based Intrusion Prevention - And inline network device that
allows blocking, mitigation (slowing down), of malicious traffic in one
of the following manners:
Layer 2 - Mac Address Filtering
Layer 3 - Source IP Filtering - "You triggered this check 5 times, I'm
going to automatically block your source IP for 10 minutes."
Layer 4 - Port Based Filtering - Basically mimic's firewall
functionality, could be triggered as in Layer 3 example.
Layer 7 - Application Based Filtering - This can be extremely advanced
and is probably the most difficult prevention feature to design from a
product standpoint, both resource wise and from a fundamental design
standpoint. Examples include: Whitelisting and Blacklisting of URI's,
RPC Bounds checking, FTP command restrictions, etc...

I guess there are two points to what I'm trying to say. 

1. Building a product that will solve everyone's problem by just
plugging it in is impossible. In my new role, I've been trained in or
have evaluated all of the most popular IPS products on the market today,
all of them have their strengths and weaknesses, but NONE of them work
well "out of the box".

2. Plan before buying, plan more before implementing, test, implement,
and tune. This IS the recipe for success.

Hope some of these comments were useful. 
Have a secure New Year!

Joseph C. Magee
Chief Technology Officer
Vigilant, LLC.
Phone: 617.921.8671
Fax:   877.577.6718
E-mail: jmagee|at|thevigilant.com
PGP FP: 22A2 906C 1FA3 0A28 8471 20C0 B9AD A7A0 8671 5F14

* My decision to leave Top Layer was to start a professional services
company focused on integrating different types of security event data
together and tuning the output according to an organizations weighted
risk, ya know, the other side of the problem. : )  I still believe in
the company and their products.

** These products were built with the intent or ability to replace IDS
(and there is nothing wrong with that.) Don't let them tell you
otherwise. An issue later faced is that their target market, fortune
1000, banking, financial services, insurance and healthcare usually
already have a heavy investment in another vendors IDS, hence the
"augment card" is played. So they will claim that they can do either/or.

> -----Original Message-----
> From: George Capehart [mailto:gwc () acm org] 
> Sent: Monday, January 05, 2004 5:26 PM
> To: Brad McGary
> Cc: focus-ids () securityfocus com
> Subject: Re: True definition of Intrusion Prevention
>
>
> On Monday 05 January 2004 03:12 pm, Brad McGary wrote:
> > I agree with your comments but would offer the thought process 
> > regarding the structure of an attack scenario. Most attacks 
> start with 
> > recon and end with target specific exploits. I've been using a 
> > commercial version of Hogwash for about two years and have 
> > significantly reduced the number of successful attacks launched 
> > against our environments by preventing the more prolific 
> recon tools 
> > from returning target intelligence. As for the worm attacks 
> we've been 
> > relatively successful at stopping these since they mostly utilize 
> > exploits which have mature snort signatures. In the end there's no 
> > panacea and we see our share of false positives and false negatives 
> > I'm sure. Please take these comments as just my specific experience 
> > and understand I certainly don't want to engage in any 
> heated debates.
>
> Hi Brad,
>
> Thanks for sharing your experience.  And, while heated 
> debates tend to 
> drift away from the topic, I'd be interested in hearing what others 
> have done to try to head off attacks.  This gets exactly to the point 
> that, to my way of thinking, to prevent intrusions one needs 
> to employ 
> a *process* which has many dimensions.  You have very clearly 
> described 
> one aspect of that process . . .
>
> Regards,
>
> George Capehart
>
> --------------------------------------------------------------
> -------------
> --------------------------------------------------------------
> -------------

---------------------------------------------------------------------------
---------------------------------------------------------------------------