Vysok a skola ekonomick a v Praze

Vysoka skola ekonomicka v Praze

Fakulta informatiky a statistiky

MASTER’S THESIS

IT Risk Register

Author: Karel Kohout

Supervisor: Ing. Ludek Novak, PhD

Academic Year: 2012/2013

mailto:[email protected]

mailto:

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

Cestne prohlasenı

Prohlasuji, ze jsem tuto diplomovou praci vypracoval samostatne. Veskere pouzite

podklady, ze kterych 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 duvernych informacı,

se kterymi 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 best-

practices related to information technology risks management, with focus on doc-

uments and guidance developed by ISACA. It builds a set of ideas and basic re-

quirements 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

Author’s e-mail [email protected]


Abstrakt

Teoreticka cast diplomove prace analyzuje nekolik vybranych metodologiı z oblasti

rızenı rizik IT se zamerenım na dokumenty vytvorene profesnı organizacı ISACA.

Vystupem jsou doporucenı a zakladnı pozadavky na efektivne fungujıcı model registru

rizik IT. Text klade velky duraz na propojenı COBIT 5 s Risk IT, ktery vychazı z

CobiT 4.1.

Prakticka cast popisuje implementaci modeloveho registru rizik IT v programo-

vacım jazyce Python s frameworkem Django za vyuzitı konceptu predstavenych v

teoreticke casti.

Klıcova slova informacnı bezpecnost, analyza rizik, registr

rizik IT, COBIT, Risk IT, Python, Django

E-mail autora [email protected]


Contents

List of Tables x

List of Figures xi

Acronyms xiii

1 Introduction 1

2 Risk management 3

2.1 Methodologies and frameworks . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 BITS Technology Risk Transfer Gap Analysis Tool (BITS GAP) 4

2.1.2 Risk IT Framework (Risk IT) . . . . . . . . . . . . . . . . . . 5

2.1.3 COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Risk and project management . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.2 PRINCE 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Risk and risk management overview . . . . . . . . . . . . . . . . . . . 12

2.3.1 Risk management in CobiT 4.1 and COBIT 5 . . . . . . . . . 17

2.4 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 IT Risk register 19

3.1 Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Business risk . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.2 Tolerance and appetite . . . . . . . . . . . . . . . . . . . . . . 22

3.1.3 Risk treatment . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.4 IT risk communication . . . . . . . . . . . . . . . . . . . . . . 25

3.1.5 Expressing risk . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.6 Expressing risk frequency . . . . . . . . . . . . . . . . . . . . 29

3.1.7 Expressing risk impact . . . . . . . . . . . . . . . . . . . . . . 30

3.1.8 Risk maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.9 Risk scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Contents viii

3.2 Various notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.1 Liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2.2 Effects of risk management and virtual risk . . . . . . . . . . . 37

3.3 Limitations and omissions of the thesis . . . . . . . . . . . . . . . . . 38

3.4 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 50

7.1 Risk register components . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1.1 Userinterface and tests . . . . . . . . . . . . . . . . . . . . . . 51

7.2 Risk register models . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.2.1 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.2.2 Impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2.3 Risk treatment . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.2.4 Risk, risk assessment and risk scenario . . . . . . . . . . . . . 56

7.3 Notes on implementation . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3.1 Django customization and configuration files . . . . . . . . . . 58

7.3.2 User rights checks . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.3.3 Audit trail (logs) . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.4 Point of time view . . . . . . . . . . . . . . . . . . . . . . . . 62

7.3.5 Test data in the register . . . . . . . . . . . . . . . . . . . . . 63

7.4 Analytical views and data access . . . . . . . . . . . . . . . . . . . . 63

7.4.1 Risk maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.4.2 Violations and top risks . . . . . . . . . . . . . . . . . . . . . 64

7.4.3 Expected issues . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.5 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8 Customizing, deploying and using the register 66

8.1 Hardware and software requirements . . . . . . . . . . . . . . . . . . 66

8.2 Information security . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8.2.1 Responsibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.3 COBIT 5 customization . . . . . . . . . . . . . . . . . . . . . . . . . 69

Contents ix

8.3.1 Goal cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.3.2 User rights and access . . . . . . . . . . . . . . . . . . . . . . 70

8.3.3 Impact and frequency scales . . . . . . . . . . . . . . . . . . . 70

8.3.4 Risk scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.4 User manual – quickstart . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.4.1 Less visible features . . . . . . . . . . . . . . . . . . . . . . . . 71

8.5 Possible uses of the risk register . . . . . . . . . . . . . . . . . . . . . 72

9 Conclusion 73

Bibliography 76

A COBIT 5 risk mappings I

B COBIT and Risk IT materials V

B.1 COBIT 5 Process capability attributes . . . . . . . . . . . . . . . . . V

B.2 COBIT 5 processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

B.3 COBIT 5 enablers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

B.4 CobiT 4.1 information criteria . . . . . . . . . . . . . . . . . . . . . . VII

B.5 CobiT 4.1 IT resources . . . . . . . . . . . . . . . . . . . . . . . . . . VIII

B.6 CobiT 4.1 to COBIT 5 process mapping . . . . . . . . . . . . . . . . IX

B.7 COBIT 5 APO12 Manage Risk figures . . . . . . . . . . . . . . . . . X

B.8 Risk IT Risk analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

C Other figures XIII

D Relevant configuration excerpts XIV

D.1 Apache2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV

D.2 Risk register defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

E Diagrams XIX

F Content of Enclosed DVD XXIV

List of Tables

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

2.2 ISO/IEC 27005:2011 risk assessment process . . . . . . . . . . . . . . 15

2.3 COBIT 5 APO12 activities . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 COBIT (BSC) Risk Description in Business Terms (examples) . . . . 28

3.2 Example frequency scales . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Generic impact scales of an event . . . . . . . . . . . . . . . . . . . . 31

3.4 Impact scales example . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5 Root mean square rationalization . . . . . . . . . . . . . . . . . . . . 32

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

4.2 Suggested user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Requirements summary . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.1 Frequency scales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Types of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

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

8.2 IT Risk register installation . . . . . . . . . . . . . . . . . . . . . . . 69

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 GLBA Subtitle A – Disclosure of Nonpublic Personal Information . . 4

2.2 Relationship between Risk IT, ValIT and CobiT 4.1 . . . . . . . . . . 5

2.3 COBIT 5 product family . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 COBIT 5 goal cascade . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 COBIT 5 enterprise enablers . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 PMBOK project management process groups . . . . . . . . . . . . . . 9

2.7 PMBOK risk-related processes (inputs and outputs) in Planning

Process Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.8 PMBOK risk-related processes (inputs and outputs) in Monitoring &

Controlling Process Group . . . . . . . . . . . . . . . . . . . . . . . . 11

2.9 Information security risk management process . . . . . . . . . . . . . 13

2.10 Increasing IT risk exposure . . . . . . . . . . . . . . . . . . . . . . . . 16

2.11 APO12 RACI chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 IT risk register RACI chart . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 IT risk categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Risk IT risk hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Tolerance and appetite . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Risk culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Risk treatment options . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.7 Balancing the risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8 Risk information properties . . . . . . . . . . . . . . . . . . . . . . . 26

3.9 Risk expression methods limitations . . . . . . . . . . . . . . . . . . . 27

3.10 Extended Balanced Score Card criteria expressing risk impact . . . . 28

3.11 Root mean square . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.12 Annualized Loss Expectancy (ALE) . . . . . . . . . . . . . . . . . . . 33

3.13 Risk map with risk appetite bands . . . . . . . . . . . . . . . . . . . 34

3.14 Modified risk map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.15 IT Risk scenario development . . . . . . . . . . . . . . . . . . . . . . 36

3.16 IT Risk scenario components . . . . . . . . . . . . . . . . . . . . . . . 36

List of Figures xii

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

7.2 Asset types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.3 Impact categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.4 Default risk scenario values . . . . . . . . . . . . . . . . . . . . . . . 57

7.5 Configuration files layout . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.6 Permission check in views – PermissionRequiredMixin . . . . . . . . . 59

7.7 Permission check in views – urls.py . . . . . . . . . . . . . . . . . . . 60

7.8 Immutable logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

B.1 COBIT 5 Process reference model . . . . . . . . . . . . . . . . . . . . VI

B.2 APO12.01 Collect data . . . . . . . . . . . . . . . . . . . . . . . . . . X

B.3 APO12.02 Analyse risk . . . . . . . . . . . . . . . . . . . . . . . . . . X

B.4 APO12.03 Maintain a risk profile . . . . . . . . . . . . . . . . . . . . X

B.5 APO12.04 Articulate risk . . . . . . . . . . . . . . . . . . . . . . . . . XI

B.6 APO12.05 Define a risk management action portfolio . . . . . . . . . XI

B.7 APO12.06 Respond to risk . . . . . . . . . . . . . . . . . . . . . . . . XI

B.8 Risk Analysis Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . XII

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

C.2 Weakest link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII

D.1 Relevant Apache 2 SSL configuration . . . . . . . . . . . . . . . . . . XIV

D.2 General virtual host configuration . . . . . . . . . . . . . . . . . . . . XIV

D.3 WSGI setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

D.4 Django file access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

D.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVI

E.1 COBIT 5 APO12 data flow diagram . . . . . . . . . . . . . . . . . . XX

E.2 Risk register full class diagram . . . . . . . . . . . . . . . . . . . . . . XXI

E.3 Risk register asset application class diagram . . . . . . . . . . . . . . XXII

E.4 Risk register risk application class diagram . . . . . . . . . . . . . . . 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).

PMBOK Project Management Body of Knowledge (project management

methodology).

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).

stakeholder Person or organization that can affect, be affected by, or perceive

themselves to be affected by a decision or activity [15, pg. 4].

US United States (United States of America).

WBS Work breakdown structure; see [1].

http://www.ietf.org/rfc/rfc2026.txt

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 2

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].

1For 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 infor-mation.

http://www.isaca.org/COBIT/Documents/COBIT5-Compare-With-4.1.ppt

http://www.isaca.org/COBIT/Documents/COBIT5-Compare-With-4.1.ppt

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 4

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 In-formation

(b) Financial Institutions Safeguards. In furtherance of the policy in subsection (a),each agency or authority described in section 505(a) shall establish appro-priate standards for the financial institutions subject to their jurisdictionrelating to administrative, technical, and physical safeguards –

1. to insure the security and confidentiality of customer records andinformation;

2. to protect against any anticipated threats or hazards to the security orintegrity of such records; and

3. to protect against unauthorized access to or use of such records orinformation which could result in substantial harm or inconvenience toany customer.

Source: Gramm-Leach-Bliley Act, 106th Congress Public Law 102, TITLE V–PRIVACY, 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.

1BITS does not stand for an acronym.2The 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 therestriction for commercial banks to also act as an investment bank or insurance company (and viceversa).

http://www.gpo.gov/fdsys/pkg/PLAW-106publ102/html/PLAW-106publ102.htm


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 comple-

ments 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 Enter-

prise IT”), released in 2012, and its older “sibling” CobiT 4.1 (“Control Objectives

for Information and related Technology” from 2007) represent “ISACA’s guidance

on the enterprise governance and management of IT”[7, pg. 15] based on real-life

experience within the industry. The framework’s 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]).


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 Man-

agement 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 author’s

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

3In line with governance in ISO/IEC 38500:2008.4Processes in COBIT 5 are an “evolution” of CobiT 4.1 processes.


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 work—in 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 isactually achieving its purpose and delivering its required outcomes as expected.”[7, pg. 45]


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 triad”6 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.

6Confidentiality, integrity, availability.7Notwithstanding the fact that COBIT 5 now contains BAI01 Manage Programmes and Projects

process and a management practice BAI01.10 Manage programme and project risk.


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, let’s go through two selected8 project

methodologies and point out parts related to risk management.

2.2.1 PMBOK

The Project Management Institute’s (PMI) Project Management Body of Knowl-

edge (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 Moni-

toring & 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,

8Haphazardly.


• 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) inPlanning Process Group

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


