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: