Firewall Wizards: Re: The Morris worm to Nimda, how little we've learned o r gained

["Jon O ." <jono () microshaft org>]

I'd have to suggest that the possibility of patches causing a failure
is again the responsibility of the vendor to ensure they function properly 
and you patching your system does not risk your job or failure.

If the company releases poorly written software and it needs a 
security patch for whatever reason, it should work. If it doesn't
they should learn to do it right. If they don't, you may need to
switch vendors. If you can't switch vendors, you have a monopoly.

This could be as simple as the vendor providing an adequate backout
function after you install the patch, or just testing their patch
install to ensure it won't blow up your implementation of their
software. 

Creating a track record of patches which result in failure and 
thereby instilling fear in the purchaser should not be accepted.




On 03-Jan-2002, Behm, Jeffrey L. wrote:
> > At the very least, jobs should be on the line when companies are
> compromised by code 
> > that could have long been prevented by patching of applications and OS's,
> > especially when those patches have been widely available and publicly
> > announced.  Even an arson victim faces penalties if they have violated
> I agree with your article as a whole, but take minor exception to the above
> paragraph.
>
> Is the job on the line if there are no or very little resources available to
> test the patches?
> I don't think you aren't suggesting blind application of all security
> related patches released from a given vendor, so how does one decide which
> are the "real" ones to apply, and which are the "ones we don't really need."
> It's the old adage of "apply patches and take a chance of breaking
> something" vs. "don't apply the patch until you are sure you need it" (but
> how are you "sure"?)
>
> I.E. Is my job on the line if I apply a patch and it causes more damage (due
> to my own corporate implementation) than the issue it was supposed to fix?
>
> I will give you that there are some patches that one should apply due to the
> severity of the consequences of not applying it (BIND, Sendmail, and
> others). My point is that if the company is not willing to provide the
> resources (time, hardware, people) needed to properly test the patch(es),
> the job should not be "on the line."
>
> A minor point, perhaps, but with the lack of skilled security admins, and
> unwillingness of companies to provide adequate resource to security
> infrastructure (including patch testing), I don't think all the blame lies
> on the ones that "should have known the patches needed to be applied."
>
> IMHO (and no flame nor offense intended!),
> Jeff
>
> Statements made are my personal opinion and in no way reflect the views of
> any company, corporation, or business.
>
> > -----Original Message-----
> > From: R. DuFresne [mailto:dufresne () sysinfo com]
> > Sent: Thursday, January 03, 02 3:11 AM
> > To: firewall-wizards () nfr net
> > Subject: [fw-wiz] The Morris worm to Nimda, how little we've learned or
> > gained
> >
> >
> >
> >
> >                     The Morris worm to Nimda
> >                how little we've learned or gained
> >                   
> >
> >                                   by:  Ron DuFresne
> >                                          (c) 2001
> >
> >
> >
> >
> > 2001 was a tumultuous year.  Prior to the September 11 airline 
> > attacks on
> <snip>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () nfr com
> http://list.nfr.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://list.nfr.com/mailman/listinfo/firewall-wizards