NATIONAL INFORMATION SECURITY FRAMEWORK (NISF) PUBLICATION

_______________________________________________________________

Security Standard No. 6

Incident Management
______________________________________

OFFICIAL

Version History

No.

Date

Section

Amendment

1.0

08/01/2014

Draft

Initial draft for NITA-U consideration

OFFICIAL

Table of Contents
1

Introduction .................................................................................................................................... 6
1.1
1.2
1.3

Incident Response Planning and Preparation ............................................................................ 9

2.1
2.2
2.3
2.4
2.5
2.6

Aims of the Standard ................................................................................................................ 6

Incident Management Concepts ............................................................................................... 6
References ............................................................................................................................... 7

Incident Management Policy .................................................................................................... 9

Integration with other Policies ................................................................................................... 9
Incident Management Scheme ............................................................................................... 10
Technical and other Support .................................................................................................. 10
Awareness, Education and Training ....................................................................................... 11
Cyber Drills ............................................................................................................................. 11

Incident Management Roles and Responsibilities ................................................................... 13

3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8

Board of Directors and Accounting Officer ...................................................................... 13

Chief Information Risk Owner (CIRO) ............................................................................. 13
Chief Information Security Officer ................................................................................... 13
Information Security Incident Response Team (ISIRT) .................................................. 13
Security Manager/ISIRT Leaders .................................................................................... 14
Security Analysts/ISIRT Analysts .................................................................................... 14
Internal Dependencies .................................................................................................... 14
External Dependencies ................................................................................................... 15

Incident Identification and Categorisation ................................................................................ 18

4.1
Benefits of Incident Categorisation ......................................................................................... 18
4.1.1
Categories of Security Incidents...................................................................................... 18
4.2
Incident Severity Levels or Ratings ........................................................................................ 19
4.2.1
Functional Impact of the Incident .................................................................................... 20
4.2.2
Information Impact of the Incident ................................................................................... 20
4.2.3
Recoverability from the Incident ...................................................................................... 20
4.2.4
Combining Functional, Information and Recoverability ................................................... 21
4.2.5
Incident Severity Levels and Escalation Criteria ............................................................. 22

Incident Management Process ................................................................................................... 24

5.1
ISO/IEC 27035 Incident Management Phases ....................................................................... 24
5.1.1
Plan and Prepare ............................................................................................................ 24
5.1.2
Detection and Reporting .................................................................................................. 24
5.1.3
Assessment and Decision ............................................................................................... 24
5.1.4
Responses ....................................................................................................................... 24
5.1.5
Lessons Learnt ................................................................................................................ 24
5.2
NIST SP 800-61 Rev 2 Incident Management Phases .......................................................... 25
5.2.1
Preparation ...................................................................................................................... 25
5.2.2
Detection and Analysis .................................................................................................... 25
5.2.3
Containment, Eradication & Recovery ............................................................................ 25
5.2.4
Post-Incident Activities .................................................................................................... 26

NISF Incident Management Process .......................................................................................... 26

6.1
6.2
6.3
6.4
6.5

Detect and Analyse................................................................................................................. 26

Begin Notification .................................................................................................................... 26
Setup Communications .......................................................................................................... 27
Contain ................................................................................................................................... 27
Identify .................................................................................................................................... 27
3

OFFICIAL

6.6
6.7
6.8

Security Incident Record ........................................................................................................ 28

Return to Operations .............................................................................................................. 29
Document and Review............................................................................................................ 29

OFFICIAL

Table of Figures
Figure 1 Categories of information security incidents according to threats ....................................... 19
Figure 2 NISF Functional Impact Categories ..................................................................................... 20
Figure 3 NIST Information Impact Categories ................................................................................... 20
Figure 4 NIST Recoverability Effort Categories ................................................................................. 21
Figure 5 Business Impact Levels ....................................................................................................... 21
Figure 6 Security Incident Severity Levels and Escalation Criteria ................................................... 22
Figure 7 NIST Incident Response Life Cycle ..................................................................................... 25

Introduction
This Standard presents the official Government of Uganda (GoU) approach for
managing information security incidents. In keeping with US ISO/IEC 27035, the
Standard covers the processes for detecting, assessing, reporting, responding to
and learning from security incidents. According to US ISO/IEC 27035, the term
information security incident management encompasses the management of
information security incidents and information security vulnerabilities.

1.1

Aims of the Standard

