Re: IDS and NMS

From: Devdas Bhagat (dvb_at_users.sourceforge.net)
Date: 06/17/03

  • Next message: Bill Royds: "Re: Rather funny; looks like page defacement to me" 
    Date: Wed, 18 Jun 2003 01:26:46 +0530
To: focus-ids@securityfocus.com

    On 17/06/03 09:48 -0700, Jim Butterworth wrote:
    > I guess you'd have to ask yourself what it was that you were
    > trying to gain by putting an IDS embedded with a NMS. Other than a from
    > a hardware resource perspective, I just don't see any benefit. The
    Ok, let me approach this problem slightly differently.
    Start by designing and installing a network. We secure the network by
    putting in a firewall (for starters).
    Now we want to know if this network is functioning properly.
    So the network admin starts off by putting in simple tools like MRTG.
    Next, a more detailed view of the network is required, so a NMS is
    installed.
    The NMS lets us have access to some aspects of the network, but doesn't
    tell us what is actually going on the wire.
    A simple application like ntop sits well in here.
    On the other hand, we need to watch the firewall as well.
    A log analysing tool is installed/developed.
    We now want finer grained data, so a NIDS is installed and tuned.
    Maybe, for even better security, application layer gateways are installed
    as well. Even more logs to go through and check.

    Now, for a better view (holistic, but this term has been overused by
    marketeers) of the network, the network administrator wants to see what
    traffic is actually flowing on the wire.
    This is where integrating the IDS console into the NMS makes sense. It
    is a single screen for the administrator to view the entire network,
    with extremely fine grained detail.
    Note that I do not claim to integrate the IDS into the NMS, just the
    consoles.

    This reporting console *should* provide network analysis of which
    host/device is using how much traffic, what type of traffic it is, where
    communications are going, is any traffic odd/abnormal, etc.
    A centralised reporting tool can _aid_ an administrator in making some
    decisions.
    This may or may not be feasible for a variety of reasons (the
    administrator has to be skilled in network management and in security as
    well, the volume of data will simply be too much to fit on one screen,
    etc). However, the idea is a useful one, since often enough, the network
    administrator has to double up as the person in charge of security.

    > sniffed traffic on our network was generating a log file size of over a
    > gig an hour in packets, and this was just using header logging, not
    > verbose logging. My opinion is that your IDS solution needs to be
    > separate.
    The IDS solution needs to be separate, but the management console for
    the IDS need not be.

    > When considering Defense in Depth, you should not rely on a
    > single IDS solution. A single NIDS device is not a panacea. A static
    I agree with this. Firewalls and proxies to block attacks, IDS systems
    (HIDS/NIDS/Log analysers/traffic monitors/...) to see that these are
    running properly and to watch for errors, alert administrators and clued
    up users are all part of a good defense in depth policy.

    However, using what tools we have to *correlate* data, find patterns and
    respond to those appropriately is not a bad thing.
    Tools have to make the life of the administrator easier, and having
    multiple tools *can* make life more difficult[1].
    <snip good suggestions>
    For example, the single console could group alerts by host together, so
    that simply asking for information for that host will alert the admin to
    the fact that it tried to connect to some external SMTP server in an
    unauthorised fashion and send mail (virus? misconfigured host? cracked
    system? Open proxy?).

    Grouping related information together helps in getting both the security
    personnel and the network personnel to understand each others problems,
    requirements, baseline network status. Having access to all information
    implies that both sides can coordinate better, rather than ending up
    blaming each other for not seeing problems.

    Devdas Bhagat

    [1] This does not imply a single large tool is always the best solution
    for any given problem. A large, complex tool that tries to do everything
    will probably be bad. What I am proposing is a set of tools reporting
    data via various protocols and yet another tool that understands all
    these protocols (possibly via plugins), and does correlation/data
    grouping/reporting as per actual administrative requirements.

    -------------------------------------------------------------------------------
    Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the
    world's premier technical IT security event! 10 tracks, 15 training sessions,
    1,800 delegates from 30 nations including all of the top experts, from CSO's to
    "underground" security specialists. See for yourself what the buzz is about!
    Early-bird registration ends July 3. This event will sell out. www.blackhat.com
    -------------------------------------------------------------------------------

  • Next message: Bill Royds: "Re: Rather funny; looks like page defacement to me"
    • Quantcast