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
Richard,

I did mention the same exact type of situation in a previous email..   in 
an IDS type of architecture, a designated host server should receive the 
update, go through some sort of process of verifying the source, the 
content, checking for all kinds of things (checksum, file size, file 
description, viruses, etc).. 
Then allow the administrator to view the contents and if they apply, run a 
compare and contrast routine to ensure compatability/interoperability with 
the current vulnerability data file, grab a test set of rules, test it 
out, simulate some of the common traffic that has been observed (Instant 
Replay).. 
Make sure everything works, then in an ideal environment, submit a change 
control request to the network folks, alerting them of the expected 
downtime, roll over the secondary IDS system.. 
You did have a cold spare IDS ready to go ?? 

Turn on the switch to the secondary IDS system, upgrade the primary IDS 
system, watch it for a few hours, make sure it doesn't keel over with the 
new update, turn off the secondary IDS system, turn on the primary IDS 
system with the new update and monitor.

If it fails, turn the secondary IDS system back on, send a support ticket 
to the network group, saying you backed out the change, send support mail 
to the vendor, and yell and scream at the reseller about the auto-update 
not working, send the debug output to the vendor, and let them squirm as 
they admit the auto-update didn't work, but yet worked in their 
environment and during QA..  :)..

Refer to the Software Quality Assurance Handbook by Bezier about software 
deployment.. 

/cheers

/mark

"Reybok, Richard K" <rreybok () lehman com>
03/24/00 08:35 AM

 
        To:     "'Jackie Chan'" <blue0ne () igloo org>, 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

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