IT Risk Register

Vysok
a skola ekonomick
a v Praze
Fakulta informatiky a statistiky
MASTERS THESIS
IT Risk Register
Author: Karel Kohout

Supervisor: Ing. Lud
ek Nov
ak, PhD
Academic Year: 2012/2013
Declaration of Authorship
The author hereby declares that he compiled this thesis independently and that
all sources have been included in the list of literature and cited according to the
CSN
ISO 690 norm.
Prague, December 9, 2012
Signature

Cestn
e prohl
asen
Prohlasuji, ze jsem tuto diplomovou praci vypracoval samostatne. Veskere pouzite
podklady, ze kter
ych jsem cerpal informace, jsou uvedeny v seznamu pouzite literatury
a citovany v textu podle normy CSN

ISO 690.
Dale prohlasuji, ze jsem pri zpracovan diplomove prace nevyuzil d
uvern
ych informac,
se kter
ymi jsem prisel do styku v zamestnan ani ze jsem v praci vedome nevyuzil
know-how zamestnavatele.
V Praze, 9. prosince 2012
Podpis
Acknowledgments
The author is especially grateful to his advisor, Ludek Novak, for invaluable comments
and assistance with the thesis.
Abstract
The theoretical part of the thesis analyzes several selected methodologies and bestpractices related to information technology risks management, with focus on documents and guidance developed by ISACA. It builds a set of ideas and basic requirements for effective model of an IT risk register. Strong emphasis is placed on
mapping CobiT 4.1 based Risk IT to COBIT 5.
The practical part describes implementation of an exploratory web-based IT
risk register in Python programming language utilizing the Django framework and
employs concepts from the analysis.
Keywords
computer security, risk analysis, IT risk register,

COBIT, Risk IT, Python, Django
Authors e-mail
karel@kohout.se
Abstrakt
Teoreticka cast diplomove prace analyzuje nekolik vybran
ych metodologi z oblasti
rzen rizik IT se zamerenm na dokumenty vytvorene profesn organizac ISACA.
V
ystupem jsou doporucen a zakladn pozadavky na efektivne fungujc model registru
rizik IT. Text klade velk
y d
uraz na propojen COBIT 5 s Risk IT, kter
y vychaz z
CobiT 4.1.
Prakticka cast popisuje implementaci modeloveho registru rizik IT v programovacm jazyce Python s frameworkem Django za vyuzit koncept
u predstaven
ych v
teoreticke casti.
Kl
cov
a slova
informacn bezpecnost, anal

yza rizik, registr
rizik IT, COBIT, Risk IT, Python, Django
E-mail autora karel@kohout.se
Contents
List of Tables
List of Figures
xi
Acronyms
xiii
1 Introduction
2 Risk management
2.1 Methodologies and frameworks . . . . . . . . . . . . . . . . . . . . . .
2.1.1 BITS Technology Risk Transfer Gap Analysis Tool (BITS GAP)
2.1.2 Risk IT Framework (Risk IT) . . . . . . . . . . . . . . . . . .
2.1.3 COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Risk and project management . . . . . . . . . . . . . . . . . . . . . .
2.2.1 PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 PRINCE 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Risk and risk management overview . . . . . . . . . . . . . . . . . . .
2.3.1 Risk management in CobiT 4.1 and COBIT 5 . . . . . . . . .
2.4 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
5
5
8
9
11
12
17
18
3 IT Risk register
3.1 Risk . . . . . . . . . . . . . . . .
3.1.1 Business risk . . . . . . .
3.1.2 Tolerance and appetite . .
3.1.3 Risk treatment . . . . . .
3.1.4 IT risk communication . .
3.1.5 Expressing risk . . . . . .
3.1.6 Expressing risk frequency
3.1.7 Expressing risk impact . .
3.1.8 Risk maps . . . . . . . . .
3.1.9 Risk scenarios . . . . . . .
19
20
20
22
23
25
27
29
30
34
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
3.2
3.3
3.4
viii
Various notes . . . . . . . . . . . . . . . . . . . . .
3.2.1 Liability . . . . . . . . . . . . . . . . . . . .
3.2.2 Effects of risk management and virtual risk .
Limitations and omissions of the thesis . . . . . . .
Chapter summary . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
38
39
4 Additional risk register security requirements
40
5 Risk register requirements summary
45
6 Risk register platform

46
6.1 Software choice and requirements server side . . . . . . . . . . . . . 46
6.2 Software requirements client side . . . . . . . . . . . . . . . . . . . 47
6.3 Possible software issues . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Risk register implementation
7.1 Risk register components . . . . . . . . . . . . . . .
7.1.1 Userinterface and tests . . . . . . . . . . . .
7.2 Risk register models . . . . . . . . . . . . . . . . .
7.2.1 Assets . . . . . . . . . . . . . . . . . . . . .
7.2.2 Impacts . . . . . . . . . . . . . . . . . . . .
7.2.3 Risk treatment . . . . . . . . . . . . . . . .
7.2.4 Risk, risk assessment and risk scenario . . .
7.3 Notes on implementation . . . . . . . . . . . . . . .
7.3.1 Django customization and configuration files
7.3.2 User rights checks . . . . . . . . . . . . . . .
7.3.3 Audit trail (logs) . . . . . . . . . . . . . . .
7.3.4 Point of time view . . . . . . . . . . . . . .
7.3.5 Test data in the register . . . . . . . . . . .
7.4 Analytical views and data access . . . . . . . . . .
7.4.1 Risk maps . . . . . . . . . . . . . . . . . . .
7.4.2 Violations and top risks . . . . . . . . . . .
7.4.3 Expected issues . . . . . . . . . . . . . . . .
7.5 Chapter summary . . . . . . . . . . . . . . . . . . .
8 Customizing, deploying and using the register
8.1 Hardware and software requirements . . . . . .
8.2 Information security . . . . . . . . . . . . . . .
8.2.1 Responsibility . . . . . . . . . . . . . . .
8.3 COBIT 5 customization . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
50
50
51
52
52
53
55
56
58
58
59
60
62
63
63
63
64
64
64
.
.
.
.
66
66
67
69
69
Contents
8.4
8.5
ix
8.3.1 Goal cascade . . . . . . . .

8.3.2 User rights and access . . .
8.3.3 Impact and frequency scales
8.3.4 Risk scenarios . . . . . . . .
User manual quickstart . . . . . .
8.4.1 Less visible features . . . . .
Possible uses of the risk register . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
70
70
71
71
71
72
9 Conclusion
73
Bibliography
76
A COBIT 5 risk mappings

B COBIT and Risk IT materials
B.1 COBIT 5 Process capability attributes .
B.2 COBIT 5 processes . . . . . . . . . . . .
B.3 COBIT 5 enablers . . . . . . . . . . . . .
B.4 CobiT 4.1 information criteria . . . . . .
B.5 CobiT 4.1 IT resources . . . . . . . . . .
B.6 CobiT 4.1 to COBIT 5 process mapping
B.7 COBIT 5 APO12 Manage Risk figures .
B.8 Risk IT Risk analysis . . . . . . . . . . .
C Other figures
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V
V
V
VII
VII
VIII
IX
X
XII
XIII
D Relevant configuration excerpts

XIV
D.1 Apache2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV
D.2 Risk register defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
E Diagrams
F Content of Enclosed DVD
XIX
XXIV
List of Tables
2.1
2.2
2.3
Alignment of ISMS and InfoSec Risk Management Process . . . . . . 14

ISO/IEC 27005:2011 risk assessment process . . . . . . . . . . . . . . 15
COBIT 5 APO12 activities . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1
3.2
3.3
3.4
3.5
COBIT (BSC) Risk Description in Business Terms (examples)

Example frequency scales . . . . . . . . . . . . . . . . . . . . .
Generic impact scales of an event . . . . . . . . . . . . . . . .
Impact scales example . . . . . . . . . . . . . . . . . . . . . .
Root mean square rationalization . . . . . . . . . . . . . . . .
4.1
4.2
ISO/IEC 27002 10.9.2 On-Line Transactions control . . . . . . . . . . 42

Suggested user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1
Requirements summary . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1
7.2
Frequency scales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Types of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.1
8.2
General security requirements . . . . . . . . . . . . . . . . . . . . . . 68

IT Risk register installation . . . . . . . . . . . . . . . . . . . . . . . 69
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
29
31
31
32
A.1 Enterprise goals and business impact . . . . . . . . . . . . . . . . . . II

A.2 COBIT 5 enterprise goals to CobiT 4.1 business goals mapping . . . . III
A.3 COBIT 5 business impacts C. 4.1 information criteria mapping . . . . IV
B.1 Mapping CobiT 4.1 processes to COBIT 5 . . . . . . . . . . . . . . . IX
D.1 Default impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
D.2 Default user groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
D.3 Default users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIII
List of Figures
2.1
2.2
2.3
2.4
2.5
2.6
2.7
GLBA Subtitle A Disclosure of Nonpublic Personal Information .

Relationship between Risk IT, ValIT and CobiT 4.1 . . . . . . . . .
COBIT 5 product family . . . . . . . . . . . . . . . . . . . . . . . .
COBIT 5 goal cascade . . . . . . . . . . . . . . . . . . . . . . . . .
COBIT 5 enterprise enablers . . . . . . . . . . . . . . . . . . . . . .
PMBOK project management process groups . . . . . . . . . . . . .
PMBOK risk-related processes (inputs and outputs) in Planning
Process Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8 PMBOK risk-related processes (inputs and outputs) in Monitoring &
Controlling Process Group . . . . . . . . . . . . . . . . . . . . . . .
2.9 Information security risk management process . . . . . . . . . . . .
2.10 Increasing IT risk exposure . . . . . . . . . . . . . . . . . . . . . . .
2.11 APO12 RACI chart . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
11
13
16
17
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
21
22
23
23
24
26
27
28
32
33
34
35
36
36
IT risk register RACI chart . . . . . . . . . . . . . . . . . . .

IT risk categories . . . . . . . . . . . . . . . . . . . . . . . . .
Risk IT risk hierarchy . . . . . . . . . . . . . . . . . . . . . .
Tolerance and appetite . . . . . . . . . . . . . . . . . . . . . .
Risk culture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Risk treatment options . . . . . . . . . . . . . . . . . . . . . .
Balancing the risk . . . . . . . . . . . . . . . . . . . . . . . . .
Risk information properties . . . . . . . . . . . . . . . . . . .
Risk expression methods limitations . . . . . . . . . . . . . . .
Extended Balanced Score Card criteria expressing risk impact
Root mean square . . . . . . . . . . . . . . . . . . . . . . . . .
Annualized Loss Expectancy (ALE) . . . . . . . . . . . . . . .
Risk map with risk appetite bands . . . . . . . . . . . . . . .
Modified risk map . . . . . . . . . . . . . . . . . . . . . . . . .
IT Risk scenario development . . . . . . . . . . . . . . . . . .
IT Risk scenario components . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
6
7
8
9
. 10
List of Figures
xii
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
Risk register ER (entity-relationship) diagram . . . .

Asset types . . . . . . . . . . . . . . . . . . . . . . .
Impact categories . . . . . . . . . . . . . . . . . . . .
Default risk scenario values . . . . . . . . . . . . . .
Configuration files layout . . . . . . . . . . . . . . . .
Permission check in views PermissionRequiredMixin
Permission check in views urls.py . . . . . . . . . .
Immutable logs . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
52
54
57
59
59
60
62
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
COBIT 5 Process reference model . . . . . . . . . . .

APO12.01 Collect data . . . . . . . . . . . . . . . . .
APO12.02 Analyse risk . . . . . . . . . . . . . . . . .
APO12.03 Maintain a risk profile . . . . . . . . . . .
APO12.04 Articulate risk . . . . . . . . . . . . . . . .
APO12.05 Define a risk management action portfolio
APO12.06 Respond to risk . . . . . . . . . . . . . . .
Risk Analysis Flowchart . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
VI
X
X
X
XI
XI
XI
XII
C.1 PRINCE 2 processes and components . . . . . . . . . . . . . . . . . . XIII

C.2 Weakest link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII
D.1
D.2
D.3
D.4
D.5
Relevant Apache 2 SSL configuration

General virtual host configuration . .
WSGI setup . . . . . . . . . . . . . .
Django file access . . . . . . . . . . .
Logging . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XIV
XIV
XV
XV
XVI
E.1
E.2
E.3
E.4
COBIT 5 APO12 data flow diagram . . . .

Risk register full class diagram . . . . . . . .
Risk register asset application class diagram
Risk register risk application class diagram .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XX
XXI
XXII
XXIII
Acronyms and definitions

activity
The main actions taken to operate the CobiT 4.1 process [6, pg. 189].
ALE
Annualized Loss Expectancy, see Figure 3.12.
API
Application Programmable Interface.
BSC
Balanced Score Card.
CSRF
Cross-Site Request Forgery.
DDoS
Distributed Denial of Service.
Domain
In CobiT 4.1, the grouping of control objectives into logical stages in the
IT life cycle of investments involving IT (Plan and Organise, Acquire and
Implement, Deliver and Support, and Monitor and Evaluate [6, pg. 189]).
HIPAA
Health Insurance Portability and Accountability Act (US legislation).
IDS
Intrusion Detection System.
ISACA
Professional organization; see www.isaca.org.
IT
Information Technology.
ITIL
The UK Office of Government Commerce (OGC) IT Infrastructure Library;

a set of guides on the management and provision of operational IT services
[6, pg. 189].
KGI
Key goal indicator; measures that tell management, after the fact, whether
an IT process has achieved its business requirements, usually expressed in
terms of information criteria [6, pg. 191].
KPI
Key performance indicator; measures that determine how well the process is
performing in enabling the goal to be reached. They are lead indicators of
whether a goal will likely be reached, and are good indicators of capabilities,
practices and skills. They measure the activity goals, which are the actions
Acronyms
xiv
the process owner must take to achieve effective process performance [6, pg.
191].
MoR
Also M o R. Management of Risk, framework; created by the Office of

Government Commerce (United Kingdom).
Metrics
Specific descriptions of how a quantitative and periodic assessment of

performance is to be measured. A complete metric defines the unit used,
frequency, ideal target value, the procedure to carry out the measurement
and the procedure for the interpretation of the assessment [6, pg. 191].
NIST
National Institute of Standards and Technology, Department of Commerce.
OGC
Office of Government Commerce (United Kingdom).

Project Management Body of Knowledge (project management
methodology).
PMBOK
PMI
Project Management Institute.
RACI
Responsible, Accountable, Consulted, Informed (see CobiT 4.1 or COBIT 5).
RBS
Risk breakdown structure; see [1].
RFC
Request For Comments (document, Internet standards-related

specification; source: RFC 2026, http://www.ietf.org/rfc/rfc2026.txt,
last retrieved November 11, 2012).
risk
Effect of uncertainty on objectives (a deviation from the expected positive

and/or negative) [15, pg. 1].
SOX
Sarbanes-Oxley act (US legislation).

Person or organization that can affect, be affected by, or perceive
themselves to be affected by a decision or activity [15, pg. 4].
stakeholder
US
United States (United States of America).
WBS
Work breakdown structure; see [1].
Chapter 1
Introduction
Risk register (sometimes referred to as risk log) is a key part of documenting any risk
analysis effort and one of the most important supporting tools of risk management,
enabling storage and communication of information in a relevant, consistent and
concise manner. The author aims to define and create an information technology risk
register model based on COBIT 5 framework and BITS Technology Risk Transfer
Gap Analysis Tool that would allow tracking and assigning information security risks
to higher COBIT business goals.
The thesis is structured as follows: Chapter 1 contains a general introduction,
information about source code formatting and several caveats. Chapters 2 and 3
discuss how various methodologies and best practices (COBIT, Risk IT and others)
interact in the definition of the register and set its requirements. In Chapter 4,
additional requirements for the register are developed based on ISO/IEC 27002.
Chapter 5 is a summary of risk register model requirements. Chapter 6 contains
notes and reasoning for the employed technologies (Python, Django web framework)
and possible programming issues, while Chapter 7 presents a high level technical
design of the register, detailed description of the implementation and source data.
Chapter 8 is a customization, deployment and user manual guidance. Items that
would severely break the flow of the text can be found in appendices (for example,
business goals mapping tables in Appendix B); source codes and examples are
enclosed on a DVD. The author has opted to include a generous amount of materials
from COBIT 5 as a reference due to the newness of the framework.
Risk register requirements are set throughout the text; crucial features are
highlighted by a small rectangle on the side of the respective paragraph. All code
excerpts are in Python 2.7 using Django 1.4. Unless specified otherwise, COBIT
means COBIT 5 framework and CobiT 4.1 the prior version of COBIT. During
the writing of the thesis, COBIT 5 has been published and the author has fully
aligned the thesis with the framework, although most of text might be used with
1. Introduction
CobiT 4.1 too. However, the COBIT 5 for Risk publication from the COBIT 5
product family was not yet released. Therefore, Risk IT methodology (which will be
consolidated with Val IT in COBIT 5) served as an important source, despite being
based on CobiT 4.1.1 The model of the risk register is sufficiently generic to allow
modifications to support further COBIT 5 family publications. Where reasonable,
the author has used examples from both COBIT 5 and CobiT 4.1.
Pro Django[4] was an invaluable reference for certain advanced concepts, as well
as Django Project documentation [10].
For a quick comparison of differences between COBIT versions, see http://www.isaca.org/

