IDS mailing list archives
RE: True definition of Intrusion Prevention
From: <Fengmin_Gong () NAI com>
Date: Fri, 2 Jan 2004 16:29:16 -0800
Hi All, Ron Gula and George Capehart etc. have made many good points about the current state of confusion facing customers surrounding "intrusion prevention". I agree with the overall comments. I do have a slightly different take on the interpretation of "intrusion prevention" and on how customers as a whole can better deal with the current situation. Before I offer my personal perspective, I do want to let you all know that I am with NAI as part of the IntruVert acquisition and I was one of the key people behind the technology, although I will be staying focused on the IPS perspective. "Intrusion prevention" can be achieved through three main approaches: (1) secure engineering - to build system with no vulnerability and use it with perfect practice, (2) taking perfect remediation steps to uncover vulnerabilities and patch them before the attackers, and (3) detecting the exploit attempts (i.e. attacks) and blocking them before serious damage is done. Note that all three approaches are not mutually exclusive. Secure engineering has been a research area for many years, it's still not clear how practical it can get and when. Remediation should be pursued in all environments possible, but it cannot be an end-all solution either due to difficulties with automated deployment and the diverse vulnerabilities that can be exploited without us knowing them. I refer to (3) as the most practical "intrusion prevention" today - detection with real-time blocking. Most noticeable example will be shellcode execution detection and dropping the payload in the network or preventing execution in the end hosts. As pointed out earlier by Ron, firewall would have achieved adequate prevention as well if a narrow enough rule can be defined that blocks the delivery of a particular attack payload. The main issue is that, today's firewall as we know it, does not offer the granularity to differentiate a normal instance of application session from one that is delivering the attack. From this perspective, prevention is a natural new capability available from newer IDS technologies. Depending on the deployment environments, IDS as we know it - monitoring only, will continue to play an important role in implementing security policies. With inline blocking capability (IPS as interpreted in this context), we now have a much more effective policy enforcement tool. By the same reasoning, customers in general will be better off if they do a little more due diligence - to see beyond the acronyms. So it's OK that marketing has forced IPS upon us without a clear definition. If you ask question and assess exactly how particular attack conditions are detected, what actions can be taken - manual or automatic, what really happens when a particular action is taken, etc., you are in a better position to make right decisions for your needs. Have a great new year! Fengmin -- Fengmin Gong, D.Sc. Chief Scientist McAfee Network Security Network Associates fengmin_gong () nai com 408-346-3237 -----Original Message----- From: George Capehart [mailto:gwc () acm org] Sent: Friday, January 02, 2004 7:57 AM To: Teicher, Mark (Mark); Gary Flynn Cc: focus-ids () securityfocus com Subject: Re: True definition of Intrusion Prevention On Friday 02 January 2004 09:41 am, Teicher, Mark (Mark) wrote:
<comments within>
<snip>
<Yes, that was the point, that marketing type people have blinded me with their definition, that I am completely confused and dumbfounded>
*grin* Well, then, I guess that disqualifies you from being a Gartner-reading pointy-haired manager . . . ;-> <snip>
<Prevention, my mother always told me always use "protection", but to this day, I am not quite sure what she meant>\
Heh. My dad used to tell me the same thing . . . but he made *really* sure that I knew what he meant. *wince* <snip>
<The term "Intrusion Prevention" isn't clearly defined, as you have observed, but "Intrusion Blocking" doesn't ring the ears like the marketing folks what you to do"
Ah, yes! *Now* I'm beginning to understand . . .
Don't get me wrong, I don't have a problem with "intrusion blocking" if it is successful . . . that is, if the attack is detected in time and the appropriate "blocking mechanisms" are available. I'd just rather call a duck a duck . . . ;-) I think it is possible to build an "intrusion blocking device." Intrusion prevention is a process. (Apologies to Bruce Schneier ;-) ) <"Intrusion Prevention is a process??" What kind of blocking mechanisms are you referring to ?? I have never met a duck who dabbles in information security, I have heard of a cat who swipes at their owner when they program insecure code :)>
What I really had in mind when I said that was that, to me at least, if there really could be such a thing as Intrusion Prevention (TM), that sort of implies staying ahead of the attacker. That is a process. One of the tools the process could/would use is "intrusion blocking." Another thing the process would/could do is design and build systems that don't have weaknesses that could be exploited in intrusion attacks. Another is to neutralize the attackers before they attack. *All* of this, though is a process. Preventing an intrusion by blocking implies understanding the vulnerabilities of the system, the corresponding attack vectors and putting layers of defense in place that will either block outright or "defang" the attack. But the world isn't static, new vulnerabilities are exposed and new attacks are concocted daily. Staying on top of them takes constant effort and implementing defenses and installing patches is an ongoing process. This is why I feel that Intrusion Prevention (TM) is a process . . . <snip>
<what distinction?? The marketing folks created a term that no one in
the industry understands. Blocking is often referring to as TCP Shunning, but since this the New Year's day, why not start the year off without falling off the soapbox :)>
*snicker* *snicker* *guffaw* *guffaw* /g BTW, a happy and prosperous New Year to all. ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ --- --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- RE: True definition of Intrusion Prevention, (continued)
- RE: True definition of Intrusion Prevention Teicher, Mark (Mark) (Jan 02)
- Re: True definition of Intrusion Prevention George Capehart (Jan 02)
- RE: True definition of Intrusion Prevention Brian Taylor (Jan 05)
- Re: True definition of Intrusion Prevention Gary Flynn (Jan 05)
- Re: True definition of Intrusion Prevention George Capehart (Jan 02)
- RE: True definition of Intrusion Prevention Teicher, Mark (Mark) (Jan 05)
- RE: True definition of Intrusion Prevention Bohling James CONT JBC (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 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)
- RE: True definition of Intrusion Prevention Teicher, Mark (Mark) (Jan 02)