1

Chapter 4—Information Security Incident Management

2
Chapter 4—Information Security Incident Management

This chapter reviews the essential knowledge necessary to establish an

effective program to respond to and subsequently manage incidents that
threaten an organization’s information systems and infrastructure.

3
Incident Management Overview

4
4.1 Incident Management Overview

 Incident management is a term that includes incident detection, incident

response and port-incident review.

 The purpose of incident management and response is to identify and

respond to unexpected disruptive events with the objective of controlling
impacts within acceptable levels.

 Incident management serves as the next-to-last safety net after controls

have failed to prevent or contain a threatening event. Its purpose is to
respond to and contain a threatening incident or to quickly restore normal
operations in the event of damage. Failing to do so will result in the
declaration of a disaster and recovery operations.

5
4.1 Incident Management Overview

 Effective incident management: ensures that incidents are detected,

recorded and managed to limit impacts.
 Recording incidents is required to ensure that:
 no aspect of an incident is overlooked,
 incident response activities can be tracked,
 information can be provided to aid planning activities.
 properly document forensics data that can be used to pursue legal
options.

 Incidents must be classified to ensure that they are correctly prioritized

and routed to the correct resources.

 Incident management provides a structure by which incidents can be

investigated, diagnosed, resolved and then closed.

 Major incidents require a response beyond that provided by the normal

incident process and may require activating BCP/DR.
6
4.1 Incident Management Overview

 Incident handling: involves the following processes / tasks:

 Detection and reporting: the ability to receive and review event

information, incident reports, and alerts.

 Treating: the action taken to categorize, prioritize and assign events

and incidents.

 Analysis: the attempt to determine what has happened, the impact

and threat, the damage that has resulted, and the recovery or
mitigation steps that should be followed.

 Incident response: the action taken to resolve or mitigate an incident,

coordinate and disseminate information, and implement follow-up
strategies to prevent recurring incidents.

7
4.1 Incident Management Overview

 Events:
 Technical, such as network attacks via viruses, denial of service (DoS)
or system intrusion. The result of mistakes, accidents, or system or
process failure.
 Physical events, such as theft of proprietary information, social
engineering, lost or stolen backup tapes or laptops.
 Environmental conditions such as floods, fires, or earthquakes.

8
4.1 Incident Management Overview

 Incident management, problem management and disaster recovery

planning, are separate but complementary processes.

 The objective is to prevent incidents from becoming problems and to

prevent problems from becoming disasters.

 Incident: any unplanned event that causes, or may cause, a disruption or

interruption to service delivery or quality.

 Problem: the root cause of one or more incidents, events, alerts or

situations.

 Typically the information security manager is the first responder to

information security related incidents, regardless of the causes.

9
4.1 Incident Management Overview
 The goal of incident management and response activities are to:
 Detect incidents quickly
 Diagnose incidents accurately
 Manage incidents properly
 Contain and minimize damage
 Restore affected services
 Determine root causes
 Implement improvements to prevent recurrence
 Document and report

 It is critical to achieve senior management support for an effective incident

management capability, via developing a business case or results of prior
incidents

 Incident management and response can be part of the trade-off that may
reduce the cost of risk management efforts by allowing higher levels of
acceptable risk
10
4.1 Incident Management Overview

Incident management systems

1. Distributed incident management system: such as network incident
detection systems (NIDSs), host intrusion detection systems (HIDSs) and
server/appliance logs.

2. Centralized incident management system: Security Information and Event

Manager (SIEM). Combines critical events and logs from different systems
and correlates them into more meaningful incident information.
Prioritizing incidents based on their business impacts. Performing specific
notifications/escalations based on the impact ratings.

11
4.1 Incident Management Overview
 Responsibilities of information security manager towards incident
management include:
o Developing information security incident management and response
plans.

o Handling and coordinating information security incident response

activities effectively and efficiently.

o Validating, verifying and reporting of countermeasure solutions, both

technical and administrative.

o Planning, budgeting and program development for all matters related

to information security incident management and response.

