Antonio Jose Segovia One of the issues that most concern managers of an organization is that their employees (although employees are not the only source of incidents, but also clients, providers, etc.) be able to work without any incident. However, this is practically impossible, because the people are not perfect, and therefore neither are information systems and technologies.
Thus, we can assume that incidents will happen in any organization, so it is necessary to establish a mechanism that will allow us to be ready when one occurs, or when someone – an employee, a contractor, third-party users of the systems – detects a weakness in the systems or services. The first step to achieve this is to establish a procedure to manage security incidents.
Before I continue with the article, let me remind you that ISO 27000 establishes the definition of a security incident in the following way: “a single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security.”
Now we are going to see in the following paragraphs the main things that you need to manage security incidents in accordance with ISO 27001 (Annex A.16 Information security incident management).
Treatment in five steps
The management of security incidents is based on different steps, which include:
- Notification of the incident: A person detects an event that may cause harm to the functioning of the organization, so he needs to communicate the incident according to the communication procedures of the organization (usually an email, a phone call, a software tool, etc.).
- Classification of the incident: A person receives the incident notification and, depending on various parameters, it is classified. The person who detects the incident can also make a classification, but is a technical expert who classifies it in the appropriate way.
- Treatment of the incident: Once the incident is classified, and the severity and time agreed for its resolution are known, a technical expert needs to decide on the necessary measures to resolve it.
- Close the incident: Once the incident is solved, all the information generated during the treatment is recorded, and finally, the person who first sent notification of the incident is notified that it was closed.
- Knowledge base: All the information generated during the treatment of the incident is critical for possible similar incidents in the future, as well as to collect evidence. Imagine that a user updates a system and after this – the system is (unintentionally) shut down. Then the user opens an incident, and incident is resolved and closed. The information generated to resolve the incident is recorded, so if the problem happens again in the future, they can simply refer to the knowledge base; they will have the perfect solution without having to waste time.
Therefore, we can see that these could be different states that an incident could have, and it is also important to inform the user about any changes in the state of the incident.
Responsibilities and knowledge base
Usually, we will define the following responsibilities:
- Technical level 1: Reception of the incident and classification
- Technical level 2: Decision about the actions and treatment for the resolution of the incident
- Responsible for changes: Approve changes when necessary
- Responsible for knowledge base: Record all information related to the knowledge base
If the company is small, the technicians for level 1 and level 2 can be the same person.
Classification of the incidents
There are many ways of classifying incidents, but the usual is to consider two parameters:
- Impact: Damage caused to the business (in economic terms, image, etc.)
- Urgency: Speed with which the organization needs to correct the incident
The intersection of these parameters will allow us to determine the priority of each incident, so in this way you can set, for example, the following table of values:
Priority matrix
So, incidents with value 1 are critical because the urgency and impact are high, so they need to be resolved before the other incidents with values 2, 3, 4, or 5 (this is the right sequence to resolve incidents).
Tools
There are many tools on the market to manage security incidents. Most of them register any type of incident, but in this case it would be appropriate to ensure that these tools allow us to differentiate a security incident from other types of incidents.
However, it is not mandatory for an organization to use a specific software tool for managing security incidents. It is equally valid to use an Excel or Word template, to register all security incidents, and to control the status of each one. A software tool can be useful, but if the incidents are few, from my point of view, Excel may be a good option.
Finally, we cannot prevent all security incidents from occurring, because it is impossible, but we can treat them, which means that the organization can be prepared for security incidents and decrease the damage.
If you are implementing ISO 27001, you can use this free ISO 27001 Lead Implementer Online Course to learn all the requirements.
