Incident Management in outsourcing

Incident Management in outsourcing

Alfredo Ramiro Reyes Zúñiga

Submission date: December 2014Responsible professor: Colin Boyd, ITEMSupervisor: Maria B. Line, ITEM

Norwegian University of Science and TechnologyDepartment of Telematics

Abstract

The current ICT environment is becoming progressively contractedout to third parties. Outsourcing ICT services has created alternativeattack surfaces. Therefore, effective strategies to conduct incident man-agement in outsourcing settings are needed. Few published standardsand guidelines addressed outsourced ICT services and what is required toconduct efficient incident management in these settings. Moreover, thereis not much published literature about current practices. In this project,an empirical study was conducted on Incident management practicesin outsourcing settings. The research was conducted as a case studyperforming a qualitative study of three Norwegian organizations, one ex-pert and a survey. The findings revealed a lack of systematic approaches.Finally, this research contributes with a framework of published and forth-coming ISO/IEC standards to provide guidance on incident managementin outsourcing settings. This research provides also with recommenda-tions and a set of questions to prepare for the challenges involved in theaforementioned settings.

Contents

List of Figures ix

List of Tables xi

List of Acronyms xiii

1 Introduction 11.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Method 52.1 Qualitative research . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Choice of method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Qualitative interviews . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Document study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Qualitative data analysis . . . . . . . . . . . . . . . . . . . . . . . . . 82.7 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 92.9 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Background study 133.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Standards and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 ISO/IEC 27001:2013 – Information security management . . 153.2.2 ISO/IEC 27002:2013 Code of practice for information security

controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 ISO/IEC 27035:2011 Information security incident management 173.2.4 ISO/IEC 27036-*:2013+ Information security for supplier rela-

tionships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.5 NIST Special Publication 800-61 . . . . . . . . . . . . . . . . 203.2.6 ENISA – Good Practice Guide for Incident Management . . . 20

3.3 Forthcoming standards . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

3.3.1 ISO/IEC 19086-* Service Level Agreement (SLA) frameworkand Technology . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.2 ISO/IEC 27017 Code of practice for information security con-trols based on ISO/IEC 27002 for cloud services . . . . . . . 22

3.3.3 ISO/IEC 27035-* Information security incident management 223.3.4 ISO/IEC 27036-4: Guidelines for security of cloud services . . 23

3.4 Framework of standards relationships . . . . . . . . . . . . . . . . . . 233.5 European ongoing developments . . . . . . . . . . . . . . . . . . . . 24

3.5.1 European Cloud Computing Strategy . . . . . . . . . . . . . 253.5.2 Cybersecurity Strategy . . . . . . . . . . . . . . . . . . . . . . 263.5.3 The Cloud Accountability Project (A4Cloud) . . . . . . . . . 26

3.6 Incident management models . . . . . . . . . . . . . . . . . . . . . . 27

4 Case Introductions 294.1 Case A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Case B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Case C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 Expert 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Findings 335.1 Case A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Plan and Prepare . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.2 Detection and Reporting . . . . . . . . . . . . . . . . . . . . . 355.1.3 Assessment and Decision . . . . . . . . . . . . . . . . . . . . 365.1.4 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 Case B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.1 Plan and Prepare . . . . . . . . . . . . . . . . . . . . . . . . . 385.2.2 Detection and Reporting . . . . . . . . . . . . . . . . . . . . . 395.2.3 Assessment and Decision . . . . . . . . . . . . . . . . . . . . 405.2.4 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.5 Lessons learnt . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Case C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3.1 Plan and Prepare . . . . . . . . . . . . . . . . . . . . . . . . . 425.3.2 Detection and Reporting . . . . . . . . . . . . . . . . . . . . . 425.3.3 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Expert 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.1 Plan and Prepare . . . . . . . . . . . . . . . . . . . . . . . . . 435.4.2 Detection and Reporting . . . . . . . . . . . . . . . . . . . . . 445.4.3 Assessment and Decision . . . . . . . . . . . . . . . . . . . . 455.4.4 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4.5 Lessons learnt . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.5 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Discussion 556.1 The research questions revisited . . . . . . . . . . . . . . . . . . . . . 55

6.1.1 How different organizations perform incident managementwhen third party companies are involved? . . . . . . . . . . . 55

6.1.2 How are the responsibilities distributed? . . . . . . . . . . . . 566.1.3 What are the challenges that organizations experience during

the operational phases of incident management in the out-sourced setting and how could they be addressed? . . . . . . 57

7 Conclusions 63

References 65

A Information Letter 69

B Interview guide 71

C Survey 73

D Poster 79

List of Figures

2.1 Different Research Methods, modified from [Yin14] . . . . . . . . . . . . 7

3.1 Incident Management Phases . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Incident Response Lifecycle, modified from [NIS12] . . . . . . . . . . . . 213.3 Incident Management and Incident Handling, adapted from [MRS10] . . 213.4 Framework of published and forthcoming standards . . . . . . . . . . . 24

5.1 Participants experience with incident management activities. . . . . . . 495.2 Organization’s size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Participant’s roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.4 Participant’s industry sectors. . . . . . . . . . . . . . . . . . . . . . . . . 515.5 Challenges when managing incidents involving third parties. . . . . . . . 525.6 Organization’s approaches to deal with incident management in outsourc-

ing scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.7 Amount of incidents in an outsourcing setting managed by the partici-

pant’s organizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.8 Effectiveness of the participant’s incident management team dealing with

outsourcing settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.9 Roles and responsibilities defined in the incident management plan re-

garding third parties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.1 Information letter provided to the case study participants . . . . . . . . 70

B.1 Questionnaire guide used during the interviews . . . . . . . . . . . . . . 72

C.1 Survey questions. Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 74C.2 Survey questions. Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75C.3 Survey questions. Part 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 76C.4 Survey questions. Part 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

D.1 Research poster presented at the NordSec 2014 conference . . . . . . . . 80

ix

List of Tables

3.1 Incident management models . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Incident management models in Case A. . . . . . . . . . . . . . . . . . . 294.2 Incident management model in Case B. . . . . . . . . . . . . . . . . . . 304.3 Incident management model in Case C. . . . . . . . . . . . . . . . . . . 304.4 Incident management models where Expert 1 is involved. . . . . . . . . 31

xi

List of AcronymsCERT Computer Emergency Response Team

CISO Chief Information Security Officer

CSIRT Computer Security Incident Response Team

ENISA European Network and Information Security Agency

FIRST Forum of Incident Response and Security Teams

ICT Information and Communication Technology

IDS Intrusion Detection System

IEC International Electro-technical Commission

IRC Internet Relay Chat

IRT Incident Response Team

ISIRT Information Security Incident Response Team

ISMS Information Security Management System

ISO International Organization for Standardization

ISP Internet Service Provider

IT Information Technology

MSSP Managed Security Service Provider

NIST National Institute for Standards and Technology

RAMRandom Access Memory

SLA Service Level Agreement

SLO Service Level Objectives

VPN Virtual Private Network

Chapter1Introduction

The current Information and Communication Technology (ICT) environment isbecoming progressively contracted out to third parties. It is rare to find nowadaysan organization that is not outsourcing at least partially its ICT operations. A risingnumber of companies provide specific ICT services to help organizations to focus ontheir core business and mitigate the lack of expertise to accomplish specific functions.

Several organizations outsource their ICT services to a professional ICT supplier.Outsourcing has several advantages, both for small and large organizations. But italso has pitfalls. It poses new challenges, responsibilities and requires communicationimprovements between two or even more separate organizations.

However, outsourcing ICT operations has created new venues for attacks. The2014 report regarding cyber-attacks against energy suppliers [Res14], states that inorder to reach large organizations, the attackers targeted their suppliers with lesssecurity. Such type of attacks have had a global presence already.

Regarding the recent cyber-attacks to the oil and energy companies in Norway,Alan Calder, founder and executive chairman of IT Governance1, responded to thenews on an interview to the digital magazine SCMagazineUK2 declaring:

“Spear phishing attacks – increasingly through the compromised sys-tems of small suppliers to large companies – is an increasingly interestingattack vector for criminals attempting to steal valuable information”

Incident management requires comprehensive qualification, training, and especiallyplanning. And if, or when, an information security incident occurs, it needs to be

1IT Governance website http://www.itgovernance.co.uk/2http://www.scmagazineuk.com/hundreds-of-norwegian-energy-companies-hit-by-cyber-

attacks/article/368539/

1

2 1. INTRODUCTION

efficiently and appropriately responded to. This is not the time for clarifyingresponsibilities.

Even though companies and organizations might be prepared for dealing withincidents in their ICT systems, studies have revealed that third party companies arenot adequately involved in planning for incidents [TLJ14], despite the fact that inmany cases the resolution depends on the supplier collaboration during the incidentmanagement.

This topic requires further investigations to identify whether there are specificchallenges related to incident management in outsourcing settings. If that is the case,then it is relevant to identify: Which are these challenges? Why do these challengesarise and how could they be addressed? Current standards and recommendationshave a lack of information to address outsourcing. Investigations are needed toconsider more specific or different kinds of recommendations when it comes toincident management in outsourcing.

1.1 Objectives

This research project aims to identify current practices and successful strategiesfor practicing incident management in an outsourced setting. It is hoped that thisstudy will develop new understandings about improvements needed to overcomechallenges related to incident management in the aforementioned settings. Theresearch questions are:

– How do different organizations perform incident management when third partycompanies are involved?

– How are the responsibilities distributed?

– What are the challenges that organizations experience during the operationalphases of incident management in an outsourced setting?

– How potential challenges related to incident management in an outsourcingsetting could be addressed?

1.2 Outline

Chapter 2 (Research method) describes what qualitative research involves, theprocess of selection for the research method and the case study process followedin the present study. An incident management background study is presented onChapter 3 (Background study), where related published standards, guidelines andforthcoming standards are described and analyzed and a current standard’s framework

1.2. OUTLINE 3

for incident management in outsourcing settings is depicted. Furthermore a briefdescription on European ongoing developments on the topic is introduced. In Chapter4 (Case Introductions) the organizations and experts in the case study are described.The findings from the case study are detailed in Chapter 5 (Findings). Chapter 6(Discussion) discusses the findings described in chapter 5 and compares them with thebackground study presented in chapter 3. In Chapter 7 (Conclusions), conclusionsand future work are described.

Appendix A contains the information sheet provided to the case study participants.In Appendix B the Interview guide can be found. Appendix C includes the surveyprovided to professionals on the field. Finally, the research poster presented at theNordSec 2014 conference is presented in Appendix D.

Chapter2Method

The study aims to extract in-depth information on how incident management isperformed in practice when outsourcing scenarios are present.

2.1 Qualitative research

Qualitative research involves exploring specific topics or issues, understanding phenom-ena and finding answers to questions, by analyzing and making sense of unstructureddata, through different research methods. It originated in the social and behavioralsciences. However, today is a method of inquiry employed in many disciplines.

Some qualitative research typical features [Rob11] are described as :

– Accounts and findings are presented verbally or in other non-numerical form.There is little or no use of numerical data or statistical analysis.

– Contexts are seeing as important. There is a need to understand phenomenain their setting.

– Situations are described from the perspective of those involved.

– The design of the research is flexible throughout the whole process.

– The generalizability of findings is not a major concern.

– It takes place in natural settings.

– It is usually small-scale in terms of numbers of persons or situations researched.

2.2 Choice of method

Different research methods have particular advantages and disadvantages, threecriteria to consider are: type of research question posed, requirement of control

5

6 2. METHOD

over behavioral events and the focus on current phenomena contrary to historicalphenomena.

To choose among the various research methods, the first and most importantcondition is to distinguish the kind of research question being posed. Then, the nextcondition is to determine whether control of behavioral events is needed and finallymake a decision on contemporary events versus historical events.

The defined question for this study, is a “how” question. As stated in section1.1 Objectives, the study aims to identify current practices and successful strategies,where there is no control over events. The study focus on contemporary phenomenon,even though some recent past events are considered, such as ICT incidents, the mainobjective is on current practices.

Based on this, case study emerged as the most suitable method for this study.Case studies are a preferred method when:

