Knowledge Management For Incident Response Teams

Masaryk University
Faculty of Informatics
Knowledge management for

incident response teams
Master’s Thesis
Mariami Gonashvili
Brno, Spring 2019

Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. All sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
Mariami Gonashvili
Advisor: RNDr. Jan Vykopal Ph.D.

Consultant: Mgr. Martin Horák
i
Acknowledgements
I would first like to thank my supervisor Jan Vykopal for providing
with his guidance and recommendations. His support and guidance
gave me valuable experience during the writing of this thesis.
I would also like to thank Martin Horák, who was my consultant
during the writing of this thesis and gave me guidance on how to
better understand knowledge management.
I would also like to express my gratitude to Martin Laštovička and
Martin Macháč for the interviews and introducing me to their incident
response environment and to Michal Čech for explaining his thesis.
Additionally, I would like to thank the Georgian governmental
scholarship, the International Education Center (IEC) for giving me
the study grant.
And last, thanks to my partner Michiel Johan Hendrik Marcus for
being my shoulder to lean on.
ii
Abstract
Computer security incident response teams provide the first line of
defence for security incidents. Timely response is highly important
to contain incidents as soon as possible. Therefore, effective knowl-
edge management in the incident response team is highly important.
The concept of knowledge management has also gained the interest
of many big organizations, because proper knowledge management
improves the performance of business processes.
This thesis focuses on knowledge management in Incident Re-
sponse teams. It suggests a customized knowledge management frame-
work for the Computer Security Incident Response Team of MU based
on a literature review of state-of-the-art knowledge management
frameworks and the business process of the respective incident re-
sponse team. This customized framework is applied in practice in
order to identify and find solutions for the knowledge requirements
for the incident response team. By closely reviewing the incident
handling process as a whole, the so-called "knowledge gaps" were
identified. Several solutions were considered and compared and fi-
nally turned into a prototype knowledge management system. The
system that was already used by the incident handling team was ex-
tended to centralize relevant documentation and automate processes
that would otherwise require manual work and cause delays. This
will help the operational team to efficiently communicate information
and guarantee an optimized work-flow.
iii
Keywords
CSIRT-MU, Incident handling, knowledge, knowledge management,
knowledge management systems, RT/RTIR, RT articles
iv
Contents
1 Introduction 1
2 CSIRT/CERT organizational context 3

2.1 CSIRT/CERT . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 CSIRT/CERT Framework . . . . . . . . . . . . . . . . . . . 4
2.3 CSIRT/CERT Services . . . . . . . . . . . . . . . . . . . . 5
2.4 Incident Handling . . . . . . . . . . . . . . . . . . . . . . 6
2.5 An example of an incident and the respective incident response 9
3 Knowledge Management 12
3.1 Definition of knowledge . . . . . . . . . . . . . . . . . . . . 12
3.2 Types of knowledge . . . . . . . . . . . . . . . . . . . . . . 14
3.3 The SECI model . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Definition of Knowledge Management . . . . . . . . . . . . 16
3.5 Knowledge Management in organizations . . . . . . . . . . 17
3.6 Knowledge Management frameworks . . . . . . . . . . . . . 17
3.7 Knowledge Management processes . . . . . . . . . . . . . . 18
3.8 Knowledge Management success and failure factors . . . . . 21
4 Overview of various knowledge management frameworks 24

4.1 A systems thinking framework for knowledge management . 24
4.2 The framework of critical failure factors in KM projects . . . 26
4.3 A threefold knowledge management framework . . . . . . . . 30
4.4 GPO-WM○ R
Framework . . . . . . . . . . . . . . . . . . . . 33
4.5 The European KM framework . . . . . . . . . . . . . . . . . 36
4.6 Comparison of the frameworks and suggested Prototype Frame-
work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Implementation of Knowledge Management in CSIRT-MU 46

5.1 CSIRT-MU . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 The prototype of KM framework for CSIRT-MU . . . . . . . 50
5.3 The implementation of KM in Incident response team . . . . 52
6 Conclusion 65
6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 66
v
Bibliography 68
Index 71
A The questions for interviews 71

A.1 Topic 1: Current Incident Handling process: . . . . . . . . . 71
A.2 Topic 2: Types of knowledge . . . . . . . . . . . . . . . . . . 71
A.3 Topic 3: Tools used for Incident handling . . . . . . . . . . . 71
A.4 Topic 4: General questions for improvements . . . . . . . . . 72
B The questionnaire for the evaluation of suggested solution 73
C The content of the thesis archive 74
vi
List of Tables
2.1 A list of CSIRT Services [2] 6
5.1 A comparision between RT and Redmine 59
vii
List of Figures
2.1 Incident Resolution cycle [2] 8
2.2 An example of a phishing email 10
3.1 Three-level hierarchy 12
3.2 Knowledge Management Processes 19
3.3 Knowledge Management Failure Factors 23
4.1 A systems thinking framework 25
4.2 KM cycle [21] 28
4.3 The GPO-WM implementation mode [24] 35
4.4 The second layer of The European KM framework 39
4.5 A general project management scheme for KM
implementation [25] 43
5.1 The time-line and the details of implementation of KM
in Incident response team 53
5.2 RT articles 58
5.3 Integrated incident handling manual in RT/RTIR: On
the left side of the figure, the incident handling
document is shown; In the middle, it is depicted how
guidelines for different incidents are integrated in RT
articles; and on the right side of the figure, it is shown
how rt articles will be connected to tickets. 61
viii
1 Introduction
Computer security incident response teams provide response to se-
curity incidents. Nowadays, the number of computer incidents is
growing and they are getting more sophisticated. Cyber security inci-
dents often lead to significant damage to organizations, such as data
loss, business process interruption or breach of privacy, which is why
timely and effective response is imperative.
The incident handling process typically starts when an incident is
reported to the incident response team. The incident is then assigned
to team members who are tasked with finding a resolution. After this,
an investigation and resolution process follows in order to contain the
incident and limit the damage. To make sure this incident handling
process happens optimally, it is essential that the right knowledge is
available to the right people at the right time. A proper knowledge
management system is essential for each organization as it increases
the performance and effectiveness of the business processes. It helps
organizations to realize what knowledge assets exist within the organi-
zation and what knowledge is missing to perform business processes
with the best result, also known as a knowledge gaps. Therefore, this
thesis focuses on knowledge management in incident response pro-
cess by analyzing how knowledge management is done in this process
and how a structured approach can identify the knowledge gaps and
solutions.
The thesis reviews state-of-the-art knowledge management frame-
works, which provide a bridge between theoretical concepts and actual
implementations, and uses them to suggest a customized knowledge
management framework for Masaryk University Computer Security
Incident Response Team (CSIRT-MU). This framework provides in-
structions and a custom implementation plan for knowledge manage-
ment within CSIRT-MU. As a result of applying the afore-mentioned
framework in practice, the strong and week points of knowledge man-
agement were identified for incident handling process of CSIRT-MU,
possible improvements were analyzed and assessed, and finally the
prototype of knowledge management system for incident response
team of CSIRT-MU was designed.
1
1. Introduction
The result of this thesis is a prototype of a knowledge management

system for the Computer Security Incident Response Team of Masaryk
University, which improves knowledge storing and accessing, creat-
ing, sharing and applying processes in a way that it adds knowledge
management functionality in the Request Tracker system, which is
used in daily operations during incident handling by this team. The
prototype suggests solutions that should decrease delays caused by
knowledge gaps during the incident handling process, increase per-
formance of the processes and optimize searchability of and access
to documented knowledge. The suggested prototype will help the
team to efficiently communicate information in order to guarantee an
optimized work-flow.
The structure of this thesis is organized into 6 chapters. Chapter 2
explains computer security incident response teams in general and
provides a description of their services. Chapter 3 provides a brief
introduction to the concepts of knowledge and knowledge manage-
ment. It explains different types of knowledge and the importance of
knowledge management in organizations. Chapter 4 covers a litera-
ture review of various knowledge management frameworks that were
used to develop the prototype KM framework for CSIRT-MU. Chap-
ter 5 covers how knowledge management happens within CSIRT-MU
and provides the final product of this thesis, which is a prototype of a
knowledge management system for CSIRT-MU. Chapter 6 summarizes
the main objectives and results of the thesis and provides guidelines
on future work.
2
2 CSIRT/CERT organizational context
This chapter covers what a CSIRT/CERT is, which problems it ad-
dresses and how it solves them.
2.1 CSIRT/CERT
In 1988, the "Internet Worm" Incident occurred, which resulted in the
largest number of compromised computers ever witnessed to that
point. At that time, there was no organization which would provide
response to security incidents. After the "Internet Worm" occurred,
the first CERT (Computer Emergency Response Team Coordination
Center) was formed to respond to computer incidents on the Inter-
net [1].
The term CERT was first used in 1989, when the host organization
(Carnegie-Mellon University) of CERT Coordination Center registered
"CERT" as a trademark. The term CSIRT (Computer Security Incident
Response Team) was introduced later in their CSIRT Handbook. Even
though CSIRT and CERT express the same concept, they are often
used interchangeably [2].
The development of the Internet has made business processes
more convenient and faster and communication all over the world
easier. A few examples are Governments, corporations, banks, schools,
different types of organizations performing daily business activities
over the Internet. However, due to the ever-increasing complexity of
Internet systems, mistakes and accidents can occur more easily and the
level of security problems in the computer systems grows with it. The
combination of the data available over the network and security flaws
in IT systems make IT systems an attack target. Therefore, Computer
incidents — the exploitation of vulnerabilities in IT systems — have
become more and more prominent. Security incident management is
essential for organizations in order to continue business processes and
protect organizational assets in case of a computer incident.
Since 1988, hundreds of CSIRTs/CERTs have been founded. Nowa-
days, CSIRTs/CERTs do not only respond to emergencies but also offer
services which prevent computer security incidents. CSIRTs/CERTs
may offer different services (shown in Table 2.1) such as a security au-
3
2. CSIRT/CERT organizational context
dits and assessments, vulnerability handling, etc, but every CSIRT/CERT

must offer an incident handling service. Without this service, a team
can not be called CSIRT/CERT [1].
2.2 CSIRT/CERT Framework

In order to better understand the goal of CSIRTs/CERTs and how they
should do their job, it is essential to define an organizational frame-
work for the CSIRTs/CERTs. That framework answers the following
questions “what to do,” “for whom”, “in what local setting” and “in
cooperation with whom”. It consists of information such as a mission
statement, constituency, a place in the organization and their relationship
to other CSIRTs/CERTs [1].
A mission statement answers the question "what to do" and helps
understanding what a CSIRT’s/CERT’s goal is, what the priorities are
and whether it is appropriate for the team to take action in a given
situation [1].
A constituency is the organization, or a group of organizations or
people which are supported by a CSIRT’s services. A CSIRT’s/CERT’s
constituency can be anyone requesting the CSIRT’s services or can be
a select group that adheres to certain constraints [1]. A constituency
can be defined by a range of IP addresses, AS (autonomous system)
numbers, domain numbers or a free text description [2].
The relationship between a CSIRT/CERT and its constituents can
fall under three different categories in terms of the authority the
CSIRT/CERT has over its constituents: full, shared or none. Under
full authority, the team can make any decision on behalf of their con-
stituency. The shared authority level means that the decision making
process is shared. As for the last level of authority, the members of
CSIRT/CERT can only give advice to their constituencies.
In general there are different types of CSIRTs/CERTs, which may
fulfill different missions for different constituencies. For example:
CERT-EU is the Computer Emergency Response Team for institutions,
agencies and bodies in the European Union. The mission statement
for CERT-EU is to provide support to European Institutions in or-
der to protect themselves against computer security incidents which
would affect their IT assets and harm the interests of the EU. The
4
Constituency of CERT-EU are EU institutions, agencies and bodies [3].

On the other hand, a CSIRT/CERT belonging to a corporation would
be more oriented on the security of that corporation and therefore, its
constituency would be system administrators and users within the
corporation. An example of such a CSIRT/CERT team is CERT-RU,
whose mission statement is to provide IT security incident response to
Radboud University (RU) in Nijmegen and to help prevent such inci-
dents from occurring. Radboud University’s organizations, employees
and students are the constituency of CERT-RU [4].
According to the basic framework for CSIRTs/CERTs, a place in
the parent organization should be defined for each CSIRT/CERT. A
CSIRT/CERT may be the entire security team for an organization or a
separate team [1].
An important part of the framework is the cooperation between
other CSIRTs/CERTs. The relationship to other CSIRTs/CERTs teams
is essential, because they can provide information in order to effectively
respond to security incidents [1].
2.3 CSIRT/CERT Services

CSIRTs/CERTs might offer different services to their constituency in
order to meet their mission statement. Usually, CSIRTs/CERTs do
not have enough resources to implement all of the services without
diminishing the quality of each of them. Therefore, a selection of
services that the CSIRT does implement, is essential as they directly
reflect the mission.
CSIRTs/CERTs Services are divided into three categories: reac-
tive services, proactive services and security quality management services
(shown in Table 2.1). Reactive services respond to incident reports
from the CSIRT’s/CERT’s constituencies, while proactive services are
more oriented on security and preventing attacks before they actually
occur. Lastly, security quality management services are not unique to
CSIRTs/CERTs and aim to improve the security of an organization [1].
Some services might depend on information from other services.
Therefore, analyzing the information flow between services is essential
in order to get rid of duplication and use pre-existing information
efficiently [1].
5
Table 2.1: A list of CSIRT Services [2]
Reactive Services Proactive Services Security Quality Man-

agement Services
Alerts and Warnings Announcements Risk Analysis
Incident Handling Technology Watch Business Continuity and
Disaster Recovery Plan-
ning
Vulnerability Handling Security Audits or As- Security Consulting
sessments
Artifact Handling Configuration and Main- Awareness Building
tenance of Security Tools,
Applications AND In-
frastructures
Development of Security Education Training
Tools
Intrusion Detection Ser- Product Evaluation or
vices Certification
Security-Related Infor-
mation Dissemination
2.4 Incident Handling
As mentioned before, if a team does not offer incident handling ser-

vices, it can not be called a CSIRT/CERT, because that is its most
important service. The incident handling process has different phases
which involve receiving, triaging, and responding to requests and
reports and analyzing incidents and events [1].
2.4.1 Incident report phase
An incident handling process starts with an incident report. Incidents

can be reported to CSIRT/CERT with the help of a website form, an
email or a phone call by a third-party. This method is more reactive,
as it relies on a third-party to raise the alarm. With sufficient and ap-
propriate monitoring systems, the team may be able to detect incident
in the system and move it to incident handling life-cycle [2].
6
2.4.2 Registration phase

After an incident is reported, it should be registered in the incident
handling system and should be assigned a unique identification num-
ber. This way, it is easier and more convenient to distinguish between
different incidents [2].
2.4.3 Triage phase

The next phase in incident handling is triage, which consists of three
steps: verification, initial classification and assignment. In the verifica-
tion step, it is checked whether a reported incident is a real incident
or not and whether it has something to do with the CSIRT’s/CERT’s
constituencies. In the initial classification step, incidents are priori-
tized. The scale for classification should be defined in advance. In
other words, at this stage it is defined which incidents are critical. In
the final step of the triage phase, incidents are assigned to incident
handlers, who will take care of the incident [2].
2.4.4 Incident resolution phase

The incident resolution phase follows after the triage phase. This phase
is the longest and is done according to the incident resolution cycle
(shown in Figure 2.1). Most of the time, several incident resolution
cycles are needed to solve the problem and a team needs to repeat the
cycle several times [2].
An incident resolution cycle starts with data analysis. An essen-
tial part of data analysis is data collection. There are several sources
for data collection: incident reporters, the monitoring of systems,
databases and log-files. After data are collected, they need to be ana-
lyzed. During data analysis, team members share ideas about a pos-
sible resolution and this way, the cycle transitions to the next step:
resolution research. This process is similar to a brainstorm process, as
team members suggest different ideas, from which only some are
chosen. The following step is the action proposal step, where a team
becomes owner of the incident and members propose concrete tasks
to third parties in order to respond to the incident. For example, a
team might propose turning off a service or checking a system for
malware in order to mitigate an attack. After actions are proposed, a
7
ECOVERY
AND R
ON
ATI DA
IC T
AD
A
AN
ER
AL
YSI
S
A C TIO N PERF O
Incident
Resolution
RCH
Cycle
SEA
RM
RE
ED
N
O
TI
L U
AC
TIO SO
NP RE
ROPOSED
Figure 2.1: Incident Resolution cycle [2]
third party is supposed to perform these actions. This signals the tran-
sition to the action performed step. During this step, the CSIRT/CERT
might monitor what actions actually are done. All these actions are
performed in order to recover the system which was attacked and it is
the real resolution of the problem [2].
2.4.5 Incident closure
After resolving an incident, the incident closure phase starts, which

includes several steps. First of all, the team should provide the final
information to all the parties involved. This information should in-
clude a short description about the incident, whether the incident was
8
resolved and final recommendations. An essential step of this phase

is archiving incidents in a secure and convenient way, as most of the
incidents include sensitive data and most of the time team members
also need to access archived incidents.
2.4.6 Post-analysis
In contrast to all previous phases, the Post-analysis phase does not

necessarily happen after every incident. It is common to perform this
phase after a period of time and to go recent interesting incidents and
discuss them between team members. The discussion identifies what
can be learned from the incident and how it was handled and usually
results in proposals for improvements. The process of post-analysis
helps a team to analyze where a team needs improvement. It can reveal
weak and strong points of the team [2].
2.5 An example of an incident and the respective

incident response
To illustrate how the incident response phases would work in practice,

this section sketches a situation that could happen and walks through
the respective phases.
2.5.1 Overview of the incident
An example of an incident is a phishing email. Take the following

hypothetical situation: A university has a dedicated CSIRT, such as
CSIRT-MU. A student receives an email from itservice@mu.cz, which
tells the user that their mailbox will be unreachable soon if they do
not request extra space (shown in Figure 2.2). The email provides
a link to a website where this can be done. The link redirects to a
strange URL outside of the university domain. That, in addition to the
suspicious mail address of the sender, urges the student to report this
to CSIRT-MU.
9
Figure 2.2: An example of a phishing email
2.5.2 Incident report and registration phase

The reported incident from the student is registered into the system
which is used for incident handling and it is assigned a unique incident
number.
2.5.3 Incident triage phase

During the triage phase, the incident handler checks whether the
reported incident falls under the constituency or not. If this is the case,
the incident handler checks whether it is really a phishing incident and
checks the link which was included in the email within a dedicated
environment (such as a virtual machine) in order to prevent it from
spreading malware from a potentially spoofed website. The incident
handler then classifies the incident as a phishing incident and the
incident resolution phase starts.
2.5.4 Incident resolution phase

During the resolution phase, the incident handler blocks the mali-
cious website on their domain. The damage of the Phishing attack is
then investigated and the impact on users is assessed. Depending on
10
the damage, additional measures might be necessary to resolve the

incident.
2.5.5 Incident closure and Post-analysis phases

After the phishing incident is contained, the reporter of incident will
be informed that incident has been resolved. The team might give
recommendations regarding the phishing attack to employees and
students.
11
3 Knowledge Management
This chapter explains the concepts of knowledge and knowledge man-
agement and explains why knowledge management is important.
3.1 Definition of knowledge

To define what knowledge management is about, first of all there should
be a concept of knowledge. However, establishing a definition of knowl-
edge is quite comprehensive in general and current literature does not
agree on a general definition of knowledge.
First of all, the terms data, information and knowledge are often
wrongly used interchangeably. However, none of these three terms
are the same, although all of them are related to each other [5].
To clarify, the relation between data, information and knowledge
can be seen as a three-level hierarchy (shown in Figure 3.1), where
data is on the bottom level, information is on the middle level and
knowledge belongs to the top level. When going from bottom to top,
rising a level is done by applying some form of processing.
Knowledge
(Analyzed books)
Information
(A list of books sorted by content)
Data
(Alphabetically sorted books)
Figure 3.1: Three-level hierarchy
Data is associated with facts about events, which with additional

processing and additional meaning can be turned into information.
12
3. Knowledge Management
In turn, information is contextualized, categorized, calculated, cor-

rected and condensed data and can be transformed into knowledge
through analysis, which concludes the hierarchy. In general, data
needs minimal human judgment and knowledge requires maximum
judgment [6].
As an example [6], an indexed book with a title is categorized as
data as it does not require any human processing to alphabetically sort
a list of such books. However, when the content of the book is known,
such as the subject, it has had to be processed, so it is categorized
as information. This can be turned into knowledge by analyzing the
book.
There are several definitions of knowledge. One of them is given
by Takeuchi, which focuses on the difference between information
and knowledge: "First, unlike information, knowledge is about action.
It is always knowledge ’to some end.’ Second, unlike information,
knowledge is about belief and commitment. Knowledge is a function
of a particular stance, perspective, or intention" [7]. This definition
does not actually define what knowledge is and how it is connected to
action, but it is more oriented on the nature of knowledge as personal
beliefs.
In a different paper [6], Tsoukas takes into account the personal
character of knowledge and therefore first defines an individual’s
knowledge. Subsequently, he derives the definition of organizational
knowledge from that. According to Tsoukas: "knowledge is the in-
dividual capability to draw distinctions, within a domain of action,
based on an appreciation of context or theory, or both". In other words,
knowledge is the ability of a person to learn how to use/apply theory
or experience in order to act or perform a task in a concrete situation.
Knowledge becomes organizational when it is created, developed and
shared between coworkers in an organization. In the same paper, this
is referred to as: "Organizational knowledge is the capability members
of an organization have developed to draw distinctions in the process
of carrying out their work, in particular concrete contexts, by enacting
sets of generalizations (propositional statements) whose application
depends on historically evolved collective understandings and expe-
riences" [6]. This definition gives insight into the way knowledge is
connected to action and how collective experience is used for creating
and developing knowledge within an organization. However, there is
13
nothing mentioned regarding knowledge which is documented and

stored outside of individuals and might be embedded in organiza-
tional routines.
In this thesis knowledge will be referred to as the following defi-
nition that was introduced by Davenport and Prusak: "a fluid mix of
framed experience, values, contextual information, and expert insight
that provides a framework for evaluating and incorporating new ex-
periences and information. It originates and is applied in the minds of
knowers. In organizations, it often becomes embedded not only in doc-
uments or repositories but also in organizational routines, processes,
practices, and norms" [5]. This definition is more comprehensive in the
sense that it defines knowledge as the mixture of different elements
and how it is used and developed. Furthermore, it addresses that
knowledge is not only present in individuals.
It emphasizes that one essential component of knowledge is expe-
rience, as Knowledge develops over time [5]. The author also speaks
about the important impact of values and beliefs on knowledge, as
organizations are made up of people whose beliefs have influence on
their decisions and actions. Furthermore, he highlights the difference
between knowledge and information, in the sense that knowledge
contains judgment of the new situation and new information and
refines itself in response to this new situation.
3.2 Types of knowledge
Most of the time two types of knowledge are distinguished: explicit

and tacit. But sometimes there is a third type of knowledge, embedded
knowledge.
Explicit knowledge refers to the knowledge which can be codi-
fied, stored and shared through different technology. This type of
knowledge is easy to identify and process.
On the other hand, tacit knowledge is associated with an individ-
ual’s experience. Therefore, this type of knowledge is quite difficult to
codify and to share. For example, when a client calls tech support, the
operator tries to extract the problem from the provided information
by asking questions based on their experience. This is tacit knowledge.
14
After establishing the issue, the operator applies explicit knowledge

to solve the problem.
The third type of knowledge is embedded knowledge, which is
quite complex as it is deeply embedded in an organization’s culture,
processes, products or rules. This type of knowledge is independent of
the expert which created it, so when this person leaves the organization
the embedded knowledge is not lost and the afore-mentioned list
is not affected. An example of embedded knowledge might be an
algorithm for calculating the optimal schedule for trains. The train
company might have several requests for the calculation of a schedule
e.g. taking into account that certain cities have a higher population
than others and should therefore have more trains per hour leaving
stations in that city. In contrast, this differs from a system that tries
to have equal numbers of trains for all cities. This final algorithm
might be accessible for other programmers, but the story behind these
specifications (reasoning behind certain choices) will be less known,
even though the knowledge that was contained in this story could be
useful to future projects [8].
3.3 The SECI model

Hirotaka Takeuchi has provided a description for the interaction be-
tween tacit and explicit knowledge. This model is known as the SECI
model. It shows knowledge creation and four ways of knowledge
conversion: socialization, externalization, combination, and internal-
ization. According to the model, knowledge-creation and knowledge-
converting processes are dynamic, rather than static [7].
∙ Socialization: Tacit knowledge is shared with others through

practice and direct experience. An example of this would be an
experienced service operator and an intern. An intern learns
how to answer clients’ responses through observing how ser-
vice operators work and through their guidance.
∙ Externalization: This conversion method describes converting

tacit knowledge into explicit knowledge. In this way, knowl-
edge will be easily accessible and shared through the orga-
nization. However, it is really hard to codify and document
15
tacit knowledge. As an example, an intern might document

guidelines and instructions on how to support clients, which
were given by an experienced service operator. However, it
is arguable whether these guidelines can per definition con-
tain the intuition that this service operator has gained through
experience.
∙ Combination: Sources of different explicit knowledge are com-

bined and new explicit knowledge is generated.
∙ Internalization: This method refers to using theoretical knowl-

edge in practice and using explicit knowledge to generate new
tacit knowledge.
3.4 Definition of Knowledge Management