This Standard is for individuals with responsibility for incident management in the
organisations that own and/or operate critical information infrastructure (CII).
This Standard uses the term CII interchangeably with protected computer the
official definition in the Computer Misuse Act, 2011. The Standard aims to help
organisations reduce the likelihood and impact of security incidents. It also seeks
to facilitate a quick resumption of business activities after a security incident. The
National Institute of Standards and Technology (NIST) warns that performing
incident response effectively is a complex undertaking. As a result, NIST states
that successful incident response requires substantial planning and resources.

1.2

Incident Management Concepts

This Standard uses the terms and definitions contained in US ISO/IEC 27035. In
turn, ISO/IEC 27000:2009 is the source of the definitions in US ISO/IEC 27035.

1.2.1.1

Information Security Forensics

The term refers to the application of investigation and analysis techniques to
capture, record and analyse information security incidents.

1.2.1.2

Information Security Incident Response Team (ISIRT)

The term refers to a team of appropriately skilled and trusted members of the
organisation that handles information security incidents during their lifecycle.
This Standard uses ISIRT synonymously with Computer Emergency Response
Team (CERT), Computer Security Incident Response Team (CSIRT) and
Computer Incident Response Team (CIRT1). Although these and similar named
organisations serve in the incident management domain, US ISO/IEC 27035
notes that their scope and purposes differ.

The International Telecommunication Union (ITU) adopted the term CIRT in Resolution 58 of its World
Telecommunication Standardization Assembly (WTSA) held in Johannesburg, South Africa, 21-30 October 2008.

OFFICIAL

1.2.1.3

Information Security Event

This is an identified occurrence of a system, service or network state indicating a
possible breach of information security, policy or failure of controls, or a
previously unknown situation that may be security relevant.

1.2.1.4

Information Security Incident

This is a single or a series of unwanted or unexpected information security
events that have a significant probability of compromising business operations
and threatening information security.

1.3

References
This Standard references the following publications:
i.

ISO/IEC (2005a), US ISO/IEC 27001: 2005 - Information Technology

Security Techniques Information Security Management Systems
Requirements, International Standards Organization (ISO)/International
Electrotechnical Commission (IEC), Geneva, Switzerland.

ii.

ISO/IEC (2011a), US ISO/IEC 27002: 2011 - Information Technology

Security Techniques Code of Practice for Information Security
Management, International Standards Organization (ISO)/International
Electrotechnical Commission (IEC), Geneva, Switzerland.

iii.

ISO/IEC (2011e), US ISO/IEC 27035: 2011 - Information Technology

Security Techniques Information Security Incident Management,
International Standards Organization (ISO)/International Electrotechnical
Commission (IEC), Geneva, Switzerland.

iv.

NIST (2012), NIST Special Public 800-61 Revision 2 - Computer Security

Incident Handling Guide, National Institute of Standards and Technology
(NIST), Gaithersburg, MD.

OFFICIAL

I.
Incident Response
Planning and Preparation

Incident Response Planning and Preparation

CII serve critical national sectors such as those dealing with Ugandas security,
defence and international relations. CII also comprise systems that support daily
life and economic activity. Thus, security incident planning and preparation is
important for two reasons. Firstly, the deliberate or accidental disruption of a CII
would inevitably affect important services. Secondly, CIIs are critical because
they control and operate other critical sectors and their physical assets. This
interconnectedness means that the impacts of the compromise of the
confidentiality, integrity and availability of a CII could go beyond the system
itself. Accordingly, planning and preparation activities include the following:

2.1

Incident Management Policy

This Standard requires that organisations create a standalone policy to deal with
the management of information security events, incidents and vulnerabilities.
The policy must apply to all staff and contractors. In line with US ISO/IEC 27035,
the incident management policy must:

2.2

Stress the importance of incident management to the organisation;

Show commitment and constitute senior managements formal acceptance of

accountability for incident management;

Summarise security event detection, reporting and collection activities;

Describe the incident assessment process including roles and stages;

Summarise the activities that follow confirmation that an event is an incident;

Stress the importance of effective logging of incidents and its role in later
analysis including the preservation of the legal weight of electronic evidence;

Address post-incident events such as lessons learnt, controls and process

improvements;

Describe security vulnerability reporting and handling;

Address the role of an ISIRT;

Stress awareness, education and trainings incident management role; and

Outline legal and regulatory compliance drivers/issues.

Integration with other Policies

In line with US ISO/IEC 27035, corporate-level security and risk management
policies must refer to the incident management policy and associated scheme
explicitly. In particular, they should:

Refer to the senior management commitment;

