Incidents, security incidents, information security incidents and personal data incidents are common topics for any person dealing with cyber security or someone who wishes to do so in the future.
Unfortunately, both at the beginning of the career of a future cyber security officer and later on, incidents handling might be particularly problematic, as security incident management is a very broad field of knowledge.
Here various fileds of knowledge interlink: high-level IT management, technical aspects of system administration, computer forensics and, finally, legal and organisational issues as well as crisis management and personal data protection.
The purpose of this text is to give a brief introduction to the problem of incident management and to point to further sources for possible self-studying of the issue.
Professional literature provides many definitions of incidents, however, we may ignore them for the moment; for the purposes of this text, it is more relevant that incidents can be viewed from three different sides:
- firstly, from the normative side, i.e. from the side of the binding, more or less commonly used standards and the information security management systems (ISMS) based on these standards;
- secondly, from the technical side, i.e. the analysis of events occurring in administered systems, distinguishing anomalies from incidents that can be classified as security incidents, defining the associated IOCs (Indicator of compromise);
- thirdly, from the legal side, i.e. taking into account legal requirements resulting from binding strategic documents, laws, regulations, etc.
Unfortunately, however, things are never that simple in real life, and in practice incident management is a combination of the three above-mentioned approaches, which must be applied simultaneously.
This simultaneous application generates the first fundamental problem of incident management.
How to bring it all together?
How do we build a common vocabulary, how do we unify disparate definitions and extract the most relevant, coherent elements from them? The definitions of incidents as used by IT and the Security Departments are quite different;
How to translate the vocabulary used in standards into technical language? Definitions of incidents used in standards, e.g. from the ISO 27001 family, are not particularly technical – they pay attention to information security, which, taking into account the semantics, is something much more general than system security;
How to combine the logic of regulations (often not very specific) with the general, relatively flexible approach of standards and then translate this into procedures related to systems management, equipment configuration, etc.?
How to create documentation of the system which will be exactly as it is supposed to be, not too long (because nobody will read it), not too short (it has to include all the important elements from the point of view of the managed system), not copied from another system, but adjusted to the one it is supposed to concern, based on a reliable risk analysis, not on imaginary grounds.
The second problem, related to the first but well beyond its scope, can be communicated in the answer to the following question:
why do we need to deal with incidents?
There are two most obvious answers:
- the legislation forces us to do so,
- we have implemented and maintain an information security management system and have undergone or wish to undergo certification or recertification.
The third answer is not as obvious – it is not enforced by law or by the system implemented, but is based on our own choice.
We deal with incidents because it is our wish to do so. We want to do this because we believe that knowing about security incidents occurring in our systems is important.
This is where another – the third – important problem related to incident management arises, namely the issue of proper understanding of the problems described earlier (problem 1 and 2).
Implementing an Information Security Management System (which is also responsible for managing incidents) does not increase our security. We comply with the adopted standard, we have the required procedures, we manage incidents in accordance with the given standard… and that is all. It is quite much, to be honest. We have procedures for handling incidents that are bound to happen sooner or later. But do we have the technical capacity? If not, the functioning of the IMS is merely an illusion.
It is similar in case of compliance with the applicable law. Compliance with legislation will not keep us safe. It will only ensure that we do not pay fines or penalties for non-compliance. Again, we must raise the question of technical capacity, without which legal compliance exists only on paper.
Incident management at the technical level is the only thing that can really enhance the security of an organisation. It should be noted, however, that failure to link technical mechanisms to appropriate procedures (IMS) or implementation of legal requirements will render the solution inadequate.
Incident management must be a coherent process where all three sides of approaching an incident described at the beginning of the text are represented.
As stated at the beginning, this text is intended as a brief introduction to the subject, signalling certain problems and posing questions for further consideration.
The text is accompanied by a list of a few selected items (with a short description) that might prove useful should you wish to further develop your interests. Items relating to personal data incidents and IT systems management incidents (ITIL, ISO 20 000) are not included.
Security incidents affect all systems existing on the market. The most extensive approach to the environments described is provided in [3]; [5] pertains to MacOs and [6] to Linux.
ISO/IEC 27035 is listed under [4]. This standard is not widely known on the Polish market; it has not been translated into Polish, but should be used by organisations profesionally handling incidents. Another issue is the proper preservation of evidence. This is described in a number of normative documents, but they are not widely used – which is actually an understatement, as one can reasonably doubt that even forensic experts use them [*PN-EN ISO/IEC 27037:2016-12 Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence; **PN-EN ISO/IEC 27041:2016-12 Information technology – Security techniques – Guidelines for ensuring the appropriateness and adequacy of the investigative method in relation to an incident; ***PN-EN ISO/IEC 27042: 2016-12 Information technology — Security techniques — Guidelines for the analysis and interpretation of digital evidence; ****PN-EN ISO/IEC 27043:2016-12 Information technology — Security techniques — Incident investigation principles and processes; *****PN-EN ISO/IEC 30121:2016-12 Information technology — Overseeing the IT forensic risk structure]. A detailed discussion of the above-mentioned standards is a topic for a separate text, but listing them here will perhaps prompt interested readers to get acquainted with these documents.
Suggested publications for further reading
[1] Carvey H., Analiza śledcza i powłamaniowa. Zaawansowane techniki prowadzenia analizy w systemie Windows 7, Gliwice 2013 – an excellent book by an outstanding specialist, it is worth referring to it despite the fact that it was published in 2013 and the title refers to Windows 7;
[2] Chojnowski A., Informatyka sądowa w praktyce, Gliwice 2020 – A pioneering work written by a long-time expert in electronics and computer science, providing numerous examples;
[3] Luttgens J, Pepe M., Mandia K.: Incydenty bezpieczeństwa. Metody reagowania w informatyce śledczej, Gliwice 2016 – the first and so far the only textbook on incident response and management on the Polish publishing market;
[4] ISO/IEC 27035-1:2016 Information technology – Security techniques – Information security incident management – Part 1: Principles of incident management – the core standard for incident management, in this edition divided into several parts. The first edition from 2011 was published in one book;
[5] https://taomm.org The Art of Mac Malware, a very interesting, unique collection of material on writing malware for macOS, malware analysis, etc., created by Patrick Wardle;
[6] Ziaja A., Praktyczna analiza powłamaniowa. Aplikacja webowa w środowisku Linux, Warszawa 2017 – the book shows the traditional approach of computer forensics on the one hand and incident response on the other, focusing on the post-breach analysis of a web application in the Linux environment.
