On Wednesday 19 March 2008 14:05:42 Valdis.Kletnieks(a)vt.edu wrote:
On Wed, 19 Mar 2008 13:02:48 EDT, Steve Grubb said:
> files. In order for the IDS system to be able to distinguish an open of a
> watched file from an open of a *special* watched file that an alert
> should be sent for, I'd like to propose a standard way of alerting the
> IDS that this record needs additional scrutiny.
Why do we need special handling for something the IDS should be able to do
for itself?
Something has to tell the IDS what to do for these 3 particular detections. It
could come from a configuration file that it reads, or it could come from the
event stream that it reads. Its just a matter of *where* the instructions
come from.
If your IDS system doesn't already have a copy of the list of
"special" watched files, you have *bigger* problems.
Not really, just think about the advantages of this approach.
o You do not need to express host:file relationships if you are checking
aggregate logs
o You always have a matching audit rule to make sure you get the data you need
o The event when recorded to disk has the meaning associated with it in case
you wonder why something didn't get classified the way you thought it should
o This technique is higher performance since you do not need iterate across a
list of all files for each incoming event.
o If the target file has a hardlink that is manipulated, the IDS won't be
fooled because a different path showed up in the event stream. (This might
even come into play for mount tricks that alter paths.)
These are the easy ones that I can think up easily. While we are at it, the
disadvantages to using the IDS configuration file approach:
o The config file will become a mess when you get to this one entry that
contains all file names one after another. Or you will have 2 config files
one for the options and one for the files. You will of course need 2 more
files for the other 2 detections, so now you have 4 config files to setup.
o No guarantee that any audit rules exist to give you the events you need.
o Lower performance
o Uses more system memory
o Susceptible to path name tricks
o Code will be far more complicated and harder to read or understand due to
size.
o You have to be very careful to keep aggregate server rules in sync with
remote system.
-Steve