12
Incident Management Resources

13
4.2 Incident Management Resources

 Resources required for the development of an incident management plan

should be identified and utilized. Example of resources include:
1. Policies and standards.
2. Personnel.
3. Roles and responsibilities.
4. Skills.
5. Awareness and education.
6. Audits.
7. Outsourced security providers.

14
4.2 Incident Management Resources

1. Policies and standards:

 The incident response plan must be backed by well-defined policies,
standards and procedures, in order to:
 Ensure that incident management activities are aligned with the
Incident Management Team (IMT) mission.
 Set correct expectations.
 Provide guidance for operational needs.
 Maintain consistency and reliability of services.
 Roles and responsibilities are clearly understood.
 Set requirements for identified alternates for all important functions.

15
4.2 Incident Management Resources

2. Personnel:
2.1 An Incident Management Team (IMT) usually consists of:
 The information security manager.
 Security Steering Group (SSG): senior managers responsible for
approving the charter and serves as an escalation point for the IMT.
 Permanent/dedicated team members: may include incident handlers,
investigators and forensics experts, and IT and physical security
specialists.
 Virtual/temporary team: normally consist of business representatives
(middle management), legal staff, communications staff (public
relations), HR staff, other security groups (physical security), risk
management and IT specialists. Requited when necessary to fill gaps
within the IMT.

16
4.2 Incident Management Resources

2.2 Incident Response Team (IRT) are incident handlers who analyze
incident data, determine the impact of the incident, and act
appropriately to limit the damage to the organization and restore
normal services.

IRT models include:

 Central IRT: a single IRT handles all incidents for the organization,
usually in a small organization.

 Distributed IRT: several teams responsible for a logical or physical

segment of the infrastructure, usually in large organization.

 Coordinating IRT: central team provides guidance to distributed

IRTs, develop policies and standards, provide training, conduct
exercises, and coordinate or support response to specific incidents.

 Outsourced IRT: fully or partially outsourced teams.

17
4.2 Incident Management Resources
4. Skills:
 Personal skills:
 Communication.
 Leadership skills.
 Presentation skills.
 Ability to follow policies and procedures.
 Team skills.
 Integrity.
 Self understanding.
 Coping with stress.
 Problem solving.
 Time management.

 Technical skills:
 Technical foundation skills.
 Incident handling skills.

18
4.2 Incident Management Resources
5. Awareness and education:
 Organizations may develop relationships with external experts to fill the
gap in internal expertise.

 Organization may need to expand the staff’s basic skills to include more
in-depth knowledge to handle incidents properly.

6. Audits:
 Internal and external audits are performed to verify compliance with
policies, standards and procedures.

 Audits provide an objective view of the overall completeness and

functionality of the incident management and response plans and
provide assurance that major gaps in the processes do not exist.

19
4.2 Incident Management Resources
7. Outsourced security providers:
 Outsourcing incident management capability may be a cost-effective
option for an organization.

 For example, organizations that have outsourced their information

technology operations may benefit from close integration if incident
management is outsourced to the same vendor.

 However, organizations would still require an incident response plan

overseen by an IRT.

20
Incident Management Objectives

21
4.3 Incident Management objectives

1. Defining objectives.
2. The desired state.
3. Strategic alignment.
4. Risk management.
5. Assurance process integration.
6. Value delivery.
7. Resource management.

22
4.3 Incident Management objectives

1. Defining objectives
 Handle incidents when they occur so that the exposure can be
contained/eradicated within an AIW.

 Prevent previous incidents from recurring by documenting and

learning from past incidents.

 Deploy proactive countermeasures to prevent/minimize the

probability of incidents from taking place.

Acceptable Interruption window (AIW): the time the company can wait
from the point of failure to the restoration of the minimum and critical
services or applications. After this time, the progressive losses caused by
the interruption are excessive for the organization.

23
4.3 Incident Management objectives

2. The desired state

 Incident management must effectively address a wide range of possible
unexpected events.

 It will need to have well-developed monitoring capabilities for key

