Be Better Prepared for the Coming Disaster

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
November marked the sixteenth anniversary of the Morris Internet Wormincident so this is a good opportunity to revisit some of the importantlessons that came from it so we don't make the same mistakes again.

The worm caught the Internet of 1988 quite by surprise and resulted insome pretty major changes in how we do things. For instance, it kickedoff the Incident Response discipline. This was in large part thanks tothe U.S. Department of Defense and its formation of the CERT CoordinationCenter at Carnegie Mellon University's Software Engineering Institute.

Indeed, in today's computing environments, no information securityprogram is complete without having an Incident Response plan in place. Inthe public sector, U.S. government agencies are even required by law(FISMA) to do so. On the other hand, there seem to be at least as manydefinitions of 'Incident Response' as there are plans and teams in placeto handle it.

To clear up any confusion, let's take a closer look at what the realcritical aspects of Incident Response are.

For starters, one of the most common mistakes that I find in companies'Incident Response plans is that they tend to focus purely on thetechnical aspects of how to handle an incident. Security incidents arebusiness concerns first and foremost, and need to be dealt with as such.

So, instead of falling into the trap of writing a plan that provides asimple 24x7 call tree and a set of technical procedures for scrubbingaffected computers of viruses, worms, and spyware, etc., consider insteadthe business process that needs to be followed. (That's not to say thatthe call tree and technical procedures aren't worth documenting. On thecontrary, but they should be secondary to clearly codifying the decisionand coordination process among the organization's businessrepresentatives.)

For example, if your company's Web commerce systems are compromised (orbelieved to be compromised), who is authorized to decide whether or notto shut down the site while the technical aspects of the incident arehandled? That is a huge decision to make, particularly if the sitegenerates significant revenue for your company.

One good practice is to define some levels of incident severity that tieback to business impact and exposure, and then pre-load some of thesedifficult decisions in a way that empowers or authorizes the IncidentResponse team to rapidly take needed technical actions.

The severity levels should include such criteria as: potential for lossof life, potential for loss of customer records, potential forunauthorized disclosure of private customer data, and so on. (Note thatnone of these are technical in nature.) For each severity level, theIncident Response team should have a clear set of actions that it isauthorized to take, and/or decision making processes that it must adhereto.

During the planning process, it quickly should become obvious that theIncident Response plan needs senior-most management endorsement and thattraining and testing of the plan and its participants are well worth thetime and effort. Either way, though, planning these non-technical aspectsof Incident Response in advance is vital to the overall effectiveness ofthe response team.

As the Morris worm spread through the Internet in 1988, many sites werequick to disconnect from the Internet, while others stayed online,blissfully unaware of the coming tsunami. In either case, the responsedecisions, if they were addressed at all, were typically made by thetechnical staff at the sites. Admittedly, there was little or no commerceon the Internet at the time, but the point is that Incident Responseactions really need to be carefully considered in advance.

Another common mistake in Incident Response planning is to neglect toinclude all of the necessary players. Consider how your Incident Responsestaff will need to interact with human resources, general counsel, publicaffairs and law enforcement. Some of these interactions may not beobvious at all, but are likely to become very important during a crisis.

For example, many major incidents have a way of getting media coverage,and often at the least convenient time for the affected sites. Taking afew minutes to brief your company's public affairs representatives on thenature of the incident, and the sensitivities of the situation, alongwith what to say and what not to say can go a long way to protecting yourcompany's reputation. Consider handing the CEO an index card of talkingpoints in the event that she gets ambushed by a reporter in the lobby.

These fairly subtle 'attention to detail' sorts of things can be whatseparates a merely adequate Incident Response program from a great one.The common thread should be advance planning of processes and proceduresthat protect the business in the event of a security crisis. Let thetechnical details flow from there, not the other way around.

If the Internet had even a fraction of the business on it in 1988 as itdoes today, you can be sure that the financial losses would have beenmajor. Let's learn from history and ensure that our Incident Responseplans are ready for whatever the future holds.

Kenneth van Wyk, a 19-year veteran of IT security, is the prinicpalconsultant for KRvW Associates, LLC. The co-author of twosecurity-related books, he has worked at CERT, as well as at the U.S.Department of Defense.

Submit a Comment

Loading Comments...