Knowledge is an essential resource for an organization. The success
of an organization depends on it. Each organization should know
what knowledge it possesses, what knowledge it needs, where this
knowledge is stored and how this knowledge is shared between em-
ployees. The answers to these questions are relevant for organizational
work-flow and are key to meeting organizational goals and strategies.
Knowledge management (KM) is all about answering these questions,
therefore it is strongly tied to organizational strategy.
There are various definitions of knowledge management, but for
this thesis the following definition is used: getting the right knowledge
available to the right people at the right time [9]. In other words, proper
knowledge management guarantees that when knowledge is needed
it will be easily accessible for usage. KM provides the creation, storing,
sharing and usage of knowledge.
According to DiMattia and others, there are two fundamental shifts
that gave rise to Knowledge Management: downsizing and technolog-
ical development [10]. Because of downsizing, organizations ended
up losing years of valuable experience and expertise, as the employees
who possessed important knowledge left the organizations. There-
fore, the organizations came to recognize the necessity of managing
employees’ knowledge. Technological development has created a po-
tential infrastructure for managing knowledge [5]. Through different
16
IT tools, such as email, groupware, the Internet, etc, it is possible to

create, store and exchange knowledge.
3.5 Knowledge Management in organizations

Knowledge management is important to an organization as it handles
the knowledge as an actual asset of an organization [9]. To manage
this asset, an organization needs a proper knowledge management
system. It helps an organization to capture and transfer knowledge,
which will be used for organizational development and success.
For example, employees might refrain from sharing knowledge
with others, because they are convinced that certain information is
critical to their unique value and sharing it might cost them a possible
promotion [11]. The right knowledge management creates a culture
of learning and sharing within the organization.
Additionally, knowledge management increases performance and
productivity of employees, services and products by making the right
knowledge accessible where it is needed. The larger the organization
is, the harder it is to manage knowledge without proper knowledge
management [5]. In small organizations, most of the time the manager
knows who has the specific experience for solving or performing
concrete tasks and can just ask employees to share knowledge or
perform a particular job at the moment when it is needed. However, the
situation is really different in enterprises and large companies, where
it is impossible to know every employee and who possesses certain
knowledge. Knowledge is only a valuable asset to the organization
when it is available at the right time. In this case, without a proper
KM system, it might be the case that the solution to the problem
is already present, but not directly available or known. As a result,
employees would develop a similar solution from scratch. It is clear,
that this kind of situation has a negative effect on the performance of
the organization.
3.6 Knowledge Management frameworks

A knowledge management framework (KMF) explains the domain of
knowledge management, defines an implementation schema and pro-
17
vides guidance toward an appropriate knowledge management sys-

tem. A KMF describes major KM components and principles that
define how these components interact with each other [12].
Developing a KMF is the first step toward implementing knowl-
edge management in an organization. In the absence of a sound KMF,
different problems might emerge. Without proper guidance, organiza-
tions may focus more on using information technology during a KM
implementation without considering that changes are also needed in
the organizational culture. Additionally, when access, transfer and
usage of knowledge is improved, only explicit knowledge might be
considered and the management of tacit knowledge might be ne-
glected. [13].
In general, there is no universally accepted framework, which
means that there are a lot of different KMFs which contain different
KM components, have a different structure and use different termi-
nology for similar things [12]. Despite the wide range of knowledge
management frameworks, what is common for these frameworks is
that they revolve around one or both of the following components:
knowledge management processes and knowledge management success and
failure factors. Both components are explained in the next sections.
3.7 Knowledge Management processes

Different literature identifies different numbers of knowledge processes,
which can be grouped into four main processes: knowledge creation,
storage and retrieval, transfer and application [14]. In different literature,
knowledge processes are also called knowledge activities and moreover,
similar processes can have different names. In the next subsections,
four KM processes (shown in Figure 3.2) are described in detail.
3.7.1 The process of knowledge creation

Knowledge creation refers to the process of generating new knowledge
for an organization. There are two approaches to this process. One is
when new knowledge is created within the organization and another
approach is knowledge acquisition, when new knowledge is gained
from external sources [14].
18
Knowledge Management Processes
The process The process

The process The process
of knowledge of knowledge
of knowledge of knowledge
storage and transfer and
creation application
retrieval sharing
Figure 3.2: Knowledge Management Processes
In an organization, new knowledge can be created through experi-

mentation, practice and interaction. An example of creating knowledge
at the individual level might be different training programs. For gener-
ating new knowledge at the community level, cross-functional project
teams are more beneficial, where a team is formed from different
departments with different expertise. This type of group might be a
source of innovation and new knowledge for the organization, if they
are given certain autonomy and freedom to conduct experiments [9].
New knowledge can also be acquired outside of an organization
from different sources: customers, competitors, suppliers, etc. Proper
sources of knowledge should be found in order to meet an organiza-
tion’s requirements for new knowledge.
3.7.2 The process of knowledge storage and retrieval

Knowledge storage and retrieval refers to the creation of organizational
memory and developing a means to access it. In the literature, two
types of memory are distinguished: internal and external. Internal
memory is tacit knowledge and the memory which resides within
the individual. External memory refers to the codified and explicit
knowledge of an organization [14].
For storing and retrieving explicit knowledge, IT based tools are
effective. These tools are used for developing external memory and
categorizing knowledge by a hierarchical structure in order to make it
easy for employees to access and retrieve. Additionally, social network
19
analysis and other knowledge maps are used to establish the location
of tacit knowledge sources [9].
3.7.3 The process of knowledge transfer and sharing

The process of Knowledge transfer and sharing refers to the commu-
nication of existing explicit or tacit knowledge to the place where it
does not exist yet and is needed to perform specific tasks.
Three methods of sharing data are distinguished: exchange be-
tween individuals (person-to-person), exchange between individuals
and knowledge repositories, and the last method is between knowl-
edge repositories. Therefore, in the literature two IT based sharing
systems are identified: the network model and the knowledge stock
model [14].
The first model is oriented around sharing tacit knowledge and
helps to establish a connection between individuals that are in different
locations. The knowledge stock model focuses on sharing explicit
knowledge between electronic knowledge repositories.
3.7.4 The process of knowledge application

Knowledge application is the process when knowledge is actually used
for solving problems and performing tasks in an organization [14].
Knowledge gains its value when it is used in practice for making
decisions. Knowledge application by itself is dependent on knowledge
creation, storage and sharing in the sense that these processes all make
knowledge available.
3.7.5 Knowledge management systems

A Knowledge Management System (KMS) is a managerial, technical and
organizational system structured to support knowledge management
processes. Examples of KMS are Groupware systems, intranet, content
management systems and document management systems. There are
three types of approaches for designing a KMS [11].
The codification approach focuses on explicit knowledge and pro-
cessing knowledge in electronic repositories, while the personalization
approach in Knowledge management systems is more focused on tacit
20
knowledge and aims to support ’face-to-face’ communication and shar-

ing knowledge between people. As tacit knowledge is more personal
and rooted in the individual’s experience, it is not easy to represent
and store via technology. Therefore, Knowledge management systems
(KMS) are less effective at processing tacit knowledge than explicit
knowledge [11].
The third approach is people-finder, which is not focused on creating
knowledge, but on finding sources of knowledge within an organi-
zation. In the literature, three types of employees are defined: one
who can acquire external knowledge and bring it into organization,
another who has the ability to gain knowledge within an organization
and lastly, one who has the capability to do both [15].
In addition, there is a fourth approach, hybrid, which aims to use
the first two approaches: codification and personalization. It aims to
support the implementation of all knowledge management processes
and create a comprehensive KM [11].
3.8 Knowledge Management success and failure

factors
Another essential element for a knowledge management framework is
that it should contain a description of critical factors which influence
the success and failure of knowledge management. The concept of
success and failure of KM is strongly connected to the expectation
which an organization has by implementing KM, therefore expecta-
tions should be realistic.
Different literature identifies and describes different influential
factors. In the book "Successes and Failures of Knowledge Manage-
ment" [16], seven factors/reasons are listed why companies are strug-
gling to implement KM in an organization. The following is a list of
these reasons:
1. culture;
2. measurement/benefits;
3. strategy;
4. organizational structure;
21
5. governance and leadership;
6. IT related issues;
7. lack of KM understanding/standards;
On the other hand, in the paper [17], Alan Frost identifies and
describes the failure factors in details that have been discussed in
KM literature. The failure factors are organized into two categories:
causal and resultant (shown in Figure 3.3). The most of this causal
failure factors listed by Alan Frost covers the list of reasons listed in
the previous paragraphs.
It is important to identify which failure factors apply to a specific
situation. When it is known which aspects can go wrong, an approach
can be designed to contain the applicable failure factors. The failure
factors
From the above, it is clear how essential it is for an organization
to have proper knowledge management. A structured approach to
achieving knowledge management is to use a knowledge management
framework. Therefore, to get a better overview of existing frameworks
and obtain the most sound KMF, next chapter will provide compar-
isons of the most notable frameworks.
22
KM failure
factors
Causal Failure Factors Resultant Failure Factors
Lack of performance indica- Lack of widespread contribu-

tors and measurable benefits tion
Inadequate management Lack of relevance, quality,

support and usability
Improper planning, design, Improper implementation of

coordination, and evaluation technology
Inadequate skill of knowledge Improper budgeting and ex-

managers and workers cessive costs
Problems with organizational Lack of responsibility and

culture ownership
Improper organizational Loss of knowledge from staff

structure defection and retirement
Overemphasis on formal
learning, systematization,
and determinant needs
Figure 3.3: Knowledge Management Failure Factors
23
4 Overview of various knowledge management
frameworks
In order to choose a suitable KMF to implement, this chapter is ori-
ented on analyzing and comparing different KMFs. Three different
types of frameworks are distinguished: prescriptive frameworks which
prescribe specific KM tasks (KM processes), descriptive frameworks
which identify attributes of KM which impact its success and failure,
and frameworks which depict both KM processes/tasks and the fac-
tors that influence knowledge management activities [18]. To develop
a comprehensive result, frameworks with a combination of both com-
ponents were taken as a starting point. The most important paper for
the analysis was "Harmonisation of knowledge management – com-
paring 160 KM frameworks around the globe" [19], which compares
160 different KMFs.
The following five frameworks cover every concept mentioned
above: a systems thinking framework for knowledge management
(see section 4.1), a framework of critical failure factors in KM projects
(see section 4.2), a threefold knowledge management framework (see
section 4.3), GPO-WM○ R
ramework (see section 4.4) and the European
KM framework (see section 4.5). This chapter describes each of them
and compares them to each other.
4.1 A systems thinking framework for knowledge

management
In 2001, Rubenstein-Montano et al. developed a comprehensive frame-
work (a systems thinking framework for knowledge management)
for KM. The concept of systems thinking infers that the framework
is both prescriptive and descriptive (shown in Figure 4.1). In this
framework, the knowledge management tasks include the following
activities: finding, verifying, storing, organizing, sharing, and using
knowledge [18].
Another component of the systems thinking framework is the in-
fluence factors for KM. The organizational culture is identified as one
of the influence factors. Cultural attributes impact how knowledge
24
4. Overview of various knowledge management frameworks
is shared, stored, distributed and used. As an example, an organiza-

tion’s culture among employees might be not to share knowledge, as
they think they would lose an advantage over other employees, which
directly translates into value, if they do. Another attribute of the frame-
work is learning, which is important for organizations if they want to
maintain their relevance and current knowledge. Two types of learning
are distinguished: single-loop learning and double-loop learning. The
difference is that in double-loop learning new knowledge is created by
combining existing knowledge and new knowledge. The framework
also focuses on the distinction between tacit and explicit knowledge,
as each type of knowledge should be managed differently [20].
organi-
zational
culture
tacit &
learn- KM explicit
ing tasks knowl-
edge
organi-
zational
strategy
Figure 4.1: A systems thinking framework
The authors give several recommendations regarding the KM

framework, which should be taken into account:
1. the organizational strategies and goals must be linked to knowl-

edge management;
25
2. planning should occur before knowledge management activi-

ties are undertaken;
3. cultural aspects of an organization must be recognized and

knowledge management must occur in a manner compatible
with the culture of the organization;
4. knowledge management is an evolutionary, iterative process

directed by feedback loops and learning [18];
4.2 The framework of critical failure factors in KM

projects
Peyman Akhavan and Amir Pezeshkan performed an analysis of sev-
eral cases when the implementation of KM in an organization was
unsuccessful. As a result of the analysis, they listed the critical failure
factors which played a role and determined these failure factors in
each stage of the KM cycle. They proposed a framework in which the
failure factors are linked to the different stages in the cycle of the KM
implementation. The framework shows the susceptible failure factors
in different stages of KM implementation cycle based on the results of
their study [21].
In the framework, the following seven KM stages (KM processes)
are listed for a KM implementation (shown in Figure 4.2):
1. Infrastructure and preparation;
2. Knowledge identification;
3. Knowledge collecting;
4. Knowledge organizing;
5. Knowledge storage;
6. Knowledge sharing
7. KM evaluation;
For each of the stages, different critical failure factors are identified.
26
4.2.1 Infrastructure and preparation

Infrastructure and preparation is the first stage of the KM cycle, where
main decisions, such as quality of KM systems are made. Therefore, the
authors identified the following failure factors during this stage [21]:
∙ Lack of familiarity with aspects of KM projects of top managers
∙ Inappropriate members of KM team
∙ Lack of detailed planning and timing for KM project
∙ Lack of separate and sufficient budget for KM
∙ Lack of commitment and support of top management for KM
∙ Improper technical infrastructure.

Ways to mitigate these failure factors are: choosing an appropriate
KM team and leader in the initial stage and making sure the top
management is familiar with the KM project and provides support
for the KM project [21].
4.2.2 Knowledge identification

The next step is the knowledge identification step and during this
stage the required knowledge for business processes is identified. An
essential factor for this step is sufficient involvement of workers, since
identifying critical knowledge is a challenging task which will affect
the firm as a whole [21]. The following critical failure factors should
be addressed during the knowledge identification step:
∙ Lack of sufficient involvement of workers;
∙ External consultants’ weakness in business knowledge and

organizational relation;
4.2.3 Knowledge collecting

In the knowledge collecting stage, identified knowledge is gathered to
be used. During this step technology is used to design and prepare
knowledge bases and documentation systems [21]. Therefore, the list
27
Knowledge Knowledge
identification collecting
Knowledge
KM evaluation organizing
Knowledge Knowledge
sharing storage
Infrastructure and preparation
Figure 4.2: KM cycle [21]
of critical failure factors which might affect success of KM during this

stage are:
∙ nonconformities between current systems and new systems;
∙ inappropriate knowledge structure which is formed initially
in this step;
∙ weak usability of KM system whose architecture is prepared
in collection step;
4.2.4 Knowledge organizing

During the knowledge organizing stage, the collected knowledge is
structured and processed to be utilized within the organization [21].
This step is more technical than others, therefore the failure factors
are technical too:
28
∙ Nonconformities between current systems and new systems,

which means that new system should conform current one.
Otherwise users abandon new system;
∙ Inability of KM team for distinguishing organizational rela-

tions;
∙ Inappropriate knowledge structure;
∙ Irrelevant knowledge with inappropriate flow and stream;
∙ Weak usability of KM system;
∙ External consultants’ weakness in business knowledge and

organizational relation;
4.2.5 Knowledge storage

The next stage is the knowledge storage stage, which is also a technical
stage. Therefore, for this step, the authors identify similar critical
failure factors as for the knowledge collection stage [21]:
∙ Nonconformities between current systems and new systems;
∙ Inappropriate knowledge structure;
∙ Weak usability of KM system;
4.2.6 Knowledge sharing

The greatest number of critical failure factors are identified at the
knowledge sharing stage. These failure factors are connected to the
issues such as organizational culture, resistance against change, man-
agerial issues etc [21]. The full list of critical failure factors mapped to
knowledge sharing stage are:
∙ Lack of KM-oriented culture in organization;
∙ Lack of knowledge sharing because of knowledge speculation;
∙ Lack of sufficient involvement of workers;
29
∙ Lack of required relation among workers;
∙ Not clarifying the KM result relation to routine tasks;
∙ Unfamiliarity of workers with KM tools;
∙ Wrong perceived image of KM;
∙ Inefficient reward system;
∙ Lack of conflict management;
∙ Resistance against the change in organization;
∙ Overreliance on technology;
In other stages, there is a higher emphasis on technological issues than

human and behavioral issues, but in the knowledge sharing phase,
the human factor is crucial, as workers should be motivated to become
involved in sharing knowledge [21].
4.2.7 KM evaluation
During the KM evaluation stage, a KM system is evaluated and its
flaws are identified in order to eliminate shortcomings. The following
failure factors are listed for this stage:
∙ Lack of commitment and support of top management for KM;
∙ Lack of efficient strategy for development and roll-out;
∙ Not measuring and evaluating the KM project result;
4.3 A threefold knowledge management framework

Holsapple and Joshi suggested a threefold KM framework that fo-
cuses on identifying key components for a knowledge management
implementation. This framework comprises the following three com-
ponents [22]:
30
1. The first component identifies all the knowledge resources in

an organization. In the paper [22], knowledge resources are
defined as the organization’s knowledge reservoir, which can
be represented in tacit and/or explicit form.
2. The second component describes the knowledge manipulation

activities, which are used to manage knowledge resources. The
organization’s participants (human and computer-based) use
these activities to produce and consume knowledge.
3. The last component identifies major influences, which have an

impact on knowledge management in an organization.
4.3.1 The Knowledge Resources

Holsapple and Joshi [22] distinguish 6 types of knowledge resources:
participants’ knowledge, culture, infrastructure, knowledge artifacts,
purpose, and strategy.
Participants’ knowledge resources can consist of either human
resources or material resources (such as computer systems) in the or-
ganization. This type of resource is affected by employees leaving their
job or participants learning. An example of participants’ knowledge
is an employee’s knowledge that is used to accomplish a task in an
organization. Participants’ knowledge should be stored/captured in
a computer system in order not to lose the knowledge after he/she
leaves the job [22].
Beliefs, values, unwritten rules, principles and norms all belong
to cultural knowledge resource. Culture is independent from partici-
pants’ knowledge, but it influences how participants use knowledge
and influences the interactions among participants.
Infrastructure refers to the roles of participants, relationships
among these roles and regulations which manage the use of roles
and relationships. Roles define what participants need to do, whereas
relationships define the interaction between participants to fulfill their
roles. A few examples of infrastructure would be service processes
and hiring processes [22].
A knowledge artifact is defined as an object which represents
knowledge. Knowledge artifacts belong to an organization but might
31
be accessible only to certain participants. Examples of knowledge ar-

tifacts are the following: training videos, business plans and patent
documents. Products of the organization also belong to knowledge
artifacts. Holsapple and Joshi say that a product is an artifact of knowl-
edge, which represents the knowledge that was used to build it [22].
The last two knowledge resources are purpose and strategy. Pur-
pose defines the reason of existence of an organization. It is strongly
tied to strategy, which defines what should be done to achieve an
organization’s purpose.
4.3.2 The Knowledge Manipulation Activities

The second component of the threefold framework is about identifying
knowledge manipulation activities, which the organization performs
on knowledge resources. Holsapple and Joshi refer to knowledge ma-
nipulation activities as a participant’s knowledge manipulation skills.
The authors distinguish six manipulation activities: acquiring knowl-
edge, selecting knowledge, internalizing knowledge, using knowledge,
externalizing knowledge and generating knowledge [22].
Acquiring knowledge is the process when knowledge is acquired
from external parties and transformed into internalized knowledge.
This knowledge might be used in the organization [22].
Selecting knowledge refers to the activity of extracting requested
knowledge from internal sources, and transferring it into the appropri-
ate activity. The authors give the following knowledge sharing system
as an example of a knowledge selecting process: a manager sends a
request for a solution to all employees, and the ones who have proper
knowledge answer the request with their suggestion [22].
Internalizing is the activity which changes existing knowledge
resources by adding knowledge, deleting knowledge, or restructuring
it fundamentally [22].
The using knowledge activity serves the purpose of generating
new knowledge from existing knowledge or externalizing it. Generat-
ing knowledge refers to procedures that lead to the generation of new
knowledge from exiting knowledge. As for externalizing knowledge,
it is the activity that produces an organizational product that will be
released into the environment [22]. For example, a CSIRT producing
a recommendation regarding a concrete vulnerability by using the
32
existing knowledge (process and product design) and then releasing

it to their predefined target.
4.3.3 The Major Influences

The third component of the framework identifies factors which influ-
ence the conduct of KM in an organization. The authors have listed
three influence factors: resource influences, managerial influences and
environmental influences [22].
Knowledge resources and other organizational resources influence
how KM is conducted. As an example, there might be a financial cap
on the expenses of knowledge manipulation activities, which restricts
it.
The managerial influences are divided into three factors: leader-
ship, coordination and measurement. Right leadership is essential for
every aspect of an organization, which includes KM. Organizations
are not able to manage knowledge resources effectively if leaders are
not willing to share knowledge in the organization. The second factor
is coordination, which means managing dependencies between activi-
ties. The last managerial influence is measurement, which is used to
evaluate the result of KM in terms of organizational learning [22].
Environmental influence is also essential for the conduct of KM in
an organization. An example of such factors are: customers, markets,
suppliers, and the GEPSE (governmental, economic, political, social,
and educational) climate [22].
4.4 GPO-WM○
R
Framework
In 2005, Heisig developed a knowledge management framework based
on different KMFs [19]. The framework consists of the three following
layers: Business process, Knowledge activities and enablers, which
influence the success of KM.
4.4.1 Business process

The KM has to demonstrate its benefits for business processes of an
organization not only from the management perspective but also from
33
the perspective of the employees (knowledge workers), who have to

perform these tasks on a daily basis [19].
4.4.2 Knowledge activities

In the framework four knowledge handling processes are identified:
create, store, share and apply. These knowledge activities should be
integrated into the business processes, as knowledge is a resource ap-
plied in the business process and as a result, the product is generated.
This product can be used by similar or different business processes in
the same or another organization [19].
4.4.3 enablers
The author identifies six enablers which influence success and sustain-
able knowledge management:
1. Culture;
2. Organizations and roles;
3. Strategy and leadership;
4. Skills and motivations;
5. Controlling and measurements;
6. Information technology;
A proper assessment is required to successfully implement KM for
the above mentioned enablers [19].
4.4.4 The GPO-WM implementation model

The task of the implementation model is to make it possible to cover
the following aspects [23]:
∙ to describe and evaluate the current state of handling core
knowledge domains;
∙ to gather improvement ideas for systematic knowledge han-

dling;
34
∙ to integrate selected KM methods and tools into business pro-

cesses in the organization
8. evaluation
KM-Implementation
7. Implementation
6. Detailed planing
5. KM-solutions
KM-Analysis and 4. GPO-WM analysis

Solution
3. KM-Audit
2. Business process
KM-Strategy
1. Corporate area
Figure 4.3: The GPO-WM implementation mode [24]
The GPO-WM implementation mode consist of three phases (shown

in Figure 4.3): KM-Strategy, KM-Analysis and solution, KM-implementation.
During these phases communication and marketing activities are es-
sential to inform stakeholders about the detailed objectives of the KM
initiatives.
The KM-Strategy phase consists of two design steps: Corporate
area and business process. At this phase, a KM-Strategy is defined by
choosing a corporate area and identifying business processes, which
35
should be improved with KM methods and instruments. The differ-

ence between the corporation strategy and KM strategy is that the
corporation strategy defines long term goals, politics and business
strategies, while KM Strategy describes KM vision, specifies KM goals
and focuses on areas where KM activities will be started. In this phase,
management should name the relevant knowledge domains in their
business context. As an example, the most common knowledge do-
mains are: customer knowledge, knowledge in people, knowledge in
products.
The KM-Analysis and solution phases consist of three design steps:
KM-Audit, GPO-WM analysis and KM-solutions. The aim of this phase
is to develop a KM-solution. The KM-audit provides data about cur-
rent state of affairs, whereas in GPO-WM analysis step, the business
processes are described according KM criteria. The design of a KM-
solution aims to achieve a closed process of the four core knowledge
management activities integrated into the business process to be im-
proved [24].
The last phase focuses on the actual implementation of KM in an
organization. It starts with a detailed planning, next follows actual
implementation of the selected KM solution and the last step is an
evaluation of the KM project [24].
4.5 The European KM framework

The European KM framework consists of three layers. The first layer
defines that the business focus should be in the center of KM initiatives.
The second layer is more oriented on the following five knowledge
activities: identify, create, store, share and use. These activities are
typically performed on business processes. The enablers represent the
third layer of the framework and they are divided into two main cate-
gories: personal and organizational knowledge capabilities. Personal
knowledge capabilities include ambition, skills, behavior, experience,
tools and time management. Organizational knowledge capabilities
are the mission, vision, strategy, organizational structure and the de-
sign of processes, measurement, understanding of culture, the use of
technology and infrastructure. The European KM framework can act
as a checklist to ensure nothing is overlooked [25].
36
In the paper [25], a general project management scheme for KM

is defined, which consists of five phases (shown in Figure 4.5). The
following chapters cover the framework itself and an implementation
scheme of the mentioned framework.
4.5.1 The first layer of the framework

Knowledge management initiatives should improve business pro-
cesses within the organization. Different knowledge approaches are
used by employees to perform their daily tasks.
4.5.2 The second layer of the framework

The paper [25] describes the second layer of the framework’s knowl-
edge activities in detail (shown in Figure 4.4):
1. Identify Knowledge: People and organizations should think about
what they want to achieve, and accordingly identify what
knowledge they need to perform that task. This step should
also conclude the analysis about the current state of knowl-
edge which is available and which is lacking to achieve the goal.
Identification of existing knowledge should take place before
the creation of new knowledge, as it will facilitate reuse of ex-
isting knowledge. The paper identifies the following common
methods and tools that support this step: feedback, brainstorm-
ing and mapping techniques.
2. Create Knowledge: There are different techniques and ways to
create new knowledge at the personal or team level. Examples
of this are training, brainstorming, and innovation processes.
However, the most crucial aspect is to store the newly created
knowledge in order to reuse it.
3. Store Knowledge: The majority of knowledge is tacit knowledge
in the organization, which is resides in people’s brains. As for
storing explicit knowledge, it depends on supporting activities
such as selecting, organizing, categorizing and updating. The
paper lists the following technical tools for storing knowledge:
document databases, question and answer systems, Narrative
and expertise locators.
37
4. Share Knowledge: The aim of this activity is to make knowledge

