Information Security Incident Management Process

Information Security Incident Management Process Anna Kostina +7-903-586-45-47 formosa@mail.ru Natalia Miloslavskaya Kashirskoe highway,31 Moscow, Russia +7-495-323-90-84 milmur@mephi.edu Alexander Tolstoy +7-495-324-97-35 ait@mephi.edu ABSTRACT The modern requirements and the best practices in the field of Information Security (IS) Incident Management Process (ISIMP) are analyzed. IS event and IS incident terms, being used for ISIMP, have been defined. An approach to ISIMP development has been created. According to this approach ISIMP processes are described. As an example the «Vulnerabilities, IS events and incidents detection and notification» joint process is examined in detail. ACM Categories & Subject Descriptors H.4.m Information Systems, INFORMATION SYSTEMS APPLICATIONS, Miscellaneous, BSP General Terms: Management, Security Keywords Information Security, Incident Management, Information Security Incident, Information Security Event, Process Approach 1. INTRODUCTION During the period of globalization and the overall development of Internet technology even the most advanced safeguards that decrease information security (IS) risks, for example, IS policy or an advanced firewall, cannot completely prevent an occurrence of events in the information environment potentially bearing threats to business of any organization. The complexity and diversity of today's business activities, use of the Internet and intranets for communication and business tasks predetermine the presence of residual risks regardless of planned and implemented countermeasures. Also, there is always a chance of realization of new unknown IS threats. Insufficient preparation by an organization to deal with such incidents will make any actual response less effective, and potentially increase the degree of potential adverse business impact. Therefore it is essential for any organization that is serious about IS to have a structured and planned approach to [1]: Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIN 09, October 6 10, 2009, North Cyprus, Turkey. Copyright 2009 ACM 978-1-60558-412-6/09/10...$10.00. detect, report and assess IS incidents, respond to IS incidents, including the activation of appropriate safeguards for the prevention and reduction of, and recovery from, impacts, learn from IS incidents, institute preventive safeguards, and, over time, make improvements to the overall approach to IS incident management. The decision of all these tasks can be obtained, if the organization has an implemented effective IS Incidents Management Process (ISIMP). It is extremely important, because ISIMP is one of basic parts of the general IS management system (ISMS) [1]. The data, that are accumulated within the given process, are necessary for many other ISMS s processes, for example, for carrying out a correct IS risks analysis or for efficiency assessment of existing IS measures and management processes. In relationship with other IS management processes ISIMP can help to assess the overall level of organization s IS. All these benefits become even more valuable when the organization uses has distributed structure, as well as partners all over the world and as a consequence uses the Internet and its intranet very actively, because the large amount of IS threats comes from the Internet and internal intranet. 2. INTERNATIONAL DOCUMENTS REGULATING IS INCIDENTS MANAGEMENT At the moment there are a sufficient number of international documents that regulate various aspects of IS incidents management. As a rule all these documents consistently consider all ISIMP stages: from process planning to its improvement after the analysis the results of the process itself. The Standard ISO/IEC 27001 Information technology Security techniques Information security management systems Requirements contains the requirements for ISMS development regardless of its activities. ISO/IEC 27001 imposes some of the general requirements to IS management processes, including ISIMP as its integral part. Among these requirements are the following [1]: the use of PDCA model (Plan Do Check Act) [1] for processes planning and implementation, control and analysis of these processes, and also improvement; proper documentation of processes and procedures; management commitment to all IS management processes; 93

