RE: comparison of NFR vs RealSecure - auto update

[rreybok () lehman com (Reybok, Richard K)]

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
you always need to be careful when you do any "auto-updates". Let's not
forget, symantec released an update for nav about a month ago that blue
screened workstations. That's not a full executable update but it sure as
hell caused a lot of problems. 

When dealing with anything that functions at the kernel level, the chance
for machine failure is real. You have no way of knowing, without seeing the
source, just what kind of an impact a system policy is going to have on the
entire app.

-----Original Message-----
From: Jackie Chan [mailto:blue0ne () igloo org]
Sent: Thursday, March 23, 2000 10:04 AM
To: Guy Bruneau
Cc: C.M. Wong; Mark.Teicher () predictive com; ids () uow edu au;
owner-ids () uow edu au
Subject: Re: IDS: comparison of NFR vs RealSecure - auto update

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
-
Guy, I think you miss the point here.  Auto Update of signatures is not
even close to being a 'patch'.  Your assumption that if the updates fail
that the sensor will be down requires alot of speculation.  Anti-virus
comapnies have been using Auto-Update technology for some time without any
problem.  

The other aspect you miss here is that you assume that an auto update will
automatically update your policy as well. I doubt that any product would
automatically update your policies too.  I mean how the hell do they know
what kind of policy you need on your specific lan segment?  And even if it
let you dynamicaly update policy, it seems obvious to me that it would be
a user configured option.

My .02

blue0ne

> The major fault I can see with auto update is if it is done during "silent
> hours" and no one is there to monitor the update.  If the patch that is
applied
> fails, the system will be down until someones comes in to check the
sensor(s)
> in the morning.  I think I could wait a few hours without those new
signatures
> so I could verify the stability of the vendor recommended patch on the
> sensor(s).
>
> A way of avoiding the detection of the sensor(s) and monitoring station(s)
> would be to download the file to a workstation or server that is not
related to
> the sensors(s) and perform the auto update internally. This could be
> accomplished in a similar fashion as the virus vendors (push-pull model)
are
> presently doing. The new dat file is pushed to the customers' server and
the
> users pull the new dat file. This could be incorporated in the IDS as an
option
> for those who don't want their IDS to connect anywhere on the Internet.
>
> Guy
>
> > Another thing Mark, in most org, there are a lot of lamers security
> > conscious admins people. Even if the new vulnerabilities arrives in CDs,
> > they're not gonna study the exploit in detail... but maybe study what
are
> > the consequences if deployed on their network (like generating huge
false
> > alarms or paging you in the morning etc). But even than, coming into the
> > office at 9 am  to find out you have a full log of false alarms is
better
> > than getting one of your servers compromised and which you have no idea
off
> > (And let's just stick to network IDS, not host IDS or tripwire etc).
> >
> > Maybe I have missed something completely and couldn't catch what's on
your
> > mind Mark. Marcus or any of you gurus out there?
> >
> > Rgrds,
> > Wong.
>
> --
> Guy Bruneau
> Ma page est a/My page at: http://www.penguinpowered.com/~bruneau