Outline the incident management policy in relevant sections;

OFFICIAL

Outline incident management scheme processes, and related infrastructure;

Outline the requirements for detecting, reporting, assessing and managing

information security events, incidents and vulnerabilities; and

Identify the personnel responsible for authorising and/or undertaking certain

critical actions e.g. taking systems off-line or shutting them down;

US ISO/IEC 27035 also states that integration involves the use of lessons learnt
from the incident management process to improve effectiveness of the corporate
risk management and other related policies.

2.3

Incident Management Scheme

According to US ISO/IEC 27035, an incident management scheme describes the
activities and procedures for dealing with security events and incidents, and the
communication of such events, incidents and vulnerabilities. The scheme comes
into use on the detection of a security event and/or vulnerability. Organisations
applying this Standard shall adopt a scheme that would serve as a guide for:

2.4

Responding to information security events;

Determining whether or not a security events become security incidents;

Managing security incidents to a conclusion;

Responding to security vulnerabilities;

Identifying lessons learnt, and improvements to the scheme and/or security

in general that are required; and

Making identified improvements.

Technical and other Support

US ISO/IEC 27035 requires that organisations acquire, prepare and test all the
necessary technical and other support means to ensure quick and effective
response to security incidents. This includes the following:

Access to details of the organisation's assets with an up-to-date asset

register and information on their links to business functions;

Access to the documented procedures related to crisis management;

Documented and promulgated communications processes;

The use of an information security event/incident/vulnerability database and

the technical means to populate and update the database quickly, analyse its
information and facilitate responses (in some instances manual records may
be required by an organisation), with the database kept provably secure;

Facilities for security forensics evidence collection and analysis; and

Adequate crisis management arrangements for the security event, incident

and vulnerability database.
10

OFFICIAL

According to US ISO/IEC 27035, the tools that support incident management

must enable the quick acquisition of security event/incident/vulnerability reports.
The tools should also make it practical to notify pre-selected internal and
external parties. US ISO/IEC 27035 recommends that, where possible, incident
management tools should be independent of the operational systems.

2.5

Awareness, Education and Training

The NISP observes that awareness, education and training helps foster a culture
that values, protects and handles information assets safely. US ISO/IEC 27035
notes that awareness and participation of all organisation personnel is crucial for
the success of a structured security incident management approach. According
to US ISO/IEC 27035, awareness briefings should explain:

The benefits of a structured incident management approach;

How the incident management scheme works, including its scope and the
security event, incident and vulnerability management workflow;

How to report security events, incidents and vulnerabilities;

The data held in, and outputs of the event/incident/vulnerability database;

Controls on confidentiality of sources as relevant;

Scheme service level agreements;

Notification of outcomes under what circumstances sources are advised;

Any constraints imposed by non-disclosure agreements;

Authority of the incident management organisation and its reporting line; and

Who receives reports from the incident management scheme, and how the
reports are distributed.

ISO/IEC 27035 and the NISP agree that security awareness should form part of
the induction process and other corporate security awareness programmes.

2.6

Cyber Drills
US ISO/IEC 27035 requires that organisations test incident management
processes and procedures regularly to identify and rectify any potential flaws
and problems. For example, a periodic cyber drill should evaluate the ISIRTs
capacity to respond to complex incidents, through the simulation of realistic
attacks, failures or faults. The Standard recommends that simulated scenarios
use real new information security threats. The drills should also involve internal
and external stakeholders involved in the incident management process. US
ISO/EC 27035 recommends that any changes resulting from post testing reviews
must under thorough checking before their application to the live environment.

11

OFFICIAL

II.
Incident Management
Roles and Responsibilities

12

Incident Management Roles and

Responsibilities
Given that, security incidents could affect an organisations capacity to achieve
its goals and meet its legal, regulatory and contractual obligations, accountability
for incident management lies with top management. Below is a description the
typical incident management roles and responsibilities:

3.1.1

Board of Directors and Accounting Officer

Boards oversee legal, financial, operational, compliance and reputational risk
management activities. Incidents could lead to the materialisation of all these
risks. Consequently, the Board demonstrates commitment to security incident
management by issuing a statement of information Risk Appetite.

3.1.2

Chief Information Risk Owner (CIRO)

The US ISO/IEC 27035 Standard requires the integration between corporatelevel risk management policies and the incident management policy. The CIRO
is able to make this happen, because he or she is responsible for the corporatelevel risk management policies. The Officer could also ensure that Boards retain
focus on incident management through quarterly reports on the risk position.

3.1.3

Chief Information Security Officer

The Chief Security Officer (CSO) or similar role takes over the management of
security incidents that exceed the powers of the internal Information Security
Incident Response Team (ISIRT). All organisations shall define the incidents that
require escalation to the CSO or similar role.

3.1.4

Information Security Incident Response Team (ISIRT)

The ISIRT is responsible for responding to security incidents involving their host
organisation. The ISIRT develops, maintains and disseminates security incident
action and response plans for different incident types. The team assigns one its
members to analyse security incident data, assess the potential business impact
and attempt to limit damage to the organisation and its operations. The ISIRT
must keep the CII owner informed of developments with the security incident at
appropriate times. In practice, ISIRTs work alongside other professionals within
and outside the organisation. Trivial incidents do not usually come to the
attention of the ISIRT. Therefore, incident categorisation must define incident
severity correctly to avoid unnecessary pressures on precious ISIRT time.

OFFICIAL

3.1.5

Security Manager/ISIRT Leaders

Security managers or ISIRT Leaders answer to the CSO. Their role is to manage
teams including ISIRTs. The roles of a security manager might include:

3.1.6

Overseeing the recording and assessment of security incidents;

Determining the actions to take to address security incidents within the scope
and responsibility of his or her team; and

Escalation to CSO or other managers security incidents and vulnerabilities

that are outside his or her teams responsibility.

Security Analysts/ISIRT Analysts

Security Analysts/ISIRT Analysts answer to the Security Manager/ISIRT Leader.
Their roles include the following:

3.1.7

Performing an initial assessment of suspected averse security events;

Escalating security events to security incidents; and

Escalation to ISIRT Leader confirmed security incidents.

Internal Dependencies
As noted above, incident management activities rely on a number of other teams
outside the core security area. The teams provide invaluable expert advice to the
ISIRT and might include the following:

3.1.7.1

Business Continuity Teams

The NISP regards incident management as business continuity issue because
security incidents disrupt and/or destroy IT systems, services and networks.
Therefore, the ISIRT and others involved in the incident management scheme
must work closely with the business continuity function to ensure that the
lessons learnt feed into business continuity policies and procedures. The ISIRT
should also advise the business continuity team of new security vulnerabilities to
facility planning for eventualities when the threats might exploit the weaknesses.
Business continuity teams also play vital roles in incident response in particular
in minimising operational disruption in high severity incidents.

3.1.7.2

IT and Network Operations Teams

System and network administrators and software developers can play a crucial
role in incident management. Given that the teams setup and/or manage the IT
infrastructure, they know how to handle the systems during emergency. For
example, electronic evidence gathering is a major feature of incident response.
14

OFFICIAL

The teams would know how to collect and preserve logs from the systems. The
teams would also know when and how to disconnect systems from the Internet.

3.1.7.3

Security Controller and Facilities Manager

Security incidents can be physical or logical intrusions. In both cases, the ISIRT
would need the assistance of the security and facilities team in gaining access to
buildings and/or locking others to preserve evidence. For physical intrusions, the
security and facilities teams may have expert knowledge on tools such as CCTV.

3.1.7.4

Human Resources
The human resources team plays an important role in incident response. HR is
particularly valuable when the incident involves a member of staff or contractor.
HR is responsible for organising disciplinary proceedings including dismissal. HR
can also help arrange services such as leave and medical assistance for victims.

3.1.7.5

Legal Department
Legal departments help ensure that incident response is in strict adherence with
relevant laws, regulations and ethics. For example, the legal team might assist
with the preservation of the legal weight and ensure the admissibility of
electronic evidence before Courts of Law. The legal team also works with HR on
disciplinary matters in particular those that lead to prosecution of a suspect. The
legal team would also advise CII owners and/or operators of contractual and
regulatory implications of security incidents e.g. loss of personal data.

3.1.8

External Dependencies
US ISO/IEC 27035 also recommends that organisations maintain contacts and
relationships with external entities, including:

3.1.8.1

Security and Intelligence Organisations

The NISP notes that security and intelligence agencies can provide CII owners
and operators information about security incidents from technical, personnel and
physical security angles in particular those posing national security risks.

3.1.8.2

Law Enforcement
Law enforcement teams can assist with electronic evidence handling. For
example, the Uganda Police Force enforces cybercrime legislation. In addition,

15

OFFICIAL

due to international arrangements such as Interpol, law enforcement can enable

the cross-border prosecution of cybercriminals.