COBIT/Documents/COBIT5-Compare-With-4.1.ppt (last retrieved April 4, 2012) for further information.
Chapter 2
Risk management
The chapter first presents a general overview of the risk management process, then
it describes methodologies and sources used to create risk register requirements.
2.1
Methodologies and frameworks
The thesis is based on two frameworks COBIT 5 [7] and Risk IT [20] and one
guideline BITS Technology Risk Transfer Gap Analysis Tool (BITS GAP) [5]. The
choice of COBIT as an underlying framework was part of the thesis assignment;
one might use other frameworks to establish risk register as well, for example the
SP 800-30 Risk Management Guide for Information Technology Systems by NIST
or ISO/IEC 27005:2011 Information technology Security techniques Information
security risk management (ISO/IEC 27005:2011). However, COBIT is particularly
suitable for tracking business goals and Risk IT naturally complements it (to the
point of being absorbed into COBIT 5). ISO/IEC 27005:2011 serves as general
risk management model, compatible with most more detailed methodologies. BITS
GAP on the other hand provides several insights into the calculations of risk within
the register that are not covered by either Risk IT or COBIT itself, especially with
regard to risk transfers.
The following part contains background information for the frameworks, as the
author believes that it is important to know why each methodology emphasizes
different aspects of risk management and how they complement each other.
2. Risk management
2.1.1
BITS Technology Risk Transfer Gap Analysis Tool (BITS

GAP)
The document was created by BITS1 in the Role of Insurance in E-Commerce Risk
Management Working Group both as a reaction to the Enron corporation accounting
fraud (or rather expected new legislation when the scandal was still being uncovered)
and the increased concerns over customer data safety and security.
It is focused on the Unites States banking industry and the Gramm-Leach-Bliley
Act (GLBA) of 1999, which among other things2 , mandates formal information
technology risk assessment process in Subtitle A Disclosure of Nonpublic Personal
Information (see Figure 2.1).
Figure 2.1: GLBA Subtitle A Disclosure of Nonpublic Personal Information
(b) Financial Institutions Safeguards. In furtherance of the policy in subsection (a),
each agency or authority described in section 505(a) shall establish appropriate standards for the financial institutions subject to their jurisdiction
relating to administrative, technical, and physical safeguards
1. to insure the security and confidentiality of customer records and
information;
2. to protect against any anticipated threats or hazards to the security or
integrity of such records; and
3. to protect against unauthorized access to or use of such records or
information which could result in substantial harm or inconvenience to
any customer.
Source: Gramm-Leach-Bliley Act, 106th Congress Public Law 102, TITLE VPRIVACY, Subtitle
A, Section 501. Emphasis author.
The banking industry pedigree of BITS GAP explains its strong focus on
insurance, legal compliance and calculation of risk in monetary terms, and on
comparisons of existing insurance policies with emerging threats. The compliance
focus is especially apparent from reasons given to perform IT risk assessment it is
recommended in the document on the grounds of corporate governance responsibility
with the example of Y2K turnover and undermining of corporate value of several
companies, and possible litigation for claims under business interruption insurance if
the company suffers a loss from disrupted information systems.
1
BITS does not stand for an acronym.

The act (http://www.gpo.gov/fdsys/pkg/PLAW-106publ102/html/PLAW-106publ102.htm,
last retrieved September 10, 2012) mainly repeals the Glass-Steagall Act of 1933 and lifts the
restriction for commercial banks to also act as an investment bank or insurance company (and vice
versa).
2
2. Risk management
2.1.2
Risk IT Framework (Risk IT)
Risk IT is a framework produced by the ISACA organization to improve enterprise

management of risks related to information technology and IT activities. It complements COBIT (or rather CobiT 4.1) in a way that it sets good practices to identify,
govern and manage IT risk[20, pg. 7]. It is a key framework used throughout this
thesis as Risk IT contains a concise definition of concepts within the register.
Figure 2.2: Relationship between Risk IT, ValIT and CobiT 4.1
Source: [20, pg. 7, Figure 1]. Note: ValIT is not used in the thesis as an important source of
information.
2.1.3
COBIT 5
COBIT 5 (A Business Framework for the Governance and Management of Enterprise IT), released in 2012, and its older sibling CobiT 4.1 (Control Objectives
for Information and related Technology from 2007) represent ISACAs guidance
on the enterprise governance and management of IT[7, pg. 15] based on real-life
experience within the industry. The frameworks philosophy is based on providing
value to stakeholders by allowing them to manage IT and related technologies in
a way that brings expected benefits at an expected (acceptable) level of risk and
expected costs (paraphrased from [7, pg. 15]).
2. Risk management
6
Figure 2.3: COBIT 5 product family
Source: [7, pg. 11, Figure 1].
Because some products within the framework are still to be released in the future
(as of July 2012), certain parts of the thesis refer to CobiT 4.1 instead of COBIT 5;
however, where possible, COBIT 5 is used. The risk register in the thesis will be
designed to support COBIT as much as possible, therefore the author would like to
iterate over several (no doubt well known) concepts of COBIT for later reference.
COBIT is a high-level framework, more focused on providing control over IT
and less on the actual enactment (which would be the domain of ITIL). It supports
enterprise governance by providing assurance about the value of IT[6, pg. 5] and is
based on opinions of experts, not a legislation which is apparent from the focus on
value of IT and business goals, rather than compliance (in contrast to BITS GAP).
COBIT is process oriented; its 37 processes are split into two process domains:
Governance with five evaluate, direct and monitor (EDM) processes3 and Management with processes in four domains: Align, Plan and Organise (APO), Build,
Acquire and Implement (BAI), Deliver, Service and Support (DSS) and Monitor,
Evaluate and Assess (MEA)4 . The register must map assets and risk scenarios
(defined later) to individual processes.
Notation: processes are marked as a regular expression [A-Z][A-Z][A-Z][1-9] (i.e.
APO12 Manage Risk ). For the full reference model, see Figure B.1.
Tracking process maturity levels (CobiT 4.1) in the register, would in the authors
opinion, make the register rather complicated, especially in terms of risk assessment
quantifying what happens to the enterprise if a process degrades one maturity level is
not easily possible. The only possible thing to track is if something affects a process,
not how on a detailed level.
On the other hand, the new Process Capability Model introduced in COBIT 5
3
4
In line with governance in ISO/IEC 38500:2008.

Processes in COBIT 5 are an evolution of CobiT 4.1 processes.
2. Risk management
allows to assess, at a certain level, how a security incident might affect processes,
as it focuses on how the selected process achieves5 its purpose. See section B.1 for
definitions of the levels.
Another important concept are the relationships between processes and enterprise
goals that allow the organization to select a few high-level goals and from these goals,
to derive key IT and process goals. The concept is represented as the goal cascade.
Figure 2.4: COBIT 5 goal cascade
Source: [7, pg. 18, Figure 4]. Modified by the author.
The risk register should support linking (tracking back and forth) between
Enterprise, IT-related and Enabler (process) goals. Also, as [7, pg. 20] notes, the two
level discrete indicators (P: primary, S: secondary) would in reality be continuous
(e.g. values in the set < 1; 10 >).
COBIT 5 explicitly defines 7 enablers they individually and collectively,
influence whether something will workin this case, governance and management
over enterprise IT[7, pg. 27]. Enablers depend on the goal cascade. A similar
concept was present in CobiT 4.1 as IT resources (see section B.5).
5
[The new model] ... improved focus on the process being performed, to confirm that it is
actually achieving its purpose and delivering its required outcomes as expected.[7, pg. 45]
2. Risk management
8
Figure 2.5: COBIT 5 enterprise enablers
Source: [7, pg. 27, Figure 12]. See section B.3 for definitions.
The older information criteria in Cobit 4.1 have been replaced (to some extent)
by the COBIT 5 Information Model and its information enablers (see Figure 2.5 and
[7, Appendix F]). However, the guideline COBIT 5: Enabling Information is still in
the process of being published.
The risk register in the thesis is agnostic to either information enablers or
information criteria both can be easily implemented and linked to assets. If the need
ever arises, the author proposes that using older CobiT 4.1 information criteria, tied
to COBIT 5 enterprise goals (see Table A.3) might be an option. Information criteria
are defined as business requirements for information[6, pg. 10] and extended
beyond the traditional CIA triad6 to: effectiveness, effectiveness, confidentiality,
integrity, availability, compliance and reliability (see section B.4 for full definitions);
these criteria are then mapped to process and activity failures. The criteria then
might be further mapped down to individual assets. However, this option will not
be implemented in the register.
2.2
Risk and project management
Even though the thesis is mainly based on COBIT (which focuses on the organization
as whole, through a longer time period7 ), the author would like to introduce several
concepts from project management methodologies too in the hope that the resulting
risk register might partially support certain project management issues.
6
Confidentiality, integrity, availability.

Notwithstanding the fact that COBIT 5 now contains BAI01 Manage Programmes and Projects
process and a management practice BAI01.10 Manage programme and project risk.
7
2. Risk management
A project is a temporary endeavor undertaken to create a unique product,

service, or result[1, pg. 5] (temporary indicating a set beginning and end). With
such a definition, processes in COBIT would, from a simplified point of view, either
support multiple project iterations over a time or an individual repeatable part of a
project that is, across a project or projects.
To leverage some ideas for the risk register, lets go through two selected8 project
methodologies and point out parts related to risk management.
2.2.1
PMBOK
The Project Management Institutes (PMI) Project Management Body of Knowledge (PMBOK, 4th edition) can serve as a great guide to explain several project
management problems and relate project management to IT risk management. The
main project management process groups are summarised in the following figure (for
a detailed interaction map, see [1, pg. 274, Fig 11.1]):
Figure 2.6: PMBOK project management process groups
Source: [1, pg. 40, Figure 3.1].
Risk management processes then would be part of Planning Process and Monitoring & Controlling Process groups as knowledge areas:
11.1 Plan Risk Management,
11.2 Identify Risks,
11.3 Perform Qualitative Risk Analysis,
11.4 Perform Quantitative Risk Analysis,
11.5 Plan Risk Response,
8
Haphazardly.
2. Risk management
10
11.6 Monitor and Control Risks.

Inputs and outputs in the following two figures present a general overview of risk
management in PMBOK (for full definitions, the reader is kindly referred to [1]).
Figure 2.7: PMBOK risk-related processes (inputs and outputs) in
Planning Process Group
Source: author, based on inputs and outputs in [1].
2. Risk management
11
Figure 2.8: PMBOK risk-related processes (inputs and outputs) in

Monitoring & Controlling Process Group
Source: author, based on inputs and outputs in [1].
While the register in the thesis might partially support PMBOK required inputs
and data formats, the author believes that it will not be possible to fully support
project management risks. The basis for such statement can be found in [1, pg.
167, 170] each individual risk can cause a very individual project cost change and
delay in project schedule (for negative risk). Therefore, getting enough data to
tie individual risk (threat) to individual item in work breakdown structure (WBS)
in project schedule and calculating impact wither would not be cost effective or
would not provide reasonable outputs. However, risks might still be monitored at
the project (or project portfolio) level if the implementing organization reasonably
defines assets in the register.
One possibility to manage project risks within the register (to some extent) would
be to add tracking of risk from PMBOK risk breakdown structure (RBS, [1, pg.
280]); it would not add any project-specific problems, yet project stakeholders would
be notified if organization-wide risk related to an item in RBS changed.
It is up to a discussion whether to monitor relationship between e.g. in case of
software development a result of a project (software product ready for shipping)
and the actual process of software development (everything needed to develop the
software) as the line between the two is blurry.
2.2.2
PRINCE 2
PRINCE (PRojects IN Controlled Environments) is a structured (and processbased) method for effective project management[17, pg. 1]. Risk management
2. Risk management
12
(Management of Risk) is one of the components of PRINCE 2 and is embedded within

all its processes (see Figure C.1 for an overview of all processes and components).
Due to the length of the thesis and PRINCE 2, the author has decided to omit
a broader introduction. Various items from PRINCE 2 were incorporated in the
text and the reader is kindly referred to chapter 2 of PRINCE 2 [17] for a broader
introduction to the methodology.
Authors vocabulary note: risk register is called Risk Log in PRINCE 2.
The following section contains a brief overview of the risk management process in
order to introduce several important concepts and to establish a common vocabulary,
as different risk methodologies use incompatible terms for similar situations.
2.3
Risk and risk management overview
As the author has already noted, a great many methodologies exist for risk management. For the sake of compatibility, ISO/IEC 27005:2011 and where necessary,
ISO/IEC 31000:2009 Risk management Principles and guidelines, will be used.
First, lets define two key terms (which is by no means a complete overview
however, the goal of the thesis is not to duplicate a complete dictionary section from
one of the ISO/IEC documents.).
Risk in a general sense is an effect of uncertainty on objectives9 , or a deviation
from the expected [15, pg. 1]. The deviation can be both positive and negative:
for example, if the actual cost of a project is lower than a budgeted cost, it still
presents a risk as the initial estimate (expectations) were different and something
has changed during the run of the project10 .
Risk management process is then a systematic application of management policies,
procedures and practices to the activities of communicating, consulting, establishing
the context, and identifying, analyzing, evaluating, treating, monitoring and reviewing
risk[15, pg. 3]. Of all the properties of risk management in ISO/IEC 31000:2009,
the author would like to point out property e), stating that risk management is
systematic, structured and timely and that such approach contributes to efficiency
and to consistent, comparable and reliable results (of risk management)[15, pg. 8].
This property is one of the underlying reasons for maintaining a high-quality risk
register, as a risk register, at its core, is nothing more than a tool to store (and
analyze) certain risk management data.
9
E.g. financial, health and safety, and environmental goals.

A very vivid example of the term risk (paraphrased from prof. Allen Garth, University of
Northern Colorado) is the risk arising from jumping off the Empire State Building there is no
risk. The person jumping can be baring a miracle sure that after a few seconds of flight, death
will inevitably follow; the outcome is certain and carries no risk at all.
10
2. Risk management
13
The definition is almost identical to BITS GAP (where risk assessment is a

knowledge process that documents the measurable security state of a system using
the consensus judgments of system stakeholders that is employed to determine the
appropriate technical and non-technical safeguards to be applied to reduce specific
risks to acceptable levels[5, pg. 7]); ISO/IEC one is slightly broader and places less
emphasis on quantifiability.
The next figure, a diagram of an information security risk management process
contains all of the phases mentioned in the previous definition and is an application
of the generic risk management process from [15].
Figure 2.9: Information security risk management process
The risk assessment part might be structured in a slightly different way in

methodologies other than ISO/IEC 27005:2011, however, the overall result should be
2. Risk management
14
similar. The risk register should support and store generic data from most phases,
including monitoring and review (the time component). The reader is kindly referred
to the source document for a detailed description of each phase. To put the process in
context, a following mapping exists to the PDCA Information security management
system (ISMS) model from ISO/IEC 27001:2005:
ISMS Process
Information Security Risk Management Process
Plan
Establishing the context, Risk assessment, Developing risk treatment plan,

Risk acceptance
Implementation of risk treatment plan
Continual monitoring and reviewing of risks
Maintain and improve the Information Security Risk Management Process
Do
Check
Act
Source: [14, pg. 9, Table 1].
Table 2.1: Alignment of ISMS and Information Security Risk Management Process
The risk register should help with all phases but context establishment as
one can note in [14], context establishment phase of risk management is mainly
about setting boundaries, scope and more importantly, purpose of risk management
(which can range from supporting ISMS to preparing business continuity and incident
response plans11 ). The register must be, as a support tool, agnostic to the purpose
of establishing information security risk management; however, the results of context
establishment phase will serve as a documentation to customize the actual instance
of the register (e.g. by setting risk acceptance criteria).
The risk assessment part in ISO/IEC 27005 (Clause 8 of the standard) is split
into three activities (processes in ISO/IEC 27001:2005):
risk identification (clause 8.2),
risk analysis (clause 8.3),
risk evaluation (clause 8.4)[14, pg. 13-20].
The full ISO/IEC 27005:2011 risk assessment process is as follows:
11
Specifically, the risk register will not support ranking risks against the risk evaluation
criteria[14, pg. 13].
2. Risk management
Phase
15
Step
Identification of
assets
Risk identification Identification of
threats
Identification of
existing controls
Identification of
vulnerabilities
Identification of
consequences
Risk analysis
Assessment of
consequences
Assessment of incident likelihood
Level of risk determination
Risk evaluation
Tasks
Create of list of assets and related business processes, determine relevance.
Determine threats, identify their type and source.
Select future (planned) and check existing controls
and their usage.
Relate vulnerabilities to assets, threats and controls, review vulnerabilities not related to any
threat.
Create incident scenarios and their impact on
assets and business processes.
Assemble a list of assessed consequences of incident scenarios with respect to assets.
Evaluate likelihood of incident scenarios (quantitative or qualitative).
Prepare a list of risks with value levels assigned.
Finalize a list of risks prioritized according to
risk evaluation criteria in relation to the incident
scenarios that lead to those risks.
Source: [14, pg. 13-20]. Tasks are paraphrased.
Table 2.2: ISO/IEC 27005:2011 risk assessment process

BITS GAP recommends a slightly different process:
1. identify each assets,
2. define undesirable events related to the asset,
3. assess the impact of the event and assign a scalar rating,
4. identify the threat agent related to the event and assign a scalar rating,
5. assess the vulnerability of the asset to the threat agent and assign a scalar
rating,
6. calculate an overall risk rating and ranking. [5, Appendix A]
Compared to ISO/IEC 27005:2011, there is an extra item the chain in ISO/IEC
27005:2011 is asset threat, whereas BITS GAP has a asset event threat.
The thesis uses the longer version (also mandated in Risk IT) as it allows capturing
information about risk in a more structured way. Also, ISO/IEC 27005:2011 puts
identification of existing controls (part of risk identification) between identifying
threats and vulnerabilities (which can vary methodology by methodology). The
impact (consequences) is assessed at the end, not as a second item in ISO/IEC; risk
2. Risk management
16
is assessed using both quantitative and qualitative measures (BITS GAPS strongly
prefers quantitative approach).
To finish building the vocabulary, asset is anything that has value to the
organization[14, pg. 14] and resource is anything that helps to achieve IT goals[20,
pg. 26]. A problem arises from a discrepancy between COBIT and ISO/IEC
information security standards. ISO/IEC 27000 series splits assets into primary
(business processes and activities, information) and supporting (hardware, software,
network, personnel, site, organizations structure), while CobiT 4.1 uses the term
asset in more or less accounting context and reserves resource for applications,
information, infrastructure and people (see section B.5); COBIT 5 introduces even
broader enablers category.
It is up to a discussion which structure is correct; for the purposes of the thesis,
asset will be used in the same meaning as resource in COBIT unless the text
specifically notes that asset is used in an accounting context.
To conclude the general introduction, the author would also like to include a
material that explains why is IT risk management actually necessary and why it
is important to maintain a risk register to track risk over time. A figure from a
study by Ernst & Young nicely summarizes how the need for a comprehensive IT
risk management increases with increasing exposure to risk and breadth of types of
IT risk:
Figure 2.10: Increasing IT risk exposure
Source: [18, pg. 6].
2. Risk management
2.3.1
17
Risk management in CobiT 4.1 and COBIT 5
The underlying requirement to perform risk management is present both in CobiT 4.1 and COBIT 5. However, the earlier framework mentions (unspecified) risk
management process (framework) in a single process PO9.1 IT Risk Management
Framework. In the newer iteration, the responsibilities are split into two and have
much more specific wording. The high-level enterprise governance duty to maintain
the risk register is primarily derived from EDM03 Ensure Risk Optimisation process,
whose purpose is to ensure that IT-related enterprise risk does not exceed risk
appetite and risk tolerance, the impact of IT risk to enterprise value is identified
and managed, and the potential for compliance failures is minimised.[8, pg. 39]
(see RACI chart at page 39 of [8] for further details). The lower managerial level
APO12 Manage Risk then assigns responsibilities to management to continually
identify, assess and reduce IT-related risk within levels of tolerance set by enterprise
executive management [8, pg. 107].
APO12 is so crucial to the thesis that it warrants a detailed look. The following
figure presents all responsibilities in the process:
Figure 2.11: APO12 RACI chart
Source: [8, pg. 108].
There are six activities in the process:
2. Risk management
18
Activity
Management practice
APO12.01 Collect data
Identify and collect relevant data to enable effective ITrelated risk identification, analysis and reporting.
Develop useful information to support risk decisions that
take into account the business relevance of risk factors.
Maintain an inventory of known risk and risk attributes (including expected frequency, potential impact and responses)
and of related resources, capabilities and current control
activities.
Provide information on the current state of IT-related exposures and opportunities in a timely manner to all required
stakeholders for appropriate response.
Manage opportunities to reduce risk to an acceptable level
as a portfolio.
Respond in a timely manner with effective measures to limit
the magnitude of loss from IT-related events.
APO12.02 Analyse risk

