Re: a novice question. -reply

[rgula () network-defense com (Ron Gula)]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au

> Let's go over this again, using two StrongARM RISC processor with 32 Megs 
> of memory, can handle the disk I/O in milliseconds, so disk thrashing will 
> not be a problem and neither will it have a problem with keeping up the 
> amount of traffic.  If you build a small embedded O/S that is smaller than 
> 1 meg.  The O/S is then optimimzed for the IDS application, no GUI 
> overhead since the GUI console communicates with the sensor via an 
> encrypted channel.  So therefore, the policy is set by the console zapped 
> into the detector, the detector handles the policy pattern matching and 
> then passes what it may think is a problem back to the console on the 
> other channel and do whatever it was setup to do.  The overhead is not on 
> the detectors per se, the Console is architected and programmed correctly, 
> could multi-thread the reporting module with the display therefore 
> eliminating some of the problems in using dynamic filter sets.  This is 
> the type of architecture for an IDS that can scale and handle more than 
> 1000 signatures.

Let's go over this again ... ;) Dragon comes pretty close to this. The 
binary and signatures is less than 200K and it would be much less if
we had dynamically linked binaries instead of statics. The Dragon Sensor
can offload all of the data to a central server. In some cases, we can
make the Dragon Sensors obtain their configs from a central server as
well via SSL. 

> The problem with the some of the current O/Ses that IDS systems rely on 
> operating systems are delivered by those people in Redmond.  The operating 
> system source code alone is riddled with hole people have not even 
> discovered yet.  Why would you trust an IDS system on that type of 
> operating system?  The ideal IDS system would use a freely available O/S 
> that is stripped of the normal crud that is usually packaged with it or 
> roll your own type of O/S ala something similiar to Livingston ComOS. Less 
> than a megabyte and can handle lots of concurrent connections. 

There are all sorts of arguments here. Personally, I like to have an IDS 
that I have the flexibility to drop SSH on if I choose to, or kerberos
or network shell for that matter. If you take everything away then you are
selling an appliance. Appliances do the things they were designed for and
that is it. There is very little chance to go back swap and swap out the web 
server for example with something that uses SSL. The corollary is that an
appliance is more secure, that is until someone can pick out a vulnerability
in the appliance.  

And for knocking NT, you can turn off all of the services on it just like
UNIX. Host based security is still an issue with all UNIX and NT systems.
Most IDS products are deployed such that only 'security guru' people get
to them. 

Ron Gula, CTO
Network Security Wizards