– “How” and “why” questions are posed.

– Little or none control over events prevails

– Focus is on a current phenomenon within a real life context.

2.3 Case study

Yin describes a case study as “an empirical inquiry that investigates a contemporaryphenomenon in depth and within its real-life context. Furthermore, he specifies thata case study copes with the technically distinctive situation in which there will bemany more variables of interest than data points. It relies on multiple sources ofevidence, and benefits from the prior development of theoretical propositions to guidedata collection and analysis.”[Yin14]

A case study is a linear but iterative process that includes 6 phases: plan, design,prepare, collect, analyze and share.

The Plan phase involves the identification of the research questions and selectingthe case study as the choice of research method.

The Design phase addresses the creation of a hypothesis about what is beingstudied and what is to be learned, as well as propositions that direct the attentionto something that should be examined within the scope of study. The design phasepurpose is to help to avoid the situation in which the evidence does not addressthe initial research questions. Here, the logic associating the collected data to

2.4. QUALITATIVE INTERVIEWS 7

Figure 2.1: Different Research Methods, modified from [Yin14]

the propositions as well as the criteria for interpreting the findings, are importantcomponents.

The Preparation phase involves creating a protocol for the research, sharpeningthe researcher skills, training for a particular case study, examining and selectingcandidate cases and executing a pilot case study. All of the activities are a preparationfor the data collection.

The Collection phase makes emphasis in the use of multiple sources of evidence,coming from at least two different sources and providing similar discoveries. Findingsare likely to be more precise and convincing if the conclusions are led by corroboration.Yin defines the interview in as “one of the most important sources of case studyinformation because they can provide essential insights into behavior events.”

The Analysis phase consists of analyzing the data either using a general strategyor by reshaping the data in an exploratory sense in order to develop a systematicidentification of what is worth analyzing and how it should be analyzed, to drawempirically based conclusions.

The Share phase involves preparing the case study report, to present the resultsand findings.

2.4 Qualitative interviews

Myers et al., describe a qualitative interview as one of the most important datagathering tools in qualitative research [MN07]. This description has been comple-mented adding that it is a powerful and flexible tool which purpose is to describeand clarify the people’s experiences [SA11]. There are various types of qualitative

8 2. METHOD

interviews. However, the ones used for this project are referred as Unstructured orsemi-structured interview and Structured interview[MN07].

A semi-structured interview is a sketch. The researcher may prepare somequestions in advanced, but some improvisation is performed during the interview.An interview guide was used as the incomplete script addressing the main researchquestions. It can be found in Appendix B.

These type of interviews were performed either face-to-face or via Skype, duringa short period of time and voice recorded. Interviews via the application Skype wereperformed only with participants that were located abroad. The questions duringthe interviews (face-to-face and via Skype) did not follow any predefined order toenable a fluid conversation and asking for elaborations when needed.

A structure interview contains a complete script prepared in advance and withno room for spontaneity. A survey is an example of this type of interview. Asurvey was performed with the participation of people with different roles in incidentmanagement teams, from a diverse set of organizations, during a course at one ofthe security conferences in Norway. The survey can be found in Appendix C

2.5 Document study

Relevant published standards, guidelines, forthcoming standards and academic litera-ture was studied to complement the knowledge obtained from the interviews and thesurvey. This was a key factor to identify a broad overview of scenarios for incidentmanagement in outsourcing settings.

2.6 Qualitative data analysis

A qualitative and inductive research method was used on this project. Differentcategories in the data were identified, as well as patterns and relationships, using a“general inductive approach”, as described by Thomas [Tho06].

He describes a methodical strategy to analyze qualitative data that can producevalid and reliable findings from focused research questions. The primary purpose ofthis approach is to allow findings to be exposed from the raw data regardless of theresearch questions and method used.

Thomas listed the purposes of an inductive analysis approach [Tho06], these are:

– To digest and summarize raw text data into a brief format.

2.7. PARTICIPANTS 9

– To define clear links between the summary findings derived from the raw dataand the research objectives.

– To develop a framework based on the experiences or processes revealed by theraw data.

A digest and summary of data of each individual case is fulfilled in Chapter 5(Findings). The findings where then linked to the research objectives and a modelunderlying the experiences or processed derived from the raw data are fulfilled inChapter 6 (Discussion).

The process of analysis and interpretation from raw data to main findings andconclusions was done following the phases of thematic coding analysis described byRobson [Rob11]. The phases can be outlined as follows:

1. Getting familiar with the data

2. Generating initial codes.

3. Identifying themes.

4. Constructing thematic networks.

5. Comparing and interpreting the patterns.

2.7 Participants

The participating organizations in this study are all Norwegian organizations. Theorganizations were selected according to their involvement with outsourcing scenarios.The participant further described as Expert 1 was selected due to his expertise andalso due to his experience in different scenarios of incident management in outsourcingsettings. This participant, as well as all the participants that took part in the survey,are Norwegian citizens.

The core activities from the participating organizations and all participants belongto different sectors which could lead to interesting findings. Sectors and expertiseare described in chapter 4.

2.8 Ethical considerations

The purpose of the research was informed to the participants when the interview wasrequested. Simultaneously an informed consent form was provided to them to ask fortheir consent. The form described what the participation in the project implied, and

10 2. METHOD

what will happen to their personal information, since the interviews were recorded. Avoluntary participation was clearly stated with the option to withdraw at any time.

The anonymity and privacy of those who participated in this project was respected.Anonymity is provided to the participants and their organizations on this report toprevent their personal information and information security practices becoming pub-lic. All information that could directly or indirectly identify individuals or individualorganizations or even link them was anonymized or deleted. Participating organiza-tions are referred on the report using alias names. No individuals or organizationsare recognizable in this report. At the end of the project research all recordings weresecurely erased.

This project was reported to the Norwegian Social Science Data services. Theinformation sheet provided to the case study participants can be found in AppendixA.

2.9 Challenges

A small number of organizations are studied and a small number of participants wereinvolved due to time restrictions. The author had little or no experience in preparingand conducting qualitative interviews. The data collection process was based oninterviews and a survey, the challenges with each approach should be considered.

Challenges with the interviews:

– Ambiguity of language can create confusion on the objectives of the researchduring the request for interviews.

– Requesting for interviews in a short time basis creates difficulties to get them.

– The participants may have chosen not to share important information for theresearch derived from a lack of trust. This could lead to an incomplete datagathering.

– Limited time for the interviews could have caused limited answers, which areprone to leave out relevant information.

– Posing “why” questions during the interview could create defensiveness on theinterviewee.

Challenges with the survey:

2.9. CHALLENGES 11

– Conducting a survey on-line might influence the number of participants thatanswered it.

– Finding an information security event where the participants invited to partici-pate in the survey would be all related to incident management tasks.

– Motivating the participants to fill out the survey.

– The participants may have chosen not to share important information for theresearch derived from a lack of trust.

– Ambiguity of language can create confusing questions.

– The participants may have chosen not to provide real answers.

Chapter3Background study

This chapter introduces relevant background information with regard to incident man-agement in outsourcing settings. An overview of relevant published and forthcomingstandards, guidelines as well as related European ongoing research is presented.

3.1 Related Work

Incident management is a term that defines all the activities related to managinginformation security incidents. It outlines the sequence of acts required to preparefor, detect, analyze, restore, and prevent future incidents.

Incident management is not only about handling an incident. It includes activitiesfor the entire set of tasks involved with the incident response lifecycle, from planningto learning from the experience of dealing with incidents.

Various standards and guidelines addressed incident management. The ones thatare well known among the information security community are: ISO/IEC1 27035,NIST SP2 800-61 and ENISA3 Good Practice Guide for Incident Management. Allof them will be described in section 3.2

Outsourcing is often perceived as the process that takes place when a companycontracts out a business function to a third party. This process involves a contractualagreement.

Siepmann presents four types of outsourcing: technology outsourcing, businessprocess outsourcing, business transformation outsourcing and knowledge processoutsourcing[Sie13]. Today the first two are predominant.

1International Organization for Standardization/International Electro-technical Commission2National Institute for Standards and Technology Special Publication3European Network and Information Security Agency

13

14 3. BACKGROUND STUDY

Technology outsourcing facilitates the use of technical capabilities from a thirdparty to benefit a company acquiring the services. Business process outsourcingempowers company’s functions that are commonly out of the core company’s compe-tency. This eliminates the need to invest on improving business functions that arenot aligned with the company interests.

Abundant academic literature related to incident management can be found. Thisis a result of the increasing interest on the topic. However, the amount of availableliterature where the incident management in outsourcing environments is addressedis very limited.

Sherwood [She97] presented an analysis of the main issues concerning security ofinformation in outsourced services, where he looks at the strategy that should befollowed to manage information security in this environment.

Siepmann [Sie13] provides comments regarding what should be addressed beforeoutsourcing the ICT services. His comment’s categories are aligned with ISO/IEC27002. There, few thoughts regarding management of information security events inoutsourcing settings can be found.

A literature review on current practices and experiences with incident managementwas done by Tøndel et al. [TLJ14]. There, the practice of incident management inoutsourcing scenarios was identified as one of the incident management challengesin this review. According to their study, additional support and domain specificguidelines on this topic are needed.

Hove et al. [HTLB14] described that incident management in outsourcing settingsis a current challenge for incident management and it has not been researched.

The current scenario of incident management is changing rapidly. Through theprocess of studying the related work and identifying the standards and guidelines(published and working drafts) presented in this chapter, the need to study theincident management in outsourcing settings became evident.

As described by Hove et al. [HTLB14] and Tøndel et al. [TLJ14] there is aneed for research around the topic of incident management in outsourcing settingssince it is one of the present incident management challenges. The current availableliterature does not address it. Sherwood’s analysis [She97], on security of informationin outsourced services, lacks an evaluation on incident management. Siepmann’swork [Sie13] addresses risk and security in outsourcing settings, but it has a broaderscope, it does not focus on incident management.

3.2. STANDARDS AND GUIDELINES 15

Furthermore, there is no analysis on the challenges at each one of the incidentmanagement phases posed by outsourcing ICT services.

3.2 Standards and guidelines

This section presents relevant published standards containing information regardingincident management in outsourcing settings.

3.2.1 ISO/IEC 27001:2013 – Information security management

ISO/IEC 27001:2013 [ISO13a] provides requirements for establishing, implementing,maintaining and continually improving an Information Security Management System(ISMS). An ISMS is a systematic approach to managing sensitive company informationso that it remains secure. It includes people, processes and Information Technology(IT) systems by applying a risk management process. The 2013 version is an evolutionfrom the 2005 version, most of the standard content remains without changes. Somedifferences from the 2005 standard include: more emphasis on measurement andevaluation on organization’s ISMS performance. It also includes a new section onoutsourcing.

This section describes some controls from the ISO 27001 standard. The contentis, unless specified otherwise, derived from [ISO13a] . The controls, listed on theAnnex A from the standard, relevant to the case study are:

– A.15 Supplier relationships.

◦ A.15.1 Information security in supplier relationships.Objective: To ensure protection of the organization’s assets that is acces-sible by suppliers.

∗ A.15.1.1 Information security policy for supplier relationships.∗ A.15.1.2. Addressing security within supplier agreements.∗ A.15.1.3 Information and communication technology supply chain.

◦ A.15.2 Supplier service delivery managementObjective: To maintain an agreed level of information security and servicedelivery in line with supplier agreements.

∗ A.15.2.1 Monitoring and review of supplier services∗ A.15.2.2 Managing changes to supplier services

– A.16 Information security incident management


◦ A.16.1 Management of information security incidents and improvementsObjective: To ensure a consistent and effective approach to the man-agement of information security incidents, including communication onsecurity events and weaknesses.

∗ A.16.1.1 Responsibilities and procedures∗ A.16.1.2 Reporting information security events∗ A.16.1.3 Reposting information security weaknesses∗ A.16.1.4 Assessment of and decision on information security events∗ A.16.1.5 Response to information security incidents∗ A.16.1.6 Learning from information security incidents∗ A.16.1.7 Collection of evidence