available at the right place at the right time, with the right
quality. Two approaches for knowledge transfer are identified:
stock approach and flow approach. The stock approach is when
knowledge is added in the databases or distributed via docu-
ments. This means that people make knowledge available in
such a way, that other people can find it. The Flow approach
is when knowledge is shared between people through direct
interaction via collaboration, workshops, coaching, etc. A few
examples of methods and tools which supports knowledge
sharing are the following: intranets/portal, databases, semi-
nars, coaching and training.
5. Use Knowledge: Knowledge is valuable when it is used. This

activity is about making sure that all the effort made over
the previously described four knowledge activities pays off.
During the application of knowledge, a knowledge gap might
be discovered.
An essential aspect is that knowledge activities have to be integrated

into business processes of an organization and its daily tasks.
4.5.3 The third layer of the framework

The third layer of the framework is focused on enablers which are key
success factors for KM and divided into two main categories: personal
and organizational knowledge capabilities.
The personal knowledge capability is divided in several groups:
∙ ambition: Sharing knowledge is essential to achieve the objec-

tive of the organization and individuals. Without personal
and collective ambition, it is difficult to motivate employees to
share knowledge or take part in knowledge processes.
∙ skills: This is a person’s ability to perform core knowledge

activities efficiently. An example of such a skill would be an
employee’s ability to effectively communicate/share knowl-
edge with other employees.
38
Identify
Use
KM activities Create
Share
Store
Figure 4.4: The second layer of The European KM framework
∙ behavior: People in a company should exhibit knowledge be-

havior, which means that they should be able and willing to
develop, share and apply knowledge.
∙ methods, tools and technologies: There should be proper tools

in the organization that provide the possibility to perform
different knowledge activities. The existence and accessibility
of such tools and methods is essential for successful KM. For
processing explicit knowledge more and more technical tools
are available. The following non-technical tools can also be
used for knowledge activities: coaching, workshops, expert
meetings and social events.
∙ time management: The idea of time management is that employ-

ees have to learn how to manage their time efficiently.
∙ personal knowledge: It is defined as the skill to solve unforeseen

problems, taking self-responsibility and decision-making.
39
Second category of enablers is organizational Knowledge capabili-

ties. It describes the conditions that the leadership of an organization
has to establish for effective KM:
∙ Mission, Vision and Strategy: The organization should define

its mission, vision and strategy. Without knowing why, what
and how, it will be very difficult to link knowledge to business
objectives.
∙ Culture: Organizational culture should be such that people

should be respected based on knowledge they have and use.
∙ Process and Organization: As Knowledge activities should be

integrated into business processes, it is important to define
roles and responsibilities related to processes and knowledge
activities.
∙ Measurement: Measurement of KM means to evaluate the cost-

benefits of a KM solution, also to have an indicators to monitor
development KM activities.
∙ Technology and Infrastructure: Technological tools provide great

opportunity to manage knowledge, for example: expert locat-
ing, e-learning and databases. Non-technical tools also play a
big role for KM.
∙ Knowledge Assets: The biggest challenge for the organization

is to develop shared knowledge assets. Knowledge assets are
those, which stays in the organization when an employee leaves
the company.
4.5.4 Phase A: Setting up a KM Project

The first phase of a project management schema for KM is setting up
a KM project. During this phase the KM initiative should be defined
and linked to the overall business strategy. To give a KM initiative
overall directions, the following aspects should be defined [25]:
∙ The KM mission: explains why KM is important for the organi-

zation.
40
∙ The KM vision: The vision states what an organization wants

to achieve with their KM initiative and what they expect to
change within the organization.
∙ The KM strategy: defines steps and procedures on how to be-

come a KM-enabled organization. Defining this strategy helps
the organization choose the right KM tools from a large num-
ber of tools.
∙ The KM aims: defines what the organization wants to achieve

with the KM initiative.
The result of these phases is that the business processes with its
key knowledge resources are identified and their status is assessed by
the management team. Additionally, a KM project team is appointed.
4.5.5 Phase B: Assessment

The second phase is oriented on the assessment of the current state
of knowledge assets and flows. The organization might already have
tools and methods as evidence of KM. In this phase, the organization
identifies whether there is already a KM strategy in place, what is
missing and possible indications of where KM has gone wrong [25].
The paper [25] identifies different tools for KM assessment:
∙ Diagnostic tools that are oriented on a self-assessment which

was performed during a workshop.
∙ Knowledge audit focus on required knowledge and provides

useful basis for structuring knowledge for electronic applica-
tion.
∙ KM audit tools using questionnaires to conduct assessment of

KM.
To conclude, during phase B, the right tool for KM assessment

should be chosen and an audit should be performed [25].
41
4.5.6 Phase C: Development
This phase is oriented on listing knowledge requirements, an evalua-

tion of alternative solutions and a design of the core elements of the
KM solution. After the current state of KM has been identified, the
next step is to choose the right KM tools/methods for improving the
current state of KM, which is a final KM solution [25].
The company should analyze whether the existed tools could be
further developed or adapted and whether it is needed to get external
providers. The result of this phase is a final KM solution with adequate
KM methods and tools [25].
4.5.7 Phase D: Implementation
During this phase, an actual implementation of the chosen KM solu-

tion takes place, including training of the end-users regarding the tools
and methods. The implementation phase is a continuous part of KM.
The essential factors which should be taken into consideration during
this phase are following: time, people and budgetary control [25].
4.5.8 Phase E: Evaluation/Sustainability
The last phase focuses on evaluating the project. The following is a list
of indications of successful KM projects:
∙ growth of the knowledge content and usage,
∙ involvement of the entire organization,
∙ global familiarity with the terms knowledge and KM
At the end of the evaluation phase, the KM project should be

evaluated. In case of success the methods introduced should be spread
throughout the whole organization, otherwise the reasons of failure
should be investigated and a decision needs to be made whether
project should be re-launched or canceled [25].
42
Phase E:
Evaluation
Phase A:
Setting up a KM Project
Phase D:
Implementation
Phase B:
Assessment
Phase C:
Development
Figure 4.5: A general project management scheme for KM implemen-

tation [25]
4.6 Comparison of the frameworks and suggested

Prototype Framework
Now that all the frameworks have been introduced, a proper com-
parison can be made between them. In this subsection, advantages
and disadvantages of each framework will be identified and weighed
against the others.
All of the frameworks described above identify knowledge manage-
ment processes (activities) and influential factors as main components
of the framework. However, there are still strong differences between
them.
The system thinking framework provides useful directions for
identifying the core components of KM frameworks and choosing
the frameworks which would be used for the prototype. However,
it does not address most of the influential factors which might have
43
crucial effect on KM success, such as information technology which is

one of the most important technical means for managing knowledge.
Therefore, for the prototype, this system thinking framework will not
be used.
The framework of critical failure factors in KM projects helps to
recognize potential failure factors during each phase of KM activi-
ties [21]. Therefore, during the implementation of each KM process,
these potential failure factors should be taken into account and solu-
tions should be identified for each of them. I believe this approach
should be part of the prototype framework, because it would be useful
to mitigate failure factors for KM. On the other hand, the framework of
critical failure factors in KM projects does not contain sufficient details
and directions on how the framework should be implemented and
what phases should be done for implementing KM. A more detailed
description and explanation is necessary to implement this framework
in practice. However as as it was already mentioned, it helps to identify
potential factors for each KM processes and this positive side should
be included in the prototype framework.
A threefold KM framework suggested by Holsapple and Joshi iden-
tifies and suggests different types of knowledge resources (the term
knowledge domain is used in other frameworks), which should be
focused on during the implementation of KM. This gives some direc-
tion to identify knowledge resources in an organization. Compared
to the other described frameworks, none of them really suggest any
types of knowledge resource in detail. These types of knowledge re-
sources should be included in the prototype framework as it will help
to identify types of knowledge resources in the organization during
implementation. The main disadvantage of this framework is that
it does not provide information how actually the framework can be
implemented, what phases are necessary and what it should be done
in each phase.
The GPO-WM framework and the European KM framework are
more oriented on Business processes and they have major similarities.
Both frameworks cover the following aspects which are really impor-
tant for KM: business processes, people and technology. Knowledge
should be identified in business processes, but people and technology
are identified as one of the influential factors for KM and need to be
taken into account. Both the GPO-WM framework and the European
44
KM framework provide an implementation plan. However, the Euro-

pean KM framework gives more detailed directions on what should
be done during each phase of the implementation and provides a
description of a wide variety of KM tools, and therefore it is more
convenient to choose and access the right tool.
Another difference between the GPO-WM framework and the Eu-
ropean KM framework is that the GPO-WM framework identifies
four knowledge processes: create, store, share and apply. The Euro-
pean KM framework identifies one more activity which is identifying
knowledge. I believe that identification of knowledge belongs to the
implementation process of a KMF. Therefore, this activity should be
integrated during the implementation when analyzing what organi-
zation want to achieve and what knowledge they need.
To conclude, the European KM framework can be used as a proto-
type for implementing KM, as it is a framework which covers all the
elements of KM and also provides a detailed description regarding
implementation steps. For implementing the mentioned framework,
it would be better if the knowledge process activities will be accord-
ing to the GPO-WM framework: generate, store, distribute and apply
knowledge. Additionally, the framework of critical failure factors in
KM projects should be used as a checkpoint for mitigating and solv-
ing failure factors and the threefold KM framework should be taken
into account when knowledge resources are identified in the business
process during the implementation.
The next chapter goes into detail on this prototype framework and
presents the implementation of this framework within CSIRT-MU.
45
5 Implementation of Knowledge Management
in CSIRT-MU
This chapter covers the practical part of the thesis. The context of
CSIRT-MU is described, which is followed by the prototype framework
and the resulting prototype knowledge management system.
5.1 CSIRT-MU
Masaryk University Computer Security Incident Response Team was
formed in May 2009 and is tasked with the defense of Masaryk Uni-
versity’s network. CSIRT-MU consists of three groups: the Incident
response group, the Proactive security group and the Secure digital
identities group [26].
5.1.1 Mission statement

CSIRT-MU’s goals are the following [27]:
∙ to create a trustworthy central contact point for ICT infrastruc-

ture at Masaryk University (MU);
∙ to provide an incident handling service to the MU ICT infras-

tructure;
∙ to share knowledge among the students and staff of MU in

order to raise IT security awareness;
∙ to take part in cyber security projects and develop tools, tech-

nologies and procedures to contribute to the state-of-the-art
cyber security domain.
5.1.2 Constituency
The constituency of CSIRT-MU is defined by a range of IP addresses:
for IPv4, these are the addresses within the range 147.251.0.0/16 and
for IPv6, these are the addresses within the range 2001:718:801::/48.
The domain muni.cz also belongs to the constituency [27].
46
5. Implementation of Knowledge Management in CSIRT-MU
CSIRT-MU has full authority over its constituents, which means

that the team is authorized to respond to all types of computer secu-
rity incidents which occur, or threaten to occur, in its constituency.
The team is authorized to monitor the operations of the computer
resources in the network in the domain of MU and disconnect a net-
work subdomain or host in case of an emergency situation [27]. For
handling and preventing computer security incidents in IT MU1 , the
team cooperates with the administrator of the IT MU element2 [28].
5.1.3 CSIRT-MU Services

CSIRT-MU provides the following services to its constituency: incident
handling, warnings and information, penetration testing, IT adminis-
trators education, educating users and the administration of digital
identities.
5.1.3.1 Incident Handling

The following information can be found on CSIRT-MU’s website:
CSIRT-MU offers incident handling services to Masaryk University,
in order to protect the security of MU’s infrastructure and network.
The team from MU handles all three types of attacks which occur in
its constituency:
∙ incidents which threaten the security of Masaryk University’s
network infrastructure, which includes DoS attacks, password
breaks, port scanning.
∙ attacks on users of MU’s network and services. Examples are
phishing or e-mail scams.
∙ other cybersecurity incidents which are relevant to MU [26].
An incident handling process starts with an incident report. Inci-
dents can be reported to CSIRT-MU with the help of a website form,
an email or a phone call.
1. IT MU means a set of technical and software equipment, networks and services

used for the purpose of data processing at MU
2. An administrator of IT MU element is an employee of MU who is responsible
for a separately manageable part of IT MU
47
5.1.3.2 Alerts, Warnings and Announcements

CSIRT-MU constantly monitors their network to detect possible at-
tacks, security vulnerabilities or intrusions and notifies MU users of
relevant threats. Furthermore, the team gives recommendations and
guidance to its constituency to protect their systems [26].
5.1.3.3 Penetration testing