APO12.03 Maintain a risk profile
APO12.04 Articulate risk
APO12.05 Define a risk management action portfolio

APO12.06 Respond to risk
Source: [8, pgs. 108 to 111].
Table 2.3: COBIT 5 APO12 activities

The reader is kindly asked to refer to section B.7 for input and output figures
of the process. The risk register should support documenting at least APO12.01
through APO12.04 (see Figure E.1).
COBIT 5 also states a realistic extent and purpose of (IT) risk management in
governance practice EDM03.02 Direct risk management, where it requires the user to
direct the establishment of risk management practices to provide reasonable assurance
that IT risk management practices are appropriate to ensure that the actual IT risk
does not exceed the boards risk appetite[8, pg. 39] (emphasis author).
The quality of the risk management process itself is evaluated in the MEA01
Monitor, Evaluate and Assess Performance and Conformance process.
2.4
Chapter summary
The author has performed an overview of various risk management methodologies

and best practices and backgrounds, and specifically, the three key documents that
consist the theoretical base of the thesis: COBIT 5, Risk IT and BITS GAP, and
walked the reader through a generic IT risk management process based on ISO/IEC
27005:2011. Mapping of processes and goals with references to thesis appendices
with detailed tables was performed too. The text also hinted on possible inclusions
of risk management methodologies, namely PRINCE 2 and PMBOK.
Finally, lets discuss the risk register itself.
Chapter 3
IT Risk register
The chapter contains a gradual definition of various concepts that exist or act within
the risk register. First, lets begin with the definition of risk register itself.
The Risk IT Practicioners guide [21] defines risk register as a database (in the
general information sense, not as a software product) providing detailed information
on each identified risk, including:
information on the risk owner,
information on details of the risk scenario,
information on detailed scores in the risk analysis,
detailed information on the risk response and risk response status,
information on controls (if applicable). [21, pg.48]
Different sources (such as risk register in [11, pg. 104, fig. 4-5]) recommend
including slightly broader inputs, including results of security tests, information
about security incidents and self-evaluation. Usually, it is advisable to use a software
product to maintain the register (as opposed to paper or spreadsheets), as long as it
is aligned to the organizations custom risk management process.
The requirement to maintain an IT risk register can derived from Risk IT RE3
process Maintain risk profile, specifically RE3.5 Maintain the IT risk register and IT
risk map 1 .
RACI chart on page 76 of Risk IT answers a crucial question who, in relation
to CobiT 4.1 roles2 , should maintain the register?
1
IT Risk register in Risk IT is an extension of a risk map but in the thesis, risk map is generally
considered a tool within the actual register.
2
Risk IT refers to CobiT 4.1.
3. IT Risk register
20
Figure 3.1: IT risk register RACI chart
Source: [20, pg. 76]; modified by the author.
On the scope of the risk register Risk register solutions3 vary in the amount of
detail they cover it is definitely not the intent of the author to create a register
able to assess each individual workstation; nor the author believes that such register
would contain meaningful data in all but few extreme situations4 as the cost of risk
assessment to fill the register and keep it updated would be prohibitively expensive
to most organizations. The register should cover key processes and assets related to
key processes.
To continue with the gradual description of the register, the thesis now introduces
several more key concepts of inner mechanisms of the register, with increasing details.
The IT risk register will follow the concepts in the text.
3.1
3.1.1
Risk
Business risk
Risk IT contains a very useful definition of IT risk as business risk associated with
the use, ownership, operation, involvement, influence and adoption of IT within an
enterprise that can occur with both uncertain frequency and magnitude and can
pose challenges in meeting strategic goals and objectives[20, pg. 7]. Such broad
definition makes it possible to extend IT risk from the usual meaning of loosing
business value to also encompass failure to gain business value, especially in terms
of lost opportunities. For example, implementing cloud computing presents a risk
in terms of loosing control over company data, but also avoiding it might pose a
different IT risk of failing to exploit an opportunity, e.g. the ability to quickly scale
enterprise computing facilities. This aspect of IT risk is apparent from the following
two figures:
3
4
See section 3.3.

Probably high security military installations.
3. IT Risk register
21
Figure 3.2: IT risk categories
Figure 3.3: Risk IT risk hierarchy
The extent of being able to capture risk in the register beyond IT operations
and service delivery is questionable one can assume that the more the IT risk
belongs to the first two categories in Figure 3.3, the less quantifiable it is. However,
it could be useful if the register provided a chance to link IT operations and service
delivery risks to the respective broadly defined (if not quantified) Enablement and
Programme and Project delivery risks.
The problem of aggregating results remains: for example the difference between
impact of risk if the whole enterprise is out of power versus if the outage hits only a
single unit is significant and the risk register would have to be able to capture it.
3. IT Risk register
3.1.2
22
Tolerance and appetite
Risk IT notes the difference between risk tolerance and risk appetite (based on COSO
ERM framework, but the definition is also compatible with the ISO 31000):
Figure 3.4: Tolerance and appetite
Risk appetite: the broad-based amount of risk a company or other entity is willing
to accept in pursuit of its mission (or vision).
Risk tolerance: the acceptable variation relative to the achievement of an objective.
Source: [20, pg. 17].
The actual levels will be based on the ability of the organization to contain loss
and organizations culture and risk taking predisposition and will inevitably vary
both within the industry and between industries from risk aversion to risk taking
(opportunity seeking). In Risk IT, both are part of the process RG1 Establish and
maintain a common risk view. Risk appetite is typically based on combination of
magnitude of risk and its frequency.
Risk tolerance is the tolerable deviation from the level set by the risk appetite
and business objectives[20, pg. 17]. For example, the company guidelines may set a
requirement to finish a project, but certain limited overruns (such as 5 % in human
resources costs) will still be acceptable in special cases. It might vary throughout the
organization too rigid a tolerance will impede pursuing new opportunities, whereas
there is no risk tolerance in case of certain legal requirements5 .
In the risk register, the possible variation of risk should be shown, and users should
be warned if the possible risk exceeds company risk tolerance. The organization
should establish a process to derive risk appetite and tolerance, but such process is
out of the scope of the thesis, as is the problem of the difference between perceived
risk appetite and real risk behavior within the organization, especially in the presence
of blame culture. The risk register then might become completely meaningless if it
doesnt provide realistic data and the people within the enterprise are not motivated
to provide realistic data6 .
5
However, Risk IT suggests that one might knowingly accept risk associated with regulatory
non-compliance[20, pg. 17] as a trafe-off if the compliance would be prohibitively expensive.
6
For example IT department is motivated to underestimate risks in the short term to avoid
compliance scrutiny, or overestimate long term risk to retain personnel or higher budget share.
3. IT Risk register
23
Figure 3.5: Risk culture
3.1.3
Risk treatment
Four possible actions, depending on risk impact and frequency, exist: avoidance,
reduction, retention and transfer.
Figure 3.6: Risk treatment options
Risk avoidance: decision not to become involved in, or action to withdraw from, a
risk situation.
Risk reduction: actions taken to lessen the probability (frequency), negative consequences, or both, associated with a risk.
Risk retention: acceptance of the burden of loss or benefit of gain from a particular
risk.
Risk transfer: sharing with another party the burden of loss or benefit of gain, for a
risk.
Source: [14]; italics: author.
Fifth possibility, Taking the opportunity, despite not being an alternative to the
four previous options, should always be explored, even though it will not be included
in the register. As The Orange Book [19] notes, two options exist when treating risk
might provide an opportunity to exploit a positive impact for example improving
IT risk controls could allow taking more risks somewhere else in the project or free
resources that could be used elsewhere. So, any time a risk treatment is proposed,
one should think about the possibility whether lowering the risk to a level further
3. IT Risk register
24
than pure necessity would not provide a benefit far beyond what would lowering risk
right to the necessary level give.
(Another) vocabulary note: the Risk IT framework uses terms accept and
mitigate for retention and reduction; the author believes that terms from ISO/IEC
27005:2011 represent the treatment (response) in a more direct way (especially
retention). A semantic problem is the relationship between risk treatments and risk
controls (measure that is modifying risk[14, pg. 2]). Based on the intended focus
of the risk register on processes and also the perceived meaning, the author employs
the term risk treatment (process to modify risk[14, pg. 5]) as a substitute for
controls. The ISO/IEC definition conveys the intended message that risk treatment
is a continuous process that needs to be managed and reviewed, not a measure at a
single point of time. However, in reality of the risk register, the difference is minimal
and depends on the organization using the register (see subsection 7.2.3).
M o R on the other hand ads a mix of reduce and transfer categories as share,
defined as sharing both gains and pains from a contract between multiple parties [16,
pg. 23]. However, the author believes that the same effect can be achieved by using
multiple treatments or multiple categories for a single treatment of a single risk .
PRINCE 2 suggests yet another risk treatment (response) option contingency,
meaning actions planned and organised to come into force as and when the risk
occurs[17, pg. 256]. In authors opinion, its importance does not warrant an addition
to the risk register, especially if one compares contingency to reduction in the same
methodology, which is (actions that) limit the impact on the project to acceptable
levels; the two options are nearly identical.
One last problem is worth mentioning the issue of costs. In spite of being fairly
simple, the following figure sums up the core decision behind any risk treatment.
Figure 3.7: Balancing the risk
Source: [17, pg. 256, Figure 17.3].
3. IT Risk register
25
Insurance as a risk treatment

Insurance as such serves to convert uncertain costs to company assets to a fixed
price (risk transfer). It is impertinent to evaluate effectiveness of insurance coverage
to past incidents, both in terms of actual versus expected costs of the incident (see
BITS GAP [5, pg. 14]) and uncovered coverage gaps.
Being reimbursed by the insurance company creates a new cost and requirement
extensive documentation, and the organization must include the actual cost of proof
of the incident in the cost of risk transfers. Maintenance of forensic data requires a
sound chain of custody. Underwriting process itself takes some time and the cost
should be added to risk transfer costs.
The overall effectiveness of insurance policies and applicability to systemic risks
related to the Internet[5, pg. 16] are questioned too in BITS GAP. The ability to
assess the value of certain assets is lacking especially loss-costs, often accompanying
information security incidents, such as:
lost business opportunity,
lost productivity,
reputation damage (according to [5, pg. 16]).
Insurance of very specific items, including whole business procedures and processes
is generally impossible. Data loss will usually relate to loss of the physical storage
medium; intermediary storage (RAM of a server) is excluded. Modern storage
methods third party clusters and especially cloud computing services (Amazon S3
storage or content distribution by Akamai) only increase the problem, as the
exact geographical location and method of data storage may be unknown to the
company. Also, a significant price difference is present between the policy for cost
of reproduction of data and a policy covering possible losses from stolen records or
revealed confidential materials (reproduction costs vs. inherent value of data).
3.1.4
IT risk communication
One of the main tasks that the risk register must accomplish is to facilitate information
flows. Within the Risk IT perspective and its communication components Expectation
(strategy, policies, procedures, awareness, training), Capability (risk management
process maturity) and Status (risk profile of the enterprise, event/loss data, cause
of loss events, options to mitigate,...), the focus is on the latter. However, in an
advanced risk register, one should consider including the Expectation component too,
to link risks with progress of training and overall company strategy.
3. IT Risk register
26
Information in the risk register must adhere to the following principles:

Figure 3.8: Risk information properties
Clear: known and understood by all shareholders.
Concise: includes avoiding jargon and avoiding technical terms.
Useful: relevant, sent to appropriate parties.
Timely: communication is timely when it allows action to be taken in the critical
moment between risk origination and its potential business consequence.
Aimed at correct target audience: aggregation must not hide root causes of risk,
yet high-level data is needed for policymakers.
Available on need-to-know basis: both internal and external parties must have a
genuine need to know risk-related data.
Source: [20, pg. 20]; paraphrased by the author.
The Clear and Concise properties will be achieved by providing sufficient

aggregation of data in the register, ie. the ability to get both a general overview
of risk with regard to business processes and a detailed technical information. The
author considers unwise to avoid actual technical details, as that would remove the
underlying source of risk data and the aggregated risk would be meaningless.
The Useful property is a focus of the risk register manual and Timely will
be solved through a dashboard and assigning time-based reminders to items in the
register. The Available on need-to-know basis is discussed in chapter 4 with regard
to ISO/IEC 27001.
Poor risk communication and awareness is a base for false confidence and will lead
to unbalanced communication to the external world on risk[21, pg. 19], harming
relations with clients, investors, regulators or shareholders. It might also lead to a
perception of covering up known risks from stakeholders[21, pg. 19].
As for clerical communication details of IT risk register data, the example
Risk IT risk register entry template ([21, pg. 48]) tracks last risk assessment date
and also due date for update of the risk assessment. This field might be used in
the register in several ways: to remind the users about pending assessments and
to disregard any risk treatments that have not been updated after due date; such
approach helps with fulfilling risk information properties (Figure 3.8) as it prevents
basing risk assumptions on false or invalid data (especially the Timely component).
A reasonable implementation might be a view of risks not assessed after a set date.
PMBOK Project communication section can serve as an inspiration for management of communication within the register and several requirements for an advanced
register might be derived. The hypothetical register should track how is information
3. IT Risk register
27
about risk distributed as certain stakeholders (especially higher up in the structure)

will need general information about risks, yet any automated output will not be able
analyze and summarize the information. Thus, the register should assign a task to
an individual employee(s) to create a summary of the selected parts of the register
and inform the stakeholder and store when the distribution occurred. The register
should also track if any action was required in the report. Such communication
procedures would also be in line with the recommendations of M o R [16, pg. 16].
Unfortunately, such requirements would extend authors risk register beyond the
scope of masters thesis.
3.1.5
Expressing risk
Closely related to risk communication is the problem of describing risk [21, pg. 33].
Both quantitative and qualitative methods have limitations:
Figure 3.9: Risk expression methods limitations
No method is fully objective and results of risk assessment are always dependent
on the person performing them and his/her skills and views.
IT-risk-related data are typically of poor quality and quite subjective (for
example, process maturity, control weaknesses).
Complex quantitative methods with limited datasets result in too confident models;
however, simplistic methods can also lead to unreliable expectations about
risk.
Source: [21, pg. 33], paraphrased by the author.
The risk register should use a mix of qualitative and quantitative approaches
to leverage their advantages and avoid some of the disadvantages and lean towards
quantitative analysis where possible7 . The expected quality of data for the register is
fairly low but the subjectivity can be alleviated by precise definitions of qualitative
terms (ie. risk impact label severe in the register should be accompanied by
definition of severe and examples as interpretations of severe will vary across the
organization and executive levels, as will vary interpretations of timeframes).
Risk IT Practicioners guide suggests expressing impact of risk in unambiguous and clear business-relevant terms[21, pg. 34], which should be the approach
supported by the risk register in this thesis, with the help of one of the presented
methods, a link to COBIT. The business impact of any IT-related event (then) lies
in the consequence of not achieving the information criteria efficiency, effectiveness,
confidentiality, integrity, availability, compliance, reliability. However, such method
7
For example by adding ranges to primarily qualitative expert opinions.
3. IT Risk register
28
would still remain in the middle between IT and business risk as it does not capture
real business impact: impact on customers or in financial terms[21, pg. 34]. An
extended method then works with transforming business goals into risk expressed as
business consequence.
Business Goal
Risk Expressed as Business Consequence
Provide a good return on investment of ITenabled business investments.

Improve corporate governance and transparency.
There is inadequate return on investment of

IT-enabled business investments.
Inadequate financial transparency for markets reflects on share value and compliance
risk.
Bad or insufficient customer service results
in client loss.
Ineffective products and services do not address customer needs, resulting in revenue
loss.
Improve customer orientation and service.

Offer competitive products and services.
Source: [21, pg. 35, figure 24].
Table 3.1: COBIT (BSC) Risk Description in Business Terms (selected

examples)
An approach that goes even further is connecting COBIT business goals with
extended Balanced score card (BSC).
Figure 3.10: Extended Balanced Score Card criteria expressing risk
impact
Financial : Share value, Profit, Revenue, Cost of capital
Customer : Market share, Customer satisfaction, Customer service
Internal : Regulatory compliance
Growth : Competitive advantage, Reputation
Source: [21, pg. 35].
However, this extended approach must be modified in an implemented risk register

as the author believes that impact in terms of extended BSC criteria is individual
for each organization and cannot be generalized it must be custom-tailored to each
IT risk register instance.
A practical example of mapping atomic IT event and business goals[21, pg.37]
with CobiT 4.1 from the Risk IT Practicioners Guide clearly explains how the risk
register in the thesis should work. For the case of an e-commerce site:
1. The business goals are improve customer service and service continuity.
3. IT Risk register
29
2. CobiT 4.1 maps business goals to IT goal; risk means not achieving IT goal,
which has impact on the prior business goal. The service continuity requires
IT to maintain specific goals, e.g. reducing application defects.
3. Then through CobiT 4.1, the cascade is continued down to the IT process
level and IT activity level[21, pg.37]. In terms of CobiT 4.1, this would lead
to ie. AI7 Install and accredit solutions.
4. At the risk analysis level, IT processes are linked to risk scenarios. The end
result is that one can trace IT process failures and events causing them to the
high level business goals.
The full and definitive mapping tailored to COBIT 5 from table Table 3.1 employed
in the register is in Appendix A.
3.1.6
Expressing risk frequency
Risk frequency, sometimes also called likehood or probability is a key to describing

risk in risk scenarios. As Risk IT Practicioners guide notes, the term frequency
(number of times an event occurs in a given time period[21, pg. 37]) provides
a more rigorous information about the event than probability. Also, it might be
complicated to establish probability of for example one harddisk failure in a server
room for a whole year (the probability approaches 1), but using number of failed
hardisks from the past year will allow the company to differentiate the risk (difference
between one failed unit and 10 failed units).
The actual rating can then be derived from occurrences per year (logarithmic in
the example).
Frequency rating (level)
Occurrences per year
5
4
3
2
1
0
h1000; 10000)
h100; 1000)
h10; 100)
h1; 10)
h0.1; 1)
h0; 0.1)
Source: [21, pg. 38, figure 25]; modified by the author.
Table 3.2: Example frequency scales