3.2.2 ISO/IEC 27002:2013 Code of practice for informationsecurity controls

ISO/IEC 27002:2013 is a code of practice that provides good practices on informationsecurity management. The standard is designed for organizations to use as a referencefor selecting controls within the process of implementing an ISMS. [ISO13b]

This section describes some implementation guidance recommendations from theISO 27002:2013. The content is, unless specified otherwise, derived from [ISO13b].Here are some implementation guidance recommendations relevant to the case study:

– A.15 Supplier relationships.

◦ A.15.1 Information security in supplier relationships.There should be processes, procedures, controls, awareness, etc. to mitigatethe risks associated with organization’s assets accessible to third partiessuch as ICT outsourcers and suppliers. This should be implemented inorder to protect the organization’s information from end to end throughthe supply chain (including cloud computing services). It should be agreedwithin the agreements and contracts.

◦ A.15.2 Supplier service delivery managementOrganizations should monitor, review and audit supplier service deliveryto maintain an agreed level of information security in line with supplier’scontracts and agreements. All service changes should be managed.

– A.16 Information security incident management

◦ A.16.1 Management of information security incidents and improvementsThere should be a quick, effective and orderly approach to the management


of information security incidents. It should include responsibilities andprocedures to manage (plan, monitor, detect, analyze, report, handleforensic evidence, perform assessment, respond and reuse the knowledgegained from) information security events, incidents and weaknesses.

3.2.3 ISO/IEC 27035:2011 Information security incidentmanagement

ISO/IEC 27035:2011 provides guidance on information security incident managementfor large and medium-sized organizations. Here is an introduction to the ISO27035:2011 standard and the content, unless specified otherwise, is derived from[ISO11] .

The standard provides an extensive and structured approach to incident manage-ment, especially to:

– Detect, report and assess information security incidents;

– Respond to an manage information security incidents;

– Detect, asses and manage information security vulnerabilities; and

– Continuously improve information security and incident management as a resultof managing information security incidents and vulnerabilities.

Incident management consists of five phases (see Figure 3.1):

– Plan and prepare

– Detection and reporting

– Assessment and decision

– Responses

– Lessons learnt

Plan and prepare This phase involves everything that is needed to operatesuccessfully the incident management. An incident management policy should beformulated and documented by each organization and gain commitment from thesenior management. Security and risk management policies should be updated andreviewed regularly

A detailed incident management scheme should be defined and documented. Thescheme should include:


Figure 3.1: Incident Management Phases

– A classification scale to grade incidents

– Incident forms

– Procedures to the use of the forms

– Operating procedures for the Information Security Incident Response Team(ISIRT)

– Overall plan to establish the ISIRT

– An activity to establish and preserve relationships and connections with internaland external organizations

– Implementation and operation of technical and other support mechanisms

– Information security awareness and training program

– Exercises to test the scheme

Once this phase is completed, organizations are ready to manage informationsecurity incidents.

Detection and reporting This phase involves detecting, collecting and reportingoccurrences of events and vulnerabilities by human or automatic means. The orga-nization should ensure that the right personnel deal with reported vulnerabilities.Information on vulnerabilities, incidents and their resolution should be preserved ina database managed by the ISIRT.


Organizations should implement monitoring mechanisms to detect and reportevents, incidents and vulnerabilities. All electronic evidence should be properlylogged, gathered and stored securely. All the information collected and reportedduring this phase should be as complete as possible to ensure that this informationcollection can be used as a basis for making assessments and decisions.

Assessment and decision This phase involves the assessment of informationrelated to events and decisions to make decisions on whether an event is an incidentor not. Organizations should conduct assessments to determine if an event is anincident or a false alarm and determine its impact on assets, information, processes,infrastructure, core services, and others. The assessments should be verified by theISIRT to confirm the results. This should be followed by decisions on how to deal withthe incident, by whom and in what priority. All the information regarding an event,incident or vulnerability should be stored in a database operated and maintained bythe ISIRT. Once an event has been detected and reported, the responsibilities shouldbe allocated and the procedures for each notified person should be distributed.

Responses This phase involves the making of responses to incidents accordingto the actions agreed in the preceding phase. The ISIRT should determine if theincident is under control and then assign internal resources and identify externalresources that can provide appropriate actions. In some cases, escalation to crisishandling might be necessary. Once the responses have been agreed, every actionconducted should be logged and thorough documentation should be created. Thiswould be used to evaluate the effectiveness and efficiency of the incident responseprocess. After handling the incident the case should be closed and recorded in thedatabase managed by the ISIRT.

Lessons learnt This phase follows once an incident has been closed. It involvesan analysis on the actions taken and learning from them. Organizations shouldreview the effectiveness of the processes, procedures, and reporting formats in orderto make improvements to the incident management scheme and its documentation.Improvements should be made also to the risk assessments. Sharing results within atrusted community is encouraged.

3.2.4 ISO/IEC 27036-*:2013+ Information security for supplierrelationships

ISO/IEC 27036:2013+ is a multipart security guideline for supplier relationshipsincluding the relationship management aspects of cloud computing. Here is anintroduction to the ISO 27036 standard parts 1, 2 and 3, the content is, unlessspecified otherwise, derived from [ISO14a] [ISO14b] [ISO13c].


The standard provides an overview of the guidance intended to assist organizationson the evaluation and treatment of the information security risks that concern theprocurement of goods, services and works from an outside external source (suppliers).It provides guidelines to acquirers and suppliers for managing information securityrisks associated with the ICT products and services supply chain. It also addressesinformation security risks such as protection of third party information assets, sharedresponsibilities, coordination between supplier and acquirer to adapt or respond tonew and changed information security requirements.

3.2.5 NIST Special Publication 800-61

This standard [NIS12] provides guidance on how to establish effective incidentresponse capabilities. It include guidelines on building capabilities such as creatingan incident response plan, developing a policy and procedures for incident handlingand reporting, building a team structure, selecting a staff model and planning stafftraining. It also provides guidance on the Computer Security Incident ResponseTeam (CSIRT) interaction with external parties such as vendors, other CSIRTs,Internet Service Providers, customers, media and law enforcement agencies.

The primary focus of the standard relies on the incident response life cycle whichmajor phases are (see Figure 3.2):

– Preparation

– Detection and Analysis

– Containment, Eradication and Recovery

– Post-Incident Activity

3.2.6 ENISA – Good Practice Guide for Incident Management

The guide [MRS10] provides good practices for security incident management. Itdescribes the creation of a Computer Emergency Response Team (CERT), its mission,constituency, responsibility and the type of services that can deliver. It providesinformation on roles, workflows and policies to deliver a successful incident handlingservice. It discusses cooperation with external parties and how to get and keep themanagement involved as success factors.

This guide makes emphasis on incident handling and describes the incidenthandling process, which involves four components (see Figure 3.3):

– Detection

3.3. FORTHCOMING STANDARDS 21

Figure 3.2: Incident Response Lifecycle, modified from [NIS12]

Figure 3.3: Incident Management and Incident Handling, adapted from [MRS10]

– Triage

– Analysis

– Incident response

3.3 Forthcoming standards

This section presents relevant forthcoming standards containing information regardingincident management in outsourcing settings.


3.3.1 ISO/IEC 19086-* Service Level Agreement (SLA)framework and Technology

This is a multipart standard that will provide an overview of Service Level Agreementsfor cloud services. The current drafts [ISOa] [ISOb] [ISOc] address SLA conceptsand requirements to build SLA’s. It aims to establish common building blocks thatcan be used to create SLA’s facilitating a common understanding between the CloudService Providers and their customers. The drafts also specify metrics commonlyused in SLA’s for cloud services.

3.3.2 ISO/IEC 27017 Code of practice for information securitycontrols based on ISO/IEC 27002 for cloud services

This standard will provide directions on the information security elements of cloudcomputing, for cloud service providers and its customers. The current draft [ISOd]describe on information security roles and responsibilities the importance of theproper definition and documentation of the demarcation of responsibilities of cloudservice customer, cloud service supplier and its suppliers as well as the review andconfirmation of this responsibilities by the customer.

The working draft describes the issues with ambiguous information securityroles and responsibilities. The content is derived from [ISOd]: Ambiguity in thedefinition of responsibilities related to issues such as data ownership, access controland infrastructure maintenance, may give rise to business or legal disputes, especiallywhen dealing with third parties.

3.3.3 ISO/IEC 27035-* Information security incidentmanagement

The standard ISO/IEC 20735:2011 is currently being revised and extended. It willbe divided into three parts:

– ISO/IEC 27035-1 Information security incident management – Part 1: Principlesof incident management The current draft outlines basic concepts and phases ofinformation security incident management. The following description is derivedfrom [ISOe]:The five phases of incident management are:

◦ Plan and prepare: Establish all that is required to operate adequatelyinformation security incident management, such as establish incidentmanagement policy, establishing an Incident Response Team, etc.

◦ Detection and reporting: Spot and report information security events thatcould be or convert into information security incidents.

3.4. FRAMEWORK OF STANDARDS RELATIONSHIPS 23

◦ Assessment and decision: Evaluate and determining if it is genuinely aninformation security incident.

◦ Responses: Forensic analysis, contain, eradicate, recovery and furtherforensic analysis, where appropriate.

◦ Lessons learnt: Improve the incident management scheme, informationsecurity, and risk assessment as a consequence of the experience obtained.

– ISO/IEC 27035-2 Information security incident management – Part 2: Guide-lines to plan and prepare for incident response The current draft [ISOf] intro-duces the concepts to plan and prepare for incident management capabilities.It covers recommended requirements to be adopted by organizations in orderto respond appropriately to information security incidents.

– ISO/IEC 27035-3: Information security incident management – Part 2: Guide-lines for incident response operations. The current draft [ISOg] offers directionson managing and responding competently to incidents. It also covers IncidentResponse Team’s organization, formation, operation roles, responsibilities andpractical activities. Annexes include examples of incident criteria based oncomputer security events and incidents as well as examples of informationsecurity events, incident and vulnerability reports and forms.

3.3.4 ISO/IEC 27036-4: Guidelines for security of cloud services

The part 4 of the standard ISO/IEC 27036 has not been published by the date ofthe creation of this document. According to the working draft [ISOh], it will provideguidance to cloud service acquirers and suppliers aiming to improve the security ofcloud services by increasing acquirers’ awareness of the information security risksassociated with cloud services, and enabling cloud service providers to persuadeacquirers about the identification and management of information security risksrelated to the services they provide.

3.4 Framework of standards relationships

The standards and guidelines ISO/IEC 27035, NIST SP 800-61 and ENISA’s GoodPractice Guide for Incident Management resemble each other presenting a diversenumber of similarities. Even though they have different phase descriptions, theyprovide similar activities that should be considered while following the standardsand guidelines.

ISO/IEC standards are developed internationally by worldwide experts in workinggroups and committees. Therefore a major emphasis on those standards and workingdrafts is presented at this work.


Figure 3.4: Framework of published and forthcoming standards

After finding that most of the material regarding incident management in out-sourcing settings is dispersed or planned to be published in the future, a frameworkof related ISO/IEC standard relationships was created to provide a broad perspectiveon the topic. The framework shows the relationships on the current standardsand the forthcoming ones. This framework can be used as a reference to identifythe relationships between the information described in this section and to provideguidance on incident management in outsourcing settings. (See Figure 3.4):

The figure shows inside the bubbles the published standards and inside rectanglesthe forthcoming standards. The arrows coming from the forthcoming standards tothe bubbles indicates which published standards will be complemented with extrasections or by providing guidelines to specifics aspects related to the general topicaddressed in the published standard(s).

The standards ISO/IEC 27001 and ISO/IEC 27002 provide good practices thatare used as a reference for information security incident management (ISO/IEC27035:2011). The standards ISO/IEC 27036-(1, 2 & 3):2013+ provide guidance onthe evaluation and treatment of information security risks concerning third parties.These guidelines should be considered when performing information security incidentmanagement and therefore its relationship with ISO/IEC 27035:2011.

3.5 European ongoing developments

This section introduces relevant projects addressing directly or indirectly challengesregarding incident management in outsourcing settings.

3.5. EUROPEAN ONGOING DEVELOPMENTS 25

