Katrina: a tough lesson in security
Pay attention, or pay the price
4. Cost of response is shifted
A typical axiom in the tort law of negligence is that we impose the liability upon the party or entity best able to avoid the damage or risk. In the case of the New Orleans flooding, this would have been some combination of the local, state and federal governments, including the U.S. Army Corps of Engineers, and of course, the United States Congress that funds these projects, as well as the electorate that votes for these Members of Congress. Had better, stronger and more durable levees been constructed and maintained, billions of dollars of damage could have been prevented.
However, in most situations, the people bearing the risk of loss are not the same people who have to make the decisions about prevention. Homeowners in New Orleans essentially had little say about whether the levees were built (although they could have chosen to live elsewhere - like San Francisco or Sri Lanka?) What is worse, drivers in Washington, D.C., those who are now paying $3.70 a gallon for gas that was just $2.50 before the hurricane, previously had little reason to support plans to build stronger levees or redundant distribution centers on the gulf coast. Operators of the closed Houston Astrodome also had little reason to appreciate the effects of a hurricane in Louisiana on their facility.
In IT attacks, the same is true. The people whose information is affected by the attack may be distant - temporally, proximally or otherwise - from the decisions about whether or how to secure the IT. The cost of prevention may come from the IT budget, but the benefit goes to other business units' productivity and it is rarely captured. The same is true for the costs of avoidance. We need better metrics for the TRUE cost of NOT providing adequate security, and then we will be better able to make informed decisions about how much to spend on security.
5. Insurance is important
In the aftermath of hurricane Katrina, many individuals who thought they had insurance (because they had been paying thousands of dollars in premiums, for years) to cover damages resulting from the hurricane find that they may not be insured for the damages. This is because most insurance policies have specific riders excluding coverage for damage resulting from "flooding." So if a hurricane blows out a levee causing water to crash into and submerge your house, the damage, although caused by a hurricane, may not be covered.
Many insurance companies offer various forms of insurance to protect key parts of the IT infrastructure. These include general business interruption insurance, reputation insurance, theft, damage or loss insurance, critical document insurance, and various forms of cyber-insurance. However, these policies contain riders and exclusions that are often confusing and mutually contradictory. If there is "physical damage" to a computer that holds your critical documents, you may be covered, but "logical damage" may not be covered. If the hard drives are wiped out by a flood it may be covered, and similarly if they're wiped by a magnet or a power surge they may be covered - but if they're wiped by a virus or worm, they are excluded. Thus, in conducting risk assessment it is important to review all of your insurance policies (including your D&O policies) to make sure you have appropriate coverage.
Also remember that when you are reducing your risk by implementing a comprehensive IT security program, you are also reducing the risk of your insurance company who ultimately would have to pay for covered losses. As a result, just as when you put in a smoke alarm or burglar alarm, you should contact the insurance company when you plan to make significant changes in your security to see whether they will reduce your premiums -- or better yet, pay for the improvements directly. Some companies, particularly those that offer cyber-insurance policies, will even pay for comprehensive audits or assessment themselves. Free security? What could be better?
6. Backup, backup and backup
The day before I go to the dentist, I try to do about six months worth of flossing and brushing. Sure, we all know we need to do this, and there is nothing sexy about having a plan for backups, but we frequently don't do them properly - not only at the corporate level, but at the personal level as well.
The hurricane also taught us that many of our plans for data recovery and disaster recovery may be too limited. For example, prior to September 11, 2001, both the federal, state and city disaster centers were located in close proximity to each other for planning, coordination and communications purposes. These were, of course, located in the World Trade Center. Not a bad decision to start with, but a very unfortunate result.
Similarly, we often have wonderful backup plans to backup data and store it at a remote location just a few blocks or miles away. In the wake of the hurricane, we need to reconsider these decisions. Work locally and backup globally.
Of course, this creates new problems. The more distributed information becomes, the more vulnerable it is to attack, disruption, and to the legal processes of the country in which it is located. Outsourcing data storage may solve some of these problems, but it may also create new problems itself. There are all fun things to think about.
7. Training and testing
The ultimate defense against disaster are well trained and well equipped people. Too few companies bother to train their employees to recognize cyber attacks, and to respond appropriately to them. All the technology in the world won't help unless people know it exists and know how and when to use it. Awareness and training are critical to success.
A cyber attack, like the breach of the New Orleans levees, is more than likely. The best enterprises will be prepared, and therefore will survive.
SecurityFocus columnist Mark D. Rasch, J.D., is a former head of the Justice Department's computer crime unit, and now serves as Senior Vice President and Chief Security Counsel at Solutionary Inc.
Sponsored: Benefits from the lessons learned in HPC