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] [thread-next>] [day] [month] [year] [list]
Message-ID: <3F26D7D6.9080704@brvenik.com>
From: security at brvenik.com (Jason)
Subject: Avoiding being a good admin - was DCOM RPC
 exploit  (dcom.c)

Michal Zalewski wrote:

> On Tue, 29 Jul 2003, Jason wrote:
> 
> 
>>Given a conservative half a day downtime for only 100,000 of the more
>>likely 150,000 employees at a very conservative average burden of $10
>>per hour you have spent $4,000,000 in productivity losses alone. This
>>completely ignores costs like lost data, lost confidence, work that has
>>to be redone...
> 
> 
> A-ha, so all of the 150,000 employees maintain a constant rate of
> "productivity", and are at a hundred percent of their output capacity, so
> that a downtime will cause an irreversible loss they cannot compensate for
> by skipping one coffee break after an incident (incidents like this
> occuring not particularly often)? And all perform a work that will be
> disrupted by an outage?
[snip]
> 
> For most companies, an incident like this once in a while is just an
> inconvenience. For that reason, they would not consider spending enormous
> amounts of money on a better staffed and better educated IT department and
> constant monitoring of the threats. Worm comes, worm goes, big deal.
> 

I agree that historically most classic worms will have a negligible 
impact on the business, especially the outlook/mass mailing type worms. 
  This is changing rapidly, we had increasing warnings with explorer32 
then code red then nimda then saphire/slammer...

Most of the worms that cause widespread impact and outage take advantage 
of poorly configured systems or unpatched systems or a common breakdown 
of the human part of fixing after following the failure of the technology.

In the case that was presented the worm resulted in a widespread 
sustained outage for most of the affected organizations lasting one to 2 
days before network services were usable and had hold out segments and 
resurgence in areas for up to weeks. This was 6 months after it hit mind 
you.

I used low sweeping numbers to represent the case in general to not have 
to consider all of the possibilities. That is an entire effort itself 
and does not do well in mail, especially when there are extra 0s and no 
coffee pumping in my veins. It was to illustrate the point that is costs 
less to suck it up and do it before and not after the fact.

I find it hard to believe that during the next technology refresh best 
practices in building these images and disabling these unneeded services 
by default cannot be done. I also find it hard to believe that this 
could not have been done in the last technology refresh bringing us to 
win2k. Especially for a company with 150,000 systems.

I think that there is no excuse for accepting an answer that it can not 
be done when there has been information readily available for years 
showing how to do it. It is an education effort and exercise in 
diligence that may ultimately make a few decide to change industries.

In doing this we will be able to handle most potential worms with this 
casual attitude of indifference because we will have an extremely 
limited exposure.

The fact that these worms are becoming more aggressive and more 
insidious and more common means that we need to start doing this a while 
ago. The more this is done the less motivation there is to produce the 
worm. The need for enormous amounts of money and IT resources and 
constant monitoring will ultimately be reduced significantly as will the 
cost of the gamble.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