periodic analysis and continual improvement of IS management processes. According to the Monitor and review the ISMS clause the following requirements should be executed in any organization [1] it is necessary to: detect errors in the results of processing; identify attempted and successful security breaches and incidents; help to detect security events and thereby prevent security incidents by the use of indicators; determine whether the actions taken to resolve a breach of security were effective. enable management to determine whether the security activities delegated to people or implemented by information technology are performing as expected. In Annex A Control objectives and controls in section А.13 IS incident management the certain set of requirements is included also. These requirements are already more concrete and are ascribed to separate stages of ISIMP. ISO/IEC TR 18044 Information technology Security techniques Information security incident management determines a formal ISIMP model. ISIMP description, as well as in ISO/IEC 27001, is based on the use of cyclic PDCA model. The document describes in detail the stages of planning and preparation, operation, analysis and improvement of ISIMP. The tasks of development and maintenance of the process documentation are also taken into consideration. Recommendations on necessary resources and procedures are also given. NIST SP 800-61 «Computer security incident handling guide» represents the collection of the best practices in the field of construction of processes of reaction to computer security incidents [3]. However IS incident is wider than computer security incidents. The group of software and technical incidents, including computer security incidents, is only its component. The process is examined from initial planning to an incident analysis after the ending of reaction process. Problems of reaction to different types of computer security incidents are discussed in detail. This document can be used as a basis for creation of incident management plans for incidents that can be caused by the use of Internet technologies. In CMU/SEI-2004-TR-015 «Defining incident management processes for CSIRT» the technique of planning, implementation, assessment and improvement of ISIMP is described. The main attention is given to the organization of an IS incidents reaction team work. The order of interaction of various participants roles during incident management processes is determined. The use of a role principle allows to allocate employees with additional duties within the scope of ISIMP without a binding to their posts and official duties [1, 4]. It is stressed out that ISIMP can be implemented in different ways depending on conditions in which it will operate. The document is not the step-by-step instruction on ISIMP development, implementation and improvement, but it gives a framework for development of the ISIMP. 3. IS EVENT AND IS INCIDENT But before proceeding to the definition of the goals of ISIMP and tasks that need to be addressed in order to achieve these goals, we are going to analyze the concepts of IS event and IS incident. In general, all of the documents observed above introduce the following definition of IS event an identified occurrence of a system, service or network state indicating a possible breach of IS policy or failure of safeguards, or a previously unknown situation that may be security relevant [1, 2]. In order IS event will take place, it is necessary that any action directed to any object has been accomplished (fig.1). Action should be accomplished by the subject. The action directed to the object should have the certain result. It is important to understand that this action does not necessarily change the state of the object on which it is directed. For example if a user incorrectly enters his/her login or password, IS event takes place. The event is - the check of user login/password and his/her access right to the given account, has failed. An event represents some logic connection between a subject, an action and an object on which the given action is directed, and some result of this action. Figure 1. IS event Defined IS event does not make any distinction between authorized and not authorized actions. Sometimes the events that are found out can be a part of IS incident or simply relate to IS. For example, if the user correctly enters login/password, then he/she gets an access to the given account. But it can appear that in this case there was the user spoofing (masquerade). Sometimes the events that occur are parts of the steps taken by the malefactor, for any unauthorized result. These events can be considered as a part of IS incident. Thus IS incident is indicated by a single or a series of unwanted or unexpected IS events that have a significant probability of compromising business operations and threatening IS [1, 2]. IS incidents can be deliberate or accidental (for example they can be a consequence of an error or the natural phenomenon) and can be caused both by technical and physical means. Their consequences can be such events as not unauthorized changes of information, 94

destruction of information or other events which make it inaccessible, as well as damage to the assets of the organization or their theft. Examples of IS incidents are denial of service, information gathering, unauthorized access [2]. Fig. 2 presents the scheme, which shows that the incident includes such interacted elements as: the malefactor (malefactors); objectives which should be achieved, methods and tools that can be used, actions and objects on which these actions are directed. The scheme, produced by the authors of this paper, is valid if it is considered that an IS incident is a set of IS events which occur because of the malefactor. The agents of an incident realization can be not only people, but also processes, software and hardware failures, etc. In addition, incidents can happen through the fault of the perpetrators, who unlike the criminals do not have the purpose of obtaining unauthorized results and are responsible for the incidents, for example, due to lack of knowledge of IS rules and so on. gathering of the corresponding information and its proper use; summary of activities following the confirmation that an IS event is an IS incident; details of storage of the process documentation, including procedures; structure of IS incidents management in the organization; the list of the legal and normative acts being used and so on. Let's assume as a basis for ISIMP planning, development, implementation, operation, analysis, support and perfection the PDCA approach, called the process approach. An organization needs to identify and manage many activities in order to function effectively. Any activity using resources and managed in order to enable the transformation of inputs into outputs can be considered to be a process [1]. Often the output from one process directly forms the input to the next process. This approach focuses on achievement of stated goals and also on the resources that are needed for their achievement. Within the ISIMP the organization should identify and manage various actions. For example, the data received as a result of reaction to IS incident, are inputs for process of the given incident investigation. The diagram of IS incidents management process (fig.3) as seven subprocesses (with corresponding numbers) allocates: vulnerabilities, IS events and incidents (VEI) detection (1); VEI notification (2); VEI messages processing (3); reaction to IS incidents (4); IS incidents analysis (5); IS incidents investigation (6); ISIMP efficiency analysis (7). Figure 2. IS incident Thus, it can be concluded that an IS incident is very flexible and multi-dimensional concept. It should be a clear understanding of the concept for the classification of incidents on the basis of which responding to IS incidents will be carried out. 4. APPROACH TO ISIMP DEVELOPMENT The policy of IS incident management should be developed and implemented in any organization [2]. It should state: the importance of IS incident management for the organization and commitment of top management to support the process; Figure 3. IS incident management process diagram the review of procedures of IS events detection, alerts and notification about IS incidents; 95