3.1.8.3

Utilities
Organisations must have relationships with utility companies such as water and.
Electricity. The utilities respond to incidents such as fire and flooding. Utilities
can support active incident response activity by turning off electricity, water and
gas utilities.

3.1.8.4

Telecommunications & Network Service

Providers of fixed and mobile telecommunication and network services can play
a vital role in incident management including:

3.1.8.5

Insights into how vulnerabilities affect proprietary systems and software;

Sharing knowledge of what works due their operational experience; and;

Sharing incident response expertise and experience.

Technology Vendors
Technology vendors can also assist incident response. Vendor roles include:

Providing data on how vulnerabilities affect their systems and software;

Sharing experience on incident response activities;

Availing security patches for vulnerabilities; and

Sharing information with customers on major threats.

16

OFFICIAL

III.
Incident
Identification
and Categorisation

17

Incident Identification and Categorisation

Incident management activities must identify all events or actions that may
compromise business operations and threaten information security. Annex C of
US ISO/IEC 27035 presents a generic approach for categorising and classifying
security incidents. According to the Standard, the approach enables personnel
and organisations to record security incidents consistently.

4.1

Benefits of Incident Categorisation

According to US ISO/IEC 27035, the benefits of a consistent approach to the
categorisation and classification of security incidents include:

4.1.1

Promotion of the exchange and sharing of information on security incidents;

Enabling the automation of security incident reporting and responses;

More efficient and effective security incident handling and management;

Faster collection and analysis of data on security incidents; and

Identification of security incident severity levels using consistent criteria.

Categories of Security Incidents

According to US ISO/IEC 27035, security incidents may result from deliberate or
accidental actions of humans through technical or physical means. The Standard
presents incident categories below. Organisation bound by the NISF must show
that their incident management activities have accounted for all the categories.

Category

Description

Examples

Natural disaster
incident

The loss of information security is

caused by natural disasters beyond
human control.

Earthquake, volcano, flood, violent wind,

lightning, tsunami, collapse, etc.

Social unrest
incident

The loss of information security is

caused by the instability of society.

Bedin, terrorist assault, war, etc.

Physical damage
incident

The loss of information security is

caused by deliberately or
accidentally physical actions.

Infrastructure failure
incident

The loss of information security is

caused by the failures of the basic
systems and services that support
the running of information systems.

Fire, water, electrostatic, abominable

environment (such as pollution, dust,
corrosion, freezing), destruction of
equipment, destruction of media, theft of
equipment, theft of media, loss of
equipment, loss of media, tampering
with equipment, tampering with media,
etc.
Power-supply failure, networking failure,
air-conditioning failure, water-supply
failure, etc.

Radiation
disturbance incident

The loss of information security is

caused by the disturbance due to
radiation.

Electromagnetic radiation,
electromagnetic pulse, electronic
jamming, voltage fluctuation, thermal
radiation, etc.

OFFICIAL

Category

Description

Examples

Technical failure
incident

The loss of information security is

caused by the faults in information
systems or related non-technical
facilities, as well as unintentional
man-made problems, resulting in
information systems unavailability or
destruction.

Hardware failure, software malfunction,

overloading (saturating the capacity of
information systems), breach of
maintainability, etc.

Malware incident

The loss of information security is

caused by malicious programs that
are created and disseminated
deliberately. A malicious program is
inserted into information systems to
damage the confidentiality, integrity
or availability of data, applications or
operating systems, and/or affect the
normal operation of information
systems.

Computer virus, network worm, Trojan

horse, botnet, blended attacks, malicious
code embedded web page, malicious
code hosting site, etc

Technical attack
incident

The loss of information security is

caused by attacking information
systems through networks or other
technical means, either by exploiting
information systems' vulnerabilities
in configurations, protocols or
programs, or by force, which results
in an abnormal status of information
systems, or potential harm to the
current system operations.

Network scanning, exploitation of

vulnerability, exploitation of backdoor,
login attempts, interference, DoS, etc.

Breach of rule
incident

The loss of information security is

caused by breaching rules
deliberately or accidentally.

Unauthorized use of resources, breach

of copyright, etc.

Compromise of
functions incident

The loss of information security is

caused by deliberately or
accidentally compromising the
functions of information systems in
terms of security.

Abuse of rights, forging of rights, denial

of actions, mis-operations, breach of
personnel availability, etc.

Compromise of
information incident

The loss of information security is

caused by deliberately or
accidentally compromising the
security of information such as
confidentiality, integrity, availability
and etc.

