background.tex

\chapter{Background}
\label{chp:background}
This chapter presents relevant background information with regard to incident management. An overview of incident management, relevant standards and guidelines as well as related research is presented.

\section{Incident Management Overview}
This section provides an overview of common concepts and terms used in incident management.
\subsection{Definitions}
\label{sec:Definitions}
%Eller et annet navn, poenget er å includere definisjoner av disse tidlig i rapporten
In information security incident management there are a few terms that need to be defined clearly. Two such terms are information or computer security \textit{incidents}\footnote{In this report the terms ``information security incident", ``computer security incident", ``ICT security incident", ``security incident" and ``incident" are used interchangeably.} and information or computer security \textit{events}. It is important to recognize these as two terms of different meaning. The standard \acs{ISO}/\acs{IEC} 27000\footnote{\acs{ISO}/\acs{IEC} 27000 Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary} \cite{ISO/IEC27000} specifies the following definitions:

\textbf{Information security:} Preservation of confidentiality, integrity and availability of information; in addition, other properties such as authenticity, accountability, non-repudiation and reliability can also be involved.

\textbf{Information security event:} Identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be security relevant.

\textbf{Information security incident:} Single or a series of unwanted or unexpected \emph{information security events} that have a significant probability of compromising business operations and threatening information security.

\textbf{\ac{ISIRT}:} Team of appropriately skilled and trusted members of the organization that handles information security incidents during their lifecycle.

The guidelines \acs{NIST} Special Publication (SP) 800-61: Computer Security Incident Handling
Guide \cite{nist800-61} specifies the following definitions:

\textbf{Event:} An event is an observable occurrence in a system or network.

\textbf{Adverse event:} Adverse events are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution of malware that destroys data.

\textbf{Computer security incident:} A violation or imminent threat of violation\footnote{An ``imminent threat of violation" refers to a situation in which the organization has a factual basis for believing that a specific incident is about to occur.} of computer security policies, acceptable use policies, or standard security practices.

\acs{NorCERT} specifies the following definitions \cite{NorCERT3Kvartal2012}:

\textbf{\ac{CSIRT}:} A central tool with the task of protecting important infrastructure. The team must consist of security specialists and they must handle and responds to incidents. Additionally, they need to create awareness and educators.

\textbf{\ac{CERT}:} A trademark that can only be used after approval by Carnegie Mellon University. Is in practice the same as a \acs{CSIRT}.

The definition of an adverse event from \acs{NIST} \cite{nist800-61} is quite similar to the definition of an information security event from ISO/IEC \cite{ISO/IEC27000}. The definitions of incidents are also quite similar. These definitions are the ones that will be used in this report. \ac{ISIRT}, \ac{CSIRT} and \ac{CERT} define similar types of teams. In this report the term \acs{IRT} is used to denote such a team. 

\subsection{What is Incident Management}
Incident management is a collective term that comprises all activities associated with managing security incidents. Incident management is not restricted to incident handling alone, but includes activities for the entire incident lifecycle; from planning, training and raising awareness to detecting, responding and learning from incidents. 

Various guidelines and standards describe best practice and suggest activities for effective and efficient incident management. It is important to note that incident response requires a substantial amount of planning and resources. Two of the most important parts of incident management are the existence of guidelines for communication and prioritization of incidents as well as the use of an evaluation process to gain experience from previous incidents. \cite{nist800-61}

As part of an incident management capability, organizations should have an incident management policy, a plan and procedures, all of which should be tailored to the specific organization's needs. Additionally, it is important to have a planned approach to reporting of vulnerabilities that have not yet been exploited. \cite{ISO/IEC27035}

%The policy should include definitions, forms and commitment from senior management, plans should outline the organization's approach towards incident response, whereas procedures should be based on the current incident management policy and plan.

%\acp{SOP} are a delineation of the specific technical processes, techniques, checklists and forms used by the incident response team. An organization should establish procedures regarding communication with various outside parties, like media, law enforcement, other incident response teams, software vendors and \acp{ISP}. It is common to have \acp{PoC} for the various outside parties. \cite{nist800-61}

Incident management is not purely an IT related issue as information security incidents threaten an organization as a whole. Having a well-planned and tailored incident management capability is therefore important for organizations in order to protect information. Incident management seeks to both prevent, contain and resolve incidents, in addition to perform post-learning. ENISA states the following about incident management \cite{enisaGuide}: 

\begin{quote}
\textit{``Incident management is an important tool of overall governance and to have it, in whatever form or shape, is a necessity."}
\end{quote}

\subsection{\acl{IRT}}
Having an \ac{IRT} will aid organizations in responding to incidents more effectively and efficiently, in addition to providing a structured approach for learning from previous incidents. 

As the various definitions in section \ref{sec:Definitions} indicate, an incident response team is ``a team that responds to computer security incidents by providing all necessary services to solve the problem(s) or to support the resolution of them" \cite{enisaCSIRTGoodPractices}. The team structure, members, tasks and responsibilities may vary depending on organizations' resources and needs. 

\ac{NIST} recommends having one person in charge of incident response, taking the role as team manager. The team manager should act as a liaison to senior management and ensure that the team has the necessary resources, personnel and skills. It is recommended that team members have diverse backgrounds so they can handle different incidents that occur. The team manager should assess the situation and assign responsibility for incidents to the most appropriate team member. \cite{nist800-61}

Usually teams consist of highly technically skilled persons, and teams should have at least one member with expertise in each major technological category. Good problem solving skills and communication skills are essential to the team as effective incident response requires collaboration and coordination within the team and throughout the organization. \cite{nist800-61}

The structure of the team may vary. The number and frequency of incidents as well as team responsibilities should guide organizations' choice of team structure. However, whenever justified  the ISO/IEC 27035 standard\footnote{ISO/IEC 27035 Information technology - Security techniques - Information security incident management} recommends having a permanent team. \cite{ISO/IEC27035}

%\acp{IRT} should have clearly defined responsibilities, processes, allocation of roles and appropriate training programs\cite{ISO/IEC27035}. Team members should hold appropriate access permissions and have access to supportive tools to be best prepared to perform incident response \cite{SANShandbook}.
%

Participating in a community of teams will be beneficial for teams due to collaboration on standards and procedures as well as information and resource sharing. To minimize the frequency of incidents and to mitigate negative impact caused by them, most \acp{IRT} do not only provide reactive services, but may also have other responsibilities, such as intrusion detection, advisory distribution, education and raising awareness within the organization. \cite{nist800-61}  
  
\section{Standards and Guidelines}
This section gives an introduction to the most relevant and widely implemented standards and guidelines for information security incident management. 
\label{section:standardsandguidelines}
\input{iso27001}
\input{iso27002}
\input{iso27035}
\input{itil}
\input{nistsp800-61}
\input{enisa}

\subsection{NorSIS - Guideline for Incident Management}
\label{sec:NorSIS}
The \ac{NorSIS} has in cooperation with a group of students\footnote{The students did a survey on incident management in Norwegian \acsp{SME}\cite{sand2010hendelseshaandtering}} developed a guideline for incident management, published in 2010\cite{norsisveiledning}. The aim of this guideline is to give a thorough description of why and how organizations should plan for security incident management, conduct business impact analysis and explain various measures to improve information security in organizations. This guideline is specifically developed for \acp{SME} and may thus not be extensive enough for large organizations. The content in this section is, unless specified otherwise, derived from\cite{norsisveiledning}.

\paragraph{Incident Management Policy} 
An incident management policy should form the basis for developing new incident management plans in organizations. A solid policy should state an organization's objectives for incident management and include a statement ensuring commitment from senior management. Any relevant laws, standards and regulations should be included. It is essential that the policy has requirements for performing regular risk assessments, business impact analysis, tests and training. The guideline recommends to include the assignment of roles and responsibilities in the incident management policy.

\paragraph{Business Impact Analysis}
NorSIS recommends organizations to conduct a business impact analysis to identify which services are of significant value and needs to be secured. Risk assessments and the identification of possible consequences of security incidents are part of this process. The guideline emphasizes the importance of knowing risks and potential threats.  

\paragraph{Preventive Measures}
One of the most cost effective ways to perform incident management is implementing preventive measures. Listed as minimum requirements are antivirus, logs, firewalls, backups, alarms, locks, regular reviews of the threat landscape, and reporting systems for employees. Other proposed measures include encryption of data and wireless networks.   

\paragraph{Recovery Strategies}
The guideline recommends having a recovery strategy to quickly re-establish business operations after an incident. Suggestions include backup and emergency solutions. Routines and plans should be in place to handle recovery efficiently.

\paragraph{Incident Management Plan}
Organizations should use previous assessments and proposed incident scenarios to develop an incident management plan. It is recommended that individual plans addressing different scenarios are developed. Each incident management plan should include type of incident, what triggered the incident, roles and responsibilities, guidelines for communication and notifications, maximum response time, check-list of tasks during incident response and post-incident activities.

\paragraph{Training}
To reduce costs caused by security incidents, NorSIS suggests training employees in correct use of equipment and making sure routines for incident response are well known.

\paragraph{Plan Maintenance}
The guideline recommends organizations to conduct annual reviews of their incident management plans. To ensure a solid and up-to-date incident management plan, changes should be made based on experience from previous incidents. 

\paragraph{Outsourcing}
When organizations decide to outsource services, they should evaluate and agree on incident management procedures. It is the organization outsourcing that is responsible for securing information properly and for making sure sufficient plans for incident management exist. An agreement should define responsibilities and state expected quality of services. 

\input{SANSincidentHandlersHandbook}

\subsection{Summary}
The standards and guidelines have a number of similarities and have chosen to divide the incident management process into several phases. Most of them describe a preparation phase, where an incident management capability is built. All of the standards and guidelines have phases for detection, analysis and incident responses, but the structure of these phases varies. All of them highlight lessons learned activities, even though not all describe a separate phase for this. It is worth noting that the guidelines presented are developed by single organizations, whereas the ISO/IEC standards are developed by groups of experts from all over the world. The development and approval of the ISO/IEC standards are extensive processes with many contributors and should therefore be widely accepted.

\section{Related Work}
\label{relatedwork}
In recent years the amount of available academic literature addressing incident management has increased along with an overall interest for the topic. Despite the amount of available literature there is limited knowledge about how organizations perform incident management in practice and thus an interesting topic for research. We studied related research papers and surveys and some of them are briefly discussed in this section.

Eugene H. Spafford presented in 2003\cite{spafford2003failure} the first large internet worm and discussed what happened during the years after this large incident, which occurred in 1988. The worm led to the CERT at Carnegie-Mellon University being established. The three flaws this worm exploited were trust relationships, buffer overflows and poor default configuration. The author claimed that these flaws have not been removed but rather worsened. The author also questioned the CERT model. He claimed that incident response is uncoordinated and of minimal effectiveness. Lastly he predicted that he could either in 2013 or 2018 write a paper about 2003 as the time were we did not know how bad it was going to get. This work is quite different from our thesis, but it is interesting that he points to lack of lessons learned and predicts that the situation in the time of this writing has not improved.

In a study from 2005\cite{brage}, a survey of Norwegian companies and public institutions was conducted where routines for information security incidents, how theory and practice differed as well as potential differences between organizations in public and private sectors were examined. The survey showed that statistical material about incidents were inaccurate due to lack of implemented routines, lack of training and weak definitions of security incidents in general. Public institutions were found to have greater shortcomings in reporting, training and statistics than private ones. A lack of documentation and use of metrics when outsourcing IT systems were also revealed. Of all the participating organizations only 50\% followed international standards for information security. Further, the study disclosed a gap between incident management theory and practice in terms of how organizations handle information security incidents. Even though private organizations were found to have overall better incident management, there were still room for improvements, especially regarding reporting, training and statistics. 

In 2007 Werlinger et al. \cite{werlinger2007detecting} conducted an exploratory study using interviews and questionnaires. The purpose of the study was to investigate what tasks security practitioners perform during security incidents, what skills and tools are necessary and what strategies are required in order to deal with security incidents. They grouped tasks into the main stages detection, analysis and response. They identified pattern recognition, hypothesis generation and cooperation as needed skills. Two identified strategies in incident response were isolation and simulation. 

Werlinger et al. \cite{werlinger2010preparation} conducted in 2009 16 semi-structured interviews with IT security practitioners from seven types of organizations. Their research focused on diagnostic work performed in response to security incidents as well as the tools used in this process. Their findings showed that a great deal of tacit knowledge is used in the diagnostic work. In addition to relying on tools, the employees used their own technical knowledge as well as their knowledge of the organization and its systems to handle incidents. The findings also showed that intensive diagnostic work was needed to be able to respond to security incidents. This research differentiates from our research in the sense that it focuses mainly on diagnostic work and the tools used instead of the entire incident management process. Additionally there is no comparison to existing standards and guidelines in the analysis of the data.

In 2010, a group of students at Gj\o vik University College conducted a survey of incident management policies, implementations, training and routines in Norwegian \acp{SME}\cite{sand2010hendelseshaandtering}. They performed interviews and questionnaires and concluded that there was still room for improvement regarding incident management in Norwegian \acp{SME}. Having a chief of information security was shown to be beneficial. The organizations that had a chief of information security tended to have better plans for incident management and in addition they used their plans more often. Their research indicates overall insufficient plans for incident management among Norwegian \acp{SME}, and poor quality in existing plans. Finally, in cooperation with \ac{NorSIS} the students proposed a guideline for incident management customized for \acp{SME}. A summary of this guideline was presented in section \ref{sec:NorSIS}. Since then, both new standards and guidelines addressing incident management have been published. It is thus interesting to study how organizations perform incident management and how these standards and guidelines are adopted in current plans and procedures for incident management.

An ongoing study by Maria B. Line \cite{maria} investigates, by conducting a case study, current practice for information security incident management in the power industry. Six large organizations are studied. Preliminary results show that plans for incident management are not widely established in the participating organizations. She found that most of the organizations perform regular meetings to evaluate incidents. It was evident that it is the ICT staff's responsibility to handle information security incidents and that there is not a close cooperation between the ICT staff and power automation staff.

Incident response teams are of utmost importance to incident management. We therefore found research related to \acp{IRT}' tasks, structure and responsibilities interesting. As described in section \ref{section:standardsandguidelines}, several standards and guidelines address establishment and running of \acp{IRT} and a few studies also look at how \acp{IRT} operate in practice. In 2003, Killcrece et al. \cite{killcrece2003state} studied the current state of practice for \acp{IRT} and found several shortcomings for teams in general such as lack of tools, training and experienced personnel. However, during the past decade new standards and guidelines have emerged and the field of incident management has matured.  Based on this and several other studies, Ahmad et al. \cite{ahmad2012incident} presents a case study exploring issues faced by incident response teams that affect the greater organizational security function. They found that organizations lack the ability to exploit their organizational learning capability. A lack of proper information dissemination and the fact that organizations tend to focus on technical learning over policy and risk were also discussed. The participants in their study agreed that if the organization had better information dissemination it would improve their security practices and thus the overall security in the organization. Additionally, they found that organizations often disseminate information from ``high impact" incidents, but that ``low-impact" incidents do not result in disseminated information despite being potentially very useful from a learning perspective. Ahmad et al. sees the distinction between high and low impact incidents as key to efficient learning processes in organizations. Further, Wiik et al. \cite{gonzalezlimits} presents a simulation model to better understand the main factors influencing an \ac{IRT}'s effectiveness. They identified that short-term pressure from a growing incident work load prevents attempts of improving the organization's response capability long-term. 

While studying related work we came to understand that the threat landscape, standards and best practice guidelines change rapidly. Surveys conducted only few years apart reveal that information security and incident management are maturing. Hence, we found studying how organizations perform incident management in practice highly relevant.