Information Security Incident Management Process
Information Security Incident Management ProcessAnna KostinaNatalia MiloslavskayaAlexander TolstoyThe Moscow Engineering PhysicsInstitute (State University) 7-903-586-45-47The Moscow Engineering PhysicsInstitute (State University)Kashirskoe highway,31Moscow, Russia 7-495-323-90-84The Moscow Engineering PhysicsInstitute (State University) mephi.eduABSTRACTThe modern requirements and the best practices in the field ofInformation Security (IS) Incident Management Process (ISIMP)are analyzed. “IS event” and “IS incident” terms, being used forISIMP, have been defined. An approach to ISIMP development hasbeen created. According to this approach ISIMP processes aredescribed. As an example the «Vulnerabilities, IS events andincidents detection and notification» joint process is examined indetail. detect, report and assess IS incidents, respond to IS incidents, including the activation ofappropriate safeguards for the prevention and reductionof, and recovery from, impacts, learn from IS incidents, institute preventive safeguards,and, over time, make improvements to the overallapproach to IS incident management.The decision of all these tasks can be obtained, if the organizationhas an implemented effective IS Incidents Management Process(ISIMP). It is extremely important, because ISIMP is one of basicparts of the general IS management system (ISMS) [1]. The data,that are accumulated within the given process, are necessary formany other ISMS’s processes, for example, for carrying out acorrect IS risks analysis or for efficiency assessment of existing ISmeasures and management processes. In relationship with other ISmanagement processes ISIMP can help to assess the overall level oforganization’s IS. All these benefits become even more valuablewhen the organization uses has distributed structure, as well aspartners all over the world and as a consequence uses the Internetand its intranet very actively, because the large amount of IS threatscomes from the Internet and internal intranet.ACM Categories & Subject DescriptorsH.4.m Information Systems, INFORMATION SYSTEMSAPPLICATIONS, Miscellaneous, BSPGeneral Terms: Management, SecurityKeywordsInformation Security, Incident Management, Information SecurityIncident, Information Security Event, Process Approach1. INTRODUCTIONDuring the period of globalization and the overall development ofInternet technology even the most advanced safeguards thatdecrease information security (IS) risks, for example, IS policy or anadvanced firewall, cannot completely prevent an occurrence ofevents in the information environment potentially bearing threats tobusiness of any organization.2. INTERNATIONAL DOCUMENTSREGULATING IS INCIDENTSMANAGEMENTAt the moment there are a sufficient number of internationaldocuments that regulate various aspects of IS incidentsmanagement. As a rule all these documents consistently considerall ISIMP stages: from process planning to its improvement after theanalysis the results of the process itself.The complexity and diversity of today's business activities, use ofthe Internet and intranets for communication and business taskspredetermine the presence of residual risks regardless of plannedand implemented countermeasures. Also, there is always a chanceof realization of new unknown IS threats. Insufficient preparationby an organization to deal with such incidents will make any actualresponse less effective, and potentially increase the degree ofpotential adverse business impact. Therefore it is essential for anyorganization that is serious about IS to have a structured andplanned approach to [1]:The Standard ISO/IEC 27001 “Information technology — Securitytechniques — Information security management systems —Requirements” contains the requirements for ISMS developmentregardless of its activities. ISO/IEC 27001 imposes some of thegeneral requirements to IS management processes, including ISIMPas its integral part. Among these requirements are the following [1]:Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specificpermission 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.93 the use of PDCA model (Plan – Do – Check – Act) [1] forprocesses’ planning and implementation, control andanalysis of these processes, and also improvement; proper documentation of processes and procedures; managementprocesses;commitmenttoallISmanagement
3. IS EVENT AND IS INCIDENTperiodic analysis and continual improvement of ISmanagement processes.But before proceeding to the definition of the goals of ISIMP andtasks that need to be addressed in order to achieve these goals, weare going to analyze the concepts of IS event and IS incident. Ingeneral, all of the documents observed above introduce thefollowing definition of IS event – an identified occurrence of asystem, service or network state indicating a possible breach of ISpolicy or failure of safeguards, or a previously unknown situationthat may be security relevant [1, 2].According to the “Monitor and review the ISMS” clause thefollowing 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 andincidents; help to detect security events and thereby prevent securityincidents by the use of indicators; determine whether the actions taken to resolve a breach ofsecurity were effective. enable management to determine whether the securityactivities delegated to people or implemented byinformation technology are performing as expected.In order IS event will take place, it is necessary that any actiondirected to any object has been accomplished (fig.1). Action shouldbe accomplished by the subject. The action directed to the objectshould have the certain result. It is important to understand that thisaction does not necessarily change the state of the object on which itis directed. For example if a user incorrectly enters his/her login orpassword, IS event takes place. The event is - the check of userlogin/password and his/her access right to the given account, hasfailed. An event represents some logic connection between asubject, an action and an object on which the given action isdirected, and some result of this action.In Annex A “Control objectives and controls” in section А.13 “ISincident management” the certain set of requirements is includedalso. These requirements are already more concrete and areascribed to separate stages of ISIMP.ISO/IEC TR 18044 “Information technology — Security techniques— Information security incident management” determines a formalISIMP model. ISIMP description, as well as in ISO/IEC 27001, isbased on the use of cyclic PDCA model. The document describesin detail the stages of planning and preparation, operation, analysisand improvement of ISIMP. The tasks of development andmaintenance of the process documentation are also taken intoconsideration. Recommendations on necessary resources andprocedures are also given.NIST SP 800-61 «Computer security incident handling guide»represents the collection of the best practices in the field ofconstruction 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 computersecurity incidents, is only its component. The process is examinedfrom initial planning to an incident analysis after the ending ofreaction process. Problems of reaction to different types ofcomputer security incidents are discussed in detail. This documentcan be used as a basis for creation of incident management plans forincidents that can be caused by the use of Internet technologies.Figure 1. IS eventDefined IS event does not make any distinction between authorizedand not authorized actions. Sometimes the events that are found outcan be a part of IS incident or simply relate to IS. For example, ifthe user correctly enters login/password, then he/she gets an accessto the given account. But it can appear that in this case there wasthe user spoofing (masquerade).In CMU/SEI-2004-TR-015 «Defining incident managementprocesses for CSIRT» the technique of planning, implementation,assessment and improvement of ISIMP is described. The mainattention is given to the organization of an IS incidents reactionteam work. The order of interaction of various participants’ rolesduring incident management processes is determined. The use of arole principle allows to allocate employees with additional dutieswithin the scope of ISIMP without a binding to their posts andofficial duties [1, 4]. It is stressed out that ISIMP can beimplemented in different ways depending on conditions in which itwill operate. The document is not the step-by-step instruction onISIMP development, implementation and improvement, but it givesa framework for development of the ISIMP.Sometimes the events that occur are parts of the steps taken by themalefactor, for any unauthorized result. These events can beconsidered as a part of IS incident. Thus IS incident is indicated bya single or a series of unwanted or unexpected IS events that have asignificant probability of compromising business operations andthreatening IS [1, 2].IS incidents can be deliberate or accidental (for example they can bea consequence of an error or the natural phenomenon) and can becaused both by technical and physical means. Their consequencescan be such events as not unauthorized changes of information,94
destruction of information or other events which make itinaccessible, as well as damage to the assets of the organization ortheir theft. Examples of IS incidents are denial of service,information gathering, unauthorized access [2].Fig. 2 presents the scheme, which shows that the incident includessuch 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. gathering of the corresponding information and its properuse; summary of activities following the confirmation that anIS event is an IS incident; details of storage of the process documentation, includingprocedures; structure of IS incidents management in the organization; the list of the legal and normative acts being used and soon.Let's assume as a basis for ISIMP planning, development,implementation, operation, analysis, support and perfection thePDCA approach, called the process approach. An organizationneeds to identify and manage many activities in order to functioneffectively. Any activity using resources and managed in order toenable the transformation of inputs into outputs can be considered tobe a process [1]. Often the output from one process directly formsthe input to the next process. This approach focuses on achievementof stated goals and also on the resources that are needed for theirachievement. Within the ISIMP the organization should identifyand manage various actions. For example, the data received as aresult of reaction to IS incident, are inputs for process of the givenincident investigation.The scheme, produced by the authors of this paper, is valid if it isconsidered that an IS incident is a set of IS events which occurbecause of the malefactor. The agents of an incident realization canbe not only people, but also processes, software and hardwarefailures, etc. In addition, incidents can happen through the fault ofthe perpetrators, who unlike the criminals do not have the purposeof obtaining unauthorized results and are responsible for theincidents, for example, due to lack of knowledge of IS rules and soon.The diagram of IS incidents management process (fig.3) as sevensubprocesses (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 incidentThus, it can be concluded that an IS incident is very flexible andmulti-dimensional concept. It should be a clear understanding ofthe concept for the classification of incidents on the basis of whichresponding to IS incidents will be carried out.4. APPROACH TO ISIMP DEVELOPMENTThe policy of IS incident management should be developed andimplemented in any organization [2]. It should state: the importance of IS incident management for theorganization and commitment of top management tosupport the process; the review of procedures of IS events detection, alerts andnotification about IS incidents;Figure 3. IS incident management process diagram95
Tables 2 and 3 contain input and output data of the developedprocess correspondently.5. «VULNERABILITIES, IS EVENTS ANDIS INCIDENTS DETECTION ANDNOTIFICATION» JOINT PROCESSThe detailed description of all subprocesses of the process is givenin table 4.Let’s consider «VEI detection and notification» joint process indetail as an example.Other processes (VEI messages processing; reaction to IS incidents;IS incidents analysis; IS incidents investigation; ISIMP efficiencyanalysis) have been also developed by the authors in a similar way,but because of the paper size limits it is impossible to consider themin detail.All employees of the organization, contractors and users fromexternal organizations, using information systems and services ofthe organization, participate in this process. After getting anyinformation on IS event or incident or detection of the suspicioussituation, causing suspicion on IS incident or IT infrastructurevulnerability presence, everyone is obliged to inform on the givenevent via defined in advance communications.Table 2. The process input dataInput dataThe diagram of the developed by the paper’s authors process isshown at the fig.4.DescriptionInformation onthe event thatpotentiallyrelates to IS.Any information on eventsor situations, which canpotentially relate to IS.Any form ofrepresentation.Information onpotential ISevent, whichcan potentiallyrelate to IS.Any information on thecondition favorable tooccurrence of events orsituations, which canpotentially relate to IS.Any form ts.Output data of the «ITinfrastructure vulnerabilitiesmanagement» process. Incase of absence of thatprocess the results of aperiodic review of theorganization’s assets securityscans.A report onthe results ofvulnerabilitiesmonitoring.Figure 4. «Vulnerabilities, IS events and IS incidents detectionand notification» process diagramIt’s necessary to notice that this subprocess can intensively use theexisting Internet technologies especially during the vulnerabilitymonitoring. There should be a base of sources of vulnerabilities thatcan be made by the use of Internet. Here the Internet acts as asource of potential IS incidents and events, but at the same time as asource of information for the vulnerability monitoring process.Table 3. The process output dataThe process description is presented in table 1 (note: triggers are theevents that start the process).Table 1. The process descriptionAimsTriggersTo detectatypical(suspicious)events thatmay lead toa breach ofIS policiesorpreviouslyunknownsituationsthat may becritical forIS.- occurrence ofeventspotentiallyaffecting IS orunusualsituations;- gettingmessages fromsafeguardtools, lifesupportsystems, etc.- a ofperformance- decisionmaking onfurther actionsto the event(for exampleto transfer it toclassificationstage);- transfer ofoutput data asan input to thefollowingsubprocess.FormProceduresand rules- «Provisionon roles forISIMP»;- «Employee’sinstruction onISIMP»; - «Procedureof detection,notificationand reaction toIS incidents»;- otherdocuments onIS (includingIS ransfer asan input tothe «VEImessagesprocessing»process.Themessageon VEI.Information whichshould be transferredas an input to the«VEI messagesprocessing» process.Thedocumentedmessage in anelectronic orprinted form.Table 4. The subprocess description96SubprocessSubprocess requirementsRolesDetection of ISeventsAll users of theorganization and alsocontractors and users fromexternal organizations,having access to resourcesof the organization,participate in detection ofsuspicious or potentiallyrelating to IS events andsituations.Inputs – Attributes ofsuspicious events andsituations.Outputs – Information onevent.All users ofthe organization,including allemployees,contractors,users fromthe externalorganizations, havingaccess toresources ofthe organization.
Table 4 (continued). The subprocess descriptionSubprocessSubprocess requirementsRolesIS events potentialdetectionAll users of theorganization, and alsocontractors and users fromexternal organizations,having access to resourcesof the organization,participate in revealingsituations, which canpotentially lead to IS eventor IS incident.Inputs – Attributes ofpotential IS events.Outputs – Information onpotential IS event.Responsibles (employeesof the division, responsiblefor IT infrastructuremaintenance) carry outanalysis of ITinfrastructurevulnerabilities monitoringresults (analysis of resultsof assets security scans)and reveal assets’vulnerabilities.Inputs - Reports onvulnerabilities monitoringresults.Outputs - Information onvulnerabilities.All users of theorganization, and alsocontractors and usersfrom externalorganizations, havingaccess to resources of theorganization, informabout all IS events,potential IS events andvulnerabilities they knowabout.-“(as previous)Analysis ofvulnerabilitiesmonitoringresultsNotification on VEIMessage on VEIreceiptExperts.Inputs - Information onIS event, potential ISevent and vulnerabilities.Outputs – The messageon VEI.Responsibles receive theinformation on IS events,potential IS events, ISincidents or vulnerabilities.Then they document(either in an electronic orprinted form) the receivedmessages and transferthem as an input to the«VEI messagesprocessing» process.Inputs – The message onVEI.Outputs – Thedocumented message onVEI.assets of theorganization.ISMSmanagers.6. CONCLUSIONSThe modern requirements and the best practices in the field ofISIMP are analyzed. To work out correct understanding of “ISevent” and “IS incident” terms, being used for ISIMP, their analysishas been carried out. An approach to ISIMP development has beendefined. According to this approach ISIMP processes are described.As an example the «Vulnerabilities, IS events and incidentsdetection and notification» joint process is examined in detail.Other processes (VEI messages processing; reaction to IS incidents;IS incidents analysis; IS incidents investigation; ISIMP efficiencyanalysis) have been also developed in a similar way.All users ofthe organization,including allemployees,contractors,users fromthe externalorganizations, havingaccess to7. REFERENCES[1] ISO/IEC 27001:2005 Information security managementsystem. Requirements.[2] ISO/IEC TR 18044:2004 Information security incidentmanagement.[3] NIST SP 800-61 Computer security incident handling guide.[4] CMU/SEI-2004-TR-015 Defining incident managementprocesses for CSIRT.97
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
Incident Management Process Map 1. Incident Management Process Map 1. Incident Management Description and Goals 9. Incident Management Description and Goals 9. Description 9. Description 9. Goals 9. Goals 9. Incident Management RACI Information 10. Incident Management RACI Information 10. Incident Management Associated Artifacts Information 24
Incident handling requires people, process and technology. 36 Security Operation Centers Well-Defined Methodology ISO/IEC 27035:2011 Information technology -- Security techniques -- Information security incident management ards ENISA Good Practice Guide for Incident Management NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide
planning, incident mitigation, and resource availability. The Incident Management Program is structured to assist the system entities, as well as provide a well- rounded incident management platform. e. System Incident Management Oversight and Authorities The System Incident Management staff is comprised of a Division of the Corporate Security
Incident*Management*Process - Investigate*&*Diagnose Process: Incident Management Activity: 3.0 Investigate & Diagnose Predecessors Incident Coordinator Incident Support Data Inter/Intra Process Annotation INC 3.1 Accept assignment INC 2.9 Escalate INC 3.2 Acknowledge Assignment INC 3.3 Acquire additional information if required
An AHIMT3 may be embed into an existing AHJ incident management structure, establish and oversee an incident management structure for the AHJ, or provide transitional incident management support to the AHJ prior to arrival of a Type 1 or Type 2 Incident Management Team. Qualifications/Selection of Team Members . Training Requirements
The IMF defines FSS's approach to incident and crisis management, the structures and teams that are in place to manage an incident, and provides an overview of how the Operational Incident Team (OIT) and Strategic Incident Team (SIT) will operate in different classifications of incident. -
7 2 Incident Management 2.1 Pre-requisites tobefore Raising an Incident DCC 2.1.1 Before raising an Incident the DCC shall use all reasonable endeavours to ensure an Incident does not already exist for the issue. 2.1.2 Pursuant to Section E2.12(d), prior to the DCC raising an Incident regarding the provision of Registration Data by a Registration Data Provider, the DCC
Data Security Breaches / Incident Investigation Process Staff must follow GMSS’s process for incident reporting which includes any data security breaches / incidents. All data security breaches / incidents must be reported initially to GMSS IG Lead / DPO / IG Team AS SOON AS THIS INCIDENT IS KNOWN
