IDS mailing list archives
Re: True definition of Intrusion Prevention
From: George Capehart <gwc () acm org>
Date: Tue, 6 Jan 2004 22:13:21 -0500
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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- Re: True definition of Intrusion Prevention, (continued)
- Re: True definition of Intrusion Prevention George Capehart (Jan 05)
- RE: True definition of Intrusion Prevention Teicher, Mark (Mark) (Jan 05)
- RE: True definition of Intrusion Prevention Fengmin_Gong (Jan 05)
- RE: True definition of Intrusion Prevention Fengmin_Gong (Jan 05)
- RE: True definition of Intrusion Prevention Teicher, Mark (Mark) (Jan 05)
- Re: True definition of Intrusion Prevention George Capehart (Jan 05)
- Re: True definition of Intrusion Prevention Frank Knobbe (Jan 05)
- Re: True definition of Intrusion Prevention George Capehart (Jan 05)
- RE: True definition of Intrusion Prevention Bohling James CONT JBC (Jan 05)
- Re: True definition of Intrusion Prevention George Capehart (Jan 05)
- RE: True definition of Intrusion Prevention Vigilant Labs (Jan 07)
- Re: True definition of Intrusion Prevention George Capehart (Jan 07)
- Re: True definition of Intrusion Prevention Andrew Plato (Jan 08)