Figure 2.8: PMBOK risk-related processes (inputs and outputs) inMonitoring & 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 process-

based) method for effective project management”[17, pg. 1]. Risk management


(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.

Author’s 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 man-

agement. 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, let’s 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.

9E.g. financial, health and safety, and environmental goals.10A 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 norisk. The person jumping can be – baring a miracle – sure that after a few seconds of flight, deathwill inevitably follow; the outcome is certain and carries no risk at all.


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


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

Do Implementation of risk treatment planCheck Continual monitoring and reviewing of risksAct Maintain and improve the Information Security Risk Management Process

Source: [14, pg. 9, Table 1].

Table 2.1: Alignment of ISMS and Information Security Risk Manage-ment 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:

11Specifically, the risk register will not support ranking risks “against the risk evaluationcriteria”[14, pg. 13].


Phase Step Tasks

Risk identification

Identification ofassets

Create of list of assets and related business pro-cesses, determine relevance.

Identification ofthreats

Determine threats, identify their type and source.

Identification ofexisting controls

Select future (planned) and check existing controlsand their usage.

Identification ofvulnerabilities

Relate vulnerabilities to assets, threats and con-trols, review vulnerabilities not related to anythreat.

Identification ofconsequences

Create incident scenarios and their impact onassets and business processes.

Risk analysisAssessment ofconsequences

Assemble a list of assessed consequences of inci-dent scenarios with respect to assets.

Assessment of in-cident likelihood

Evaluate likelihood of incident scenarios (quanti-tative or qualitative).

Level of risk de-termination

Prepare a list of risks with value levels assigned.

Risk evaluation Finalize a “list of risks prioritized according torisk evaluation criteria in relation to the incidentscenarios 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


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, organization’s 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.3.1 Risk management in CobiT 4.1 and COBIT 5

The underlying requirement to perform risk management is present both in Co-

biT 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:


Activity Management practice

APO12.01 Collect data Identify and collect relevant data to enable effective IT-related risk identification, analysis and reporting.

APO12.02 Analyse risk Develop useful information to support risk decisions thattake into account the business relevance of risk factors.

APO12.03 Maintain a risk pro-file

Maintain an inventory of known risk and risk attributes (in-cluding expected frequency, potential impact and responses)and of related resources, capabilities and current controlactivities.

APO12.04 Articulate risk Provide information on the current state of IT-related expo-sures and opportunities in a timely manner to all requiredstakeholders for appropriate response.

APO12.05 Define a risk man-agement action portfolio

Manage opportunities to reduce risk to an acceptable levelas a portfolio.

APO12.06 Respond to risk Respond in a timely manner with effective measures to limitthe magnitude of loss from IT-related events.

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 board’s 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, let’s 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, let’s 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 organization’s 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 map1.

RACI chart on page 76 of Risk IT answers a crucial question – who, in relation

to CobiT 4.1 roles2, should maintain the register?

1IT Risk register in Risk IT is an extension of a risk map but in the thesis, risk map is generallyconsidered a tool within the actual register.

2Risk 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 Risk

3.1.1 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:

3See section 3.3.4Probably high security military installations.


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.1.2 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 willingto 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 organization’s 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

doesn’t provide realistic data and the people within the enterprise are not motivated

to provide realistic data6.

5However, Risk IT suggests that one might knowingly accept risk “associated with regulatorynon-compliance”[20, pg. 17] as a trafe-off if the compliance would be prohibitively expensive.

6For example IT department is motivated to underestimate risks in the short term to avoidcompliance scrutiny, or overestimate long term risk to retain personnel or higher budget share.


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, arisk situation.

Risk reduction: actions taken to lessen the probability (frequency), negative conse-quences, or both, associated with a risk.

Risk retention: acceptance of the burden of loss or benefit of gain from a particularrisk.

Risk transfer: sharing with another party the burden of loss or benefit of gain, for arisk.

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


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].


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.


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 criticalmoment 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 manage-

ment of communication within the register and several requirements for an advanced

register might be derived. The hypothetical register should track how is information


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 author’s risk register beyond the

scope of master’s 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 dependenton the person performing them and his/her skills and views.”

IT-risk-related data are typically “of poor quality and quite subjective” (forexample, “process maturity, control weaknesses”).

Complex quantitative methods with limited datasets result in too confident models;however, simplistic methods can also lead to unreliable expectations aboutrisk.

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 Practicioner’s guide suggests expressing impact of risk in “unambigu-

ous 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

7For example by adding ranges to primarily qualitative expert opinions.


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 IT-enabled business investments.

There is inadequate return on investment ofIT-enabled business investments.

Improve corporate governance and trans-parency.

Inadequate financial transparency for mar-kets reflects on share value and compliancerisk.

Improve customer orientation and service. Bad or insufficient customer service resultsin client loss.

Offer competitive products and services. Ineffective products and services do not ad-dress customer needs, resulting in revenueloss.

Source: [21, pg. 35, figure 24].

Table 3.1: COBIT (BSC) Risk Description in Business Terms (selectedexamples)

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 riskimpact

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 Practicioner’s 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.


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 Practicioner’s 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 〈1000; 10000)4 〈100; 1000)3 〈10; 100)2 〈1; 10)1 〈0.1; 1)0 〈0; 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


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 Practicioner’s 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

8CCTA Risk Analysis and Management Method.


scales to the needs of the enterprise.

AreaScale 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).

Legal – Regulatory non-complianceImpact Legal Financial (USD); up to License to Operate

0 $01 $1,000,0002 $2,000,0003 Personal conviction $5,000,000 Fined4 $10,000,0005 Imprisonment 〈$10,000,000 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 Practicioner’s 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.


Figure 3.11: Root mean square

xRMS =

√√√√ n∑i=1

x2i

n

Where:

xi is impact score from a selected area,

n is number of areas, and

xRMS 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 fromthree areas

Arithmetic mean Root mean square (roundedto two digits)

2, 2, 2 2 21, 2, 3 2 2.160, 2, 4 2 2.580, 1, 5 2 2.94

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:


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).


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 organization’s 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.


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 – return-

on-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.


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.2 Various notes

3.2.1 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 risk-

