Getting incident response right: Part 2

By | September 04, 2012

Posted in: Network Security Trends

Now that we know what to do in advance, what happens when the balloon goes up and the response is not theoretical but right now. The difference between a well thought out, comprehensive plan and a plan that leaves the participants fluttering around for hours trying to assemble the troops can mean the difference of perhaps millions of dollars.

The critical factor is time. There should be a call sheet, with everyone having dedicated pagers for alerting. The sheet must be current, including alternatives if people are not available, and someone is available 365x24x7. This list should be available as a tree, showing who is to call whom and all key members are alerted. When in doubt, call everyone, but in some cases there may be some who are called, some who are not. (They can always go back to sleep.)

The participants should know exactly what to do and when to do it. For example, the normal response used to be to cut the system off from the network, but this is not always possible. If the system is critical, you cannot just take it offline. Also, the system may hold the key to the attackers, the link that allows you to trace them and perhaps track them.

Define the action to be taken to determine:

  • The exact nature  of the attack; what is being done and to what asset(s)?

  • How severe is the attack? Can you watch it develop or does it need immediate attention?

  • What assets are under attack? Are they critical or can you watch for a while and give the bad guys some rope?

  • Quickly assesses the risk to the business


The plan should be sufficiently detailed to:


  • Make clear the network and security tools required

  • The type of information to be gathered

  • The technical and procedural measures to be taken to gather evidence rapidly without compromising it

The level of notification is a bit trickier.  It should be carefully managed on a need to know basis. Depending on the organization’s culture, notifying management may be automatic or it may wait, depending on severity, for the weekly reports.

Affected employees, depending on impact. If they can carry on business as usual, they might never have to be notified. On the other hand, if they are going to be impacted, they must be informed at least in part.

The question of public notification is trickier. One would think that immediate notification is best , but that’s not the case. The Ponemon Institute reports that the companies that wait at least until they’ve had time to assess the breach and determine what had actually happened do better than those that divulge the breach immediately. On the other hand, the longer you wait, the more you leave your organization open to possible criticism.

Others to be considered for notification (and when) includes partners, service providers, legal counsel and corporate communications. Law enforcement is on a case by case basis, but go there only if you are prepared to be committed to sharing information.

The response itself should follow your plan. Isolate but do not necessarily stop the breach unless the need is urgent, but it is urgent if possible to copy the system for forensic purposes. Track down and eradicate all traces of the breach.

In the wake of the attack determine what went wrong and how to shore up your defenses. Is there anything you could have done better? Better forensics, log collections possibly technology gaps and lessons learned. Learn and do better next time, because it will happen again.

You May Also Be Interested In: