The incident management process

As you know, the Incident Management Process (IMS) consists of five stages: 

1. Reporting 
2. Investigation 
3. Corrective action – incident response 
4. Assessment 
5. Review 

In this section, you’ll explore some detail about what occurs in each, so you can be aware of the kind of considerations you’ll need to make when creating your own IMS. Before starting, take a moment to think about everything you’ve learned so far, and bullet point a list of what considerations you might make if you were to set up your IMS now. There will then be a check back at the end to see if you missed anything.

Figure 1: Incident management process 

Reporting  

This was mentioned earlier, but as a refresher, remember that the report should cover these areas once the incident has been repaired: 

• A root cause analysis 
• How the incident could have been prevented 
• The impact it had on the organisation 
• The estimated costs and damages 
• How the incident could be prevented from re-occurring 
• What additional remedial work is being carried out to ensure the incident doesn’t happen again 

Now, you’ll look at how you might investigate the incident to find this information.

Investigation 

The Incident Response Team, or IRT, is the pre-designated group who can investigate security incidents. An organisation might have different IRTs who deal with different types of incidents, for example a facilities issue or an information security incident.  

Incidents can be anything, a simple virus outbreak, a lost key to a secure cabinet, a terrorist attack, a flood or a power cut. To help them react to any size of incident, the IRT has emergency powers in certain circumstances providing them with the authority to take the necessary action to ensure systems and information are kept safe, and the right procedures are followed for legal investigations. The IRT must follow proper forensic processes if the incident is likely to be the subject of legal proceedings.  

All artefacts to be used by the Incident Response Team should be pre-defined and available for immediate use. Document proformas, in line with the top-level operational security policies and procedures, should be kept up to date. 

Corrective action/incident response  

The computer security industry has a mature approach to handling computer security incidents, in general. Once an incident has been identified, systems should be set up to notify that a response is required and then a process of containment, eradication, recovery and education should be followed. However, evidence shows that more than half of incident response plans fail when first tested. Time to examine the four-step process so you can try to reduce the chances of a plan failing at your own organisation.  

  The Corrective action/incident response:  

1. Containment - Containment means making sure the problem can’t become worse. This might mean ringfencing systems, unplugging or disconnecting equipment, deleting data from hard disks, or issuing remote wipe commands to stolen laptops. These measures should be predefined and designed to resolve the issue once it happens.  
2. Eradication - Eradication is about removing the threat. For example, by quarantining systems and running virus removal software.  
3. Recovery - The recovery stage focuses on resuming the service for those affected, through restoring data from backups, rebuilding systems, or maybe even failing over to a resilience site with limited capability to keep the organisation running during an outage. 
4. Document - Finally, the incident should be documented, and a root cause analysis completed to enable the organisation to learn from it. Every incident is an opportunity to learn and better respond in the future. 

Incident assessment  

You’ve already looked at incident assessment in this Course, so you’ll know that there’s a quantification process that scores an incident from 1 to 4 depending on its consequences. Can you remember some of the criteria for each scoring? Make a note and test yourself.  

Review  

After an incident has happened and the Incident Review Team has resolved the issue, a formal review should be conducted as the final step of the management phase. This should identify: 

• Who was responsible? 
• What happened? 
• Where it happened? 
• Who was affected? 
• What were the reasons for the incident? 
• Over what timeframe did the incident occur? 

It should be a formal meeting with minutes and actions recorded. The meeting should formally review: 

• The processes and work instructions 
• The systems that were included in the incident 
• The overarching policies that determine the organisation’s security posture 
• A root cause analysis to identify what went wrong 

At the end of the meeting, corrective actions should be agreed and signed-off, with authority delegated to relevant individuals to implement a remediation programme.

What’s next? 

Now you have a more in-depth view of what happens in each stage of a successful IMS, you can move on to learn more about what might happen to the reports and data you store when called upon for digital forensics in the future.