IDS: RE: True definition of Intrusion Prevention

["Teicher, Mark (Mark)" <teicher () avaya com>]

-----Original Message-----
From: George Capehart [mailto:gwc () acm org] 
Sent: Friday, January 02, 2004 8: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:
<snip>


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>
OK,  The process of correlating network based attacks is ultimately
flawed, since a MSP is dependent on the underlying technology and the
skill set they employ to properly categorize an "intrusion" and then
have defined processes and procedures in place to properly respond.
IDS/IPS technology can differentiate between known and unknown.  The
"unknown" or "leftover" then has to be hand analyzed by skilled people
or not so-skilled people in order to feed that knowledge back into the
underlying technology. 

It becomes the "feeding the machine" type thing, until one arrives at a
ftp >300 buffer overflow, and it turns out to be a Kerberos login
authentication packet.  Until the underlying technology can properly
analyze packets from various sources at reasonable speeds, categorize
them into the different buckets, exercise a quick little binary tree to
either "PERMIT" or "DENY" and then have some sort of quick manual
override.  The Intrusion Prevention (TM) process has a long way to go.  

P.S. Someday, SecurityFocus might even post one of my articles, they get
some interesting stories from Mark Rasch all the time..:)



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