lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: inouk at (Eric LeBlanc)
Subject: no more public exploits and general PoC gui
 de lines 

On Wed, 28 Apr 2004 wrote:

> On Wed, 28 Apr 2004 09:35:43 EDT, Eric LeBlanc <>  said:
> 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.

I agree with you. It's depend of situation of the company.

For example:

Case 1:
 - small PME with 10 computers
 - they are all under NAT, on a Cisco/Linksys/486 with linux/openbsd/etc
 - all employee are competent and they have admin privileges on their

In this case, the cost is less o patch their computer (I talk about
Windows).  Even, the fast patching is not necessary, they can wait some
day or week before patching, because they are already protected under the
NAT/Firweall.  Of couse, they have configured outlook to avoid
open/execute html/vbs/other automatically if they use it.  Also, they have
a anti-virus scanner for mail and anti-virus on their computer.

Case 2: Same as Case 1, but all of their computer are connected directly
on the Internet, and all employe don't know the word "patch".

That's will be more more more dangerous, and their computer will be used
as zombies (or wathever) for a long time before a sysadmin will see that
something is wrong in their network. (If he is not competent, I've seen
it one time)

Case 3: big big company with 10 000 computers, such as financial corp.
they are all on local network and they have Internet which they pass
through a router/nat/etc.  Employee don't have admin privilege on their
computers, and the company have also 5 000 more laptop for mobile employe,
taht they connect on the net everywhere, even in a company.

In that case, I bet you will agree with me that the faster we patch their
computer, the lost (money/time) will be less.

Of course, each company is unique... It's just an example that I want to
show that one method (fast patching in particuliar) can't apply to all
situation.  We shoud also consider servers (IIS, MSQL, etc) as well...
It's a complex thing!

> 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. ;)

Bof, "the right tool for the right job".  For example, if I want a
software which it will run only on windows? :-)

Microsoft have done a lot of work about stability (since XP), but about
security and patching system, they have a lot of work to do.

Eric LeBlanc
UNIX is user friendly.
It's just selective about who its friends are.

Powered by blists - more mailing lists