A similar scheme will be used in the risk register to remove possible bias of the
person inputting the data; however, the scheme should be fully adjustable. Another
advantage of the scheme is that it is possible to compare estimates from past years
3. IT Risk register
30
to actual rate of occurrence and adjust accordingly current estimates of frequency.

Ultimately, the choice of scale will be based on the risk assessment method, unless
the method and software support are tightly connected as is the case of CRAMM8 .
Even though the thesis does not focus on psychological issues of risk analysis,
certain schemes of assessing frequency must avoided. Mainly, schemes instinctively
leading the person to assign average value e.g. the middle one in a five-level
scale.
Estimating the real frequency might prove to be difficult. Compared to traditional
incidents (for example theft of tangible assets), information security events often
lack a clear, identifiable point for cause of loss[5, pg. 16]. One can assume that
an incident began at several possible points, ranging from passive reconnaissance of
corporate network to actual intrusion, and theft or abuse of data. Determining a
too late point may prohibit claims for losses happening before the incident, and too
early a point will lack definite evidence. In a register beyond the thesis, a certain
amount of fuzzy matching should be added. For example in case of statistics of
assets affected by incidents, the register might try to inform the user that a recorded
incident could have affected an asset even though it took place a week outside of a
selected time period.
A useful item to track related to frequency is the proximity of risk, defined in [17,
pg. 387] as the closeness in time in which the risk is likely to occur. Sometimes, the
value (date) is unknown, as one cannot predict for example floods with high certainty.
However, a risk of the main business site being overloaded, leading to degraded
customer service, might have a set point at which it can appear specifically, launch
of a new marketing campaign. The risk register should track proximity.
Risk frequency by no means captures any relation to impact frequency and
impact are separated, even though such concept may seem strange. However, it
allows us to capture both frequent event (level 5) with minimal impact (level 0) such
as a random port scan on a company firewall and infrequent event (level 1) with
extremely high impact (level 5) such as loss of all customer data.
3.1.7
Expressing risk impact
Risk impact (also, magnitude in Risk IT) should be expressed in business terms
(see subsection 3.1.5). The author proposes implementing impact scales based on
Risk IT Practicioners guide with certain modifications. The ultimate method of
expressing risk impact cannot be defined by the risk register itself but rather by the
risk analysis procedures. Therefore, the risk register should support extending the
8
CCTA Risk Analysis and Management Method.
3. IT Risk register
31
scales to the needs of the enterprise.

Area
Scale
Metric 1
...
Metric i
0
...
n
Source: [21, pg. 38, figure 25].
Table 3.3: Generic impact scales of an event

The metric should preferably be quantitative; if multiple metrics are applicable in
the area, the one with the highest ranking (impact) is the risk impact of the event in
the area. One event can have several impacts in different areas (e.g. legal, financial,
regulatory as in the following table).
Impact
0
1
2
3
4
5
Legal
Legal Regulatory non-compliance

Financial (USD); up to
License to Operate
Personal conviction
Imprisonment
$0
$1,000,000
$2,000,000
$5,000,000
$10,000,000
h$10,000,000
Fined
Revoked
Source: [21, pg. 39, figure 26]; modified by the author to adhere to Table 3.3 structure.
Table 3.4: Impact scales example

Risk IT Practicioners guide provides several methods to get one final risk impact
for the event. None of these methods provide one relevant compound number, even
though such number could be of great use throughout the register. Calculating it as
an arithmetic average of risk impacts in each area would give us a single number,
however, it would also cover variance within the scores. The author proposes to use
root mean square (quadratic mean) to estimate compound impact of an event in
the register.
3. IT Risk register
32
Figure 3.11: Root mean square
xRM S =
v
n
uP
u
x2i
t
i=1
Where:
xi is impact score from a selected area,
n is number of areas, and
xRM S is the resulting risk impact of the event.
Source: [12, pg. 33].
The rationalization of root mean square is in the following table:

Risk impacts from
three areas
Arithmetic mean
Root mean square (rounded

to two digits)
2,
1,
0,
0,
2
2
2
2
2
2.16
2.58
2.94
2,
2,
2,
1,
2
3
4
5
Source: author.
Table 3.5: Root mean square rationalization

It is evident that root mean square does not cover variance as much as square
mean does the tendency to emphasize higher impacts might even be increased with
certain tweaks to the formula. Despite the results, one must remain wary of any
averages in the register and the register should provide a way to display events
(scenarios) with low average impact, but a single high impact in a certain area. Also,
in case of known financial impact of event, such impact (magnitude) should be
retained within the register and used for precise calculations.
Compared to Risk IT, BITS GAP uses a more traditional expression of incidents
defined through annualized loss expectancy as:
3. IT Risk register
33
Figure 3.12: Annualized Loss Expectancy (ALE)
AV EF ARO = ALE
Where:
ALE annualized loss expectancy,
ARO annualized rate of occurrence,
EF exposure factor (threat severity),
AV asset value.
The author believes that the risk register could support both options, even
though Risk IT recommends not using highly quantitative methods because of
possible inaccuracies. ALE is extremely valuable for comparing different ways of risk
treatment and their combinations, on the other hand, it also includes and extremely
subjective component - exposure factor. Such factor would be extremely hard to
express exactly in fairly limited scope of the thesis.
BITS GAP also mentions several interesting costs arising from information
security incidents, which are, in the opinion of the author, not present in most other
literature:
management diverted from strategic focus,
negative publicity,
loss of customers,
large accounts move,
defense expenses.
Such costs can be higher by several orders of magnitude than the actual value
of lost data. For example, defacement of corporate public website will be viewed
as lax security and will cause media attention, despite the fact that the website is
completely isolated from the corporate intranet and contains no data that is not
considered public. However, guessing such costs is extremely problematic as there is
no reference point: for regular incidents, costs are known or can be estimated from
past data but for large, catastrophic incidents, very limited data exists. Another
problem is the average cost for a type of incident, which should be carefully calculated
(preferably as median, to limit a few incidents that skew the scale e.g. a harddisk
failure causing extremely unusual losses will increase costs of a typical routine disk
failure in a RAID field).
3. IT Risk register
34
As for project management methodologies, the impact scales can be extended

into several categories. PMBOK [1, pg. 281] suggests using cost, scope or quality
change, in addition to pure cost, as examples however, the categories should be
tailored to individual organizations needs.
3.1.8
Risk maps
A convenient way to express risk is to use a risk map a graphical two dimensional
diagram, with frequency and impact being the two dimensions[21, pg. 46].
Figure 3.13: Risk map with risk appetite bands
In the opinion of the author, Risk IT map has a shortcoming. If one compares risk
bands in the map, the slope of the line between risk bands is not 45 degrees (indicating
that frequency and magnitude do not have same scale). Psychologically, it is
understandable to expect points on a line (e.g. between Opportunity and Acceptable)
to have equal risk (in terms of combinations of magnitude and frequency), no
matter how unsubstantiated that might be. Therefore it could be useful to display the
risk map with bands as circles see Figure 3.14. Also, the generalized risk treatment
options (avoidance, retention, reduction, transfer, see Figure 3.6) are indicated in
the map (but merely as a suggestion) and a notion that risk is continuous (instead
of clearly differentiated with risk bands) can be discerned as continuous rainbow
instead of four clearly separated bands.
3. IT Risk register
35
Figure 3.14: Modified risk map
Source: author.
The actual risk treatment is more a matter of financial decision through for
example ALE (see Figure 3.12) and subsequent return-on-risk (or ROSI returnon-security) calculations as it is possible that with a set budget, treating several
lower risks with result in much lower ALE than treating a single risk with high
ALE (or combination of frequency and magnitude). Such analysis is of course out of
the scope of the thesis and would probably be performed on specific data extracted
from the register.
3.1.9
Risk scenarios
Scenarios and their analysis (in terms of Risk IT) is a technique to make IT risk
more concrete and tangible and to allow for proper risk analysis and assessment.
[21, pg. 51], while IT risk scenario is a a description of an IT-related event that can
lead to a business impact, when and if it should occur[21, pg. 54].
Scenarios help in identifying possible IT risks throughout the organization, which,
given the widespread use of information technology and business dependence on IT,
is not an easy task. Despite the fact that the development of risk scenarios is not
part of the thesis, risk scenarios compose an important part of the register and it
should allow adding new scenarios to the generic ones included in the example data.
Two possible ways of developing risk scenarios are hinted on in the following figure.
Any generic risk, however, must be adapted to the specific organization during risk
analysis.
3. IT Risk register
36
Figure 3.15: IT Risk scenario development
Risk IT provides a very agreeable overview of scenario components:

Figure 3.16: IT Risk scenario components
3. IT Risk register
3.2
3.2.1
37
Various notes
Liability
The difference between being attacked and being a source-proxy of an attack may
create a coverage gap abuse of infrastructure is typically not covered under insurance;
neither is provided coverage against vicarious liability9 or human error.
A recommendation for risk management should be that transferring risk with
insurance creates a new, secondary risk.
3.2.2
Effects of risk management and virtual risk
A good risk management can have a profound effect on the organization and its risktaking behavior. A common sense might suggest that the better the risk management
process (and the better the data in the register), the better the approach to risk,
despite the fact that in reality, the effect could be completely opposite. As Adams
notes in [2], a common belief states that seat belts reduce casualties in road accidents.
However, the issues gets rather complicate if we take into account wider timeframe.
Do seat belts affect risk taking behavior ? Could it be that the nett effect of seat
belts is lower than we think, because while a seat belt saves life during an accident,
it makes people cause more accidents by making us feel safer (and thus drive faster
and more aggressively)?
The same can be inferred for the risk register the better the data, the closer to
any safety margin can the organization get. If we expect on average 20 hardware
failures in a datacenter per day and from previous years calculate that within the 95
% confidence interval, there will be no more than 25 failures, then any inventory of
replacement hardware can be lowered to lets say 26 per day. Keeping more is not
acceptable from the financial standpoint but what if an unexpected event strikes?10
A similar issue gradually occurs as the knowledge of risk landscape improves, the
register is filled in more and more and most events are predicted by risk analysis
the organization might tend to forget about yet unknown risks, lingering outside of
the risk register.
Another problem is the perception risk. In [2], Adams splits risk into three
categories: directly perceptible risks (falling off a cliff trauma and death), risks
perceived through science (smoking increased probability of lung cancer death)
9
Liability without regard to the personal fault of the employer for torts committed by an
employee in the scope of employment[9, pg. 648] (under the common law doctrine of respondeat
superior ).
10
A reasonable organization would have plans for events outside the interval (insurance, temporary
technical solutions), but the idea is to present a simplified example.
3. IT Risk register
38
?
and virtual risks (cell phones use cancer death)11 . Virtual risks may or may
not exist, but they have real consequences people act on the meanings that they
impose on uncertainty[2, pg. 29].
For the risk register, virtual risks create a problem with risks that cannot either
be scientifically measured at all or cannot be measured with the dataset available to
the organization. A common virtual risk could be the feeling of being a direct target
of an attack while the actual attack was only circumstantial result of looking for
weak spots across a set of organizations. On the other hand, due to the existence
of endless amount of random attacks (for example, automatic robots guessing FTP
account passwords), the organization could decide to not assign any meaning to a
directed attack.
3.3
Limitations and omissions of the thesis
Numerous items are omitted from the thesis: risk culture, psychology of risk, communication of risk would all warrant a more detailed look (as [20] suggests), and
methods encouraging people to fill the register could definitely suffice as a topic
for another text. Also, lots of technical problems remain too, as well as specific
problems with tying the risk register to methodologies and frameworks other than
COBIT 5.
Certain problems with inner mechanisms of risk are unsolved for example impact
and frequency act together lots of the time. Imagine an event that might have a
very low probability of turning out to be catastrophic and a much higher probability
to remain within acceptable bands. The author believes that capturing individual
probabilities of possible risk events would require too extensive an analysis and
therefore outgrow the purpose of the register in thesis. However, to compensate
and capture the possible (no matter how improbable) risk of catastrophic loss, risk
scenarios in the register could be modified to contain a field to mark them as possibly
having much higher impact than expected and the threshold could be part of
setting up the register.
Also, the implementation of the register is rather academic that is, in a realistic
deployment scenario, the register would require e.g. authentication customization
and certain changes in the code to allow for a much more granular permission model.
During the early stages of the thesis, before COBIT 5 was released, the author
contemplated assigning CobiT 4.1 controls to individual risk scenarios, so as to allow
following links between control failure and risk to assets. While the link may not
11
Examples made up by the author of the thesis.
3. IT Risk register
39
be apparent, it is implemented in the register through a proxy object (RiskEntry,

detailed later) but the relationship is only indirect.
No interfaces to other systems are considered, but an extension of the register
could for example include data from intrusion detection systems (IDS).
3.4
Chapter summary
The author has explored various concepts of business risk and the thesis introduced
the definition of risk register as a database (in the general information sense, not as
a software product) supporting providing detailed information on each identified
risk[21, pg.48]. The chapter continued with risk tolerance and appetite as two
distinct terms, possible risk treatments (risk avoidance, reduction, retention and
transfer) and discussion of relationship between risk treatment and risk controls. A
significant part of the text is also dedicated to expressing risk in quantitative and
qualitative ways; various methods to calculate or assess risk impact and frequency
are discussed and the author defined preliminary scales that will be used in the
implementation part of the thesis. The reader was also presented with risk scenarios
as an invaluable tool to identify risk and with two ways to establish risk scenarios,
and risk maps were introduced too as a graphical representation of organizations
risk position.
The last part of the chapter contained a short summary of thesis limitations, and
some thoughts on how risk management affects our behavior and how we as not so
rational humans understand and evaluate risk. The thesis continues with details of
the risk register security requirements.
Chapter 4
Additional risk register security
requirements
While the basic set of requirements can be easily derived from the theoretical part of
the thesis, there are some further topics that need to be discussed.
The security of the register itself is a key issue; the author bases all requirements
on ISO/IEC 27002:2005 norms and deems that the selected requirements provide
reasonable security1 . This chapter knowingly omits physical security of the register
(such as access of personnel to a database server) or any measures that are not
directly related to risk register implementation as a software program running in
void.
All core controls (item 0.6 Information security starting point) will be considered.
All requirements that are critical during the implementation have been included in
the Implementation guide (Chapter 5, Table 8.1).
The following part contains comments on several ISO/IEC 27002:2005 controls
that are not part of the table in Chapter 5. The reader is kindly asked to keep in
mind that all requirements not directly affecting risk register as a software stack
are placed in Chapter 5 in the implementation checklist. This includes for example
backups.
6 Organization of information security The external requirements (6 Organization
of information security) are left to the user of the risk register, as they depend on
the individual implementation and access of third parties; the register itself only
prevents any unauthorized access of external parties.
1
More stringent requirements, for example memory separation, are probably unrealistically
expensive, especially considering the type of data (known risks) in the register. Also see Figure C.2.
4. Additional risk register security requirements
41
7.2 Information classification Any information within the register is considered

to be classified and private2 . All parts of the register and output from the register
will display an appropriate label (for example, Confidential).
10.1.3 Segregation of duties The author has considered implementing the register
in a way that would require two people to edit critical items (editor and reviewer
to accept the change). However, such extreme segregation would prove to be
unmaintainable if used in an actual working environment. As a compensation control,
the author suggests assigning a duty to periodically review changes in the register in
bulk; the register itself must support capturing all changes for a preselected period
for analysis.
10.4 Protection against malicious and mobile code As per the software and
hardware requirements (section 8.1), the register is expected to be operating in a
controlled server environment where all programs and libraries are supplied and
updated in a secure way through a package manager provided by the operating
system vendor. The client connecting to the register is out of the scope of the thesis,
because the register is a web application and cannot3 manipulate with the client
computer in any way.
Protection against introduction of malicious code into the register by the user
works in two ways. All uploaded files are scanned by an anti-virus program4 and
all text fields are automatically sanitized to prevent SQL injections and cross-site
scripting5 .
10.9.2 On-Line Transactions The risk register works as a web application, so
fulfilling this control bears an utmost importance. While the ISO/IEC 27002:2005
control is focused on e-commerce, it remains valid for any high-security web application; it requires that information involved in on-line transactions should be
protected to prevent incomplete transmission, mis-routing, unauthorized message
alteration, unauthorized disclosure, unauthorized message duplication or replay.[13,
pg. 54].
Within the register, the control is established in the following ways:
2
The statement is not completely valid for publicly listed companies that are typically obliged
by law to disclose certain facts to shareholders (owners of shares) and the general public.
3
In an idealistic world without insecure web browsers.
4
general_tools/file.py contains a function content file name() that can be used to hook the
virus scanner to an external anti-virus program; a safer option would be to implement a custom
filestorage in Django (extend an existing one). The same approach is possible to implement digital
signatures and timestamps for all uploaded files.
5
Which happens by default with the Django library.
Item to prevent
Solution
Incomplete transmission
Mis-routing
Unauthorized message alteration
Unauthorized disclosure
Unauthorized message duplication
Unauthorized message replay
SSL encryption (mod openssl ); see section D.1.

n/a
SSL encryption (mod openssl ); also, clickjacking protection in Django.
SSL encryption (mod openssl ).
SSL encryption (mod openssl ); cross-site request
forgery (CSRF) protection in Django.
SSL encryption (mod openssl ); cross-site request
forgery (CSRF) protection in Django.
42
Source: author; Django documentation, [13], [3].
Table 4.1: ISO/IEC 27002 10.9.2 On-Line Transactions control

A further protection would be to implement a user session lasting only until the
user closes his browser window; in authors opinion, such behavior would make the
application cumbersome unless the standard authentication back-end is replaced
with for example Active Directory or LDAP, so it is not included in the default
configuration.
10.10.1 Audit logging The risk register should log all changes in key objects within
the register. The following items from ISO/IEC 27002:2005 should also be logged
automatically:
user IDs (a),
dates, times, and details of key events, e.g. log-on and log-off (b),
records of successful and rejected system access attempts (d),
records of successful and rejected data and other resource access attempts
(e)[13, pg. 55].
The remaining requirements are to be fulfilled by the organization using the
risk register (see Table 8.1). The audit trail implementation is documented in
subsection 7.3.3.
11 Access control User access is controlled at a technical level within the application. However, the larger issue of assigning access must be tackled during the
register implementation (and is specifically required in chapter 8).
Role
Permissions
user
edit
logs
user administrator
Can
Can
Can
Can
43
access the register interface and log-in.

