RE: True definition of Intrusion Prevention

[<Fengmin_Gong () NAI com>]

Mark,

Thanks for the feedback.  You are absolutely correct that getting the
prevention system tuned to the particular network it's deployed is a
real critical factor.  Today what you have on the one hand, is some
capability for correlating the host and vulnerability identification
with IDS alert, such those from Tenable or RNA; on the other hand, you
have system with inline blocking capability like I1200/2600/4000.  What
you would ideally want is to have these capability integrated in one
system.  The language underlying Intrushield does recognize things like
applicable software packages, versions, or protocols for any given
vulnerability.  But there is currently no ready interface for taking the
vulnerability scanner info to customize the policy for your environment
automatically.  We are fully aware of such needs and working towards
such capability.  So, that's why currently serious prevention users are
expected to deploy the solution in inline but in monitoring mode (IDS)
initially, to account for environmental behaviors, and to tune out
false-positive prone events before transition to enable blocking.

With no intention to start a "what's anomaly detection" debate, let me
add a few words related to dealing with zero-day exploits.  Let's
consider only buffer overflow kind of attacks for a moment, considering
that these are still by far the most dangerous ones today. If a
vulnerability is known, we can write a very reliable set of checks (note
that I am avoiding using signature or anomaly because they are not
always as clearly understood as people like; the checks I refer to can
be a combination of multiple string matches, length check of very
specific fields/subfields, and scan for generic shellcode segments) to
detect all variants of the exploit against this vulnerability.

So what can we do to deal with potential zero-day exploits?  We all know
that one way to catch potential buffer overflow is using length checks.
Equipped with stream reassembly and protocol parsing, we can define
length checks for a lot of fields even though there is no reported
vulnerability. However, it's very challenging to get some of these
thresholds right especially when there are multiple implementations that
can interpret these fields, and the usage varies from environment to
environment.  This kind of capability is useful for environments where
very critical assets are being protected, and skilled security analysts
are available to closely monitor and tune the policies.  You may be
spending 95% of extra effort to obtain 5% of extra coverage, in order to
comfortably consider enabling blocking on these events.

Another way to provide less aggressive coverage for zero-day exploit but
offering more reliable detection is through detection of shellcode in
specific application fields. Here we are not talking about some simple
noop sequence match or other opcode match, rather a fairly comprehensive
shellcode profile match. This detection has been found to be very
reliable to warrant blocking without much concern.  This event is also
sufficiently malicious across all deployment environments.  Of course,
some buffer overflow without shellcode may slip through to cause DoS on
the target, but that is the tradeoff the user needs to make.

These capabilities are indeed very powerful, and takes some effort to
utilize them fully. We are constantly exploring ways to make the
configuration of these capabilities more flexible so that users can get
the most benefit with less tuning effort.  Please feel free to send all
suggestions to me directly so that we do not take up other folks'
bandwidth on the list.

Regards,
Fengmin

-----Original Message-----
From: Teicher, Mark (Mark) [mailto:teicher () avaya com] 
Sent: Friday, January 02, 2004 4:43 PM
To: Gong, Fengmin; gwc () acm org; flynngn () jmu edu
Cc: focus-ids () securityfocus com
Subject: RE: True definition of Intrusion Prevention


Fengmin,

Thank you for your reply.  The real teeth behind any Intrusion
Prevention system is for the system to understand the particular network
it is deployed in.  As I just completed a very thorough product
evaluation of the I-2600 appliance in a particular network environment.
It detected lots of attacks that were more or less false positives due
to the nature of the network traffic generated.  Remediation steps will
vary enterprise to enterprise. I found that one can sandbox attacks to
see how the attacks operate instead of out and out denying the traffic.
There has not been one IPS available that really does a good job on zero
day exploits.  Although zero day exploits are very hard to predict
unless one is doing throwing some processor power into the protocol
dis-assembly re-assembly.  Another point to illustrate is that most IPS
systems today do not have true IPS type attacks, except for a few
modified IDS signatures with TCP shunning abilities. Classifications of
IPS signatures can also be overwhelming. Categorizations and granularity
becomes an exercise in futility.  Bulk Editing of learned actions is
interesting, but not intuitive..

/hope that confuses the issue more.

/cheers

P.S. Still waiting for Al H to reply.. :)
/mark

-----Original Message-----
From: Fengmin_Gong () NAI com [mailto:Fengmin_Gong () NAI com] 
Sent: Friday, January 02, 2004 5:29 PM
To: gwc () acm org; Teicher, Mark (Mark); flynngn () jmu edu
Cc: focus-ids () securityfocus com
Subject: RE: True definition of Intrusion Prevention

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.


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




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