taking 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 let’s 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 anemployee in the scope of employment”[9, pg. 648] (under the common law doctrine of respondeatsuperior).

10A reasonable organization would have plans for events outside the interval (insurance, temporarytechnical solutions), but the idea is to present a simplified example.


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, com-

munication 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, lot’s 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

11Examples made up by the author of the thesis.


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 organization’s

“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.

1More stringent requirements, for example memory separation, are probably unrealisticallyexpensive, 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 ap-

plication; 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:

2The statement is not completely valid for publicly listed companies that are typically obligedby law to disclose certain facts to shareholders (owners of shares) and the general public.

3In an idealistic world without insecure web browsers.4general_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 customfilestorage in Django (extend an existing one). The same approach is possible to implement digitalsignatures and timestamps for all uploaded files.

5Which happens by default with the Django library.

general_tools/file.py


Item to prevent Solution

Incomplete transmission SSL encryption (mod openssl); see section D.1.Mis-routing n/aUnauthorized message alter-ation

SSL encryption (mod openssl); also, clickjacking pro-tection in Django.

Unauthorized disclosure SSL encryption (mod openssl).Unauthorized message dupli-cation

SSL encryption (mod openssl); cross-site requestforgery (CSRF) protection in Django.

Unauthorized message replay SSL encryption (mod openssl); cross-site requestforgery (CSRF) protection in Django.

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 author’s 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 appli-

cation. However, the larger issue of assigning access must be tackled during the

register implementation (and is specifically required in chapter 8).


Role Permissions

user Can access the register interface and log-in.edit Can edit items in the register.logs Can access risk register logs.user administrator Can 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

6In the thesis, review can be easily implemented by adding a new field to objects to mark reviewstatus and a custom objects Manager that would filter inactive (non-reviewed) objects from queriesby default.

7See [10] at https://docs.djangoproject.com/en/dev/topics/auth/.8By implementing a JavaScript login form to prevent the browser from recognizing it as a login

prompt.9See [10] at https://docs.djangoproject.com/en/dev/topics/auth/

#how-django-stores-passwords; the mechanism follows NIST SP 800-132 Recommenda-tion for Password-Based Key Derivation – Part 1: Storage Applications.

10See [10] at https://docs.djangoproject.com/en/dev/topics/security/

#cross-site-scripting-xss-protection

https://docs.djangoproject.com/en/dev/topics/auth/

https://docs.djangoproject.com/en/dev/topics/auth/#how-django-stores-passwords

https://docs.djangoproject.com/en/dev/topics/auth/#how-django-stores-passwords

https://docs.djangoproject.com/en/dev/topics/security/#cross-site-scripting-xss-protection

https://docs.djangoproject.com/en/dev/topics/security/#cross-site-scripting-xss-protection


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 crypto-

graphically 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.

11All potentially dangerous characters are converted to HTML entities.12See [10] at https://docs.djangoproject.com/en/dev/topics/security/

#sql-injection-protection13With pyclamav library; also see http://code.google.com/p/django-antivirus/ (last re-

trieved August 20, 2012).14May not be possible with all database backends. However, the default PostgreSQL fully

supports transactions.

https://docs.djangoproject.com/en/dev/topics/security/#sql-injection-protection

https://docs.djangoproject.com/en/dev/topics/security/#sql-injection-protection

http://code.google.com/p/django-antivirus/

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 fromrisk identification, estimation, evaluation, treatment and acceptancephases of ISO/IEC 27005 Risk management process, specifically:

• storing risk assessment data,

• categorizing assets (goals, processes) through COBIT 5 goalcascade,

• documenting risk events (scenarios),

• linking assets with risks, risk scenarios and risk treatments,

• analysing risk events (scenarios) and business effects of eventsthrough a set of extendable scales (frequencies, impacts) ac-cording to Risk IT using both quantitative and qualitativeapproaches,

• tracking risk and risk treatment through time.

The risk register should also support employing risk tolerance andappetite levels, rudimentary tracking of project IT risks and allowquickly displaying data at various levels of aggregation.

Source data Use COBIT 5 and Risk IT as source data where possible.Performance Provide near real-time performance with data processing times from

one user input to another lower than 30 seconds.Reliability Assure data integrity.Usability Contain user interface understandable by knowledgeable computer

user and provide help throughout the interface.Security Support multiuser environment with granular access control. Log all

user actions and allow review. Label information in the register.Hardware and software Client software agnostic to server software running the register; soft-

ware libraries part of the standard Debian wheezy or packaged withthe 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.

1Django’s tagline “The Web framework for perfectionists with deadlines” sums it all – while theauthor may not be a perfectionist, this thesis certainly has a deadline.

2See [10] at https://docs.djangoproject.com/en/1.4/misc/api-stability/3See [10] at https://docs.djangoproject.com/en/.4See [10] at https://docs.djangoproject.com/en/1.4/internals/deprecation/.5See security issues at https://www.djangoproject.com/weblog/ and bug reports at https:

//code.djangoproject.com/query.6See [10] design philosophies at https://docs.djangoproject.com/en/1.4/misc/

design-philosophies/ (last retrieved December 8, 2012).

https://docs.djangoproject.com/en/1.4/misc/api-stability/

https://docs.djangoproject.com/en/

https://docs.djangoproject.com/en/1.4/internals/deprecation/

https://www.djangoproject.com/weblog/

https://code.djangoproject.com/query

https://code.djangoproject.com/query

https://docs.djangoproject.com/en/1.4/misc/design-philosophies/

https://docs.djangoproject.com/en/1.4/misc/design-philosophies/

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 numer-

ous 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 framework-

library) 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.

7https://github.com/bradleyayers/django-tables2/; GIT commit g595c8d4 (last retrievedOctober 5, 2012).

8Based on experience with the stack; the performance starts to lag only when making severaltens of thousands object manipulations (retrieve from database, perform interaction, save modifiedobject) per second on low-cost servers (Intel Core i5 CPU, 8 GB RAM).

https://github.com/bradleyayers/django-tables2/


The list is arbitrarily based on author’s 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.

9Including for example Internet Explorer 7.10Leading to Unicode string comparison errors, for example in Python in the Cygwin environment