Interception, spying, eavesdropping,

disclosure, masquerade, social
engineering, network phishing, theft of
data, loss of data, tampering with data,
data error, data flow analysis, position
detection, etc.

Harmful contents
incident

The loss of information security is

caused by propagating undesirable
content through information
networks, which endangers national
security, social stability and/or public
safety and benefits.

Illegal content, panic content, malicious

content, abusive content, etc.

Figure 1 Categories of information security incidents according to threats

4.2

Incident Severity Levels or Ratings

According to NIST SP 800-61 Revision 2, the decision on how to prioritise the
handling of an incident is perhaps the most critical in the incident handling
process. NIST advises that organisations consider relevant factors in deciding
how to prioritise incident handling in particular:

19

OFFICIAL

4.2.1

Functional Impact of the Incident

NIST recommends that organisations can use the impact of a security incident
on business functionality as a factor for determining its rating. Using the criteria,
incidents that have the biggest impact on current and future functionality get a
higher rating than those with a mild impact. NIST summarises it as follows:

Category

Definition

None
Low

No effect to the organizations ability to provide all services to all users

Minimal effect; the organisation can still provide all critical services to all users but has lost
efficiency
Organisation has lost the ability to provide a critical service to a subset of system users
Organisation is no longer able to provide some critical services to any users

Medium
High

Figure 2 NISF Functional Impact Categories

4.2.2

Information Impact of the Incident

According to NIST SP 800-61 Revision 2, the information impact deals with the
impact of a security incident on confidentiality, integrity and availability. The
unauthorised copying and transfer of sensitive information is an example. NIST
states that using this factor, incident handlers would consider the impact of the
information theft on the organisations overall mission. SS1 identifies industrial
espionage as one of the threat sources. The theft of sensitive blueprints can put
an organisation at a competitive and strategic disadvantage because the data
thieves shortcut the research process and go to market sooner. The victim of the
data theft may also face legal and contractual issues after the data theft. NIST
represents the impact as follows:

Category

Definition

None
Privacy
Breach
Proprietary
Breach
Integrity Loss

No information was exfiltrated, changed, deleted, or otherwise compromised

Sensitive personally identifiable information (PII) of taxpayers, employees, beneficiaries,
etc. was accessed or exfiltrated
Unclassified proprietary information, such as protected critical infrastructure information
(PCII), was accessed or exfiltrated
Sensitive or proprietary information was changed or deleted

Figure 3 NIST Information Impact Categories

4.2.3

Recoverability from the Incident

Thirdly, NIST SP 800-61 Revision 2 considers the amount of time and resources
required to recover from an incident. For example, incidents such as natural
disasters may annihilate assets completely. NIST gives a good example of
confidentiality, which once compromised is lost for that information asset. As a
20

OFFICIAL

result, there is little benefit in directing excessive resources in recovering from

irreversible incidents. However, organisations may justify reasonable investment
in preventing similar incidents. NIST represents the impact as follows:

Category

Definition

Regular
Supplemented
Extended
Not
Recoverable

Time to recovery is predictable with existing resources

Time to recovery is predictable with additional resources
Time to recovery is unpredictable; additional resources and outside help are needed
Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted
publicly); launch investigation

Figure 4 NIST Recoverability Effort Categories

4.2.4

Combining Functional, Information and Recoverability

The Business Impact Tables outlined in Security Standard No. 1 Technical
Risk Assessment (SS1) combine the functional, information and recoverability
impacts of information security incidents. The table below shows the relationship
between business impact and the classification levels defined in Security
Standard No. 3 Security Classification (SS3).

Classification Level

Impact Level

Business Impact

UNCLASSIFIED

Trivial

UNCLASSIFIED-PERSONAL

Low

OFFICIAL

High

SECRET

Extreme

TOP SECRET

Catastrophic

Figure 5 Business Impact Levels

Parties applying this Standard should refer to SS1 and SS3 for the business
impact tables and security classification levels respectively.

21

OFFICIAL

4.2.5

Incident Severity Levels and Escalation Criteria

As outlined above, SS1 plots business impact on a scale of 0 to 4. Below is a
generic definition of the business impact levels and their escalation criteria.

Incident Severity

Description

Highest Escalation

Response Time

Trivial

These incidents have no

immediate harmful impacts.
However, they must be
analysed to prevent more
significant incidents in the
future e.g. port scanning

ISIRT Help Desk

As appropriate

Low

Incidents cause minor

