Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky MASTER S THESIS. IT Risk Register

Transcription

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky MASTER S THESIS IT Risk Register Author: Karel Kohout Supervisor: Ing. Luděk Novák, PhD Academic Year: 2012/2013

2 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 ČSN ISO 690 norm. Prague, December 9, 2012 Signature

3 Čestné prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně. Veškeré použité podklady, ze kterých jsem čerpal informace, jsou uvedeny v seznamu použité literatury a citovány v textu podle normy ČSN ISO 690. Dále prohlašuji, že jsem při zpracování diplomové práce nevyužil důvěrných informací, se kterými jsem přišel do styku v zaměstnání ani že jsem v práci vědomě nevyužil know-how zaměstnavatele. V Praze, 9. prosince 2012 Podpis

4 Acknowledgments The author is especially grateful to his advisor, Luděk Novák, for invaluable comments and assistance with the thesis.

5 Abstract The theoretical part of the thesis analyzes several selected methodologies and bestpractices related to information technology risks management, with focus on documents and guidance developed by ISACA. It builds a set of ideas and basic requirements for effective model of an IT risk register. Strong emphasis is placed on mapping CobiT 4.1 based Risk IT to COBIT 5. The practical part describes implementation of an exploratory web-based IT risk register in Python programming language utilizing the Django framework and employs concepts from the analysis. Keywords computer security, risk analysis, IT risk register, COBIT, Risk IT, Python, Django Author s karel@kohout.se

6 Abstrakt Teoretická část diplomové práce analyzuje několik vybraných metodologií z oblasti řízení rizik IT se zaměřením na dokumenty vytvořené profesní organizací ISACA. Výstupem jsou doporučení a základní požadavky na efektivně fungující model registru rizik IT. Text klade velký důraz na propojení COBIT 5 s Risk IT, který vychází z CobiT 4.1. Praktická část popisuje implementaci modelového registru rizik IT v programovacím jazyce Python s frameworkem Django za využití konceptů představených v teoretické části. Klíčová slova informační bezpečnost, analýza rizik, registr rizik IT, COBIT, Risk IT, Python, Django autora karel@kohout.se

7 Contents List of Tables List of Figures Acronyms x xi xiii 1 Introduction 1 2 Risk management Methodologies and frameworks BITS Technology Risk Transfer Gap Analysis Tool (BITS GAP) Risk IT Framework (Risk IT) COBIT Risk and project management PMBOK PRINCE Risk and risk management overview Risk management in CobiT 4.1 and COBIT Chapter summary IT Risk register Risk Business risk Tolerance and appetite Risk treatment IT risk communication Expressing risk Expressing risk frequency Expressing risk impact Risk maps Risk scenarios

8 Contents viii 3.2 Various notes Liability Effects of risk management and virtual risk Limitations and omissions of the thesis Chapter summary Additional risk register security requirements 40 5 Risk register requirements summary 45 6 Risk register platform Software choice and requirements server side Software requirements client side Possible software issues Risk register implementation Risk register components Userinterface and tests Risk register models Assets Impacts Risk treatment Risk, risk assessment and risk scenario Notes on implementation Django customization and configuration files User rights checks Audit trail (logs) Point of time view Test data in the register Analytical views and data access Risk maps Violations and top risks Expected issues Chapter summary Customizing, deploying and using the register Hardware and software requirements Information security Responsibility COBIT 5 customization

9 Contents ix Goal cascade User rights and access Impact and frequency scales Risk scenarios User manual quickstart Less visible features Possible uses of the risk register 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 Apache XIV D.2 Risk register defaults XVII E Diagrams XIX F Content of Enclosed DVD XXIV

10 List of Tables 2.1 Alignment of ISMS and InfoSec Risk Management Process ISO/IEC 27005:2011 risk assessment process COBIT 5 APO12 activities COBIT (BSC) Risk Description in Business Terms (examples) Example frequency scales Generic impact scales of an event Impact scales example Root mean square rationalization ISO/IEC On-Line Transactions control Suggested user roles Requirements summary Frequency scales Types of events General security requirements IT Risk register installation 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 IX D.1 Default impacts XVII D.2 Default user groups XVIII D.3 Default users XVIII

11 List of Figures 2.1 GLBA Subtitle A Disclosure of Nonpublic Personal Information Relationship between Risk IT, ValIT and CobiT COBIT 5 product family COBIT 5 goal cascade COBIT 5 enterprise enablers PMBOK project management process groups PMBOK risk-related processes (inputs and outputs) in Planning Process Group PMBOK risk-related processes (inputs and outputs) in Monitoring & Controlling Process Group Information security risk management process Increasing IT risk exposure APO12 RACI chart IT risk register RACI chart IT risk categories Risk IT risk hierarchy Tolerance and appetite Risk culture Risk treatment options Balancing the risk Risk information properties Risk expression methods limitations Extended Balanced Score Card criteria expressing risk impact Root mean square Annualized Loss Expectancy (ALE) Risk map with risk appetite bands Modified risk map IT Risk scenario development IT Risk scenario components

12 List of Figures xii 7.1 Risk register ER (entity-relationship) diagram Asset types Impact categories Default risk scenario values Configuration files layout Permission check in views PermissionRequiredMixin Permission check in views urls.py Immutable logs 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

13 Acronyms and definitions activity The main actions taken to operate the CobiT 4.1 process [6, pg. 189]. ALE Annualized Loss Expectancy, see Figure API BSC CSRF DDoS Application Programmable Interface. Balanced Score Card. Cross-Site Request Forgery. 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 IT ITIL KGI KPI Information Technology. 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]. 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]. 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

14 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 OGC National Institute of Standards and Technology, Department of Commerce. 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 risk SOX Request For Comments (document, Internet standards-related specification ; source: RFC 2026, last retrieved November 11, 2012). Effect of uncertainty on objectives (a deviation from the expected positive and/or negative) [15, pg. 1]. 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].

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

16 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 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 COBIT/Documents/COBIT5-Compare-With-4.1.ppt (last retrieved April 4, 2012) for further information.

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

18 2. Risk management BITS Technology Risk Transfer Gap Analysis Tool (BITS GAP) The document was created by BITS 1 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 things 2, mandates formal information technology risk assessment process in Subtitle A Disclosure of Nonpublic Personal Information (see Figure 2.1). Figure 2.1: GLBA Subtitle A Disclosure of Nonpublic Personal Information (b) Financial Institutions Safeguards. In furtherance of the policy in subsection (a), each agency or authority described in section 505(a) shall establish appropriate standards for the financial institutions subject to their jurisdiction relating to administrative, technical, and physical safeguards 1. to insure the security and confidentiality of customer records and information; 2. to protect against any anticipated threats or hazards to the security or integrity of such records; and 3. to protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer. Source: Gramm-Leach-Bliley Act, 106th Congress Public Law 102, TITLE 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 ( 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).

19 2. Risk management Risk IT Framework (Risk IT) Risk IT is a framework produced by the ISACA organization to improve enterprise management of risks related to information technology and IT activities. It complements COBIT (or rather CobiT 4.1) in a way that it sets good practices to identify, govern and manage IT risk [20, pg. 7]. It is a key framework used throughout this thesis as Risk IT contains a concise definition of concepts within the register. Figure 2.2: Relationship between Risk IT, ValIT and CobiT 4.1 Source: [20, pg. 7, Figure 1]. Note: ValIT is not used in the thesis as an important source of information COBIT 5 COBIT 5 ( A Business Framework for the Governance and Management of Enterprise IT ), released in 2012, and its older sibling CobiT 4.1 ( Control Objectives for Information and related Technology from 2007) represent 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]).

