Re: comparison of NFR vs RealSecure - auto update -reply

[Mark.Teicher () predictive com (Mark.Teicher () predictive com)]

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
Currently the auto-update feature is not a feature that has been 
incorporated into any of the IDS products yet.  If you look at X-Press 
Update with ISS 6.0.1, one needs to be connected to the Internet for the 
X-Press Update function to work and the particular NT Workstation ISS is 
installed on, the permissions on the directory must be set to Full or the 
X-Press update will fail.

Anti-Virus update also needs a Internet connection for it to be successful 
or a hole poked through a firewall for the update to be successful.

Some versions of Anti-Virus programs actually do update the program and 
the .dat file, so your point is muted, the .dat file updates are the only 
ones that work successfully, although some vendor have released bad 
updates causing the workstation the virus engine is installed on to reboot 
continually, until the update is removed. 

Again, some of the anti-virus programs do update the various anti-virus 
policies a user has customized or deletes them regardless.   This has been 
a ongoing issue with some of the Anti-Virus vendors for quite some time. 
Most of the ISV routines written assume overwrite or check for date stamp 
first.

Some of the recent releases of IDS software require the administrator to 
remove the previous version and install the new version with the new 
vulnerability/check updates.  The after the installation is complete, one 
has to start from scratch again, or import the policy back into the proper 
directories.

The technology is out there, who ever figures out the right way of 
applying the technology will succeed, or attempt to succeed.. :)

/my .025

/m

Jackie Chan <blue0ne () igloo org>
03/23/00 07:04 AM

 
        To:     Guy Bruneau <bruneau () ottawa com>
        cc:     "C.M. Wong" <wongcm () ep com my>, Mark.Teicher () predictive com, 
ids () uow edu au, owner-ids () uow edu au
        Subject:        Re: IDS: comparison of NFR vs RealSecure - auto update

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