3.5.1 European Cloud Computing Strategy

This strategy [EC 12], was launched in September 2012. It aims to identify waysto maximize the potential offered by the cloud . In June 2014, one of the workinggroups for the implementation of strategy: The Cloud Select Industry Group onService Level Agreements issued a set of Service Level Agreement standardizationguidelines for Cloud Service Providers and professional Cloud Service Customers.The guidelines aim to provide a set of principles to assist organizations, throughthe development of standards and guidelines for cloud SLAs and other governingdocuments.

This section describes some Service Level Objectives (SLO) relevant to the casestudy. The content is, unless specified otherwise, derived from [EC 14]:

4.4 Security incident management and reportingDescription of the context or of the requirement

An information security incident is a single or a series of unwanted or unexpectedinformation security events that have a significant probability of compromisingbusiness operations and threatening information security. Information securityincident management are the processes for detecting, reporting, assessing, respondingto, dealing with, and learning from information security incidents.

Description of the need for SLOs, in addition to information availablethrough certification

How information security incidents are handled by a cloud service provider isof great concern to cloud service customers, since an information security incidentrelating to the cloud service is also an information security incident for the cloudservice customer.

Description of relevant SLOs Relevant SLO’s and their requirements:

– Percentage of timely incident reports Describes the defined incidents to thecloud service which are reported to the customer in a timely fashion.This is represented as a percentage by the number of defined incidents reportedwithin a predefined time limit after discovery, over the total number of definedincidents to the cloud service which are reported within a predefined period(i.e. month, week, year, etc).

– Percentage of timely incident responses Describes the defined incidents that areassessed and acknowledged by the cloud service provider in a timely fashion.This is represented as a percentage by the number of defined incidents assessedand acknowledged by the cloud service provider within a predefined time limit


after discovery, over the total number of defined incidents to the cloud servicewithin a predefined period. (i.e. month, week, year, etc)).

– Percentage of timely incident resolutions Describes the percentage of definedincidents against the cloud service that are resolved within a predefined timelimit after discovery.

3.5.2 Cybersecurity Strategy

The strategy [EC 13] was published in February 2013, aiming to safeguard an onlineenvironment providing the highest possible freedom and security and protectingpersonal data and privacy. Once implemented, data controllers will be covered by arange of security obligations such as notification of incidents, risk management andparticipation in coordinated responses.

3.5.3 The Cloud Accountability Project (A4Cloud)

Pearson et al. [PTC+12] describe that this project aims to assist holding each cloudprovider accountable for how it manages, uses and passes on data and other relatedinformation, such as personal, sensitive and confidential information. The projectcombines socio-economic, legal, regulatory and technical approaches.

Accountability The Merriam-Webster dictionary defines accountability as: “anobligation or willingness to accept responsibility or to account for one’s actions”.Accountability is a simple idea defined as “not only should an organization do ev-erything necessary to exercise good stewardship of the data under its control, itshould also be able to demonstrate that is doing so” [Pea14]. This demonstrationis done by providing detailed information and evidence of the organization’s ac-tions. Papanikolau et al. [PP11] describe the notion of accountability by regulatoryframeworks, as a data protection model, which is moving to ‘end-to-end’ personaldata protection governance in which the entity that collects the data from the datasubject is accountable for the data use and distribution from collection to disposaland during its transit around the globe. Moreover, governance and complianceframeworks such as ISO/IEC 27001/27002 contain elements of accountability suchas assurance, transparency and responsibility. For instance the following controlsrequire attribution and separation of responsibility:A.7.1.2 Terms and conditions of employment, which states that “The contractualagreements with employees and contractors shall state their and the organization’sresponsibilities for information security.”A.7.2.1 Management responsibilities, which states that “Management shall requireall employees and contractors to apply information security in accordance with theestablished policies and procedures of the organization.”

3.6. INCIDENT MANAGEMENT MODELS 27

A.7.3.1 Termination or change of employment responsibilities, which states that “In-formation security responsibilities and duties that remain valid after termination orchange of employment shall be defined, communicated to the employee or contractorand enforced.”

Pearson refers to the importance of accountability as follows: “It is important torealize that accountability complements privacy and security, rather than replacingthem. If organizations are accountable, they need not just to define and implementprivacy and security controls where appropriate, but also define and accept respon-sibility for so doing, show that they are in compliance with privacy and securityrequirements, and provide remediation and redress in case of failure.”[Pea14]

3.6 Incident management models

Models of operation and human resource models for CERTs are briefly addressed inthe Good Practice Guide for incident Management from ENISA [MRS10]. Based onthat information, the incident management models were classified according to howorganizations may manage capabilities, personnel and expertise (See Table 3.1).

CapabilitiesAt organization’s side At provider side Outsourced

ExecutionFull-time Full-time Partially outsourcedPart-time Part-time Fully outsourced

Virtual team Virtual team

Table 3.1: Incident management models

– Incident management is executed at the organization side. This model iscommon on big size organizations and might coordinate also the incidentmanagement on the organization’s third parties when third parties are smallsize companies.

◦ Full time incident response team. In this model the team personnel arefully dedicated to incident response tasks.

◦ Part-time incident response team. This model is usually taken whenteam members perform not only incident response tasks but also otherresponsibilities inside the organization.

◦ Virtual team. In this model the personnel is full-time dedicated to differentresponsibilities and is gathered only to handle an incident.

Each one of these models could be implemented having also collaboration fromexternal experts.


– Incident management is executed at the provider side. This model might betaken by organizations with limited expertise on incident management, lettingthe supplier taking care of coordinating the incident response.

◦ Full time incident response team. In this model the team personnel arefully dedicated to incident response tasks.

◦ Part-time incident response team. This model is usually taken whenteam members perform not only incident response tasks but also otherresponsibilities inside the organization.

◦ Virtual team. In this model the personnel is full-time dedicated to differentresponsibilities and is gathered only to handle an incident.

Each one of these models could be implemented having also collaboration fromexternal experts.

– Outsourced incident management. This model is taken by organizations thatwant to concentrate on core goals or in some cases cut costs.

◦ Incident management or incident response are partially outsourced. Thismodel is taken to avoid delivering a particular service, when in-depthexpertise is needed or when there is a lack of qualified personnel.

◦ Incident management is fully outsourced. This model is executed by athird party providing incident management to the organization and maybeto the supplier too if this one has adopted the same model.

Chapter4Case Introductions

4.1 Case A

The organization studied in case A is a Norwegian network (service provider) operator.Throughout the rest of this project, the organization in this case will be referredto as Organization A. The interviewees were the current and former leader of theComputer Emergency Response Team (CERT). Both of them have about 20 yearsof experience in incident management including both technical and administrativetasks. They were part of the first CERT team in Norway and pioneers in this field.They have mentored other Incident Response Teams and also encouraged them toget into international organizations like the Forum of Incident Response and SecurityTeams (FIRST).

Organization A is a network provider coordinating the incident response atorganizations with limited expertise on incident management. It has a part-timeincident response team. Organization A’s incident management model is executed atthe organization’s side when in-house incidents are handled. However, for most ofthe organizations that receive services from Organization A, the latter is the one thatcoordinates the incident response for the former ones. In other words, OrganizationA behaves as the provider in the provider side model, for the organizations thatreceive services from Organization A (See Table 4.1). The interview was mainlyaddressed taking into consideration the provider side incident management model.


ExecutionFull-time Full-time Partially outsourcedPart-time Part-time Fully outsourcedVirtual team Virtual team

Table 4.1: Incident management models in Case A.

29

30 4. CASE INTRODUCTIONS

4.2 Case B

The organization studied in case B provides a secure network to exchange informationin one of the national industry sectors in Norway. Throughout the rest of this project,the organization in this case will be referred to as Organization B. The intervieweewas the leader of the Computer Security Incident Response Team (CSIRT).

The interviewee has had two years of experience in incident management includingboth technical and administrative tasks. Besides, the interviewee has had 14 years ofexperience performing malware analysis and implementing new detection techniquesin a different organization.

Organization B’s model is incident management executed at the organization side.It has a full-time incident response team (See Table 4.2). Some incidents have beenmanaged in cooperation between IRTs in the organization and in the third party.




Table 4.2: Incident management model in Case B.

4.3 Case C

The organization studied in case C belongs to the public sector. Throughout therest of this project, the organization in this case will be referred to as OrganizationC. The interviewee used to hold there the Head of Information Technology (IT)department job position.

Organization C’s model is incident management executed at the organization side(See Table 4.3). It has a part-time incident response team.


ExecutionFull-time Full-time Partially outsourcedPart-time Part-time Fully outsourcedVirtual team Virtual team

Table 4.3: Incident management model in Case C.

4.4. EXPERT 1 31

4.4 Expert 1

Throughout the rest of this project, the expert in this case will be referred to asExpert 1. The interviewee was the Chief Information Security Officer from hisorganization and the leader of incident security response capabilities. He has beendealing with incidents for about 5 years where he has acquired experience in incidentmanagement being a manager and supervising teams in Norway. The intervieweehas also worked as a technical expert in incident response and as a consultant wherehe has been pulled in for incident response. The interviewee is considered a technicalexpert when dealing with incidents in an organization.

Outside his day job, he runs his own company providing support while dealingwith incident response and penetration testing. These activities are performed basedon his time availability.

Expert 1 works full time in an organization which model is Incident managementexecuted at the organization side. But his own company provides incident responseservices as an outside specialist to companies which model is Incident managementpartially outsourced (See Table 4.4).




Table 4.4: Incident management models where Expert 1 is involved.

4.5 Survey

The Survey was performed with the participation of people with different roles inincident management teams, from a diverse set of organizations, during a course onIncident Response Team Management at the security conference Sikkerhetssymposiet2014 in Norway. The course leader introduced the survey to the 10 course participantsand those willing to participate did it, replies from 6 participants where collected.

Chapter5Findings

This chapter presents findings from the case study. The findings from each case aredescribed separately. The information described here is presented as given in theinterviews. The findings are organized based on the phases of the standard ISO/IEC27035 presented in section 3.2.3; the lessons learnt phase as well as the assessmentand decision phase were not addressed during some of the interviews and thereforeare not presented in the respective case’s findings.

5.1 Case A

This section describes findings from Case A, where the interviewees were the currentand former leader of the Organization A’s CERT. Organization A’s CERT performsin-house incident handling most of their time and occasionally performs incidentcoordination supporting the institutions that receive services from Organization A.Whenever the institutions getting services from Organization A have experiencedincidents through these services, Organization A has kept the responsibility, hasinformed the affected institution and coordinated with it incident response activities.

5.1.1 Plan and Prepare

Organization A is producing best practice documents, open and available to everybody.These best practice documents are produced to the needs of the institutions gettingservices from Organization A. An Information Security Policy template has beencreated already and used in processes to aid the organizations and institutions thatreceive or acquire Organization A’s services with getting an information security inplace. The security policy template is based on ISO/IEC 27001 and ISO/IEC 27002and it has been summarized to a convenient and workable level (25-30 pages). Itcombines legal requirements and best practices for information security management.

Training and awareness has been provided, the last time was done from 2006 to2009, covering most of the institutions getting services from Organization A. During

33

34 5. FINDINGS

that time, when the training and awareness exercise was performed, OrganizationA’s CERT had the ambition to push some of the training’s participant groups intoIncident Response Teams. This effort was not successful, only one team appeared.The former leader of the CERT stated:

“In retrospective it was a little bit premature at that time. Now thetime is there. Instead of us pushing the course on them, they are askingfor it. This is a big difference.”

Organization A’s CERT knows that the effort to train the institutions gettingservices from Organization A, have provided to the institutions with the knowledgeto evaluate what type of incident response is needed, how to react, not to panic, andall the necessary steps to do containment as well as to bring back an attacked systemto a clean state. However, some of the people exposed to the training back then, arenowadays somewhere else; they do not hold the same job positions.

Now, the new training and awareness plan from Organization A’s CERT is to runa new course for the biggest institutions getting services from Organization A. Theseinstitutions might have enough resources to develop their own Incident ResponseTeam (IRT). After the planned course, Organization A’s CERT will evaluate theoutcome and if this strategy is successful and the willingness to participate spreadsinto the sector, they will make a series of courses.

