Re: True definition of Intrusion Prevention

[George Capehart <gwc () acm org>]

On Tuesday 06 January 2004 01:39 pm, Vigilant Labs wrote:

<snip>

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

Hello Joseph,

Well, this is a great way to keep the conversation going . . . ;-)

I would like to suggest that any organization that is not 100% on 1 and 
2 are failing in their risk management process (and for my protection 
and theirs shouldn't be connected to the world at large . . .).  If 
they're not 100% on 3, and they don't get help from someone who is, 
they deserve what they get.  

> 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) ; )

As it is at the moment, there is no penalty for connecting to the 
Internet even if the organization or individual is clueless.  Right 
now, the burden (such as it is or is not) is on corporate governance 
and individual conscience to understand ones system(s) and protect 
them.  In most cases in which an individual or corporation operates a 
system that interfaces with the public (automobiles and long-haul 
trucking come immediately to mind), the operator must demonstrate 
understanding of basic "rules of the road" and safety before they are 
licensed to use the system "in public."  And there are criminal and 
civil penalties for failing to do so.  I suspect that until the use of 
digital systems comes under the same kind of regulation, we will 
continue to see individuals and organizations behaving with total 
disregard for their own risk and the risk they pose to others . . .


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

Couldn't agree more . . .

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

That shouldn't be a great surprise.  Every System and network is 
different . . .

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

Yes!  Understand the vulnerabilities the system has.  Understand the 
current and probable future threats that the system may face.  
Implement whatever combination of controls that the risk management 
process determines is appropriate.  Rinse and repeat.  :-)

> Hope some of these comments were useful.

And thought provoking.

> Have a secure New Year!

Cheers,

George Capehart

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