20 2. Risk management 6 Figure 2.3: COBIT 5 product family Source: [7, pg. 11, Figure 1]. Because some products within the framework are still to be released in the future (as of July 2012), certain parts of the thesis refer to CobiT 4.1 instead of COBIT 5; however, where possible, COBIT 5 is used. The risk register in the thesis will be designed to support COBIT as much as possible, therefore the author would like to iterate over several (no doubt well known) concepts of COBIT for later reference. COBIT is a high-level framework, more focused on providing control over IT and less on the actual enactment (which would be the domain of ITIL). It supports enterprise governance by providing assurance about the value of IT [6, pg. 5] and is based on opinions of experts, not a legislation which is apparent from the focus on value of IT and business goals, rather than compliance (in contrast to BITS GAP). COBIT is process oriented; its 37 processes are split into two process domains: Governance with five evaluate, direct and monitor (EDM) processes 3 and Management with processes in four domains: Align, Plan and Organise (APO), Build, Acquire and Implement (BAI), Deliver, Service and Support (DSS) and Monitor, Evaluate and Assess (MEA) 4. The register must map assets and risk scenarios (defined later) to individual processes. Notation: processes are marked as a regular expression [A-Z][A-Z][A-Z][1-9] (i.e. APO12 Manage Risk). For the full reference model, see Figure B.1. Tracking process maturity levels (CobiT 4.1) in the register, would in the 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: Processes in COBIT 5 are an evolution of CobiT 4.1 processes.

21 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 achieves 5 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 is actually achieving its purpose and delivering its required outcomes as expected. [7, pg. 45]

22 2. Risk management 8 Figure 2.5: COBIT 5 enterprise enablers Source: [7, pg. 27, Figure 12]. See section B.3 for definitions. The older information criteria in Cobit 4.1 have been replaced (to some extent) by the COBIT 5 Information Model and its information enablers (see Figure 2.5 and [7, Appendix F]). However, the guideline COBIT 5: Enabling Information is still in the process of being published. The risk register in the thesis is agnostic to either information enablers or information criteria both can be easily implemented and linked to assets. If the need ever arises, the author proposes that using older CobiT 4.1 information criteria, tied to COBIT 5 enterprise goals (see Table A.3) might be an option. Information criteria are defined as business requirements for information [6, pg. 10] and extended beyond the traditional CIA 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 period 7 ), the author would like to introduce several concepts from project management methodologies too in the hope that the resulting risk register might partially support certain project management issues. 6 Confidentiality, integrity, availability. 7 Notwithstanding the fact that COBIT 5 now contains BAI01 Manage Programmes and Projects process and a management practice BAI01.10 Manage programme and project risk.

23 2. Risk management 9 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 selected 8 project methodologies and point out parts related to risk management PMBOK The Project Management Institute s (PMI) Project Management Body of Knowledge (PMBOK, 4th edition) can serve as a great guide to explain several project management problems and relate project management to IT risk management. The main project management process groups are summarised in the following figure (for a detailed interaction map, see [1, pg. 274, Fig 11.1]): Figure 2.6: PMBOK project management process groups Source: [1, pg. 40, Figure 3.1]. Risk management processes then would be part of Planning Process and Monitoring & Controlling Process groups as knowledge areas: 11.1 Plan Risk Management, 11.2 Identify Risks, 11.3 Perform Qualitative Risk Analysis, 11.4 Perform Quantitative Risk Analysis, 11.5 Plan Risk Response, 8 Haphazardly.

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

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

26 2. Risk management 12 (Management of Risk) is one of the components of PRINCE 2 and is embedded within all its processes (see Figure C.1 for an overview of all processes and components). Due to the length of the thesis and PRINCE 2, the author has decided to omit a broader introduction. Various items from PRINCE 2 were incorporated in the text and the reader is kindly referred to chapter 2 of PRINCE 2 [17] for a broader introduction to the methodology. 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 management. For the sake of compatibility, ISO/IEC 27005:2011 and where necessary, ISO/IEC 31000:2009 Risk management Principles and guidelines, will be used. First, 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 objectives 9, 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 project 10. Risk management process is then a systematic application of management policies, procedures and practices to the activities of communicating, consulting, establishing the context, and identifying, analyzing, evaluating, treating, monitoring and reviewing risk [15, pg. 3]. Of all the properties of risk management in ISO/IEC 31000:2009, the author would like to point out property e), stating that risk management is systematic, structured and timely and that such approach contributes to efficiency and to consistent, comparable and reliable results (of risk management) [15, pg. 8]. This property is one of the underlying reasons for maintaining a high-quality risk register, as a risk register, at its core, is nothing more than a tool to store (and analyze) certain risk management data. 9 E.g. financial, health and safety, and environmental goals. 10 A very vivid example of the term risk (paraphrased from prof. Allen Garth, University of Northern Colorado) is the risk arising from jumping off the Empire State Building there is no risk. The person jumping can be baring a miracle sure that after a few seconds of flight, death will inevitably follow; the outcome is certain and carries no risk at all.

27 2. Risk management 13 The definition is almost identical to BITS GAP (where risk assessment is a knowledge process that documents the measurable security state of a system using the consensus judgments of system stakeholders that is employed to determine the appropriate technical and non-technical safeguards to be applied to reduce specific risks to acceptable levels [5, pg. 7]); ISO/IEC one is slightly broader and places less emphasis on quantifiability. The next figure, a diagram of an information security risk management process contains all of the phases mentioned in the previous definition and is an application of the generic risk management process from [15]. Figure 2.9: Information security risk management process Source: [14, pg. 8, Figure 2]. 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

28 2. Risk management 14 similar. The risk register should support and store generic data from most phases, including monitoring and review (the time component). The reader is kindly referred to the source document for a detailed description of each phase. To put the process in context, a following mapping exists to the PDCA Information security management system (ISMS) model from ISO/IEC 27001:2005: ISMS Process Plan Do Check Act Information Security Risk Management Process Establishing the context, Risk assessment, Developing risk treatment plan, Risk acceptance Implementation of risk treatment plan Continual monitoring and reviewing of risks Maintain and improve the Information Security Risk Management Process Source: [14, pg. 9, Table 1]. Table 2.1: Alignment of ISMS and Information Security Risk Management Process The risk register should help with all phases but context establishment as one can note in [14], context establishment phase of risk management is mainly about setting boundaries, scope and more importantly, purpose of risk management (which can range from supporting ISMS to preparing business continuity and incident response plans 11 ). 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 (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 ]. The full ISO/IEC 27005:2011 risk assessment process is as follows: 11 Specifically, the risk register will not support ranking risks against the risk evaluation criteria [14, pg. 13].

29 2. Risk management 15 Phase Step Tasks Identification of assets Risk identification Identification of threats Identification of existing controls Identification of vulnerabilities Risk analysis Risk evaluation Identification of consequences Assessment of consequences Assessment of incident likelihood Level of risk determination Source: [14, pg ]. Tasks are paraphrased. Create of list of assets and related business processes, determine relevance. Determine threats, identify their type and source. Select future (planned) and check existing controls and their usage. Relate vulnerabilities to assets, threats and controls, review vulnerabilities not related to any threat. Create incident scenarios and their impact on assets and business processes. Assemble a list of assessed consequences of incident scenarios with respect to assets. Evaluate likelihood of incident scenarios (quantitative or qualitative). Prepare a list of risks with value levels assigned. Finalize a list of risks prioritized according to risk evaluation criteria in relation to the incident scenarios that lead to those risks. 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

30 2. Risk management 16 is assessed using both quantitative and qualitative measures (BITS GAPS strongly prefers quantitative approach). To finish building the vocabulary, asset is anything that has value to the organization [14, pg. 14] and resource is anything that helps to achieve IT goals [20, pg. 26]. A problem arises from a discrepancy between COBIT and ISO/IEC information security standards. ISO/IEC 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].

31 2. Risk management Risk management in CobiT 4.1 and COBIT 5 The underlying requirement to perform risk management is present both in CobiT 4.1 and COBIT 5. However, the earlier framework mentions (unspecified) risk management process (framework) in a single process PO9.1 IT Risk Management Framework. In the newer iteration, the responsibilities are split into two and have much more specific wording. The high-level enterprise governance duty to maintain the risk register is primarily derived from EDM03 Ensure Risk Optimisation process, whose purpose is to ensure that IT-related enterprise risk does not exceed risk appetite and risk tolerance, the impact of IT risk to enterprise value is identified and managed, and the potential for compliance failures is minimised. [8, pg. 39] (see RACI chart at page 39 of [8] for further details). The lower managerial level APO12 Manage Risk then assigns responsibilities to management to continually identify, assess and reduce IT-related risk within levels of tolerance set by enterprise executive management [8, pg. 107]. APO12 is so crucial to the thesis that it warrants a detailed look. The following figure presents all responsibilities in the process: Figure 2.11: APO12 RACI chart Source: [8, pg. 108]. There are six activities in the process:

