Re: IDS and NMS

[Devdas Bhagat <dvb () users sourceforge net>]

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
-------------------------------------------------------------------------------