Re: NIPS Vendors explicit answer

From: Frank Knobbe (frank_at_knobbe.us)
Date: 04/26/04

  • Next message: Tiago Filipe Dias: "RE: Logs correlation (again)"
    To: focus-ids@securityfocus.com
    Date: Mon, 26 Apr 2004 16:45:59 -0500
    
    
    

    Greetings,

    I'm gonna resist to quote a lot of what Vik said (mainly product
    description) and cut to the chase. I do want to highlight this quote:

    On Fri, 2004-04-23 at 16:36, Vikram Phatak wrote:
    > As with firewalls, we believe IPS needs to be more black and white
    > regarding the approach taken. While much of the work being done
    > regarding anomalous behavior is cool, it is not practical unless it
    > can be used in the "real world" to prevent attacks. Believing that
    > traffic is harmful and knowing it is harmful are two different things.

    If you confine your thinking to statistical anomaly detection, then this
    may be correct. However, behavioral anomalies can be safely detected and
    used to prevent attacks. After all, you know how your network is
    supposed to act and can (by cleverly crafting custom rules) detect any
    "fishy" activity that should be prevented (or never happen in the first
    place).

    ipAngel places a great deal of emphasis on correlation of
    vulnerabilities to IDS alerts. While I wish you well in this endeavor, I
    do question the approach. I'm not harping on ipAngel in particular since
    the same applies to other vendors as well. It remains to be seen how
    much value that approach actually adds to intrusion Detection.

    In my opinion, you are restraining your IDS rules to certain
    vulnerabilities for certain systems. This is okay for reducing false
    positive, but imho it should not be a driving factor when developing
    your IDS rules. After all, if you know what your are vulnerable to, why
    not act and remedy the vulnerability? If you know what set of possible
    vulnerabilities might apply to you (for example, running IIS), then
    sure, use that info to tune the IDS and reduce FP's. But don't just
    focus on those vulnerabilities.

    IDSes are Intrusion Detection Systems. Why do we need to detect
    something that we know exists? In my opinion we should focus our efforts
    on detecting the *unknown* events, not the known ones. I argue that you
    are looking the wrong way :)
    Statistical anomaly detection is one attempt to do that (and I agree, it
    may not be the most foolproof method, but it does provides value as an
    added layer).

    Another method of detecting these unknown events is that of (what I
    call) descriptive behavioral anomaly detection. Using this approach you
    first describe traffic patterns that are normal and expected. You then
    get alerted when abnormal traffic patterns are detected.

    The simplest example I can condense this to is a single web server. Why
    let the IDS run a VA scan to determine of it's patched or not instead of
    you applying the patch? While it's fine to determine the system type so
    that IDS rules can be tuned, beyond that I don't see much added value.
    However, behavioral anomaly detection will. You would expect only
    incoming web requests to that web server. If you define that traffic
    patterns such that you will be alerted on other traffic, for example the
    web server establishing an outbound FTP session or tunnel or shell, you
    can safely detect this event and give your IDS much more value.

    At Praemunio, we do Intrusion Prevention differently than most other
    shops. I'm not gonna toot my horn here, but suffice to say that we use
    the behavioral approach combined with Intrusion Prevention, and I can
    tell you that it is working extremely well.

    I believe there is a market for vendors (like Sourcefire) to come up
    with tools to ease the pain in identifying your network and subsequently
    crafting customized rules for it (if that is indeed what Sourcefire's
    RNA does... Marty, please elaborate if I'm off track here). Instead of
    focusing on vulnerabilities, we should focus on devices/assets, which
    traffic flows are normal and which are not, and engage the IDS with
    knowledge of the good, known behavior (and have it alert on the bad)
    instead of focusing on bad behavior (and ignoring the good).

    Regards,
    Frank

    
    



  • Next message: Tiago Filipe Dias: "RE: Logs correlation (again)"

    Relevant Pages

    • Re: NIPS Vendors explicit answer
      ... >If you confine your thinking to statistical anomaly detection, ... Regarding correlating VA with IDS - I agree with you regarding the ... which includes attacks that are irrelavent from an IPS perspective (like ... >vulnerabilities for certain systems. ...
      (Focus-IDS)
    • Re: anomaly vs signature
      ... which combines signature and anomaly detection: ... Signature Detection and Intrusion Anomaly Detection. ... Sent from the IDS forum at Nabble.com. ...
      (Focus-IDS)
    • anomaly vs signature
      ... Recently I was given a task to survey the relative success of Intrusion ... Signature Detection and Intrusion Anomaly Detection. ... Sent from the IDS forum at Nabble.com. ...
      (Focus-IDS)
    • RE: Changes in IDS Companies?
      ... It does intrusion detection with alerting and pattern matching ... IDS is down...but at least your network isn't, ... ::: mode being rolled into Snort) are both good technologies ...
      (Focus-IDS)
    • RE: Specification-based Anomaly Detection
      ... Hi Stefano & Toby, ... I feel that the mind set of the discussion was about such applications, ... would not be much different than a network IDS. ... Does this make intrusion detection in web applications deferent? ...
      (Focus-IDS)