RE: IDS and NMS

["Jim Butterworth" <res0qh1m () verizon net>]

Let me approach my response a little differently...  

I would agree with your commentary if the network in question was a
relatively small network (1 class "C" using 100Mbps speed, less than 250
machines) then I would tend to agree that maybe the volume of traffic
could probably be handled by a single console, operated by a
"super-admin", with a solid understanding of how his/her network
operates [including OSI layer fingerprint, communication tendencies,
application requirements, etc..]  This small scale (not to diminish the
job's importance) job could benefit from the points in your argument;
because it would basically amass the information this person would need,
and place it in one easy to manage place {console}.  Conceptually, I can
see the merit of your position.   Good on you for trying to make the job
of being the Super Geek easier.

If, however, the plan is to implement this sort of solution in a large
scale network (GAN/WAN) then I guess I would remain skeptical to the
usefulness of such a capability.  You stated, "<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.>"  I
guess my view of an IDS would better be described as a means to
recognize and alert on traffic_of_interest.   I think the challenge in
working with any IDS is to be able to recognize normal behavior of your
network and either modify or construct new rules to separate the wheat
from the chaff.  I say this because, ideally, the concept is to tune the
IDS to a point that when it cries "Wolf!", it means it.  So, I set the
IDSes up to suppress reporting of "traffic on the wire" and only report
packets which warrant further analysis.  Keep in mind, at this point,
you are truly doing "detection" and not "prevention".   If the results
of the analysis are such that you should augment the security of your
premise routers, border gateways, tighten access to secure enclaves,
etc...  Than so be it.  To get to the point where only "real" stuff is
reported takes a long time and a great deal of forensic analysis.  How
many Mark 1 Mod 0 sysadmins are versed in this craft?  I would guess
maybe 5%. 

In our IDS implementation, we had thousands of machines, about 2 dozen
of which required unique connectivity outside our home networks for
logistics, administrative, and financial purposes.  We were running 8
class "C"s, ATM connectivity between the servers {try and sniff that?!}
and a few selected desktops, three separate enclaves, 95% DHCP w/5%
static assignments,  4 email servers, 4 web proxies, 6 file servers,
etc......   To consider your idea would, in OUR implementation, mean
that the IDS folks (Myself and the 5 who work for me) would have to
timeshare a machine (NMS segment) with the network technicians, who
themselves hardly ever concern themselves with traffic on the network.
We needed to run our own sensors(8), manage our own rules, collate our
own data, into our own SQL database, and perform our own analysis of
whether the Corporate Security policy was truly being enforced by the
hardware and scripts in place.    

An interesting side note was that we were actually asked by the head
cheese if we could perform some sort of automated traffic analysis
(Maybe something you are trying to get to?) that might demonstrate
trends and be able to shed light on the offset of traffic loading.  I
explained that short of recognizing scanning, or potential infection by
virus/worm, I could not with confidence use the sensors to explain why
packets were getting dropped, or packet latency was increasing, etc.
About the best I could do is just assure them that it was not malicious
activity causing the load on the network.  

In the bottom line, what would be sacrificed or gained by hosting the
NMS & IDS on the same console?  I would tell you that, I would not be
interested in acquiring a capability as you outline, and the
aforementioned reasons are why.  We value security and service equally,
and the personnel performing both do not cross.  Just one man's
opinion...

Thanks, Mr. Bhagat.

R/Jim Butterworth
GCIA



-----Original Message-----
From: Devdas Bhagat [mailto:dvb () users sourceforge net] 
Sent: Tuesday, June 17, 2003 12:57 PM
To: focus-ids () securityfocus com
Subject: Re: IDS and NMS

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


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