6'th International Symposium on Telecommunications (IST'2012)

A Comprehensive Classification of
Incident Handling Information
Mohsen Nowruzi∗ , Hossein Hadian Jazi∗ ,
Mojtaba Dehghan∗ , Mohammad Shahmoradi∗ ,
Sayed Hadi Hashemi∗ , Mohammad Babaeizadeh∗
∗ APA
Research Center
Isfahan University of Technology
{nowruzi, dehghan, hadian, shahmoradi, hashemi, babaeizadeh}@nsec.ir

Abstract—Incident Handling is a process that detects, analyze may have different structures and policies for management of
and respond to security incidents in an effective way. Even security incidents. The most important discipline in Incident
though this process is highly depends on expert security teams, Management is Incident Handling that is the early detection
an automated system is highly desired. In order to automate
this procedure, all the required information must be identified of incidents, mitigating the effects, and restoring the affected
and classified to become machine usable. This paper, proposed resources [1].
a comprehensive classification of this information. This list has There are many different recommendations available for
been extracted from well-known literature in this field. implementing Incident Handling in an organization. For ex-
Keywords: Incident Management, Incident Handling, Com- ample, In [2] ENISA suggests a process while NIST in [1]
puter Security, Computer Security Emergency Response Team
proposes another approach. Several other researchers and se-
curity groups recommends similar procedures used by CERTs
I. I NTRODUCTION around the world [3], [4], [5], and [6].
Incident Handling is one the most important requirement CERT/CC recommends a four step procedure for Incident
for Business Continuity in any organization. One of the most Handling in [7]:
important aspects of Incident Handling is information gathered Detecting and Reporting: the ability to receive and review
from the environment. Information gathering techniques and event information, incident reports, and security alerts.
its maintenance varies from one organization to another. Most Triage: the actions taken to categorize, prioritize, and
of this information is collected by Computer Emergency assign events and incidents
Response Team (CERT), while the rest of it will be gathered Analysis: the attempt to determine what has happened,
by other groups in Incident Management. Identification and what impact, threat, or damage has resulted, and what
classification of this information is very vital for creating an recovery or mitigation steps should be followed. This can
accurate and flexible Incident Handling process. include characterizing new threats that may impact the
Nowadays, Incident Handling is highly depends on expert infrastructure.
security teams and maintaining an effective Incident Handling Incident Response: the actions taken to resolve or mitigate
is very costly even in smaller organizations. Therefore, an an incident, coordinate and disseminate information, and
automated Incident Handling process is extremely desired. implement follow-up strategies to prevent the incident
Toward automating this procedure, capability of making the from happening again
information used by expert teams usable for machines is Most of recommendations can be mapped to CERT/CC
very critical. Therefore, identification and classification of this recommended procedure. Therefore, we will use CERT/CC
information becomes much more important when one tries to suggested steps as Incident Handling process in the rest of the
design an automated Incident Handling procedure. paper.
This paper is an attempt to develop a comprehensive list of
III. FACTORS
Incident Handling usable information and their features, based
on well-known recommendations in this concept. The information which can be extracted from the environ-
The remaining of the paper is organized as follows: Section ment called “Factors”. The first step in information gathering
2 provides a description of Incident Handling procedure. In from the environment is extracting the list of factors and
Section 3, list of factors and their description will be repre- describing them. Description of each factor should covers all
sented and Section 4 draws features of each factor. Finally, its aspects in addition to its relation with other factors.
Section 5 presents conclusion remarks and future works. Contact List[1]: a list of people or groups that could
be helpful in an Incident Handling mission. This list
II. I NCIDENT H ANDLING covers information like names, contact info, schedule of
Incident management is a set of activities for preparation, availability, and so on. For example, in case of Denial of
prevention and responding to security incidents. Organization Service, it could be helpful to contact ISP support group.