Regarding cloud services, the former leader of the CERT stated:

“Today there is a clear migration to cloud services. We try to buildup for this information leakage, as we consider moving confidential datato any cloud service business. The responsibility is to the cloud service’scustomers. It is up to them to make sure that the cloud owner is handlingthe data correctly. You can’t do incident handling at cloud providers; it isa matter of what kind of agreements you have with them. Unfortunatelythe last version of the training do not contain any recommendations onthis topic . It is something that should be implemented in the future.”

Roles and responsibilities should be documented, which is not necessarily the case.Some institutions, getting services from Organization A, are exposed to standardterms from cloud service providers (take it or leave it). Organization A recommends:

– Do not accept standard terms immediately

5.1. CASE A 35

– Use common sense

– Think about any situations that can arise and try to make rules that resolvethem

– State clearly that any issue with sub-vendors is responsibility of the vendornot the client

Regarding responsibilities that have not been defined beforehand, the formerleader of the CERT stated:

“There is always an entity owning the problem. It is like an illness,you can’t say I have cancer it doesn’t regard me. It’s your problem. IfI have no agreement beforehand I would try to do anything that wouldhelp me getting off. The owner of the data is the one responsible for theproblem if it is not stated anywhere.”

Some recommendations to react to this situation were:

– A catch-all clause

– Use insurance companies

5.1.2 Detection and Reporting

Detection, at the Organization A’s premises, is occasionally done through complaints,but mainly by their own systems reporting anomalies. There are a number of sensorslistening to anomalies. The challenge here is to update them. There is constantlynew ways to hack systems or new signatures. It is important to run after the peopleperforming the updates. The current leader of the CERT stated:

“It is a matter of fact that attackers will be always ahead of us.”

Institutions that receive services from Organization A vary on sizes. Some ofthem are small and do not have an incident response team. The communication isusually clear about who to contact regarding an incident. In general, every institution,including those that acquire services from Organization A, should have a securitycontact; they do not necessarily need to have a team. The former leader of the CERTstated:

36 5. FINDINGS

“A fire can happen in every house, not every house should have theirown fireman, but they should know how to react when the fire sets in,same thing here.”

Organization A’s CERT has trained personnel at the institutions that get servicesfrom Organization A. The trained personnel are not an incident response team assuch, but they know themselves what to do. It has rarely happened that a hackedsystem could go for a long time without the intrusion being detected, it is discoveredsooner or later.

5.1.3 Assessment and Decision

Organization A’s CERT provides support to institutions getting services from Orga-nization A. Support includes, but is not limited to determine what hits them andhow serious is the incident. The former leader of the CERT stated:

“We try to give them information to do wise decisions.”

The common problem in this phase is that the systems in place are gettingoutdated; the current defenses might not be working anymore because the attackersare using new strategies. The challenge is keeping updated with new developments.

Organization A has a strong trademark and the institutions getting services fromOrganization A have a strong trust over it. The institutions are not afraid to revealinformation (even more than what they should) about their infrastructure to handlethe incident. The former leader of the CERT stated:

“Trust is not something you can demand, it is something that youearn. It takes time to build trust and it can be loss in one minute.”

5.1.4 Responses

Some challenges that Organization A’s CERT perceive in this phase are:

– Some institutions getting services from Organization A have no experience inincident handling, no time to think about it and no resources.

– Lack of expertise in general.

5.1. CASE A 37

In such cases, where institutions getting services from Organization A are sosmall, the institution’s IT team knows how to operate IT services to a minimum level,the lack of experience in incident handling is temporarily solved by OrganizationA’s CERT help. This help consists on assisting them with preventive measures likepacket filters and awareness on how to build some protection. If an incident occurs,Organization A’s CERT supervises them, coordinates the incident and helps themout providing advice about what should be done.

The former leader of the CERT stated:

“95% of the incidents that hit you haven’t seen before.”

Organization A’s CERT do not perform incident handling at the premises ofinstitutions getting services from Organization A. Organization A’s CERT consistsof six people doing incident management and incident handling on a part time basis.

Organization A does not only provide services, it also get services from a thirdparty. Organization A outsources its accounting system as well as its publishingsystem. There has not been the need to manage any incident with the provider. Thismight be a consequence of the Organization A’s CERT performing checkups on theservices and if it is found that they are lacking behind, they ask the provider to fix it.If there are critical holes that can be exploited, they need to be fixed immediately.It is important to have an agreement on updating the systems in use or that areoutsourced. The time frame from getting the discovery until it is fixed is a concern.

Organization A’s CERT considers that services such as log analysis and preventionnature services, could be outsourced in the future. The former leader of the CERTstated:

“Outsourcing incident management is not a common way of doingit in this country, because we are quite small, what is a big company inNorway is a small company in the United States for instance. However,there will be a team established that will provide services in the street. Youwill be able to buy incident management and incident handling servicesfor a yearly fee. It will happen sooner or later, even in Norway. Thereare already others doing it. Norway is not lacking technical expertise, butstill it is a small country.”

38 5. FINDINGS

5.2 Case B

This section describes findings from case B, where the interviewee was the leader ofthe Computer Security Incident Response Team (CSIRT).


Everyone that connects to the Organization B’s network should follow a code ofconduct which includes different kind of security needs that need to be fulfilled to getaccess to the network. The code of conduct is developed cooperatively by participantsfrom different entities that belong to the Organization B’s sector, including the entitiesthat have access to the Organization B’s network. It is not only a policy comingfrom the top to the entities. Every entity has contributed on the code of conduct.This peer participation makes them follow it on a strong way. Besides, OrganizationB’s CSIRT performs frequent revisions or audits into the organizations to verify ifthey are following the code that they committed to follow.

Organization B’s CSIRT has created an incident mailing list for almost eachorganization that has access to its network, in order to notify them about incidentsand in some cases to provide them with information such as updates, patches, etc.The incident mailing list is still on process. However, Organization B’s CSIRT is nowable to save time by using it. The interviewee commented:

“At the beginning we did not have mailing lists and we only had sortof database with contact points. Then, we needed to look out through allof them to find out whom to send the information.”

Building the incident mailing list has taken time and it is still not finished. Havingcontact points in all the organization is one of their current challenges, especially insmall organizations. The interviewee commented:

“We don’t have good contact points for all the organizations that wewould like to have. That is something we have been focusing on, buildingup contact points in all the organizations where we need to have them. Thechallenge is to make sure that those receiving the information understandit and act as they should on handling the incident.”

Organization B’s CSIRT has focused on getting contact points with roles in eachorganization to avoid personal relationships instead of organizational relationships.It is more common to find these roles in big organizations than in small ones. Smallorganizations might not have all the technical experts that they should have.

5.2. CASE B 39

Organization B’s CSIRT is planning to have some experience-sharing workshopswith the large organizations. Most of these organizations face the same challenges.Therefore, sharing experiences with each other will provide them with differentapproaches to solve their issues and to contribute to each other’s capabilities. Anothergoal is to obtain some feedback about what these organizations need in order toprovide them with better capabilities.

Organization B’s CSIRT sends advices to all the entities and organizations thatbelong to its network were they have a contact point. The advices are related to newthreats and vulnerabilities, procedures to patch the systems, etc.

Some of the entities that connect to the Organization B’s network use devicesthat are provided by third parties to the entities. The third parties providing thesedevices require having a Virtual Private Network (VPN) or having capabilities toplug external memory devices such as USB drives to be able to update the device.Organization B’s CSIRT is working together with the entities to secure the connectionpoints to the third parties. The interviewee stated:

“There has been news regarding third parties that have copied out,by accident, a lot of sensitive information from devices provided to anorganization. It was not their intention to do it. The third party evenwas reporting it and was making sure that they were telling exactly whathappened and how they deleted the information. But still, it shows thatsensitive information was able to leak out of that organization via a thirdparty’s product.”

The third party’s devices plugged to the Organization B’s network are mostly inclosed networks, which is quite secure when it comes to third parties having accessinto the network. According to the interviewee the third parties are afraid of takinginformation from the Organization B, but still it is important to make sure thatthere is full control of the information they can have access.


The Organization B has a close network where all the authorized entities are connectedto the network. Within the network there are a lot of sensors such as IntrusionDetection Systems (IDS) to monitor all the network traffic within the network.Organization B’s CSIRT has been able to discover incidents within its network usingthe sensors and then reporting to the entities or organizations affected.

40 5. FINDINGS

There have been difficulties to get the sensors placed in every location, but nowthe sensors are located at all the relevant places. There are personnel digging intothe logs received and developing new rules for the sensors to detect new incidents.

Most of the sensors findings are general malware that is hitting everyone, such askey loggers, banking Trojans, etc., which is written by criminals trying to get moneyby getting access to bank access credentials. In average this kind of malware infectseveryday one client of the Organization B’s network.

Organization B’s CSIRT has built up a mechanism to process all the logs receivedto be able to work as smart as possible and discover as much as possible with relativelyfew resources. Their strategy has been to automate as much as possible to discovernew incidents. The interviewee commented:

“We try to automate and use as little time as possible in order tospend more time digging deeper into the logs and doing more research todiscover new kind of threats. We have already a method to discover thekind of threats that we are discovering now. What we aim is to developnew methods to discover more type of threats.”

Once that incidents are detected these are reported to the contact points. Inaddition Organization B’s CSIRT is also doing vulnerability scans of the network.When vulnerable systems are found, notifications are provided to the organization’scontact points as well as recommendations about what to do.


Organization B’s CSIRT helps the entities inside the Organization B network toanalyze their logs and figure out what is going on. That is something that has beendone quite often. This analysis has in some cases required to sit down together withother incident teams all day and night long, to fully figure out what was going on,what kind of incident was it and how to mitigate it. In many cases having a sensorat the entity’s location has definitely provided extra help to find more informationabout the incident.

Whenever it is needed Organization’s B CSIRT has join other CSIRT, CERTor IRT outside the Organization B, providing experts that could offer assistance inassessing and solving an incident.

5.2. CASE B 41

5.2.4 Responses

Organization B’s CSIRT provides with assistance and recommendations while workingwith third parties IRT’s. However, all decisions related to the infrastructure of theorganization are taken by those who know it. The interviewee commented:

“We are not coming to join their organization and to tell them: Youhave to do it this way. We always try to make sure that they perceive thatwe are doing it together. We need to be open minded.”

One of the challenges that Organization B’s CSIRT perceive in this phase is thatpeople working only part time in incident teams usually do not know all the routinesand communications channels.

5.2.5 Lessons learnt

It is important to make sure that everyone knows the routines and to have the timeto make some exercises. It is not very difficult it just need to be done.

The use of logs is something that does not necessarily require many resources,but it helps a lot when having an incident. By looking at the logs, informationabout what kind of damage has been done, information that has been leaked andhow did the incident got in the organization can be found. Organization B’s CSIRTencourages the use of logging mechanisms as much as possible. If there are not anylogs available, there is no way to prove anything. It is very important to be able toverify the information of an incident.

Organization B’s CSIRT has a good national and international contact networkin the information security field. This network provides them with useful informationfrom different kind of domains. The interviewee stated:

“Sharing information with others makes ourselves much better, be-cause we get information back. It is important to cooperate with otherorganizations. It is very useful to have open discussions and try to shareas much as possible. Trust is very important; if people see that they cantrust you and that you deliver good stuff you typically get good stuff back.We are having meetings and data communication channels with otherCERT’s and different kind of security organizations in Norway. We havebeen using our Internet Relay Chat (IRC) and we talk daily with peopleat the information security community.”

42 5. FINDINGS

Organization B’s CSIRT is planning to perform penetration tests within theorganizations to discover weak points or weak solutions that are vulnerable. Thegoal is to use the information that is already obtained by the vulnerability scans tosee what can be exploited and must be patched or modified. Nevertheless, a strategyto summarize some penetration tests and get lessons learned from the tests should beused to identify what should be improved at the organizations within OrganizationB’s network.

5.3 Case C