32 2. Risk management 18 Activity APO12.01 Collect data APO12.02 Analyse risk APO12.03 Maintain a risk profile APO12.04 Articulate risk APO12.05 Define a risk management action portfolio APO12.06 Respond to risk Management practice Identify and collect relevant data to enable effective ITrelated risk identification, analysis and reporting. Develop useful information to support risk decisions that take into account the business relevance of risk factors. Maintain an inventory of known risk and risk attributes (including expected frequency, potential impact and responses) and of related resources, capabilities and current control activities. Provide information on the current state of IT-related exposures and opportunities in a timely manner to all required stakeholders for appropriate response. Manage opportunities to reduce risk to an acceptable level as a portfolio. Respond in a timely manner with effective measures to limit the magnitude of loss from IT-related events. 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.

33 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 map 1. RACI chart on page 76 of Risk IT answers a crucial question who, in relation to CobiT 4.1 roles 2, 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.

34 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 solutions 3 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 situations 4 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 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 Probably high security military installations.

35 3. IT Risk register 21 Figure 3.2: IT risk categories Source: [20, pg. 7, Figure 2]. Figure 3.3: Risk IT risk hierarchy Source: [20, pg. 11, Figure 3]. 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.

36 3. IT Risk register Tolerance and appetite Risk IT notes the difference between risk tolerance and risk appetite (based on COSO ERM framework, but the definition is also compatible with the ISO 31000): Figure 3.4: Tolerance and appetite Risk appetite: the broad-based amount of risk a company or other entity is willing to accept in pursuit of its mission (or vision). Risk tolerance: the acceptable variation relative to the achievement of an objective. Source: [20, pg. 17]. The actual levels will be based on the ability of the organization to contain loss and 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 requirements 5. 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 data 6. 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.

37 3. IT Risk register 23 Figure 3.5: Risk culture Source: [21, pg. 25, Figure 19] Risk treatment Four possible actions, depending on risk impact and frequency, exist: avoidance, reduction, retention and transfer. Figure 3.6: Risk treatment options Risk avoidance: decision not to become involved in, or action to withdraw from, a risk situation. Risk reduction: actions taken to lessen the probability (frequency), negative consequences, or both, associated with a risk. Risk retention: acceptance of the burden of loss or benefit of gain from a particular risk. Risk transfer: sharing with another party the burden of loss or benefit of gain, for a risk. Source: [14]; italics: author. Fifth possibility, Taking the opportunity, despite not being an alternative to the four previous options, should always be explored, even though it will not be included in the register. As The Orange Book [19] notes, two options exist when treating risk might provide an opportunity to exploit a positive impact for example improving IT risk controls could allow taking more risks somewhere else in the project or free resources that could be used elsewhere. So, any time a risk treatment is proposed, one should think about the possibility whether lowering the risk to a level further

38 3. IT Risk register 24 than pure necessity would not provide a benefit far beyond what would lowering risk right to the necessary level give. (Another) vocabulary note: the Risk IT framework uses terms accept and mitigate for retention and reduction; the author believes that terms from ISO/IEC 27005:2011 represent the treatment (response) in a more direct way (especially retention). A semantic problem is the relationship between risk treatments and risk controls ( measure that is modifying risk [14, pg. 2]). Based on the intended focus of the risk register on processes and also the perceived meaning, the author employs the term risk treatment ( process to modify risk [14, pg. 5]) as a substitute for controls. The ISO/IEC definition conveys the intended message that risk treatment is a continuous process that needs to be managed and reviewed, not a measure at a single point of time. However, in reality of the risk register, the difference is minimal and depends on the organization using the register (see subsection 7.2.3). M o R on the other hand ads a mix of reduce and transfer categories as share, defined as sharing both gains and pains from a contract between multiple parties [16, pg. 23]. However, the author believes that the same effect can be achieved by using multiple treatments or multiple categories for a single treatment of a single risk. PRINCE 2 suggests yet another risk treatment (response) option contingency, meaning actions planned and organised to come into force as and when the risk occurs [17, pg. 256]. In authors opinion, its importance does not warrant an addition to the risk register, especially if one compares contingency to reduction in the same methodology, which is (actions that) limit the impact on the project to acceptable levels ; the two options are nearly identical. One last problem is worth mentioning the issue of costs. In spite of being fairly simple, the following figure sums up the core decision behind any risk treatment. Figure 3.7: Balancing the risk Source: [17, pg. 256, Figure 17.3].

39 3. IT Risk register 25 Insurance as a risk treatment Insurance as such serves to convert uncertain costs to company assets to a fixed price (risk transfer). It is impertinent to evaluate effectiveness of insurance coverage to past incidents, both in terms of actual versus expected costs of the incident (see BITS GAP [5, pg. 14]) and uncovered coverage gaps. Being reimbursed by the insurance company creates a new cost and requirement extensive documentation, and the organization must include the actual cost of proof of the incident in the cost of risk transfers. Maintenance of forensic data requires a sound chain of custody. Underwriting process itself takes some time and the cost should be added to risk transfer costs. The overall effectiveness of insurance policies and applicability to systemic risks related to the Internet [5, pg. 16] are questioned too in BITS GAP. The ability to assess the value of certain assets is lacking especially loss-costs, often accompanying information security incidents, such as: lost business opportunity, lost productivity, reputation damage (according to [5, pg. 16]). Insurance of very specific items, including whole business procedures and processes is generally impossible. Data loss will usually relate to loss of the physical storage medium; intermediary storage (RAM of a server) is excluded. Modern storage methods third party clusters and especially cloud computing services (Amazon S3 storage or content distribution by Akamai) only increase the problem, as the exact geographical location and method of data storage may be unknown to the company. Also, a significant price difference is present between the policy for cost of reproduction of data and a policy covering possible losses from stolen records or revealed confidential materials (reproduction costs vs. inherent value of data ) 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.

40 3. IT Risk register 26 Information in the risk register must adhere to the following principles: Figure 3.8: Risk information properties Clear: known and understood by all shareholders. Concise: includes avoiding jargon and avoiding technical terms. Useful: relevant, sent to appropriate parties. Timely: communication is timely when it allows action to be taken in the critical moment between risk origination and its potential business consequence. Aimed at correct target audience: aggregation must not hide root causes of risk, yet high-level data is needed for policymakers. Available on need-to-know basis: both internal and external parties must have a genuine need to know risk-related data. Source: [20, pg. 20]; paraphrased by the author. The Clear and Concise properties will be achieved by providing sufficient aggregation of data in the register, ie. the ability to get both a general overview of risk with regard to business processes and a detailed technical information. The author considers unwise to avoid actual technical details, as that would remove the underlying source of risk data and the aggregated risk would be meaningless. The Useful property is a focus of the risk register manual and Timely will be solved through a dashboard and assigning time-based reminders to items in the register. The Available on need-to-know basis is discussed in chapter 4 with regard to ISO/IEC Poor risk communication and awareness is a base for false confidence and will lead to unbalanced communication to the external world on risk [21, pg. 19], harming relations with clients, investors, regulators or shareholders. It might also lead to a perception of covering up known risks from stakeholders [21, pg. 19]. As for clerical communication details of IT risk register data, the example Risk IT risk register entry template ([21, pg. 48]) tracks last risk assessment date and also due date for update of the risk assessment. This field might be used in the register in several ways: to remind the users about pending assessments and to disregard any risk treatments that have not been updated after due date; such approach helps with fulfilling risk information properties (Figure 3.8) as it prevents basing risk assumptions on false or invalid data (especially the Timely component). A reasonable implementation might be a view of risks not assessed after a set date. PMBOK Project communication section can serve as an inspiration for management of communication within the register and several requirements for an advanced register might be derived. The hypothetical register should track how is information

