[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200309021526.h82FQrEl015632@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Slow mail (was Re: New Microsoft Internet
On Tue, 02 Sep 2003 02:57:49 MDT, Irwan Hadi <irwanhadi@...by.com> said:
> Received: from NETSYS.COM (localhost [127.0.0.1])
> by netsys.com (8.11.6p2/8.11.6) with ESMTP id h827wOx20101;
> Tue, 2 Sep 2003 03:58:24 -0400 (EDT)
4AM??? ;)
> I believe that for infosec stuffs, the faster information being
> distributed/sent is the better. Late putting patch just because the
> information come almost 1 hour later after it is sent might be
> catastropic.
At 4AM I'm usually asleep. At 5AM I'm usually *still* asleep.
Let's think the risks through here. The only time an hour's delay would prove
a problem is if there is a *specific* incident (such as a massive DDoS or
Warhol Worm, or the discovery of *which* 20 IP addresses Sobig-F will be
using). In such a case, e-mail has a significant weakness:
Telephones have bells that ring.
This is actually a problem I've been trying to deal with for several years in a
non-infosec context (the specific case is "University President decides at 1PM
that the Uni is closing at 3PM, 2 hours early, due to impending weather". In
this case, it's often not just infosec, it's lives at danger (we're in the mountains,
and some employees live on some very dangerous back roads that get much worse
if there's an ice storm). It turns out that sending out 60,000 pieces of e-mail in
under 5 minutes is easily doable.
Actually making sure that the information is *READ* and *ACTED ON* is a much
bigger problem. It turns out to be *much* more productive to send e-mail to
the 200 senior secretaries in each department and have them do the door-to-door
notifications in their department. The averaged tenured professor is very
unlikely to read his e-mail immediately, but even the most absent-minded
instructor will take notice when the senior secretary tells them the same
information that was in the e-mail....
-------------- 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/20030902/4667ee2e/attachment.bin
Powered by blists - more mailing lists