Re: future of IDS

[Dominique Brezinski <dom_brezinski () securecomputing com>]

At 09:38 AM 10/19/98 -0400, Bennett Todd wrote:
> switch carries more traffic than can be logged or analyzed.
>
> Whereas seach individual host does not carry so much, so the thing to do
is to
> distribute the first level of analysis out, so that only a condensed stream
> needs to be brought back to the central management and analysis station.
>
> -Bennett

It is quite possible to analyze traffic on a switch, as a matter of fact
the switch is already analyzing every frame that comes through. Logging all
the traffic that comes through a switch is an entirely different story
though. That is why the switch would actually become a data *reduction*
point for the IDS. Of course, any analysis and data reduction done buy the
switch *may* introduce latency depending on the switch architecture. It is
quite possible to develop a switch that is capable of doing first level ID
analysis and data reduction without introducing latency (think about
something like a dedicated ID processor running in parallel with the
switching processor). The frames take two paths as they enter the switch:
the switching path and the ID path. The switching path gets the frame to
its destination port, well the ID path analyzes the frame and either
triggers an event, sends the frame to some other portion of the IDS, or
drops the frame because it is not significant.

If one wants the switch to be able to drop frames based on ID analysis,
then the ID analysis probably needs to be done inline with the switching
logic. This will cause an increase in latency. Look at the ODS switches
with ISS RealSecure on them. You have the option of running the IDS inline
with the switching logic so the switch can respond to attacks or just have
the switch duplicate frames to the RealSecure engine running on the general
purpose processor on the switch. This stuff is not magic. If switch
manufactures get serious about bringing ID into the network infrastructure,
you will see switches designed to support this kind of application.

Host and network based ID both have strong and weak points with today's
hardware and operating systems. Current commercial operating systems have
inadequate audit trails for ID. An example is that if you enable process
auditing on NT, you do not get a record of the arguments passed to the
process (command line arguments etc.). Sun's BSM is way better, but it is
not entirely there either. IDS developers have to hack shims into the
auditing systems and the OS to get the level of detail they need. This
means less system stability, more places to introduce errors in the IDS,
and longer development time. If commercial OS vendors worked with IDS
developers and researchers to enhance the auditing to the level and format
needed to do good ID and they all supported APIs to get audit records as
events instead of having read the records out of log files, we could have
great host based IDS. Until then, they will be mediocre and have limited ID
capabilities. The same goes for network hardware (and the software that
runs on it) vendors. When they get the clue and start developing switches
and routers that either generate the correct auditing information or
support running IDS code on them, we will get good network IDS.

This is all just one part of ID though. There are other differences in host
and network based ID, but the best IDS will undoubtedly use at least a bit
of both.  


Dominique Brezinski CISSP                   (612)628-5378
Secure Computing        http://www.securecomputing.com