controls, to provide early detection of potential problems.

 It will have personnel trained in incident handling and response

procedures.

 Capturing all relevant information and apply previously learned lessons.

24
4.3 Incident Management objectives

3. Strategic alignment
 Incident management must be aligned with the organization’s strategic
plan.

4. Risk management
 Successful outcomes of risk management include effective incident
management and response capabilities.

 Any risk that is not prevented by controls will constitute an incident that
must be managed and responded to with the intent that it does not
escalate into a disaster.

25
4.3 Incident Management objectives

5. Assurance process integration

 Incident management will often require the involvement of a number of
other organizational assurance functions (physical security, legal, HR,
others), in addition to the information security manager.

 An effective outcome defines which departments are involved in various

incident management and response activities.

6. Resource management
 Resource management includes time, people, budget and other factors to
achieve objectives efficiently under given resource constraints.

 Incident management and response activities consume resources that

must be managed to achieve optimal effectiveness, through prioritization.

26
4.3 Incident Management objectives

7. Value delivery
 To deliver value, incident management should:
 Integrate with business processes and structures as seamlessly as
possible.

 Improve the capability of businesses to manage risk and provide

assurance to stakeholders.

 Integrate with BCP.

 Become part of an organization’s overall strategy and effort to protect

and secure critical business function and assets.

 Optimize risk management efforts.

27
Incident Management Metrics and Indicators

28
4.4 Incident Management Metrics and Indicators

 Incident management metrics, measures and indicators are the criteria used
to measure the effectiveness and efficiency of the incident management
function.

 Incident management reports and measures should be presented to senior

management as a basis of justification of continuous support and funding.

 Incident management reports and measures are useful for the IMT for self-
assessment.

 Examples:
 Total number of reported incidents.
 Total number of detected incidents.
 Average time to respond to an incident relative to the AIW.
 Average time to resolve an incident.
 Total number of incidents successfully resolved.
 Total damage from reported and detected incidents if incident
response was not performed. 29
Developing an Incident Response Plan

30
4.5 Developing an Incident Response Plan

 The incident management action plan is also known as the incident

response plan (IRP).

 The IRP details the actions, personnel and activities that take place in case
of adverse events.

 There are a number of approaches to developing the IRP (such as

approaches developed by CMU/SEI, SANS Institute, NIST).

 The following are key elements to develop IRP:

1. Gap analysis.
2. Business impact assessment.
3. Escalation process for effective incident management.
4. Help desk processes for identifying security incidents.
5. Incident management and response teams.
6. Organization, training and equipping the response staff.
7. Incident notification process.
31
4.5 Developing an Incident Response Plan

1. Gap analysis (Basis for developing an IRP)

 To resolve the gap between current incident response capabilities
compared with the desired level.

 Gap analysis report can be used for planning purposes to determine the
following:
 Processes that need to be improved to be more efficient and
effective.
 Resources needed to achieve the objectives for the incident
response capability.
 Prioritize efforts of improvement based on the areas of greatest
potential impact and the best cost benefit.

32
4.5 Developing an Incident Response Plan
2. Business Impact Assessment
 BIAs have three primary goals:
 Criticality prioritization: every critical business unit process must be
identified and prioritized. The impact of an incident must be
evaluated — the higher the impact, the higher the priority.

 Downtime estimation: estimate the maximum tolerable downtime

(MTD) - the longest period of unavailability of critical
processes/services/information assets before the company may
cease operation.

 Resource requirement: resource requirements for critical processes,

with the most time-sensitive and highest-impact processes receiving
the most resource allocation.

33
4.5 Developing an Incident Response Plan

 Benefits of conducting a BIA:

 Increasing the understanding of the amount of potential loss that
could occur from certain types of incidents.

 Facilitating all response management activities.

 Raising the level of awareness for response management within an

organization.

34
4.5 Developing an Incident Response Plan
3. Escalation process for effective incident management
 A detailed description of the escalation process should be documented.

 For every event, a list of actions should be described with the

