Date: Wed, 29 May 2002 18:39:14 +0100
From: David Litchfield <david@ngssoftware.com>
To: bugtraq@securityfocus.com
Subject: To Provide a Patch or to Service Pack?
Critical is a relative term. For me, what may be critical, may be
non-critical to many others. As a consumer of a (nonspecific) software
product, if there is a security flaw in it I'd like to be given information
about the flaw and access to a patch. Having read and digested this
information and assessed the risk to me and my organization, I may choose
not to install the patch but then again I may - if I think this is, in my
situation, a critical security issue. At least I have the choice though.
Remove the security patch, by opting to roll up as many of them as you can
into a service pack, and I am no longer empowered to make this choice. The
vendor has attempted to assess the risk on behalf of their customers, which
with a large customer base, is nigh on impossible. There is no one solution
fits all.
So what are the motivations for going down the service pack path as oppossed
to providing individual (or group / 1 in 10) patches?
Money? Assume it costs 100K to produce and organize a hotfix for a large
organisation. With, say, 50 hotfixes a year this can get quite expensive so
there is a definite business case for rolling out as little hotfixes as
possible. The vendor is attempting to save money which is not a bad thing.
However. Assume that a fix for a security vulnerability is rolled up into a
service pack rather than a hotfix being made available. This was done
because the vendor has "assessed" the risk and believe that 90% of the
customers will not be greatly exposed to any risk so it is generally safe to
service pack it. This still leaves 10% who are exposed to the risk. Lets say
1% of this 10% are bitten by the issue. The cost to these people will/could
be, I would argue, considerably more than the 100K the vendor was trying to
save. So in effect their offloading their costs onto the customer. This is
not a good thing.
Avoiding bad press? Another possible reason but one which is mitigated if
the vendor writes a more secure product in the first place. The more shame
you have to put up with, the less likely you are to re-follow the steps that
lead to the shame in the first place. ( a bit weak I know but in honesty I
don't think too many vendors hide behind this.)
Admins are complaining about too many patches? Sure this can be a problem -
but, let's face it, it's part of your job so stop complaining and get on
with it. I'm sure the CTO, CSO or CFO would rather have their boxen secured
than not secured. (I know that sounds harsh, but I'm tyring to boil it down
to basics - I've been in a role where I've had to maintain patches and
sure - I'd rather be reading Dilbert - but I'm not paid to do that.)
So anyway, these are my views and I wonder what the general consensus is out
there. Should patches me made available for all security issues or should
the vendor assess the risk on behalf of their customers and roll them up in
service packs. What can we do as a community one way or the other to have
recommedations excepted? Or if you've anything further to add that I've not
covered or haven't thought of - both pro and anti please feel free.
TIA,
David Litchfield
http://www.ngssoftware.com/