Authorized licensed use limited to: Institut Teknologi Bandung. Downloaded on June 07,2024 at 01:00:17 UTC from IEEE Xplore. Restrictions apply.
978-1-4673-2073-3/12/$31.00 ©2012 IEEE
1071
Organization Services List[1]: a list of services that an Analysis Result[1]: a result history of analysis in various
organization offers to its customers or staffs. This list Incident Handling cases. This history contains reports
contains descriptive attributes (e.g. service name, sen- along with their results.
sitivity, and agreements) as well as relational attributes
(e.g. infrastructural entities of the service and responsible Prioritization criteria[1][3]: a set of criterion that is used
contacts) by the response team of an organization for prioritization
of multiple incidents to be response. This set includes
Assets List[1]: a list of assets in an organization, which criterion list along with an algorithm to evaluate prioriti-
contains descriptive information (e.g. identities, sensitiv- zation based on results of criteria.
ity) along with associated contacts. Hardware, software,
licenses, subscription, documents, data, and intellectual Prioritization Result[1]: a result history of prioritization
properties are some examples of assets. in various Incident Handling cases. This history contains
result of prioritization for each report along with result
Network Activity History[1]: an activity history of every of each prioritization criterion.
network attached entity in an organization domain (e.g.
routers, switches, firewalls, servers, services, and hosts). Prioritization criterion[9][3]: a criterion that is considered
This history contains periodic network usage, mixture of along with other criteria for prioritization of an incident.
used protocols, top destination or sources and so on. This criterion consists of required date with some kinds
of evaluation method. For example, Current and Potential
Sensitive Files Checksum[1]: a repository of checksum Technical Effect is a prioritization criterion that indicates
of sensitive files (e.g. executable, configuration, and dy- current affection of an incident on an organization and
namic libraries). possible other influences if the incident is not addressed.
This criterion usually lookup incident report information
Intrusion Detection Reports[1]: an archive of incoming in some pre-filled tables.
intrusion reports from security devices such as Intrusion
Detection Systems, Intrusion Prevention Systems, Corre- Threats List[9]: a list of the most important threats for
lation Engines, and Honeypots. This archive also includes security of an organizations assets. This list includes the
results of processing reports. essence of threats along with their importance rate.

Users Incident Reports[1]: an archive of incoming event Risk Table[9]: a table of the most critical risks of assets
reports from customers, staffs, or administrators of the security, which is built up from threats and assets lists.
organization. This archive also includes results of pro-
cessing reports. Incident Response Result[1]: a result history of response
in various Incident Handling cases. This history contains
Web Incident Reports[1]: an archive of published incident incident reports along with their activities document.
reports in other organizations. This archive possibly in-
cludes results of processing reports. Strategies List[1]: a list of strategies for addressing an
incident in an organization. This list depends on capacity
Triage Classification[8]: a classification of incidents which of the organization and its response team. It consists
will be used in Triage stage of Incident Handling. This of sequence of identification, containment, eradication
classification consists of possible classes for incoming and recovery tasks for each class of incident in several
incidents as well as identification supplementary speci- situations.
fication.
Activities Document[1]: an archive of documents describ-
Analysis Incident Classification[1]: a classification of ing chosen response strategy in case of incident happen-
incidents which will be used in the analysis stage of ing and the result of its execution.
Incident Handling. This classification consists of possible
classes for incoming incidents as well as identification Actual loss of incident[1]: an archive of determined loss
supplementary specification. of each incident that is determined by response team of
an organization.
Triage Criteria[8]: a set of criterion that is used by the
response team of the organization to triage an incident. Published Vulnerabilities Databases[10][11]: a detail
database of published vulnerability on available sources.
Triage Result[8]: a result history of triage in various This database contains vulnerability description and at-
Incident Handling cases. This history contains reports tributes, and possibly mitigation solutions.
along with their results.
Exposed Vulnerabilities List[10][11]: an archive of vulner-

Authorized licensed use limited to: Institut Teknologi Bandung. Downloaded on June 07,2024 at 01:00:17 UTC from IEEE Xplore. Restrictions apply.
1072
 abilities discovered in an organization, which is usually
updated with vulnerability scanners or vulnerability man-
agement systems utilized in the organization.

Configurations[10][11]: a collection of configurations in

an organization, which contains current configuration of
network and systems and possibly change history log of
them.

