RE: True definition of Intrusion Prevention

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

Actually,

It isn't that hard to do, since the technology has improved over the
years.  Network topologies are much easier to product with passive
network scanning.  Taking the information from the network topology, and
building a nice table of the IP, hostnames and operating systems then
becomes an exercise in regular expression parsing. Once the information
is parsed, sorting by o/s, than correlating the o/s information, once
can then sift through the crud of network attacks, discards the one that
don't apply to the particular O/S and just focus on monitoring for
specifics.  It then becomes an exercise is refining the binary tree
algorithms for speed.

If you an MSP lurking the list looking for good ideas, I got lots of
them :)

/m

-----Original Message-----
From: George Capehart [mailto:gwc () acm org] 
Sent: Friday, January 02, 2004 11:08 AM
To: Teicher, Mark (Mark)
Cc: focus-ids () securityfocus com
Subject: Re: True definition of Intrusion Prevention

On Friday 02 January 2004 11:08 am, Teicher, Mark (Mark) wrote:
> -----Original Message-----

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

Yes, I agree.  I'm going to go a bit astray here, and I don't know 
whether it will survive moderation, but here goes:

I guess I'd like to take a step back and re-examine the way we are 
thinking about things and put a slightly different spin on them.  I see 
intrusion detection as a monitoring behavior which may trigger a 
reactive behavior/response.  It is a process that looks for things it 
shouldn't be seeing.  I see Intrusion Prevention (TM) (whatever that 
turns out to be) as a proactive process the goal of which is to 
implement and operate a System which presents an attack surface that 
approaches zero.  The idea is to field a system in which the number of 
real attacks reported by IDSs approaches zero.  There would be much 
more to Intrusion Prevention (TM) than analyzing packets and deciding 
what to do with them.  In this utopian view, the IDS really wouldn't 
have much to do . . .  How one would go about doing this is the hard 
part.  It involves all aspects of the SDLC.  It involves *really* 
knowing the systems in place, what their current vulnerabilities are 
and fixing them or putting them behind several layers of defense.  It 
involves defense in depth.  It involves white-listing.  It is truly a 
Capital-S System-level collection of processes . . .

I probably will not live to see it . . .  ;->

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

Hope I live to see that, though . . . :-)

/g





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