Incident Response Management

An incident is a (potential) deviation from the norm which causes (or may cause) harm [reference].

In other words: activity that you see each and every day is not an incident; you should have processes in place that compensate for the risk that may be associated with it. Activity that has no chance of causing any form of damage is not an incident. That does not mean you can ignore the activity completely, but it is also no all-hands-on-deck situation.

The process that an organization must put in place to respond to these incidents consists of a number of steps (prepare, identify, contain, eradicate, recover, lessons learned [reference]), and it is always followed to some extent. Not always can each step be distinguished easily from the preceding or the following, but in a very real sense, they are always there.

Having the ability to recognize each action that an incident responder takes in relation to each step allows the incident manager to remain in control of the situation.

Especially when an organization may have to handle multiple incidents in parallel, having an established process in place that can be used to separate the incidents, and track the progress of each individual incident is invaluable.

So, step back and reflect on the last incident you handled. It might be a phishing attack that had a chance of success, or even something as trivial as a virus on a computer. What steps did you take? How would each step map to the steps listed above? Was there something you could have done differently in handling the incident? How was the incident detected? Could it have been prevented?

Incident management is an art instead of a science, but we can try to get close. Those who master the art will be able to really add value to their organizations and ensure that they work for an organization in which the human stakeholders have confidence its information handling capabilities.