Re: IDS and NMS

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

On 18/06/03 10:25 -0700, Jim Butterworth wrote:
> Let me approach my response a little differently...  
Replies to the list, please.
 
> 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
Or a larger network appropriately partitioned and staffed.

> 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
I believe that any administrator worth his or her salt should at least
try to understand the network [1]. It may not be possible to do that in a
single day, but some experience with that particular network should give
the admin a general feel for the health of the network.

> 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.
This is *very* often the case.
 
> 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
My typical experience of security problems has tended to be someone
approaching the helpdesk/admin and saying "This application isn't
working today. Could you check it up now?". Not a very desirable
situation, but unhappily a very common one. For such an admin, being
able to quickly check on what is happening would be a boon.
This may or may not be true in all networks, and I would not suggest
that this solution is correct for everybody.

> 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
s/traffic_of_interest/behaviour_of_interest/
I do not restrict IDS to just NIDS. IDS encompasses NIDS, HIDS, data 
trending and traffic pattern matching tools.

Examples:
Oops, that webserver just got something listening on a high port. I
wonder if its normal or a zero day that my IDS couldn't detect?
Why is my mailserver suddenly having a larger volume of outgoing data?
Check, lots of outgoing email. Send the postmaster a heads up. 
Log analysis reveals that the server was being hijacked to send out spam,
oops. 
Not stuff a NIDS will/may detect, yet definitely undesirable traffic.

> 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
I do not want to consider "prevention" at this point. Getting good
detection is hard enough. 

> 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%. 
They need to learn. Like it or not, this is a full time job. While I
respect the people who "also" administer systems because they are the
most technically clued, I will not say that they are necessarily the
people with the skills and/or the time to do this job correctly.

> 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?!}
I don't know a sniffer which handles ATM yet. Shouldn't be too hard to
insert a kernel module to hook into the ATM functions and report from
there though :).

> 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
Not necessarily. All that you would want was the NMS data itself.
What I am proposing is to make additional data available to the network
administrator/security analyst who has to take care of the network.
Having a *tool* to deal with more data /efficiently/ will not hurt.
I consider security a *part* of management. It cannot be separate from
the systems being managed.

> 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.    
However, having *additional* information about system/network behaviour
would definitely not hurt your analysis.
How do you determine if your public webserver is being hit by a
distributed SYN flood attack? Or your mailserver is being hit by a
distributed spam run? I would consider a spam run to be malicious
traffic, and expect to be alerted of it if spam was being accepted.
However, if the server was responding with a 5xx error, I would want it
logged into the not so important category, something for the postmaster
to deal with in the normal course of work, but not a reason for me to
call him/her up and warn of the spam run.

> 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
This could be an additional benefit of integrating the two data sources.
> From my POV, both the network management team, and the security team
need to get a lot of the same data, but focus on it in different ways.
The network admin/system administrator will want to check that their
systems are working within their parameters of operation.
The security personnel will want to observe deviations from normal
behaviour even when systems are operating within the normal parameters.

> 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.  
I would not expect the answer to a "why" from this system. However, a
heads up warning of the network not behaving as expected *will* be
useful and a point to check out.

> 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...
IMHO, both groups of personnel need to be aware of what is going on on
the network, for different reasons.
Making it easier for them to share data and understand the others
position is one good reason to integrate both together.
Providing sufficient data to make analysis faster is another good
reason. Raw data will /not/ be useful, but properly analysed data will
be. The NMS provides one view of the network, the IDS another. Having
both views /will/ help in sorting out issues faster.

Of course, it may not be considered necessary or useful in some
organisations, or not worth the cost in others. This has to be
determined by the organisation in question with a standard cost-benefit
analysis.

Of course, having dealt with a smaller organisation, I personally would
have appreciated something like this that would have let me see my
network status at a quick glance.

At this point, I don't think we are differing in understanding each
others positions, just in the cost/benefit analysis, which would be
specific to each organisation.

Devdas Bhagat

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