41 3. IT Risk register 27 about risk distributed as certain stakeholders (especially higher up in the structure) will need general information about risks, yet any automated output will not be able analyze and summarize the information. Thus, the register should assign a task to an individual employee(s) to create a summary of the selected parts of the register and inform the stakeholder and store when the distribution occurred. The register should also track if any action was required in the report. Such communication procedures would also be in line with the recommendations of M o R [16, pg. 16]. Unfortunately, such requirements would extend author s risk register beyond the scope of master s thesis Expressing risk Closely related to risk communication is the problem of describing risk [21, pg. 33]. Both quantitative and qualitative methods have limitations: Figure 3.9: Risk expression methods limitations No method is fully objective and results of risk assessment are always dependent on the person performing them and his/her skills and views. IT-risk-related data are typically of poor quality and quite subjective (for example, process maturity, control weaknesses ). Complex quantitative methods with limited datasets result in too confident models; however, simplistic methods can also lead to unreliable expectations about risk. Source: [21, pg. 33], paraphrased by the author. The risk register should use a mix of qualitative and quantitative approaches to leverage their advantages and avoid some of the disadvantages and lean towards quantitative analysis where possible 7. 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 unambiguous and clear business-relevant terms [21, pg. 34], which should be the approach supported by the risk register in this thesis, with the help of one of the presented methods, a link to COBIT. The business impact of any IT-related event (then) lies in the consequence of not achieving the information criteria efficiency, effectiveness, confidentiality, integrity, availability, compliance, reliability. However, such method 7 For example by adding ranges to primarily qualitative expert opinions.

42 3. IT Risk register 28 would still remain in the middle between IT and business risk as it does not capture real business impact: impact on customers or in financial terms [21, pg. 34]. An extended method then works with transforming business goals into risk expressed as business consequence. Business Goal Provide a good return on investment of ITenabled business investments. Improve corporate governance and transparency. Improve customer orientation and service. Offer competitive products and services. Risk Expressed as Business Consequence There is inadequate return on investment of IT-enabled business investments. Inadequate financial transparency for markets reflects on share value and compliance risk. Bad or insufficient customer service results in client loss. Ineffective products and services do not address customer needs, resulting in revenue loss. Source: [21, pg. 35, figure 24]. Table 3.1: COBIT (BSC) Risk Description in Business Terms (selected examples) An approach that goes even further is connecting COBIT business goals with extended Balanced score card (BSC). Figure 3.10: Extended Balanced Score Card criteria expressing risk impact Financial : Share value, Profit, Revenue, Cost of capital Customer : Market share, Customer satisfaction, Customer service Internal : Regulatory compliance Growth : Competitive advantage, Reputation Source: [21, pg. 35]. However, this extended approach must be modified in an implemented risk register as the author believes that impact in terms of extended BSC criteria is individual for each organization and cannot be generalized it must be custom-tailored to each IT risk register instance. A practical example of mapping atomic IT event and business goals [21, pg.37] with CobiT 4.1 from the Risk IT 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.

43 3. IT Risk register 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 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 ; 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

44 3. IT Risk register 30 to actual rate of occurrence and adjust accordingly current estimates of frequency. Ultimately, the choice of scale will be based on the risk assessment method, unless the method and software support are tightly connected as is the case of CRAMM 8. 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 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 8 CCTA Risk Analysis and Management Method.

45 3. IT Risk register 31 scales to the needs of the enterprise. Area Scale Metric 1... Metric i 0... n Source: [21, pg. 38, figure 25]. Table 3.3: Generic impact scales of an event The metric should preferably be quantitative; if multiple metrics are applicable in the area, the one with the highest ranking (impact) is the risk impact of the event in the area. One event can have several impacts in different areas (e.g. legal, financial, regulatory as in the following table). Legal Regulatory non-compliance Impact Legal Financial (USD); up to License to Operate 0 $0 1 $1,000,000 2 $2,000,000 3 Personal conviction $5,000,000 Fined 4 $10,000,000 5 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.

46 3. IT Risk register 32 Where: x i Figure 3.11: Root mean square n i=1 x RMS = n is impact score from a selected area, n is number of areas, and x RMS is the resulting risk impact of the event. x 2 i Source: [12, pg. 33]. The rationalization of root mean square is in the following table: Risk impacts from three areas Arithmetic mean 2, 2, , 2, , 2, , 1, Root mean square (rounded to two digits) 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:

47 3. IT Risk register 33 Figure 3.12: Annualized Loss Expectancy (ALE) AV EF ARO = ALE Where: ALE annualized loss expectancy, ARO annualized rate of occurrence, EF exposure factor (threat severity), AV asset value. Source: [5, pg. 12]. 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).