on Microsoft Windows XP.


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 high-

level 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


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 history2

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

1Django terminology; essentially a Python class with an underlying ORM mapper that allowspermanent storage transparent to the programmer.

2http://code.google.com/p/fullhistory/ (last retrieved June 10, 2012).

http://code.google.com/p/fullhistory/


the analysis needed to define the relationships would be beyond the scope of this

thesis.

The risk register doesn’t track changes to Asset objects. The author has contem-

plated 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 it’s more

valuable to know “what’s 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; 0.1) events per year Improbable events, unlikelynatural disasters, ...

1 < 0.1; 1) events per year The event took place over acompany lifetime.

2 < 1; 12) events per year Up to once a month.3 < 12; 52) events per year Up to once every week.4 < 52; 365) events per year Almost every day.5 < 365; 1000000) events per years Multiple events per day.

Source: author.

Table 7.1: Frequency scales

The scale probably wouldn’t 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

3Stored in RiskEntry model, described later.


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 IM-

PACT 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


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 Practicioner’s 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.

4For example, one might ponder that governmental organization would accept higher productivitylosses as a tradeoff to lower monetary loss. It doesn’t need to generate any revenue (hence lowerissues with productivity), while even small direct financial costs could be critical due to increasedbudget oversight.

5Economic position of the country etc.6RiskTreatmentOption – imagine a broad insurance contract; then RiskTreatment contains

specific information how the broad insurance contract treats risk in the RiskEntry object.7Removal is still possible from the admin interface.


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 don’t 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 freq. Then, instance of Frequency with level in the interval

< avg freq−1; avg freq+1) is selected; the engine establishes the frequency value

from the level as (upper times per interval− lower times per interval)/2 and adds

8If it reduces risk.9Or for example floods during certain months and under certain meteorological circumstances.

10A similar example is a government site(s) during a time when certain legislation is prepared –most notably, the ACTA (Anti-Counterfeiting Trade Agreement).


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 haven’t 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, inap-propriate 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

11Even 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 forexample the resulting risk map would have to include another axis (the time element).


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.


Figure 7.5: Configuration files layout

00 deployment.conf: Variables enabling the debug environment, email notificationsfor 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 likename, 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 PermissionRe-

quiredMixin 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 PermissionRequiredMixin(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 permission 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 PermissionDenied ("User does not have permission: %s" %

permission)

1617 class SecUpdateView ( (...), PermissionRequiredMixin , UpdateView):

18 action = "change"

Source: author; general tools/views.py, simplified. Note the superuser permission.


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, itpasses 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 andwhere 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, ...)


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 doesn’t 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, al-

though 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 OwnershipRequired-

Mixin 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 (in-

cluding 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.

12The reader is kindly referred to Django documentation [10] at https://docs.djangoproject.com/en/1.4/topics/http/middleware/ for details.

13In the register, they can be logged at the webserver level.14Parent and child instances are rather problematic to differentiate.

https://docs.djangoproject.com/en/1.4/topics/http/middleware/

https://docs.djangoproject.com/en/1.4/topics/http/middleware/


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 HTTP requestEXCEPTION ExceptionLOGIN User logged inLOGOUT User logged outOBJECT Object changedLOGIN TRY 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 def save (self , force_update=False , force_insert=False):

2 if self.pk is not None:

3 raise PermissionDenied ("You are not allowed to edit log

objects")

4 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

15See settings.LOG MODELS CHANGE in conf/10 app defaults.conf.


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

16The past view is limited because the register doesn’t contain a history layer for relationships.Therefore, for example risk treatments are applied based on current date, not on the point of viewdate, because there is no way of knowing whether they existed in the past and were related to therisk entry in the past.

17Create-Update-Delete.18That is, without taking into account values from ElevatedRisk and RiskTreatment instances.


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


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 CPU’s 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 imple-

mentation 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.


ISO/IEC27002:2005sectionreference

Requirement

10.1.1 Document the whole implementation process of the register; document operations ofthe risk register throughout the lifecycle.

6.1.3 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 oper-ating system and vendor updates),

• creating a security profile of the hardware and software running the riskregister.

6.1.5 Require all personnel maintaining the risk register must accept a non-disclosureagreement.

6.1.5 Establish a process for reporting and evaluating unauthorized information disclosure.6.2 Examine external parties controls from ISO/IEC 27002.6.2.3 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 isplaced in shared rack).

7.2.2 Create an information labeling policy and accordingly assign user groups in theregister.

8.1.1 Create and assign security groups and responsibilities according to a predefinedinformation security policy.

8.2.2 Ensure that all users of both the risk register and its outputs must have an appropriateinformation security awareness and receive training.

8.3.3 Access rights to the register must be modified when the user changes his or her rolein the organization (including contract termination).

9 Consider reviewing physical security controls.10.1.2 Document any changes to the risk register configuration.10.1.3 Maintain “two men policy” for all configuration changes.10.2 Monitor third party service delivery management.10.4.1 Check for malicious code after customizing the risk register user interface.10.4.1 Establish and enforce policy about the type of documents that can be uploaded to

the risk register.10.4.1 Secure client stations accessing the risk register.10.5 Set up frequent automatic encrypted risk register backups including logs and regularly

test risk register full recovery from a backup.10.5 Establish a backup procedure that preserves the last state of the register before

backup for forensic investigation.10.7.4 Prevent unauthorized access to risk register documentation.10.10.6 Setup automatic server system clock synchronization.10.10.1 Periodically review risk register logs; analyze changes that might have been performed

to cover illicit activities.10.10.1 Periodically review server logs.10.10.1 Monitor, log and analyze “changes to system configuration, use of system utilities and

applications, activation and de-activation of protection systems, such as anti-virussystems and intrusion detection systems”[13, pg. 55].

12.3.2 Properly manage risk register server SSL certificates.12.4 Adhere to 12.4 Security of system.

Source: author; based on [13].

Table 8.1: General security requirements


The following tasks must be accomplished when the risk register is installed.

Item Procedure

Database password Change default database user password.User accounts Change default administrator’s password.Configuration item set-tings.SECRET KEY

