To Provide a Patch or to Service Pack?

From: David Litchfield (david@ngssoftware.com)
Date: 05/29/02 

From: "David Litchfield" <david@ngssoftware.com>
To: <bugtraq@securityfocus.com>
Date: Wed, 29 May 2002 18:39:14 +0100

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/

Relevant Pages

  • Re: To Provide a Patch or to Service Pack?
    ... I personally would prefer to know the risk to which I am exposed and even manage ... the risk myself even if there is no patch. ... The vendor is attempting to save money which is not a bad thing. ... > customers will not be greatly exposed to any risk so it is generally safe to ...
    (Bugtraq)
  • Re: It takes two to tango
    ... great nation was founded with freedom in mind, and this freedom is what we ... likely going to reproduce it so the vendor should be able to reproduce it). ... ASSUME the risk of making any information public. ... which melted the CPU onto the motherboard causing a downtime of 4 hours. ...
    (Bugtraq)
  • Re: REGION=0M and LSQA
    ... You state "vendors ignore customers quite often." ... customers frequently ignore vendor (including ... Others either do not do this or don't advertise the event, IMO. ... I am sure we could say IBM does the same, but in their defense they do seem to listen better at requirements and implement things with more thought that OEM vendors do. ...
    (bit.listserv.ibm-main)
  • Re: The legal / illegal line?
    ... I have only resorted to this technique in the past when I have other customers relying on a given product and a small vendor is not taking that seriously. ... It needs to be a small vendor because as you say, you need to *know* that the person who authorizes it has the power to do so. ... they are _not_ in any way a client until a signed agreement exsists. ...
    (Pen-Test)
  • Re: Decompiler.NET reverse engineers your CLS compliant code
    ... > much of a risk that you may get hit by a bus tomorrow and won't need the ... of becoming useless in the unfortunate case that the vendor dissappears. ... >> with that kind of licensing. ... It does nothing to keep prices low ...
    (microsoft.public.dotnet.languages.vb)