responsible person and the estimated time for execution.

 If the accumulated elapsed time reaches a predetermined limit, the

emergency status may change to an alert condition (low, medium, high).

 Alert notification may include senior management, response and

recovery teams, HR, insurance companies, backup facilities, the public,
shareholders and stakeholders, legal counsel, vendors and customers.

35
4.5 Developing an Incident Response Plan
4. Help desk processes for identifying security incidents
 Processes should be defined for help desk personnel to distinguish a
typical help desk request from a possible security incident.

 The help desk is likely to receive the first reports indicating a security-
related problem, thus prompt recognition of an incident and escalation
to appropriate parties is critical to minimizing the damage.

 Improving the awareness of help desk personnel, will enhance security

incident detection and reduce the risk that the help desk could be
successfully targeted in a social-engineering attack.

 Help desk personnel should be aware of the proper procedures to report

and escalate a potential issue.

36
4.5 Developing an Incident Response Plan
5. Incident management and response teams
 IRP must identify teams and define their assigned responsibilities in the
event of an incident. Examples:
 Emergency action team: Designated “fire wardens” and “bucket
crews” whose function is to deal with fires or other emergency
response scenarios.

 Damage assessment team: Qualified individuals who assess the extent

of damage to physical assets and make an initial determination
regarding what is a complete loss vs. what is restorable or salvageable.

 Emergency management team: Responsible for coordinating the

activities of all other recovery teams and handling key decision making.

 Relocation team: Responsible for coordinating the process of moving

from the hot site to a new location or to the restored original location.

37
4.5 Developing an Incident Response Plan
 Security team: Often called a computer security incident response
team, it is responsible for monitoring the security of systems and
communication links, containing any ongoing security threats, resolving
any security issues that delay the recovery of the systems, and assuring
the proper installation and functioning of every security software
package.

38
4.5 Developing an Incident Response Plan
5. Organization, training and equipping the response staff
 Training the response teams includes developing event scenarios and
test the response and recovery plans to ensure that teams are familiar
with their tasks and responsibilities.

 IMT members should undergo the following training programs:

 Induction to the IMT: provide the essential information required to be
an effective IMT member.

 Mentoring team members regarding roles, responsibilities and

procedures: pairing new members with experienced members.

 On-the-job training: provide an understanding of company policies,

standards, procedures, available tools and applications, acceptable
code of conduct, etc.

 Formal training: to attain an adequate level of competence necessary

to support the overall incident management capability.
39
4.5 Developing an Incident Response Plan
6. Incident notification process
 Having an effective and timely security incident notification process is a
crucial to help the organization to respond quickly and efficiently.

 Mechanisms could be in place that enable an automated detection

system to send emails or phone messages to designated personnel.

 Risk management, HR, legal, public relations and network operations are
the most likely functions to be notified in case of an incident.

 Notification activities are effective only if knowledgeable personnel

understand their responsibilities and perform them in an efficient and
timely manner.

 Such responsibilities can be documented in employee’s job descriptions.

40
4.5 Developing an Incident Response Plan
Challenges in developing an incident management plan

 Lack of management buy-in and organizational consensus.

 Mismatch to organizational goals and structure.

 IMT member turnover.

 Lack of communication process.

 Complex and wide plan.

41
Business Continuity and Disaster Recovery Procedures

42
4.6 Business Continuity and Disaster Recovery Procedures

Disaster Recovery and Business Recovery

 Disaster recovery (DR) has traditionally been defined as the recovery of IT
systems after disruptive events such as hurricanes and floods.

 Business recovery is defined as the recovery of the critical business

processes necessary to continue or resume business operations. Business
recovery includes disaster recovery, as well as all other required operational
aspects.

 An effective strategy for recovery plans will strike the most cost-effective
balance between risk management efforts, incident management and
response, and BC/DRP.

 Disaster declaration criteria must be defined to determine when an incident

cannot be resolved by the available recovery processes and a disaster must
be declared.

43
4.6 Business Continuity and Disaster Recovery Procedures

Recovery sites (offsite backup facilities)

 The most appropriate alternative recovery site must be based on

