IDS mailing list archives
Re: Dream IDS was Q on resources needed to manage IDSes
From: "Andy Cuff [Talisker]" <lists () securitywizardry com>
Date: Mon, 15 Dec 2003 22:19:54 -0000
Hi Jimi, Most of what you require has been available from various commercial IDS for some time, but it requires you to iron out the false positive manually
. I'd like to see an AI engine I can train with a rule base that I can modify.
AI can be prone to problems through training it to ignore bad traffic gradually. Having said that SHADOW is pretty good. Better (IMHO) is using plenty of IF ELSE etc like statements within a protocol decode signature. I came across an IDS last week that allows the customer to write protocol decoders with trivial ease, I was completely blown away! I signed an NDA but I'll ask if I can discuss it on list ASAP. (I needed a cold shower!) I'm the worlds worst coder and even I could figure it out ;o)
I want multiple sensors I can park all over my network and tie to a single console.
no problem most will do this with ease. BUT check out their scaleability how big does the back end need to be to cope with the quantity of sensors you're talking about. If I remember correctly ManHunt does this quite well by distributing the number crunching across the sensors.
I want to be able to feed it a network diagram so that it "knows" what is authorized to live where. It will know what the OS is supposed to be and what the applications should be. That should tell it what kind of traffic to expect to and from every thing on the network.
Perhaps not a diagram but you can do this with a combination of tuning and fingerprinting, this will also overcome the problem you'll find with the diagram idea of the information becoming dated overtime.
I also want it to alarm if one of my Windows file servers starts suddenly serving port 80 traffic. I want it to alarm if it starts being a proxy or a router or something else that it's not supposed to be.
This can be achieved through tuning signatures to the hosts, rather than what you are suggesting I'd suggest reversing it to report on anything serving 80 traffic except webservers etc.
If I track something down and find out that it's bogus (for example the L3trevier pings on a Windows network) because its actually legitimate traffic, I should be able to tell it not to process that any more because its actually my Windows hosts talking to the domain controllers. Once I tell it that it's normal Windows traffic, it should still alarm if it sees this coming from something that's NOT a Windows box or going to something that's not a domain controller.
normal false positive tuning
I want to be able to feed my SuperWidget 1000A a new rule for the latest virus traffic signature/root exploit/IIS bug/root kit/whatever and having it adjust my firewall rules and router ACL's to block that traffic (and other sufficiently "bad" traffic) when it sees it. I only want to be bothered when it finds something it doesn't understand.
Rather than tune the firewall why not use an IPS and block such traffic there, alternatively and not quite so effective use the various automated response features of your IDS.
When someone makes something that will do these things, I'll buy it. Until then, I'm sticking to Snort/ACID/MySQL for IDS and I'll just be running myself and my staff ragged while we try to keep up with the alerts and keep tweaking the rules.
Try a few commercial IDS/IPS you'll be pleasantly surprised, pit it against your Snort and run a comparison. Though I find Snort pretty good these days, it has a good breadth of signatures if not the depth of individual signatures that I'd like to see, it complements the commercial offerings very well at a fraction of the purchase price though some of this is offset in the cost of maintaining it.. take care -andy Talisker Security Tools Directory http://www.securitywizardry.com
Jimi Teicher, Mark (Mark) wrote:Anton, I disagree. If the event correlation engine is designed correctly. Human analysts should be rarely introduced into the equation of # of humans/ #of sensors. It is a big "IF". Most MSPs didn't understand that designing event correlation engines takes time and money. If the MSP would have focused more on event correlation then building nice SOC's to impress their potential customer base, this discussion would be irrelevant. Very few MSP have perfected their event correlation engine in a scaleable sense. Those who were almost there have been gobbled by much larger companies who just bought into the market or just wanted to eliminate the "barbarians at the gate" Compared to the number of MSP's in the market place over 5 years ago, compared to the number of MSP's left, it is fair to say, either a) Were acquired b) Massive layoffs/management re-organization c) Influenced a couple of analyst panels stating the have better technology, market share and beating their competition d) Have some guy with a pony tail as their CTO writing books and being quoted when a major security related news article is posted to the Internet and get a couple of trial customer e) Out of money Some of the options may apply to the current market.. /mark -----Original Message----- From: Anton A. Chuvakin [mailto:anton () chuvakin org] Sent: Friday, December 05, 2003 1:07 PM To: focus-ids () securityfocus com Subject: Re: Question on resources needed to manage IDSes1-5 IDS sensors - 1 Analyst 5-15 IDS sensors -2 Analystsbeing. It would be generous to assume a human could qualify a reasonably complex alert in 30 seconds. After that, it's simply aThe above also implies a certain usage scenario. One "complex alert in 30 seconds" implies that the analyst just sits there and stares at the console where alerts pop up - which might be neither the most common nor the most effective way. The tools available to analysts would also matter, namely, how much time it will take to collect the context info and to make a decision. I suspect the specific IDS usage details will heavilly affect the "analyst to sensor" ratios.--------------------------------------------------------------------------
-
--------------------------------------------------------------------------
-
--------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- Re: Question on resources needed to manage IDSes, (continued)
- Re: Question on resources needed to manage IDSes simonis (Dec 02)
- Re: Question on resources needed to manage IDSes Jeff Nathan (Dec 02)
- Re: Question on resources needed to manage IDSes Anton A. Chuvakin (Dec 09)
- Re: Question on resources needed to manage IDSes Jeff Nathan (Dec 10)
- Re: Question on resources needed to manage IDSes Jeff Nathan (Dec 02)
- Re: Question on resources needed to manage IDSes simonis (Dec 02)
- Re: Question on resources needed to manage IDSes Terence Runge (Dec 02)
- RE: Question on resources needed to manage IDSes Kohlenberg, Toby (Dec 03)
- RE: Question on resources needed to manage IDSes Teicher, Mark (Mark) (Dec 03)
- RE: Question on resources needed to manage IDSes Morse, Greg (Dec 03)
- RE: Question on resources needed to manage IDSes Teicher, Mark (Mark) (Dec 10)
- Re: Question on resources needed to manage IDSes Jimi Thompson (Dec 15)
- Re: Dream IDS was Q on resources needed to manage IDSes Andy Cuff [Talisker] (Dec 16)
- Re: Question on resources needed to manage IDSes Jimi Thompson (Dec 15)
- RE: Question on resources needed to manage IDSes Mike Disley (Dec 10)