This section describes findings from Case C, where the interviewee used to hold therethe Head of IT department position.


Communication paths and awareness should be properly planned. Regarding theawareness the interviewee stated:

“You don’t want people thinking that you are paranoid, when you aresimply treating the security issues seriously.”

The Incident Response Team should include staff from the third party. Thereshould be clear documentation where it is stated who is responsible for an incident,when to report, how to handle it and who are the people involved. The owner of thedata is the one who is held responsible, therefore should be reported about everysingle incident.

Overlapping roles could be an issue between the third party security staff andthe company. This should be clarified in order to have a cooperative work and makeeach other stronger.


In some cases the role defined to receive the reports from the third party might nothave a proper communication internally (e.g. security department confronting ITdepartment). This should be thoroughly considered during the previous phase tomake the detection phase more agile.

5.3.3 Responses

Dealing with critical and complex systems could be challenging especially when youneed to correct or patch them. There should be some way to test that the patch

5.4. EXPERT 1 43

would not lead to new incidents coming out from this solution. The intervieweestated:

“I have seen that in some cases implementing a solution can be delayedfor weeks due to the lack of knowledge on dealing with complex systems.On the other hand there are also some cases where people do not dare topatch at all.”

5.4 Expert 1

This section describes findings from Expert 1, where the interviewee was the expertholding the Chief Information Security Officer (CISO) position.


Expert 1 described that having an incident response policy defined including a thirdparty, such as ICT service’s providers, is essential. Documentation is extremelyimportant, as long as it is not dead documentation that is never updated or read.The amount of planning and preparation for this commitment depends on what thescope is. The scope should include what type of incidents needs intervention fromthe third party, what type of interventions are needed from the third party and whatis expected to be covered by the third party. Setting up the scope is very importantwithin the policy. The policy should include some definition of what kind of eventsare considered security incidents and which are not related with security incidents.Because a third party coming into a different organization would be clueless of whatis normal, what is accepted and what is not. Scoping is extremely important, whenit comes to develop this documentation.

Expert 1 suggests that procedures should be built point by point specifying whatcan be applied to some third party. He encourages looking at what are the acceptablerisk limits for the organization and then adapting the responsibilities and roles in theincident response effort, considering what is expected from the third party to comewith. There is a lot of preparation work that needs to be done before committing toa third party. Some of the requirements that definitely need to be written down andset as a policy for the commitment are:

– How would the outsourcing organization be evaluated?

– How would the organization know if the third party is doing its job?

– What kinds of incidents are expected to be identified by the third party?

– What kind of reporting and notification is expected from the third party?

44 5. FINDINGS

It is important to properly scope the third party engagement and not consider somekind of clause describing that they should detect everything, if that is the case thenthe organization needs to make sure that the third party has the ability to enforcetheir incident response capabilities. Then, it is crucial to have some way of testingthe third party incident response capabilities. The incident management team shouldknow if the third party is actually responding when they should respond. These canbe tested to measure that the policy and the SLA agreement are being accomplished.

It is recommendable to properly define in the SLA the expectancies of the thirdparty services (e.g. cloud service providers). SLA’s should cover:

– Notification of incidents

– Time to detection

– Speed on response after an incident occurs

– Accepted limit of reoccurrence for an incident

If this is not included into the provisioning services when the organization ispurchasing something and before signing the contract, it would be much harder toget it afterwards. It would be very valuable and would help to have some assurancethat the third party will follow up on the incident after its occurrence. Before theorganization signs the contract, it has the advantage of the contractual negotiation,but after the contract is signed, there is no contracting bargain until the contractis up for renegotiation or it is running out of time. Today there are cloud serviceproviders and internet service providers rising up everywhere from small companiesand medium companies and everyone wants to provide some kind of services. Thequality from these new companies would be very varied. Therefore, is essential toensure some kind of security expectations into the contract.

The contract should include a clause stating that the organization is allowed toexercise the right to test the capabilities of the incident response of the third party.Contracting agreement with a third party should not involve long term contractsthat are not negotiable over time.


Expert 1 described that in this phase the goal is to identify which events can provethat there is an incident going on, identify false positives and know when to declare anincident or not. Within identification there are some big uncertainties and unknowns,all of them are anomalies. The challenge here is to identify which incidents are not

5.4. EXPERT 1 45

being spotted and how would a third party help to detect more incidents. It isimportant to review the following questions:

– What if the third party does not detect incidents?

– How many incidents are being detected by the third party?

– How many are not being detected by them?


Definitely is hard for the third party to come in and help identifying the incidents,because they do not know the organization and they will not be able to fullyunderstand the business, the drivers and operational drivers. Besides, according towhat is defined in the scope there might be privacy, legal and compliance concerns.For example:

– How will a third party capture Random Access Memory (RAM)?

– Is some kind of VPN access required?

– How is the third party applying the organization’s privacy and compliancesettings?

However the third party organization might ask the organization to collect thevolatile data for them.

5.4.4 Responses

Expert 1 describes that is essential to determine what type of containment capabilitiesthe third party should bring to the team. Is the third party allowed to changeanything? If they are, has the organization properly integrated the third party intothe change management structure? What if the third party does not understandthe business and operational drivers well enough? What if the third party affectssomething and make the incident worse, if they for example shut down a system or ifthey remove the wrong files, are these risks considered?

Expert 1 explained that when he performs incident response for other companiesit is harder than working internally. The challenge as a third party is to separatewhat actually matters in the incident from everything else that is just noise.

“It is comparable to getting into a black box system most of the time,there is some kind of problem that needs to be detected and solved. This

46 5. FINDINGS

might seem like a jungle of IT systems everywhere. It is not a clear picturelike the one you might have while working internally for an organizationwhere probably you are already familiar with a lot of those systems frombefore.”

A third party will be very careful doing eradication, because if they ever doanything wrong, they might be held accountable for that for a very long time.Perhaps the third party’s mistakes would not be as accepted as it would be if aninternal employee has done the same mistakes. That is very typical with consultants;they have a less risk appetite than the internal employees for the work done. Thethird party actions in this phase rely on the scope previously defined.

Another challenge is the process of communication with the third party regardingthe containment and eradication, for example a change in some of systems (e.g. avery precise and high quality patch), making sure that things are done right andhaving the objectives of this patch not being lost in some kind of translation betweenthe third party and internally in the organization.

According to the defined scope, the incident management should consider howmuch would be expected from the third party to perform recovery, which requires tomake sure that the organization can get the systems back up and running in normalconditions, apply security patches, scan for vulnerabilities of the system, make surethat the attacker can not return and even monitor for the attacker return.

Expert 1 described that when he has performed incident response for othercompanies, he has found that rarely the organizations have well enough technicalprocedures to allow some third party to set up their systems from scratch.

Regarding the reporting actions from the third party, organizations should defi-nitely expect a technical report for the incidents, this report should cover what hasbeen done in the incident, timestamp events that are atomic (describing date andtime of actions taken by every actor involved), probable theories or hypothesis andconclusions. The latter should include the reasons to come out with those conclusions.

5.4.5 Lessons learnt

Following the procedures written in the first phase of incident management, whendealing with incidents and within the lessons learned phase, procedures should berevised and updated with what went wrong to the chain management in order toapply proper changes. Every time that the organization updates the procedures, anotification should be provided to the internal and external teams (including those

5.4. EXPERT 1 47

from the third party) describing why these changes occurred. There are training andawareness synergies that can occur there.

Third parties are expected to bring lessons learned to the table from high damagingincidents, incidents where everything has gone wrong, or incidents that have dragout in time for a very long time. Ideally there should be a lessons learned meetingfor every incident but that might not be feasible. These should be well defined inthe policies and in the SLA.

Expert 1 advises that in case of some kind of disagreement, for example, wherean incident is not being solved due to responsibilities not being defined correctly.First deal with the incident and later look at what actually caused this disagreement.It could have been caused by the introduction of a new system, new technology ornew threat vectors. Then look at how the responsibilities can be changed, so it doesnot happen again. Further defining the agreement with the third party, describingresponsibilities on this type of incidents (whether they belong to the third party ornot), and make sure that there is a common set of expectations.

“I would try to focus my efforts being proactive and trying to be on topof these things before they actually occur. Probably I would create somekind of scenarios to simulate an incident, expecting the third party tonotify me that they are having an incident. If possible, I would go in thereas an observer looking at how they will deal with the mock up incident. Iwould observe how they go forward, what their troubles are, what kind ofinformation they need, how long time it takes, and basically look if theyhave the capabilities to deal with this. This might even be something Icould notify them in advance. Then, when I get the notification, I wouldinform them that it was just an exercise, and that my organization is justmaking sure that they can deal with this type of incidents as stated in thecontract.”

It is important to verify the metrics established in the SLA, taking a look at thetime to detection, the amount of incidents per month, etc. It is important to verify ifthere have been less or more incidents. If there have been fewer incidents than before,then what is the cause? Changes in the threat landscape, new techniques to blockincidents implement or is it a matter of not doing a proper detection job anymore? Ifmore incidents are being experienced than before, the organization needs to identifywhy. It is important to look at these metrics and verify that the third party is doingits job.

Expert 1 described that it is common to find part time incident response teams,especially in Norway, due to the number of small organizations. However, bigger

48 5. FINDINGS

organizations might have a dedicated team. Today a common way of creating incidentresponse teams is to have a virtual team with members from Human Resourcesdepartment, IT operations, system administrators, developers and so on that youonly pull those that you need at that point of time. People with incident responsecapabilities outside their regular job should be notified that they can be pull out onthe fly when need it. They should receive training and their senior management andtheir management need to take into account for a resource that is not working witha regular task. On the other hand the organization, might take in consultants tohelp do that job. One of the reasons of the predominance of virtual teams is money.It is expensive to staff the team full time and it might not be that flexible.

However, working with virtual teams is very much harder than working witha dedicated team. A full time dedicated team would achieve a higher technicalproficiency because they would be used to work with incidents all the time. Anotheradvantage of having a dedicated team is present at cases where sensitive informationis handled (many incident response cases deal with sensitive information). Dedicatedstaff is more devoted to the confidentiality of the case than someone who is justbrought in for this one incident. It is much easier to manage a dedicated team andcoordinate multiple incidents at the same time, as well as re-prioritize the training ofthe staff.

Expert 1 has found in the past, highly insecure applications that his organization’ssuppliers had, which were treated as an incident. He outlined that his organizationhave had some incidents that have been challenging, mainly because of the contractrequirements did not defined what type of availability and what type of reportingnotification were expected.

Nowadays when an attacker is targeting a company, he looks first at the company’ssuppliers. They are the weakest links and the ones who have open tunnels and trustrelationships open from before. Attackers go after the suppliers in order to moveup to the targeted organization, which is their prime target. Once the attackershave broken the supplier’s security, they just pivot through from organization toorganization. Therefore raising awareness of these issues is important to justify theneed for enforcing the incident response capabilities and to establish better policiesand SLA’s with third parties.

Something that is already on the raise is the use of Managed Security ServiceProviders (MSSPs), which are a kind of third party that operates as a securityoperation center for their clients. Clients forward all their traffic and logs into theMSSP systems and they do intrusion detection and analysis on the data and so on.That relationship needs to be very much defined, scoping is even more important.Every organization has still so much to learn from its own systems and data. Not

5.5. SURVEY 49

Figure 5.1: Participants experience with incident management activities.

every business is ready to hire MSSP’s and outsourcing security functions yet.

5.5 Survey

This section describes findings from the survey conducted with six participantsfrom a course on Incident Response Team Management at the security conferenceSikkerhetssymposiet 2014 in Norway.

One third of the participants involved with incident management activities haveaccumulated experience for more than 5 years. Another third have been involvedfor more than 2 years and less than 5 years. At least 2/3 of the participants haveenough experience and can provide a good insight of the current scenario in theirorganizations. (see Figure 5.1)

None of the participants work in a global company. One half of them work in smallcompanies with 100-499 employees. The participants belong to different companysizes, which provides a good overview at from small to medium size companies. (seeFigure 5.2)

The participants perform a diverse set of roles which provides a broad perspectiveon the participants activities involved with incident management capabilities. Someof them have more than one role. (see Figure 5.3)

