From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: no more public exploits and general PoC gui de lines 

On Wed, 28 Apr 2004 09:35:43 EDT, Eric LeBlanc <inouk@....net>  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. ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040428/27310ba6/attachment.bin

Powered by blists - more mailing lists