CSIRT-MU offers its constituency penetration testing services, which
check the system for vulnerabilities and possible attack vectors. Fur-
thermore, the team provides recommendations to mitigate the threats [26].
5.1.3.4 IT administrators education

CSIRT-MU provides training for IT administrators within its con-
stituency in order to raise the awareness regarding security.
5.1.3.5 Educating Users

CSIRT-MU provides basic cyber security training for all users within
its constituency.
5.1.3.6 Administration of digital identities

The CSIRT-MU team is responsible for managing access to the services
at MU.
5.1.4 Place in Organization

CSIRT-MU is a part of the Institute of Computer Science, therefore man-
agement, liaison and supervision are provided by head of Communi-
cation Infrastructure Division of Institute of Computer Science [26].
CSIRT-MU covers the computer security of Masaryk University and
addresses computer security incidents. On the other hand, CSIRT-
MU does not give direct support to the end-users. This responsibility
belongs to system or network administrators of the respective depart-
ments.
48
5.1.5 Relationship to Others
Communication and coordination among CSIRTs is essential in or-

der to share information regarding incidents and attacks. Therefore,
CSIRT-MU also cooperates with other organizations on a national
and international level and exchanges essential information regarding
security incidents [26]. Cooperation with the global security infrastruc-
ture of the CSIRT teams is essential, therefore CSIRT-MU collaborate
with Trusted Introducer and has a "certified" team status.
The following are organizations that CSIRT-MU collaborates with:
∙ CSIRT.CZ is the National CSIRT of the Czech Republic and it

is administered by the CZ.NIC association, which operates the
domain name registry for the .CZ domain, the CZ top-level
domain and public education in the area of domain names.
∙ CESNET is an association of universities of the Czech Republic

and the Czech Academy of Sciences. Masaryk University uses
the CESNET e-infrastructure to connect to the Internet. In case
of security incidents, participants are obliged to inform and
handle incidents in collaboration with the CESNET-CERTS
team [29]. Therefore, this partnership is important for the inci-
dent handling service as CSIRT-MU cooperates with CESNET-
CERTS to solve the security incidents in the MU network.
∙ CSIRT-MU cooperates with The National Cyber and Information

Security Agency (NÚKIB/NCISA), which is a central state body
for cyber Security in Czechia. NCISA operates the Governmen-
tal CERT (GovCERT.CZ).
∙ GÉANT is an international partner for CSIRT-MU. Géant facil-

itates a platform known as TF-CSIRT, which provides a forum
where members of the CSIRT community from the research
and education networking community and other sectors from
around the world, exchange experiences and knowledge in
a trusted environment in order to improve cooperation and
coordination.
49
5.2 The prototype of KM framework for CSIRT-MU

This section describes a customized knowledge management frame-
work that is based on the frameworks that were introduced in chapter 4
and has been tailored to CSIRT-MU.
The prototype framework mostly follows the European KM frame-
work, and contains components from other frameworks. As mentioned
before, the first layer of the European KM framework focuses on busi-
ness processes. In this case, the target is the incident handling team,
which is a part of the incident response group of CSIRT-MU and
consists of 4 people who deal with the day-to-day incidents. It is
necessary to identify the knowledge resources within the business
processes of the incident handling service. The following knowledge
resources from the threefold KM framework will be addressed: partic-
ipant knowledge resources and knowledge artifacts. The framework
mentions other types of knowledge resources, but they have been
incorporated in other stages of the framework, which is why they can
be ignored here.
The second layer of the framework, which focuses on knowledge
activities, is based on the GPO-WM framework and consists of four
knowledge activities: knowledge creation, storing knowledge, knowl-
edge sharing and knowledge usage. All these activities should be
applied to knowledge resources which will be identified for the inci-
dent response service of CSIRT-MU.
The third layer of the framework, which covers the key success
factors of KM, should be customized in this case. As the KM implemen-
tation is focused on the incident handling team, not all the influential
factors which were listed in the original framework will be applicable.
Additionally, applicable failure factors which were identified in the
framework of critical failure factors in KM should be added for this
layer. The following is a list of influential factors for success and failure
of implementing KM for the incident response service of CSIRT-MU:
∙ Lack of sufficient involvement of incident handlers;
∙ IT related issues such as improper technical infrastructure;
∙ Nonconformities between current systems and new systems,

which means that the fundamentals of the new system should
50
not be too different from the existing system, otherwise users

will abandon the new system;
∙ Measurement of KM means to evaluate the cost-benefits of a

KM solution, also to have indicators to monitor development
KM activities;
∙ Inappropriate knowledge structure which is formed during

the implementation.
∙ Unfamiliarity of incident handlers with KM tools.
The original project management schema of the European KM

framework for implementing KM in the incident handling team was
incompatible without customizing it, as the original implementation
is oriented on small and medium-sized enterprises. Addionally, the
prototype framework contains components from other frameworks,
therefore it was necessary to customize the implementation schema.
The implementation of KM will therefore take place in three phases:
assessment of KM in the incident response team, development of a
KM solution in the incident response team and an evaluation of the
suggested solution.
The motivation for this thesis already implicitly finished phase A:
"setting up KM project" from the European KM framework implemen-
tation schema as most aspects of this phase were already established
before the start of the thesis. The KM aim is to improve the perfor-
mance of the incident handling process by implementing KM in the
business processes.
5.2.1 Phase 1: Assessment of KM
The assessment of KM phase mostly follows the assessment phase

from the European KM framework, which means that during this
phase, the right tool for KM assessment will be chosen. Through an
audit, the types of knowledge which are used during the incident
handling process and the tools as evidence of KM are identified.
51
5.2.2 The Phase 2: Development of KM solution

This phase is similar to phase C of the European KM framework:
Development. The input of this phase is the data from phase 1. During
this phase, the following topics will be addressed: finding a solution for
the incident response group’s KM requirements, evaluating alternative
tools for knowledge management and integrating KM principles into
the current incident response service.
5.2.3 The Phase 3: Evaluation of the suggested solution

This phase is different from the last two phases of the European KM
framework. It mostly focuses on testing the prototype solution and
updating the parts of the solution which need refinement. This phase
involves introducing the KM solution from phase 2 to the end-users
(in this case incident handlers) and updating parts of the solution
according to the received feedback. As the result of this thesis is a pro-
totype, the implementation of the prototype knowledge management
system in practice is out of scope.
5.3 The implementation of KM in Incident response

team
This section provides the actual implementation of KM in CSIRT-MU
describes each phases in detail (shown in Figure 5.1).
5.3.1 Phase 1: Assessment of KM in the incident response team

The most important influential factor, which was identified for this
phase and addressed accordingly, was "lack of sufficient involvement
of worker". This factor was addressed by conducting interviews with
incident handlers.
For the assessment of KM in the incident handling team of CSIRT-
MU, the Fraunhofer KM Audit approach was used, which is one of the
tools that was introduced in the European KM framework. The Audit
comprises the following steps: initial state (preparation), focus setting,
adjustment of inventory, survey, analysis and evaluation, feedback
workshop and project start [25].
52
March 2019
Start of Phase 1 Phase 1: Assessment of KM in the incident response team
KM audit is performed: interviews with incident handlers
March 2019 Knowledge requirements
Start of Phase 2
Phase 2: Development of KM solution in incident response team
Evaluation of alternative solutions and designing prototype of KMS
May 2019 The prototype of KMS
Start of Phase 3
Phase 3: Evaluation of the suggesting solution
Evaluation of alternative solutions and implementing improvements
The improved prototype of KMS

End of Phase 3
Figure 5.1: The time-line and the details of implementation of KM in

Incident response team
During the ’initial state’ step and ’focus setting’ step of the KM
audit, the relevant documents regarding incident handling processes
and procedures were analyzed. Additionally, several members of the
incident handling team were approached for the interviews.
During the ’adjustment of inventory’ and ’survey’ steps, customized
questionnaires were prepared regarding the incident handling pro-
cess and interviews were performed. It should be mentioned here
that the sole reason for these interviews was to create an overview of
knowledge domains and processes within the team. As a result, new
answers led to new questions that were incorporated in every new
interview, so the questionnaires were altered in between interviews.
53
As the answers to the questionnaires were confidential, these will

not be published. However, the questionnaires are included in the
appendix A and are focused on the following topics:
∙ Current incident handling process: this part of the question-
naire covered the specifics of the incident handling process at
CSIRT-MU and how the incident handling process for different
security incidents differs.
∙ Types of knowledge: the purpose of the questions was to de-
fine types of knowledge which are used in incident handling
processes and to identify knowledge gaps in the process. The
focus was on participant’s knowledge resources, which include
human resources and material resources, and knowledge arti-
facts such as training materials. The questions regarding tacit
knowledge were oriented on finding how personal knowledge
between team members was shared and what KM tools are
used for supporting KM activities for tacit knowledge. The
questions for explicit knowledge were focused on identifying
what types of documents/encoded knowledge is used for the
incident handling process, which knowledge is more important
in resolving the security incidents and how this documented
knowledge is created/generated, stored and accessed, shared
and used.
∙ Tools which are used for incident handling: this covers the
tools which are used for responding to incidents and tools for
knowledge management.
∙ Improvements: the last part of the interviews was dedicated
to discussing what can be improved and how and whether
there was a dependence hierarchy that slows down certain
processes, for example, whether certain documents/people
are needed for certain processes that are not always available.
After the interviews, the result was analyzed to identify the knowl-
edge area where improvement is needed. To address the incident
handling process, both tacit and explicit knowledge is important. The
following sub-subsections list and explain the result of the analysis of
the interviews.
54
5.3.1.1 The assessment of KM in incident handling process of

CSIRT-MU from the perspective of tacit Knowledge
Tacit knowledge is created when an incident handler is responding
to security incidents and during training. During the interviews, the
different means for sharing tacit knowledge between the incident han-
dling team members was identified. One means is weekly meetings,
where the team exchanges information and shares knowledge. An-
other way of sharing tacit knowledge is annual reports. One last way
of sharing personal knowledge is comments that are placed in the
electronic system (Request Tracker) during incident handling. These
comments can then be checked by other incident handlers and used
for handling similar incidents. This can be seen as a knowledge con-
versation of externalization3 when tacit knowledge is converted into
explicit knowledge.
The organization supports the culture of sharing knowledge be-
tween team members. An improvement of their KM perspective might
be to make the same pattern of incidents easily searchable in the
electronic system. This way, accessing knowledge and using existing
knowledge would be easier and more efficient. Even though different
categories are used for incidents, an option would be to label incidents
which exhibit similar behavior.
5.3.1.2 The assessment of KM in incident handling process of

CSIRT-MU from the perspective of explicit Knowledge
During the interviews, it was identified that there is no convenient way
to access to the documentation/explicit knowledge, as documents are
saved in several different electronic programs and there is no proper
categorization for these documents. To make explicit knowledge more
easily accessible and searchable, one solution would be to categorize
documents and to store them in a central place. This categorization
would then make it easier to find relevant documents.
The most demanding document is the incident handling manual
which provides guidelines for incident handlers how to solve differ-
ent types of cyber security incidents. Therefore, during the incident
3. the externalization is defined in the SECI model by Hirotaka Takeuchi, although

it is still arguable whether tacit knowledge can really be codified or not.
55
handling process, the incident handler needs to access the document

to get the necessary information. To improve the performance of the
incident handling process from the perspective of KM, the current
incident handling guidelines should be indexed and more accessible
in the sense that guidelines for certain types of incidents should be
easy to find.
To conclude, as a result of the KM assessment, the main knowledge
requirement is a KM tool/method which supports proper storage of
and access to knowledge activities in order to reuse knowledge, as cur-
rent solutions for storing and accessing the right documented knowl-
edge are inconvenient. Several KM tools/methods for supporting
other KM activities are in place and no knowledge gaps are identi-
fied. For the identification of knowledge activities, the lessons learned
KM method is used in practice, which is already implemented in the
incident handling process. For knowledge sharing, it was already ex-
plained in the previous sub-subsection that different methods are used
between the team members, which is highly efficient because each
team member knows what has been done by the other team members
during incident handling (by seeing the comments in the system and
by meeting weekly). As for creating knowledge, methods such as train-
ing, success stories (interesting incidents are shared between team
members) are used. The main focus for improving KM in incident
handling team of CSIRT-MU would be the KM requirement of storing
and accessing explicit knowledge.
The feedback workshop was addressed by creating reports of the
interviews including an analysis of the acquired information and
communicating these reports back to the team.
5.3.2 The Phase 2: Development of KM solution in incident

response team
This subsection is oriented on the requirements from the previous
subsections, evaluating alternative solutions and designing the proto-
type of the knowledge management system for the incident response
group of CSIRT-MU.
Based on the analysis of the KM assessment, the main KM require-
ment is a KM solution which supports the storage of knowledge activ-
ities and accessing explicit knowledge, in order to improve incident
56
handling performance and process. For the purpose of storing knowl-