probability, BIA, risk tolerance of management and cost.

 Types of recovery sites includes:

 Hot site:
 Fully configured with equipment, network and systems software
compatible with the primary installation .
 The only additional needs are staff, programs, data files and
documentation.
 Ready to operate within several hours.
 Cost is high.

44
4.6 Business Continuity and Disaster Recovery Procedures

 Warm sites:
 Complete infrastructures, but are partially configured in terms of IT,
usually with network connections and essential peripheral
equipment such as disk drives, tape drives and controllers.
 Sometimes a warm site is quipped with a less-powerful central
processing unit (CPU) than the primary site.
 The installation of missing units as computers, may take days or
weeks.
 Is less costly than a hot site.

 Cold sites:
 Have only the basic environment (electrical wiring, air conditioning,
flooring, etc.).
 The cold site is ready to receive equipment, but does not offer any
components at the site in advance of the need.
 Activation of the site may take several weeks.
 Portable centers belong to this category.
45
4.6 Business Continuity and Disaster Recovery Procedures

 Mobile sites:
 Specially designed trailers that can be quickly transported to a
business location or an alternate site to provide a ready-conditioned
IPF.
 Can be configured with servers, desktop computers,
communications equipment, and even microwave and satellite data
links.
 They are a useful alternative when there are no recovery facilities in
the immediate geographic area.
 They are also useful in case of a widespread disaster and may be a
cost-effective alternative for duplicate IPFs for a multisite
organization.

46
4.6 Business Continuity and Disaster Recovery Procedures

Methods for providing continuity of network services

 Redundancy:
 Providing extra capacity with a plan to use the surplus capacity should
the normal primary transmission capability not be available.
 Providing multiple paths between routers.
 Using special dynamic routing protocols.
 Providing for failover devices to avoid single point of failures in routers,
switches, firewalls, etc.
 Saving configuration files for recovery of network devices in the event
they fail.

47
4.6 Business Continuity and Disaster Recovery Procedures

 Alternative routing:
 Alternative routing means routing information via an alternate medium
such as copper cable or fiber optics.
 This involves use of different networks, circuits or end points, if the
normal network is unavailable.
 Dial-up circuits as an alternative to dedicated circuits, a cellular phone
and microwave communications as alternatives to land circuits, and
couriers as an alternative to electronic transmissions.

48
4.6 Business Continuity and Disaster Recovery Procedures
High-availability considerations
 Server recovery should also be included in the disaster recovery plan.

 Redundant Array of Inexpensive Disks (RAID) provides performance

improvements and fault-tolerant capabilities via hardware or software
solutions, breaking up data and writing them to a series of multiple disks.

 A Storage Area Network (SAN) is a high-speed, special-purpose network that

provides mass storage using remote interconnected devices, such as disk
arrays, tape libraries or optical jukeboxes, with associated servers that
function as if they were attached locally.

 Fault-tolerant servers provide for fail-safe redundancy through mirrored

images of the primary server, including distributed processing of a server
load “load balancing” or “clustering,” where all servers take part in
processing.

49
4.6 Business Continuity and Disaster Recovery Procedures
Insurance
 The recovery plan should also contain key information concerning the
organization’s insurance.

 Specific types IS insurance coverage include:

 IT equipment and facilities: Provides coverage of physical damage to
the IPF and owned equipment.
 Media (software) reconstruction: Insurance is available for on-
premises, off-premises or in-transit disasters and covers the actual
reproduction cost of the property.
 Extra expense: Extra costs of continuing operations following damage
or destruction at the IPF. Extra expense can cover the loss of net profits
caused by computer media damage.
 Business interruption: Covers the loss of profit due to the disruption of
the activity of the company caused by any covered IT malfunction or
security-related event.

50
4.6 Business Continuity and Disaster Recovery Procedures
 ISM should test the Business Continuity and Disaster Recovery Procedures

 Types of tests:
 Checklist review: A preliminary step to a real test. Recovery checklists
