Incident response: IT problem resolution with a concept

Constant attacks and repeated incidents are just part of the routine in IT. They’re unlikely to be resolved well without proper incident response management. And a number of requirements have to be met to do the job right.

Service interruptions and incidents are just a part of everyday routine in IT. Which is why almost all larger companies have set up an incident management procedure, also known as “incident response management.” These procedures are commonly based on ITIL and ITSM procedures or ISO standards. The main objective of an incident response procedure is to resolve an issue quickly, in the best possible way. 

But the very definition of a service interruption may vary, depending on the concept applied and the company itself. In general, a service interruption can be defined as an event that results in an interruption of an IT service or impairs its quality. Service interruptions are often categorised by severity – say, as a standard incident or a major incident. But it’s important to avoid setting up too many categories here, because any escalation of an incident usually takes place in a context of emergency management. In other words, beyond a certain level of impact, the service interruption is redefined as an emergency or crisis, as this article about the crisis team explains.

Security incidents: A special case

A properly functioning incident response procedure runs quickly and predictably. The path from detection to response should be short, and communication should be clear, so the right people can be notified quickly if an escalation becomes necessary. A simple structure is also crucial to make sure events get handled in the best possible way. The procedure should be simple enough that employees can follow it with ease even when under stress.

But incident management for security problems is often prioritised separately because these events may have such serious consequences. Which means they’re not just important, but urgent. Events like these are sometimes also handled by a separate staff, called a computer security incident response team (CSIRT), that’s distinct from classic IT incident management. This can also ensure faster recognition of things like false positives (false alarms).

 

The incident manager takes over 

Usually it makes good sense to assign each event to someone who can deal with it authoritatively and takes on the role of an incident manager. The task normally falls to someone within whose sphere of duties the service interruption has occurred. An incident manager guides the people involved through the necessary steps to advance the incident from detection to resolution.

A typical incident response process can typically be divided into three phases. It starts with detection. Then comes an analysis with the aim of developing a fix, and finally there’s a resolution. But the process isn’t quite over yet at that point, because another important aspect is evaluating the incident so as to prevent a recurrence – so far as possible.

 

The three phases of incident response management

The first phase usually begins with an incident report. In IT security, this is often done entirely automatically by appropriate monitoring systems. The necessary steps in this phase include evaluating the incident’s severity, and thus categorising it appropriately. Many security monitoring systems also perform this function. An incident manager for the event is already appointed in this phase. This person will then bring in additional suitable personnel for the second phase, the analysis or solution-finding, and may decide to escalate the matter further. If a solution is found, such as a patch or a change in a firewall rule, it must first be tested. All steps in this phase should be documented, so that variants can be tried out more easily if the first idea does not work out. No later than by the third phase of processing, all the individuals or departments affected must be notified. If the resolution will need more time, it’s a good idea to keep everyone posted about progress. Afterwards, a retrospective analysis of the incident begins. A discussion meeting with developers or administrators can be helpful here, because by working together it’s often easier to find good ways of avoiding such cases in the future. Germany’s Federal Office for Information Security (BSI) maintains a checklist that can be very useful in managing incidents. 

Author: Uwe Sievers