48 3. IT Risk register 34 As for project management methodologies, the impact scales can be extended into several categories. PMBOK [1, pg. 281] suggests using cost, scope or quality change, in addition to pure cost, as examples however, the categories should be tailored to individual organization s needs 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 Source: [21, pg. 46, Figure 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 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.

49 3. IT Risk register 35 Figure 3.14: Modified risk map Source: author. The actual risk treatment is more a matter of financial decision through for example ALE (see Figure 3.12) and subsequent return-on-risk (or ROSI returnon-security) calculations as it is possible that with a set budget, treating several lower risks with result in much lower ALE than treating a single risk with high ALE (or combination of frequency and magnitude). Such analysis is of course out of the scope of the thesis and would probably be performed on specific data extracted from the register 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.

50 3. IT Risk register 36 Figure 3.15: IT Risk scenario development Source: [21, pg. 52, Figure 37]. Risk IT provides a very agreeable overview of scenario components: Figure 3.16: IT Risk scenario components Source: [21, pg. 55, Figure 39].

51 3. IT Risk register Various notes Liability The difference between being attacked and being a source-proxy of an attack may create a coverage gap abuse of infrastructure is typically not covered under insurance; neither is provided coverage against vicarious liability 9 or human error. A recommendation for risk management should be that transferring risk with insurance creates a new, secondary risk Effects of risk management and virtual risk A good risk management can have a profound effect on the organization and its risktaking behavior. A common sense might suggest that the better the risk management process (and the better the data in the register), the better the approach to risk, despite the fact that in reality, the effect could be completely opposite. As Adams notes in [2], a common belief states that seat belts reduce casualties in road accidents. However, the issues gets rather complicate if we take into account wider timeframe. Do seat belts affect risk taking behavior? Could it be that the nett effect of seat belts is lower than we think, because while a seat belt saves life during an accident, it makes people cause more accidents by making us feel safer (and thus drive faster and more aggressively)? The same can be inferred for the risk register the better the data, the closer to any safety margin can the organization get. If we expect on average 20 hardware failures in a datacenter per day and from previous years calculate that within the 95 % confidence interval, there will be no more than 25 failures, then any inventory of replacement hardware can be lowered to 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 an employee in the scope of employment [9, pg. 648] (under the common law doctrine of respondeat superior). 10 A reasonable organization would have plans for events outside the interval (insurance, temporary technical solutions), but the idea is to present a simplified example.

52 3. IT Risk register 38 and virtual risks (cell phones use? cancer death) 11. Virtual risks may or may not exist, but they have real consequences people act on the meanings that they impose on uncertainty [2, pg. 29]. For the risk register, virtual risks create a problem with risks that cannot either be scientifically measured at all or cannot be measured with the dataset available to the organization. A common virtual risk could be the feeling of being a direct target of an attack while the actual attack was only circumstantial result of looking for weak spots across a set of organizations. On the other hand, due to the existence of endless amount of random attacks (for example, automatic robots guessing FTP account passwords), the organization could decide to not assign any meaning to a directed attack. 3.3 Limitations and omissions of the thesis Numerous items are omitted from the thesis: risk culture, psychology of risk, communication of risk would all warrant a more detailed look (as [20] suggests), and methods encouraging people to fill the register could definitely suffice as a topic for another text. Also, 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 11 Examples made up by the author of the thesis.

53 3. IT Risk register 39 be apparent, it is implemented in the register through a proxy object (RiskEntry, detailed later) but the relationship is only indirect. No interfaces to other systems are considered, but an extension of the register could for example include data from intrusion detection systems (IDS). 3.4 Chapter summary The author has explored various concepts of business risk and the thesis introduced the definition of risk register as a database (in the general information sense, not as a software product) supporting providing detailed information on each identified risk [21, pg.48]. The chapter continued with risk tolerance and appetite as two distinct terms, possible risk treatments (risk avoidance, reduction, retention and transfer) and discussion of relationship between risk treatment and risk controls. A significant part of the text is also dedicated to expressing risk in quantitative and qualitative ways; various methods to calculate or assess risk impact and frequency are discussed and the author defined preliminary scales that will be used in the implementation part of the thesis. The reader was also presented with risk scenarios as an invaluable tool to identify risk and with two ways to establish risk scenarios, and risk maps were introduced too as a graphical representation of 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.

54 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 security 1. This chapter knowingly omits physical security of the register (such as access of personnel to a database server) or any measures that are not directly related to risk register implementation as a software program running in void. All core controls (item 0.6 Information security starting point) will be considered. All requirements that are critical during the implementation have been included in the Implementation guide (Chapter 5, Table 8.1). The following part contains comments on several ISO/IEC 27002:2005 controls that are not part of the table in Chapter 5. The reader is kindly asked to keep in mind that all requirements not directly affecting risk register as a software stack are placed in Chapter 5 in the implementation checklist. This includes for example backups. 6 Organization of information security The external requirements (6 Organization of information security) are left to the user of the risk register, as they depend on the individual implementation and access of third parties; the register itself only prevents any unauthorized access of external parties. 1 More stringent requirements, for example memory separation, are probably unrealistically expensive, especially considering the type of data (known risks) in the register. Also see Figure C.2.

55 4. Additional risk register security requirements Information classification Any information within the register is considered to be classified and private 2. All parts of the register and output from the register will display an appropriate label (for example, Confidential ) 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 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 cannot 3 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 program 4 and all text fields are automatically sanitized to prevent SQL injections and cross-site scripting On-Line Transactions The risk register works as a web application, so fulfilling this control bears an utmost importance. While the ISO/IEC 27002:2005 control is focused on e-commerce, it remains valid for any high-security web application; it requires that information involved in on-line transactions should be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay. [13, pg. 54]. Within the register, the control is established in the following ways: 2 The statement is not completely valid for publicly listed companies that are typically obliged by law to disclose certain facts to shareholders (owners of shares) and the general public. 3 In an idealistic world without insecure web browsers. 4 general_tools/file.py contains a function content file name() that can be used to hook the virus scanner to an external anti-virus program; a safer option would be to implement a custom filestorage in Django (extend an existing one). The same approach is possible to implement digital signatures and timestamps for all uploaded files. 5 Which happens by default with the Django library.

56 4. Additional risk register security requirements 42 Item to prevent Solution Incomplete transmission SSL encryption (mod openssl); see section D.1. Mis-routing n/a Unauthorized message alteration SSL encryption (mod openssl); also, clickjacking protection in Django. Unauthorized disclosure SSL encryption (mod openssl). Unauthorized message duplication SSL encryption (mod openssl); cross-site request forgery (CSRF) protection in Django. Unauthorized message replay SSL encryption (mod openssl); cross-site request forgery (CSRF) protection in Django. Source: author; Django documentation, [13], [3]. Table 4.1: ISO/IEC 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 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 Access control User access is controlled at a technical level within the application. However, the larger issue of assigning access must be tackled during the register implementation (and is specifically required in chapter 8).

57 4. Additional risk register security requirements 43 Role user edit logs user administrator Source: author. Permissions Can access the register interface and log-in. Can edit items in the register. Can access risk register logs. Can assign and remove user roles. 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 data 6 ). 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 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 practices 7 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 template 8, 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 Session time-out Control and follows most of items in Password management system; passwords are stored as salted hashes 9. The user has no access to system utilities from the web application Correct processing in applications All data in Django (and hence in the risk register) is automatically sanitized at two levels. The templating system 10 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 8 By implementing a JavaScript login form to prevent the browser from recognizing it as a login prompt. 9 See [10] at #how-django-stores-passwords; the mechanism follows NIST SP Recommendation for Password-Based Key Derivation Part 1: Storage Applications. 10 See [10] at #cross-site-scripting-xss-protection

58 4. Additional risk register security requirements 44 do not override any content escaping 11. At the database level, Django ORM model prevents using raw SQL 12 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 exists 13. 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 integrity 14. No checks for internal processing exist, as the nature of data in the register prevents such checks Cryptographic controls The risk register stores the password in a cryptographically secure way (see 11 Access control). All access must be performed through a properly configured web server over SSL encrypted connection. Proper server configuration is in section D.1. No further cryptographic controls exist; it would be possible to create cryptographically signed PDF files with data from the register by customizing some of the templates and using LaTeX together with for example Adobe LiveCycle Digital Signatures ES2 for processing. Built-in Django issues The built-in Django adminstration interface, while perfect for initial data input, accesses all models at a low level, bellow any risk register views. Therefore, it could be used to avoid certain parts of the logging system (detailed later) and should be disabled by default. 11 All potentially dangerous characters are converted to HTML entities. 12 See [10] at #sql-injection-protection 13 With pyclamav library; also see (last retrieved August 20, 2012). 14 May not be possible with all database backends. However, the default PostgreSQL fully supports transactions.

59 Chapter 5 Risk register requirements summary General requirements are set in the thesis. However, to provide a coherent overview of the expected functionality, the risk register shall contain the following features. Area Functionality Functionality Support COBIT 5 APO12.01 through APO12.04 and store data from risk identification, estimation, evaluation, treatment and acceptance phases of ISO/IEC Risk management process, specifically: storing risk assessment data, categorizing assets (goals, processes) through COBIT 5 goal cascade, documenting risk events (scenarios), linking assets with risks, risk scenarios and risk treatments, analysing risk events (scenarios) and business effects of events through a set of extendable scales (frequencies, impacts) according to Risk IT using both quantitative and qualitative approaches, tracking risk and risk treatment through time. Source data Performance Reliability Usability Security Hardware and software The risk register should also support employing risk tolerance and appetite levels, rudimentary tracking of project IT risks and allow quickly displaying data at various levels of aggregation. Use COBIT 5 and Risk IT as source data where possible. Provide near real-time performance with data processing times from one user input to another lower than 30 seconds. Assure data integrity. Contain user interface understandable by knowledgeable computer user and provide help throughout the interface. Support multiuser environment with granular access control. Log all user actions and allow review. Label information in the register. Client software agnostic to server software running the register; software libraries part of the standard Debian wheezy or packaged with the register. Source: author. Note: knowledgeable computer user is definitely a vague term. Table 5.1: Requirements summary

60 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 quality 1. Django has a stable API 2, very detailed documentation 3 and known depreciation plan and release dates 4 and the releases are based on annecdotical evidence 5 very well tested and lack any significant bugs or security holes. Django encourages software development good practices 6. The framework is fully based on the model-view-controller (MVC) structure and is object oriented. More features of Django are described throughout the text of the thesis, especially with regard to security. 1 Django s tagline The Web framework for perfectionists with deadlines sums it all while the author may not be a perfectionist, this thesis certainly has a deadline. 2 See [10] at 3 See [10] at 4 See [10] at 5 See security issues at and bug reports at https: //code.djangoproject.com/query. 6 See [10] design philosophies at design-philosophies/ (last retrieved December 8, 2012).

61 6. Risk register platform 47 Apart from standard Python modules, the risk register uses several Django applications: django-tables2 by Bradley Ayers 7 to display sortable HTML tables, django-extension to generate class diagrams. PostgreSQL version 9.1 is the default database backend. Django supports numerous database backends and the author also used SQLite during development. Django uses memcached instance to improve performance. The application is served by Apache 2 webserver (prefork) through mod wsgi; the stack supports a caching proxy, additional logging and any other Apache 2 features. The development version can also run through the built-in Django web server for easier debugging. Apache 2 might be replaced with nginx or lighttpd after some adjustments. The operating system needed for the default risk register is Linux, specifically Debian (wheezy); generally speaking, the risk register can be installed on any recent Linux/Unix based system that supports the underlying infrastructure (webserver, database). The author is not aware of the extent of support on Windows based operating systems. While the Python (as interpreted language) and Django (as an extensive frameworklibrary) is not the fastest possible combination (in terms of speed of calculation), the author believes 8 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 GIT commit g595c8d4 (last retrieved October 5, 2012). 8 Based on experience with the stack; the performance starts to lag only when making several tens of thousands object manipulations (retrieve from database, perform interaction, save modified object) per second on low-cost servers (Intel Core i5 CPU, 8 GB RAM).

