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. Of course some users don't apply patches when they are out (check Nimbda) but some prefer to apply the patch as soon as possible without waiting it to be bundled with 4+ other patches (check you know who ;) ). In case you have missed it, check: http://www.eweek.com/article/0,3658,s%253D701%2526a%253D26875,00.asp "...He later acknowledged that some Microsoft code was so flawed it could not be safely disclosed..." Georgi Guninski http://www.guninski.com David Litchfield wrote: > 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 : Thu May 30 2002 - 08:32:59 PDT