Re: Announcement: Alert Verification for Snort

From: Sam f. Stover (
Date: 10/24/03

  • Next message: Frank Knobbe: "Re: Announcement: Alert Verification for Snort"
    Date: Fri, 24 Oct 2003 11:40:46 -0400
    To: "Andrew Hall" <>

    On Thursday, October 23, 2003, at 09:19 PM, Andrew Hall wrote:

    > I think what you are really after is to be found in a good security
    > information management (SIM) tool.

    No - I wasn't talking about correlating events from disparate sources.
      I'm looking for an intelligent IDS that will integrate into a SIM,
    sure. But my points were specifically targeted towards an IDS that is
    smarter today than the IDS of 10 or even 5 years ago.

    > An IDS is good at what it does ... ie in raw detection of "events" ...
    > by what ever means that is (string matching, heuristics, protocol
    > anomaly etc)

    No - an IDS *sensor* is good at what you describe. However, I'm
    talking about the whole Intrusion Detection SYSTEM, which needs to do
    much more than just detect events. I'm guessing that this sort of
    thing is what Marty eluded to when he said that Sourcefire was working
    on developing the means to do this.

    > but as mentioned by others on the list the context is
    > critical to determine if the event is really an "incident". And again,
    > without context the priority of an incident can not be determined.

    This is precisely my point. I need to be able to configure my IDS so
    that events (which will eventually make it to the SIM) have been
    categorized and prioritized in a way that helps me focus on important

    > <snip>

    > Finally, there is the good old debate of why an IDS is even being
    > deployed in a network. I argue that an IDS has three main purposes all
    > of which are essential;
    > - Real time event notification
    > - Trending analysis
    > - Forensics
    > <snip>

    I don't really disagree with your 3 items (except maybe the "real time"
    aspect of the first one).

    > I argue that the only way to get this flexibility is to use a SIM tool
    > ... something which can store large amounts of raw data / logs, yet
    > present a highly filtered and highly correlated view of all the data in
    > your network.

    I don't think it's very responsible of an IDS vendor to generate
    millions of alerts and then pass the responsibility for prioritizing
    those alerts to a third party SIM tool. It sounds like this is what
    you are suggesting? Or should IDS vendors become high-end SIM
    developers as well?

    I think some middle ground can be found which allows users to
    prioritize without having to buy a SIM...



  • Next message: Frank Knobbe: "Re: Announcement: Alert Verification for Snort"

    Relevant Pages

    • RE: on NIDS/NIPS tuning
      ... SIM vendor that has a correlation engine that can handle a fraction of the ... and respond to all of the alerts. ... >Where to tune is a very good question and not easily answered. ... >>default we tune the IDS. ...
    • RE: IDS event filtering
      ... AFAIK this is the best list on securityfocus for SIM. ... and incident handling lists appear to be moribund. ... Subject: IDS event filtering ... > CORE IMPACT. ...
    • RE: on NIDS/NIPS tuning
      ... Most SIMs should be able to handle serious IDS load if you give ... As for tuning, I never said anything about not tuning, in fact you ... >I am curious to know what SIM product can handle un-tuned IDS ... >attacks from ...
    • RE: [fw-wiz] RE: IDS (was: FW appliance comparison)
      ... word programming and give you the sign of the cross. ... The problem is that the SIM solutions don't know how to pick important ... data out of log files. ... is not really a failure of IDS - it's that the IDS designers made ...
    • RE: on NIDS/NIPS tuning
      ... I'd suggest that IDStuning is still essential. ... Where to tune is a very good question and not easily answered. ... try to tune on the sensor first and on the SIM second. ... If you tune what appears to be noise at the IDS, ...