Known Malware Database[12]: a detail database of dis- Fig. 1. Storarge Types of Factors.
covered malware on available sources (e.g. Symantec
knowledge base). This database contains malware de-
scription and attributes, and possibly detection and miti- 2) Machine-Friendly Repository: if the storage can be used
gation solutions. by other machines and systems.
3) Implicit-Data: if the information is generated but does
Malwares List[12]: an archive of malware discovered in not stored officially.
an organization, which is usually updated with output Each factor based on its storage type may require specific
of security solutions (e.g. anti-malware and intrusion way of collection and conversion to be represented in knowl-
detection systems in the organization). edge base. It should also provide a mapping function to map
the adapted information with knowledge base representation.
Policy List[7]: a collection of policies in an organization, This concept has been shown in Figure 1.
which contains current policy of network and systems,
and possibly change history log of them. B. Responsible Party
Each factor would be produced or maintained by a certain
Penetration Test Document[10]: an archive of penetration provider. The most common types of these parties are:
test logs in the organization. 1) Computer Security Team: members of the organization
which are responsible for security.
Misconfiguration List[10]: an archive of misconfiguration
2) Information Technology Team: staffs of the IT group in
found in an organization, which is usually updated with
the organization (e.g. network administrators).
periodic compliance reviews.
3) Security Tools: security devices or software which are
System Patch Level[10]: a List of patches applied on currently being used in the organization.
entities in an organization, which is usually updated with 4) Administrative Tools: administrative devices or soft-
Patch Management Systems. wares which are currently being used in the organization.
5) Users: employees or costumers of the organization.
Affected Entities List[12]: an archive of affected entities 6) Organization: other groups of the organization (e.g.
in an organization, which is detected by response team managers).
or other security facilities. 7) 3rd Party Security Teams: security groups outside of the
organization (e.g. security vendors).
Response Guides[12]: a database of response guides in
several type of incidents and intrusion, which is con- C. Representations
stantly updated. For example, removal methods of various This attributes draws how a factor is represented.
malware types are part of this database. 1) Standard: there is a well-known standard template for
the factor. For example, CCE1 [13] for Configuration,
IV. F EATURES CEE2 for Event Logs, and MAEC3 [14] for Malware.
Each factor can be described by defining an specific set 2) Common non-Standard: there is no well-known standard
of attributes which has been represented in Table I. These template for the factor while used templates are very
attributes which demonstrates how to prepare, gather and similar (e.g. phone books).
utilize each factor in Incident Handling, described in details 3) Non-Standard: there is no well-known standard template
in the following. for the factor (e.g. mission reports).

A. Common Storage Type

Based on the common way an organization stores and
updates each factor, they can be partitioned into three different
sets: 1 Common Configuration Enumeration
1) Repository: if the organization intends to store the factor 2 Common Event Expression
by an exact routine. 3 Malware Attribute Enumeration and Characterization

Authorized licensed use limited to: Institut Teknologi Bandung. Downloaded on June 07,2024 at 01:00:17 UTC from IEEE Xplore. Restrictions apply.
1073
 TABLE I
C LASSIFICATION OF I NCIDENT H ANDLING I NFORMATION

Factor Name Common Storage Type Responsible Party Representations Origin Discipline Applicant
Contact List Repository Computer Security Team Common non-Standard Incident Handling Analysis, Response
Organization Services List Repository Organization Common non-Standard Risk Analysis Analysis, Response
Assets List Repository Information Technology Team Standard IT Operations Analysis, Response
Network Activity History Implicit-Data Administrative Tools Non-Standard IT Operations Triage, Analysis
Sensitive Files Checksum Machine-Friendly Repository Security Tools Standard IT Operations Response
Intrusion Detection Reports Machine-Friendly Repository Security Tools Standard Intrusion Detection Services Detection
Users Incident Reports Implicit-Data Users Non-Standard Incident Handling Detection
Web Incident Reports Repository 3rd Party Security Teams Non-Standard Alerts and Warnings Detection
Triage Classification Repository Computer Security Team Common non-Standard Incident Handling Triage
Analysis Incident Classification Repository Computer Security Team Common non-Standard Incident Handling Analysis
Triage Criteria Implicit-Data Computer Security Team Non-Standard Incident Handling Triage
Triage Result Implicit-Data Computer Security Team Non-Standard Incident Handling Triage
Analysis Result Implicit-Data Computer Security Team Non-Standard Incident Handling Analysis
Prioritization criteria Repository Computer Security Team Non-Standard Incident Handling Analysis
Prioritization Result Implicit-Data Computer Security Team Non-Standard Incident Handling Analysis

1074
Prioritization criterion Repository Computer Security Team Non-Standard Incident Handling Analysis
Threats List Repository Organization Standard Risk Analysis Analysis
Risk Table Repository Organization Standard Risk Analysis Analysis
Incident Response Result Implicit-Data Computer Security Team Non-Standard Incident Handling Response
Strategies List Implicit-Data Computer Security Team Non-Standard Incident Handling Response
Activities Document Repository Computer Security Team Non-Standard Incident Handling Response
Actual loss of incident Repository Computer Security Team Common non-Standard Incident Handling Response
Published Vulnerabilities Databases Machine-Friendly Repository 3rd Party Security Teams Standard Vulnerability Handling Analysis
Exposed Vulnerabilities List Machine-Friendly Repository Security Tools Standard Vulnerability Handling Analysis
Configurations Machine-Friendly Repository Information Technology Team Standard IT Operations Triage
Known Malware Database Machine-Friendly Repository 3rd Party Security Teams Standard Artifact Handling Analysis
Malware List Machine-Friendly Repository Security Tools Standard Artifact Handling Analysis
Policy List Repository Information Technology Team Standard IT Operations Analysis, Response
Penetration Test Document Repository Computer Security Team Non-Standard Security Audit or Assessment Analysis
Misconfiguration List Implicit-Data Information Technology Team Non-Standard Security Audit or Assessment Analysis
System Patch Level Machine-Friendly Repository Security Tools Standard Vulnerability Handling Analysis

