RE: True definition of Intrusion Prevention
Date: 01/03/04

  • Next message: "RE: True definition of Intrusion Prevention"
    Date: Fri, 2 Jan 2004 18:34:19 -0800
    To: <>, <>, <>


    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.


    -----Original Message-----
    From: Teicher, Mark (Mark) []
    Sent: Friday, January 02, 2004 4:43 PM
    To: Gong, Fengmin;;
    Subject: RE: True definition of Intrusion Prevention


    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.


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

    -----Original Message-----
    From: []
    Sent: Friday, January 02, 2004 5:29 PM
    To:; Teicher, Mark (Mark);
    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 Gong, D.Sc.
    Chief Scientist
    McAfee Network Security
    Network Associates
    -----Original Message-----
    From: George Capehart [] 
    Sent: Friday, January 02, 2004 7:57 AM
    To: Teicher, Mark (Mark); Gary Flynn
    Subject: Re: True definition of Intrusion Prevention
    On Friday 02 January 2004 09:41 am, Teicher, Mark (Mark) wrote:
    > <comments within>
    > <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 . . .  ;->
    > <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*
    > <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 . . .
    > <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*
    BTW, a happy and prosperous New Year to all.

  • Next message: "RE: True definition of Intrusion Prevention"

    Relevant Pages

    • RE: True definition of Intrusion Prevention
      ... It detected lots of attacks that were more or less false positives due ... True definition of Intrusion Prevention ... detection with real-time blocking. ...
    • Re: Alarming (was protocol analysis)
      ... the concept of Intrusion Prevention ... does not lie soley on the foundation of attack recognition. ... sublte patterns that from a linear viewpoint should not have any direct connection with ...
    • Re: Another comment on how much Europeans love America
      ... In response to the terrorist attacks of 9/11, he formed a Homeland ... prevention of terrorist attacks. ...
    • Re: IDS testing methodologies
      ... or of attempted internal attacks. ... in prevention instead of spreading them across prevention, ... Admittedly I believe he's now selling detection and ... response services, but he has a very good point. ...
    • Windows Attack
      ... available on Microsoft web-site for the prevention of ... attacks through the window enviroment. ...