The organization’s primary industry where the participants work was diverse,which provides a broad perspective on the different sectors and their involvement

50 5. FINDINGS

Figure 5.2: Organization’s size.

Figure 5.3: Participant’s roles.

5.5. SURVEY 51

Figure 5.4: Participant’s industry sectors.

with incident management in outsourcing settings. (see Figure 5.4)

Even that the majority of the participants have not been involved in incidentmanagement in outsourcing scenarios, some of the challenges were identified such as(see Figure 5.5):

– Lack of standards and tools

– Lack of skills, training and/or certification on proper methodology

– Lack of communication

– Lack of established policy

– Repudiation of responsibility from the third party

Most of the participants are not aware that their organizations have had anyincident in an outsourcing setting. But for those who are, they have manage itinternally with a part time incident team. (see Figure 5.6)

Most of the participants are not aware that their organizations have had anyincident in an outsourcing setting. But for those who are:

– They have managed some incidents already over the past two years. (seeFigure 5.7)

52 5. FINDINGS

Figure 5.5: Challenges when managing incidents involving third parties.

– They have managed some incidents already and they consider that they manageit in a marginally effective manner. (see Figure 5.8)

Most of the participants have never seen the roles and responsibilities defined inthe incident management plan regarding third parties. Those who have seen thembelieve that they are well defined, but there overlaps on the roles. (see Figure 5.9)

5.5. SURVEY 53

Figure 5.6: Organization’s approaches to deal with incident management in out-sourcing scenarios.

Figure 5.7: Amount of incidents in an outsourcing setting managed by the partici-pant’s organizations.

54 5. FINDINGS

Figure 5.8: Effectiveness of the participant’s incident management team dealingwith outsourcing settings.

Figure 5.9: Roles and responsibilities defined in the incident management planregarding third parties.

Chapter6Discussion

In this chapter the findings from chapter 5 are analyzed and discussed in the light ofthe research questions presented in section 1.1.

6.1 The research questions revisited

6.1.1 How different organizations perform incident managementwhen third party companies are involved?

Organization A takes a proactive approach and performs tests on the ICT servicesoutsourced. When something wrong is detected, it is handled as an incident andinformed to the provider to solve it. Actions from the provider on updating thesystems are included in the service level agreement.

Organization A’s CERT made emphasis on making sure that the third partiesare handling the data and the incidents correctly. Organization A’s CERT hasrecommended to the organizations and institutions getting services from OrganizationA to not accept standard terms from the third parties and to establish clearly allroles and responsibilities according to their needs.

Organization B has developed cooperatively a code of conduct that needs to befulfilled to get access to the network. This code of conduct is audited. Special actionsare taken for those organizations that have third parties providing them with devicesthat need to be updated through a VPN or by using USB drives. These actions areto make sure that there is full control of the information which the third parties haveaccess to.

Organization B’s CSIRT provides assistance on preventive measures and awarenessto the organization that have access to the Organization B’s network. If an incidentoccurs they are contacted through incident mailing lists. When third parties IRT’s are

55

56 6. DISCUSSION

involved, Organization B’s CSIRT work together with them and provide assistanceand recommendations.

Organization C recommends including staff from the third party to the IncidentResponse Team as well as having documented clearly the responsibilities and com-munication channels. This will benefit the IRT with cooperative work from the thirdparty.

Expert 1 highlights the importance of developing properly the documentation.The incident response policy should be defined including third parties. The policymust include the third party’s expectancies and how would each one of them beevaluated. Procedures must be specific about what applies to the third party. Thethird party engagement should be properly scoped to avoid making all-inclusiveclauses. Otherwise, making sure that the third party has the ability to enforce theirincident response capabilities and evaluating them is needed. The SLA should includethe third party service’s expectancies and their metrics. The contract should includethe right to test the capabilities of the incident response of the third party and shouldnot be a long term contract that is not negotiable over time.

The survey showed that most of the participants are not aware that their organi-zations have had any incident in an outsourcing setting. This results could be causeddue to misinterpretations on the questions. Despite the fact of the ambiguity onsome of the questions, some participants are aware and consider that the incidenthas been managed in a marginally effective manner.

6.1.2 How are the responsibilities distributed?

Whenever the institutions getting services from Organization A have received incidentsthrough these services, Organization A has kept the responsibility and coordinatedwith the affected institution an incident response.

Organization’s A CERT provides assistance on preventive measures and awarenessto the institutions getting services from Organization A. If an incident occurs,Organization’s A CERT supervises them and coordinates the incident response.However, the responsibility of the actions taken is from the institutions.

Organization B’s CSIRT provided no information on agreements and contractsthat could be used to determine how the responsibilities are distributed.

Organization C made emphasis on describing clearly the responsibilities includingwhen to report an incident, and who should be involved.

Expert 1 raises awareness of the issues involving third parties. Raising awareness

6.1. THE RESEARCH QUESTIONS REVISITED 57

is important to justify the need for enforcing incident response capabilities andestablish better policies and SLA’s with third parties. Responsibilities should beproperly defined in the policy, SLA’s and contract agreements. Expert 1 advised thatin a case of responsibility disagreement, the organizations should focus on dealingwith the incident and later review what caused that disagreement. Perform theproper modifications so that it will not happen again making sure that there is acommon set of expectation with the third party.

6.1.3 What are the challenges that organizations experienceduring the operational phases of incident management inthe outsourced setting and how could they be addressed?

Here are introduced the challenges identified during the operational phases of incidentmanagement and the organization’s approaches or expert’s recommendations toaddress them. Moreover, some questions have been added to help the organizationsto evaluate their preparedness for these challenges.

– Distribution of responsibilities. Defining precisely what type of incidentsneed intervention from the third party, what type of interventions are neededfrom the third party and what is expected to be covered by the third party ischallenging. Organization A’s CERT has developed an information securitypolicy template that is used to aid other organizations and institutions toget information security in place. However, this template does not considerinformation security in supplier relationships, which could help to mitigate therisks associated with organization’s assets accessible to third parties such asICT service providers and suppliers. Moreover, Organization A recommendednot accepting standard terms from the third parties. Organization B providesto the organizations, institutions or entities that can access Organization B’snetwork with a code of conduct that contains all the security needs thatshould be fulfilled to get access to their network. Expert 1 made the followingrecommendations: It is important to define clear responsibilities and state themin the service level agreement. Organizations should describe point by pointwhat is expected from the third party to come with. Every organization shouldavoid the use of catch all clause describing that the third party should detecteverything, if that is the case, then the organization needs to make sure thatthe third party has the ability to enforce its incident response capabilities.

◦ How would the third party participate in each phase and potentially inthe decision making?

◦ Does the scope of your policy include what type of incidents need inter-vention and what kinds of activities are needed from the third party?

58 6. DISCUSSION

◦ Does the policy describe what is expected to be embraced by the thirdparty?

◦ Have you defined responsibilities regarding issues with sub-vendors?

– Overlapped roles and responsibilities. Defining roles and responsibilitieswithout having a clear picture of the third party security staff and the or-ganization security staff could create overlaps that may generate difficulties.According to the survey most of the participants have never seen the rolesand responsibilities defined in the incident management plan regarding thirdparties even though they are involved in incident management and incidenthandling. The documentation such as the information security policy should bedistributed to everyone involved within incident management activities. Thosewho have seen them believe that they are well defined, but some overlaps onthe roles are present. Organization C made emphasis on analyzing thoroughlydifferent scenarios to identify if there are overlapped roles or any weak pointson the defined responsibilities and correct them.

◦ Does your IRT include staff from the third party?◦ Are the roles held by third party personnel involved with the IRT, either

as part of the team or as a contact point, not overlapping with any otherrole inside the third party company?

– Handling and incident without specific responsibilities being deter-mined or documented beforehand. Unclear responsibilities situationsmight occur due to changes on the organization or provider infrastructure, newtechnology or new threat vectors. Expert 1 recommended to deal first with theincident and then look at how the responsibilities can be changed or adapted toprevent re-occurrence, making sure that there is a common set of expectationsbetween the organization and the third party. Organization A recommendedusing catch all clauses or insurance company’s services.

◦ Does follow up actions in the case of a security incident scale up to includethe third party?

◦ Are your contracts and agreements with the third party consideringresponsibilities for scenarios not defined beforehand?

– Appropriate data handling by the third party. It is essential to monitor,audit and review third party’s data handling in order to make sure thatthere is full control of the information that third parties can have access to.Organization B advises to implement secure connection points to third parties.Expert 1 recommends to take a proactive approach and perform tests on theservices received by the third party in order to know if they are respondingwhen they should respond, to verify that they are notifying the organization


about security incidents and that they are compliant with the expectanciesdefined in the policy. Expert 1 also recommends including a clause stating thatthe organization is allowed to exercise the right to test the capabilities of theincident response of the third party. Describe the right to test in the servicelevel agreement.

◦ Have you considered a clause stating the right to test the incident responsecapabilities of the third party?

◦ What kind of reporting and notification is the third party required deliv-ering?

◦ What are the third party’s expectancies, have you defined them in theSLA?

– Lack of expertise. Shortage of skilled personnel affects also the organiza-tion’s incident management capabilities. Trained personnel might move to newjob positions or companies. Organization A advises to provide training andbuilding incident response capabilities in the biggest institutions and organi-zations getting services from the Organization and do it in the future withthe rest of institutions and organizations. Organization B recommends toperform experience-sharing workshops to provide to the contact points withdifferent approaches to solve their common issues and contribute to each other’scapabilities.

◦ Does the training and awareness plan involve third parties?

– Incident detections by third parties. Identification of incidents reducingthe number of false positives demands contextual knowledge. Providing withthe right knowledge to a third party is not a simple task. Organization A’sCERT has implemented mechanisms to detect and report events and incidentssuch as sensors, through the complaints, and security contacts. Even thoughOrganization A’s CERT do not manage the detection at institutions that getservices from Organization A, first one has trained personnel to detect them andto contact them in case they need help to handle it. The detection mechanismsimplemented by Organization B’s CSIRT such as deployed sensors in everyrelevant location as well as the logs processing are an effective strategy. Expert1 highlighted that is not enough to set up mechanisms for detection. Thechallenge is to identify false positives and discard them to know when to declarean incident. Expert 1 suggests defining what events are security incidents andwhich are not related with security incidents to provide a third party withknowledge on what is normal, what is accepted, what is not and so on. Performtests and simulate incidents, expecting the third party to notify about havingan incident.

60 6. DISCUSSION

◦ Have you defined what kinds of incidents are expected to be identified bythe third party?

◦ Have you defined and documented a notification scheme with parametersand metrics involving third party services?

◦ Is the documentation clear enough regarding what kind of events areconsidered security incidents so that a third party can understand what isaccepted and what is not?

◦ Does the third party have mechanisms in place to detect and identifyinformation security incidents?

– Updating the detection mechanisms. New detection rules need to bedeveloped and updated to the detection mechanisms. These ones might belocated on different geographical points. Organization B recommends to trainin every institution a security contact capable of knowing what to do and howto do it.

◦ Are you able to detect incidents at every relevant point in your infrastruc-ture?

◦ Are you logging as much as you are capable to do?◦ What kind of logs are you collecting?

– Making assessment of some incidents. Figuring out what is going onduring an incident occurrence, what kind of incident is it and how to mitigateit might require an extensive analysis during day and night. Organization A’sCERT provides support to assess and take decisions regarding incidents withthe institutions getting services from Organization A. These actions are notonly internal as recommended by the assessment and decision phase on thestandard ISO/IEC 27035 but also supporting other institutions to ensure aneffective approach to the management of incidents. Organization B’s CSIRThelps the entities inside the Organization B in the assessment of logs. Expert 1stated that collaborative assessment would be needed because the third partywould have a hard time identifying the incidents from the events because theydo not know the organization. Organization B suggests to log as much aspossible and to ensure that sensors are in place. Sensors can provide extra helpto find more information about the incident.

◦ Is the third party able to provide response capabilities?◦ Do you have capabilities to perform incident handling on third party

premises?◦ Do your organization and the third party have common procedures when