disruption to non-essential
services. The incidents may
cause medium term agony
to an individual or short-term
embarrassment or
inconvenience to several
individuals.

ISIRT

Within 48 hours.

High

These incidents cause

moderately serious
disruptions to services
including non-permanent
loss of the ability to provide
some services. The
incidents affect a small
group of users and cause
moderate embarrassment
e.g. website defacement

Chief Security
Officer;
ISIRT

Within 1 hour.

These incidents will usually

cause serious disruptions to
services, affecting the
organisations ability to
achieve its core business
objectives. The incidents
affect mission-critical
equipment or services and
damage confidence in the
organisation.

Project Director;
Chief Security
Officer
Chief Information
Risk Owner for CII

Immediately or as soon
as possible

These incidents will usually

cause disastrous disruption
to services, leading to the
permanent loss of a core
service or a facility
supporting the entire
organisation or a major
division or affiliate.

Board
Accounting Officer

Immediately

Extreme

Catastrophic

Figure 6 Security Incident Severity Levels and Escalation Criteria

22

OFFICIAL

IV.
Incident
Management
Process

23

Incident Management Process

ISO/IEC 27035 and NIST SP 800-61 Revision 2 describe the incident response
process in similar ways and divide into phases as follows.

5.1

ISO/IEC 27035 Incident Management Phases

The US ISO/IEC 27035 phases are:

5.1.1

Plan and Prepare

This phase involves getting all that is required in place to operate successful
information security incident management.

5.1.2

Detection and Reporting

This is the first phase to use the incident management scheme operationally. It
involves the identification of, collecting information associated with, and reporting
on occurrences of security events and existence of vulnerabilities by human or
automatic means.

5.1.3

Assessment and Decision

The second operational phase of the incident management scheme assesses
information associated with occurrences of security events and the decision on
whether or not it is security incident.

5.1.4

Responses
This phase involves reacting to information security incidents in accordance with the
actions agreed in the assessment and decision phase.

5.1.5

Lessons Learnt
This phase occurs after the resolution or closure of security incidents. It involves
learning lessons incident and/or vulnerability handling approach.

OFFICIAL

5.2

NIST SP 800-61 Rev 2 Incident Management Phases

The NIST SP 800-61 Revision 2 presents similar phases as illustrated below.

Figure 7 NIST Incident Response Life Cycle

NIST describes the phases in its incident management process as follows:

5.2.1

Preparation
This phase involves establishing and training an incident response team, and
acquiring the necessary tools and resources. The organisation also attempts to
limit the number of incidents by selecting and implementing controlled driven by
the results of risk assessments. However, residual risk remains.

5.2.2

Detection and Analysis

This phase involves identifying and generation of incident alerts. Organisations
use the severity rating to mitigate and recover from the incidents. The analysis
part of the phase is to establish whether the incident has affected more assets.

5.2.3

Containment, Eradication & Recovery

This phase involves steps to stop the spread of the incident e.g. shutdown a
system, disconnect if from a network and disable certain functions. It aims to buy
time to develop a more effective remediation strategy. The phase ends with the
eradication and recovery from the security incident and/or vulnerability.

25

OFFICIAL

5.2.4

Post-Incident Activities
This phase captures the lessons learnt in a report that explains the cause and
cost of the incident and the recommended steps for preventing future incidents.

NISF Incident Management Process

This Standard combines the activities in the US ISO/IEC 27035 and the NIST SP
800-61 Revision 2 to create the NISF Incident Management Process below.
Readers of this Standard should consider consulting the original documents if
they require more information on the ISO/IEC and NIST approaches. However,
as a minimum requirement, incident management policies and procedures of all
the organisations bound by the NISF must support the activities below:

6.1

Detect and Analyse

Several NISP mandated minimum security requirements such as IS7 Malicious
Code Protection; IS8 portable and removable media security and IS10
Protective Monitoring require CII owners and operators to have in place capacity
to detect, analyse and report unauthorised user and system activities. From an
incident management view, this implies technical solutions and procedures to
enable the ISIRT Analyst to make judgement about:

The type of incident;

Its scope or severity; and

People, systems and information resources involved or affected.

The analyst would use the initial impressions to formulate the first response. The
analyst should have a mechanism of escalating the event to other analysts
and/or the ISIRT leader on confirmation that it is indeed a security incident. The
team leader would then conduct detailed analysis of the security incident. The
ISIRT leader would also choose the next course of action from the predetermined steps in the organisational incident management process.

6.2