Authorized licensed use limited to: Institut Teknologi Bandung. Downloaded on June 07,2024 at 01:00:17 UTC from IEEE Xplore. Restrictions apply.
Affected Entities List Implicit-Data Computer Security Team Standard Incident Handling Analysis
Response Guides Repository 3rd Party Security Teams Non-Standard Incident Handling Response
D. Origin Discipline more details. Furthermore, for each factor without an standard
Each factor is produced inside an specific discipline. Com- format, a format should be produced.
mon factors in an organization are originated from IT Op-
erations (e.g. network monitoring) or some of the Incident ACKNOWLEDGMENT
Management disciplines: The authors would like to thank Research Institute of
1) Alerts and Warnings ICT, especially Dr. H. Gharaei, Mr. A. Soozani, and
2) Incident Handling Mr. A. R. Ghaznavi for their support.
3) Vulnerability Handling
4) Artifact Handling R EFERENCES
5) Announcement
6) Technology Watch [1] K. Scarfone, T. Grance, and K. Masone, “Computer security incident
handling guide,” NIST Special Publication, vol. 800, no. 61, p. 38, 2008.
7) Security Audit or Assessment [2] E. Network and information Security Agency, “A step-by-step approach
8) Configuration & Maintenance of Security Tools, Appli- on how to set up a csirt,” no. WP2006/5.1, p. 86, 2006.
cations, Infrastructures [3] M. West-Brown, D. Stikvoort, K. Kossakowski, G. Killcrece, and
R. Ruefle, “Handbook for computer security incident response teams
9) Development of Security Tools (csirts),” DTIC Document, Tech. Rep., 2003.
10) Intrusion Detection Services [4] S. Northcutt and S. Institute, Computer Security Incident Handling: Step
11) Security-Related Information Dissemination by Step, a Survival Guide for Computer Security Incident Handling.
Sans Institute, 2001.
12) Risk Analysis [5] E. Schultz and R. Shumway, Incident response: a strategic guide to
13) Business Continuity & Disaster Recovery Planning handling system and network security breaches. Sams, 2001.
14) Security Consulting [6] S. Mitropoulos, D. Patsos, and C. Douligeris, “On incident handling and
15) Awareness Building response: A state-of-the-art approach,” Computers & Security, vol. 25,
16) Education/Training no. 5, pp. 351–370, 2006.
[7] C. Alberts, A. Dorofee, G. Killcrece, R. Ruefle, and M. Zajicek, “Defin-
17) Product Evaluation or Certification ing incident management processes for csirts: A work in progress,” 2004.
[8] E. Network and information Security Agency, “Good practice guide for
E. Applicant incident management,” p. 110, 2010.
This attribute indicates that in which stage of Incident [9] “Information security for network managers,” 2005, software Engineer-
ing Institute Carnegie Mellon University.
Handling (Detecting and Reporting, Triage, Analysis, and [10] S. Manzuik, A. Gold, and C. Gatford, Network security assessment: from
Incident Response) procedure, the factor can be utilized. vulnerability to patch. Syngress, 2006.
[11] P. Mell, T. Bergeron, and D. Henning, “Creating a patch and vulnera-
V. C ONCLUSION bility management program,” NIST Special Publication, vol. 800, p. 40,
2005.
In this article, a comprehensive list of information used [12] P. Mell, K. Kent, J. Nusbaum, N. I. of Standards, and T. (US), Guide
in Incident Handling has been proposed. To the best of our to Malware Incident Prevention and Handling. US Department of
knowledge, the proposed list covers all the common informa- Commerce, Technology Administration, National Institute of Standards
and Technology, 2005.
tion utilized in Incident Handling procedure. Description and [13] MITRE. (Accessed: 18/07/2012) Common configuration enumeration.
features of each factor also provided. [Online]. Available: http://cce.mitre.org/
The future work would be to demonstrate how these factors [14] ——. (Accessed: 18/07/2012) Malware attribute enumeration and
characterizatio. [Online]. Available: http://maec.mitre.org/
can be used in each step of Incident Handling process in

Authorized licensed use limited to: Institut Teknologi Bandung. Downloaded on June 07,2024 at 01:00:17 UTC from IEEE Xplore. Restrictions apply.
1075