lists.openwall.net   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  linux-hardening  linux-cve-announce  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: smcmahon at eiv.com (Shawn McMahon)
Subject: No Subject (re: openssh exploit code?)

Montana Tenor wrote:
> I agree with Mitch.  Lets say you get an advisory that
> a severe thunderstorm may be coming your way.  Do you
> wait until the wind and rain are blowing inside your
> house to close the windows and doors.  Do you allow
> the kids to keep playing outside?  You do the prudent
> thing.  Instead of trying to brute-force Mitch into
> this, think about why doing the right thing to protect
> the long term interests of your business is the RIGHT
> thing to do.

Now let's say you get a severe thunderstorm WATCH.  You're cooking 
dinner.  Do you finish cooking dinner, or do you pitch it and seek shelter?

You don't know, because all I told you was there was a watch; I didn't 
tell you anything else.

Not every severe thunderstorm warning requires the same response, with 
the same alacrity.  I used to be in radio, and I had to make exactly 
those choices; do I stay and broadcast, or is it time to shut down the 
transmitter?  Do I have time to shut down the transmitter, or should I 
not even bother and just bolt for the shelter full speed?

Security isn't a binary decision; not every vulnerability requires 
immediate shutdown of every vulnerable service.  It's about gathering 
information and mitigating risk.  Sometimes the loss to your business of 
shutting off that service immediately is so great that the risk of a 
hard-to-exploit vulnerability that hasn't been seen to be exploited in 
the wild is not great enough to sustain that loss.

Let me put it this way; in between when the latest vulnerability is 
mentioned in Full Disclosure, and when the patch is released, tested, 
and installed, would you want to be told you could not ship any packages 
via FedEx or UPS because the necessary systems all had that service shut 
off while waiting for the patch?  Would you want to be told that in 
order to make up for the shortfall in revenue of having done this, every 
package was going to cost $1 more to ship for the next few months?

For your home system with a handful of users, just doing without 
services may always be the right answer.  For an easily exploited hole 
for which there is a particularly nasty worm running around right now, 
that might even be the right answer for a mission-critical system in a 
Fortune 500 corporation.  It isn't the right answer every time for every 
vulnerability for every system in every company.

We gather the information, and then we make the decisions.  Management 
HAS to be involved in those decisions because the risk to the company of 
fixing the problem is just as important to consider as the risk of 
delaying the fix, or even of not doing the fix at all sometimes.  I 
don't have an example off the top of my head of the latter, although I 
can certainly come up with a couple of fixes delayed for months.  I know 
of some systems at one of the two companies I mentioned above that had 
to delay a critical Windows fix for months because the alternative would 
have been all international flights being suspended.  That would have 
been a big enough deal that it would have affected the economies of 
probably every country in the world negatively.  No, I'm not saying any 
more than that about it, except to say that the fix has since been applied.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