ID 6788
Scheer, Michael: Development of an IT-Security Performance Measurement System
Hamburg: Diplomica GmbH, 2003
Zugl.: Darmstadt, Fachhochschule, BA-Thesis / Bachelor, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Executive Summary
Adequate security of information and the systems that process it is a fundamental manage-
ment responsibility. Management must understand the current status of their IT-Security
program in order to make informed decisions.
In this context, this Bachelor Thesis proposes a Performance Measurement System for IT-
Security, which is designed to be well-balanced and comprehensive. It views IT-Security
from four perspectives: Organisational, Financial, Operational and Personnel.
The documentation of the system contains the key figures and their interrelationships.
With its modular design, it can either be used out-off-the-box or tailored to the specific
requirements of the organisation.
III
Contents
Executive Summary
III
1 Introduction
1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Theoretical Background
3
2.1 Performance Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
Key Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.3
The Balanced Scorecard . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2 IT-Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1
Goals of IT-Security . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.2
Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.3
Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1
The Asset/Threat/Vulnerability/Safeguard Concept . . . . . . . . . 11
2.3.2
Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3
Risk Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Existing Standards for IT-Security . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1
Standards for Information Security Management . . . . . . . . . . . 14
2.4.2
Standards for Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.3
Standards for Development . . . . . . . . . . . . . . . . . . . . . . 15
2.4.4
Standards for a Common Terminology . . . . . . . . . . . . . . . . 16
V
VI
CONTENTS
3 Requirements
19
3.1 General Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1
Financial Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2
Regulatory Requirements . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3
Organisational Requirements . . . . . . . . . . . . . . . . . . . . . . 20
3.1.4
Requirements for Performance Measurement . . . . . . . . . . . . . 21
3.2 Requirements at a Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Development Approach
23
4.1 Top-Down vs. Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1
Top-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2
Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Development Approach chosen . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Findings
29
5.1 Top-Down Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1
Generic Security Model . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2
Self-Assessment Guide . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.3
Findings and Discussion . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Bottom-Up Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1
List of Key Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2
Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Meet in the Middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Discussion of Key Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.1
Key Figures Definition Table . . . . . . . . . . . . . . . . . . . . . . 41
5.4.2
Application of Quality Criteria . . . . . . . . . . . . . . . . . . . . 42
5.4.3
Documentation of Key Figures . . . . . . . . . . . . . . . . . . . . . 43
6 Basic Management Report
61
6.1 Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Proposed Key Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
CONTENTS
VII
A Incident Response Form
63
B Project Management
65
B.1 Project Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.2 Variance Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
C Retrospective and Future Directions
67
D Recommendations for IT-Based Performance Measurement
69
E Bibliography
71
F Glossary
75
VIII
CONTENTS
List of Figures
2.1 The four perspectives of the Balanced Scorecard . . . . . . . . . . . . . . .
6
2.2 Attack scenario against integrity [21] . . . . . . . . . . . . . . . . . . . . .
7
2.3 Attack scenario against availability [21] . . . . . . . . . . . . . . . . . . . .
8
2.4 Attack scenario against confidentiality[21] . . . . . . . . . . . . . . . . . .
8
2.5 Attack scenario against accountability[21] . . . . . . . . . . . . . . . . . . .
8
2.6 Composition of an IT-Security Policy . . . . . . . . . . . . . . . . . . . . .
9
2.7 The Asset/Threat/Vulnerability/Safeguard Concept . . . . . . . . . . . . . 11
2.8 3x3 Risk Level Matrix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.9 Computer Security Incident Taxonomy . . . . . . . . . . . . . . . . . . . . 17
4.1 Possible way to divide IT-Security into fields . . . . . . . . . . . . . . . . . 24
4.2 Key figures without any relation . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Key figures and their relations . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Key figures, their relations and central key figures identified
. . . . . . . . 25
4.5 The proposed development approach . . . . . . . . . . . . . . . . . . . . . . 27
5.1 A generic security model for computer networks and distributed systems . . 30
5.2 Topic Areas of the NIST Security Self-Assessment Guide . . . . . . . . . . 31
5.3 The four perspectives of the IT-Security Performance Measurement System
34
5.4 Identified relationships of the key figures . . . . . . . . . . . . . . . . . . . 38
A.1 Computer Security Incident Response Form . . . . . . . . . . . . . . . . . 64
B.1 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
IX
List of Tables
4.1 Comparison of Top-Down and Bottom-Up approach . . . . . . . . . . . . . 26
5.3 Key Figure Definition Table . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1 Proposed key figures for Basic Management Report . . . . . . . . . . . . . 62
XI
Chapter 1
Introduction
This chapter briefly discusses the reason for this Bachelor Thesis and introduces the
problem statement.
1.1
Motivation
Due to the increasing use of information technology in all sectors of industry, an unprece-
dented amount of digital information is currently being generated, processed, transmitted
and stored, raising the question of how to ensure an adequate level of security.
Several statistics prove the growing total number of security incidents, raising the security
awareness of IT-Management. Based on this, many projects have been carried out in order
to improve security.
With an increasing interest in IT-Security, questions arise like:
· What percentage of the IT-Budget should we spend on IT-Security?
· How good is our level of security in comparison to other companies (benchmarking)?
· Do our security investments amortise?
· ...
Up to the present, answers to these questions are somewhat vague and based only on
subjective perception. Security metrics
1
could close this gap, because they rest upon
objective ratios and enable a comparison over time.
1
In May 2001, a first scientific Workshop on Security Metrics [22] was held in Williamsburg Virginia.
The goals of the workshop were to characterize the information security measurement problem domain,
identify "good practices", focus needs, and determine potential research directions.
1
2
CHAPTER 1. INTRODUCTION
1.2
Problem Statement
The consideration of IT-Security relevant incidents demands a ratio system, in order to
detect tendencies at an early stage and to enable reasonable reporting and response.
Therefore, an analysis of the relevant IT-Security key figures has to be conducted, based
on a critical looking at a method of ascertainment.
A detailed discussion of the key figures (purpose, scope, possible aggregation, etc.) should
be performed. The thesis should be written in English, and it might be that the thesis or
parts of it must be classified confidential.
The overall goal of the bachelor thesis is a comprehensive documented performance mea-
surement system for IT-Security, that includes the method of ascertainment of the key
figures.
Chapter 2
Theoretical Background
This bachelor thesis is mainly founded on two different areas of theory, performance mea-
surement and IT-Security. The goal is, as I mentioned earlier, to apply performance
measurement mechanisms to IT-Security. Therefore, this chapter explores the basic con-
cepts behind both IT-Security and performance measurement. It starts with a section
about performance measurement and key figures, explaining what they are and where
they originally come from. The rest of the chapter introduces important concepts of
IT-Security.
3
4
CHAPTER 2. THEORETICAL BACKGROUND
2.1
Performance Measurement
2.1.1
Definitions
As a basis for further discussion, this section defines the central terms for performance
measurement.
Definition of performance measurement:
"Performance measurement is the ongoing monitoring and re-
porting of program accomplishments, particularly progress to-
wards preestablished goals. A "program" may be any activity,
project, function, or policy that has an identifiable purpose or
set of objectives."[5]
This definitions stresses the importance of the monitoring and reporting process. For
monitoring and reporting, key figures are being used.
Definition of key figure:
Key figures are high-compressed measures, which report about
quantitative ascertainable facts related either to the overall com-
pany or partitions of it.
In practice, a key figure is used seldom alone. Different key figures are composed together
in some sort of system, in order to reflect the complexity of reality.
Definition of performance measurement system:
A performance measurement system, sometimes also referred to
as a ratio system, is a compilation of key figures, which correlate
in an objective and reasonable way.
2.1.2
Key Figures
The intention of key figures is to illustrate intricate operational information in a straight-
forward and comprehensive way. They are applied:
· To perceive the strengths and weaknesses of the company.
· To analyse specific trends.
· To compare the company with other companies, or to compare individual depart-
ments within a company with one another (benchmarking).
Key figures were first used for balance sheet analysis in the United States in the 19th
century. They served as decision guidance for the allocation of short-term loans. The
2.1. PERFORMANCE MEASUREMENT
5
application of key figures for in-house financial analyses had been prefaced by the devel-
opment of the "Dupont-System of Financial Control" (1919).
In German-speaking countries, one differs between absolute figures and ratio figures
1
.
This differs from the Unites States, where absolute figures are out of scope. However,
absolute figures are useful for performance measurement and will be used later on in this
document.
1
Ratio figures emerge from setting at least two absolute figures in a ratio. Percentages, for example,
are ratio figures.
6
CHAPTER 2. THEORETICAL BACKGROUND
2.1.3
The Balanced Scorecard
The Balanced Scorecard is a performance measurement system developed by David Norton
and Robert Kaplan [10].
It is worth mentioning here, because the Balanced Scorecard is getting more and more
popular in practise. The reason for the new Balanced Scorecard approach was that ex-
isting performance measurement approaches had been too centric on financial accounting
measures. Therefore, the Balanced Scorecard concept extends the financial accounting
measures with three new perspectives, namely
· Customer
· Internal Business Processes
· Learning and Growth
Figure 2.1 illustrates this interrelation.
Vision
and
Strategy
Customer
Financial
Internal Business
Processes
Learning and
Growth
"To succed financially,
how should we
appear to our
stakeholders?"
"To achieve our
vision, how should
we appear to our
customers?"
"To satisfy our
shareholders and
customers, what
business processes
must we excel at?"
"To achieve our vision,
how will we sustain our
ability to change and
improve?"
Figure 2.1: The four perspectives of the Balanced Scorecard
2.2. IT-SECURITY
7
The objective of balanced reporting is to find a better way of reflecting reality. For
steering a company and making the right decisions, it is important to have comprehensive
information at hand.
2.2
IT-Security
Continuity of operations and correct functioning of information systems is important to
most businesses. Threats to computerised information and process are threats to business
quality and effectiveness.
The objective of IT-Security
2
is to put measures in place, which eliminate or reduce
significant threats to an acceptable level.
2.2.1
Goals of IT-Security
Since a precise and commonly accepted definition of IT-Security does not exist [6], we
often find attemps towards definitions in literature based on introducing the so-called 5
Security Goals [16]:
1. Integrity: The security goal that generates the requirement for protection against
either intentional or accidental attemps to violate data integrity (the property that
data has when it has not been altered in an unauthorized manner) or system in-
tegrity (the quality that a system has when it performs its intended function in an
unimpaired manner, free from unauthorized manipulation).
Transmitter
Receiver
Attacker
Figure 2.2: Attack scenario against integrity [21]
Figure 2.2 shows an intentional attempt to violate data in transit. The transmitter
wants to send data (e.g. an email) to the receiver, but the attacker intercepts the
data and alters it for some reason.
2. Availability: The security goal that generates the requirement for protection against
intentional or accidental attempts to perform unauthorized deletion of data or oth-
erwise cause a denial of service or data.
2
IT-Security is sometimes referred to as computer security, e.g.[6]. However, the meaning is the same.
8
CHAPTER 2. THEORETICAL BACKGROUND
Transmitter
Receiver
Attacker
Figure 2.3: Attack scenario against availability [21]
Figure 2.3 depicts an intentional attempt to cause a denial of service or data. For
instance, the attacker overwhelms the receiver with so many requests, that he is no
longer able to process and respond to the requests of the transmitter.
3. Confidentiality: The security goal that generates the requirement for protection from
intentional or accidentional attempts to perform unauthorized data reads. Confi-
dentiality covers data in storage, during processing, and in transit.
Transmitter
Receiver
Attacker
Figure 2.4: Attack scenario against confidentiality[21]
Figure 2.4 shows an intentional attempt of unauthorized data read. For example,
the attacker intercepts an email during transmission.
4. Accountability: The security goal that generates the requirement for actions of an
entity to be traced uniquely to that entity. This supports non-repudiation, intrusion
detection and legal action.
Transmitter
Receiver
Attacker
Figure 2.5: Attack scenario against accountability[21]
Figure 2.5 depicts a possible attack scenario against accountability. The attacker
sends an email to the receiver, but pretends to be the transmitter. Doing so, he
might place an order at the expense of the transmitter.
2.2. IT-SECURITY
9
5. Assurance: Grounds for confidence that the other four security goals have been ade-
quately met by a specific implementation. "Adequately met" includes functionality
that performs correctly, sufficient protection against unintentional errors (by users
or software), and sufficient resistance to intentional penetration or bypass.
2.2.2
Security Policy
A security policy is a preventative mechanism for protecting important company data and
processes. It is a document, which communicates a coherent security standard to users,
management and technical staff.
Philosophy
General Guidelines
Safety Concepts, Concrete Measures
Business Management
IT-Management
IT-Security Officer
static, not technology
oriented
dynamic, technology
oriented
Figure 2.6: Composition of an IT-Security Policy
Figure 2.6 depicts the structure of an IT-Security Policy. People at different hierarchy
levels contribute to the policy document. The philosophy of the Business Management
is a relatively static part of the policy document, whereas the concrete measures at the
bottom are dynamic. For this reason, this part must be updated regularly.
An IT-Security Policy is a prerequisite to quality control (ISO 900x) as well as mandatory
legal requirements exist like protection of customer and employee data, which must be
implemented by a security policy.
10
CHAPTER 2. THEORETICAL BACKGROUND
2.2.3
Incident Response
Before defining incident response, it is necessary to define the term computer security
incident first. Eugene Schultz [15] gives the following definition of the term computer
security incident:
"By (computer security) incidents, we mean adverse events that
threaten security in computing systems and networks. Events
include any observable thing that happens in a computer and/or
network. Adverse events include system crashes, packet flooding
within a network, web-site defacement, and execution of mali-
cous code that destroys data."
Incident response means actions taken to deal with incidents that occur. These actions
normally represent some form of intervention to negate or minimize the impact of the
incident.
Ende der Leseprobe aus 83 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2003, Development of an IT-Security Performance Measurement System, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/222142
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare