DRAFT - SS6 - Incident Management v1.0

8/18/2019 DRAFT - SS6 - Incident Management v1.0

1/29

NATIONAL INFORMATION SECURITY FRAMEWORK (NISF) PUBLICATION _______________________________________________________________

Security Standard No. 6 –

Incident Management ______________________________________


2/29

OFFICIAL

2

Version History

No. Date Section Amendment

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


3/29

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


4/29

OFFICIAL

4

6.6 Security Incident Record ........................................................................................................ 28 6.7

Return to Operations .............................................................................................................. 29

6.8 Document and Review............................................................................................................ 29


5/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


6/29

1 Introduction

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

1.1 Aims of the Standard

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

1.2 Incident Management ConceptsThis Standard uses the terms and definitions contained in US ISO/IEC 27035. Inturn, 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 tocapture, 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 theorganisation that handles information security incidents during their lifecycle.This Standard uses ISIRT synonymously with Computer Emergency ResponseTeam (CERT), Computer Security Incident Response Team (CSIRT) andComputer Incident Response Team (CIRT1). Although these and similar namedorganisations serve in the incident management domain, US ISO/IEC 27035notes 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.


7/29

OFFICIAL

7

1.2.1.3 Information Security Event

This is an identified occurrence of a system, service or network state indicating apossible breach of information security, policy or failure of controls, or apreviously 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 securityevents that have a significant probability of compromising business operationsand 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)/InternationalElectrotechnical Commission (IEC), Geneva, Switzerland.

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

Security Techniques—

Code of Practice for Information SecurityManagement, International Standards Organization (ISO)/InternationalElectrotechnical 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 ElectrotechnicalCommission (IEC), Geneva, Switzerland.

iv. NIST (2012), NIST Special Public 800-61 Revision 2 - Computer SecurityIncident Handling Guide, National Institute of Standards and Technology(NIST), Gaithersburg, MD.


8/29

OFFICIAL

8

I. Incident Response

Planning and Preparation


9/29

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 dailylife and economic activity. Thus, security incident planning and preparation isimportant for two reasons. Firstly, the deliberate or accidental disruption of a CIIwould inevitably affect important services. Secondly, CIIs are critical becausethey control and operate other critical sectors and their physical assets. Thisinterconnectedness means that the impacts of the compromise of theconfidentiality, integrity and availability of a CII could go beyond the systemitself. Accordingly, planning and preparation activities include the following:

2.1 Incident Management Policy

This Standard requires that organisations create a standalone policy to deal withthe 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 ofaccountability 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 lateranalysis including the preservation of the legal weight of electronic evidence;

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

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 managementpolicies must refer to the incident management policy and associated schemeexplicitly. In particular, they should:

Refer to the senior management commitment;

Outline the incident management policy in relevant sections;


10/29

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 certaincritical actions e.g. taking systems off-line or shutting them down;

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

2.3 Incident Management Scheme

According to US ISO/IEC 27035, an incident management scheme describes theactivities and procedures for dealing with security events and incidents, and thecommunication of such events, incidents and vulnerabilities. The scheme comesinto use on the detection of a security event and/or vulnerability. Organisationsapplying 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 securityin 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 thenecessary technical and other support means to ensure quick and effectiveresponse to security incidents. This includes the following:

Access to details of the organisation's assets with an up-to-date assetregister 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 andthe technical means to populate and update the database quickly, analyse itsinformation and facilitate responses (in some instances manual records maybe 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, incidentand vulnerability database.


11/29

OFFICIAL

11

According to US ISO/IEC 27035, the tools that support incident managementmust 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, incidentmanagement 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 culturethat values, protects and handles information assets safely. US ISO/IEC 27035notes that awareness and participation of all organisation personnel is crucial forthe success of a structured security incident management approach. Accordingto 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 thesecurity 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 thereports are distributed.

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

2.6 Cyber DrillsUS ISO/IEC 27035 requires that organisations test incident managementprocesses and procedures regularly to identify and rectify any potential flawsand problems. For example, a periodic cyber drill should evaluate the ISIRT’scapacity to respond to complex incidents, through the simulation of realisticattacks, failures or faults. The Standard recommends that simulated scenariosuse real new information security threats. The drills should also involve internaland external stakeholders involved in the incident management process. USISO/EC 27035 recommends that any changes resulting from post testing reviewsmust under thorough checking before their application to the live environment.


12/29

OFFICIAL

12

II. Incident Management

Roles and Responsibilities


13/29

3 Incident Management Roles and

ResponsibilitiesGiven that, security incidents could affect an organisation’s capacity to achieveits goals and meet its legal, regulatory and contractual obligations, accountabilityfor incident management lies with top management. Below is a description thetypical 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 theserisks. Consequently, the Board demonstrates commitment to security incidentmanagement 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 CIROis 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 ofsecurity incidents that exceed the powers of the internal Information SecurityIncident Response Team (ISIRT). All organisations shall define the incidents thatrequire 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 hostorganisation. The ISIRT develops, maintains and disseminates security incidentaction and response plans for different incident types. The team assigns one itsmembers to analyse security incident data, assess the potential business impactand attempt to limit damage to the organisation and its operations. The ISIRTmust keep the CII owner informed of developments with the security incident atappropriate times. In practice, ISIRTs work alongside other professionals withinand outside the organisation. Trivial incidents do not usually come to theattention of the ISIRT. Therefore, incident categorisation must define incident

severity correctly to avoid unnecessary pressures on precious ISIRT time.


14/29

OFFICIAL

14

3.1.5 Security Manager/ISIRT Leaders

Security managers or ISIRT Leaders answer to the CSO. Their role is to manageteams 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 scopeand responsibility of his or her team; and

Escalation to CSO or other managers security incidents and vulnerabilitiesthat 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 teamsoutside the core security area. The teams provide invaluable expert advice to theISIRT and might include the following:

3.1.7.1 Business Continuity Teams

The NISP regards incident management as business continuity issue becausesecurity incidents disrupt and/or destroy IT systems, services and networks.Therefore, the ISIRT and others involved in the incident management schememust work closely with the business continuity function to ensure that the

lessons learnt feed into business continuity policies and procedures. The ISIRTshould also advise the business continuity team of new security vulnerabilities tofacility planning for eventualities when the threats might exploit the weaknesses.Business continuity teams also play vital roles in incident response in particularin 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 crucialrole in incident management. Given that the teams setup and/or manage the IT

infrastructure, they know how to handle the systems during emergency. Forexample, electronic evidence gathering is a major feature of incident response.


15/29

OFFICIAL

15

The teams would know how to collect and preserve logs from the systems. Theteams 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 ISIRTwould need the assistance of the security and facilities team in gaining access tobuildings and/or locking others to preserve evidence. For physical intrusions, thesecurity 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 isparticularly valuable when the incident involves a member of staff or contractor.HR is responsible for organising disciplinary proceedings including dismissal. HRcan 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 withrelevant laws, regulations and ethics. For example, the legal team might assistwith the preservation of the legal weight and ensure the admissibility of

electronic evidence before Courts of Law. The legal team also works with HR ondisciplinary matters in particular those that lead to prosecution of a suspect. Thelegal team would also advise CII owners and/or operators of contractual andregulatory 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 andrelationships with external entities, including:

3.1.8.1 Security and Intelligence Organisations

The NISP notes that security and intelligence agencies can provide CII ownersand operators information about security incidents from technical, personnel andphysical 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,


16/29

OFFICIAL

16

due to international arrangements such as Interpol, law enforcement can enablethe 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. Utilitiescan support active incident response activity by turning off electricity, water andgas utilities.

3.1.8.4 Telecommunications & Network Service

Providers of fixed and mobile telecommunication and network services can playa 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.


17/29

OFFICIAL

17

III. Incident

Identificationand Categorisation


18/29

4 Incident Identification and Categorisation

Incident management activities must identify all events or actions that maycompromise business operations and threaten information security. Annex C ofUS ISO/IEC 27035 presents a generic approach for categorising and classifyingsecurity incidents. According to the Standard, the approach enables personneland 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 thecategorisation 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 oraccidental actions of humans through technical or physical means. The Standardpresents incident categories below. Organisation bound by the NISF must showthat their incident management activities have accounted for all the categories.

Category Description Examples

Natural disasterincident

The loss of information security iscaused by natural disasters beyondhuman 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 damageincident

The loss of information security iscaused by deliberately oraccidentally physical actions.

Fire, water, electrostatic, abominableenvironment (such as pollution, dust,corrosion, freezing), destruction ofequipment, destruction of media, theft ofequipment, theft of media, loss ofequipment, loss of media, tamperingwith equipment, tampering with media,etc.

Infrastructure failureincident

The loss of information security iscaused by the failures of the basicsystems and services that supportthe running of information systems.

Power-supply failure, networking failure,air-conditioning failure, water-supplyfailure, etc.

Radiation

disturbance incidentThe loss of information security iscaused by the disturbance due toradiation.

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


19/29

OFFICIAL

19

Category Description Examples

Technical failureincident

The loss of information security iscaused by the faults in information

systems or related non-technicalfacilities, as well as unintentionalman-made problems, resulting ininformation systems unavailability ordestruction.

Hardware failure, software malfunction,overloading (saturating the capacity of

information systems), breach ofmaintainability, etc.

Malware incident The loss of information security iscaused by malicious programs thatare created and disseminateddeliberately. A malicious program isinserted into information systems todamage the confidentiality, integrityor availability of data, applications oroperating systems, and/or affect thenormal operation of informationsystems.

Computer virus, network worm, Trojanhorse, botnet, blended attacks, maliciouscode embedded web page, maliciouscode hosting site, etc

Technical attackincident

The loss of information security iscaused by attacking informationsystems through networks or othertechnical means, either by exploitinginformation systems' vulnerabilitiesin configurations, protocols orprograms, or by force, which resultsin an abnormal status of informationsystems, or potential harm to thecurrent system operations.

Network scanning, exploitation ofvulnerability, exploitation of backdoor,login attempts, interference, DoS, etc.

Breach of ruleincident

The loss of information security iscaused by breaching rulesdeliberately or accidentally.

Unauthorized use of resources, breachof copyright, etc.

Compromise offunctions incident

The loss of information security iscaused by deliberately oraccidentally compromising thefunctions of information systems interms of security.

Abuse of rights, forging of rights, denialof actions, mis-operations, breach ofpersonnel availability, etc.

Compromise ofinformation incident

The loss of information security iscaused by deliberately oraccidentally compromising thesecurity of information such asconfidentiality, integrity, availabilityand etc.

Interception, spying, eavesdropping,disclosure, masquerade, socialengineering, network phishing, theft ofdata, loss of data, tampering with data,data error, data flow analysis, positiondetection, etc.

Harmful contentsincident

The loss of information security iscaused by propagating undesirablecontent through informationnetworks, which endangers national

security, social stability and/or publicsafety and benefits.

Illegal content, panic content, maliciouscontent, 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 thehandling of an incident is perhaps the most critical in the incident handlingprocess. NIST advises that organisations consider relevant factors in deciding

how to prioritise incident handling in particular:


20/29

OFFICIAL

20

4.2.1 Functional Impact of the Incident

NIST recommends that organisations can use the impact of a security incidenton business functionality as a factor for determining its rating. Using the criteria,incidents that have the biggest impact on current and future functionality get ahigher 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 lostefficiency

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 theimpact of a security incident on confidentiality, integrity and availability. Theunauthorised copying and transfer of sensitive information is an example. NISTstates that using this factor, incident handlers would consider the impact of the

information theft on the organisation’s overall mission. SS1 identifies industrialespionage as one of the threat sources. The theft of sensitive blueprints can putan organisation at a competitive and strategic disadvantage because the datathieves shortcut the research process and go to market sooner. The victim of thedata theft may also face legal and contractual issues after the data theft. NISTrepresents the impact as follows:

Category Definition

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

PrivacyBreach

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

ProprietaryBreach

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 resourcesrequired to recover from an incident. For example, incidents such as natural

disasters may annihilate assets completely. NIST gives a good example ofconfidentiality, which once compromised is lost for that information asset. As a


21/29

OFFICIAL

21

result, there is little benefit in directing excessive resources in recovering fromirreversible incidents. However, organisations may justify reasonable investmentin 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

NotRecoverable

Recovery from the incident is not possible (e.g., sensitive data exfiltrated and postedpublicly); 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 – TechnicalRisk Assessment (SS1) combine the functional, information and recoverabilityimpacts of information security incidents. The table below shows the relationshipbetween business impact and the classification levels defined in SecurityStandard 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 businessimpact tables and security classification levels respectively.


22/29

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 ageneric definition of the business impact levels and their escalation criteria.

Incident Severity Description Highest Escalation Response Time

Trivial These incidents have noimmediate harmful impacts.However, they must beanalysed to prevent moresignificant incidents in thefuture e.g. port scanning

ISIRT Help Desk As appropriate

Low Incidents cause minordisruption to non-essentialservices. The incidents maycause medium term agonyto an individual or short-termembarrassment orinconvenience to severalindividuals.

ISIRT Within 48 hours.

High These incidents causemoderately seriousdisruptions to servicesincluding non-permanentloss of the ability to providesome services. Theincidents affect a smallgroup of users and causemoderate embarrassmente.g. website defacement

Chief SecurityOfficer;

ISIRT

Within 1 hour.

Extreme These incidents will usuallycause serious disruptions toservices, affecting theorganisation’s ability toachieve its core businessobjectives. The incidentsaffect mission-criticalequipment or services anddamage confidence in theorganisation.

Project Director;

Chief SecurityOfficer

Chief InformationRisk Owner for CII

Immediately or as soonas possible

Catastrophic These incidents will usuallycause disastrous disruptionto services, leading to thepermanent loss of a core