Generate a new random string upon installa-tion.

Django admin Disable the administration interface in theproduction environment via urls.py.

Configuration file set-tings/00 deployment.conf

Set all values to false.

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.


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

1A useful control is to review whether a user is not logging again and again from different IPaddresses (machines) within the organization.


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 auditor’s account, the URL /risk/scenario/items/add/ will display permission

error and /risk/scenario/items/0/delete/ will explain why it’s not possible to edit

objects at all.


8.5 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 organization’s 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.

2Which 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.

3Albeit there is no “editing” lock in the register, so the users would have to agree on someseparation.

4Or freely available risk registers under various licences.5Including 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 master’s 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 In-

surance 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-237-

3.

[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.

http://httpd.apache.org/docs/2.2/

http://httpd.apache.org/docs/2.2/

http://www.bits.org/publications/doc/GapAnalysis0402.pdf

http://www.bits.org/publications/doc/GapAnalysis0402.pdf

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/.

[11] DOUCEK, P., NOVAK, L., SVATA, V.: Rızenı bezpecnosti informacı. Prvnı

vydanı. Praha: Professional Publishing, 2008. ISBN 978-80-86946-88-7.

[12] HINDLS, R., HRONOVA, S., SEGER, J.: Statistika pro ekonomy. Pate vydanı.

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 – Informa-

tion 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: Sta-

tionery 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.

https://docs.djangoproject.com/en/1.4/

https://docs.djangoproject.com/en/1.4/

http://www.ey.com/Publication/vwLUAssets/The_evolving_IT_risk_landscape/$FILE/Insights%20on%20IT%20risks_Evolving%20IT%20landscape_AU0886.pdf



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.

A. COBIT 5 risk mappings II

Ente

rpri

seG

oal

Bu

sin

ess

Imp

act

FinancialPerspective

Sta

keh

old

erva

lue

ofb

usi

nes

sin

vest

men

tsIn

ad

equ

ate

fin

an

cial

retu

rnon

inve

stm

ent

of

IT-e

nab

led

bu

sin

ess

inve

stm

ents

.P

ortf

olio

ofco

mp

etit

ive

pro

du

cts

and

serv

ices

Inad

equ

ate

pro

du

cts

an

dse

rvic

es,

not

ad

dre

ssin

gcu

stom

ern

eed

s,re

sult

ing

inre

venu

elo

ss.

Man

aged

bu

sin

ess

risk

(saf

egu

ard

ing

ofas

sets

)IT

-rel

ate

dri

sks

not

man

aged

,le

avin

gth

eco

mp

any

exp

ose

d.

Com

pli

ance

wit

hex

tern

alla

ws

and

regu

lati

ons

Vio

lati

onof

regu

lati

ons

orco

ntr

acts

,re

sult

ing

inle

gal

fin

es/d

amag

esor

per

son

alle

gal

con

se-

qu

ence

sfo

rb

oard

an

dex

ecu

tive

s.Im

pro

veco

rpor

ate

gove

rnan

cean

dtr

ansp

aren

cyIn

adeq

uat

etr

ansp

aren

cyfo

rst

akeh

old

ers,

not

mee

ting

clie

nt

exp

ecta

tion

s;la

ckof

com

plian

ce.

Fin

anci

altr

ansp

aren

cyF

inan

cial

frau

d,

loss

of

good

wil

l.CustomerPerspective

Cu

stom

er-o

rien

ted

serv

ice

cult

ure

Bad

or

insu

ffici

ent

cust

om

erse

rvic

e,re

sult

ing

incl

ient

loss

.B

usi

nes

sse

rvic

eco

nti

nu

ity

and

avai

lab

ilit

yIn

ad

equ

ate

serv

ice

leve

ls,

resu

ltin

gin

cust

om

erdis

sati

sfact

ion

an

dp

ote

nti

al

reven

ue

loss

.A

gile

resp

onse

sto

ach

angi

ng

bu

sin

ess

envir

onm

ent

Inabilit

yto

react

toch

angin

gm

ark

etor

clie

nt

requir

emen

tson

ati

mel

ybasi

s,re

sult

ing

inre

venu

elo

ss.

Info

rmat

ion

-bas

edst

rate

gic

dec

isio

nm

akin

gW

rong

stra

tegic

dec

isio

ns

on

new

busi

nes

sin

itia

tives

,re

sult

ing

incl

ient/

reven

ue

loss

and

share

hold

erva

lue.

Op

tim

isat

ion

ofse

rvic

ed

eliv

ery

cost

sP

roduct

sor

serv

ices

bro

ught

tom

ark

etat

too

hig

ha

pri

ceor

inadeq

uate

pro

fit

marg

in,

pote

nti

all

yre

sult

ing

insh

are

valu

ean

dcl

ient

loss

.In

tern

alPerspective

Op

tim

isat

ion

ofbu

sin

ess

pro

cess

fun

ctio

nal

ity

Ineffi

cien

tan

din

ad

equ

ate

op

erati

on

sof

the

ente

rpri

se.

Op

tim

isat

ion

ofbu

sin

ess

pro

cess

cost

sL

ower

pro

fita

bil

ity.

Man

aged

bu

sin

ess

chan

gep

rogr

amm

esIn

effici

ent

an

din

ad

equ

ate

op

erati

on

sof

the

ente

rpri

se,

resu

ltin

gin

loss

of

op

port

un

itie

s.C

omp

lian

cew

ith

inte

rnal

pol

icie

sIn

effici

ent

an

din

ad

equ

ate

op

erati

on

sof

the

ente

rpri

se,

resu

ltin

gin

com

pli

an

ceis

sues

.O

per

atio

nal

and

staff

pro

du

ctiv

ity

Ineffi

cien

tand

inadeq

uate

op

erati

ons

of

the

ente

rpri

se,

resu

ltin

gin

inadeq

uate

pro

duct

ivit

yan

deffi

cien

cy.

Learn

ingand

Gro

wth

Perspective

Skil

led

and

mot

ivat

edp

eop

leIn

ab

ilit

yto

sust

ain

gro

wth

or

curr

ent

op

erati

on

s.P

rod

uct

and

bu

sin

ess

innov

atio

ncu

ltu

reL

oss

of

op

port

un

itie

s,lo

wgro

wth

,er

odin

gm

ark

etsh

are

.

Sou

rce:

[21,

pg.

42,

figu

re29

];th

eta

ble

has

bee

nm

odifi

edby

the

au

thor

toin

corp

ora

teC

OB

IT5

ente

rpri

segoals

word

ing

from

[7,

pg.

15,

figu

re5].

Tab

leA

.1:

Ente

rpri

sego

als

and

busi

nes

sim

pac

t

A. COBIT 5 risk mappings III

COBIT 5 Enterprise Goal CobiT 4.1 Business goals

Financial PerspectiveStakeholder value of business investments Provide a desired return on investment of

IT-enabled business investmentsPortfolio of competitive products and services Offer competitive products and services (in

customer perspective)Managed business risk (safeguarding of as-sets)

Manage IT-related business risk

Compliance with external laws and regula-tions

Provide compliance with external laws, regu-lations and contracts (in internal perspective)

Financial transparency Improve corporate governance and trans-parency

Customer PerspectiveCustomer-oriented service culture Improve customer orientation and serviceBusiness service continuity and availability Establish service continuity and availabilityAgile responses to a changing business envi-ronment

Create agility in responding to changing busi-ness requirements

Information-based strategic decision making Obtain reliable and useful information forstrategic decision making

Optimisation of service delivery costs Achieve cost optimisation of service deliveryInternal Perspective

Optimisation of business process functional-ity

Improve and maintain business process func-tionality

Optimisation of business process costs Lower process costsManaged business change programmes Manage business changeCompliance with internal policies Provide compliance with internal policiesOperational and staff productivity Improve and maintain operational and staff

productivityLearning and Growth Perspective

Skilled and motivated people Acquire and maintain skilled and motivatedpeople

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 goalsmapping

A. COBIT 5 risk mappings IV

Cobit

Info

rm

atio

nCriteria

Busi

ness

Goals

–C

onse

quence

(Im

pact)

Eff

ecti

veness

Effi

cie

ncy

Confi

denti

ality

Inte

gri

tyA

vailabilit

yC

om

pliance

Reliabilit

yFin

ancia

lPerspectiv

eIn

adequate

financia

lre

turn

on

invest

ment

of

IT-e

nable

dbusi

ness

invest

ments

.P

Inadequate

pro

ducts

and

serv

ices,

not

addre

ssin

gcust

om

er

needs,

resu

ltin

gin

revenue

loss

.P

S

IT-r

ela

ted

risk

snot

managed,

leavin

gth

ecom

pany

exp

ose

d.

PP

P

Vio

lati

on

of

regula

tions

or

contr

acts

,re

sult

ing

inle

gal

fines/

dam

ages

or

pers

onal

legal

conse

-quences

for

board

and

executi

ves.

PP

SS

SS

Inadequate

transp

are

ncy

for

stakehold

ers

,not

meeti

ng

client

exp

ecta

tions;

lack

of

com

pliance

SP

Fin

ancia

ltr

ansp

are

ncy

SP

PP

PCustom

er

Perspectiv

eB

ad

or

insu

fficie

nt

cust

om

er

serv

ice,

resu

ltin

gin

client

loss

.P

SS

S

Inadequate

serv

ice

levels

,re

sult

ing

incust

om

er

dis

sati

sfacti

on

and

pote

nti

al

revenue

loss

.P

SS

Inabilit

yto

react

tochangin

gm

ark

et

or

client

requir

em

ents

on

ati

mely

basi

s,re

sult

ing

inre

venue

loss

.P

SS

SP

Wro

ng

stra

tegic

decis

ions

on

new

busi

ness

init

iati

ves,

resu

ltin

gin

client/

revenue

loss

and

share

-hold

er

valu

e.

PS

SS

Pro

ducts

or

serv

ices

bro

ught

tom

ark

et

at

too

hig

ha

pri

ce

or

inadequate

pro

fit

marg

in,

pote

n-

tially

resu

ltin

gin

share

valu

eand

client

loss

.P

InternalPerspectiv

eIn

effi

cie

nt

and

inadequate

op

era

tions

of

the

ente

rpri

se.

PS

SP

Low

er

pro

fita

bilit

y.

PS

SP

S

Ineffi

cie

nt

and

inadequate

op

era

tions

of

the

ente

rpri

se,

resu

ltin

gin

loss

of

opp

ort

unit

ies.

SP

S

Ineffi

cie

nt

and

inadequate

op

era

tions

of

the

ente

rpri

se,

resu

ltin

gin

com

pliance

issu

es.

P

Ineffi

cie

nt

and

inadequate

op

era

tions

of

the

ente

rpri

se,

resu

ltin

gin

inadequate

pro

ducti

vit

yand

effi

cie

ncy.

PS

S

Learnin

gand

Growth

Perspectiv

eIn

abilit

yto

sust

ain

gro

wth

or

curr

ent

op

era

tions.

PS

Loss

of

opp

ort

unit

ies,

low

gro

wth

,ero

din

gm

ark

et

share

.S

P

Sou

rce:

[21,

pg.

44,

figu

re31

];th

eta

ble

has

bee

nm

od

ified

and

rest

ruct

ure

dby

the

auth

orto

suit

CO

BIT

5en

terp

rise

goal

s(A

pp

end

ixA

)ra

ther

than

Cob

iT4.

1b

usi

nes

sgo

als.

Tab

leA

.3:

CO

BIT

5busi

nes

sim

pac

tsto

Cob

iT4.

1in

form

atio

ncr

ite-

ria

map

pin

g

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

B. COBIT and Risk IT materials VI

Fig

ure

B.1

:C

OB

IT5

Pro

cess

refe

rence

model

Sou

rce:

[7,

pg.

33,

Fig

ure

16].

B. COBIT and Risk IT materials VII

B.3 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 enter-

prise.

• 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 in-

formation 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, tech-

nology 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.

B. COBIT and Risk IT materials 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 unau-

thorised 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

B. COBIT and Risk IT materials 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 EDM01, EDM02, EDM04, EDM03, MEA02ME1 MEA01ME3 MEA03ME2 MEA02DS8 DSS02DS9 BAI10, DSS02DS6 APO06DS7 APO07DS4 DSS04DS5 APO13, DSS05, DSS02DS2 APO10DS3 BAI04DS1 APO09DS10 DSS03DS11 DSS01, DSS04, DSS06, DSS05DS12 DSS01, DSS05DS13 DSS01, DSS05, BAI09PO8 APO11PO9 EDM03, APO01, APO12PO6 APO01, EDM03PO7 APO07, APO01PO4 APO01, APO11, APO07PO5 APO06, APO05PO2 APO03, APO01PO3 APO02, APO04, EDM01, APO03, APO01PO1 EDM02, APO02, APO05PO10 BAI01AI5 BAI03, APO10AI4 BAI05, BAI08AI7 BAI05, BAI07AI6 BAI06AI1 BAI02AI3 BAI03, DSS02AI2 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. COBIT and Risk IT materials X

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].