62 6. Risk register platform 48 The list is arbitrarily based on author s experience with HTML/CSS and capacity to test templates in numerous browsers. Any reasonably recent 9 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 and Twitter Bootstrap CSS framework version 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 not 10. The author discourages running the register on platforms that are not recommended in section 6.1. Django employs an ORM object relationship mapper layer between instances of classes (models in Django) and the database. This poses certain challenges with class inheritance and the author sometimes had to compromise between theoretically clean design and practical database performance. While the author prefers to reuse code as much as possible, sometimes a component in the register was developed from scratch if existing components and plugins did not seem to be up to date. 9 Including for example Internet Explorer Leading to Unicode string comparison errors, for example in Python in the Cygwin environment on Microsoft Windows XP.

63 6. Risk register platform 49 Certain items in the register are implemented in a way that simplifies development but might be considered against best practices. One case is the choice option on certain fields, where one or two characters would suffice as key in the (key, value) tuple. However, the author has opted to use much longer key (up to 20 characters) as he believes that the performance impact on database is miniscule, while the impact of using keys unreadable to humans during development and deployment would cost much more.

64 Chapter 7 Risk register implementation In general, the risk register supports COBIT 5 APO12 process. A partial highlevel data flow diagram of APO12 can be found in Figure E.1; it is based on COBIT 5 (derived from section B.7) and the register only supports APO12.01 through APO 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).

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

66 7. Risk register implementation 52 to continuity of the text, the reader who is unfamiliar with Django is kindly asked to skip to section 7.3, especially to the text about configuration files in subsection and return back after becoming familiar with the material. 7.2 Risk register models All models 1 inherit from models.model. The author has opted not to use any custom layers between Django and the risk register such as object history Assets All assets are represented by the Asset model in asset/models.py. The risk register implements four types of assets to support COBIT 5 goal cascade (see Figure 2.4). While it might be confusing to store both goals and assets in one type of object, the author believes that at a high-level view, there is no difference between goal, process and asset (as an accounting term) and the term asset can be used to encompass them all. The cascade is fully customizable, but certain templates will require changes (mainly the asset/tree.html template tailored to COBIT 5). Figure 7.2: Asset types Enterprise goal IT-related goal Process (enabler goal) Resource Source: author; config/50 app defaults.conf, ASSET TYPES; based on COBIT 5. The field failure text contains the mapping between COBIT 5 enterprise goals and Risk IT business impacts (see Appendix A) for asset type Enterprise goal. Any Asset model can have relations to multiple other Assets (either as a parent or a child) and the relationship captures additional data (in AssetRelation). The default implementation only supports expressing the relationship as a binary value (field importance in AssetRelation), meaning that the child assets can be marked either as primary or secondary. Changing the relationship to a discreet range (see subsection 2.1.3) is possible; however, the author opted not to implement such system 1 Django terminology; essentially a Python class with an underlying ORM mapper that allows permanent storage transparent to the programmer. 2 (last retrieved June 10, 2012).

67 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 contemplated tracking asset relationships in time, for example allowing to display how a current risk register affects a goal cascade from two years ago. However, such change would add two layers of complexity to the register both tracking history for the goal (asset) cascade and tracking historical relationships. From a purely business point of view, tracking past goals can serve for performance review, but 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) Impacts Possible impact scales of risk 3 are represented in the Frequency and Impact objects, which correspond to subsection and subsection 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, unlikely natural disasters,... 1 < 0.1; 1) events per year The event took place over a company 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; ) 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 3 Stored in RiskEntry model, described later.

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

69 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 status 4 and local settings 5. 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 $ 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 risk 6. Both models allow for attachments and neither can be deleted 7 to disable a risk treatment, one is required to update the valid until field. Such approach reflects two requirements: it displays how was something solved in the past, it explicitly forces users to think in terms of time, meaning that any risk treatment should always be reviewed in the future and is not valid forever. 4 For example, one might ponder that governmental organization would accept higher productivity losses as a tradeoff to lower monetary loss. It 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.

70 7. Risk register implementation 56 RiskTreatment can also be employed to affect levels of risk directly through fields effect frequency effect impact. These two options can seem to be relatively controversial, as they are decoupled from the risk impacts and frequencies, so they should be used carefully. Risk controls might appear to be quite different from risk treatment but after some consideration, controls can already be described with RiskTreatment models. The key here is that there 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 reduce 8 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 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 infrastructure 9 ) 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 losses 10. ElevatedRisk effect on Risk is computed by first calculating root mean square of risk impacts and then adding average of values from effect impact fields of related ElevatedRisk instances. For frequency, average of ElevatedRisk fields effect frequency is calculated as avg f req. Then, instance of Frequency with level in the interval < avg 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 8 If it reduces risk. 9 Or for example floods during certain months and under certain meteorological circumstances. 10 A similar example is a government site(s) during a time when certain legislation is prepared most notably, the ACTA (Anti-Counterfeiting Trade Agreement).

71 7. Risk register implementation 57 it to existing number in field frequency value in the Risk instance. By default, only currently valid ElevatedRisk instances affect risk (that is, historical and future values are discounted) 11. The author acknowledges that the resulting values may not fully represent reality however, they provide some aggregated information. Both models allow for attachments the author expects the organization to reuse common detailed templates that have far more information to be retained than, no matter how detailed, model in the register. Risk models are linked to RiskAssessment a fairly limited model used to capture merely information about a risk assessment taking place and assessed risks. It is not the goal of the risk register in the thesis to support whole risk assessment processes, however, this model allows us to capture the relationship. Specifically, one can analyze which valid risks 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 ]; however, certain fields were simplified by the author, for example actor allows only one value (instead of both internal and external). Such limitation is merely a simplification, one can add numerous possibilities in conf/50 app defaults.conf. Figure 7.4: Default risk scenario values Actor: internal, external Threat types: failure, malicious, accidental, natural Events: ineffective execution, ineffective design, regulation, theft, destruction, inappropriate use, modification, interruption Timing: non-critical, critical, unknown Duration: short, moderate, extended, unknown Detection: instant, moderate, slow Source: conf/50 app defaults.conf, based on [21, pg ]. 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).

72 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: 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 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.

73 7. Risk register implementation 59 Figure 7.5: Configuration files layout 00 deployment.conf: Variables enabling the debug environment, notifications for administrators. 50 app defaults.conf: Default variables for various objects in the register. 80 site custom.conf: Variables relevant to the organization running the register like name, address,... Source: author User rights checks By default, Django generates add, change and delete permissions for all objects. All relevant models in the register also have an additional permission access. The structure of the permission string is module.action model; the permission model is binary and supports only either allowing and disallowing access to all objects of a model. Permissions except for access are implemented and checked in the Django admin interface too. Permissions are enforced at the level of views by using a mixin PermissionRequiredMixin within class-based views SecCreateView, SecUpdateView, SecDetailView, SecDeleteView SecListView (with parent classes being the default Django DeleteView, UpdateView, CreateView, ListView, DetailView respectively). Figure 7.6: Permission check in views PermissionRequiredMixin 1 In views.py: 2 class 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 ) class SecUpdateView ( (...), PermissionRequiredMixin, UpdateView ): 18 action = " change " Source: author; general tools/views.py, simplified. Note the superuser permission.

74 7. Risk register implementation 60 One can then enforce user rights with generic views using a code as simple as the following excerpt: Figure 7.7: Permission check in views urls.py 1 urlpatterns = patterns ( '', 2 url (r '^ items /(?P<pk >([\d])+)/ update /$', SecUpdateView. as_view ( model = Asset, template_name = ' object / object_form. html '), name = 'asset - update '), 3 ) Source: author; simplified example. If the risk register gets a request matching regular expression, it passes object private key (pk), object class Asset and template where the object should be rendered. In SecUpdateView, the data is manipulated in completely generic way, no matter which object and where is displayed. The implementation means that access to all objects within the register is centralized and can be verified. No standard access apart from generic views exists. Also, if needed, a REST (or XML) API can use the same implementation by inheriting from for example SecCreateView and overriding methods of CreateView without ever altering the permission system. A similar view (OwnershipRequiredMixin) enforces access rights by checking either a permission to access (edit, delete,...) the object or whether the user is owner of the object, albeit the view is not used in the register apart from access to user profiles. Assignment of user rights is based on Django groups. Overview of existing groups and assigned permissions is in Table D.2 and Table D.3.User permissions can also be altered with two Django flags: Staff status allows access to Django admin (and thus display access to all models) and Superuser status overrides any permission checks in the register 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,...)

