mitch at ccmr.cornell.edu
Fri Feb 21 16:50:36 GMT 2003
If this is the report I'm thinking of, we had a presentation here a
few months ago by someone who was directly involved in the project
that produced that report. Sorry, don't remember her name just now.
Her conclusion though was that the really costly incidents were the
ones where the techies got interested in "what happened here?" and
spent lots of time analyzing the exploit, forensics, et al. Secondary
conclusion: if you want to save $$ don't do this; when a system is
cracked, wipe, reinstall, get back to business, let it go.
Not saying I fully endorse this strategy, though it's obvious how this
conclusion can easily be reached. Just reporting what I heard.
On Thu, 20 Feb 2003, Andrew Cormack wrote:
> The University of Michigan and others published a report of an Incident
> Cost Analysis and Modelling Project in 1998, which has some useful
> figures. The report was only available in printed form to purchase, but
> I found an executive summary through Google. I believe there were plans
> to update the survey but don't know if anything came of it.
> The report does walk throughs of 30 different incidents and tries to
> estimate the costs of each, though a lot of the figures are likely to be
> underestimates as they weren't able to quantify things like reputation
> damage or external liability. So the really costly incidents are the
> ones that leave a lot of staff doing nothing for a day or so: the cost
> of that wasted effort far exceeds the cost of systems staff or hardware
> I tried to do a similar collection of anonymised reports in the UK a few
> years ago but got very few volunteers, I'm afraid.
More information about the unisog