B. COBIT and Risk IT materials XI

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].

B. COBIT and Risk IT materials XII

B.8 Risk IT Risk analysis

Figure B.8: Risk Analysis Flowchart


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).

http://xkcd.com/538/

Appendix D

Relevant configuration excerpts

D.1 Apache2

Figure D.1: Relevant Apache 2 SSL configuration

1 SSLProtocol -all +TLSv1 +SSLv3

2 SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

3 SSLCertificateFile /etc/apache2/ssl/certApache2.pem

4 SSLCertificateKeyFile /etc/apache2/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 <VirtualHost *:80>

2 ServerName risk.company.int

3 ServerAdmin [email protected]

4 DocumentRoot /home/www/risk.company.int/

56 <Directory />

7 Options FollowSymLinks -Indexes

8 AllowOverride AuthConfig FileInfo Indexes Limit

9 </Directory >

1011 SSLEngine on


D. Relevant configuration excerpts XV

Figure D.3: WSGI setup

1 # Python scripts are compiled (.pyc); it is important to either reload

the server or edit the file wsgi_handler .py to force the

interpreter to look for changes in source code (.py).

2 WSGIScriptAlias / /home/www/risk.company.int/wsgi_handler.py

34 # riskregister is a system user and must exist as such (/etc/passwd , /