service or a facilitysupporting the entireorganisation or a majordivision or affiliate.

Board

Accounting Officer

Immediately

Figure 6 – Security Incident Severity Levels and Escalation Criteria


23/29

OFFICIAL

23

IV. Incident

ManagementProcess


24/29

5 Incident Management Process

ISO/IEC 27035 and NIST SP 800-61 Revision 2 describe the incident responseprocess 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 successfulinformation security incident management.

5.1.2 Detection and Reporting

This is the first phase to use the incident management scheme operationally. Itinvolves the identification of, collecting information associated with, and reportingon occurrences of security events and existence of vulnerabilities by human orautomatic means.

5.1.3 Assessment and Decision

The second operational phase of the incident management scheme assessesinformation associated with occurrences of security events and the decision onwhether or not it is security incident.

5.1.4 Responses

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

5.1.5 Lessons Learnt

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


25/29

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, andacquiring the necessary tools and resources. The organisation also attempts tolimit the number of incidents by selecting and implementing controlled driven bythe results of risk assessments. However, residual risk remains.

5.2.2 Detection and Analysis

This phase involves identifying and generation of incident alerts. Organisationsuse the severity rating to mitigate and recover from the incidents. The analysispart 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 asystem, disconnect if from a network and disable certain functions. It aims to buytime to develop a more effective remediation strategy. The phase ends with the

eradication and recovery from the security incident and/or vulnerability.


26/29

OFFICIAL

26

5.2.4 Post-Incident Activities

This phase captures the lessons learnt in a report that explains the cause andcost 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 SP800-61 Revision 2 to create the NISF Incident Management Process below.Readers of this Standard should consider consulting the original documents ifthey require more information on the ISO/IEC and NIST approaches. However,

as a minimum requirement, incident management policies and procedures of allthe organisations bound by the NISF must support the activities below:

6.1 Detect and Analyse

Several NISP mandated minimum security requirements such as IS7 – MaliciousCode Protection; IS8 portable and removable media security and IS10 – Protective Monitoring require CII owners and operators to have in place capacityto detect, analyse and report unauthorised user and system activities. From anincident 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. Theanalyst should have a mechanism of escalating the event to other analystsand/or the ISIRT leader on confirmation that it is indeed a security incident. Theteam leader would then conduct detailed analysis of the security incident. TheISIRT 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 individualsof the security incident. It is beneficial for the team leader to have a script ofwhat to say during incident notification to avoid confusion.


27/29

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 thedestruction of electronic evidence and/or exposure of the vulnerability to otherthreat sources and actors. Therefore, this step requires that ISIRT leader andother stakeholders to setup a secure channel for communicating informationabout the status, extent and actions taken to contain a security incident. Giventhat some of the communications occur over insecure networks such as e-mailand the Public Switched Telephone Network (PSTN), organisations would find itbeneficial to assign codes to security incidents and/or vulnerabilities. In this way,the ISIRT leader is able to coordinate response without risking disclosure ofsensitive information to unauthorised parties.

6.4 Contain

As defined in step three of the NIST SP 800-61 Revision 2 incident response lifecycle 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. Itaims to buy time to develop an effective remediation strategy. At this stage, theISIRT must work closely with other professionals such as forensics, system andnetwork 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 someinstances the sensitivity of the information involved might so high that the impactof the disclosure outweighs the benefits of gathering evidence and prosecutingthe 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 aslaw enforcement, security and intelligence organisations would take over andassist in answering the questions above. In some cases, the forensics team ispart of the ISIRT. In this case, there must enough segregation between theactivities of the operational ISIRT group and the forensics investigators.


28/29

OFFICIAL

28

6.6 Security Incident Record

During this activity, the ISIRT shall create an accurate record of the incident sofar 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.


29/29

OFFICIAL

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

6.7 Return to Operations

This activity involves the resumption of operations to the level before the securityincidents and/or in accordance with Service Level Agreements. The ISIRT shallwork closely with all professionals identified in this process, in particular the ITand Networking teams to ensure that the system returns to full capacity. Due tohigh likelihood of an ongoing forensics investigation, it is unlikely that operationalteam would regain access to all the assets involved in the security incident. Assuch, 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 thisactivity. According to Standard, the phase involves the identification of andmaking improvements to information security risk assessment and managementprocesses. This activity involves the review of the successes and issuesencountered during the incident response cycle. The results of the review couldserve as inputs for corporate-level risk policies, procedures and awarenesscampaigns to prevent similar security incidents and vulnerabilities in the future.The review also considers the ISIRT’s ability to handle major emergencies.

Documents

DRAFT - SS6 - Incident Management v1.0