collecting and presenting evidence for the purpose of disciplinary action?


– Adequate incident response by the third party. Changes in the threatlandscape, inadequate techniques to block incidents, lack of skilled personneland a complex infrastructure among others might affect the incident responseactivities performed by the third party. Organization A’s CERT provides help tothe small institutions that get services from Organization A. This help consistson supervising them and coordinating the incident, providing them with advices.Organization B’s CSIRT provides with assistance and recommendations whileworking with third parties Incident Response Teams. Responses are performedin a collaboratively manner. Expert 1 suggests performing tests or simulateincidents and observe how the third party’s incident responders go forward,what are their troubles, what kind of information they need, how long time ittakes and identifying if the third party has the capabilities to deal with thetest or simulated incident.

◦ Have you defined how much is expected from the third party while per-forming recovery?

◦ Have you consider to have meetings after incidents that involve a thirdparty’s incident?

◦ How often are you planning to verify the metrics established in the SLAagainst the reports from the third party?

◦ How would you evaluate the third party incident response efficiency andits ability to enforce its incident response capabilities?

– Responding in critical and complex systems. Patching critical and com-plex systems without creating new incidents coming out from the solution.Organization C made emphasis on involving the right personnel during the as-sessment phase to identify risks on making changes on these systems. Moreover,you should determine a preliminary approach and test it.

◦ Will the organization provide the third party with capabilities to makechanges in the organization’s management structure when responding?

◦ How will you handle the corrective measures implementation in complexsystems allocated in the third party infrastructure?

– Lack of knowledge on incident response routines and communicationchannels. Personnel involved with incident response activities in a part-time basis usually do not know all the routines and communication channels.Organization B recommends performing incident response exercises and testingthe knowledge on the response routines. Expert 1 recommends that everytime that an organization updates its incident management procedures, anotification should be provided to the internal and external teams (includingthose from the third party) describing why these changes occurred. According

62 6. DISCUSSION

to the survey, the answers regarding a marginally effective response couldbe the result of different factors, the time that the participants have beeninvolved with incident management tasks, the size of their companies, theamount of experienced people inside their organizations, etc. More questionsto clarify these answers are needed. These opinions show that there is room forimprovement on the current strategies adopted by the organizations, especiallyto coordinate themselves with the third parties to adapt or respond to newsecurity requirements.

◦ How will you recall and evaluate the incident response routines after theexercises have been conducted?

– Lack of technical procedures to set up systems from scratch. Theorganizations rarely have well enough technical procedures to allow some thirdparty to set up their systems from scratch. Expert 1 suggests to prepare thisdocumentation in order to facilitate a smooth recovery phase.

◦ Does the third party understand the business and operational drivers ofyour organization well enough before modifying anything in your infras-tructure to solve an incident?

Chapter7Conclusions

This project studied three organizations with three different incident managementmodels. These organizations were selected based on their capabilities, executionmodel and expertise. They have dealt with incidents where third party companiesare involved or have supported third parties to go through an incident. Their modelsare executed at the organization side in full-time or part-time and as the provider atprovider side in part-time. Furthermore, an expert provided insights and recommen-dations on incident management in outsourcing settings. The expert was selectedbased on his knowledge and experience on partially outsourced models. Additionally,the existing and forthcoming standards and guidelines related to incident manage-ment or outsourced ICT services were examined and the organization’s practiceswere analyzed to identify successful strategies for practicing incident management inan outsourced setting. The interviews revealed a lack of systematic approaches toimprove the incident management in outsourced settings among organizations fromthe different sectors. Despite the selected organizations belonging to different sectorsand using particular incident management models, some challenges are common inmost of the cases. These challenges are related to responsibilities, incident detectionand incident response. The expert’s insight and recommendations were very beneficialin this research. Incident management involving outsourced ICT services must beplanned and addressed before and during the contract negotiations. The policy,procedures and contracting agreements must be defined point by point about whatapplies to a third party, including responsibilities. Incident management and incidentresponse must be specified as an integral part of the outsourcing agreement. It isthe organization’s responsibility to specify the requirements and expectancies for theoutsourced ICT services. It is the third party’s responsibility to deliver services tomeet those agreed security expectancies and requirements. In addition to findinganswers to the research questions, two other contributions were developed in thisproject:

1. A framework of ISO/IEC standards that can be used as a reference to identify

63

64 7. CONCLUSIONS

the relationships between the information described in this research and toprovide guidance on incident management in outsourcing settings.

2. A set of recommendations and questions to help the organizations to evaluatetheir preparedness for the challenges involved with incident management inoutsourcing settings.

A similar study including a large number of organizations could lead to reveal morechallenges and successful strategies. Including a large number of organizations couldreflect different approaches taken by different industry sectors with an increasedgranularity. Some of the interviewees see future trends on outsourced incidentmanagement models. One that is already on the rise is the use of Managed SecurityService Providers. Future research is required in that direction.

References

[EC 12] EC: European Cloud Computing Strategy, Unleashing the Potential of CloudComputing in Europe (2012). Report, European Commission, Brussels, September2012.

[EC 13] EC: Cybersecurity Strategy of the European Union: An Open, Safe and SecureCyberspace. Report, European Commission, Brussels, February 2013.

[EC 14] EC: The Cloud Select Industry Group on Service Level Agreements - Cloud ServiceLevel Agreement Standardization Guidelines. Report, European Commission,Brussels, June 2014.

[HTLB14] Cathrine Hove, Marte Tarnes, Maria B Line, and Karin Bernsmed. Informationsecurity incident management: Identified practice in large organizations. In ITSecurity Incident Management & IT Forensics (IMF), 2014 Eighth InternationalConference on, pages 27–46. IEEE, 2014.

[ISOa] ISO/IEC WD 19086-1 Information technology - Cloud computing - Service levelagreement (SLA) framework and Technology - Part 1: Overview and concepts.Standard, International Organization for Standardization (ISO).

[ISOb] ISO/IEC WD 19086-2 Information technology - Cloud computing - Servicelevel agreement (SLA) framework and Technology - Part 2: Metrics. Standard,International Organization for Standardization (ISO).

[ISOc] ISO/IEC WD 19086-3 Information technology - Cloud computing - Servicelevel agreement (SLA) framework and Technology - Part 3: Core requirements.Standard, International Organization for Standardization (ISO).

[ISOd] ISO/IEC WD 27017 Information technology - Security techniques - Code ofpractice for information security controls based on ISO/IEC 27002 for cloudcomputing services. Standard, International Organization for Standardization(ISO).

[ISOe] ISO/IEC WD 27035-1 Information technology - Security techniques - Informationsecurity incident management - Part 1: Principles of incident management.Standard, International Organization for Standardization (ISO).

65

66 REFERENCES

[ISOf] ISO/IEC WD 27035-2 Information technology - Security techniques - Informationsecurity incident management - Part 2: Guidelines to plan for incident response.Standard, International Organization for Standardization (ISO).

[ISOg] ISO/IEC WD 27035-3 Information technology - Security techniques - Informationsecurity incident management - Part 3: Guidelines for incident response operations.Standard, International Organization for Standardization (ISO).

[ISOh] ISO/IEC WD 27036-4, Information technology - Security techniques - Informationsecurity for supplier relationships - Part4: Guidelines for security of Cloud services.Standard, International Organization for Standardization (ISO).

[ISO11] ISO/IEC 27035:2011 Information technology - Security techniques - Informa-tion security incident management. Standard, International Organization forStandardization (ISO), Geneva, CH, September 2011.

[ISO13a] ISO/IEC 27001:2013 Information technology - Security techniques - Informationsecurity management systems - Requirements Preview. Standard, InternationalOrganization for Standardization (ISO), Geneva, CH, November 2013.

[ISO13b] ISO/IEC 27002:2013 Information technology - Security techniques - Code ofpractice for information security controls. Standard, International Organizationfor Standardization (ISO), Geneva, CH, October 2013.

[ISO13c] ISO/IEC 27036-3:2013 Information technology - Security techniques - Informationsecurity for supplier relationships - Part 3: Guidelines for information and commu-nication technology supply chain security. Standard, International Organizationfor Standardization (ISO), Geneva, CH, November 2013.

[ISO14a] ISO/IEC 27036-1:2014 Information technology - Security techniques - Informationsecurity for supplier relationships - Part 1: Overview and concepts. Standard,International Organization for Standardization (ISO), Geneva, CH, April 2014.

[ISO14b] ISO/IEC 27036-2:2014 Information technology - Security techniques - Informationsecurity for supplier relationships - Part 2: Requirements. Standard, InternationalOrganization for Standardization (ISO), Geneva, CH, August 2014.

[MN07] Michael D Myers and Michael Newman. The qualitative interview in is research:Examining the craft. Information and organization, 17(1):2–26, 2007.

[MRS10] Miroslav Maj, Roeland Reijers, and Don Stikvoort. Good practice guide forincident management, 2010.

[NIS12] NIST Special Publication 800-61 Computer Security Incident Handling Guide(Rev.2). Standard, National Institute of Standards and Technology (NIST), Maryland,US, August 2012.

[Pea14] Siani Pearson. Accountability in cloud service provision ecosystems. In SecureIT Systems, pages 3–24. Springer, 2014.

REFERENCES 67

[PP11] Nick Papanikolaou and Siani Pearson. A cross-disciplinary review of the conceptof accountability. In Proceedings of the DIMACS/BIC/A4Cloud/CSA Interna-tional Workshop on Trustworthiness, Accountability and Forensics in the Cloud(TAFC)(May 2013), 2011.

[PTC+12] Siani Pearson, Vasilis Tountopoulos, Daniele Catteddu, Mario Südholt, RefikMolva, Christoph Reich, Simone Fischer-Hübner, Christopher Millard, VolkmarLotz, Martin Gilje Jaatun, et al. Accountability for cloud and other future internetservices. In CloudCom, pages 629–632, 2012.

[Res14] Symantec Security Response. Dragonfly: Cyberespionage Attacks Against EnergySuppliers. White paper, Symantec, 07 2014.

[Rob11] Colin Robson. Real world research: a resource for users of social research methodsin applied settings. Wiley Chichester, 2011.

[SA11] Ulrike Schultze and Michel Avital. Designing interviews to generate rich data forinformation systems research. Information and Organization, 21(1):1–16, 2011.

[She97] J. Sherwood. Managing security for outsourcing contracts. Computers & Security,16(27):603–609, 1997.

[Sie13] Frank Siepmann. Managing risk and security in outsourcing IT services: Onshore,offshore and the cloud. CRC Press, 2013.

[Tho06] David R. Thomas. A general inductive approach for analyzing qualitative evalua-tion data. American Journal of Evaluation, 27(2):237–246, June 2006.

[TLJ14] Inger Anne Tøndel, Maria B Line, and Martin Gilje Jaatun. Information securityincident management: Current practice as reported in the literature. Computers& Security, 2014.

[Yin14] Robert K Yin. Case study research: Design and methods. Sage publications,2014.

AppendixAInformation Letter

These section includes the information letter provided to the case study participants.This document contains the background and purpose of the research. It also informsthem about the implications of their participation and how their personal data willbe treated.

This document is a consent form reported to the Norwegian Social Science Dataservices.

69

70 A. INFORMATION LETTER

Figure A.1: Information letter provided to the case study participants

AppendixBInterview guide

These section includes the interview guide used as a sketch during the interviewseither face-to-face or via Skype.

The questions during the interviews did not followed any predefined order toenable a fluid conversation and asking for elaborations when needed.

71

72 B. INTERVIEW GUIDE

Figure B.1: Questionnaire guide used during the interviews

AppendixCSurvey

These section includes includes the survey provided to a set of professionals on thefield.

The survey was answered by people with different roles in incident managementteams, from a diverse set of organizations, during a course at one of the securityconferences in Norway.

73

74 C. SURVEY

Figure C.1: Survey questions. Part 1

75


76 C. SURVEY


77


AppendixDPoster

These section includes the research poster presented at the NordSec 2014 conferenceregarding this work.

79

80 D. POSTER

Figure D.1: Research poster presented at the NordSec 2014 conference

Documents

Incident Management in outsourcing