This is the third article in a series that aims to help organisations build and maintain their information security incident management and response capability.
Before getting “into the weeds” of an incident handling process, it is useful to have a bird’s eye view of what it looks like. In this article I will provide you with an overview of the process and a brief description of each of the process steps. While incident handling is widely perceived to be a technical process, only some of its steps require technical knowledge. In reality, a lot of incidents do not require any technical knowledge to handle them. For example, incidents that relate to policy violations, physical security breaches, loss of computing devices, etc.
Simply put, an incident handling process consists of the following steps (the underlined words represent the key process activity):
- The incident handling process is triggered either by detecting a security event (e.g. as a result of help-desk tickets review, audit logs review, unexpected system behaviour etc.) or the reporting of an event by a user, customer, partner, service provider, etc.
- Usually there are a number of events (possible incidents) that require further examination within a limited timeframe. These events should be triaged to determine:
- Which events qualify as being security incidents?, and
- How to prioritise the security incidents in order of importance.
- Incidents are analysed in order of priority. Based on the initial analysis, they may need further triage, whereas:
- Some security incidents might be demoted to events or even disregarded (at least from a security perspective).
- Incident priority ratings are changed.
- This analysis should eventually lead to identifying (note this is not an exhaustive list):
- Which information assets were affected?
- What was the effect?
- When did it happen?
- How did it happen?
- Is it linked to other events or incidents?
- An incident or a group of connected incidents are responded The response process attempts to:
- Contain the effects of the incident, limit its impact, prevent its spread, and regain partial control.
- Eliminate the cause of the incident by eradicating its source. For example, removing the attacker footprint, or removing the incident’s root cause (such as patching a known vulnerability, fixing a misconfiguration error, etc.).
- Recover from the incident by ensuring business-as-usual is resumed and that the relevant controls are in place to prevent the incident from reoccurring, or at least reduce its likelihood and/or impact should it happen again.
Typically, after handling a relatively significant incident or a group of minor incidents, a post-incident analysis is performed. The purpose of this analysis is to identify areas of strength and weaknesses in the process or its execution, as well as opportunities for process improvement.
Each of these steps are highlighted in the diagram below:
Throughout the process, communication with management, relevant teams and team members takes place. I will discuss the individual roles within the incident handling process in more depth in a future article. I will also dedicate an article specifically to discuss reporting on the handling of an information security incident.
In summary, the incident handling process steps are: detection/reporting, triage, analysis, response (containment, eradication and recovery), and finally post-incident analysis.
In the next post I will discuss the detecting and reporting steps of the incident handling process.