Begin Notification
Notification is the typical next step after the confirmation of a security incident.
The ISIRT leader uses pre-established guidance to notify nominated individuals
of the security incident. It is beneficial for the team leader to have a script of
what to say during incident notification to avoid confusion.

26

OFFICIAL

6.3

Setup Communications
Organisations must have in place secure means of sharing incident information.
Failure to communicate securely could alert the perpetrators leading to the
destruction of electronic evidence and/or exposure of the vulnerability to other
threat sources and actors. Therefore, this step requires that ISIRT leader and
other stakeholders to setup a secure channel for communicating information
about the status, extent and actions taken to contain a security incident. Given
that some of the communications occur over insecure networks such as e-mail
and the Public Switched Telephone Network (PSTN), organisations would find it
beneficial to assign codes to security incidents and/or vulnerabilities. In this way,
the ISIRT leader is able to coordinate response without risking disclosure of
sensitive information to unauthorised parties.

6.4

Contain
As defined in step three of the NIST SP 800-61 Revision 2 incident response life
cycle above, this phase involves steps to stop the spread of the incident e.g.
shutdown a system, disconnect if from a network and disable certain functions. It
aims to buy time to develop an effective remediation strategy. At this stage, the
ISIRT must work closely with other professionals such as forensics, system and
network administration to understand fully the impact of the containment actions.
For example, whilst shutting down a system might stop the spread of the attack,
it has the potential to destroy electronic evidence that might assist in the
identification and eventual prosecution of the perpetrator(s). However, in some
instances the sensitivity of the information involved might so high that the impact
of the disclosure outweighs the benefits of gathering evidence and prosecuting
the culprits such as when the disclosure could lead to widespread loss of life.

6.5

Identify
This activity follows containment and focuses on the identification of:

What happened?

Where it happened?

Why it happened?

When it happened?

Who perpetrated it?; and

How it happened?

With the support of the ISIRT, forensics teams both internal and external such as
law enforcement, security and intelligence organisations would take over and
assist in answering the questions above. In some cases, the forensics team is
part of the ISIRT. In this case, there must enough segregation between the
activities of the operational ISIRT group and the forensics investigators.

27

OFFICIAL

6.6

Security Incident Record

During this activity, the ISIRT shall create an accurate record of the incident so
far and store it in the Incident tracking system. According to US ISO/IEC 27035,
the security incident record should contain:
i.

Date of Incident;

ii.

Incident Number;

iii.

(If Applicable) Related Event and/or Incident Identity Numbers;

iv.

Point of Contact details;

v.

ISIRT Member details;

vi.

Information Security Incident Description;

vii.

Information Security Incident Details such as date and time;

viii.

Information Security Incident Category;

ix.

Components/Assets affected;

x.

Adverse Business Impact/Effect of the Incident;

xi.

Total Recovery Costs from the Incident;

xii.

Incident Resolution;

xiii.

(If Incident caused by People) person(s)/Perpetrators(s) involved;

xiv.

Description of the Perpetrator;

xv.

Actual or Perceived Motivation;

xvi.

Actions taken to Resolve the Incident;

xvii.

Actions Planned to Resolve the Incident;

xviii.

Actions Outstanding;

xix.

Conclusions;

xx.

Internal Individuals/Entities Notified;

xxi.

External Individuals/Entities Notified; and

xxii.

Sign-Offs i.e. Originator and Reviewers.

28

OFFICIAL

Organisations should not expect the ISIRT to complete the above lengthy form in
one sitting. Indeed, some of the information will only be available in later stages
of the incident response lifecycle.

6.7

Return to Operations
This activity involves the resumption of operations to the level before the security
incidents and/or in accordance with Service Level Agreements. The ISIRT shall
work closely with all professionals identified in this process, in particular the IT
and Networking teams to ensure that the system returns to full capacity. Due to
high likelihood of an ongoing forensics investigation, it is unlikely that operational
team would regain access to all the assets involved in the security incident. As
such, the organisation shall mobilise new and/or replacement assets.

6.8

Document and Review

The US ISO/IEC 27035s last phase i.e. lessons learnt coincides with this
activity. According to Standard, the phase involves the identification of and
making improvements to information security risk assessment and management
processes. This activity involves the review of the successes and issues
encountered during the incident response cycle. The results of the review could
serve as inputs for corporate-level risk policies, procedures and awareness
campaigns to prevent similar security incidents and vulnerabilities in the future.
The review also considers the ISIRTs ability to handle major emergencies.

29