75 7. Risk register implementation 61 Five events are logged: HTTP request: The event is captured in the LogRequestMiddleware, which runs after Session and Authentication middleware 12. 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 logged 13. 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, although the result of the attempt is not stored anywhere. As the author has already suggested, the user is urged to customize the authentication against a centralized solution. Exceptions: Request exceptions are stored through standard Django signal got request exception listener in log/signals.py including the full request data and variables provided by Django. This should not lead to large amounts of data if for example the register front end contains links to missing content, because static content will not be processed by Django at all. View,edit and delete events on models: PermissionRequiredMixin and 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 (including creation and deletion), even for super users. However, changes from the admin interface are still possible which should not affect security of the solution as the admin should not have access to controlled risk register objects. The author has considered logging from save() methods, but that solution proved to be too complicated if multiple objects change and also due to Django inheritance implementation The reader is kindly referred to Django documentation [10] at com/en/1.4/topics/http/middleware/ for details. 13 In the register, they can be logged at the webserver level. 14 Parent and child instances are rather problematic to differentiate.

76 7. Risk register implementation 62 The database stores only first 100 bytes of variables (e.g. request path) to prevent certain attacks and save space. The following figure lists all event types (tuples in the actual configuration file): Constant REQUEST EXCEPTION LOGIN LOGOUT OBJECT LOGIN TRY Description HTTP request Exception User logged in User logged out Object changed Attempted login Source: author; config/50 app defaults.conf. Table 7.2: Types of events All logs stored in the database are immutable the model can be saved once and only once, any attempt on editing LogItem will result in an exception. Such design means that even if an attacker attempts to implement a backdoor in some other module that changes logs, the attack will not succeed. Figure 7.8: Immutable logs 1 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 default 15, 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 Point of time view The risk register contains a feature similar to a time machine. The user can set the register to display values based on point of time. The risk register then filters all objects in reasonable views based on the assumption that the date set by user is 15 See settings.log MODELS CHANGE in conf/10 app defaults.conf.

77 7. Risk register implementation 63 current date. This key feature allows users to understand how will the risk landscape look in the future (and, to some extent, how it looked in the past 16 ) 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 CRUD 17 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 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 forms 18 ). The map could be expanded in numerous ways, for example by allowing to limit the selection to a range of dates, years and 16 The past view is limited because the register doesn t contain a history layer for relationships. Therefore, for example risk treatments are applied based on current date, not on the point of view date, because there is no way of knowing whether they existed in the past and were related to the risk entry in the past. 17 Create-Update-Delete. 18 That is, without taking into account values from ElevatedRisk and RiskTreatment instances.

78 7. Risk register implementation 64 so on. The generated image as well as data sheet can be downloaded as JPEG and PNG images and CSV file 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 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

79 7. Risk register implementation 65 models Asset and AssetRelation, impact scales and their source data and the extent of inclusion of project management impacts from PMBOK, and risk treatments. A significant portion of the text explores models related to risk entries and risk scenarios; the highlights are the mapping between COBIT 5 goals (processes) and Risk IT risks, various calculations withing the RiskEntry model and RiskScenario values for actors, threats, events, timing, duration and detection. The second part of the chapter focused on the inner working of the register around models. The structure of configuration files and their loading order was defined, and the author spent some time detailing how user rights are enforced within the risk register and how can such checks be extended. The reader could also get familiar with audit trails available in the register and their limitations. Last but not least was the point of time feature of the risk register and various analytical views available to the user. To name a few, the text presented different risk maps, views detailing risk register violations (such as risks without assigned frequencies), views with expected issues (future risks) and top charts (for example, top risks by aggregated impact level). For more detailed documentation, the reader is kindly referred to risk register source code and docstrings or the (slightly cumbersome) automatically generated EpyDoc code overview. The thesis continues with the implementation notes and user quick-start manual.

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

81 8. Customizing, deploying and using the register 67 Django 1.4. The author strongly discourages using versions of Python other than 2.6 or 2.7, experimental Apache 2 servers (for example tk or mpm due to Python global lock) or MySQL due to possible integrity issues. PostgreSQL can be easily substituted for Oracle databases by a simple configuration change. 8.2 Information security Each user may be assigned a basic user group and additional user groups (granting privileges, for example to access items related to specific project); individual user rights should not be assigned unless completely necessary. The following criteria should be meet within the organization during implementation and should be treated as a checklist. However, the checklist is not a substitute for an information security policy. The goal of the list is to relate ISO/IEC 27002:2005 controls to the risk register implementation from the point of view of the implementing organization. There is no doubt that there are more controls that could and should be used, but the the author tried to select a minimal list.

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

83 8. Customizing, deploying and using the register 69 The following tasks must be accomplished when the risk register is installed. Item Database password User accounts Configuration item settings.secret KEY Django admin Configuration file settings/00 deployment.conf Procedure Change default database user password. Change default administrator s password. Generate a new random string upon installation. Disable the administration interface in the production environment via urls.py. Set all values to false. Source: author. Table 8.2: IT Risk register installation only. As a general rule, the register should be accessible from the company intranet Responsibility General risk management duties should be based on Figure 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 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.

84 8. Customizing, deploying and using the register 70 The priority of goals is set to 0 (primary) and 1 (secondary) by default the user is strongly suggested to redefine the range and or at least modify the values. The recommended customization procedure based on [7, pg ] 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 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 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 account Impact and frequency scales Assess and modify impact and frequency scales (models Impact, Frequency, also constant IMPACT AREAS in conf/50 app defaults.conf ). Redefine impact levels to 1 A useful control is to review whether a user is not logging again and again from different IP addresses (machines) within the organization.

85 8. Customizing, deploying and using the register 71 company needs and risk thresholds. Update descriptions of impacts to local legal and regulatory landscape, as well as financial impacts 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 ) 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.

86 8. Customizing, deploying and using the register 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 solutions 2, 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 level 3. 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 solutions 4. 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 requirements 5, expectations and budget for a further, deeper risk assessment. 2 Which should not be expected of any academic software, keeping in mind that the last 20 % of product functionality (the polish) would probably take 80 % of the resources. 3 Albeit there is no editing lock in the register, so the users would have to agree on some separation. 4 Or freely available risk registers under various licences. 5 Including risk register requirements.

87 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

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

89 Bibliography [1] A Guide To The Project Management Body of Knowledge (PMBOK Guide). Fourth Edition. Newtown Square, PA, USA: Project Management Institute, ISBN [2] ADAMS, J.: RISKY BUSINESS: The Management of Risk and Uncertainty. London: Adam Smith Institute, ISBN [3] Apache HTTP Server Version 2.2 Documentation [online]. Apache Software Foundation [last retrieved September 21, 2012]. Available from: apache.org/docs/2.2/. [4] ALCHIN, M.: Pro Django. New York: Springer-Verlag New York, Inc., ISBN [5] BITS Technology Risk Transfer Gap Analysis Tool [online]. BITS Role of Insurance in E-Commerce Risk Management Working Group, 2002 [last retrieved December 8, 2012]. Available from: GapAnalysis0402.pdf. [6] CobiT 4.1. Rolling Meadows, IL, USA: IT Governance Institute, ISBN [7] COBIT 5 A Business Framework for the Governance and Management of Enterprise IT. Rolling Meadows, IL, USA: ISACA, ISBN [8] COBIT 5 Enabling processes. Rolling Meadows, IL, USA: ISACA, ISBN [9] CLARKSON, K. W., MILLER, R. L., CROSS, F. B.: Business Law: text and cases. Twelfth edition. Mason, OH, USA: South-Western, Cengage Learning, ISBN

