NATIONAL INFORMATION SECURITY FRAMEWORK (NISF) PUBLICATION _______________________________________________________________

Security Standard No. 6 –

Incident Management ______________________________________

OFFICIAL

2

Version History

No. Date Section Amendment

1.0 08/01/2014 Draft Initial draft for NITA-U consideration

OFFICIAL

3

Table of Contents

1 Introduction .................................................................................................................................... 6

1.1 Aims of the Standard ................................................................................................................ 6 1.2 Incident Management Concepts ............................................................................................... 6 1.3 References ............................................................................................................................... 7

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

2.1 Incident Management Policy .................................................................................................... 9 2.2 Integration with other Policies ................................................................................................... 9 2.3 Incident Management Scheme ............................................................................................... 10 2.4 Technical and other Support .................................................................................................. 10 2.5 Awareness, Education and Training ....................................................................................... 11 2.6 Cyber Drills ............................................................................................................................. 11

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

3.1.1 Board of Directors and Accounting Officer ...................................................................... 13 3.1.2 Chief Information Risk Owner (CIRO) ............................................................................. 13 3.1.3 Chief Information Security Officer ................................................................................... 13 3.1.4 Information Security Incident Response Team (ISIRT) .................................................. 13 3.1.5 Security Manager/ISIRT Leaders .................................................................................... 14 3.1.6 Security Analysts/ISIRT Analysts .................................................................................... 14 3.1.7 Internal Dependencies .................................................................................................... 14 3.1.8 External Dependencies ................................................................................................... 15

4 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

5 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

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

6.1 Detect and Analyse................................................................................................................. 26 6.2 Begin Notification .................................................................................................................... 26 6.3 Setup Communications .......................................................................................................... 27 6.4 Contain ................................................................................................................................... 27 6.5 Identify .................................................................................................................................... 27

OFFICIAL

4

6.6 Security Incident Record ........................................................................................................ 28 6.7 Return to Operations .............................................................................................................. 29 6.8 Document and Review............................................................................................................ 29

OFFICIAL

5

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

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

1 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

7

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

8

I. Incident Response

Planning and Preparation

2 Incident Response Planning and Preparation

CII serve critical national sectors such as those dealing with Uganda’s 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:

Stress the importance of incident management to the organisation;

Show commitment and constitute senior management’s 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 training’s incident management role; and

Outline legal and regulatory compliance drivers/issues.

2.2 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

10

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:

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.

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

OFFICIAL

11

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 ISIRT’s 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.

OFFICIAL

12

II. Incident Management

Roles and Responsibilities

3 Incident Management Roles and Responsibilities

Given that, security incidents could affect an organisation’s 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 corporate-level risk management policies and the incident management policy. The CIRO is able to make this happen, because he or she is responsible for the corporate-level 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

14

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:

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 team’s responsibility.

3.1.6 Security Analysts/ISIRT Analysts

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

Performing an initial assessment of suspected averse security events;

Escalating security events to security incidents; and

Escalation to ISIRT Leader confirmed security incidents.

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

OFFICIAL

15

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,

OFFICIAL

16

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:

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.

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

OFFICIAL

17

III. Incident

Identification and Categorisation

4 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:

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.

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

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.

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.

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

19

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:

OFFICIAL

20

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 No effect to the organization’s ability to provide all services to all users

Low Minimal effect; the organisation can still provide all critical services to all users but has lost efficiency

Medium Organisation has lost the ability to provide a critical service to a subset of system users

High Organisation is no longer able to provide some critical services to any users

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 organisation’s 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 No information was exfiltrated, changed, deleted, or otherwise compromised

Privacy Breach

Sensitive personally identifiable information (PII) of taxpayers, employees, beneficiaries, etc. was accessed or exfiltrated

Proprietary Breach

Unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated

Integrity Loss 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

OFFICIAL

21

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 Time to recovery is predictable with existing resources

Supplemented Time to recovery is predictable with additional resources

Extended Time to recovery is unpredictable; additional resources and outside help are needed

Not Recoverable

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 0 Trivial

UNCLASSIFIED-PERSONAL 1 Low

OFFICIAL 2 High

SECRET 3 Extreme

TOP SECRET 4 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.

OFFICIAL

22

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.

Extreme These incidents will usually cause serious disruptions to services, affecting the organisation’s 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

Catastrophic 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

Figure 6 – Security Incident Severity Levels and Escalation Criteria

OFFICIAL

23

IV. Incident

Management Process

5 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

25

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.

OFFICIAL

26

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.

6 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 pre-determined 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.

OFFICIAL

27

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.

OFFICIAL

28

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.

OFFICIAL

29

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 27035’s 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 ISIRT’s ability to handle major emergencies.