5. «VULNERABILITIES, IS EVENTS AND IS INCIDENTS DETECTION AND NOTIFICATION» JOINT PROCESS Let s consider «VEI detection and notification» joint process in detail as an example. All employees of the organization, contractors and users from external organizations, using information systems and services of the organization, participate in this process. After getting any information on IS event or incident or detection of the suspicious situation, causing suspicion on IS incident or IT infrastructure vulnerability presence, everyone is obliged to inform on the given event via defined in advance communications. The diagram of the developed by the paper s authors process is shown at the fig.4. Figure 4. «Vulnerabilities, IS events and IS incidents detection and notification» process diagram It s necessary to notice that this subprocess can intensively use the existing Internet technologies especially during the vulnerability. There should be a base of sources of vulnerabilities that can be made by the use of Internet. Here the Internet acts as a source of potential IS incidents and events, but at the same time as a source of information for the vulnerability process. The process description is presented in table 1 (note: triggers are the events that start the process). Table 1. The process description Aims Triggers Criteria of performance Procedures and rules To detect atypical (suspicious) events that may lead to a breach of IS policies or previously unknown situations that may be critical for IS. - occurrence of events potentially affecting IS or unusual situations; - getting messages from safeguard tools, lifesupport systems, etc. - getting vulnerabilities - decisionmaking on further actions to the event (for example to transfer it to classification stage); - transfer of output data as an input to the following subprocess. - «Provision on roles for ISIMP»; - «Employee s instruction on ISIMP»; - «Procedure of detection, notification and reaction to IS incidents»; - other documents on IS (including IS policies). Tables 2 and 3 contain input and output data of the developed process correspondently. The detailed description of all subprocesses of the process is given in table 4. Other processes (VEI messages processing; reaction to IS incidents; IS incidents analysis; IS incidents investigation; ISIMP efficiency analysis) have been also developed by the authors in a similar way, but because of the paper size limits it is impossible to consider them in detail. Table 2. The process input data Input data Description Form Information on the event that potentially relates to IS. Information on potential IS event, which can potentially relate to IS. Vulnerabilities Decisionmaking Transfer as an input to the «VEI messages processing» process. Any information on events or situations, which can potentially relate to IS. Any information on the condition favorable to occurrence of events or situations, which can potentially relate to IS. Output data of the «IT infrastructure vulnerabilities management» process. In case of absence of that process the results of a periodic review of the organization s assets security scans. Table 3. The process output data Output Description data The message on VEI. Information which should be transferred as an input to the «VEI messages processing» process. Any form of representation. Any form of representation. A report on the results of vulnerabilities. Form The documented message in an electronic or printed form. Table 4. The subprocess description Subprocess Subprocess requirements Roles Detection of IS events organization and also contractors and users from external organizations, having access to resources of the organization, participate in detection of suspicious or potentially relating to IS events and situations. Inputs Attributes of suspicious events and situations. Outputs Information on event. All users of the organization, including all employees, contractors, users from the external organizations, having access to resources of the organization. 96

Table 4 (continued). The subprocess description Subprocess Subprocess requirements Roles IS events potential detection Analysis of vulnerabilities results Notification on VEI organization, and also contractors and users from external organizations, having access to resources of the organization, participate in revealing situations, which can potentially lead to IS event or IS incident. Inputs Attributes of potential IS events. Outputs Information on potential IS event. Responsibles (employees of the division, responsible for IT infrastructure maintenance) carry out analysis of IT infrastructure vulnerabilities results (analysis of results of assets security scans) and reveal assets vulnerabilities. Inputs - Reports on vulnerabilities Outputs - Information on vulnerabilities. organization, and also contractors and users from external organizations, having access to resources of the organization, inform about all IS events, potential IS events and vulnerabilities they know about. - - (as previous) Experts. All users of the organization, including all employees, contractors, users from the external organizations, having access to Message on VEI receipt Inputs - Information on IS event, potential IS event and vulnerabilities. Outputs The message on VEI. Responsibles receive the information on IS events, potential IS events, IS incidents or vulnerabilities. Then they document (either in an electronic or printed form) the received messages and transfer them as an input to the «VEI messages processing» process. Inputs The message on VEI. Outputs The documented message on VEI. assets of the organization. ISMS managers. 6. CONCLUSIONS The modern requirements and the best practices in the field of ISIMP are analyzed. To work out correct understanding of IS event and IS incident terms, being used for ISIMP, their analysis has been carried out. An approach to ISIMP development has been defined. According to this approach ISIMP processes are described. As an example the «Vulnerabilities, IS events and incidents detection and notification» joint process is examined in detail. Other processes (VEI messages processing; reaction to IS incidents; IS incidents analysis; IS incidents investigation; ISIMP efficiency analysis) have been also developed in a similar way. 7. REFERENCES [1] ISO/IEC 27001:2005 Information security management system. Requirements. [2] ISO/IEC TR 18044:2004 Information security incident management. [3] NIST SP 800-61 Computer security incident handling guide. [4] CMU/SEI-2004-TR-015 Defining incident management processes for CSIRT. 97