• No results found

Information Security Incident Management Process

N/A
N/A
Protected

Academic year: 2021

Share "Information Security Incident Management Process"

Copied!
5
0
0

Loading.... (view fulltext now)

Full text

(1)

Information Security Incident Management Process

Anna Kostina

The Moscow Engineering Physics

Institute (State University)

+7-903-586-45-47

formosa@mail.ru

Natalia Miloslavskaya

The Moscow Engineering Physics

Institute (State University)

Kashirskoe highway,31

Moscow, Russia

+7-495-323-90-84

milmur@mephi.edu

Alexander Tolstoy

The Moscow Engineering Physics

Institute (State University)

+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]:

• 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;

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.

(2)

• 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,

(3)

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.

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;

• the review of procedures of IS events detection, alerts and notification about IS incidents;

• 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).

(4)

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 monitoring. 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 monitoring 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, life-support systems, etc. - getting vulnerabilities’ monitoring results. - decision-making 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.

Any information on events or situations, which can potentially relate to IS.

Any form of representation. Information on potential IS event, which can potentially relate to IS.

Any information on the condition favorable to occurrence of events or situations, which can potentially relate to IS.

Any form of representation.

Vulnerabilities’ monitoring results.

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.

A report on the results of vulnerabilities monitoring.

Table 3. The process output data Decision-making Output data Description Form Transfer as an input to the «VEI messages processing» process. The message on VEI. Information which should be transferred as an input to the «VEI messages processing» process. The documented message in an electronic or printed form.

Table 4. The subprocess description

Subprocess Subprocess requirements Roles

Detection of IS events

All users of the 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 organi-zation, including all employees, contractors, users from the external organiza-tions, having access to resources of the organi-zation.

(5)

Table 4 (continued). The subprocess description

Subprocess Subprocess requirements Roles

IS events potential detection

All users of the 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. -“- (as previous) Analysis of vulnerabilities monitoring results Responsibles (employees of the division, responsible for IT infrastructure maintenance) carry out analysis of IT infrastructure

vulnerabilities monitoring results (analysis of results of assets security scans) and reveal assets’ vulnerabilities. Inputs - Reports on vulnerabilities monitoring results. Outputs - Information on vulnerabilities. Experts.

Notification on VEI All users of the 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. All users of the organi-zation, including all employees, contractors, users from the external organiza-tions, having access to Inputs - Information on IS event, potential IS event and vulnerabilities.

Outputs – The message

on VEI. assets of the organiza-tion. Message on VEI receipt

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. 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

References

Related documents

A statistically significant negative correlation was dem- onstrated in the study cohort between the maternal serum PIGF levels, foetal heart rate (FHR), birth weight and length,

Drivers with driving license for Class B (obtained before 1998) who drive ambulances, fire vehicles, vehicles for transportation of school children and taxis are obliged to undergo a

Respondent’s challenge is made on the sole ground that Respondent’s counsel had, in the past 2 years, worked closely in other cases with a different lawyer from the same law firm as

psychologists in Utah stay in the profession of school psychology and to explore measures that could be taken to encourage school psychologists to remain in the field until

Data obtained during the first years of field growth suggest that the rootstock propagation method did not seem to influence the field performance of fruit trees, since no

Web services need to be selected using appropriate interaction styles i.e., either Simple Object Access Protocol (SOAP) or Representational State Transfer Protocol (REST)

Support of BP MS 150 Recommended Training Rides – BP MS 150 Ride Marshals, wearing Ride Marshal apparel, must support in at least two BP MS 150 Spring Recommended Rides. Supporting

advancements?” through the lenses of telematics car insurances and the Finnish insurance market. What was found out was, that the slow-moving or traditional companies can feel