On Wed, 28 Apr 2004 09:35:43 EDT, Eric LeBlanc <inouk@xxxxxxx> said: > Just to tell your boss that the > worm/DoS/exploit/wathever-that-will-cause-a-severe-damage-on-machines-and-network > will cost them more than keeping their system up to date (with proof). That would be easy enough to do, except for the difficulty in actually generating accurate and believable ROI values for patching. It's easy to quantify the costs for the admin time in doing the work and the costs of the patching downtime if everything goes well, but fiendishly hard in estimating the costs of a given vulnerability left unpatched. We've seen "critical" vulnerabilities that haven't generated a big flamestorm, and we've seen things like Blaster/Slammer. You can't predict which one a given vulnerability will be, and even for a major event, a significant percentage of systems "dodge a bullet" and don't get hit. > It's enough to convince them that the patching will save them a *LOT* of > money and time (if the patch don't broke the system of course, especially > with microsoft patches). So you're left with: 1) Install the patch during the regular patching schedule, with known cost $X and additional unknown cost $Y if the patch is bad. In addition, this exposes you to a worm cost of $W if a small worm comes out (with probability A), and a higher cost $U if a big worm comes out (with probability 1-A), and both $W and $U are not guaranteed even if a worm does happen, since your site might dodge the bullet till the usual patching window. In addition, you have to factor in a cost of $V if you're directly targeted by a black-hat, with probability dependent on target desirability, opportunity, whether that black hat has the 0-day, and whether you've fired anybody recently - and $V was a risk even *before* the patch/advisory came out... 2) Install the patch immediately, with higher known cost $X+$Z for service disruption, plus a higher likelyhood of incurring $Y due to less regression testing. Make reasonable estimates for A, U, V, W, X, Y, and Z. When calculating X, Y, and Z, make sure to allow for "lost opportunity" costs - if you're busy doing X, that's time you're not spending doing other stuff, so if the VP doesn't have a presentation for a potential client because you were patching rather than fixing his workstation, the cost of the lost contract should be included. You have one hour. Show all work :) Oh, and remember that for the *next* patch, almost none of these numbers can be re-used, so you get to do it all over again.... The *real* reason that it's so hard to make the case to the average PHB is because it's actually very hard to calculate the costs/benefits for any given patch. If you want to actually make the case, take a *years* worth of money paid to Redmond, a year's worth of A/V software costs, a year's worth of costs attributed to fighting viruses/worms/attacks, and suggest a move to RedHat instead. ;)
Attachment:
pgp00071.pgp
Description: PGP signature