are distributed to all members of a recovery team to review and ensure
that the checklist is current.
 Structured walkthrough: Team members physically implement the
plans on paper and review each step to assess its effectiveness, identify
enhancements, constraints and deficiencies.
 Simulation test: The recovery team role play a prepared disaster
scenario without activating processing at the recovery site.
 Parallel test: The recovery site is brought to a state of operational
readiness, but operations at the primary site continue normally.
 Full interruption test: Operations are shut down at the primary site and
shifted to the recovery site in accordance with the recovery plan; this is
the most rigorous form of testing, but is expensive and potentially
disruptive.
51
4.6 Business Continuity and Disaster Recovery Procedures
Recovery test metrics
 Metrics should be developed and used in measuring the success of the plan
and testing against the stated objectives.

 Metrics results should be used not only to measure the effectiveness of the
plan, but more importantly, to improve it.

 Types of metrics usually apply:

 Time: Elapsed time for completion of prescribed tasks, delivery of
equipment, assembly of personnel and arrival at a predetermined site.

 Amount: Amount of work performed at the backup site by clerical

personnel and the amount of information systems processing
operations.

52
4.6 Business Continuity and Disaster Recovery Procedures
 Percentage and/or number:
 The number of vital records successfully carried to the backup site
versus the required number.
 The number of supplies and equipment requested versus actually
received.
 The number of critical systems successfully recovered can be
measured with the number of transactions processed.

 Accuracy:
 Accuracy of the data entry at the recovery site versus normal
accuracy (as a percentage).
 The accuracy of actual processing cycles by comparing output
results with those for the same period processed under normal
conditions.

53
Post-Incident Activities and Investigation

54
4.7 Post-Incident Activities and Investigation

 The follow-up process in incident response is potentially the most valuable

part of the effort.

 Lessons learned during incident handling can improve a security practice as

well as the incident response process itself.

 The information security manager needs to calculate the cost of the

incident, by adding the cost of any loss or damage plus the cost of labor and
any special software or hardware needed to handle the incident.

55
4.7 Post-Incident Activities and Investigation

Documenting events
 There should be a clear record of events, so information be investigated and
provided to a forensics team or authorities if necessary.

 Information security manager should ensure that potential or actual

evidence is not changed, modified or contaminated.

 Trained computer forensics personnel can inspect computer systems that

have been hacked, if they were not removed or contaminated.

 The initial response by the system administrator should include:

 Retrieving information needed to confirm an incident.
 Identifying the scope and size of the affected environment (e.g.,
networks, systems, applications).
 Determining the degree of loss, modification or damage (if any).
 Identifying the possible path or means of attack.

56
4.7 Post-Incident Activities and Investigation

Legal aspects of forensic evidence

 The required documentation to maintain legally admissible evidence must
include:
 Chain of custody forms that include:
 Name and contact information of custodians.
 When, why and by whom an evidence item was acquired or moved.
 Detailed identification of the evidence (serial numbers, model
information, etc.).
 Where it is stored (physically or logically).
 When/if it was returned.

 Checklists for acquiring technicians (including details of legally

acceptable forensic practices).

 Detailed activity log templates for acquiring technicians.

57
4.7 Post-Incident Activities and Investigation

 Signed nondisclosure/confidentiality forms for all technicians involved in

recovering evidence.

 An up-to-date case log that outlines:

 Dates when requests were received
 Dates investigations were assigned to investigators
 Name and contact information investigator and requestor
 Identifying case number
 Basic notes about the case and its requirements and completed
procedures
 Date when completed

58
4.7 Post-Incident Activities and Investigation

 Investigation report templates that include:

 Name and contact information of investigators
 Date of investigation and an identifying case number
 Details of any interviews or communications with management or
staff regarding the investigation
 Details of devices or data that was acquired (serial numbers,
models, physical or logical locations)
 Details of software or hardware tools used for acquisition or
analysis (these must be recognized forensically sound tools)
 Details of findings including samples or copies of relevant data
and/or references to their storage location
 Final signatures of investigator in charge

59
60