edit items in the register.
access risk register logs.
assign and remove user roles.
Source: author.
Table 4.2: Suggested user roles

A fifth role might be included in a customized risk register review allowing
users to approve changes of other users (preferably without allowing the user to
change any other data6 ).
The actual extent of user access must be defined by the organization adopting
the risk register and is required in the manual (subsection 8.3.2). The register at its
current state before customization is in direct violation of several clauses, including
periodic changes of passwords in 11.2.3 User password management. The author
expects the organization using the register to replace the default authentication
backend, and customize it to enforce information security best practices7 or manually
enforce the policies.
Preventing password storage is a technical problem with the default HTML
templates, users will be asked by the web browser to store passwords. The author
leaves the decision to either prevent password storage in the template8 , the browser
or to consider the risk of storing passwords to be the lesser evil with regard to simple
(easy to remember) passwords.
Django automatically adheres to 11.5.5 Session time-out Control and follows
most of items in 11.5.3 Password management system; passwords are stored as salted
hashes9 . The user has no access to system utilities from the web application.
12.2 Correct processing in applications All data in Django (and hence in the risk
register) is automatically sanitized at two levels. The templating system10 prevents
any output of malicious code to the users (cross-site scripting) and default templates
6
In the thesis, review can be easily implemented by adding a new field to objects to mark review
status and a custom objects Manager that would filter inactive (non-reviewed) objects from queries
by default.
7
See [10] at https://docs.djangoproject.com/en/dev/topics/auth/.
8
By implementing a JavaScript login form to prevent the browser from recognizing it as a login
prompt.
9
See
[10]
at
https://docs.djangoproject.com/en/dev/topics/auth/
#how-django-stores-passwords; the mechanism follows NIST SP 800-132 Recommendation for Password-Based Key Derivation Part 1: Storage Applications.
10
See
[10]
at
https://docs.djangoproject.com/en/dev/topics/security/
#cross-site-scripting-xss-protection
44
do not override any content escaping11 . At the database level, Django ORM model
prevents using raw SQL12 and all parameters in object queries are sanitized (and the
author did not use the extra() method to access data).
The ORM database layer also automatically enforces checks on input length of
any data.
Two avenues for malicious data remain: file uploads and further use of data
elsewhere. The author maintains that files should be checked within a company-wide
antivirus software. Implementing a rudimentary ClamAV filter is fairly simple if no
company-wide software exists13 .
Processing failures due to the nature of web applications, the whole request
from the user is performed as one database transaction. In case of any failures, the
database is rolled back to its previous state without any loss of integrity14 .
No checks for internal processing exist, as the nature of data in the register
prevents such checks.
12.3 Cryptographic controls The risk register stores the password in a cryptographically secure way (see 11 Access control ). All access must be performed through
a properly configured web server over SSL encrypted connection. Proper server
configuration is in section D.1. No further cryptographic controls exist; it would be
possible to create cryptographically signed PDF files with data from the register
by customizing some of the templates and using LaTeX together with for example
Adobe LiveCycle Digital Signatures ES2 for processing.
Built-in Django issues The built-in Django adminstration interface, while perfect
for initial data input, accesses all models at a low level, bellow any risk register views.
Therefore, it could be used to avoid certain parts of the logging system (detailed
later) and should be disabled by default.
11
All potentially dangerous characters are converted to HTML entities.

See
[10]
at
https://docs.djangoproject.com/en/dev/topics/security/
#sql-injection-protection
13
With pyclamav library; also see http://code.google.com/p/django-antivirus/ (last retrieved August 20, 2012).
14
May not be possible with all database backends. However, the default PostgreSQL fully
supports transactions.
12
Chapter 5
Risk register requirements summary
General requirements are set in the thesis. However, to provide a coherent overview
of the expected functionality, the risk register shall contain the following features.
Area
Functionality
Functionality
Support COBIT 5 APO12.01 through APO12.04 and store data from

risk identification, estimation, evaluation, treatment and acceptance
phases of ISO/IEC 27005 Risk management process, specifically:
storing risk assessment data,
categorizing assets (goals, processes) through COBIT 5 goal
cascade,
documenting risk events (scenarios),
linking assets with risks, risk scenarios and risk treatments,
analysing risk events (scenarios) and business effects of events
through a set of extendable scales (frequencies, impacts) according to Risk IT using both quantitative and qualitative
approaches,
tracking risk and risk treatment through time.
Source data
Performance
Reliability
Usability
Security
Hardware and software
The risk register should also support employing risk tolerance and
appetite levels, rudimentary tracking of project IT risks and allow
quickly displaying data at various levels of aggregation.
Use COBIT 5 and Risk IT as source data where possible.
Provide near real-time performance with data processing times from
one user input to another lower than 30 seconds.
Assure data integrity.
Contain user interface understandable by knowledgeable computer
user and provide help throughout the interface.
Support multiuser environment with granular access control. Log all
user actions and allow review. Label information in the register.
Client software agnostic to server software running the register; software libraries part of the standard Debian wheezy or packaged with
the register.
Source: author. Note: knowledgeable computer user is definitely a vague term.
Table 5.1: Requirements summary
Chapter 6
Risk register platform
The risk register in the thesis is a web-based client-server application.
6.1
Software choice and requirements server side
The core of the risk register is implemented in the Python programming language,
using all features of the version 2.7; it is running on the standard Python interpreter.
There are no features which would prevent migration to Python 3 once the Django
framework starts supporting it (experimental support is already in version 1.5). The
choice of Python is based on rapid development and personal experience with the
language and ecosystem.
The risk register heavily uses the Django web framework. The author has selected
Django due to both knowledge of the framework and reasonable quality1 . Django
has a stable API2 , very detailed documentation3 and known depreciation plan and
release dates4 and the releases are based on annecdotical evidence5 very well
tested and lack any significant bugs or security holes.
Django encourages software development good practices6 . The framework is fully
based on the model-view-controller (MVC) structure and is object oriented. More
features of Django are described throughout the text of the thesis, especially with
regard to security.
1
Djangos tagline The Web framework for perfectionists with deadlines sums it all while the
author may not be a perfectionist, this thesis certainly has a deadline.
2
See [10] at https://docs.djangoproject.com/en/1.4/misc/api-stability/
3
See [10] at https://docs.djangoproject.com/en/.
4
See [10] at https://docs.djangoproject.com/en/1.4/internals/deprecation/.
5
See security issues at https://www.djangoproject.com/weblog/ and bug reports at https:
//code.djangoproject.com/query.
6
See [10] design philosophies at https://docs.djangoproject.com/en/1.4/misc/
design-philosophies/ (last retrieved December 8, 2012).
6. Risk register platform
47
Apart from standard Python modules, the risk register uses several Django
applications:
django-tables2 by Bradley Ayers7 to display sortable HTML tables,
django-extension to generate class diagrams.
PostgreSQL version 9.1 is the default database backend. Django supports numerous database backends and the author also used SQLite during development. Django
uses memcached instance to improve performance.
The application is served by Apache 2 webserver (prefork) through mod wsgi ; the
stack supports a caching proxy, additional logging and any other Apache 2 features.
The development version can also run through the built-in Django web server for
easier debugging. Apache 2 might be replaced with nginx or lighttpd after some
adjustments.
The operating system needed for the default risk register is Linux, specifically
Debian (wheezy); generally speaking, the risk register can be installed on any recent
Linux/Unix based system that supports the underlying infrastructure (webserver,
database). The author is not aware of the extent of support on Windows based
operating systems.
While the Python (as interpreted language) and Django (as an extensive frameworklibrary) is not the fastest possible combination (in terms of speed of calculation),
the author believes8 that it provides sufficient performance for the type of data and
type of calculations in the register.
6.2
Software requirements client side
The register requires the connecting client to use any modern browser. Supported
browsers are:
Microsoft Internet Explorer 9.0 or newer,
Mozilla Firefox 12.0,
Google Chrome 20.0.
7
https://github.com/bradleyayers/django-tables2/; GIT commit g595c8d4 (last retrieved
October 5, 2012).
8
Based on experience with the stack; the performance starts to lag only when making several
tens of thousands object manipulations (retrieve from database, perform interaction, save modified
object) per second on low-cost servers (Intel Core i5 CPU, 8 GB RAM).
48
The list is arbitrarily based on authors experience with HTML/CSS and capacity
to test templates in numerous browsers. Any reasonably recent9 web browser will be
able to connect to the register, even though some HTML elements might be misplaced
and some JavaScript user interface not working. The risk register is agnostic to the
client operating system and does not manipulate any files on the client connecting
to the register.
No mobile browsers are supported, due to screen size and possible security
limitations (or lack of security configuration, updates including certificate revocation
in some mobile devices), although the default template is responsive and will scale
well on small screens.
The user interface leverages functions and scaffolding provided by jQuery JavaScript
library version 1.8.2 and Twitter Bootstrap CSS framework version 2.1.1.
6.3
Possible software issues
There are no known issues within the default risk register. Some of the technologies
may lead to inconsistencies in the data for example, PostgreSQL has much more
stringent enforcement of SQL database standards, while SQLite or MySQL (other
Django backends) allow modifying data in unfortunate ways. Import of data from
a perfectly running instance of SQLite to PostgreSQL might in some cases lead to
integrity errors especially if data in the SQLite database has been modified manually.
To prevent corruption, data in the register is stored in JSON format and imported
by Django through syncdb command. During data import, it is run through the
Django model machinery, as opposed to direct SQL dump of a database, that
would be safe only if imported into the same database engine.
Unicode strings require careful manipulation; while Python and Django support
Unicode, the underlying platform may not10 . The author discourages running the
register on platforms that are not recommended in section 6.1.
Django employs an ORM object relationship mapper layer between instances
of classes (models in Django) and the database. This poses certain challenges with
class inheritance and the author sometimes had to compromise between theoretically
clean design and practical database performance.
While the author prefers to reuse code as much as possible, sometimes a component
in the register was developed from scratch if existing components and plugins did
not seem to be up to date.
9
Including for example Internet Explorer 7.

Leading to Unicode string comparison errors, for example in Python in the Cygwin environment
on Microsoft Windows XP.
10
49
Certain items in the register are implemented in a way that simplifies development
but might be considered against best practices. One case is the choice option on
certain fields, where one or two characters would suffice as key in the (key, value)
tuple. However, the author has opted to use much longer key (up to 20 characters) as
he believes that the performance impact on database is miniscule, while the impact
of using keys unreadable to humans during development and deployment would cost
much more.
Chapter 7
Risk register implementation
In general, the risk register supports COBIT 5 APO12 process. A partial highlevel data flow diagram of APO12 can be found in Figure E.1; it is based on
COBIT 5 (derived from section B.7) and the register only supports APO12.01
through APO12.04. The processes that will be supported in the register are shown
in blue. Any external actors (processes) not directly supported within the register
are shown in rectangles.
7.1
Risk register components
From the high-level diagram and theoretical requirements in chapter 2, the author
has created an ER diagram of basic risk register entities. Several entities are omitted
(any entities related to either logs, user accounts or essentially non-relevant items
such as file storage). Also, certain entities that are implemented as static variables
are described in a way that deviates from the Chen ER notation. The purpose of the
deviation is to simplify the diagram, make it easier to understand the modification
of the notations allows us to both describe certain important entities (for example,
ACTOR, EVENT,...) yet not to clutter the diagram.
Each entity in the diagram corresponds to a Django model (Python class),
hence the camel notation name. Many-to-many intermediate entities (tables in the
database representation) are not included unless they contain additional information
(AssetRelation).
7. Risk register implementation
51
Figure 7.1: Risk register ER (entity-relationship) diagram
Source: author; extended Chen notation static variables marked as rectangles with double vertical
lines.
Despite the fact that the diagram is focused toward the technical implementation,
it also describes the risk register as complex system. A full scale class diagram is
included as Figure E.2 in Appendix E.
7.1.1
Userinterface and tests
While the user interface of the risk register would warrant a detailed analysis too,
the author believes that the implementing company will customize it during roll-out.
The same applies to tests where possible, the author implemented automatic unit
tests in the code. However, any integration or interface tests would have to be
redefined and repeated during the customization and therefore were not formalized
in the thesis.
The following section of the thesis contains information on individual parts
entities within the register, their default values and technical implementation. Due
52
to continuity of the text, the reader who is unfamiliar with Django is kindly asked to
skip to section 7.3, especially to the text about configuration files in subsection 7.3.1
and return back after becoming familiar with the material.
7.2
Risk register models
All models1 inherit from models.Model. The author has opted not to use any custom
layers between Django and the risk register such as object history 2
7.2.1
Assets
All assets are represented by the Asset model in asset/models.py. The risk register
implements four types of assets to support COBIT 5 goal cascade (see Figure 2.4).
While it might be confusing to store both goals and assets in one type of
object, the author believes that at a high-level view, there is no difference between
goal, process and asset (as an accounting term) and the term asset can be used to
encompass them all. The cascade is fully customizable, but certain templates will
require changes (mainly the asset/tree.html template tailored to COBIT 5).
Figure 7.2: Asset types
Enterprise goal
IT-related goal
Process (enabler goal)
Resource
Source: author; config/50 app defaults.conf, ASSET TYPES ; based on COBIT 5.
The field failure text contains the mapping between COBIT 5 enterprise goals
and Risk IT business impacts (see Appendix A) for asset type Enterprise goal.
Any Asset model can have relations to multiple other Assets (either as a parent
or a child) and the relationship captures additional data (in AssetRelation). The
default implementation only supports expressing the relationship as a binary value
(field importance in AssetRelation), meaning that the child assets can be marked
either as primary or secondary. Changing the relationship to a discreet range (see
subsection 2.1.3) is possible; however, the author opted not to implement such system
1
Django terminology; essentially a Python class with an underlying ORM mapper that allows
permanent storage transparent to the programmer.
2
http://code.google.com/p/fullhistory/ (last retrieved June 10, 2012).
53
the analysis needed to define the relationships would be beyond the scope of this
thesis.
The risk register doesnt track changes to Asset objects. The author has contemplated tracking asset relationships in time, for example allowing to display how a
current risk register affects a goal cascade from two years ago. However, such change
would add two layers of complexity to the register both tracking history for the
goal (asset) cascade and tracking historical relationships. From a purely business
point of view, tracking past goals can serve for performance review, but its more
valuable to know whats know (which means current, not past goals).
This fairly simplistic asset model allows representing most possible relationships.
Also, assets can be disabled (field is active set to false); it is probable that no single
company would be able to try to fulfill all COBIT 5 BSC goals.
Default values are pre-populated from COBIT 5 (assets, relationships, primary
or secondary values) and Risk IT (failure texts).
7.2.2
Impacts
Possible impact scales of risk3 are represented in the Frequency and Impact objects,
which correspond to subsection 3.1.6 and subsection 3.1.7 respectively. Maximum
number of levels is defined in config/50 app defaults.conf, variable SCALES so it
can be easily altered. The default frequency in the register is as follows:
Frequency Rating
Times occurring per year
Rationale
< 0; 0.1) events per year
< 0.1; 1) events per year
2
3
4
5
< 1; 12) events per year

< 365; 1000000) events per years
Improbable events, unlikely

natural disasters, ...
The event took place over a
company lifetime.
Up to once a month.
Up to once every week.
Almost every day.
Multiple events per day.
Source: author.
Table 7.1: Frequency scales