etc/group). It is recommended to disable login by changing the

shell in /etc/passwd to e.g. /bin/false. Separating WSGI scripts by

users allows better monitoring and user separation (regular file

and directory permissions apply); compare to mod_python or mod_php

for PHP scripts.

5 WSGIDaemonProcess riskregister user=riskregister group=riskregister

processes=1 threads=15

6 WSGIProcessGroup riskregister


Figure D.4: Django file access

1 # Regular scripts are processed in the chain Apache 2 - mod_wsgi -

Python interpreter , which is fairly inefficent . The standard

procedure is to disable mod_wsgi for certain directories and let

plain Apache 2 to serve media files (images , CSS style sheets ,...)

to improve performance and memory footprint.

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 >

89 <Directory /home/www/risk.company.int/media/>

10 FileETag none

11 ExpiresActive On

12 ExpiresDefault "access plus 4 weeks"

13 ExpiresByType image/gif A2592000

14 ExpiresByType image/png A2592000

15 ExpiresByType image/jpg A2592000

16 ExpiresByType image/jpeg A2592000

17 </Directory >

1819 <Location /media -admin >

20 SetHandler none

21 Order deny ,allow

22 Allow from all

23 FileETag none

24 ExpiresActive On

25 ExpiresDefault "access plus 10 years"

26 </Location >

2728 # Django contains a built -in web administration -- friendly user

interface to table editing. This alias makes its templates

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 >


D. Relevant configuration excerpts XVI

Figure D.5: Logging

1 # All logs should be rotated with standard logrotate and archived for a

sufficient time.

2 ErrorLog /var/log/apache2/logs/rregister/error.log

3 LogLevel warn

45 # Access log -- beyond application -- can be used to log any request

for any item in the register for posibble (but extensive , and thus

also expensive) audit analysis. Please see Apache 2 documentation

for explanation 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/apache2/logs/rregister/access.log combined

1112 </VirtualHost >


D. Relevant configuration excerpts XVII

D.2 Risk register defaults

Level Impact

Competitive advantage - market share lossLevel 5: > 15 %Level 4 < 15 %Level 3 < 10 %Level 2 < 5 %Level 1 < 2 %Level 0 < 1 %

Legal - regulatory complianceLevel 5 ImprisonmentLevel 5 License to operate revokedLevel 3 Personal convictionLevel 3 FineLevel 2 Official investigation

Productivity - loss of MDLevel 5 > 20 MDLevel 4 < 20 MDLevel 3 < 10 MDLevel 2 < 5 MDLevel 1 < 2 MDLevel 0 < 1 MD

Reputation - external perceptionLevel 5 Continued negative press coverageLevel 5 Customer rating worse than 2.5/5Level 4 Customer rating 2.5/5 and betterLevel 3 Customer rating 3.5/5 and betterLevel 3 Negative press coverageLevel 1 Customer rating 4.0/5 and betterLevel 1 News articleLevel 0 Customer rating 4.5/5 and better

Cost of responseLevel 5 > 100 000 USDLevel 4 < 100 000 USDLevel 3 < 20 000 USDLevel 2 < 10 000 USDLevel 1 < 5000 USDLevel 0 < 500

Source: author. Values in Legal and Reputation (press) categories based on [21, pg. 38] (Risk IT).

Table D.1: Default impacts

D. Relevant configuration excerpts XVIII

[Default user groups]

Group Permissions

user Can log in; implicitly can update own profile.auditor Can access any regular model related to the risk register except for

user profiles.regular user Can access and edit any model except for accessing logs and editing

risk frequencies, impacts.manager Can edit risk frequencies and impacts.administrator Can access risk register logs.

Source: author.

Table D.2: Default user groups

User Groups

user userauditor user, auditorregular user user, regular usermanager user, regular user, manageradministrator user, administratorkarel 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).

vbox

src

epydoc

diagrams

Date post:	04-Feb-2022
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times