Last updated at Wed, 13 Dec 2017 16:23:06 GMT
In the series of articles titled “Incident Response Life Cycle in NIST and ISO standards” I review incident response life cycle, as defined and described in NIST and ISO standards related to incident management.
In the previous article, I started discussing ISO/IEC 27035, the ISO standard on information security (cybersecurity) incident management. In this article, I continue the review of ISO/IEC 27035.
Importance of evidence
Why is evidence important and why it is mentioned as one of the benefits of well-structured incident management approach? Again here the role of the incident response team is not often seen as strongly tied to evidence gathering and preservation. The incident response team often acts under strong stress to restore the functionality that has been affected by the incident. The restoration activities sometimes are contradictory to evidence gathering. But what is urgent in the moment of fighting with an incident might become much less important later, when strong, court-admissible evidence is needed e.g. to prosecute the attackers. But if a correct approach is applied to incident management, such as one outlined in ISO/IEC 27035, both of these goals can be achieved.
ISO/IEC 27035 explains that well-structured approach will help properly allocate budgets and resources needed for incident management. Such approach means that incident response team management monitors its performance and draws organizational conclusions from such monitoring to properly allocate people and resources. It will also help correctly allocate tasks and relate them to staff qualifications, which will lead to “engagement of skilled personnel only for those processes where their skills are needed and only at the stage of the process where their contribution is needed”. In my opinion, comprehensive analysis of standard operating procedures (SOPs) of the incident management team might also lead to considering using a security automation solution, which might also help minimize budgets needed for incident management activities.
The incident management cycle of ISO/IEC 27035
I already reviewed the incident management cycle of NIST Special Publication 800-61. Now let’s see how such cycle is defined by ISO/IEC 27035.
ISO/IEC 27035 is based on four phases of incident management:
- Plan and Prepare,
- Detection and Reporting,
- Assessment and Decision,
- Lessons Learnt.
The last phase (Lessons Learnt) constitutes an input to the first phase (Plan and Prepare).
So, similarly to NIST 800-61, a cyclic approach is used.
Let’s discuss these phases. Please note that ISO/IEC 27035-1 discusses “principles of incident management” so it doesn’t give much detail about these phases. They are discussed in detail in further parts of ISO/IEC 27035 standard, I will write about these parts of ISO/IEC 27035 in next articles.
Plan and Prepare phase
Proper planning means effective incident response. The standard lists formulation of information security incident management policy as the first preparatory step. Such policy should cover not only a general approach to cybersecurity incident management, but also list benefits of properly structured incident management to an organization. Such policy should be known to all staff and also, which is even more important, should have top management commitment, because this is what ensures that appropriate resources are assigned to incident management.
ISO/IEC 27035-1 requires that the existence of information security incident management policy should be reflected in other high-level cybersecurity documents, e.g. general organizational information security policy.
Information security incident management policy is a high-level general document. It should be the basis for lower-level procedural documents. The main procedural document for incident management should be the information security incident management scheme (also called response plan), containing detailed procedural and technical information on the incident management approach. Such scheme can contain SOPs (standard operating procedures) or SOPs can be separate documents, linked to the scheme.
Cybersecurity incidents and incident handling awareness and training program development should also be a part of preparatory activities. User awareness might have a critical influence on the effective incident response (there might be events that are not detected by automated systems but can be seen by users as an anomaly – it then only depends on user awareness if such event is reported or not). So this preparatory step should not be neglected.
And, last but not least, an incident response team (IRT) needs to be established. ISO/IEC 27035-1 defines two types of IRTs: dedicated team and virtual team. I’ll come back to these two types of teams in one of next articles, in which I’ll review ISO/IEC 27035-2 that gives detailed preparatory guidance.
Detection and Reporting phase
ISO/IEC 27035-1 diversifies the following sources of event information (events might become incidents if certain criteria are met):
- technical security systems;
- logs analysis;
- IT department / helpdesk;
- external parties.
The management of all these sources can be a bit complex, so you can consider using a security automation software to handle certain interactions and communication.
The standard stresses that also detected vulnerabilities should trigger appropriate actions from the incident response team (i.e. not only incidents are triggers of such actions). I’ll come back to this in more detail later.
The standard requires that all events are tracked in a dedicated tracking and monitoring system, handled by the incident response team. It also points out that one of the main purposes of such system is decision and support, so there should be as much relevant data entered as possible for well-informed decisions to be made.
In next article in this series, I will review next phases of ISO/IEC 27035 incident management cycle.