90 Bibliography 76 [10] Django documentation. Version 1.4. [online]. Django Software Foundation [last retrieved December 8, 2012]. Available from: com/en/1.4/. [11] DOUCEK, P., NOVÁK, L., SVATÁ, V.: Řízení bezpečnosti informací. První vydání. Praha: Professional Publishing, ISBN [12] HINDLS, R., HRONOVÁ, S., SEGER, J.: Statistika pro ekonomy. Páté vydání. Praha: Professional Publishing, ISBN [13] ISO/IEC 27002:2005. Information technology Security techniques Code of practice for information security management. Geneva: International Standards Organization, [14] ISO/IEC 27005:2011. Information technology Security techniques Information security risk management (second edition). ISO/IEC 27005:2011, Geneva: International Standards Organization, [15] ISO/IEC 31000:2009. Risk management Principles and guidelines. Geneva: International Standards Organization, [16] Management of Risk Pocketbook edition. London: Stationery Office, Office of Government Commerce, ISBN [17] Managing Successful Projects with PRINCE2. Fourth edition. London: Stationery Office, Office of Government Commerce, ISBN [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: 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, ISBN [20] The Risk IT Framework. Rolling Meadows, IL, USA: ISACA, ISBN [21] The Risk IT Practitioner Guide. Rolling Meadows, IL, USA: ISACA, ISBN

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

92 A. COBIT 5 risk mappings II 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 consequences 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 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]. Table A.1: Enterprise goals and business impact

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

94 A. COBIT 5 risk mappings IV Cobit Information Criteria Business Goals Consequence (Impact) Effectiveness Efficiency Confidentiality Integrity Availability Compliance Reliability Financial Perspective Inadequate financial return on investment of IT-enabled business investments. P Inadequate products and services, not addressing customer needs, resulting in revenue loss. P S IT-related risks not managed, leaving the company exposed. P P P Violation of regulations or contracts, resulting in legal fines/damages or personal legal consequences for board and executives. P P S S S 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 Inability to react to changing market or client requirements on a timely basis, resulting in revenue loss. P S S S P Wrong strategic decisions on new business initiatives, resulting in client/revenue loss and shareholder value. P S S S Products or services brought to market at too high a price or inadequate profit margin, potentially resulting in share value and client loss. Internal Perspective Inefficient and inadequate operations of the enterprise. P S S P P Lower profitability. P S S P S Inefficient and inadequate operations of the enterprise, resulting in loss of opportunities. S P S Inefficient and inadequate operations of the enterprise, resulting in compliance issues. P Inefficient and inadequate operations of the enterprise, resulting in inadequate productivity and efficiency. Learning and Growth Perspective Inability to sustain growth or current operations. P S P S S Loss of opportunities, low growth, eroding market share. S P 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. Table A.3: COBIT 5 business impacts to CobiT 4.1 information criteria mapping

95 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

96 B. COBIT and Risk IT materials VI Source: [7, pg. 33, Figure 16]. Figure B.1: COBIT 5 Process reference model

97 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 enterprise. Culture, ethics and behaviour of individuals and of the enterprise are very often underestimated as a success factor in governance and management activities. Information is pervasive throughout any organisation and includes all information produced and used by the enterprise. Information is required for keeping the organisation running and well governed, but at the operational level, information is very often the key product of the enterprise itself. Services, infrastructure and applications include the infrastructure, technology and applications that provide the enterprise with information technology processing and services. People, skills and competencies are linked to people and are required for successful completion of all activities and for making correct decisions and taking corrective actions. Source: [7, pg. 27]. 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.

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

99 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. Source: [6, pg. 12]. B.6 CobiT 4.1 to COBIT 5 process mapping CobiT 4.1 process ME4 ME1 ME3 ME2 DS8 DS9 DS6 DS7 DS4 DS5 DS2 DS3 DS1 DS10 DS11 DS12 DS13 PO8 PO9 PO6 PO7 PO4 PO5 PO2 PO3 PO1 PO10 AI5 AI4 AI7 AI6 AI1 AI3 AI2 COBIT 5 processes EDM01, EDM02, EDM04, EDM03, MEA02 MEA01 MEA03 MEA02 DSS02 BAI10, DSS02 APO06 APO07 DSS04 APO13, DSS05, DSS02 APO10 BAI04 APO09 DSS03 DSS01, DSS04, DSS06, DSS05 DSS01, DSS05 DSS01, DSS05, BAI09 APO11 EDM03, APO01, APO12 APO01, EDM03 APO07, APO01 APO01, APO11, APO07 APO06, APO05 APO03, APO01 APO02, APO04, EDM01, APO03, APO01 EDM02, APO02, APO05 BAI01 BAI03, APO10 BAI05, BAI08 BAI05, BAI07 BAI06 BAI02 BAI03, DSS02 BAI03 Source: based on [8, pg ]; 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

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

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

102 B. COBIT and Risk IT materials XII B.8 Risk IT Risk analysis Figure B.8: Risk Analysis Flowchart Source: [21, pg. 82, Figure 47].

103 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: (last retrieved November 17, 2012).

104 Appendix D Relevant configuration excerpts D.1 Apache2 Figure D.1: Relevant Apache 2 SSL configuration 1 SSLProtocol -all + TLSv 1 + SSLv 3 2 SSLCipherSuite HIGH : MEDIUM :! anull :+ SHA 1:+MD5:+ HIGH :+ MEDIUM 3 SSLCertificateFile / etc / apache 2/ ssl / certapache 2. pem 4 SSLCertificateKeyFile / etc / apache 2/ ssl / key. pem Source: author; Apache 2 configuration files. The following excerpts present a configuration of the Apache 2 virtual host. Notes on configuration specific to Django, mod wsgi or the risk register are included as comments (prefixed with #). Figure D.2: General virtual host configuration 1 < VirtualHost *:80> 2 ServerName risk. company. int 3 ServerAdmin rregisteradmi@company. coim 4 DocumentRoot / home / www / risk. company. int / 5 6 < Directory /> 7 Options FollowSymLinks - Indexes 8 AllowOverride AuthConfig FileInfo Indexes Limit 9 </ Directory > SSLEngine on Source: author; Apache 2 configuration files.

105 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 3 4 # 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 Source: author; Apache 2 configuration files. 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 > 8 9 < Directory / home / www / risk. company. int / media /> 10 FileETag none 11 ExpiresActive On 12 ExpiresDefault " access plus 4 weeks " 13 ExpiresByType image / gif A ExpiresByType image / png A ExpiresByType image / jpg A ExpiresByType image / jpeg A </ Directory > < 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 > # 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 > Source: author; Apache 2 configuration files.

106 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 / apache 2/ logs / rregister / error. log 3 LogLevel warn 4 5 # 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 / apache 2/ logs / rregister / access. log combined </ VirtualHost > Source: author; Apache 2 configuration files.

107 D. Relevant configuration excerpts XVII D.2 Risk register defaults 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 > USD Level 4 < USD Level 3 < USD Level 2 < USD Level 1 < 5000 USD Level 0 < 500 Source: author. Values in Legal and Reputation (press) categories based on [21, pg. 38] (Risk IT). Table D.1: Default impacts

108 D. Relevant configuration excerpts XVIII Group user auditor regular user manager administrator Source: author. [Default user groups] Permissions Can log in; implicitly can update own profile. Can access any regular model related to the risk register except for user profiles. Can access and edit any model except for accessing logs and editing risk frequencies, impacts. Can edit risk frequencies and impacts. Can access risk register logs. Table D.2: Default user groups User user auditor regular user manager administrator karel Groups user user, auditor user, regular user user, regular user, manager user, administrator no groups; Superuser flag set to true Source: author. All users have default password letmein. Table D.3: Default users

109 Appendix E Diagrams Intentionally left blank.

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

111 E. Diagrams XXI Figure E.2: Risk register full class diagram Source: author; diagram teaser full resolution diagram is enclosed on a DVD.

112 E. Diagrams XXII Figure E.3: Risk register asset application class diagram Source: author.

113 E. Diagrams XXIII Figure E.4: Risk register risk application class diagram Source: author.