Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
Security lessons from Katrina
Mark Rasch, 2005-09-12

In the waning days of August, a massive category 5 hurricane devastated the gulf coast of the United States, particularly devastating the city of New Orleans. In addition to the estimated $50 billion in property damage, clean-up and reconstruction costs, and the hundreds of likely dead, and tens of thousands displaced, the hurricane and its aftermath have disrupted businesses throughout the southern United States. From this disaster, there are a few lessons IT staff, and IT security staff, as well as senior management should learn. The sad thing is that many won't take these lessons to heart.

1. Infrastructure is important

Much of the devastation resulting from hurricane Katrina, particularly to the city of New Orleans, resulted not from the initial wind damage, but from the collapse of key portions of the infrastructure which were not designed to withstand an event that, at least in retrospect, was eminently predictable, if not inevitable. The collapse of key levees in the Big Easy caused tens of millions of dollars of damage and loss because they were designed to withstand only a category 3 hurricane.

In most companies, the IT infrastructure has grown organically, based upon the needs or perceived needs of individual business units. Thus, the mix of hardware and software, applications, technologies and processes are generally not mapped, and generally not adequate. Most entities do not know what technologies that they have employed, what software (or versions) they are using, or even what the scope and extent of their network looks like. In addition, in most enterprises, "security" is a discrete item -- it's an add-on, often an afterthought, yet it's frequently mentioned in one of those, "oh by the way" telephone calls after some new application is about to go (or has already gone) live.

Infrastructure is fragile and brittle. Survivability, redundancy, and security have to be built into it at the outset. An elegant network or application is of no use if it is destroyed, insecure, or inoperable. Duh.

2. Infrastructures are co-dependant

We typically think of IT as a single infrastructure, but it is not. Perhaps if your network and the Internet are seen as one of the same, it's easier to explain all those security breaches on "your" network. When the hurricane took down the electricity, the oil and natural gas refineries on the mainland of the gulf coast could not operate, nor could the pumping stations pump any oil or gas. A single catastrophic event will likely lead to the disruption of multiple infrastructures, each dependent upon each other.

The same is true for both IT and IT security. Electricity, telecommunications, Internet, transportation, and people are all co-dependent. Knowledge of these facts should inform not only your disaster recovery plans, but also your initial design. Don't forget that hardware, software, policy, planning and training are also key elements of your infrastructure.

3. Prevention is cheaper than response (usually)

Much of the work of prevention -- knowing what the risks to the enterprise are, and mitigating these risks where it's cost-effective -- can and should be done long before any attack or disaster affects an enterprise. It has been estimated that the costs of responding to an attack, including personnel costs, data recovery costs, diversion of attention from other priorities, direct economic damage and theft, and costs that damage one's reputation are often from 10 to 100 times the cost of preventing the damage in the first place. Right now, the tens of millions of dollars it would have cost to shore up and improve the levees looks like a sound investment. A month ago, it was government pork barrel spending.

We typically tie IT security spending to a percentage of the overall IT budget, and then value security based upon the value of the IT infrastructure. Why spend $50,000 to secure an IT asset that itself only cost (or is worth) $5,000? This is the wrong way to analyze the situation. We need to address the cost not of the IT itself, but the value of the information that is being processed by, stored on, or transmitted through the infrastructure.
Story continued on Page 2 



Mark D. Rasch is an attorney and technology expert in the areas of intellectual property protection, computer security, privacy and regulatory compliance. He formerly worked at the Department of Justice, where he was responsible for the prosecution of Robert Morris, the Cornell University graduate student responsible for the so-called Morris Worm and the investigations of the Hannover hackers featured in Clifford Stoll’s book, "The Cuckoo’s Egg."
    Digg this story   Add to del.icio.us   (page 1 of 2 ) next 
Comments Mode:
What lesson would that be? 2005-09-13
Anonymous
Security lessons from Katrina 2005-09-13
Ramki B
Security lessons from Katrina 2005-09-13
Anonymous
Security lessons from Katrina 2005-09-15
Peter B
Security lessons from Katrina 2005-09-16
Anonymous
Security lessons from Katrina 2005-09-18
Sreehari Padmanabhan
Risk management 101 2005-09-19
Oofus Funnybutt III
Security lessons from Katrina 2005-09-21
Anthony LAI, CISSP, CISA
Security lessons from Katrina 2005-09-21
Javier Romero


 

Privacy Statement
Copyright 2010, SecurityFocus