The scale probably wouldnt require many changes in a realistic deployed register
unless the organization wants to focus more on planning events in the future rather
than day-to-day operations. The user is free to input any frequency (freeform
field), and the register itself then selects appropriate Frequency instances and sets
the relationship. This allows the user to change frequency values, reassign new levels
3
Stored in RiskEntry model, described later.
54
and yet no information is lost in the process. One risk is expected to have only one
frequency assigned and frequencies are limited (on a database level) to one per level.
The impact of events (incidents) is much more complicated. The author expects
heavy customization of possible impacts, probably even adding new categories of
impact. This is especially important for companies with specific strategy. Consider
a business with low-cost market positioning (e.g. fast food chains), where lower
customer satisfaction is of a lesser concern that in case of high-end luxury goods
producer. The same applies to press coverage in case of some companies, any press
coverage might be considered beneficial, yet the risk register considers press coverage
as negative impact.
The default register contains the following categories (stored in constant IMPACT AREAS in conf/50 app defaults.conf :
Figure 7.3: Impact categories
Competitive advantage market share loss (Risk IT)
Productivity loss of man-days (Risk IT)
Cost of response (Risk IT)
Reputation - external perception (Risk IT)
Legal regulatory compliance (Risk IT)
Loss of management focus (BITS GAP)
Quality change (PMBOK)
Scope change (PMBOK)
Cost increase (PMBOK)
Delivery date change (PMBOK)
Source: author; categories are based on [21, pg. 38] (Risk IT), [1, pg. 281] (PMBOK) and [5]
(BITS GAP).
Project impact categories (PMBOK) are in the register but are not populated.
The author deems that using all categories within one risk register would clutter the
data with unnecessary details unless it would be used to track significant projects.
Also, the project categories work as an extension of Risk IT categories. The reasoning
is simple one impact (e.g. Delivery date change of 30 days) in two projects can
have very different results for the organization. Postponing a long-term project
with enough leeway, such as migration to a newer version of software product on
workstations, would probably have very little impact. On the other hand, postponing
a Sarbannes-Oxley compliance project when the company is preparing for an initial
public offering (IPO) by a month could ruin the whole IPO. To capture the impact
55
of postponing the project, Delivery date change would not be enough unless used in
combination with e.g. competitive advantage.
For an overviews of various levels in each category please see section D.2, Table D.1.
The author assigned Competitive advantage - marketshare loss and Reputation external perception levels as an educated guess; Legal - regulatory compliance come
from Risk IT Practicioners guide. Cost of response is individual for each organization,
its status4 and local settings5 . Productivity - loss of MD (man days) was designed
by the author to cover situations with less than one lost day, less than a week, two
weeks and one month (roughly 20 MD) intervals.
Impact versus asset models
One last problem remains the issue whether impacts are not identical with effects
of risk on assets. The author believes that there is distinction between the two.
Assets are more related to goals, processes and are covered by risk scenarios, while
impacts can capture smaller, more granular effects. Also, the direct effect of risk on,
for example, a process might be impossible to describe, whereas the user might know
that the risk will cause a loss of $10.000.
7.2.3
Risk treatment
Four types of risk treatment (avoidance, reduction, retention and transfer) were
implemented based on Figure 3.6. The treatment itself is split into two models in
risk/models.py: RiskTreatmentOption being a generic treatment (for example an
insurance contract) and RiskTreatment, describing the relationship between a generic
treatment and specific risk6 . Both models allow for attachments and neither can be
deleted7 to disable a risk treatment, one is required to update the valid until field.
Such approach reflects two requirements:
it displays how was something solved in the past,
it explicitly forces users to think in terms of time, meaning that any risk
treatment should always be reviewed in the future and is not valid forever.
4
For example, one might ponder that governmental organization would accept higher productivity
losses as a tradeoff to lower monetary loss. It doesnt need to generate any revenue (hence lower
issues with productivity), while even small direct financial costs could be critical due to increased
budget oversight.
5
Economic position of the country etc.
6
RiskTreatmentOption imagine a broad insurance contract; then RiskTreatment contains
specific information how the broad insurance contract treats risk in the RiskEntry object.
7
Removal is still possible from the admin interface.
56
RiskTreatment can also be employed to affect levels of risk directly through

fields effect frequency effect impact. These two options can seem to be relatively
controversial, as they are decoupled from the risk impacts and frequencies, so they
should be used carefully.
Risk controls might appear to be quite different from risk treatment but after
some consideration, controls can already be described with RiskTreatment models.
The key here is that there dont have to be any effects in RiskTreatmentOption. Then
any control used to prevent risk can be described within the reduce category and
any control used to detect risk within the retent or reduce8 category. With such
combination, it is possible to remove any existing confusion between RiskTreatment
and (now non-existent) Control models.
Each RiskEntry object (described in the following subsection) allows unlimited
amount of risk treatments (assigned RiskTreatmentOption objects). Effects of
RiskTreatment instances on RiskEntry objects is described in the following section;
the calculation is similar to effects of ElevatedRisk.
7.2.4
Risk, risk assessment and risk scenario
The risk itself is mirrored by the RiskEntry model, which links together impacts and
frequency, risk treatments, risk scenarios and risk analysis. The class has only a
few required fields, to allow capturing risk at early stages of risk analysis (ie. when
very little is known about the risk). The risk is always relevant for a certain period,
never without an end date to force regular reassessments. To cover proximity of
risk (see subsection 3.1.6, also Prince 2: [17, pg. 387]) another model is introduced
ElevatedRisk. It can express situations where a standard, existing risk (such as
DDoS attack on key infrastructure9 ) will be elevated beyond the normal level. For
example, during Christmas, ability of an e-commerce company to withstand such
attack would be very limited due to increased number of shoppers, and the attack
would also cause higher losses10 .
ElevatedRisk effect on Risk is computed by first calculating root mean square of
risk impacts and then adding average of values from effect impact fields of related
ElevatedRisk instances. For frequency, average of ElevatedRisk fields effect frequency
is calculated as avg f req. Then, instance of Frequency with level in the interval
< avg f req 1; avg f req + 1) is selected; the engine establishes the f requency value
from the level as (upper times per interval lower times per interval)/2 and adds
8
If it reduces risk.
Or for example floods during certain months and under certain meteorological circumstances.
10
A similar example is a government site(s) during a time when certain legislation is prepared
most notably, the ACTA (Anti-Counterfeiting Trade Agreement).
9
57
it to existing number in field frequency value in the Risk instance. By default, only
currently valid ElevatedRisk instances affect risk (that is, historical and future values
are discounted)11 . The author acknowledges that the resulting values may not fully
represent reality however, they provide some aggregated information.
Both models allow for attachments the author expects the organization to reuse
common detailed templates that have far more information to be retained than, no
matter how detailed, model in the register.
Risk models are linked to RiskAssessment a fairly limited model used to capture
merely information about a risk assessment taking place and assessed risks. It is
not the goal of the risk register in the thesis to support whole risk assessment
processes, however, this model allows us to capture the relationship. Specifically,
one can analyze which valid risks havent been covered by recent risk assessments.
The author believes that this part of the register could be significantly expanded
by adding a model with company structure (for example departments). One than
could manage a relationship between assets (goals, processes) and scopes of the risk
analysis.
Linking risk assessment and risk provides additional data, as risk assessment
(analysis) should not be an individual, separate act for each risk.
A separate model RiskScenario stores risk scenarios, with links to RiskEntry and
Assets. Risk scenarios are based on generic scenarios from [21, pg. 59 - 68]; however,
certain fields were simplified by the author, for example actor allows only one value
(instead of both internal and external ). Such limitation is merely a simplification,
one can add numerous possibilities in conf/50 app defaults.conf.
Figure 7.4: Default risk scenario values
Actor: internal, external
Threat types: failure, malicious, accidental, natural
Events: ineffective execution, ineffective design, regulation, theft, destruction, inappropriate use, modification, interruption
Timing: non-critical, critical, unknown
Duration: short, moderate, extended, unknown
Detection: instant, moderate, slow
Source: conf/50 app defaults.conf, based on [21, pg. 59 - 68].
The dependencies between risk scenarios and assets (processes in this case) come
11
Even though displaying future values could be useful, it would pose a rather complicated task.
Multiple ElevatedRisk will exist in the future at different points of time. This means that for
example the resulting risk map would have to include another axis (the time element).
58
from section B.6. The mapping is based on [21, pg. 69 and following] but it was
adapted by the author from CobiT 4.1 to COBIT 5.
The assignment of frequencies and impacts to risk is random. The rationale
for random assignment is the need for data in the register and without proper risk
analysis, any data would be meaningless. Random assignment also removes any
possible bias of the author and allows for more rigorous checking of risk register
output. Basic rules were:
one in six risks has no impacts assigned,
one in six risks has no frequency assigned,
remaining risks have from one to four impacts from each impact area.
The full code is available in asset/views.py.
There are two ways that might be used to populate RiskEntries and RiskScenarios
top-down, by making more and more detailed risk scenarios based on the default
generic ones, and then creating risks from the scenarios, or bottom-up, by first
creating ad-hoc risks and then devising plausible scenarios. Both ways are equally
valid (see figures in subsection 3.1.9).
7.3
Notes on implementation
The following section contains several implementation notes that describe the inner
processes in the risk register.
7.3.1
Django customization and configuration files
The author has extended the standard configuration file settings.py with a simple
layout of several configuration files in the conf directory. Files are loaded in numbered
order (50 would be loaded before 55 ), so it is advisable to override default variables,
rather than change them. Most of the files are not important to the risk register and
their purpose is included at the top of the file in comments. The format is standard
Python, as files are executed on load.
59
Figure 7.5: Configuration files layout

00 deployment.conf: Variables enabling the debug environment, email notifications
for administrators.
50 app defaults.conf: Default variables for various objects in the register.
80 site custom.conf: Variables relevant to the organization running the register like
name, email address, ...
Source: author.
7.3.2
User rights checks
By default, Django generates add, change and delete permissions for all objects.
All relevant models in the register also have an additional permission access. The
structure of the permission string is module.action model ; the permission model is
binary and supports only either allowing and disallowing access to all objects of a
model. Permissions except for access are implemented and checked in the Django
admin interface too.
Permissions are enforced at the level of views by using a mixin PermissionRequiredMixin within class-based views SecCreateView, SecUpdateView, SecDetailView,
SecDeleteView SecListView (with parent classes being the default Django DeleteView,
UpdateView, CreateView, ListView, DetailView respectively).
Figure 7.6: Permission check in views PermissionRequiredMixin
1 In views . py :
2 class P e r m i s s i o n R e q u i r e d M i x i n ( object ) :
3
( ...)
4
def dispatch ( self , request , * args , * * kwargs ) :
5
permission = " % ( app ) s .% ( action ) s_ % ( model ) s " % { " app " : self .
model . _meta . app_label ,
6
" model " : str (
self . model .
__name__ ) .
lower ( ) ,
7
" action " : self .
action }
8
( ...)
9
# The p e r m i s s i o n check :
10
if request . user . has_perm ( permission ) or request . user .
11
is_superuser :
12
return super ( PermissionRequiredMixin , self ) . dispatch (
13
request , * args , * * kwargs )
14
( ...)
15
raise P e r m i s s i o n D e n i ed ( " User does not have permission : % s " %
permission )
16
17 class SecUpdateView ( ( ...) , PermissionRequiredMixin , UpdateView ) :
18
action = " change "
Source: author; general tools/views.py, simplified. Note the superuser permission.
60
One can then enforce user rights with generic views using a code as simple as the
following excerpt:
Figure 7.7: Permission check in views urls.py
1 urlpatterns = patterns ( ' ' ,
2
url ( r '^ items / ( ?P < pk > ( [ \ d ] ) + ) / update / $ ' , SecUpdateView . as_view ( model
= Asset , template_name = ' object / object_form . html ') , name = ' asset update ') ,
3 )
Source: author; simplified example. If the risk register gets a request matching regular expression, it
passes object private key (pk), object class Asset and template where the object should be rendered.
In SecUpdateView, the data is manipulated in completely generic way, no matter which object and
where is displayed.
The implementation means that access to all objects within the register is
centralized and can be verified. No standard access apart from generic views exists.
Also, if needed, a REST (or XML) API can use the same implementation by inheriting
from for example SecCreateView and overriding methods of CreateView without ever
altering the permission system. A similar view (OwnershipRequiredMixin) enforces
access rights by checking either a permission to access (edit, delete,...) the object or
whether the user is owner of the object, albeit the view is not used in the register
apart from access to user profiles.
Assignment of user rights is based on Django groups. Overview of existing groups
and assigned permissions is in Table D.2 and Table D.3.User permissions can also be
altered with two Django flags: Staff status allows access to Django admin (and thus
display access to all models) and Superuser status overrides any permission checks
in the register.
7.3.3
Audit trail (logs)
All logging is performed in the log module; logs are stored in LogItem class instances.
There are several details that are worth a closer look.
The time of the event is based on the moment when the LogItem model is saved
in Django (or rather when the parent models.Model save() method is called). This
decision is based both on the ease of implementation (auto now add=True in the field
definition) and the reality of timely capturing the exact time of the event, especially
with respect to multiple abstraction layers in Django.
Also, as the instance is stored in the same database as the risk register itself, the
implementation could lead to loss of audit logs if the database is corrupted. However,
it is trivial to override the save() method and store log events at multiple places
(database, flat file, remote server via rsyslog, ...)
61
Five events are logged:

HTTP request: The event is captured in the LogRequestMiddleware, which runs
after Session and Authentication middleware12 . The author has contemplated
placing it as the first middleware for the request but such position would
prohibit the register from capturing user names (the fields in request variable
are not yet populated at that moment). IP address, username, type of request
and request path is captured; requests for files (e.g. CSS, images) are not
logged13 . The other possibility, listening to django.core.signals.request started
is not practical either, as this signal doesnt even have the request variable
populated.
Login, logout: In log/signals.py, the register waits for django.contrib.auth module
signal user logged in (and user logged out); the register stores IP addresses and
usernames.
Attempted login: The register tracks login attempts in LogRequestMiddleware, although the result of the attempt is not stored anywhere. As the author has
already suggested, the user is urged to customize the authentication against a
centralized solution.
Exceptions: Request exceptions are stored through standard Django signal got request exception
listener in log/signals.py including the full request data and variables provided
by Django. This should not lead to large amounts of data if for example the
register front end contains links to missing content, because static content will
not be processed by Django at all.
View,edit and delete events on models: PermissionRequiredMixin and OwnershipRequiredMixin respectively provide all logging if the calling view uses the mixin; not
using the mixin should be considered a severe design violation, as it shortcuts
permission checks too. The register stores views and changes to objects (including creation and deletion), even for super users. However, changes from
the admin interface are still possible which should not affect security of the
solution as the admin should not have access to controlled risk register objects.
The author has considered logging from save() methods, but that solution
proved to be too complicated if multiple objects change and also due to Django
inheritance implementation14 .
12
The reader is kindly referred to Django documentation [10] at https://docs.djangoproject.

com/en/1.4/topics/http/middleware/ for details.
13
In the register, they can be logged at the webserver level.
14
Parent and child instances are rather problematic to differentiate.
62
The database stores only first 100 bytes of variables (e.g. request path) to prevent
certain attacks and save space. The following figure lists all event types (tuples in
the actual configuration file):
Constant
Description
REQUEST
EXCEPTION
LOGIN
LOGOUT
OBJECT
LOGIN TRY
HTTP request
Exception
User logged in
User logged out
Object changed
Attempted login
Source: author; config/50 app defaults.conf.
Table 7.2: Types of events

All logs stored in the database are immutable the model can be saved once
and only once, any attempt on editing LogItem will result in an exception. Such
design means that even if an attacker attempts to implement a backdoor in some
other module that changes logs, the attack will not succeed.
Figure 7.8: Immutable logs
1
2
3
4
def save ( self , force_update = False , force_insert = False ) :

if self . pk is not None :
raise P e r mi s s i o n D e n i e d ( " You are not allowed to edit log
objects " )
super ( LogItem , self ) . save ( force_update = False , force_insert =
False )
Source: author; log/models.py.
An additional logging scaffolding is in Log/signals.py. Disabled by default15 , it

allows logging any Django model change at an extremely low-level implementation,
hence even in the administration interface. Output can be redirected to for example
rsyslog.
7.3.4
Point of time view
The risk register contains a feature similar to a time machine. The user can set
the register to display values based on point of time. The risk register then filters
all objects in reasonable views based on the assumption that the date set by user is
15
See settings.LOG MODELS CHANGE in conf/10 app defaults.conf.
63
current date. This key feature allows users to understand how will the risk landscape
look in the future (and, to some extent, how it looked in the past16 ).
7.3.5
Test data in the register
The source of data is either explicitly mentioned (COBIT 5, Risk IT, a combination
of the two, other methodologies) or the data is randomly generated. Randomly
generated data includes RiskAssessment and RiskEntry instances. ElevatedRisks
and RiskTreatments were created manually.
7.4
Analytical views and data access
Most objects can be edited via the CRUD17 interface in the left menu, with one
exception deleting objects is not possible for any object from the risk module to
retain historical values and prevent any possible tampering.
There are numerous analytical views that help users understand data in the
register. The author must stress that the goal of the risk register is to store
structured data and capture relationships the goal is not to reproduce existing
software. Therefore, not all possible views were defined for detailed analysis of data,
the user will probably export relevant data and analyze them with either statistical
or common spreadsheet software.
7.4.1
Risk maps
Risk maps are based on suggestions from Risk IT, albeit with some differences. The
scale for frequency is logarithmic and uses exact frequency values (not levels) and
there is no colored band. The author first implemented a classic risk map with
ranges from green to red, however, with logarithmic scale, the color slightly loses its
meaning.
Two views were implemented by the author as an example (risks fitting in the
valid date range and a risk map including two representation of the same risks
treated and elevated and base forms18 ). The map could be expanded in numerous
ways, for example by allowing to limit the selection to a range of dates, years and
16
The past view is limited because the register doesnt contain a history layer for relationships.
Therefore, for example risk treatments are applied based on current date, not on the point of view
date, because there is no way of knowing whether they existed in the past and were related to the
risk entry in the past.
17
Create-Update-Delete.
18
That is, without taking into account values from ElevatedRisk and RiskTreatment instances.
64
so on. The generated image as well as data sheet can be downloaded as JPEG and
PNG images and CSV file.
7.4.2
Violations and top risks
To quickly assess exceptions in the register, users have the following views available:
Risks without risk assessment: all risks that have no risk assessment assigned. The
rationale is that while users can add ad-hoc risks and risk scenarios, they should
be included in a risk assessment as soon as possible.
Risks without impacts or frequency: again, risks that are not fully assessed, merely
detected.
Risks with other fields missing: view including all risks with some values missing.
Risk near expiry date: all risks that will expire in the next 90 days (based on point of
time).
The risk register also contains three top ten views top risks by aggregated
risk (frequency value and impact level multiplied), by aggregated impact level and
by aggregated frequency value.
7.4.3
Expected issues
Future elevated risks: two views that show new elevated risks that will start to exist,
and elevated risks that will continue to affect risks in the next year (based on
point of time).
To conclude the chapter, lets also note certain quirks of the register. User can
encounter edit links and buttons even though the user account has no permissions for
editing this is caused by using extremely generic views templates, where it is not
easily possible to know which object and object class is being displayed (the reader
is kindly referred to check templates/object/object detail.html file). In a realistic
scenario, all such links could be hidden by creating a new template tag to construct
a permission check with model class name.
7.5
Chapter summary
The author has described all important risk register classes (models in Django),
especially the implementation of COBIT 5 goal cascade through an asset tree and
65
models Asset and AssetRelation, impact scales and their source data and the extent
of inclusion of project management impacts from PMBOK, and risk treatments.
A significant portion of the text explores models related to risk entries and risk
scenarios; the highlights are the mapping between COBIT 5 goals (processes) and
Risk IT risks, various calculations withing the RiskEntry model and RiskScenario
values for actors, threats, events, timing, duration and detection.
The second part of the chapter focused on the inner working of the register around
models. The structure of configuration files and their loading order was defined, and
the author spent some time detailing how user rights are enforced within the risk
register and how can such checks be extended. The reader could also get familiar
with audit trails available in the register and their limitations. Last but not least was
the point of time feature of the risk register and various analytical views available to
the user. To name a few, the text presented different risk maps, views detailing risk
register violations (such as risks without assigned frequencies), views with expected
issues (future risks) and top charts (for example, top risks by aggregated impact
level).
For more detailed documentation, the reader is kindly referred to risk register
source code and docstrings or the (slightly cumbersome) automatically generated
EpyDoc code overview.
The thesis continues with the implementation notes and user quick-start manual.
Chapter 8
Customizing, deploying and using the
register
The following chapter documents selected activities required to deploy and maintain
the IT risk register (the user manual). It also contains a generic quick-start guide
detailing basic workflow in the register. The author deems hints and help spread
throughout the application to be far superior to any separate manual, so detailed
descriptions of models, their fields and meaning of views are part of the application.
The chapter is not a replacement for a full-fledged risk management methodology
customized to the needs of individual organization that should always be always
accompanying every implementation of the risk register.
All customizations and the process of customization must be documented.
8.1
Hardware and software requirements
General software requirements should be derived from section 6.1. As for the hardware
platform, there is no specific requirement as long as it can run a supported operating
system and related programs. The author recommends using servers with at least
dual-core x86-64 CPUs with clocks above 1.5 GHz and 4 GB RAM during periodic
risk assessments. Outside peak periods, the risk register could run on a virtual server
as long as it has enough dedicated RAM (2 GB would be a minimum).
The tried and tested software stack is as follows:
Apache 2.2,
PostgreSQL version 9.1,
Debian (wheezy),
Python 2.7,
8. Customizing, deploying and using the register
67
Django 1.4.
The author strongly discourages using versions of Python other than 2.6 or 2.7,
experimental Apache 2 servers (for example tk or mpm due to Python global lock)
or MySQL due to possible integrity issues. PostgreSQL can be easily substituted for
Oracle databases by a simple configuration change.
8.2
Information security
Each user may be assigned a basic user group and additional user groups (granting
privileges, for example to access items related to specific project); individual user
rights should not be assigned unless completely necessary.
The following criteria should be meet within the organization during implementation and should be treated as a checklist. However, the checklist is not a
substitute for an information security policy. The goal of the list is to relate ISO/IEC
27002:2005 controls to the risk register implementation from the point of view of
the implementing organization. There is no doubt that there are more controls that
could and should be used, but the the author tried to select a minimal list.
68
ISO/IEC Requirement
27002:2005
section
reference
10.1.1
6.1.3
Document the whole implementation process of the register; document operations of

the risk register throughout the lifecycle.
Assign responsibility for:
maintaining security profiles and user accounts in the register,
securing risk register hardware (server),
maintaining risk register application software (server software including operating system and vendor updates),
creating a security profile of the hardware and software running the risk
register.
6.1.5
6.1.5
6.2
6.2.3
7.2.2
8.1.1
8.2.2
8.3.3
9
10.1.2
10.1.3
10.2
10.4.1
10.4.1
10.4.1
10.5
10.5
10.7.4
10.10.6
10.10.1
10.10.1
10.10.1
12.3.2
12.4
Require all personnel maintaining the risk register must accept a non-disclosure
agreement.
Establish a process for reporting and evaluating unauthorized information disclosure.
Examine external parties controls from ISO/IEC 27002.
Review control 6.2.3 Addressing security in third party agreements and apply if
critical parts of the risk register are outsourced or shared (such as if a server is
placed in shared rack).
Create an information labeling policy and accordingly assign user groups in the
register.
Create and assign security groups and responsibilities according to a predefined
information security policy.
Ensure that all users of both the risk register and its outputs must have an appropriate
information security awareness and receive training.
Access rights to the register must be modified when the user changes his or her role
in the organization (including contract termination).
Consider reviewing physical security controls.
Document any changes to the risk register configuration.
Maintain two men policy for all configuration changes.
Monitor third party service delivery management.
Check for malicious code after customizing the risk register user interface.
Establish and enforce policy about the type of documents that can be uploaded to
the risk register.
Secure client stations accessing the risk register.
Set up frequent automatic encrypted risk register backups including logs and regularly
test risk register full recovery from a backup.
Establish a backup procedure that preserves the last state of the register before
backup for forensic investigation.
Prevent unauthorized access to risk register documentation.
Setup automatic server system clock synchronization.
Periodically review risk register logs; analyze changes that might have been performed
to cover illicit activities.
Periodically review server logs.
Monitor, log and analyze changes to system configuration, use of system utilities and
applications, activation and de-activation of protection systems, such as anti-virus
systems and intrusion detection systems[13, pg. 55].
Properly manage risk register server SSL certificates.
Adhere to 12.4 Security of system.
Source: author; based on [13].
Table 8.1: General security requirements
69
The following tasks must be accomplished when the risk register is installed.
Item
Procedure
Database password
User accounts
Configuration
item
tings.SECRET KEY
Django admin
Change default database user password.

Change default administrators password.
Generate a new random string upon installation.
Disable the administration interface in the
production environment via urls.py.
Set all values to false.
set-
Configuration
file
settings/00 deployment.conf
Source: author.
Table 8.2: IT Risk register installation

As a general rule, the register should be accessible from the company intranet
only.
8.2.1
Responsibility
General risk management duties should be based on Figure 2.11. Responsibilities

within the register should comply with Figure 3.1 (Risk IT RACI chart), however,
the extent of the documentation of responsibilities, as well as checks that ensure their
fulfillment are definitely out of the scope and should be designed and implemented
based on a broader approach of the company to IT risk management.
The author suggests that there should be at least some segregation of duties
not only for review, but to also provide an independent view, fresh ideas and sanity
checks.
8.3
COBIT 5 customization
The organization deploying the register must customize the default settings based
on COBIT 5 to its own needs. Several specific areas should be adapted. The register
might be used without implementing COBIT 5 itself, however, the author believes
that it is beneficial if the organization at least considers and uses most COBIT
principles.
8.3.1
Goal cascade
As [7, pg. 20] mentions, the default cascade may not be aligned with actual enterprise
goals and should be modified according to enterprise (or industry) size and goals.
70
The priority of goals is set to 0 (primary) and 1 (secondary) by default the user is
strongly suggested to redefine the range and or at least modify the values.
The recommended customization procedure based on [7, pg. 20-21] is as follows:
1. define enterprise goals,
2. select key enterprise goal (e.g. customer satisfaction),
3. raise priority of the related enterprise goals (e.g. 6. Customer-oriented service
culture, 7. Business service continuity and availability),
4. analyze related IT goals based on the mapping, select relevant goals,
5. adjust risk register weights accordingly.
The default data comes from Figure 22 in [7, pg. 50] (Mapping COBIT 5
Enterprise Goals to IT-related Goals). The goal cascade can be customized either
through the Django interface (Asset, AssetRelation models) or in the risk register
interface itself.
8.3.2
User rights and access
The simplified user access defined in Table 4.2 is unsuitable for all except the most
simplistic production environments. It is imperative to define new user groups during
the customization of the register. A preferable way to accomplish separation of duties
is to create a matrix based on Figure 2.11 user categories and to define responsibilities
and permissions for each category of users. Document user access policy according to
11.1.1 Access control policy in ISO/IEC 27002:2005. As a general rule, users should
have exactly the rights they need to perform their documented and assigned duties
in the register. Duties and rights (groups) must be periodically reviewed, especially
if the risk register does not use a company-wide centralized database to prevent
leavers or users who moved to another position from accessing it.
Document assigning and revoking rights in the register. Also, establish a policy
that requires all users to have assigned individual groups to access data in the register
to prevent users from sharing one account1 .
8.3.3
Impact and frequency scales
Assess and modify impact and frequency scales (models Impact, Frequency, also
constant IMPACT AREAS in conf/50 app defaults.conf ). Redefine impact levels to
1
A useful control is to review whether a user is not logging again and again from different IP
addresses (machines) within the organization.
71
company needs and risk thresholds. Update descriptions of impacts to local legal
and regulatory landscape, as well as financial impacts.
8.3.4
Risk scenarios
Adapt generic risk scenarios in the register and develop your own.
8.4
User manual quickstart
The general input and usage of data should follow workflow suggested in Risk IT
risk analysis (see Figure B.8). Detailed descriptions of each field is in the templates
of the register.
As an example, the author would like to present common workflow for new risk
assessment:
1. create new risk analysis object,
2. verify that the goal cascade is adequate,
3. create new risk scenarios as appropriate,
4. update and extend risk scenarios, link to risk assessment,
5. create risk entries for scenarios, estimating frequencies and impacts throughout
the risk analysis process,
6. add new risk treatments, reevealute existing risk treatments,
7. analyze risks in the register,
8. assign risk treatments.
To quickly test the risk register, run the VirtualBox virtual machine from the
attached DVD (user rr, password letmein).
8.4.1
Less visible features
There are several features that can be missed during quick exploration. The reader
should try using the point of time display (at the top of the screen) and logging in as
different users. To test permissions, one can manually alter the URL for example,
with auditors account, the URL /risk/scenario/items/add/ will display permission
error and /risk/scenario/items/0/delete/ will explain why its not possible to edit
objects at all.
8.5
72
Possible uses of the risk register
The risk register produced as the result of this thesis is by no means a piece of software
that would be commercially viable (sold as a complete product). Despite lacking
the polish of packaged solutions2 , the author believes that the risk register can be
successfully used as an internally in small to medium organizations to accomplish
various tasks.
The obvious role of the risk register in the organization is as a complete risk
register. This can be accomplished by uploading older data and templates, as most
objects in the register support file attachments. The organization could then both
retain older data and established processes, and add additional value tracking of
relationships between objects in the register.
The software can also be used in a completely opposite way: as a quick, free-form
storage of relatively unstructured information during and ad-hoc risk analysis or
high-level risk assessments (most quantitative fields in forms are not mandatory).
The web-based nature of the register allows quick cooperation of multiple users, with
updates instantly available after submitting changes, and with data segregated at an
object level3 . The relationship then could be used to track objects that need deeper
analysis and assessments.
Of course, it can be customized and serve in roles between these two extremes.
The risk register nicely fills a void between unstructured flat files (such as multiple
spreadsheets in common office software) that cannot track relationships across
elements in the organizations risk (eco)system and full commercial solutions4 . The
focus of the register on assets as processes, rather than assets as individual items
for example workstations could help the organization to store and manipulate data
from a relatively exact, yet still fast risk analysis, and from that analysis, to define
requirements5 , expectations and budget for a further, deeper risk assessment.
2
Which should not be expected of any academic software, keeping in mind that the last 20 %
of product functionality (the polish) would probably take 80 % of the resources.
3
Albeit there is no editing lock in the register, so the users would have to agree on some
separation.
4
Or freely available risk registers under various licences.
5
Including risk register requirements.
Chapter 9
Conclusion
The author has analyzed several key risk management best practices COBIT 5, Risk
IT, BITS GAP and other methodologies (namely PMBOK) in relation to information
technology risk management. The analysis provided a basic set of ideas that allowed
implementing a model of an IT risk register based on Django web framework and
Python programming language. The goals of the thesis were achieved by the author
at a level and extent reasonable for a masters thesis. It proved to be possible to
create a risk register with goal mapping between COBIT 5 and Risk IT, to update
certain Risk IT parts to complement COBIT 5 instead of CobiT 4.1 and to even
include ideas from project management methodologies. However, it became clear
that fully supporting project risk management within a register focused on COBIT
5 processes and structures would prove to require a much more extensive analysis
and research.
The contribution of the author was twofold. In the theoretical part, an analysis
and synthesis of multiple methodologies and mapping of at first sight incompatible
texts provide a basis for the risk register, and in itself, contains original work of
the author. However, the theoretical part of the thesis also served as an important
stepping stone for the practical part. In the practical part, the implementation of the
IT risk register, albeit only of an exploratory version, builds on top of the theoretical
foundations of the analysis. The resulting risk register is complemented with basic
default data, user groups assignment and extensible design that approaches the
problem based on interactions and relationships of individual elements in the register
as a system, rather than from a perspective of a plain data storage. The resulting IT
risk register is also accompanied with a thorough set of configuration scripts, reusable
source code, deployment checklist and a security-conscious centralized approach to
user permissions.
Especially due to the breadth of the field of IT risk management, there are several
possible areas where the thesis could be extended in the future. A further study
9. Conclusion
74
might focus on the methodology aspect that is, extending the connection to project
management risk and implementing newer methodologies (which could be considered
a shortcoming of the thesis, in terms of substituting Risk IT for the yet to be released
part of COBIT 5).
The practical aspect extending the risk register would mean implementing
a new authentication backend, testing the register by using it through a realistic
risk analysis. Then, based on real-world results, views of data could be tailored
to specific needs of a selected organization. Within the register, several possible
features could greatly improve the functionality: fuzzy matching of risk and dates
would provide improved data for users, and a history layer and import of data
from for example intrusion detection systems would allow creating new data mining
features. However, the author has to stress that such features are well beyond any
possible and meaningful extent of this thesis, just by the sheer amount of time and
length of text necessary to design and implement such extended features.
Bibliography
[1] A Guide To The Project Management Body of Knowledge (PMBOK Guide).
Fourth Edition. Newtown Square, PA, USA: Project Management Institute, 2008.
ISBN 978-1-933890-51-7.
[2] ADAMS, J.: RISKY BUSINESS: The Management of Risk and Uncertainty.
London: Adam Smith Institute, 1999. ISBN 1-902737-06-7.
[3] Apache HTTP Server Version 2.2 Documentation [online]. Apache Software
Foundation [last retrieved September 21, 2012]. Available from: http://httpd.
apache.org/docs/2.2/.
[4] ALCHIN, M.: Pro Django. New York: Springer-Verlag New York, Inc., 2009.
ISBN 978-1-4302-1047-4.
[5] BITS Technology Risk Transfer Gap Analysis Tool [online]. BITS Role of Insurance in E-Commerce Risk Management Working Group, 2002 [last retrieved
December 8, 2012]. Available from: http://www.bits.org/publications/doc/
GapAnalysis0402.pdf.
[6] CobiT 4.1. Rolling Meadows, IL, USA: IT Governance Institute, 2007. ISBN
1-933284-72-2.
[7] COBIT 5 A Business Framework for the Governance and Management of
Enterprise IT. Rolling Meadows, IL, USA: ISACA, 2012. ISBN 978-1-60420-2373.
[8] COBIT 5 Enabling processes. Rolling Meadows, IL, USA: ISACA, 2012. ISBN
978-1-60420-241-0.
[9] CLARKSON, K. W., MILLER, R. L., CROSS, F. B.: Business Law: text and
cases. Twelfth edition. Mason, OH, USA: South-Western, Cengage Learning,
2012. ISBN 978-0-538-47082-7.
Bibliography
76
[10] Django documentation. Version 1.4. [online]. Django Software Foundation [last
retrieved December 8, 2012]. Available from: https://docs.djangoproject.
com/en/1.4/.
V.: R
zen bezpecnosti informac. Prvn
L., SVATA,
[11] DOUCEK, P., NOVAK,
vydan. Praha: Professional Publishing, 2008. ISBN 978-80-86946-88-7.
S., SEGER, J.: Statistika pro ekonomy. Pate vydan.
[12] HINDLS, R., HRONOVA,
Praha: Professional Publishing, 2004. ISBN 80-86419-59-2.
[13] ISO/IEC 27002:2005. Information technology Security techniques Code of
practice for information security management. Geneva: International Standards
Organization, 2005.
[14] ISO/IEC 27005:2011. Information technology Security techniques Information security risk management (second edition). ISO/IEC 27005:2011, Geneva:
International Standards Organization, 2011.
[15] ISO/IEC 31000:2009. Risk management Principles and guidelines. Geneva:
International Standards Organization, 2009.
[16] Management of Risk Pocketbook. 2010 edition. London: Stationery Office, Office
of Government Commerce, 2010. ISBN 978-0113312986.
[17] Managing Successful Projects with PRINCE2. Fourth edition. London: Stationery Office, Office of Government Commerce, 2005. ISBN 0-11-330946-5.
[18] The evolving IT risk landscape: The why and how of IT Risk Management
today [online]. Ernst & Young (EYGM Limited), 2012 [last retrieved September
21, 2012]. Available from: http://www.ey.com/Publication/vwLUAssets/
The_evolving_IT_risk_landscape/$FILE/Insights%20on%20IT%20risks_
Evolving%20IT%20landscape_AU0886.pdf.
[19] The Orange Book: Management of Risk - Principles and Concepts. London:
HM Treasury, 2004. ISBN 1-84532-044-1.
[20] The Risk IT Framework. Rolling Meadows, IL, USA: ISACA, 2009. ISBN
978-1-60420-111-6.
[21] The Risk IT Practitioner Guide. Rolling Meadows, IL, USA: ISACA, 2009. ISBN
978-1-60420-116-1.
Appendix A
COBIT 5 risk mappings
The following table rewords COBIT enterprise (business in CobiT 4.1) goals (split
into BSC categories) in terms of business impacts, to better suit the risk register.
See Appendix A for a comparison of CobiT 4.1 and COBIT 5 in terms of goals.
Financial Perspective
Inadequate financial return on investment of IT-enabled business investments.
Inadequate products and services, not addressing customer needs, resulting in revenue loss.
IT-related risks not managed, leaving the company exposed.
Violation of regulations or contracts, resulting in legal fines/damages or personal legal consequences for board and executives.
Inadequate transparency for stakeholders, not meeting client expectations; lack of compliance.
Financial fraud, loss of goodwill.
Customer Perspective
Bad or insufficient customer service, resulting in client loss.
Inadequate service levels, resulting in customer dissatisfaction and potential revenue loss.
Inability to react to changing market or client requirements on a timely basis, resulting in
revenue loss.
Wrong strategic decisions on new business initiatives, resulting in client/revenue loss and
shareholder value.
Products or services brought to market at too high a price or inadequate profit margin,
potentially resulting in share value and client loss.
Internal Perspective
Inefficient and inadequate operations of the enterprise.
Lower profitability.
Inefficient and inadequate operations of the enterprise, resulting in loss of opportunities.
Inefficient and inadequate operations of the enterprise, resulting in compliance issues.
Inefficient and inadequate operations of the enterprise, resulting in inadequate productivity
and efficiency.
Learning and Growth Perspective
Inability to sustain growth or current operations.
Loss of opportunities, low growth, eroding market share.
Business Impact
Table A.1: Enterprise goals and business impact
Source: [21, pg. 42, figure 29]; the table has been modified by the author to incorporate COBIT 5 enterprise goals wording from [7, pg. 15, figure 5].
Skilled and motivated people

Product and business innovation culture
Optimisation of business process functionality

Optimisation of business process costs
Managed business change programmes
Compliance with internal policies
Operational and staff productivity
Optimisation of service delivery costs
Information-based strategic decision making
Customer-oriented service culture

Business service continuity and availability
Agile responses to a changing business environment
Improve corporate governance and transparency

Financial transparency
Stakeholder value of business investments

Portfolio of competitive products and services
Managed business risk (safeguarding of assets)
Compliance with external laws and regulations
Enterprise Goal
A. COBIT 5 risk mappings

II
COBIT 5 Enterprise Goal
III
CobiT 4.1 Business goals
Stakeholder value of business investments
Provide a desired return on investment of
IT-enabled business investments
Portfolio of competitive products and services Offer competitive products and services (in
customer perspective)
Managed business risk (safeguarding of as- Manage IT-related business risk
sets)
Compliance with external laws and regula- Provide compliance with external laws, regutions
lations and contracts (in internal perspective)
Improve corporate governance and transparency
Customer-oriented service culture
Improve customer orientation and service
Business service continuity and availability
Establish service continuity and availability
Agile responses to a changing business envi- Create agility in responding to changing busironment
ness requirements
Information-based strategic decision making Obtain reliable and useful information for
strategic decision making
Optimisation of service delivery costs
Achieve cost optimisation of service delivery
Optimisation of business process functional- Improve and maintain business process funcity
tionality
Optimisation of business process costs
Lower process costs
Managed business change programmes
Manage business change
Compliance with internal policies
Provide compliance with internal policies
Improve and maintain operational and staff
Operational and staff productivity
productivity
Acquire and maintain skilled and motivated
Skilled and motivated people
people
Product and business innovation culture
Manage product and business innovation
Source: [7, pg. 15, figure 5], [6, pg. 169], linked by the author.
Table A.2: COBIT 5 enterprise goals to CobiT 4.1 business goals

mapping
Compliance
Reliability
Table A.3: COBIT 5 business impacts to CobiT 4.1 information criteria mapping
Source: [21, pg. 44, figure 31]; the table has been modified and restructured by the author to suit COBIT 5 enterprise goals (Appendix A) rather than CobiT
4.1 business goals.
Loss of opportunities, low growth, eroding market share.
Inefficient and inadequate operations of the enterprise, resulting in inadequate productivity and
P
S
efficiency.
Inability to sustain growth or current operations.
P
S
Inefficient and inadequate operations of the enterprise, resulting in compliance issues.
P
S
Inefficient and inadequate operations of the enterprise, resulting in loss of opportunities.
Lower profitability.
Wrong strategic decisions on new business initiatives, resulting in client/revenue loss and shareholder value.
Inability to react to changing market or client requirements on a timely basis, resulting in revenue
loss.
Products or services brought to market at too high a price or inadequate profit margin, potentially resulting in share value and client loss.
Inefficient and inadequate operations of the enterprise.
P
Inadequate service levels, resulting in customer dissatisfaction and potential revenue loss.
Bad or insufficient customer service, resulting in client loss.
Inadequate transparency for stakeholders, not meeting client expectations; lack of compliance
P
P
Violation of regulations or contracts, resulting in legal fines/damages or personal legal consequences for board and executives.
Cobit Information Criteria

Confidentiality
Integrity
Availability
IT-related risks not managed, leaving the company exposed.
Inadequate products and services, not addressing customer needs, resulting in revenue loss.
Efficiency
P
Effectiveness
Inadequate financial return on investment of IT-enabled business investments.
Business Goals Consequence (Impact)

IV
Appendix B
COBIT and Risk IT materials
B.1
COBIT 5 Process capability attributes
0 Incomplete process The process is not implemented or fails to achieve its process
purpose. Little or no evidence of any systematic achievement of the process
purpose.
1 Performed process The implemented process achieves its process purpose.
2 Managed process The process is implemented in a managed fashion (planned,
monitored and adjusted) and its work products are appropriately established,
controlled and maintained.
3 Established process The process is implemented using a defined process that is
capable of achieving its process outcomes.
4 Predictable process The process operates within defined limits to achieve its
process outcomes.
5 Optimising process The process is continuously improved to meet relevant current
and projected business goals.
Source: [7, pg. 42]. Reworded by the author to be more explicit.
B.2
COBIT 5 processes
Figure B.1: COBIT 5 Process reference model
B. COBIT and Risk IT materials

VI
B.3
VII
COBIT 5 enablers
Principles, policies and frameworks are the vehicle to translate the desired
behaviour into practical guidance for day- to-day management.
Processes describe an organised set of practices and activities to achieve
certain objectives and produce a set of outputs in support of achieving overall
IT-related goals.
Organisational structures are the key decision-making entities in an enterprise.
Culture, ethics and behaviour of individuals and of the enterprise are
very often underestimated as a success factor in governance and management
activities.
Information is pervasive throughout any organisation and includes all information produced and used by the enterprise. Information is required for
keeping the organisation running and well governed, but at the operational
level, information is very often the key product of the enterprise itself.
Services, infrastructure and applications include the infrastructure, technology and applications that provide the enterprise with information technology
processing and services.
People, skills and competencies are linked to people and are required for
successful completion of all activities and for making correct decisions and
taking corrective actions.
B.4
CobiT 4.1 information criteria
To satisfy business objectives, information needs to conform to certain control

criteria, which COBIT refers to as business requirements for information. Based on
the broader quality, fiduciary and security requirements, seven distinct, certainly
overlapping, information criteria are defined as follows:
Effectiveness deals with information being relevant and pertinent to the
business process as well as being delivered in a timely, correct, consistent and
usable manner.
VIII
Efficiency concerns the provision of information through the optimal (most

productive and economical) use of resources.
Confidentiality concerns the protection of sensitive information from unauthorised disclosure.
Integrity relates to the accuracy and completeness of information as well as
to its validity in accordance with business values and expectations.
Availability relates to information being available when required by the
business process now and in the future. It also concerns the safeguarding of
necessary resources and associated capabilities.
Compliance deals with complying with the laws, regulations and contractual
arrangements to which the business process is subject, i.e., externally imposed
business criteria as well as internal policies.
Reliability relates to the provision of appropriate information for management
to operate the entity and exercise its fiduciary and governance responsibilities.
Source: [6, pg. 10, 11].
B.5
CobiT 4.1 IT resources
The IT organisation delivers against these goals by a clearly defined set of processes
that use people skills and technology infrastructure to run automated business
applications while leveraging business information. (...)
To respond to the business requirements for IT, the enterprise needs to invest in
the resources required to create an adequate technical capability (e.g., an enterprise
resource planning [ERP] system) to support a business capability (e.g., implementing
a supply chain) resulting in the desired outcome (e.g., increased sales and financial
benefits).
The IT resources identified in CobiT 4.1 can be defined as follows:
Applications are the automated user systems and manual procedures that
process the information.
Information is the data, in all their forms, input, processed and output by
the information systems in whatever form is used by the business.
Infrastructure is the technology and facilities (i.e., hardware, operating
systems, database management systems, networking, multimedia, and the
IX
environment that houses and supports them) that enable the processing of the
applications.
People are the personnel required to plan, organise, acquire, implement, deliver,
support, monitor and evaluate the information systems and services. They
may be internal, outsourced or contracted as required.
B.6
CobiT 4.1 to COBIT 5 process mapping

CobiT 4.1 process
COBIT 5 processes
ME4
ME1
ME3
ME2
DS8
DS9
DS6
DS7
DS4
DS5
DS2
DS3
DS1
DS10
DS11
DS12
DS13
PO8
PO9
PO6
PO7
PO4
PO5
PO2
PO3
PO1
PO10
AI5
AI4
AI7
AI6
AI1
AI3
AI2
EDM01, EDM02, EDM04, EDM03, MEA02

MEA01
MEA03
MEA02
DSS02
BAI10, DSS02
APO06
APO07
DSS04
APO13, DSS05, DSS02
APO10
BAI04
APO09
DSS03
DSS01, DSS04, DSS06, DSS05
DSS01, DSS05
DSS01, DSS05, BAI09
APO11
EDM03, APO01, APO12
APO01, EDM03
APO07, APO01
APO01, APO11, APO07
APO06, APO05
APO03, APO01
APO02, APO04, EDM01, APO03, APO01
EDM02, APO02, APO05
BAI01
BAI03, APO10
BAI05, BAI08
BAI05, BAI07
BAI06
BAI02
BAI03, DSS02
BAI03
Source: based on [8, pg. 217-222]; modified by the author to provide direct process to process
mapping instead of the original control objective to process mapping (including a fixed typo in
DSS001 instead of DSS01).
Table B.1: Mapping CobiT 4.1 processes to COBIT 5
B.7
COBIT 5 APO12 Manage Risk figures

Figure B.2: APO12.01 Collect data
Source: [8, pg. 108].
Figure B.3: APO12.02 Analyse risk
Source: [8, pg. 109].
Figure B.4: APO12.03 Maintain a risk profile
Source: [8, pg. 109].

Figure B.5: APO12.04 Articulate risk
Source: [8, pg. 110].
Figure B.6: APO12.05 Define a risk management action portfolio
Source: [8, pg. 110].
Figure B.7: APO12.06 Respond to risk
Source: [8, pg. 111].
XI
B.8
Risk IT Risk analysis

Figure B.8: Risk Analysis Flowchart
XII
Appendix C
Other figures
Figure C.1: PRINCE 2 processes and components
Source: [17, pg. 12, Figure 2.4]. Processes are withing the rectangle.
Figure C.2: Weakest link
Source: obligatory XKCD: http://xkcd.com/538/ (last retrieved November 17, 2012).
Appendix D
Relevant configuration excerpts
D.1
Apache2
Figure D.1: Relevant Apache 2 SSL configuration
1
2
3
4
SSLProtocol - all + TLSv 1 + SSLv 3

SSLC ipherSui te HIGH : MEDIUM : ! aNULL : + SHA 1 : + MD 5 : + HIGH : + MEDIUM
S S L C e r t i f i c a t e F i l e / etc / apache 2 / ssl / certApache 2 . pem
S S L C e r t i f i c a t e K e y F i l e / etc / apache 2 / ssl / key . pem
Source: author; Apache 2 configuration files.
The following excerpts present a configuration of the Apache 2 virtual host. Notes
on configuration specific to Django, mod wsgi or the risk register are included as
comments (prefixed with #).
Figure D.2: General virtual host configuration
1
2
3
4
5
6
7
8
9
10
11
< VirtualHost * : 8 0 >

ServerName
risk . company . int
ServerAdmin
r r e g i s t e r a d m i @ c o m p a n y . coim
DocumentRoot
/ home / www / risk . company . int /
< Directory / >
Options
AllowOverride
</ Directory >
Follo wSymLink s - Indexes

AuthConfig FileInfo Indexes Limit
SSLEngine on
D. Relevant configuration excerpts
Figure D.3: WSGI setup

1 # Python scripts are c o m p i l e d ( . pyc ) ; it is i m p o r t a n t to either reload
the server or edit the file w s g i _ h a n d l e r . py to force the
i n t e r p r e t e r to look for changes in source code ( . py ) .
2 W SG IS c ri pt Al i as / / home / www / risk . company . int / wsgi_handler . py
3
4 # r i s k r e g i s t e r is a system user and must exist as such ( / etc / passwd , /
etc / group ) . It is r e c o m m e n d e d to disable login by c h a n g i n g the
shell in / etc / passwd to e . g . / bin / false . S e p a r a t i n g WSGI scripts by
users allows better m o n i t o r i n g and user s e p a r a t i o n ( regular file
and d i r e c t o r y p e r m i s s i o n s apply ) ; compare to m o d _ p y t h o n or mod_php
for PHP scripts .
5 W S G I D a e m o n P r o c e s s riskregister user = riskregister group = riskregister
processes = 1 threads = 1 5
6 W S G I P r o c e s s G r ou p riskregister
Figure D.4: Django file access

1 # Regular scripts are p r o c e s s e d in the chain Apache 2 - m o d _ w s g i Python interpreter , which is fairly i n e f f i c e n t . The s t a n d a r d
p r o c e d u r e is to disable m o d _ w s g i for certain d i r e c t o r i e s and let
plain Apache 2 to serve media files ( images , CSS style sheets ,...)
to improve p e r f o r m a n c e and memory f o o t p r i n t .
2 Alias / site_media / / home / www / risk . company . int / media /
3 < Location / media >
4
SetHandler none
5
Order deny , allow
6
Allow from all
7 </ Location >
8
9 < Directory / home / www / risk . company . int / media / >
10
FileETag none
11
ExpiresActive On
12
Expi resDefau lt " access plus 4 weeks "
13
ExpiresByType image / gif A 2 5 9 2 0 0 0
14
ExpiresByType image / png A 2 5 9 2 0 0 0
15
ExpiresByType image / jpg A 2 5 9 2 0 0 0
16
ExpiresByType image / jpeg A 2 5 9 2 0 0 0
17 </ Directory >
18
19 < Location / media - admin >
20
SetHandler none
21
Order deny , allow
22
Allow from all
23
FileETag none
24
ExpiresActive On
25
Expi resDefau lt " access plus 1 0 years "
26 </ Location >
27
28 # Django c o n t a i n s a built - in web a d m i n i s t r a t i o n - - f r i e n d l y user
i n t e r f a c e to table editing . This alias makes its t e m p l a t e s
accessible .
29 Alias / media - admin / / usr / share / pyshared / django / contrib / admin / media /
30 < Directory / usr / share / pyshared / django / contrib / admin / media / >
31
SetHandler none
32
Order deny , allow
33
Allow from all
34 </ Directory >
XV

Figure D.5: Logging
1 # All logs should be rotated with s t a n d a r d l o g r o t a t e and a r c h i v e d for a
s u f f i c i e n t time .
2 ErrorLog
/ var / log / apache 2 / logs / rregister / error . log
3 LogLevel
warn
4
5 # Access log - - beyond a p p l i c a t i o n - - can be used to log any request
for any item in the r e g i s t e r for p o s i b b l e ( but extensive , and thus
also e x p e n s i v e ) audit a n a l y s i s . Please see Apache 2 d o c u m e n t a t i o n
for e x p l a n a t i o n of the log format .
6 LogFormat
" % h % l % u % t \"% r \" % > s % b \"% { Referer } i \" \"% { User Agent } i \" " combined
7 LogFormat
" % h % l % u % t \"% r \" % > s % b " common
8 LogFormat
" % { Referer } i - > % U " referer
9 LogFormat
" % { User - agent } i " agent
10 CustomLog
/ var / log / apache 2 / logs / rregister / access . log combined
11
12 </ VirtualHost >
XVI
D.2
XVII
Risk register defaults
Level
Impact
Level
Level
Level
Level
Level
Level
5:
4
3
2
1
0
Level
Level
Level
Level
Level
5
5
3
3
2
Level
Level
Level
Level
Level
Level
5
4
3
2
1
0
Level
Level
Level
Level
Level
Level
Level
Level
5
5
4
3
3
1
1
0
Level
Level
Level
Level
Level
Level
5
4
3
2
1
0
Competitive advantage - market share loss

> 15 %
< 15 %
< 10 %
<5%
<2%
<1%
Legal - regulatory compliance
Imprisonment
License to operate revoked
Personal conviction
Fine
Official investigation
Productivity - loss of MD
> 20 MD
< 20 MD
< 10 MD
< 5 MD
< 2 MD
< 1 MD
Reputation - external perception
Continued negative press coverage
Customer rating worse than 2.5/5
Customer rating 2.5/5 and better
Negative press coverage
News article
Cost of response
> 100 000 USD
< 100 000 USD
< 20 000 USD
< 10 000 USD
< 5000 USD
< 500
Source: author. Values in Legal and Reputation (press) categories based on [21, pg. 38] (Risk IT).
Table D.1: Default impacts
XVIII
[Default user groups]

Group
Permissions
user
auditor
Can log in; implicitly can update own profile.

Can access any regular model related to the risk register except for
user profiles.
Can access and edit any model except for accessing logs and editing
risk frequencies, impacts.
Can edit risk frequencies and impacts.
Can access risk register logs.
regular user
manager
administrator
Source: author.
Table D.2: Default user groups
User
Groups
user
auditor
regular user
manager
administrator
karel
user
user, auditor
user, regular user
user, regular user, manager
user, administrator
no groups; Superuser flag set to true
Source: author. All users have default password letmein.
Table D.3: Default users
Appendix E
Diagrams
Intentionally left blank.
E. Diagrams
XX
Figure E.1: COBIT 5 APO12 data flow diagram
Source: author; based on APO12 process inputs and outputs in [8, pgs. 108 to 111]. Please see
chapter 7 for explanation. Line patterns present to improve readability only.
E. Diagrams
XXI
Figure E.2: Risk register full class diagram
Source: author; diagram teaser full resolution diagram is enclosed on a DVD.
E. Diagrams
XXII
Figure E.3: Risk register asset application class diagram
Source: author.
E. Diagrams
XXIII
Figure E.4: Risk register risk application class diagram
Source: author.
Appendix F
Content of Enclosed DVD
There is a DVD enclosed to this thesis with the following structure.
Folder vbox: Virtual Box disk (pre-installed Debian 6.0.6; all passwords set to
letmein), exported machine and setup files.
Folder src: source codes of the risk register.
Folder epydoc: automatically generated code overview (EpyDoc).
Folder diagrams: larger class diagrams (including class diagram).

IT Risk Register

Uploaded by

Document Information

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

IT Risk Register

Uploaded by

Copyright:

Available Formats

Vysok

Author: Karel Kohout

Prague, December 9, 2012

a citovany v textu podle normy CSN

computer security, risk analysis, IT risk register,

informacn bezpecnost, anal

E-mail autora karel@kohout.se

4 Additional risk register security requirements

5 Risk register requirements summary

6 Risk register platform

8.3.1 Goal cascade . . . . . . . .

A COBIT 5 risk mappings

D Relevant configuration excerpts

Alignment of ISMS and InfoSec Risk Management Process . . . . . . 14

COBIT (BSC) Risk Description in Business Terms (examples)

ISO/IEC 27002 10.9.2 On-Line Transactions control . . . . . . . . . . 42

General security requirements . . . . . . . . . . . . . . . . . . . . . . 68

A.1 Enterprise goals and business impact . . . . . . . . . . . . . . . . . . II

GLBA Subtitle A Disclosure of Nonpublic Personal Information .

IT risk register RACI chart . . . . . . . . . . . . . . . . . . .

Risk register ER (entity-relationship) diagram . . . .

COBIT 5 Process reference model . . . . . . . . . . .

C.1 PRINCE 2 processes and components . . . . . . . . . . . . . . . . . . XIII

Relevant Apache 2 SSL configuration

COBIT 5 APO12 data flow diagram . . . .

Acronyms and definitions

Annualized Loss Expectancy, see Figure 3.12.

Application Programmable Interface.

Balanced Score Card.

Cross-Site Request Forgery.

Distributed Denial of Service.

Health Insurance Portability and Accountability Act (US legislation).

Intrusion Detection System.

Professional organization; see www.isaca.org.

The UK Office of Government Commerce (OGC) IT Infrastructure Library;

Also M o R. Management of Risk, framework; created by the Office of

Specific descriptions of how a quantitative and periodic assessment of

National Institute of Standards and Technology, Department of Commerce.

Office of Government Commerce (United Kingdom).

Project Management Institute.

Responsible, Accountable, Consulted, Informed (see CobiT 4.1 or COBIT 5).

Risk breakdown structure; see [1].

Request For Comments (document, Internet standards-related

Effect of uncertainty on objectives (a deviation from the expected positive

Sarbanes-Oxley act (US legislation).

United States (United States of America).

Work breakdown structure; see [1].

For a quick comparison of differences between COBIT versions, see http://www.isaca.org/

Methodologies and frameworks

BITS Technology Risk Transfer Gap Analysis Tool (BITS

BITS does not stand for an acronym.

Risk IT Framework (Risk IT)

Risk IT is a framework produced by the ISACA organization to improve enterprise

Source: [7, pg. 11, Figure 1].

In line with governance in ISO/IEC 38500:2008.

Source: [7, pg. 18, Figure 4]. Modified by the author.

Risk and project management

Confidentiality, integrity, availability.

A project is a temporary endeavor undertaken to create a unique product,

Source: [1, pg. 40, Figure 3.1].

11.6 Monitor and Control Risks.

Source: author, based on inputs and outputs in [1].

Figure 2.8: PMBOK risk-related processes (inputs and outputs) in

Source: author, based on inputs and outputs in [1].