edge, the literature identifies different KM tools such as databases,
document management systems and yellow pages [25]. For the in-
cident handling process, a document management tool was chosen
from the KM tools as a KM solution. Document management provides
a solution for processing, storing, changing, searching and deleting
documents [25].
The next step is to identify existing KM tools for the incident han-
dling process of CSIRT-MU, their analytical capabilities and whether
they support further development or adaptability to KM. If this is not
present yet, an alternative tool needs to be introduced.
5.3.2.1 Possible KM solutions

KM should support business processes and the KM solution should
be smoothly integrated into the business processes such that it re-
duces the extra work for users. The suggested KM solution should
be compatible with current tools and the current process of incident
handling, which addresses the influetial factor "nonconformities be-
tween current system and new system". Additionally, the influential
factors "weak usability of KM system" and "improper technical in-
frastructure" have to be taken into account when choosing a possible
solution. Therefore, the process of finding the KM solution was mostly
focused on current electronic systems which are used by the incident
handlers. Several systems are used for managing documentation in
CSIRT-MU, which can be seen as a solution. One of the tools which are
used for storing and managing the documents is Redmine wiki with
the knowledgebase plugin [30]. The current problem regarding the
the documents in Redmine wiki is that documentation is not easily
searchable and is not categorized, which makes it harder for incident
handlers to find the right documentation. One possible solution would
be to create a tagging system and a proper structure in the documents.
Another solution might be a tool called Request Tracker (RT) with
the plug-in RT for Incident Response (RTIR), which is already used by
the incident handling team of CSIRT-MU for responding to incidents at
the moment of writing this thesis. RT is a ticket tracking system, which
provides functionality for the organizations to keep track of what tasks
needs to be done, who is working on the tasks, what tasks already
57
Figure 5.2: RT articles
have been performed and other details regarding the tasks. RTIR is an
incident-handling tool which provides functionality for CSIRT/CERT
teams to track, respond to and deal with computer incidents [31]. RT
provides an articles module which is a knowledge based system and
supports knowledge management activities for storing and managing
explicit knowledge (shown in Figure 5.2). RT provides the possibility of
organizing articles into classes and topics, and supports customization
of articles by defining custom fields for all classes of articles. These
custom fields are user-defined properties and users can define the
name, the type and which parts of RT it applies to. RT articles are not
used by incident handling group, but in particular, the function of
articles could be used to integrate documents and manage explicit
knowledge.
It is clear that both options have the possibility that with further
development they could be valid KM solutions. This means that an
in-depth comparison should be made to determine which option is the
best for an appropriate KM system for the incident handling service.
The following section compares RT articles and Redmine knowledge
58
base based on their features for documentation management which

are necessary for a KM system in the incident handling service. The
following table 5.1 shows this comparison.
Table 5.1: A comparision between RT and Redmine
Features Redmine RT Articles

Dividing articles into cat- yes yes
egories
Uploading attachments yes yes
Searching by category yes yes
Searching by tag yes yes
Flexibility in configura- no yes
tion
From the table, it is clear that RT articles support more features

than Redmine, as they provide flexibility in configuration, which can
be really useful for custom requirements and for convenience of fu-
ture changes. Another advantage and probably the most important
advantage of RT articles is that it would provide access to the relevant
documents in the environment that is already used for incident han-
dling. Therefore, it will be more convenient to access and use explicit
knowledge when it is needed during incident handling. There needs
to be a way to integrate the information from Redmine into Request
Tracker. This advantage weighs in very heavily, so the decision was
made to use RT articles to develop a KM system and address the KM
requirements for the incident handling team of CSIRT-MU.
5.3.2.2 The prototype of the knowledge management system in

CSIRT-MU
During the assessment of KM phase, the decision was made to use
RT articles as a means to create the KM system prototype, which
would provide proper storing and accessing of knowledge activities
for documented knowledge/explicit knowledge, provide knowledge
externalization and support knowledge reuse. The result of this prac-
tical part is an enhanced prototype version of RT/RTIR, where the
incident response guidelines have been incorporated in RT articles,
59
the documented knowledge is integrated in RT and several features

are added to make knowledge easily accessible. The prototype is built
using Vagrant 4 and Ansible 5 and a custom scrip6 (see appendix C).
This virtual environment provides configuration and adds documen-
tation in the form of RT articles by reading text files. Additionally, the
phishing example that was introduced in section 2.5, which covered a
mapping of the incident handling phases to a phishing attack, has also
been added to the virtual environment and can be used to get a better
overview of additional functionality described below. For detailed
instructions, please consult the README in the electronic attachment
that comes with the prototype.
Dynamic incident handling manual in RT/RTIR To better address

KM requirement of "making the right knowledge available to the right
people at the right time", it was suggested to integrate the most impor-
tant document for incident handling, the incident handling manual,
into RT/RTIR. The first step was to analyze the specific sections of
the incident handling manual and actual incident handling processes
in RT/RTIR in order to find a way to link the different sections with
guidelines from the incident handling manual to the appropriate tick-
ets/incidents.
For actual incident handling, three queues are used: general, info
and automatic. The incidents in the general queue are solved manually
by the incident handler, the tickets in the info queue have a mostly
informational purpose and the incidents in the automatic queue are
detected by automatic tools. Additionally, incidents are divided into
categories and during the incident handling process, the right cate-
gory is set for tickets. Examples of the categories are the following:
phishing, spam, DoS, Application Compromise. The incident handling
manual provides guidelines on how to handle incidents with different
categories in different queues. As incidents in general and info queues
4. Vagrant is a tool to manage virtual machine environments and to configure and

use reproducible work environments
5. Ansible is IT automation engine for configuration management and application
deployment
6. Scrips are a feature within RT that provide functionality for the user to configure
RT for customized behavior.
60
are resolved manually, the main focus was on these queues to integrate
guidelines from the incident handling manual into RT.
The integration of the incident handling manual in RT/RTIR was
done in the following way: for each category of incident in general
queue, the relevant sections were chosen from the incident handling
manual and added as articles in the dedicated class ("incident handling
manual class") in RT/RTIR. When an incident handler determines
the category of the incident in RT/RTIR, the article corresponding to
the incident category shows up (shown in Figure 5.3). In this way, an
incident handler does not need to manually find the right section of
the right document anymore, which optimizes the process. For the
Info queue, articles with the name "Info" are accessible when an actual
ticket is created.
Incident handling
manual document RT articles Incidents
in RT/RTIR
General queue
:
Phishing Phishing
1. Phishing
2. Spam
3. DDoS Spam Phishing
4. DoS
5. Account compromised DDoS DDoS
6. ....
Figure 5.3: Integrated incident handling manual in RT/RTIR: On the

left side of the figure, the incident handling document is shown; In
the middle, it is depicted how guidelines for different incidents are
integrated in RT articles; and on the right side of the figure, it is shown
how rt articles will be connected to tickets.
Incident tagging system: Addionally, to make knowledge during

an incident handling process reusable, an incident tagging system was
suggested in the prototype of the KMS. The additional custom field
"tagging incidents" was added to all incidents in RT/RTIR in such
a way that during the handling of the security incident, an incident
61
handler can add custom or already used tags. The benefit of using
this specific functionality, is that RT checks its tag database while a
key word is being typed and autocorrects to a tag that already exists.
This will be helpful for an incident handler to search incidents with
similar patterns and check the comments which were made by incident
handler.
Structuring explicit knowledge in RT/RTIR To make the explicit

knowledge available to incident handlers, it was necessary to identify
and analyze the documentation and explicit knowledge resources
which are needed to solve the incidents. Then each of them would
be put in a predefined category. RT articles provide the functionality
of categorization in the following way: articles can be divided into
classes and into topics. For this case, a more flat structure was chosen
and therefore only classes were used for categorization. Additionally,
to make accessing and searching documents more convenient, a cus-
tom field with type "multiple tags" would be used. Note that this was
previously added for tickets/incidents, but it can be used for articles
similarly. In this way, when creating/adding new articles, this type
of system would support custom categorization. This approach has
several benefits, as it allows users to change or add categories in the
future, without requiring any technical changes. This custom catego-
rization system would be efficient when multiple documents from
different categories need to be loaded in a certain situation. For exam-
ple, if the team wants certain documents to be shown to newcomers,
they could add the tag "newcomer" to the documents in question. A
team member/incident handler can then search documentation with
this tag.
RT articles also allow specifying custom fields for each of the class
categories. In case of incident handling service, the field which would
be used for storing the explicit knowledge is "Refers to" which is used
to define the location of documents. For this purpose, it was also
possible to add documents by uploading files locally, but that would
make the file a snapshot of a certain moment, even though the latest
version might change in the original location. An example would be
legal documents from partner organizations such as CESNET, MU
and CSIRT.CZ. As the legal documents might be changed by another
62
organization, the link would make it easier to find the new document
and make sure that the latest version is used. Another benefits of
this approach is that right now the documents are saved in different
system, and in this way it could be able to create one central point for
accessing the explicit knowledge.
Templates in RT for sending replies The incident handling team

uses templates when an incident handler needs to send requests or
replies to administrators or users and these requests are structured
in a similar way. These templates are not stored in RT/RTIR, which
provides the possibility to include articles as templates and use them
for replying to a ticket. A template would then make this task a lot
easier and faster, which is exactly what the custom field would enable.
In case of the templates, for storing the content of the documentation,
the custom field wiki-text is used. This improves the process in such
a way that when a different template is added to the articles in the
class category templates, the incident handler can use this template
directly when replying to an incident.
5.3.3 The Phase 3: Evaluation of the suggesting solution

The suggested prototype of the KMS fully addresses the KM require-
ments which were identified for the incident handling service of CSIRT-
MU. To evaluate the suggested solution and identify improvements,
the prototype was presented to the incident handlers. By presenting
the KM solution to incident handlers the following influential fac-
tors for this phase were addressed: "not measuring and evaluating
KM project" and "unfamiliarity of incident handlers with KM tools".
During the meeting, the solution was presented and explained to the
incident handlers to make them familiar with the system and to iden-
tify the possible drawbacks which might emerge during the usage
of the system. The possible issues in the KM system were discussed.
Additionally, to evaluate the system, a questionnaire was used which
is provided in appendix B.
According to the feedback from the incident handlers, the inte-
grated incident handling manual in RTIR will speed up the process of
learning for incident handlers. One improvement that was suggested
was to use rich text for formatting the text of the integrated incident
63
handling manual, which was integrated in the prototype implementa-

tion by converting wikitext into Rich text. Another concern which was
identified during the presentation was the issue of maintainability
of the integrated incident handling manual in case it needs to be up-
dated or converted back to a text document. By itself RT/RTIR does
not provide functionality to extract the articles into a text document
and vice versa. It would still be possible to create such functionality
by creating own parser code, which could be done as follows. The
electronic attachment (see appendix C) that comes with this thesis
provides functionality to read text files from the file system and turn
them into RT/RTIR articles. The functionality needs to be extended
and refined for smooth usage, and additional decisions should be
made such as whether the original source file will be kept as the main
source of the incident handling document, which means that changes
will be made to that file and then parsed again into articles, or the
changes will be made in the articles in RT and the incident handling
document will be extracted from the RT articles.
The tagging system for incidents was found to be really useful
by incident handlers as they usually spend a lot of time searching
similar incidents and the tagging system facilitates this. It would make
searching incidents which are similar but not related easier and more
convenient.
For the templates, it was suggested to add the option to get some
date from the RT system dynamically into reply after inserting the
template. This is possible by using the ArticleTemplates plugin in RT/R-
TIR which turns articles into dynamic templates. This option was
integrated into the vagrant configuration file.
The Incident handlers found the integrated documents into RT/R-
TIR and the tagging system useful. Additional categories were identi-
fied for documents for better categorization.
To conclude, incident handlers found the suggested solution useful
for improving the KM in their business processes.
64
6 Conclusion
At the moment of the writing of this thesis, there is no documentation
on cases where KM has been applied to CSIRTs/CERTs, so this thesis
is the first attempt. This was achieved through separate literature re-
views on knowledge management and incident response and applying
the concepts from that literature to the case of the incident handling
team of CSIRT-MU. I developed a customized framework for a knowl-
edge management implementation for the incident handling team of
CSIRT-MU based on the literature review of state-of-the-art KMFs. I
chose elements from different frameworks for the custom KMF and
developed a customized implementation plan of the afore-mentioned
framework.
The aim of the thesis was to suggest a prototype of a Knowledge
Management System for the incident handling team of CSIRT-MU,
which would provide improvement of the knowledge management
of their business processes. The KM implementation for the incident
response team was done in three phases: Assessment of knowledge
management, development of a prototype and an evaluation of the
prototype. As a result of the first two phases, the Knowledge require-
ments were identified and solutions were found to address the KM
requirements. In the last phase, the prototype was evaluated by the
incident handlers to ensure that the requirements were met. Now the
suggested KMS can be deployed to the operational environment of
CSIRT-MU and then evaluated in practice.
While working on this thesis, I faced several challenges, but the
nature of incident response teams was the most challenging factor as
most of the information is confidential. In contrast, developing and
analyzing KM in an organization requires detailed and explicit infor-
mation about the organizational structure, processes, culture, tools
used in processes and more. During the implementation of KM in
CSIRT-MU, I did not have full access to such information, therefore the
data had to be acquired during the interviews and from studying the
incident handling manual in a restricted environment. Another chal-
lenge was to study the Request Tracker system and get familiar with
its capabilities and how it is used in practice by CSIRT-MU. The latter
was again confidential, so the only source of information about how
65
6. Conclusion
the incident handlers of CSIRT-MU use the system was the interviews.
Another challenge was studying the concept of KM and creating the
prototype framework which would be suitable for CSIRT-MU, as there
is no general consensus on how KM should be done.
6.1 Future work

As this thesis created a prototype, it showed how the main concepts
of knowledge management can be applied to the incident handling
team of CSIRT-MU, but several quality-of-life improvements could
be made which would emerge when it is deployed in practice. One
improvement would be a way to maintain the latest versions of the
integrated incident handling manual from one place. For this purpose,
functionality such as downloading the incident handling manual from
an external URL and including updates into RT/RTIR system auto-
matically would work. During the usage of the prototype in practice,
it might also be desired to update the categories of the documents. It
is necessary for the team to continue evaluating the knowledge man-
agement system in practice and to list new requirements and improve
the system accordingly.
Additionally, the whole concept of evaluating KM is a tricky area,
because there is not one way to measure how good or bad a knowl-
edge management solution is. To understand whether a knowledge
management solution has achieved the intentions of knowledge man-
agement improvement, further research should be conducted on ways
to measure the effectiveness of knowledge management solutions in
practice. It can still be evaluated by looking into factors such as whether
incident response process is more efficient after implementing KM
in process, whether redundant work has decreased and how team
members feels regarding KM solution. The result of the KM project is
important for future development of KM in the whole CSIRT/CERT
organization. If the KM project is a success, the methods introduced
should be used to implement KM in the whole organization and in
case of failure, the reasons should be studied and eliminated for the
future.
To conclude, it was established that the prototype will have a posi-
tive impact on the knowledge management within the team, provided
66
6. Conclusion
that the people involved are willing, convinced and trained to achieve
the best possible benefits from the suggested KM system.
67
Bibliography
1. Handbook for Computer Security Incident Response Teams. Carnegie Mel-
lon University, 2013.
2. MIROSLAW MAJ MSC, Roeland Reijers; MSC, Don Stikvoort. Good
Practice Guide for Incident Management. European Network and in-
formation Security Agency (ENISA), 2010.
3. RFC 2350 CERT-EU. 2011.
4. CSIRT-RU [online]. Radboud University [visited on 2018-10-06]. Avail-
able from: https : / / www . ru . nl / ict / algemeen / informatie -
beveiligen/informatiebeveiliging/cert-ru/rfc-2350.
5. DAVENPORT Thomas H, Prusak Laurence. Working Knowledge : How
Organizations Manage What They Know. Boston, Massachusetts: Har-
vard Business School Press, 1998.
6. TSOUKAS, H.; VLADIMIROU, E. What is Organizational Knowledge?
Journal of Management Studies. 2001.
7. TAKEUCHI, Hirotaka. The New Dynamism of the Knowledge-Creating
Company. In: TAKEUCHI, Hirotaka; SHIBATA, Tsutomu (eds.). In
Japan Moving Toward a More Advanced Knowledge Economy: Advanced
Knowledge—Creating Companies. Washington (D.C.): World Bank In-
stitute (WBI), 2006.
8. HORVATH, A. Working with Tacit Knowledge. In: JAMES W. COR-
TADA, John A. Woods (ed.). The Knowledge Management Yearbook
2000-2001. Butterworth-Heinemann, 2000.
9. Knowledge management tools [online]. Alan Frost, 2010 [visited on 2018-07-08].
Available from: https://www.knowledge-management-tools.net.
10. DIMATTIA, S.; ODER, N. Knowledge management: hope, hype, or harbinger?
Library Journal. 1997, vol. 122, no. 15.
11. AMR ARISHA, Mohamed Ragab. Knowledge Management and Measure-
ment: a Critical Review. Journal of Knowledge Management. 2013,
vol. 17.
68
BIBLIOGRAPHY
12. KOSTAS METAXIOTIS, Kostas Ergazakis; PSARRAS, John. Exploring

the world of knowledge management: agreements and disagreements in the
academic/practitioner community. Journal of Knowledge Management.
2005, vol. 9.
13. WONG, Kuan Yew; ASPINWALL, Elaine. Knowledge Management Im-
plementation Frameworks: A Review. Knowledge and Process Manage-
ment. 2004, vol. 11.
14. EASTERBY-SMITH, Mark; LYLES, Marjorie A. handbook of organiza-
tional learning and knowledge management. A John Wiley and Sons,
Ltd, Publication, 2011.
15. MÅRTENSSON, Maria. A critical review of knowledge management as a
management tool. Journal of Knowledge Management. 2000, vol. 4.
16. V. RIBIÈRE, F.A. Calabrese. Why are companies still struggling to
implement knowledge management? Answers from 34 experts in
the field. In: LIEBOWITZ, Jay (ed.). Successes and Failures of Knowledge
Management. Washington (D.C.): Morgan Kaufmann, 2016.
17. FROST, Alan. A Synthesis of Knowledge Management Failure Factors [on-
line] [visited on 2018-12-30]. Available from: http://www.knowledge-
management-tools.net/failure.html.
18. A systems thinking framework for knowledge management. decision support
systems. 2001, vol. 31.
19. HEISIG, Peter. Harmonisation of knowledge management – comparing 160
KM frameworks around the globe. Journal of Knowledge Management.
2009, vol. 13, no. 4.
20. SMARTVision: A knowledge-management methodology. Journal of Knowl-
edge Management. 2001, vol. 5.
21. AKHAVAN, Peyman; PEZESHKAN, Amir. Knowledge management
critical failure factors: a multicase study. The journal of information
and knowledge management systems. 2014, vol. 44, no. 1.
22. HOLSAPPLE, C.; JOSHI, K. Knowledge management: a threefold framework.
Kentucky Initiative for Knowledge Management. 1997, vol. 104.
23. HEISIG, Peter. The GPO-WM○ R Method for the Integration of Knowledge
Management into Business Processes. European Research Center for
Knowledge and Innovation. 2006.
69
BIBLIOGRAPHY
24. MERTINS, Kai; HEISIG, Peter; VORBECK, Jens. Knowledge Manage-

ment: Concepts and Best Practices. Chandos Publishing, 2003.
25. CEN. European Guide to good Practice in Knowledge Management. CWA
14924, Part 1 – 5. European Committee for Standardization. 2004.
26. CSIRT-MU [online]. Masaryk University [visited on 2018-07-28]. Avail-
able from: https://csirt.muni.cz.
27. RFC 2350 CERT-MU. 2018. Version 1.5.
28. Masaryk University Directive No. 9/2017: Administration of informa-
tion technology [online] [visited on 2017-09-12].
29. CESNET [online]. CESNET [visited on 2018-10-12]. Available from:
https://www.cesnet.cz.
30. knowledgebase plugin for Redmine [online]. Redmine [visited on 2019-05-14].
Available from: https ://www.redmine.org/plugins/redmine_
knowledgebase.
31. Request Tracker [online]. Best Practical Solutions [visited on 2019-05-14].
Available from: https://bestpractical.com/request-tracker.
70
A The questions for interviews
A.1 Topic 1: Current Incident Handling process:

1. Describe incident handling process and accordingly give an
example.
2. For each phases of incident handling process answer following

questions:
∙ Which information do you need and Where is it stored?

∙ Which information do you produce and Where is it stored?
3. Are there internal/custom guidelines on how to perform the

phases? Where can you find them?
A.2 Topic 2: Types of knowledge

1. List all documents that are used during incident handling?
2. What specific documents (legal document, manual guidelines,

advisories written by CSIRT members) you are using during
incident handling?
3. Where are all documents located and how can you find them?
Are these documents organized and easily accessible by all the
team members?
4. Is there a centralized place with all documentation? if not,

where are the different types of documents located? Do you
think these documents can be saved centralized?
5. How are the lessons learned shared between team members

after each incidents?
A.3 Topic 3: Tools used for Incident handling

1. What tools do you use for incident handling?
71
A. The questions for interviews
2. Are these tools easily accessible?
3. Do you use any tool for knowledge sharing between team

members?
4. Describe incident handling process in RT/RTIR.
A.4 Topic 4: General questions for improvements

1. In your opinion, what information should be more accessible?
2. Is there a dependence hierarchy that slows down certain pro-

cesses? for example, are certain documents/people needed for
certain processes that are not always available? Is it possible to
codify/document some information which these people have?
3. what would you improve in the incident handling?
72
B The questionnaire for the evaluation of sug-
gested solution
1. Will you use the integrated incident handling manual in RT?
What would you improve about it? What do you see as a draw-
back?
2. How useful is the tagging system for tickets and incidents in

terms of finding incidents with similar patterns?
3. Do the templates for ticket replies speed up the incident han-

dling process or are they irrelevant?
4. Are the suggested categories for documents appropriate for

the incident handling? Please cross out the categories which
you would remove and write down the categories which you
would add:
∙ Training materials
∙ Legal documents
∙ Scripts
∙ Lesson learned from incidents
∙ Manuals and Guidelines
5. Do you think that the proposed solutions regarding categories

and tagging improve the accessibility of documents?
6. In general what would you change about the suggested so-

lution? Does the suggested system feel intuitive and easy to
use?
73
C The content of the thesis archive
The thesis archive available at https://is.muni.cz/auth/th/pupg1/
includes the virtual environment for a prototype of a knowledge man-
agement system for incident response teams, built in Request Tracker.
The advantages of this system are centralization and automatic linking
of necessary documents and faster communication between different
parties. The files are organized in the following structure:
∙ ansible
* roles: The folder contains ansible roles.
- ansible-conf.yml: The configuration for ansible playbook.yaml.
- playbook.yml: The configuration of ansible.
- README.md: The file provides information regarding the ansi-
ble roles.
∙ Vagrantfile: Configuration of the vagrant virtual develop-

ment environment.
∙ vagrant-conf.yml: Contains Configuration details for vagrant

file.
∙ README.md: The file contains description, installation and usage

of the project.
An MIT license is used for the source code.
74

Knowledge Management For Incident Response Teams

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Knowledge Management For Incident Response Teams

Uploaded by

Copyright:

Available Formats

Masaryk University

Knowledge management for

Brno, Spring 2019

Advisor: RNDr. Jan Vykopal Ph.D.

2 CSIRT/CERT organizational context 3

4 Overview of various knowledge management frameworks 24

5 Implementation of Knowledge Management in CSIRT-MU 46

A The questions for interviews 71

B The questionnaire for the evaluation of suggested solution 73

C The content of the thesis archive 74

The result of this thesis is a prototype of a knowledge management

dits and assessments, vulnerability handling, etc, but every CSIRT/CERT

2.2 CSIRT/CERT Framework

Constituency of CERT-EU are EU institutions, agencies and bodies [3].

2.3 CSIRT/CERT Services

Table 2.1: A list of CSIRT Services [2]

Reactive Services Proactive Services Security Quality Man-

2.4 Incident Handling

As mentioned before, if a team does not offer incident handling ser-

2.4.1 Incident report phase

An incident handling process starts with an incident report. Incidents

2.4.2 Registration phase

2.4.3 Triage phase

2.4.4 Incident resolution phase

Figure 2.1: Incident Resolution cycle [2]

2.4.5 Incident closure

After resolving an incident, the incident closure phase starts, which

resolved and final recommendations. An essential step of this phase

In contrast to all previous phases, the Post-analysis phase does not

2.5 An example of an incident and the respective

To illustrate how the incident response phases would work in practice,

2.5.1 Overview of the incident

An example of an incident is a phishing email. Take the following

Figure 2.2: An example of a phishing email

2.5.2 Incident report and registration phase

2.5.3 Incident triage phase

2.5.4 Incident resolution phase

the damage, additional measures might be necessary to resolve the

2.5.5 Incident closure and Post-analysis phases

3.1 Definition of knowledge

Figure 3.1: Three-level hierarchy

Data is associated with facts about events, which with additional

In turn, information is contextualized, categorized, calculated, cor-

nothing mentioned regarding knowledge which is documented and

3.2 Types of knowledge

Most of the time two types of knowledge are distinguished: explicit

After establishing the issue, the operator applies explicit knowledge

3.3 The SECI model

∙ Socialization: Tacit knowledge is shared with others through

∙ Externalization: This conversion method describes converting

tacit knowledge. As an example, an intern might document

∙ Combination: Sources of different explicit knowledge are com-

∙ Internalization: This method refers to using theoretical knowl-

3.4 Definition of Knowledge Management

IT tools, such as email, groupware, the Internet, etc, it is possible to

3.5 Knowledge Management in organizations

3.6 Knowledge Management frameworks

vides guidance toward an appropriate knowledge management sys-

3.7 Knowledge Management processes

3.7.1 The process of knowledge creation

Knowledge Management Processes

The process The process

Figure 3.2: Knowledge Management Processes