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/
This archive was generated by hypermail 2b30 : Wed May 29 2002 - 16:51:06 PDT