Professional Documents
Culture Documents
It Risk Register PDF
It Risk Register PDF
MASTER’S THESIS
IT Risk Register
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
9 Conclusion 73
Bibliography 76
E Diagrams XIX
activity The main actions taken to operate the CobiT 4.1 process [6, pg. 189].
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]).
IT Information Technology.
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].
RACI Responsible, Accountable, Consulted, Informed (see CobiT 4.1 or COBIT 5).
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].
1
For a quick comparison of differences between COBIT versions, see http://www.isaca.org/
COBIT/Documents/COBIT5-Compare-With-4.1.ppt (last retrieved April 4, 2012) for further infor-
mation.
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.
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.
1
BITS does not stand for an acronym.
2
The act (http://www.gpo.gov/fdsys/pkg/PLAW-106publ102/html/PLAW-106publ102.htm,
last retrieved September 10, 2012) mainly repeals the Glass-Steagall Act of 1933 and lifts the
restriction for commercial banks to also act as an investment bank or insurance company (and vice
versa).
2. Risk management 5
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]).
2. Risk management 6
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
3
In line with governance in ISO/IEC 38500:2008.
4
Processes in COBIT 5 are an “evolution” of CobiT 4.1 processes.
2. Risk management 7
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.
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 is
actually achieving its purpose and delivering its required outcomes as expected.”[7, pg. 45]
2. Risk management 8
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.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]):
Risk management processes then would be part of Planning Process and Moni-
toring & Controlling Process groups as knowledge areas:
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]).
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
2. Risk management 12
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:
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):
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,
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:
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.
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:
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 map 1 .
RACI chart on page 76 of Risk IT answers a crucial question – who, in relation
to CobiT 4.1 roles2 , should maintain the register?
1
IT Risk register in Risk IT is an extension of a risk map but in the thesis, risk map is generally
considered a tool within the actual register.
2
Risk IT refers to CobiT 4.1.
3. IT Risk register 20
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:
3
See section 3.3.
4
Probably high security military installations.
3. IT Risk register 21
The extent of being able to capture risk in the register beyond IT operations
and service delivery is questionable – one can assume that the more the IT risk
belongs to the first two categories in Figure 3.3, the less quantifiable it is. However,
it could be useful if the register provided a chance to link IT operations and service
delivery risks to the respective broadly defined (if not quantified) Enablement and
Programme and Project delivery risks.
The problem of aggregating results remains: for example the difference between
impact of risk if the whole enterprise is out of power versus if the outage hits only a
single unit is significant and the risk register would have to be able to capture it.
3. IT Risk register 22
Risk appetite: the broad-based amount of risk a company or other entity is willing
to accept in pursuit of its mission (or vision).
Risk tolerance: the acceptable variation relative to the achievement of an objective.
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 .
5
However, Risk IT suggests that one might knowingly accept risk “associated with regulatory
non-compliance”[20, pg. 17] as a trafe-off if the compliance would be prohibitively expensive.
6
For example IT department is motivated to underestimate risks in the short term to avoid
compliance scrutiny, or overestimate long term risk to retain personnel or higher budget share.
3. IT Risk register 23
Risk avoidance: decision not to become involved in, or action to withdraw from, a
risk situation.
Risk reduction: actions taken to lessen the probability (frequency), negative conse-
quences, or both, associated with a risk.
Risk retention: acceptance of the burden of loss or benefit of gain from a particular
risk.
Risk transfer: sharing with another party the burden of loss or benefit of gain, for a
risk.
Fifth possibility, “Taking the opportunity”, despite not being an alternative to the
four previous options, should always be explored, even though it will not be included
in the register. As The Orange Book [19] notes, two options exist when treating risk
might provide an opportunity to exploit a positive impact – for example improving
IT risk controls could allow taking more risks somewhere else in the project or free
resources that could be used elsewhere. So, any time a risk treatment is proposed,
one should think about the possibility whether lowering the risk to a level further
3. IT Risk register 24
than pure necessity would not provide a benefit far beyond what would lowering risk
right to the necessary level give.
(Another) vocabulary note: the Risk IT framework uses terms “accept” and
“mitigate” for retention and reduction; the author believes that terms from ISO/IEC
27005:2011 represent the treatment (response) in a more direct way (especially
retention). A semantic problem is the relationship between risk treatments and risk
controls (“measure that is modifying risk”[14, pg. 2]). Based on the intended focus
of the risk register on processes and also the perceived meaning, the author employs
the term “risk treatment” (“process to modify risk”[14, pg. 5]) as a substitute for
controls. The ISO/IEC definition conveys the intended message – that risk treatment
is a continuous process that needs to be managed and reviewed, not a measure at a
single point of time. However, in reality of the risk register, the difference is minimal
and depends on the organization using the register (see subsection 7.2.3).
M o R on the other hand ads a mix of reduce and transfer categories as “share”,
defined as sharing both gains and pains from a contract between multiple parties [16,
pg. 23]. However, the author believes that the same effect can be achieved by using
multiple treatments or multiple categories for a single treatment of a single risk .
PRINCE 2 suggests yet another risk treatment (response) option – contingency,
meaning “actions planned and organised to come into force as and when the risk
occurs”[17, pg. 256]. In authors opinion, its importance does not warrant an addition
to the risk register, especially if one compares contingency to “reduction” in the same
methodology, which is “(actions that) limit the impact on the project to acceptable
levels”; the two options are nearly identical.
One last problem is worth mentioning – the issue of costs. In spite of being fairly
simple, the following figure sums up the core decision behind any risk treatment.
• lost productivity,
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”).
“No method is fully objective and results of risk assessment are always dependent
on the person performing them and his/her skills and views.”
IT-risk-related data are typically “of poor quality and quite subjective” (for
example, “process maturity, control weaknesses”).
Complex quantitative methods with limited datasets result in too confident models;
however, simplistic methods can also lead to unreliable expectations about
risk.
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
7
For example by adding ranges to primarily qualitative expert opinions.
3. IT Risk register 28
would still remain in the middle between IT and business risk as it does not capture
real business impact: “impact on customers or in financial terms”[21, pg. 34]. An
extended method then works with transforming business goals into risk expressed as
business consequence.
An approach that goes even further is connecting COBIT business goals with
extended Balanced score card (BSC).
1. The business goals are improve customer service and service continuity.
3. IT Risk register 29
2. CobiT 4.1 maps business goals to IT goal; risk means not achieving IT goal,
which has impact on the prior business goal. The service continuity requires
IT to maintain specific goals, e.g. reducing application defects.
3. Then through CobiT 4.1, the “cascade is continued down to the IT process
level and IT activity level”[21, pg.37]. In terms of CobiT 4.1, this would lead
to ie. AI7 Install and accredit solutions.
4. At the risk analysis level, IT processes are linked to risk scenarios. The end
result is that one can trace IT process failures and events causing them to the
high level business goals.
The full and definitive mapping tailored to COBIT 5 from table Table 3.1 employed
in the register is in Appendix A.
A similar scheme will be used in the risk register to remove possible bias of the
person inputting the data; however, the scheme should be fully adjustable. Another
advantage of the scheme is that it is possible to compare estimates from past years
3. IT Risk register 30
Area
Scale Metric 1 ... Metric i
0
...
n
Source: [21, pg. 39, figure 26]; modified by the author to adhere to Table 3.3 structure.
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.
3. IT Risk register 32
v
uPn
u
t x2i
i=1
xRM S =
n
Where:
xi is impact score from a selected area,
n is number of areas, and
xRM S is the resulting risk impact of the event.
Source: author.
It is evident that root mean square does not “cover” variance as much as square
mean does – the tendency to emphasize higher impacts might even be increased with
certain tweaks to the formula. Despite the results, one must remain wary of any
averages in the register – and the register should provide a way to display events
(scenarios) with low average impact, but a single high impact in a certain area. Also,
in case of known financial impact of event, such impact (“magnitude”) should be
retained within the register and used for precise calculations.
Compared to Risk IT, BITS GAP uses a more traditional expression of incidents
defined through annualized loss expectancy as:
3. IT Risk register 33
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:
• negative publicity,
• loss of customers,
• defense expenses.
Such costs can be higher by several orders of magnitude than the actual value
of lost data. For example, defacement of corporate public website will be viewed
as lax security and will cause media attention, despite the fact that the website is
completely isolated from the corporate intranet and contains no data that is not
considered public. However, guessing such costs is extremely problematic as there is
no reference point: for “regular” incidents, costs are known or can be estimated from
past data but for large, catastrophic incidents, very limited data exists. Another
problem is the average cost for a type of incident, which should be carefully calculated
(preferably as median, to limit a few incidents that skew the scale – e.g. a harddisk
failure causing extremely unusual losses will increase costs of a typical routine disk
failure in a RAID field).
3. IT Risk register 34
In the opinion of the author, Risk IT map has a shortcoming. If one compares risk
bands in the map, the slope of the line between risk bands is not 45 degrees (indicating
that frequency and magnitude do not have same “scale”). Psychologically, it is
understandable to expect points on a line (e.g. between Opportunity and Acceptable)
to have equal “risk” (in terms of combinations of magnitude and frequency), no
matter how unsubstantiated that might be. Therefore it could be useful to display the
risk map with bands as circles – see Figure 3.14. Also, the generalized risk treatment
options (avoidance, retention, reduction, transfer, see Figure 3.6) are indicated in
the map (but merely as a suggestion) and a notion that risk is continuous (instead
of clearly differentiated with risk bands) can be discerned as continuous “rainbow”
instead of four clearly separated bands.
3. IT Risk register 35
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.
?
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.
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.
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 .
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:
• dates, times, and details of key events, e.g. log-on and log-off (b),
• records of successful and rejected data and other resource access attempts
(e)”[13, pg. 55].
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).
4. Additional risk register security requirements 43
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.
12.2 Correct processing in applications All data in Django (and hence in the risk
register) is automatically sanitized at two levels. The templating system10 prevents
any output of malicious code to the users (cross-site scripting) and default templates
6
In the thesis, review can be easily implemented by adding a new field to objects to mark review
status and a custom objects Manager that would filter inactive (non-reviewed) objects from queries
by default.
7
See [10] at https://docs.djangoproject.com/en/dev/topics/auth/.
8
By implementing a JavaScript login form to prevent the browser from recognizing it as a login
prompt.
9
See [10] at https://docs.djangoproject.com/en/dev/topics/auth/
#how-django-stores-passwords; the mechanism follows NIST SP 800-132 Recommenda-
tion for Password-Based Key Derivation – Part 1: Storage Applications.
10
See [10] at https://docs.djangoproject.com/en/dev/topics/security/
#cross-site-scripting-xss-protection
4. Additional risk register security requirements 44
do not override any content escaping11 . At the database level, Django ORM model
prevents using raw SQL12 and all parameters in object queries are sanitized (and the
author did not use the extra() method to access data).
The ORM database layer also automatically enforces checks on input length of
any data.
Two avenues for malicious data remain: file uploads and further use of data
elsewhere. The author maintains that files should be checked within a company-wide
antivirus software. Implementing a rudimentary ClamAV filter is fairly simple if no
company-wide software exists13 .
Processing failures – due to the nature of web applications, the whole request
from the user is performed as one database transaction. In case of any failures, the
database is rolled back to its previous state without any loss of integrity14 .
No checks for internal processing exist, as the nature of data in the register
prevents such checks.
12.3 Cryptographic controls The risk register stores the password in a 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.
11
All potentially dangerous characters are converted to HTML entities.
12
See [10] at https://docs.djangoproject.com/en/dev/topics/security/
#sql-injection-protection
13
With pyclamav library; also see http://code.google.com/p/django-antivirus/ (last re-
trieved August 20, 2012).
14
May not be possible with all database backends. However, the default PostgreSQL fully
supports transactions.
Chapter 5
General requirements are set in the thesis. However, to provide a coherent overview
of the expected functionality, the risk register shall contain the following features.
Area Functionality
Functionality Support COBIT 5 APO12.01 through APO12.04 and store data from
risk identification, estimation, evaluation, treatment and acceptance
phases of ISO/IEC 27005 Risk management process, specifically:
The risk register should also support employing risk tolerance and
appetite levels, rudimentary tracking of project IT risks and allow
quickly displaying data at various levels of aggregation.
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 with
the register.
Apart from standard Python modules, the risk register uses several Django
applications:
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.
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.
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
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.
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.
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.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).
• Enterprise goal
• IT-related goal
• Process (enabler goal)
• Resource
The field failure text contains the mapping between COBIT 5 enterprise goals
and Risk IT business impacts (see Appendix A) for asset type “Enterprise goal”.
Any Asset model can have relations to multiple other Assets (either as a parent
or a child) and the relationship captures additional data (in AssetRelation). The
default implementation only supports expressing the relationship as a binary value
(field importance in AssetRelation), meaning that the child assets can be marked
either as primary or secondary. Changing the relationship to a discreet range (see
subsection 2.1.3) is possible; however, the author opted not to implement such system
1
Django terminology; essentially a Python class with an underlying ORM mapper that allows
permanent storage transparent to the programmer.
2
http://code.google.com/p/fullhistory/ (last retrieved June 10, 2012).
7. Risk register implementation 53
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:
Source: author.
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
3
Stored in RiskEntry model, described later.
7. Risk register implementation 54
and yet no information is lost in the process. One risk is expected to have only one
frequency assigned and frequencies are limited (on a database level) to one per level.
The impact of events (incidents) is much more complicated. The author expects
heavy customization of possible impacts, probably even adding new categories of
impact. This is especially important for companies with specific strategy. Consider
a business with low-cost market positioning (e.g. fast food chains), where lower
customer satisfaction is of a lesser concern that in case of high-end luxury goods
producer. The same applies to press coverage – in case of some companies, any press
coverage might be considered beneficial, yet the risk register considers press coverage
as negative impact.
The default register contains the following categories (stored in constant IM-
PACT AREAS in conf/50 app defaults.conf :
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
7. Risk register implementation 55
of postponing the project, Delivery date change would not be enough unless used in
combination with e.g. competitive advantage.
For an overviews of various levels in each category please see section D.2, Table D.1.
The author assigned Competitive advantage - marketshare loss and Reputation -
external perception levels as an educated guess; Legal - regulatory compliance come
from Risk IT 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.
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.
• it explicitly forces users to think in terms of time, meaning that any risk
treatment should always be reviewed in the future and is not valid forever.
4
For example, one might ponder that governmental organization would accept higher productivity
losses as a tradeoff to lower monetary loss. It doesn’t need to generate any revenue (hence lower
issues with productivity), while even small direct financial costs could be critical due to increased
budget oversight.
5
Economic position of the country etc.
6
RiskTreatmentOption – imagine a broad insurance contract; then RiskTreatment contains
specific information how the broad insurance contract treats risk in the RiskEntry object.
7
Removal is still possible from the admin interface.
7. Risk register implementation 56
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.
The dependencies between risk scenarios and assets (processes in this case) come
11
Even though displaying future values could be useful, it would pose a rather complicated task.
Multiple ElevatedRisk will exist in the future at different points of time. This means that for
example the resulting risk map would have to include another axis (the time element).
7. Risk register implementation 58
from section B.6. The mapping is based on [21, pg. 69 and following] but it was
adapted by the author from CobiT 4.1 to COBIT 5.
The assignment of frequencies and impacts to risk is random. The rationale
for random assignment is the need for data in the register and without proper risk
analysis, any data would be meaningless. Random assignment also removes any
possible bias of the author and allows for more rigorous checking of risk register
output. Basic rules were:
• remaining risks have from one to four impacts from each impact area.
Source: author.
1 In views . py :
2 class P e r m i s s i o n R e q u i r e d M i x i n ( object ) :
3 ( ...)
4 def dispatch ( self , request , * args , * * kwargs ) :
5 permission = " % ( app ) s .% ( action ) s_ % ( model ) s " % { " app " : self .
model . _meta . app_label ,
6 " model " : str (
self . model .
__name__ ) .
lower ( ) ,
7 " action " : self .
action }
8 ( ...)
9 # The p e r m i s s i o n check :
10 if request . user . has_perm ( permission ) or request . user .
11 is_superuser :
12 return super ( PermissionRequiredMixin , self ) . dispatch (
13 request , * args , * * kwargs )
14 ( ...)
15 raise P e r m i s s i o n D e n i ed ( " User does not have permission : % s " %
permission )
16
17 class SecUpdateView ( ( ...) , PermissionRequiredMixin , UpdateView ) :
18 action = " change "
One can then enforce user rights with generic views using a code as simple as the
following excerpt:
Source: author; simplified example. If the risk register gets a request matching regular expression, it
passes object private key (pk), object class Asset and template where the object should be rendered.
In SecUpdateView, the data is manipulated in completely generic way, no matter which object and
where is displayed.
The implementation means that access to all objects within the register is
centralized and can be verified. No standard access apart from generic views exists.
Also, if needed, a REST (or XML) API can use the same implementation by inheriting
from for example SecCreateView and overriding methods of CreateView without ever
altering the permission system. A similar view (OwnershipRequiredMixin) enforces
access rights by checking either a permission to access (edit, delete,...) the object or
whether the user is owner of the object, albeit the view is not used in the register
apart from access to user profiles.
Assignment of user rights is based on Django groups. Overview of existing groups
and assigned permissions is in Table D.2 and Table D.3.User permissions can also be
altered with two Django flags: Staff status allows access to Django admin (and thus
display access to all models) and Superuser status overrides any permission checks
in the register.
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.
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 request
EXCEPTION Exception
LOGIN User logged in
LOGOUT User logged out
OBJECT Object changed
LOGIN TRY Attempted login
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.
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 ).
so on. The generated image as well as data sheet can be downloaded as JPEG and
PNG images and CSV file.
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.
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.
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
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.
• Apache 2.2,
• 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.
ISO/IEC Requirement
27002:2005
section
reference
10.1.1 Document the whole implementation process of the register; document operations of
the 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 risk
register.
6.1.5 Require all personnel maintaining the risk register must accept a non-disclosure
agreement.
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 is
placed in shared rack).
7.2.2 Create an information labeling policy and accordingly assign user groups in the
register.
8.1.1 Create and assign security groups and responsibilities according to a predefined
information security policy.
8.2.2 Ensure that all users of both the risk register and its outputs must have an appropriate
information security awareness and receive training.
8.3.3 Access rights to the register must be modified when the user changes his or her role
in 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-virus
systems 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.
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- Generate a new random string upon installa-
tings.SECRET KEY tion.
Django admin Disable the administration interface in the
production environment via urls.py.
Configuration file set- Set all values to false.
tings/00 deployment.conf
Source: author.
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”.
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:
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.
company needs and risk thresholds. Update descriptions of impacts to local legal
and regulatory landscape, as well as financial impacts.
5. create risk entries for scenarios, estimating frequencies and impacts throughout
the risk analysis process,
To quickly test the risk register, run the VirtualBox virtual machine from the
attached DVD (user rr, password “letmein”).
2
Which should not be expected of any “academic” software, keeping in mind that the last 20 %
of product functionality (the polish) would probably take 80 % of the resources.
3
Albeit there is no “editing” lock in the register, so the users would have to agree on some
separation.
4
Or freely available risk registers under various licences.
5
Including risk register requirements.
Chapter 9
Conclusion
The author has analyzed several key risk management best practices – COBIT 5, Risk
IT, BITS GAP and other methodologies (namely PMBOK) in relation to information
technology risk management. The analysis provided a basic set of ideas that allowed
implementing a model of an IT risk register based on Django web framework and
Python programming language. The goals of the thesis were achieved by the author
at a level and extent reasonable for a 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
[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.
[8] COBIT 5 – Enabling processes. Rolling Meadows, IL, USA: ISACA, 2012. ISBN
978-1-60420-241-0.
[9] CLARKSON, K. W., MILLER, R. L., CROSS, F. B.: Business Law: text and
cases. Twelfth edition. Mason, OH, USA: South-Western, Cengage Learning,
2012. ISBN 978-0-538-47082-7.
Bibliography 76
[10] Django documentation. Version 1.4. [online]. Django Software Foundation [last
retrieved December 8, 2012]. Available from: https://docs.djangoproject.
com/en/1.4/.
[11] DOUCEK, P., NOVÁK, L., SVATÁ, V.: Řı́zenı́ bezpečnosti informacı́. Prvnı́
vydánı́. Praha: Professional Publishing, 2008. ISBN 978-80-86946-88-7.
[12] HINDLS, R., HRONOVÁ, S., SEGER, J.: Statistika pro ekonomy. Páté vydánı́.
Praha: Professional Publishing, 2004. ISBN 80-86419-59-2.
[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.
Appendix A
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.
Enterprise Goal Business Impact
Financial Perspective
Stakeholder value of business investments Inadequate financial return on investment of IT-enabled business investments.
Portfolio of competitive products and services Inadequate products and services, not addressing customer needs, resulting in revenue loss.
Managed business risk (safeguarding of assets) IT-related risks not managed, leaving the company exposed.
Compliance with external laws and regulations Violation of regulations or contracts, resulting in legal fines/damages or personal legal conse-
quences for board and executives.
Improve corporate governance and transparency Inadequate transparency for stakeholders, not meeting client expectations; lack of compliance.
Financial transparency Financial fraud, loss of goodwill.
Customer Perspective
A. COBIT 5 risk mappings
Customer-oriented service culture Bad or insufficient customer service, resulting in client loss.
Business service continuity and availability Inadequate service levels, resulting in customer dissatisfaction and potential revenue loss.
Agile responses to a changing business environment Inability to react to changing market or client requirements on a timely basis, resulting in
revenue loss.
Information-based strategic decision making Wrong strategic decisions on new business initiatives, resulting in client/revenue loss and
shareholder value.
Optimisation of service delivery costs Products or services brought to market at too high a price or inadequate profit margin,
potentially resulting in share value and client loss.
Internal Perspective
Optimisation of business process functionality Inefficient and inadequate operations of the enterprise.
Optimisation of business process costs Lower profitability.
Managed business change programmes Inefficient and inadequate operations of the enterprise, resulting in loss of opportunities.
Compliance with internal policies Inefficient and inadequate operations of the enterprise, resulting in compliance issues.
Operational and staff productivity Inefficient and inadequate operations of the enterprise, resulting in inadequate productivity
and efficiency.
Learning and Growth Perspective
Skilled and motivated people Inability to sustain growth or current operations.
Product and business innovation culture Loss of opportunities, low growth, eroding market share.
Source: [21, pg. 42, figure 29]; the table has been modified by the author to incorporate COBIT 5 enterprise goals wording from [7, pg. 15, figure 5].
Source: [7, pg. 15, figure 5], [6, pg. 169], linked by the author.
Inadequate products and services, not addressing customer needs, resulting in revenue loss. P S
Inadequate transparency for stakeholders, not meeting client expectations; lack of compliance S P
Financial transparency S P P P P
Customer Perspective
Bad or insufficient customer service, resulting in client loss. P S S S
Inadequate service levels, resulting in customer dissatisfaction and potential revenue loss. P S S
A. COBIT 5 risk mappings
Inability to react to changing market or client requirements on a timely basis, resulting in revenue P S S S P
loss.
Wrong strategic decisions on new business initiatives, resulting in client/revenue loss and share- P S S S
holder value.
Products or services brought to market at too high a price or inadequate profit margin, poten- P
tially resulting in share value and client loss.
Internal Perspective
Inefficient and inadequate operations of the enterprise. P S S P
Lower profitability. P S S P S
Inefficient and inadequate operations of the enterprise, resulting in inadequate productivity and P S S
efficiency.
Learning and Growth Perspective
Inability to sustain growth or current operations. P S
Source: [21, pg. 44, figure 31]; the table has been modified and restructured by the author to suit COBIT 5 enterprise goals (Appendix A) rather than CobiT
4.1 business goals.
4 – Predictable process The process operates within defined limits to achieve its
process outcomes.
• 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.
• 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.
• 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.
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.”
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).
Other figures
Source: [17, pg. 12, Figure 2.4]. Processes are withing the rectangle.
D.1 Apache2
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 #).
Level Impact
Competitive advantage - market share loss
Level 5: > 15 %
Level 4 < 15 %
Level 3 < 10 %
Level 2 <5%
Level 1 <2%
Level 0 <1%
Legal - regulatory compliance
Level 5 Imprisonment
Level 5 License to operate revoked
Level 3 Personal conviction
Level 3 Fine
Level 2 Official investigation
Productivity - loss of MD
Level 5 > 20 MD
Level 4 < 20 MD
Level 3 < 10 MD
Level 2 < 5 MD
Level 1 < 2 MD
Level 0 < 1 MD
Reputation - external perception
Level 5 Continued negative press coverage
Level 5 Customer rating worse than 2.5/5
Level 4 Customer rating 2.5/5 and better
Level 3 Customer rating 3.5/5 and better
Level 3 Negative press coverage
Level 1 Customer rating 4.0/5 and better
Level 1 News article
Level 0 Customer rating 4.5/5 and better
Cost of response
Level 5 > 100 000 USD
Level 4 < 100 000 USD
Level 3 < 20 000 USD
Level 2 < 10 000 USD
Level 1 < 5000 USD
Level 0 < 500
Source: author. Values in Legal and Reputation (press) categories based on [21, pg. 38] (Risk IT).
Source: author.
User Groups
user user
auditor user, auditor
regular user user, regular user
manager user, regular user, manager
administrator user, administrator
karel no groups; Superuser flag set to true
Diagrams
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
Source: author.
E. Diagrams XXIII
Source: author.
Appendix F
• 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).