RE: VA/IDS Integration (Was: RE: re[2]: Intrusion Risk Assessment)

From: David J. Meltzer (djm@intrusec.com)
Date: 01/10/03

  • Next message: Talisker: "Re: IDS Stealth Mode" 
    From: "David J. Meltzer" <djm@intrusec.com>
To: <focus-ids@securityfocus.com>
Date: Fri, 10 Jan 2003 10:53:55 -0500

    Good list. Also other interesting tidbits to note:

    - Much of the bleeding edge functionality deployed comes from
    integration work done by the security pros and not from the
    off-the-shelf software; the scanners out there today widely vary in how
    easy a motivated consultant can add these kind of tie-ins. E.g., NetIQ
    Security Analyzer does a great job with comprehensive XML support in
    making doing this kind of integration a breeze whereas some other
    scanners make you deal with unformatted log files or undocumented
    databases (I'm not endorsing or denigrating any of these products as a
    whole, just this is a nice feature others would be well-served to
    emulate).

    - ISS Internet Scanner has a feature "ActiveAlert" that will directly
    send high-priority vulnerabilities directly to their RealSecure console
    as an alert.

    Also worth noting is that while most of the solutions out today work at
    the correlation level (taking output from VA and using it to hone-in on
    IDS results), there is also a lot of potential value in building the
    relationships between these products at the engine-level. Some of the
    areas people are working on yet haven't found the way into most VA or
    IDS solutions yet:

    - Actively launching scans to validate vulnerabilities (technically
    easy, though it has a host of potential security, dos, and network
    performance problems that have led most vendors to stick with the easier
    correlation solution for now)

    - Inspecting traffic from hosts/services in the IDS for vulnerability
    assessment (you touched on this with banners, though from an integration
    perspective admins often use IDS today to identify 'policy violation'
    vulnerabilities and you can dig much deeper into watching the actual
    activity of a service to identify its vulnerabilities).

    - Target-based IDS (TIDS) where the IDS is actively reconfigured to
    monitor and prioritize for exploitation of actual vulnerabilities based
    on vulnerability assessment data. (see
    http://lists.insecure.org/lists/ids/2000/Jul/0119.html).

    - Using network change detection, from active probes (e.g. Tripwire for
    Network Devices) and/or passive monitoring (e.g. carefully crafted IDS
    policies or flow-based IDS, also Securify might fall in here) to detect
    changes that might fall into the 'potential vulnerability' category.

    - VDS (vulnerability detection systems) that operate in the same
    continuously monitoring manner as an IDS but are monitoring for
    vulnerabilities and not intrusions, and by nature have a look and feel
    that is much more IDS than scanner.

    -Dave

    -------------------
    David J. Meltzer
    djm@intrusec.com
    CTO, Intrusec, Inc.

    -----Original Message-----
    From: Ron Gula [mailto:rgula@tenablesecurity.com]
    Sent: Wednesday, January 08, 2003 11:34 PM
    To: focus-ids@securityfocus.com
    Subject: re[2]: Intrusion Risk Assessment

    There are several systems available out there where the relationship
    between vulnerability
    assessment (VA) and Intrusion detection/prevention is leveraged.

    ** ISS Site Protector can fuse ISS Scanner and ISS Real Secure
    information
    together such that
    you can ignore events from ISS RealSecure that you are not vulnerable
    to.

    ** Several NIDS consider service banners for some of their attack
    checks.
    NFR and Intruvert
    do this where possible. Many of the NIDS (like Snort, Dragon and ISS)
    have
    signatures to
    look for specific vulnerabilities as well.

    ** Our Lightning Console correlates Nessus vulnerabilities with ISS,
    Snort,
    Dragon and Bro
    alerts such that end users only get alerts when their systems have a
    correlation of a known IDS
    event and a vulnerability. (Sorry for the plug, but felt it was
    relevant)

    ** nCircle has an appliance that does VA/IDS correlation as well.

    ** Cisco recently acquired a company named Psionic which had a product
    that
    looked at logs
    from ISS and Netranger and then quickly verify that the targeted systems

    were indeed vulnerable

    There are probably more coming ...

    (apologies to any vendor that I either forgot or misrepresented)

    When I was involved with the Dragon IDS, I did not like any of the
    scoring
    systems that were
    out there. I've seen a lot, and each is good for a specific environment.

    The two big problems
    were setting up a scoring system for a given environment and getting rid
    of
    creeping false
    positives. Because of this, I was really interested in writing
    signatures
    that looked for evidence
    of a compromise or a successful attack. My thought was that you either
    had
    an attack or you
    did not, because there was to much grey area in between. Integrating
    vulnerabilities together
    with intrusion data is the first step.

    Ron Gula, CTO
    Tenable Network Security
    http:\\www.tenablesecurity.com

    At 04:52 PM 1/8/2003 +0000, Richard Bennison wrote:
    > > The problem with this is, define "damage." IDS systems are not
    > > aware of
    >the nature of what they defend. An IIS exploit might be utterly
    >useless against an apache web server, but the IDS is not intrinically
    >aware of which servers are apache and which are IIS. Add to that the
    >fact that such severity levels as "minor damage" or "minimal access to
    >recover," are dependent upon the information stored on a machine (which

    >no current IDS could ever be cognizant of) as well as the role of that
    >machine.
    > <
    >
    >Accounting for the string above, this is where the relationship between
    >vulnerability assessment (VA) and Intrusion detection/prevention (IDP)
    >becomes key. If a NIDS or HIDS is aware of the nature of the system(s)
    it
    >is protecting then it can respond relative to the liability of the
    system
    >to the attack.
    >
    >Apologies if this is answering the incorrect string....
    >
    >It is untrue that IDP cannot be cognizant of the systems protected, as
    >although you may not be able to respond relative to the box type, you
    can
    >respond based on patch liability or services running on the box i.e.
    IIS
    >attacks on Apache, if the IDP knows that the box is not running IIS (or
    is
    >running IIS patched) why would it need to block/report the attack. As
    such
    >if you impliment a VA/IDP interaction that scans systems and primes IDP
    to
    >react appropriately then a score may be applied to each attack per
    system.
    >There is a system out there that does this, let me know if you want
    more
    >details.
    >
    >Rich

    Relevant Pages