information security risk management a holistic ...

INFORMATION SECURITY RISK MANAGEMENT: A HOLISTIC FRAMEWORK by

WERNER GEORGE BORNMAN DISSERTATION submitted in fulfilment of the requirements for the degree

MASTERS IN THE ECONOMIC AND MANAGEMENT SCIENCES in

INFORMATICS in the

FACULTY OF ECONOMIC AND MANAGEMENT SCIENCES at the

RAND AFRIKAANS UNIVERSITY SUPERVISOR: PROF. L. LABUSCHAGNE OCTOBER 2004

ABSTRACT Information security risk management is a business principle that is becoming more important for organisations due to external factors such as governmental regulations. Since due diligence regarding information security risk management (ISRM) is necessitated by law, organisations have to ensure that risk information is adequately communicated to the appropriate parties. Organisations can have numerous managerial levels, each of which has specific functions related to ISRM. The approaches of each level differ and this makes a cohesive ISRM approach throughout the organisation a daunting task. This task is compounded by strategic and tactical level management having specific requirements imposed on them regarding risk management. Tactical level management has to meet these requirements by instituting processes that can deliver on what is required. Processes in turn should be executed by operational level management. However, the available approaches of each managerial level make it impossible to communicate and consolidate information from the lower organisational levels to top level management due to the differing terminology, concepts and scope of each approach. This dissertation addresses the ISRM communication challenge through a systematic and structured solution. ISRM and related concepts are defined to provide a solid foundation for ISRM communication. The need for and institutions that impose risk management requirements are evaluated. These requirements are used to guide the solution for ISRM communication. At strategic level, governmental requirements from various countries are evaluated. These requirements are used as the goals of the communication processes. Different approaches at tactical and operational level are evaluated to determine if they can meet the strategic level requirements. It was found that the requirements are not met by most of the evaluated approaches. The Bornman Framework for ISRM Methodology Evaluation (BFME) is presented. It allows organisations to evaluate ISRM methodologies at operational level against the requirements of strategic management. This framework caters for the

i

Abstract

ability of ISRM methodologies to be adapted to organisational requirements. Developed scales allow for a qualitative comparison between different methodologies. The BFME forms the basis of the Bornman Framework for ISRM Information Communication (BFIC). This communication framework communicates the status of each ISRM component. This framework can be applied to any ISRM methodology after it has been evaluated by the BFME. The Bornman Risk Console (BRC) provides a practical implementation of the BFIC. The prototype utilises an existing ISRM methodology’s approach and provides decision-enabling risk information to top level management. By implementing the BRC and following the processes of the BFME and BFIC the differences in the approaches at each managerial level in different organisational structures are negated. These frameworks and prototype provide a holistic communication framework that can be implemented in any organisation.

ii

AFRIKAANSE OORSIG Inligtingsekuriteitsrisikobestuur is `n besigheidsbeginsel wat al hoe meer belangrik word vir organisasies weens eksterne faktore soos regeringsregulasies. Risiko inligting moet doeltreffend gekommunikeer word na die toepaslike partye aangesien redelike sorg met betrekking tot inligtingsekuriteitsrisikos wetlik vereis word. Organisasies

bestaan

uit

verskeie

bestuursvlakke

waarvan

elkeen

inligtingsekuriteitsrisikobestuur (ISRB) verwante funksies verrig. Die benaderings op elke vlak verskil en dit maak dit moeilik om `n samehangende ISRB benadering, wat regdeur die organisasie toegepas kan word, te bewerkstellig. Die taak word verder bemoeilik deur risiko spesifieke vereistes wat aan strategiese en taktiese vlak bestuur voorgelê word. Taktiese vlak bestuur moet aan hierdie vereistes voldoen deur prosesse in plek te stel wat deur operasionele vlak bestuur uitgevoer behoort te word. Nietemin, elke bestuursvlak se benadering tot ISRB maak die kommunikasie van risiko inligting vanaf die operationele vlak tot die strategiese vlak moeilik. Dit is as gevolg van die benaderings se verskillende terminologië, konsepte en omvang. Die verhandeling spreek die kommunikasie probleem ten opsigte van ISRB aan deur `n stelsematige en gestruktureerde oplossing. ISRB en verwante konsepte word gedefinieer om `n soliede grondslag vir ISRB kommunikasie te vorm. Die behoeftes, en die instansies wat dié ISRB vereistes skep, word geëvalueer. Hierdie vereistes word gebruik as `n gids vir die oplos van die ISRB kommunikasie probleem. Op strategiese vlak word regerings se verwaginge van verskeie lande geëvalueer. Die verwagtinge word die doelwitte van die ISRB kommunikasie. Verskeie benaderings op die taktiese en operasionele vlakke word geëvalueer om te bepaal of die strategiese ISRB vereistes aan voldoen kan word. Dit was vasgestel dat min benaderings aan die strategiese vereistes voldoen. Die “Bornman Framework for ISRM Methodology Evaluation” (BFME) laat organisasies toe om ISRB metodologië op die operasionele vlak teen strategiese

iii

Afrikaanse Oorsig

vereistes te evalueer. Die raamwerk neem die moontlikheid van die metodologie om aangepas te kan word vir organisasie vereistes in ag. Evaluasie skale laat kwalitatiewe evaluasie tussen die metodologië toe. Die “Bornman Framework for ISRM Methodology” vorm die fondament van die “Bornman Framework for ISRM Information Communication” (BFIC). Die kommunikasie raamwerk kommunikeer die status van elke ISRB komponent. Die raamwerk word toegapas op enige ISRB metodologie nadat dit geëvalueer is deur middel van die BFME. Die “Bornman Risk Console” (BRC) verskaf `n praktiese toepassing van die “Bornman Framework for ISRM Information Communication”. Die prototipe benut `n bestaande ISRB metodologie en verskaf risiko besluitnemings inligting vir `n organisasie se top bestuursvlakke. Deur die implementering van die BRC en die voorafgaande prosesse van die BFME en BFIC, word die verskille van die ISRM benaderings op die verskillende bestuursvlakke nietig. Die raamwerke en prototipe verskaf `n holistiese kommunikasie raamwerk wat in enige organisasie toegepas kan word.

iv

ACKNOWLEDGEMENTS THIS WORK IS DEDICATED TO MY MOTHER AND MY SISTER

I want to take this opportunity to thank some people who have been instrumental in the completion of this research undertaking. God for blessing me with perseverance and a passion for learning. My mother, thank you for all your support. You have always been a great inspiration to me and taught me the meaning of working hard. You are a pillar of strength. My sister, Karin, thank you for always listening, making great suggestions and supporting me in everything I do. Prof. L. Labuschagne, for all your guidance, support, encouragement and leadership. My family for their continued support and encouragement. The financial assistance of the South African Department of Labour (DoL) in this research is hereby acknowledged. Opinions expressed and conclusions arrived at are those of the author and are not necessarily to be attributed to the DoL.

v

IN D E X CHAPTER 1 1.1. INTRODUCTION..................................................................................................1 1.2. MOTIVATION FOR THIS STUDY ............................................................................1 1.3. PROBLEM STATEMENT.......................................................................................3 1.4. PROBLEM SOLUTION APPROACH ........................................................................5 1.5. DISSERTATION LAYOUT .....................................................................................6 1.6. RESEARCH METHODOLOGY ...............................................................................9 1.7. RESEARCH GOAL ............................................................................................10 1.8. RESEARCH VALUE ...........................................................................................10 1.9. CONCLUSION ..................................................................................................11

CHAPTER 2 INFORMATION SECURITY RISK MANAGEMENT CONCEPTS 2.1. INTRODUCTION................................................................................................13 2.2. INFORMATION SECURITY ..................................................................................14 2.2.1. Confidentiality.........................................................................................14 2.2.2. Integrity ..................................................................................................14 2.2.3. Availability ..............................................................................................14 2.2.4. Secondary Information Security Components.........................................15 2.3. RISK COMPONENTS .........................................................................................15 2.3.1. Asset ......................................................................................................17 2.3.2. Threat.....................................................................................................18 2.3.3. Vulnerability............................................................................................19 2.4. MANAGEMENT .................................................................................................19 2.4.1. Strategic Management............................................................................20 2.4.2. Tactical Management .............................................................................20 2.4.3. Operational Management .......................................................................20 2.5. GENERIC RISK MANAGEMENT PROCESSES .......................................................21 2.5.1. Identify....................................................................................................21 2.5.2. Measure .................................................................................................22 2.5.3. Control....................................................................................................22 2.5.4. Monitor ...................................................................................................24 2.6. RISK MANAGEMENT CONCEPTS .......................................................................24 2.6.1. Information Technology Risk Management (ITRM).................................25 2.6.2. Information Security Risk Management (ISRM) ......................................25 2.6.3. Risk Analysis ..........................................................................................25 2.6.4. Risk Assessment....................................................................................26 2.6.5. Risk Evaluation.......................................................................................26 2.6.6. Other Concepts ......................................................................................26 2.7. RESEARCH VALUE ...........................................................................................27 2.8. CONCLUSION ..................................................................................................27

CHAPTER 3 INFORMATION SECURITY RISK MANAGEMENT METHODOLOGIES 3.1. INTRODUCTION................................................................................................29

vi

Index

3.2. CHAPTER FOCUS ............................................................................................29 3.3. INFORMATION SECURITY RISK MANAGEMENT APPROACHES...............................30 3.4. STANDARDS ....................................................................................................31 3.5. GUIDELINES ....................................................................................................34 3.6. METHODOLOGIES ............................................................................................37 3.6.1. CRAMM..................................................................................................38 3.6.2. OCTAVE ................................................................................................42 3.6.3. CORAS ..................................................................................................48 3.7. RESEARCH VALUE ...........................................................................................55 3.8. CONCLUSION ..................................................................................................56

CHAPTER 4 ORGANISATIONAL GOVERNANCE AND INFORMATION SECURITY 4.1. INTRODUCTION................................................................................................58 4.2. CHAPTER FOCUS ............................................................................................59 4.3. STRATEGIC AND TACTICAL LEVEL REQUIREMENTS ............................................59 4.3.1. King II .....................................................................................................60 4.3.2. Cadbury..................................................................................................60 4.3.3. Turnbull ..................................................................................................61 4.3.4. Sarbanes-Oxley......................................................................................62 4.3.5. Electronic Communications and Transactions Act ..................................63 4.3.6. Promotion of Access to Information Act ..................................................63 4.4. TOP LEVEL ISRM INSTRUMENTS ......................................................................64 4.4.1. ITIL.........................................................................................................65 4.4.2. CobiT......................................................................................................68 4.4.3. BASEL II Accord.....................................................................................73 4.5. RESEARCH VALUE ...........................................................................................75 4.6. CONCLUSION ..................................................................................................75

CHAPTER 5 ORGANISATIONAL STRUCTURES AND ISRM 5.1. INTRODUCTION................................................................................................77 5.2. ORGANISATIONAL FUNCTIONS ..........................................................................78 5.2.1. Core Business Functions........................................................................78 5.2.2. Supporting Business Functions ..............................................................79 5.3. ORGANISATIONAL STRUCTURES .......................................................................84 5.3.1. Strategic Business Units.........................................................................85 5.3.2. Departmentalisation................................................................................86 5.4. DEPARTMENTALISATION AND RISK MANAGEMENT..............................................93 5.4.1. Functional and Matrix Departmentalisation.............................................93 5.4.2. Geographic Departmentalisation ............................................................93 5.4.3. Product, Customer and Project Departmentalisation ..............................94 5.5. RESEARCH VALUE ...........................................................................................94 5.6. CONCLUSION ..................................................................................................95

CHAPTER 6 ENTERPRISE-WIDE RISK MANAGEMENT 6.1. INTRODUCTION................................................................................................96 6.2. HOLISTIC RISK VIEWS......................................................................................97 6.3. ENTERPRISE-WIDE RISK MANAGEMENT ............................................................99 6.4. ENTERPRISE-WIDE RISK VIEW ........................................................................100 6.4.1. Business Risks .....................................................................................101

vii

Index

6.4.2. Event Risks ..........................................................................................102 6.4.3. Financial Risks .....................................................................................103 6.5. ENTERPRISE-W IDE RISK MANAGEMENT COMPONENTS ....................................104 6.5.1. Corporate Governance .........................................................................105 6.5.2. Data and Technology Resources..........................................................107 6.5.3. Line Management.................................................................................108 6.5.4. Portfolio Management ..........................................................................108 6.5.5. Risk Transfer ........................................................................................109 6.5.6. Risk Analytics .......................................................................................109 6.5.7. Stakeholder Management.....................................................................110 6.6. RESEARCH VALUE .........................................................................................110 6.7. CONCLUSION ................................................................................................110

CHAPTER 7 ENTERPRISE-WIDE RISK MANAGEMENT FRAMEWORKS 7.1. INTRODUCTION..............................................................................................112 7.2. FRAMEWORKS...............................................................................................113 7.2.1. Treasury Board of Canada Integrated Risk Management Framework...113 7.2.2. Grant Thornton Enterprise-Wide Risk Management Framework...........118 7.2.3. COSO Enterprise Risk Management Framework..................................120 7.3. ROADBLOCKS OF ENTERPRISE-W IDE RISK MANAGEMENT................................124 7.3.1. The “Science” of Risk Management......................................................124 7.3.2. IT and Infrastructure .............................................................................124 7.3.3. Responsibility and Risk Accountability..................................................125 7.4. RESEARCH VALUE .........................................................................................130 7.5. CONCLUSION ................................................................................................131

CHAPTER 8 BORNMAN FRAMEWORK FOR ISRM METHODOLOGY EVALUATION 8.1. INTRODUCTION..............................................................................................133 8.2. DEVELOPING AN APPROACH TO COMPARE ISRM METHODS .............................134 8.3. SELECTION OF COBIT CONTROL.....................................................................136 8.4. DEVELOPING THE EVALUATION CRITERIA ........................................................137 8.5. DETAILED CRITERIA.......................................................................................139 8.5.1. BFME Core Risk Management Components ........................................139 8.5.2. BFME Process Supporting Components ..............................................145 8.5.3. BFME Risk Management Supporting Components...............................148 8.6. COMPARISON PROCESS ................................................................................151 8.7. APPLICATION OF SCALE .................................................................................154 8.8. BFME IMPLEMENTATION................................................................................155 8.9. ISRM METHOD EVALUATION RESULTS ...........................................................157 8.9.1. CORAS ................................................................................................158 8.9.2. OCTAVE ..............................................................................................158 8.9.3. CRAMM................................................................................................159 8.10. BFME LIMITATIONS .....................................................................................160 8.11. RESEARCH VALUE .......................................................................................161 8.12. CONCLUSION ..............................................................................................162

CHAPTER 9 BORNMAN FRAMEWORK FOR ISRM INFORMATION COMMUNICATION 9.1. INTRODUCTION..............................................................................................164 9.2. IDENTIFY ISRM COMMUNICATION APPROACH .................................................165

viii

Index

9.3. THE BFIC .....................................................................................................165 9.3.1. BFIC Core Indicators ............................................................................166 9.3.2. BFIC Supporting Indicators...................................................................167 9.3.3. The Complete BFIC..............................................................................169 9.4. GAUGING THE BFIC ......................................................................................171 9.4.1. Indicator Levels ....................................................................................171 9.4.2. Indicator Measures ...............................................................................173 9.5. RESEARCH VALUE .........................................................................................189 9.6. CONCLUSION ................................................................................................190

CHAPTER 10 BORNMAN RISK CONSOLE 10.1. INTRODUCTION............................................................................................192 10.2. ISRM HOLISTIC FRAMEWORK ......................................................................193 10.3. PROTOTYPE OBJECTIVES.............................................................................194 10.4. BRC PROTOTYPE COMPONENTS..................................................................195 10.4.1. Information Security Risk Management Methodology .........................195 10.4.2. Supporting Technology.......................................................................196 10.4.3. BRC Technology ................................................................................196 10.5. BRC DEVELOPMENT ...................................................................................196 10.6. BRC FUNCTIONS.........................................................................................198 10.6.1. Overview ............................................................................................199 10.6.2. Console ..............................................................................................200 10.6.3. XML Data ...........................................................................................201 10.7. BRC EVALUATION .......................................................................................202 10.7.1. Advantages ........................................................................................203 10.7.2. Disadvantages....................................................................................205 10.8. RESEARCH VALUE .......................................................................................206 10.9. CONCLUSION ..............................................................................................207

CHAPTER 11 CONCLUSION 11.1. INTRODUCTION............................................................................................209 11.2. REVISITING THE PROBLEM ...........................................................................210 11.2.1. Definitions and Concepts....................................................................210 11.2.2. Various Risk Management Needs.......................................................210 11.2.3. Risk Management Information ............................................................211 11.2.4. Risk Management Approaches...........................................................211 11.2.5. Risk Management Communication .....................................................211 11.2.6. Dynamic Environment.........................................................................212 11.2.7. Silo Risk Management........................................................................212 11.3. VALUE OF RESEARCH ..................................................................................213 11.3.1. New View of ISRM..............................................................................213 11.3.2. ISRM Integration.................................................................................213 11.3.3. Streamline ISRM ................................................................................214 11.3.4. ISRM Focus........................................................................................214 11.3.5. Roadblocks.........................................................................................215 11.4. LESSONS LEARNED .....................................................................................215 11.4.1. ISRM Integration.................................................................................215 11.4.2. ISRM Threat Focuses.........................................................................215 11.4.3. ISRM Influences .................................................................................216 11.4.4. ISRM Multiplicity .................................................................................216 11.4.5. Increased importance of ISRM ...........................................................216

ix

Index

11.4.6. Information Security Risk Management Environment..........................217 11.5. POSSIBLE FUTURE RESEARCH .....................................................................217 11.5.1. Linking with Risk Awareness and Culture ...........................................217 11.5.2. Development of a Risk Communication Protocol ................................217 11.5.3. BFIC Implementation..........................................................................217 11.6. EPILOGUE ...................................................................................................218

APPENDIX A .................................................................................. 219 APPENDIX B .................................................................................. 226 APPENDIX C .................................................................................. 227 APPENDIX D .................................................................................. 228 BIBLIOGRAPHY .............................................................................. 229

x

LIST O F FIG U R E S Figure 1-1: Dissertation layout .......................................................................................... 7 Figure 2-1: Risk components .......................................................................................... 16 Figure 2-2: Threat groupings .......................................................................................... 18 Figure 2-3: Managerial levels.......................................................................................... 20 Figure 2-4: Generic risk management processes............................................................ 21 Figure 2-5: Risk management control decision ............................................................... 23 Figure 2-6: Relationships between risk management concepts....................................... 25 Figure 3-1: Chapter focus ............................................................................................... 30 Figure 3-2: Information security risk management approaches....................................... 30 Figure 3-3: AS/NZS 4360 risk management standard..................................................... 32 Figure 3-4: SABS ISO/IEC 17799 PDCA model.............................................................. 33 Figure 3-5: ISO/IEC Guide 73......................................................................................... 35 Figure 3-6: NIST risk assessment methodology.............................................................. 36 Figure 3-7: ISF Standard of Good Practice for Information Security layout ..................... 37 Figure 3-8: Methodologies section layout........................................................................ 38 Figure 3-9: CRAMM approach ........................................................................................ 39 Figure 3-10: CRAMM methodology................................................................................. 40 Figure 3-11: OCTAVE methodology ............................................................................... 43 Figure 3-12: CORAS risk management processes ......................................................... 50 Figure 3-13: ISRM approach focus ................................................................................. 55 Figure 4-1: Chapter focus ............................................................................................... 59 Figure 4-2: Relationships between ITIL volumes ............................................................ 65 Figure 4-3: CobiT structure............................................................................................. 69 Figure 4-4: CobiT products ............................................................................................. 71 Figure 5-1: Functions of an organisation......................................................................... 78 Figure 5-2: How the functions interrelate ........................................................................ 80 Figure 5-3: Strategic business units................................................................................ 86 Figure 5-4: Functional departmentalisation ..................................................................... 88 Figure 5-5: Geographic departmentalisation ................................................................... 88 Figure 5-6: Product departmentalisation ......................................................................... 89 Figure 5-7: Customer departmentalisation ...................................................................... 90 Figure 5-8: Project departmentalisation .......................................................................... 91 Figure 5-9: Matrix departmentalisation............................................................................ 92 Figure 6-1: General view of ERM.................................................................................. 101 Figure 6-2: ERM components ....................................................................................... 104 Figure 7-1: Treasury Board of Canada Integrated Risk Management Framework......... 114 Figure 7-2: Grant Thornton ERM Framework and Risk Profile ...................................... 118 Figure 7-3: COSO ERM Framework ............................................................................. 121 Figure 8-1: Comparative framework.............................................................................. 135 Figure 8-2: Core risk management component layout................................................... 140 Figure 8-3: Control balance time line ............................................................................ 146 Figure 8-4: Compliance and need for adaptability inverse relationship ......................... 153 Figure 8-5: Example of inverse scale............................................................................ 153 Figure 8-6: Final Compliance Calculation Steps ........................................................... 155 Figure 8-7: BFME implementation ................................................................................ 156 Figure 9-1: BFIC core indicators and respective groupings........................................... 167 Figure 9-2: BFIC process supporting indicators ............................................................ 168 Figure 9-3: Relationships between BFIC risk management supporting indicators ......... 168 Figure 9-4: Bornman Framework for ISM Information Communication.......................... 169

xi

List of Figures

Figure 9-5: BFIC component example .......................................................................... 170 Figure 10-1: ISRM holistic framework ........................................................................... 193 Figure 10-2: BRC objectives ......................................................................................... 194 Figure 10-3: BRC prototype components...................................................................... 195 Figure 10-4: Console data source flow diagram............................................................ 197 Figure 10-5: BRC prototype views ................................................................................ 198 Figure 10-6: Console’s overview view........................................................................... 199 Figure 10-7: BRC console view .................................................................................... 200 Figure 10-8: BRC XML data view.................................................................................. 202 Figure 10-9: Console distributed nature........................................................................ 203

xii

LIST OF TABLES Table 4-1: CobiT information criteria grouping ................................................................ 69 Table 7-1: ERM distribution/responsibility ..................................................................... 127 Table 8-1: CobiT information criteria security requirements .......................................... 137 Table 8-2: Example of evaluation process ................................................................... 154 Table 9-1: BFIC measure levels.................................................................................... 171 Table 9-2: Risk action plan measures........................................................................... 174 Table 9-3: Asset measures........................................................................................... 174 Table 9-4: Threat measures.......................................................................................... 175 Table 9-5: Vulnerability measures................................................................................. 176 Table 9-6: Cause and effect measures ......................................................................... 176 Table 9-7: Consequence measures .............................................................................. 177 Table 9-8: Likelihood measures.................................................................................... 178 Table 9-9: Safeguard measures.................................................................................... 179 Table 9-10: Risk measures........................................................................................... 179 Table 9-11: Risk ranking measure ................................................................................ 180 Table 9-12: Control conflict measure ............................................................................ 180 Table 9-13: Control purpose communication measure.................................................. 181 Table 9-14: Control monitoring measure....................................................................... 181 Table 9-15: Incident reporting measure ........................................................................ 182 Table 9-16: Consideration of identification measure ..................................................... 183 Table 9-17: Categories of risk measure ........................................................................ 183 Table 9-18: ROI calculation measure............................................................................ 184 Table 9-19: Balanced control measure ......................................................................... 184 Table 9-20: Residual risk measure ............................................................................... 185 Table 9-21: Third-party objectivity measure .................................................................. 185 Table 9-22: Global and system level assessment measure .......................................... 186 Table 9-23: Reassessment measure ............................................................................ 186 Table 9-24: Management input measure ...................................................................... 187 Table 9-25: Incident reporting measure ........................................................................ 187 Table 9-26: Risk policy and procedures measure ......................................................... 188 Table 9-27: Risk support documentation measure........................................................ 189 Table 9-28: Risk ownership and responsibility measure ............................................... 189

xiii

C h a p te r 1

INTRODUCTION 1.1. INTRODUCTION Organisations are becoming increasingly dependent on their information technology infrastructures. These infrastructures can be proprietary networks, systems or public shared networks, for instance the Internet. Information technology infrastructures have enabled organisations to be more decentralised and have increased communication options more than ever before. With these decentralisation and increased communication options, organisations have become more vulnerable to existing threats and some never before encountered. New threats are constantly emerging that take advantage of technological vulnerabilities that can impact all aspects of an organisation. With these new vulnerabilities and threats, organisations are more vulnerable than ever before. This dissertation focuses on a specific problem related to securing information through risk management processes. The next section motivates why research in this area was undertaken.

1.2. MOTIVATION FOR THIS STUDY The research was instigated as a result of different concerns that management of organisations currently face and will be facing. These concerns range from technical to management levels. Need for Risk Management There is a growing concern among stakeholders of organisations with regard to the power held by managers [KING 02]. That is why stakeholders demand greater diligence in the management of assets that they entrust to management. However, information technology forms the foundation of enablers of modern organisations and any risks which face this foundation will have an impact on the whole

1

Introduction

organisation. This necessitates due diligence within the operation of information technology and, in particular, ensuring the security of the intangible assets (data and information) which are managed by information technology. Importance of Information Organisations are aware of the importance of the information that they control. Information not only provides them with assets to better serve their clientele, but it is in a growing number of instances the commodity. Organisations have to ensure that they protect these assets as they would any other important assets. However, intangible assets such as data and information are more difficult to protect as the vulnerability of information is such that if it is compromised, it is difficult for the organisation to determine this. Management and Accessibility of Information Due to the growing importance and value of information, organisations are gathering it at an unprecedented rate. This enormous amount of information has to be managed in such a manner to gain the maximum value from it. Having timely access to the appropriate information in a manner that adds value to services and products is becoming paramount to information management of organisations. Distributed environments make for modular information asset distribution, which means that these assets are more often than not closest to the primary users of that information. These distributed environments make it more difficult to control the access people and systems have to the assets. Having the decentralised system and controls increases the risks of the assets being compromised. Responsibility and Accountability By law management of organisations are being held more responsible and accountable for their information assets. This is enforced by privacy laws that require organisations to protect information of customers and employees. This requires management to be more astute in protecting the assets that are entrusted to them. Standardisation and Communication Organisations are using more standardised and public communication mediums. The Internet is considered by many as the most influential medium of organisations. Although the Internet facilitates communication to a degree never

2

Introduction

before envisaged, it has opened organisations to more risks and a dynamic environment with new risks emerging constantly. This communication and standardisation exposes organisations to aspects that are beyond their control, for instance the public communication networks. These aspects require greater diligence in securing organisational assets. All of the motivations listed in this section boil down to protecting the information and data assets of an organisation in a dynamic environment. These motivations lead to a problem that is solved in this dissertation. The problem is defined in the next section.

1.3. PROBLEM STATEMENT Information security risk management (ISRM) is dissimilar to other risk management areas. It addresses risks of the underlying foundation of modern organisations, information and the security involved. This risk management area has many obstacles from a business perspective, which makes it difficult to understand, control and implement. This section outlines the problems within ISRM. However, these problems boil down to a single concept, ISRM communication. These communication obstacles are broken down into manageable subsections. Definitions and Concepts Risk management as a business practice is riddled with ambiguous terminology. This ambiguity is further augmented throughout an organisation as different risk management principles are applied within each business unit or function. The processes, standards and methodologies that are employed in the different business units and business principles have different risk management definitions associated with them. These various definitions are in many ways contradictory. These contradictory definitions make it difficult to communicate risk management related aspects to various parties. Various Risk Management Needs Organisations consist of different units, structures, management levels and resource combinations. This immeasurable permutation of combinations increases the complexity of needs and requirement of risk management for an organisation.

3

Introduction

Organisations have to communicate risk information to meet these needs. This communication is not only vertical but also horizontal within the organisational structure. Silo Risk Management Risk management is usually associated with a silo management approach. This silo approach describes the concept of managing risk within a business function, for instance logistics, finance or procurement. However, ISRM is a cross-functional practice that has an impact on different functional silos. The impact that ISRM has on other silos goes both ways; ISRM is very integrated into other areas. However, the ISRM approaches do not provide information in such a way that it can be incorporated into the risk management approaches of the other silos. Risk Management Information Risk management methodologies are concerned with gathering information, using that information in determining risks, measuring those risks and controlling and monitoring them. These processes require and produce vast amounts of data and decision-enabling information for management in respective functional silos in an organisation. Each functional silo implements different risk management approaches at different levels, which produces great amounts of disjointed data and information sets. These information sets have to be communicated effectively for them to add value to an organisation. Risk Management Approaches Management has different approaches that it can employ to practise risk management. However, these approaches differ from each other and pairing them with approaches at the different levels of management increases the ambiguity in data, communication, terms and coordination. This ambiguous communication leads to ineffective risk management in the different functional units and the organisation as a whole. Risk Management Communication Considering the various methods, needs, terms, approaches and definitions, communicating risk management processes, results and coordination is a daunting undertaking. These different considerations, from a holistic point of view,

4

Introduction

can be compared to a huge jigsaw puzzle where the pieces do not fit together; consequently there is no holistic risk picture. Focusing on just the ISRM principle in organisations, there are inconsistencies in what is expected, provided, delivered, managed and communicated. This is as a result of standards, products, frameworks, methods and approaches that are targeted at specific levels of an organisation. Even if these solutions effectively address problems at the different levels, they do not take into consideration the solutions in the other levels of the organisation. With this lack of consideration, the terminology ambiguity, concepts and incompatibility of processes can lead to ineffective or ambiguous communications. Dynamic Environment Information technology is constantly changing with new risks emerging on a daily basis. This dynamic environment requires that methodologies and processes be employed which identify and address risks in a timely manner. However, the ISRM methodologies that are available to management are time-consuming. Although the methodologies have sequential processes to address risks, the rapidly changing environment introduces risks at such a rate that once a risk management cycle has finished controlling the risks, multiple incidents of new risks have been introduced. This leads to ISRM not proactively managing risks. This section outlined the various components that constitute the problem with ISRM within an organisation. This problem is solved by following a structured approach. This approach is discussed in the next section.

1.4. PROBLEM SOLUTION APPROACH “That is the essence of science: Ask an impertinent question, and you are on the way to a pertinent answer.” – Bronowski, Jacob (1908-1974) Ascent of man (1973) ch.4. The problem is approached by systematically addressing specific portions of the problem. Defining terms and concepts related to information security and its management is the first step. This serves to eliminate any ambiguity in the ISRM arena.

5

Introduction

As part of the background study the different risk management needs have to be defined. These needs are determined by investigating the different areas within the organisation that are associated with ISRM and the requirements placed on these areas. Once the needs have been determined, the information that they require and produce should be determined. This will provide a holistic view of whether or not tools and applications produce the required information. The tools and applications that are applicable to ISRM should be evaluated. This evaluation should form a structured approach and should be based on the needs of the decision-makers. Different approaches should be included in this evaluation. If the ISRM approaches meet the needs of the decision-makers, the question is how the risk information is going to be communicated effectively to the appropriate people. This question will have to be brought in line by evaluating how organisations communicate risk information and what can provide better communication. Risk management is usually based on a silo approach. Silo risk management refers to the practice of being limited by the scope of its parent functional business unit, for instance finance or logistics. This is not the case with information security as the nature of business information and underlying information technology permeates all functions of an organisation. Therefore an investigation into the role of information technology in the bigger scheme of the organisation is required. The overall guideline used in the approach is to investigate what is required and to align and streamline the processes and technologies to deliver on the requirements. This is accomplished by dividing the approach into chapters. Each chapter addresses a component of the solution approach. The next section discusses the layout of the dissertation.

1.5. DISSERTATION LAYOUT This dissertation consists of 11 chapters. Figure 1-1 provides a graphical representation of the dissertation’s layout.

6

Introduction

The dissertation is divided into two parts. Part 1 consists of seven chapters and Part 2 of four chapters.

e r tu a r e ti L d n u o r g k c a B – 1 t r a P

Chapter 1 Introduction Chapter 2 Information Security Risk Management Concepts Chapter 3 Information Security Risk Management Methodologies

Chapter 4 Organisational Governance and Information Security

Chapter 5 Organisational Structures and ISRM

Chapter 6 Enterprise Risk Management Chapter 7 ERM Frameworks

Chapter 8 Bornman Framework for ISRM Methodology Evaluation Chapter 9 Bornman Framework for ISRM Information Communication

n io t u l o S 2 t r a P

Chapter 10 Bornman Risk Console Chapter 11 Conclusion

Figure 1-1: Dissertation layout

Part 1 will focus on the background literature that puts the problem stated above into the context of the organisation. As illustrated in the figure below, Chapter 1 and Chapter 2 should be read sequentially while Chapter 3 to Chapter 6 can be read in parallel. Chapter 7 builds on Chapter 6 and should be read sequentially. Chapter 1 is the introduction that provides the problem statement and research methodology that is followed. In order to provide background information on risk management, Chapter 2 defines the concepts of information security, risk and the management processes to address risk related to information security. Chapter 3 and Chapter 4 provide a top-down and bottom-up view of ISRM, while Chapter 5 investigates how the organisational structure impacts ISRM. Chapter 6 gives an enterprise-wide view of how all the risk management components fit

7

Introduction

together in an organisation. Chapter 7 concludes Part 1 with discussions on approaches

to

implement

enterprise-wide

risk

management

(ERM)

in

organisations. Throughout the dissertation references are made to the various managerial levels in an organisation. Three generic risk management levels are used; they are strategic, tactical and operational (see paragraph 2.4). Chapter 3 discusses various ISRM methodologies. These methodologies are generally selected by tactical management. Chapter 4 investigates the regulations, tools and frameworks that strategic level management has at its disposal. Chapter 5 looks at how the risk management principle fits within an organisation. This chapter outlines various organisational structures. It also addresses who is responsible for the risk management function within an organisation and the responsible management silo. All three managerial levels are referred to in this chapter. Chapter 6 and Chapter 7 explore the concept of ERM and evaluate the role of information security risk management within the ERM context. Part 2 focuses on addressing the problem that is identified by the background study. The first process in addressing the problem brings the operational methodologies more in line with the requirements of middle and top management. Chapter 8 suggests a comparative framework to accomplish this. Chapter 9 outlines an ISRM console that was developed to provide management with risk information which is compliant with information technology and corporate governance requirements. Chapter 10 describes the prototype ISRM console based on the evaluation framework of Chapter 8 and the console measures described in Chapter 9. The dissertation closes with a summary provided in Chapter 11, along with possible future research areas that flow from the results of this dissertation. The chapter layout discussed in this section outlined the structure that is followed in addressing the problem highlighted in section 1.3. These two sections are

8

Introduction

based on the research methodology that was followed, which is discussed in the next section.

1.6. RESEARCH METHODOLOGY Research methodology indicates the approaches that were followed in the research; not only the approaches in defining the problem, scope and background of the research topic, but also those used in solving the problem. Various approaches could have been used. However, primarily two approaches were used in this research; they are literature study and prototyping [OLIV 99]. Literature Study The literature study was an iterative process. Initially it served to provide a general overview of the ISRM environment. Journal articles, published books and ISRM methodologies formed the basis of this literature study. From the literature study it became apparent that there are numerous potential research topics within the ISRM domain. Each of these topics was further investigated by means of an extensive literature review. Once the research focus was determined, the literature study focused on the research problem. The research problem was broken down into logical units which facilitated the process of identifying and gathering appropriate literature. The literature on each logical unit was evaluated against its relevance to the research problem. During the literature study it became apparent that ISRM is both influenced by and influences numerous business functions. The most prominent influences were identified and included in the iterative literature identification and evaluation process. This led to the identification and evaluation of laws, regulations and government recommendations that become more focused on information technology. Although the literature study’s primary role was to provide contextual and background information on ISRM, it provided valuable information in developing a solution to the research problem. Journals, methodology documentation, books, laws, regulations, standards and recommendations provided detailed information

9

Introduction

and guidance on developing a solution to the problem that resulted in the development of a prototype. Prototype A proof of concept prototype was developed to illustrate that the solution does indeed solve the research problem. The prototype is a software program that was structured on the solution and serves to automate the developed processes. In order to develop a proof of concept prototype various technologies have to be researched. This technology research involves the technology of the ISRM methodologies, communication technologies and technologies for programming the prototype. The research methodology was followed in order to achieve a specific research goal. This research goal is defined in the next section.

1.7. RESEARCH GOAL The goal of this research is to develop a solution to the problem of ISRM ambiguity in terms of communication, processes, needs and execution. This research goal will be achieved in order to add value to the field of ISRM. The next section briefly discusses the potential value the research holds for ISRM.

1.8. RESEARCH VALUE This research is undertaken to solve problems that face the ISRM principle but should do so in order to add value to an organisation. Therefore the research solution will add value in terms of the following areas: Reduced ISRM Ambiguity Reducing any ambiguity associated with ISRM can result in better understanding, communicating and controlling of risks. Prove Unified Risk Management Communication The research will suggest a framework for ISRM communication which complies with strategic risk information requirements. The framework will prove that it is possible to communicate risk information effectively and efficiently from the operational level of an organisation to its top (strategic) level management.

10

Introduction

Requirements of top management, be they regulatory, managerial or for competitive advantage, can be met by processes at operational level. Risk Management Competitive Advantage Risk management is not only concerned with identifying any negative impacts on the organisation. It can also identify areas that can be exploited to an organisation’s advantage. By having a system that facilitates better risk information communication, management can focus more on identifying incidents that can negatively and positively affect the organisation. Risk Management meets Needs The differences between the needs of top management and those of the rest of the organisation, combined with regulatory demands, different environments and asset groupings, make customising risk communication channels a daunting task. The research suggests a generic communication channel that can be applied to all types of organisations in all types of environments. Seamless Risk Management According to the King II Report [KING 02], risk management should form part of the daily operational activities of organisations. However, risk management is often considered to be projects that share resources with normal business functions. By having processes and technology in place, the risk management function can be seamlessly integrated with daily operations. Real-time Risk Management Information There are numerous information security risk controls that are technology based. These technologies provide real-time information about incidents and threat and vulnerability status. The research will keep these technologies in mind during the development of the solution and use them as part of the ISRM processes and not merely as control management.

1.9. CONCLUSION ISRM communications are a great challenge for organisations. There is a need to better manage the risks of information security in an organisation, as information is a valuable resource and the threats to and vulnerabilities of this resource are increasing dramatically. There are various methodologies that propose to be the

11

Introduction

solution in managing the risks and these methodologies are evaluated throughout the dissertation. However, one of the communication culprits is the ambiguous terminology of ISRM. The next chapter will define and discuss ISRM terminology and concepts.

12

C h a p te r 2

INFORMATION SECURITY RISK

ANAGEMENT CONCEPTS

M

2.1. INTRODUCTION Different standards coupled with methodologies, guidelines and frameworks produce a cornucopia of definitions of information security risk management and related components. These ambiguous terminologies, concepts and scope definitions lead to confusion in communicating risk information, thereby reducing the effectiveness of risk management. The goal of this chapter is to define information security and its related risk management concepts as used in this document. In order to manage risks related to information security the first objective is to understand what information security is. The second objective is to define risk and what components constitute it. The third objective is to outline who is responsible for ISRM and to associate actions with these levels. ISRM as a management principle consists of cyclical processes which should be able to be narrowed to a few generic steps. The next objective is to define a set of generic risk management steps. ISRM has various related concepts, which have to be identified as the final objective. The structure of the chapter is guided by the objectives. The definitions of risk and its components are preceded by the definitions of information security and its components. The responsible parties within an organisation are defined before defining the risk related concepts and processes for which they are responsible. The next section discusses the concept of information security as the basis of ISRM.

13

Information Security Risk Management Concepts

2.2. INFORMATION SECURITY In order to secure something, there are two aspects that have to be considered. They are what is to be secured and what specific aspects of it are to be secured. This section discusses the concepts of information (what to secure) and information security (specific aspects to secure). First a distinction has to be made between data and information. Data is the raw facts that have not been processed yet, while information is processed data on which decisions can be based [ROB 00]. Information security is concerned not only with securing decision-enabling information, but the security of the data, from which information is derived, as well. Information security is considered to consist of three primary components [CRAM01 96]: confidentiality, integrity and availability. These components are also referred to as security requirements [TUDO 01] or security goals [PFLE 97].

2.2.1. Confidentiality Confidentiality is ensuring that information is accessible only to those authorised to have access [SABS 00], regardless of where the information is stored or how it is accessed [TUDO 01] [PFLE 97].

2.2.2. Integrity Integrity can be described as safeguarding the accuracy and completeness of information and processing methods [SABS 00]. It is protecting information from intentional, unauthorised or accidental changes [TUDO 01] [PFLE 97]. Furthermore, it is important to protect the processes and software that have access to the information.

2.2.3. Availability Availability is ensuring that authorised users have access to information and associated assets when required [SABS 00] [TUDO 01] [PFLE 97]. Although the three primary components discussed here are considered to be best practice, there are other views of what can be considered as secondary information security components. The next section discusses these secondary components.

14


2.2.4. Secondary Information Security Components According to Donn Parker [PARK 04] information security components should consist of more than the confidentiality, integrity and availability of information. He proposes an extension to the Bob Courtney model [PARK 04] [BRIN04] of confidentiality, integrity and authenticity with utility, possession, deterrence, prevention, detection, mitigation, transference, sanctions and rewards, recovery and, correction of loss [BRIN 04]. The secondary information security components of Donn Parker are excluded from the research for three reasons. 1. The majority of the secondary components have been grouped into other information security principle. For example prevention, detection, mitigation and transference forms part of information security controls (see section 2.5.3). 2. Secondary components are not considered by the information security risk management methodologies discussed in Chapter 3. These components are further not explicitly required by corporate governance recommendation discussed in Chapter 4. 3. The secondary components focus on a security community where security forms part of job performance [PARK 02]. This stance advocates the elimination of measures assigned to risk related actions for instance probability and impact [PARK 04]. Since the ISRM methodologies that are discussed in this document all regard risk measures as paramount the secondary components of Parker contradicts best practice. Information security is compromised if at least one of the primary information security components is violated by a risk. However, various components have to be present before a risk exists. The next section investigates risk and its components.

2.3. RISK COMPONENTS Risk has various definitions depending on its context; however, there is relative consensus on the components that constitute risk. Risk is the chance of something happening that will have an impact upon objectives [ASNZ 99]. It can

15


also be seen as the possibility of suffering harm or loss [ALBE 03]. The definition of risk as used in this document is as follows: Risk is a function of the likelihood of a given threat’s source exploiting a particular potential vulnerability, and the resulting impact of that adverse event on the organisation [STON 01]. Risk has various definitions; however, different sources are of one mind that risk has at least two components: likelihood and impact [CONR 03] [FRAM 03]. These components are considered to be the risk measure components. They make up the values that can be assigned to a risk (see section 2.5.2). Although these components are iterated in numerous sources, these components do not address the even more basic components of risk. Asking questions like “likelihood of what?” and “impact on what?” reveals that certain components are taken for granted when defining these components as the only risk components. Answers to the above questions provide three lower level components of risk. They are asset, vulnerability and threat. The likelihood and impact components can be seen as subcomponents of vulnerability (impact) and threat (likelihood). Unlike the probability and impact components, these three components establish the existence of risk and not a relative value of risk. Figure 2-1 provides a graphical representation of the risk component relationships. A threat exploiting an asset’s vulnerability provides the likelihood component, while the vulnerability of the asset to be exploited provides the impact component. The figure indicates that the threat and vulnerability components are applicable to each of the subgroupings of assets (tangible and intangible).

Figure 2-1: Risk components

Each of the components illustrated in Figure 2-1 are discussed in the next sections.

16


2.3.1. Asset In general terms an asset can be defined as something that has value to organisations [ALBE 03]. In a financial context the term ‘asset’ refers to a resource that is controlled by an organisation as a result of past events and from which future benefits are expected to flow to the organisation [SAIC 02] [FAEL 99]. Although this has been accepted as a financial definition of assets, there are different groupings of assets. Of these different groupings the most popular is the grouping of assets into tangible and intangible assets [SAIC 02] [PELT 01].

2.3.1.1. Tangible Assets Tangible assets are also referred to as physical assets [PELT 01] and are loosely defined as those items that can be seen. The financial definition of a tangible asset is the requirement that it be in physical form and comply with the definition of an asset as above [SAIC 02]. Within

the

workstations,

information input

technology

devices,

domain,

network

hardware

infrastructure

such and

as

servers,

communication

infrastructure is considered to be a tangible asset. However, the physical form of an asset alone does not qualify a resource to be an asset in the case of software, knowledge and debtors, which are intangible assets.

2.3.1.2. Intangible Assets Intangible or logical assets [PELT 01] are the logical property of an organisation. According to the South African Institute of Chartered Accountants [SAIC 02], an intangible asset is an identifiable non-monetary asset without physical substance which is held by an organisation in the production or delivering of goods and services, renting or administrative purposes. The intangible assets of the IT domain are, among others, the intellectual property of an organisation (software), knowledge (employees) and patents. Information and data fall into this asset grouping (see paragraph 2.2). A risk only exists when a threat exploits a vulnerability of an asset. The next section discusses what a threat is.

17


2.3.2. Threat According to Peter Neuman [NEUM 95], a threat is the danger that a vulnerability can actually lead to undesirable consequences. Tom Peltier [PELT 01] regards a threat as an intent to do something bad to something or someone, while the Webster Dictionary regards a threat as an indication of an impending undesirable event [PELT 01]. The CORAS methodology for risk assessment [IST 03] regards a threat as the representation of a potential cause for loss of asset value. Threats can be grouped into three categories within the IT domain. These groupings have been proposed by various authors [PELT 01] [PFLE 97] [NEUM 95] [STON 01] and are used by ISRM methods such as CRAMM [CRAM01 96] [CRAM02 96] [INSI01 03] and OCTAVE [ALBE 01] [ALBE 03]. The groupings’ designation represents the source of the threat.

Figure 2-2: Threat groupings

2.3.2.1. Human Threats originating from a human source can be subgrouped according to the motive elements as described by Peltier [PELT 01]. The motives are accidental and malevolent. Accidental human threats are those threats that are unintended and unexpected events, for instance an employee spilling coffee on a computer. Malevolent human threats are also referred to as malicious threats.

This

subgrouping indicates all the threats that humans deliberately undertake to affect an organisation. An example of this type of threat is a disgruntled employee deleting important information from the organisation’s computers.

18


Although threats can originate from humans, be it internal or external to the organisation, they can be controlled to an extent. However, some threats are beyond the control of humans.

2.3.2.2. Natural Threats originating from nature are threats that are commonly referred to as acts of God. Some of the threats grouped under nature are cyclones, erosion, floods, earthquakes and lightning, etc.

2.3.2.3. Technical Technical failure refers to the unforeseen failure of the technology, for instance a computer hard drive crashing and losing all information stored on it [INSI01 03]. A threat only exists when there is a vulnerability of an asset that can be exploited. The next section discusses the concept of vulnerability.

2.3.3. Vulnerability A vulnerability is a weakness that can be triggered accidentally or exploited intentionally [STON 01] [NEUM 95]. From this definition a vulnerability is the potential to exploit an asset, which makes a vulnerability an element of an asset. For instance, a computer hard drive fails when it is exposed to moisture. Therefore it is vulnerable to liquids, rain or damp. Vulnerability can be classed as unsatisfactory controls, or exceptional circumstances that have not been planned for or that nullify the effect of existing, satisfactory, controls [IST 03]. Vulnerabilities can be thought of as control mechanisms that ideally should be in place, but for some reason they are missing or not sufficiently robust [IST 03]. This section discussed the components of risk. The next section investigates management’s responsibility towards ISRM.

2.4. MANAGEMENT Throughout the document risk management is discussed in terms of three generic levels of management. The levels correspond with the time frame of the decisions that are made at that particular level, as illustrated in Figure 2-3. Short term refers to a period of less than one year, medium term refers to one to approximately five years and long term refers to a period more than five years [HEJS 99].

19


Figure 2-3: Managerial levels

2.4.1. Strategic Management Strategic management makes long-term decisions which are major courses of action for an organisation [EGLI 04]. In order to execute decisions effectively and efficiently, various functions and processes have to be coordinated within the organisation. Strategic management is responsible for this coordination along with developing a strategic vision [MCGR 04].

2.4.2. Tactical Management Tactical management refers to a less significance term than strategic operations [DICT 04]. It is also known as middle level management. At this level, management is responsible for transforming the strategic vision of the organisation into processes and functions.

2.4.3. Operational Management Operational management is also referred to as first-line management. It is responsible for executing the processes developed at tactical level by employing people, internal processes and systems [RISK 04]. Different processes and steps of ISRM are the responsibility of the different managerial levels of an organisation. The processes and steps depend on the organisation. Generic risk management steps are outlined in the next section.

20


2.5. GENERIC RISK MANAGEMENT PROCESSES Risk management has different meanings for different people. A generic definition of risk management is an act or practice of dealing with risk [CONR 03]. However, risk management is applied by people on a daily basis; walking across the street, for instance. Standards, frameworks and methodologies have a varying number of risk management steps, although closer inspection of risk management processes results in the identification of four generic risk management processes. They are identify, measure, control and monitor [PELT 01]. Figure 2-4 illustrates the cyclical nature of the risk management processes.

Figure 2-4: Generic risk management processes

Each of the processes illustrated in Figure 2-4 are discussed in the following sections.

2.5.1. Identify A high level definition of the identification process is the process that identifies, list and characterises elements of risk [ISO 02]. This definition encapsulates the identification of the components outlined in section 2.3. During the identification process the risk components have to be broken down into the basic components in order to achieve an effective risk assessment [CONR 03]. This is the identification of the assets, threat and vulnerability components. During the identification two other components have to be identified for each risk. They are the consequences and probability components of a risk [ISO 02] [CONR 03] [PELT 01] [DPWS 01] [ASNZ 99]. The probability component is often interchangeably used with frequency [ASNZ 99]. This value indicates the chances or incident rate over a specified period. The ISO/IEC [ISO 02] define probability as the extent to which an event is likely to occur. Consequence is the outcome [ISO 02] or result of a risk occurring. A risk can have more than one consequence.

21


2.5.2. Measure Measure is the process of determining a risk value for the identified risks. Risk can be measured in terms of consequences and likelihood [DPWS 01] [ASNZ 99]. There are numerous and varying approaches to risk measurement. A basic risk value formula is [PELT 01] [INSI01 03]: Risk Value = Probability x Impact In order to calculate a value for risk, the values of the multipliers can be either of two types. They are qualitative or quantitative values [PELT 01] [IST 03]. a) Qualitative Value A qualitative value does not attempt to assign a numeric value to a risk component [PELT 01]. A qualitative value uses word forms or descriptive scales to describe values [ASNZ 99]. These values are usually adapted to suit the circumstances of the risk assessment. This type of value assignment is less time-consuming and is effective in the initial screening of risks. The qualitative measures of high, medium and low provide the simplest means of assigning values to risk impacts [ALBE 03]. b) Quantitative Value Quantitative values are numerical values assigned to a risk component and are derived from factual data [ASNZ 99]. These numerical values can be financial, calculated or counted values, for instance the number of successful hacking attempts on a server.

2.5.3. Control Once the risks have been identified and measurements assigned to their components, decisions have to be made on how to address the risks. The actions that will be taken will depend on the organisation’s ability to accept risk, also referred to as risk tolerance [KING 02]. If an organisation has a high risk tolerance, it will accept risk that has higher probability and impact values than others. Therefore the number of risks it will avoid is minimal. Figure 2-5 provides a graphical representation of the probability and impact relationship to the four generic actions management can take in terms of addressing risks [CONR 03].

22


yti li ba bo rP

Manage

Avoid

Accept

Transfer

Impact Figure 2-5: Risk management control decision

The figure is divided into four quadrants with the y-axis indicating probability and the x-axis representing impact. Each quadrant illustrates the actions management can take with regard to a risk depending on the relationship to probability and impact. The four actions are generic and the level determining which actions to be taken will depend on the organisation’s willingness to accept risk. If the probability is high and the impact low, the course of action is to manage the risk, while a high probability and high impact recommends an avoidance action. Each of the risk management control decisions illustrated in Figure 2-5 are discussed in more detail. a) Manage Managing or risk mitigation is actions taken to reduce either the impact of risk or the probability that the risk will arise [ASNZ 99] [FRAM 03]. If an organisation is situated in an area that has constant power outages that result in server downtime, risk mitigation action can include the implementation of an offsite server backup centre. The backup centre can take over the primary site’s function, thereby reducing the impact and negating the probability of the risk. b) Avoid Risk avoidance is concerned with reducing the organisation’s exposure to the likelihood of risk by avoiding situations that could give rise to the risk in question [FRAM 03] [CRAM01 96]. For instance, if an organisation is situated in an area 23


that has a high probability of tornados, an avoidance decision might involve relocating and reducing that particular risk exposure. c) Accept Risk management’s goal is not to eliminate risk but to reduce it to an acceptable level. Risk acceptance is the process of acknowledging an acceptable level of risk without taking measures to control or mitigate the risk [CONR 03]. For instance, if there is a low probability of a threat having an impact on an organisation, it will be best to accept it rather than spending capital to address an inconsequential risk. d) Transfer A risk places a burden on organisations in terms of impact and required resources to manage it. Risk transference is the action of shifting this burden to a third party [FRAM 03] [CRAM01 96]. There are various ways in which risk events can be transferred, for instance warranties, contracts or insurance.

2.5.4. Monitor Organisations invest time and resources into the identification, measurement and controlling of risks. These investments should not be in vain. Therefore, risk should be periodically reviewed and evaluated to determine the need for additional risk management [DPWS 01]. It is important to ensure that the risk management processes are executed and making an impact on the risks, and the way to determine this is through the monitoring process. The four generic steps of identification, measurement, control and monitoring are basic risk management processes. These processes can be complemented by other risk management concepts that describe groupings of the above processes and elaborate on results obtained from them. These risk management concepts are discussed in the next section.

2.6. RISK MANAGEMENT CONCEPTS Risk management is an area with not only various ambiguous terms, but also concepts that relate to groupings of terms. This section will highlight some of these ambiguous terms and define them as they will be used within this dissertation.

24


Figure 2-6 provides a graphical representation of the different concepts that are discussed in this section.

Figure 2-6: Relationships between risk management concepts

The concepts illustrated in Figure 2-6 are addressed from the outside in.

2.6.1. Information Technology Risk Management (ITRM) ITRM encompasses more than just the security of information. ITRM is process, financial, investment, business and any other risk area that can have an impact on information technology. An example of ITRM is the consideration of implementing a wireless network instead of a traditional cable-based network infrastructure. Aspects that will be considered are the long-term financial impact, security impact and operational aspects.

2.6.2. Information Security Risk Management (ISRM) ISRM focuses on the basic security requirements of the information and its related aspects, for instance hardware, software, processes and human elements. ISRM consists of the processes that will identify, measure, address and monitor risks, for instance the risks a database server will face if a web server is granted access to it. The three concepts that are grouped under ISRM in Figure 2-6 consist of overlapping generic risk management processes.

2.6.3. Risk Analysis Risk analysis is the initial processes of identifying, measuring and prioritising risk [LABU 92]. Conrow [CONR 03] defines risk analysis as the process of examining

25


each risk to refine its description, isolate the cause and determine the effects [ASNZ 99].

2.6.4. Risk Assessment Risk assessment is the process that includes the processes of risk analysis as well as proposing controls to address the risks [ASNZ 99]. It is the risk processes associated with increasing the likelihood of meeting cost, performance and schedule objectives [CONR 03].

2.6.5. Risk Evaluation Considering the generic processes of risk management, risk evaluation is the subgrouping of measurement and control [IST 03]. It encompasses the decisionmaking processes of which risks will be addressed and how. Risk evaluation further includes the evaluation of the proposed risk controls.

2.6.6. Other Concepts Risk management terms/concepts that do not refer to groupings of risk still have an impact on how risks will be managed through the processes. These concepts are: a) Risk Tolerance Risk tolerance is also known as risk profile or risk appetite. It is the level of risk an organisation is willing to accept. An acceptable level is a level of risk where the risk-taker makes the decision that he or she accepts the consequence of the identified risk [FRAM 03] [CRAM01 96]. Risk tolerance is defined by strategic management [COBI03 00]. b) Residual Risk Not all risks can be eliminated, nor can they all be controlled. Risks have to be reduced to an acceptable level. Risks that remain after the implementation of controls are known as residual risk [STEV 03]. Residual risk is the risk that remains after the identified risks have been controlled. Residual risk = Gross risk – Controlled risk

26


In order to determine if an organisation is meeting its risk tolerance objective, the level of acceptable risk has to be compared to the residual risk. If the residual risk is more than the risk tolerance, then the goal has not been achieved.

2.7. RESEARCH VALUE Standard terminology provides a common ground for communicating risk management information among parties. As stated in Chapter 1, risk management and information security risk management are strewn with ambiguous terminology. The risk management related concepts that are defined in this chapter have been compiled from international standards, best practices and guidelines. The definitions and concepts are discussed in relation to each other, which provides a view of the role and scope of each concept. Defining and outlining the basic concepts reduces the ambiguity of more advanced concepts of risk management. It further assists in consolidating different sets of terminologies to provide a common set of definitions. The concepts defined in this chapter provide a basis for understanding the concepts and frameworks discussed in this dissertation.

2.8. CONCLUSION Information security consists of three basic components: availability, integrity and confidentiality. Although there are various schools of thought on the components of risks, it has been determined that a risk consists of three components. These components are asset, threat and vulnerability. A risk is a function of the likelihood of a given threat’s source exploiting a particular potential vulnerability, and the resulting impact of that adverse event on the organisation. Three generic managerial levels can be identified to assign risk management responsibility according to time. These levels are strategic (long term), tactical (medium term) and operational (short term). At each level a set of generic risk management processes can be executed. These generic risk management processes are risk identification, measurement, control and monitoring. Several risk management related concepts have been identified. Information technology risk management incorporates information security risk management, risk assessment, risk analysis and risk evaluation.

27


The goal of this chapter was to define information security and its related risk management concepts. The goal was achieved by systematically addressing information security, risk, risk management and related concepts. Different objectives were set in order to achieve the chapter’s goals. Each of these objectives was met. A clear understanding of information security was achieved by identifying and defining the components that make up information security. Risk and its components were identified and defined. In order to understand the risk management responsibility the managerial levels of organisations were grouped into three generic levels and their respective responsibilities identified. A set of generic risk management processes were identified. During the identification of these processes, important risk management related concepts were identified. These concepts were clearly defined and explained in context with the generic risk management processes. In this chapter four generic risk management processes were discussed which can be identified in various risk management methodologies. However, methodologies are not the only approaches to addressing information security. The next chapter focuses on different information security risk management approaches that can be implemented at operational level.

28

C h a p te r 3

INFORMATION SECURITY RISK

ANAGEMENT METHODOLOGIES

M

3.1. INTRODUCTION In the previous chapter generic risk management processes were identified. However, there are various approaches which include ISRM methodologies to identify, measure, control and monitor information security risks. Organisations might not realise there are different approaches to address ISRM. This ignorance could lead to ineffective ISRM. The goal of this chapter is to provide an overview of existing ISRM approaches. The first objective is to identify different approaches that can be followed in managing information security related risks. The second objective is to evaluate and discuss each of these approaches. The chapter’s focus is first determined. This focus is indicated relative to a managerial level. Then the different ISRM approaches are identified. From there each of the identified approaches are investigated, and products, documents or processes that belong to that approach are discussed. The next section defines the managerial level that forms the focus of this chapter.

3.2. CHAPTER FOCUS The ISRM approaches discussed in this chapter focus on the lowest (operational) managerial level of an organisation (see paragraph 2.4). Figure 3-1 provides a graphical representation of the managerial level on which this chapter is focused.

29

Information Security Risk Management Methodologies

Figure 3-1: Chapter focus

At operational level, the short term, there are various approaches that management can choose from to address ISRM. The next section identifies these different approaches.

3.3. INFORMATION SECURITY RISK MANAGEMENT APPROACHES Organisations, and specifically operational management, are faced with different approaches that they can employ to address information security risk. This section outlines three basic ISRM approaches that were identified through the literature study. Figure 3-2 provides a graphical representation of the three approaches, which are discussed in this section.

Guidelines

Standards

Methodologies

Figure 3-2: Information security risk management approaches

Each approach has specific documents, products or processes that can be grouped according to the approach, with each approach sharing some

30


commonalities. These shared commonalities are indicated by the overlapping sections of each circle. Each of these approaches is discussed in sections 3.4 to 3.6.

3.4. STANDARDS A standard can be defined as a measure to which others conform, or a degree of excellence for a particular purpose [OXFO 80]. From these definitions it is clear that a standard is a level that an organisation is required to, or aspires to, attain. Usually standards are documents or products that list certain controls that have to be abided by in order to obtain a degree of acceptability. The design and implementation of information security management systems, like standard compliance, is a strategic decision [SANS 03]. Two prominent ISRM standards are outlined. The AS/NZS 4360 [ASNZ 99] is a risk management standard, and the SABS ISO 17799 [SABS 00] is a code of good practice standard. There are several others and this is not an exhaustive listing of standards. a) AS NZS 4360:1999 The AS/NZS 4360:1999 Risk Management is a joint Australian and New Zealand standard. The standard was first published in 1995 and revised in 1999. The standard’s objective is to provide a generic framework for establishing the context, identification, analysis, evaluation, treatment, monitoring and communication of risk [ASNZ 99]. Figure 3-3 (page 32) provides a graphical representation of the AS/NZS 4360:1999 standard. The diagram flows from the top to the bottom and cycles back through the monitoring and review process to the initial step of establishing the context of the risk management processes. The standard highlights the importance of communicating and consulting throughout the execution of the processes. During the ‘Establish the context’ process the scope of the risk management processes is established. The processes of this standard are in line with the generic risk management processes outlined in section 2.5. Several of the risk management concepts outlined in section 2.6.6 are used in describing this

31


standard’s processes, for instance risk evaluation, risk analysis and risk assessment.

Establish the context

Identify risks

Analyse risks

Evaluate risks Assess risks Treat risks

Figure 3-3: AS/NZS 4360 risk management standard

The AS/NZS 4360 standard is a standard from Australia and New Zealand; however, each country can have its own standards. The next section discusses a standard from South Africa. b) SABS ISO/IEC 17799 The SABS ISO/IEC 17799 [SABS 00] standard is an ISO/IEC standard adopted from the BS7799. The ISO/IEC 17799 standard was approved and adopted by South African National Standards and re-released as an SABS ISO/IEC standard. The standard consists of two parts. Part 1 contains information security controls categorised into ten high level control groupings. These high level control groupings address security areas such as the

32


documenting of a security policy, personal security, security education and training, business continuity and virus detection and prevention controls. According to this standard, organisations determine their security requirements through a methodological assessment of risk. Once the risk areas have been identified organisations can use the standard as a guideline or control list that they can implement in order to reduce their risk exposure [SABS 00]. Part 2 specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an information security management system [SANS 03]. Standards and codes of good practices, for instance the SABS ISO/IEC 17799, are used within several existing ISRM methodologies [ALBE 03]. This catalogue of practice or standard provides a benchmark to which organisations can compare themselves. It also provides a structure for an organisation’s protection strategy. The definitions within the SABS ISO/IEC 17799 (Parts 1 and 2) standard are in line with the definitions provided in Chapter 2. The generic risk management processes are represented by the relatively high level Plan-Do-Check-Act (PDCA model) as illustrated in Figure 3-4.

Figure 3-4: SABS ISO/IEC 17799 PDCA model

The standards outlined in this section provide control requirements that have to be put in place to be compliant. There are products that provide organisations with direction rather than dictating what should be implemented; these are known as guidelines.

33


3.5. GUIDELINES Guidelines provide direction for any action or process related to achieving a certain goal. Guidelines can be defined for a specific subset or the complete process of the risk management process. The guidelines discussed in this section provide direction on how to address information security risks. Guidelines differ from standards in that where a standard indicates a certain level that has to be or is desirable to be achieved, the guidelines provide assistance in attaining that level. An analogy of this relationship is a road trip. The standard is the destination and parameters, for instance only use highways. Guidelines are the roadmaps which provide different paths to reach the destination. The guidelines that are discussed are the ISO Guide 73, NIST Risk Management Guide for IT Systems, and ISF Standard of Good Practice for Information Security. a) ISO Guide 73 The ISO/IEC Guide 73 is released by the International Organisation of Standards (ISO), which is a worldwide federation of national standard bodies. This guide was developed in collaboration with the International Electrotechnical Commission (IEC). ISO/IEC Guide 73 [ISO 02] provides specific guidance on terms and definitions of concepts related to risk management and addresses risk from both the negative and positive impact it can have on an organisation. Risks have to be communicated within an organisation as well as to parties external to the organisation. Therefore the guide was developed to assist this communication process. It provides risk vocabulary that is not specific to a business domain; however, the guide notes that the wording can be adapted to suit a specific domain. The guide is generic and is compiled to encompass the general field of risk management [ISO 02].

34


Figure 3-5: ISO/IEC Guide 73

Figure 3-5 provides a graphical representation of the ISO/IEC Guide 73’s structure. It consists of three sections which address the scope, provide an overview of the risk management terms and definitions, and finally list and define terms. These terms and definitions are grouped into four subsections. b) NIST Risk Management Guide for IT Systems The guide is published by the National Institute of Standards and Technology (NIST) in the United States of America as a report from Information Technology Laboratory at NIST. The NIST Risk Management Guide for Information Technology Systems Special Publication 800-30 [STON 01] provides a foundation for developing an effective risk management programme. The guide consists of various sections that address the following risk management areas: •

Risk management concepts and overview – This section addresses the need for risk management and the integration of risk management into the software/system development life cycle, and outlines the key roles within a risk management programme.

•

Risk assessment methodology – The NIST guide outlines a risk assessment methodology that consists of nine steps (see Figure 3-6).

•

Risk mitigation process – Risk mitigation concepts are outlined. These concepts address the mitigation options available, mitigation strategies, an approach for control implementation, control categories, control cost-benefit analysis and residual risk.

•

Good practice – Guidance is provided on evaluation and assessment with specific emphasis on good security practice and keys for success.

35


1. System characterisation 2. Threat identification 3. Vulnerability identification 4. Control analysis 5. Likelihood determination 6. Impact analysis (C-I-A) 7. Risk determination 8. Control recommendation 9. Results documentation Figure 3-6: NIST risk assessment methodology

The recommendations made in the guide are in line with the generic risk management processes outlined in Chapter 2. c) ISF Standard of Good Practice for Information Security The Information Security Forum (ISF) is an organisation that consists of over 250 organisations worldwide that co-operate in the development of standards and best practices geared towards information security [ISF 03]. The ISF also developed a risk management methodology known as the Fundamental Information Risk Management (FIRM) methodology [ISF 00]. This methodology is only available to member organisations. Therefore only the standard of good practice is referred to in this dissertation. This standard of good practice addresses information security from a business perspective by addressing the information security needs of business critical systems. It is updated every two years and is based on research and contributions of ISF members.

36


The standard addresses enterprise-wide security management, critical business applications, computer installations, networks and systems development, as illustrated in Figure 3-7. Each of these areas has a varying number of subgroupings of recommendations. For instance, enterprise-wide security management has subgroupings of security requirements, secure environments, malicious attacks and management review.

Figure 3-7: ISF Standard of Good Practice for Information Security layout

The guide outlines the principle of the objectives of the guide and provides a topic matrix which can be used to relate information security related topics to the Standard of Good Practice components. The Standard of Good Practice primarily consists of five components. These components are security management, critical business applications, computer installations, networks and system development. Each of these components has several areas that provide guidance on that particular component. This section discussed the guidelines that assist organisations in addressing information

security.

The

next

section

addresses

the

final

approach,

methodologies.

3.6. METHODOLOGIES Most methodologies have a Plan-Do-Check-Act (PDCA) cycle which is a systematic and orderly approach [OXFO 80] to risk management [SANS 03]. This dissertation focuses on the use of ISRM methodologies and incorporating standards (see section 3.4) and best practices or guidelines (see section 3.5) as part of the controlling management phase. This incorporation of standards and guidelines is illustrated in Figure 3-2. Labuschagne

[LABU

92]

has

identified

different

generations

of

ISRM

methodologies based on the generic environment in which they were

37


implemented. The current generation’s methodologies focus on a decentralised system which is more interconnected than that of any previous generation. Three different methodologies are discussed. All three methodologies fall into the current generation of ISRM methodologies. Each has a distinct approach in identifying, measuring, controlling and monitoring risks. Each methodology has its own definitions of risk concepts. Although risk concepts are defined in Chapter 2, the terms as they are used within the methodologies are used in this section. Figure 3-8 indicates that for each methodology the approach and processes are discussed.

Figure 3-8: Methodologies section layout

Sections 3.6.1 to 3.6.3 discuss the three different ISRM methodologies. The methodology’s approach and processes are discussed for each methodology. The first methodology that is discussed is the CRAMM methodology.

3.6.1. CRAMM In 1985 the UK government’s Cabinet Office tasked the Central Computer and Telecommunications Agency (CCTA) with investigating the risk analysis and management methods in existence within Central Government for Information Technology [CRAM 03]. Following their investigation a new method was developed by the CCTA which drew upon all of the existing best practices under the title of the CCTA Risk Analysis and Management Method, or CRAMM. Various software packages based on the CRAMM method were released during the 1990s and were eventually wholly funded by Insight Consulting in 2001, which released CRAMM version 5 in 2003.

38


Insight Consulting is a Siemens Communications Business, and is a United Kingdom based provider of services and solutions for information security and risk management [INSI02 03]. CRAMM (version 5) fully supports the five stages of the BS 7799 accreditation [SCOL 01]. CRAMM is available in various versions, each for a specific geographical or governmental market [INSI03 03]. These versions include UK Standard, NATO; Dutch Language; Social Care and National Health Service.

3.6.1.1. CRAMM Approach A CRAMM review is conducted in three stages. During the first stage the organisational business, assets and inventory are determined along with building a model of the organisation. Threats, vulnerabilities and risk measures are determined in the second stage. In the final stage the CRAMM software proposes countermeasures based on the preceding stage’s results. Figure 3-9 provides a graphical representation of the CRAMM approach.

Figure 3-9: CRAMM approach

CRAMM defines risk as a function of two separate components: the likelihood that an unwanted incident will occur and the impact that will result from the incident. CRAMM consists of two distinct processes: analysis and management. CRAMM has an extensive control database. This control database consists of over 3 000 security controls, which are constantly updated [INSI02 03]. Whenever

39


a control is proposed by the software supporting information such as control motivation, cost, benefits, expected advantage and control type are provided. CRAMM’s methodology focuses on identifying risks to important assets and implementing countermeasures with the replacement value of the physical asset in mind. Although the data is valued according to the business impact, it still employs probability as part of the assessment [COBI01 00] [BAMM 99].

3.6.1.2. CRAMM Processes As Figure 3-10 indicates, CRAMM consists of six steps grouped into two processes. The two processes are analysis and management. Each step in the processes is discussed in more detail in this section.

Figure 3-10: CRAMM methodology

a) Assets - Analysis Critical assets are determined through interviews. The interviewer creates asset groups on the basis of how physical assets, software and hardware interrelate. The physical assets are valued on the replacement value and data assets on the business impact if the data is compromised [INSI03 03]. Data assets and their values are determined by data owners [CRAM02 96]. The valuation step provides the impact component of risk. The data values are determined by discussing the worst case scenarios for each of the security requirements, for instance availability (see section 2.2). Although CRAMM assigns a replacement value to the physical asset and an estimated business value to the data asset, they are grouped together into asset 40


groups. The asset groups are utilised in order to speed up the risk analysis process. Asset models are determined to protect enabling assets, for instance the hardware that enables the software to function. b) Threats - Analysis A threat assessment involves identifying and assessing the level of threat to the assets of a system. The “level of threat” is measured as a likelihood of occurrences. Threats are identified for asset groupings and not individual assets. CRAMM provides lists of types of threats that can be linked to asset groups. Threats are identified through structured questionnaires that are produced by CRAMM [INSI03 03] [LABU 92]. Threats can be assigned a qualitative value on a five-point scale ranging from very low, low, medium, high to very high [INSI01 03]. c) Vulnerability - Analysis Vulnerability is a measure of inherent weakness within the system or network. Threat and vulnerability assessment deliver the likelihood component of risk assessment. Qualitative values are assigned for vulnerability rating. These ratings are low, medium or high. d) Risk Assessment - Analysis A risk assessment involves measuring the level of risk to the system or network. The level of risk is identified from the value of the assets, the level of threat and the extent of the vulnerability. Measures of risk translate directly into measures of security requirements, so that if there is a high risk there is a high requirement for security. The risk value is calculated within the CRAMM software product. During the automated risk estimation, referred to as MOR (Measure of Risk), a value is calculated for each threat to all assets in an asset group, assets that depend on or are depended on and all types of impact that could result from the threat [INSI01 03]. e) Countermeasure - Management Countermeasures are recommended by the CRAMM tools according to the calculated measure of risk. The controls are drawn from a variety of authoritative sources which include the UK’s Security Authorities, BS 7799, and the Information Technology Security Evaluation Criteria and Insight Consultants [INSI03 03]. The

41


proposed controls have to be evaluated against the budget, practical implementation issues and the existing countermeasures [CRAM02 96]. f) Implementation - Management The countermeasures that are recommended in the previous step have to be implemented. These countermeasures are recommended from a database within CRAMM but the software package does not take into consideration the environment in which the organisation finds itself. CRAMM proposes the most effective controls. However, certain controls can mitigate more than one risk and this decision or correlation will have to occur during the implementation process. g) Audit - Management A benefit outlined by CRAMM is auditability of the CRAMM review [CRAM02 96]. At each step of the CRAMM processes review can be conducted on the past processes. CRAMM further allows for the audit on the suitability and status of security controls on an existing system [INSI02 03]. CRAMM is an information security risk management methodology that focuses more on the technical nature, whereas some methodologies focus on the business view of ISRM. One of these methods is the OCTAVE methodology.

3.6.2. OCTAVE OCTAVE [ALBE 01] was developed by the Carnegie Mellon Software Engineering Institute. The OCTAVE (Operational Critical Threat, Asset and Vulnerability Evaluation) method is usually led by a small, interdisciplinary team of an organisation’s personnel and focuses on an organisation’s assets and the risks to those assets. These assets are identified through interviews conducted within the organisation at strategic, tactical and operational level. The essential elements of the OCTAVE approach are embodied in a set of criteria that define the requirements for OCTAVE [ALBE 01]. Organisations can then develop methods that are consistent with the OCTAVE criteria. There can be many methods consistent with these criteria, but there is only one set of OCTAVE criteria. A method was developed that is consistent with the criteria, namely the OCTAVE Method [ALBE 03], which was designed with big organisations in mind.

42


3.6.2.1. OCTAVE Approach OCTAVE has a three-phased approach to the identification of the organisational information security needs. The three phases examine the organisational and technological issues and, through a series of workshops, to provide a comprehensive picture of needs. Figure 3-11 provides a graphical representation of the OCTAVE approach and detailed processes. The three phases are build asset-based threat profile, identify infrastructure vulnerabilities, and develop security strategy and plans. Phase 1:

Build asset-based threat profile

Preparation

Critical assets Security requirements for critical assets Threats to critical assets Current security practices Current organisational vulnerabilities

Phase 2:

Identify infrastructure vulnerabilities

Phase 3:

Develop security strategy and plans Risks to critical assets Risk measures Protection strategy Risk mitigation plans

Key components Current technology vulnerabilities Progressive series of workshops Figure 3-11: OCTAVE methodology

From the diagram it becomes clear that OCTAVE focuses not on the complete ISRM cycle, but only up until the recommendation of countermeasures. OCTAVE does not take the probability component of threat into consideration when determining risk, and uses a qualitative approach to valuation. Through the workshop the analysis team identifies critical assets and focuses the risk analysis activities on those assets. This is referred to as an asset-driven evaluation approach. The participants of the workshops are employees from tactical, strategic and operational levels. Workshops can either be facilitated

43


discussions where employees participate, or workshops where the risk analysis team conducts activities on their own.

3.6.2.2. OCTAVE Processes The OCTAVE methodology consists of three phases with eight processes and eleven activities. The processes and activities are discussed within each phase. These process, activities and phases are illustrated in Figure 3-11. Phase 1: Build Asset-based Threat Profile The goal of the first phase is to construct an organisational view of OCTAVE. This phase consists of four processes that are focused on gathering multiple perspectives about the information security. These perspectives are based on the knowledge of the employees. Different employee levels of the organisation are utilised in this phase. a) Processes 1 to 3: Identify Employee Knowledge During the identification of employee knowledge processes the three key areas that have been identified by OCTAVE are senior management, operational area management and staff knowledge. Each of the employee levels correspond to a process. There are four activities that have to be performed within each of these three processes. They are: •

Identify assets and relative priorities – Information related assets are identified that enable employees to perform their job. From this activity a small number of assets are isolated and will form the focus for the remaining assessment processes.

•

Identify areas of concern – Analysis participants identify areas that concern them on how the most important assets can be threatened. Known threat sources and outcomes of threat prompts assist in developing scenarios.

•

Identify security requirements for most important assets – Certain qualities of an asset are important to the organisation. This activity is geared towards identifying those qualities and translating them into security requirements on which to focus.

44


•

Capture knowledge of current security practices and organisational vulnerabilities – Organisations have to establish their current position of information security before continuing to protect the assets. Best practice codes and security standards provide guidance and benchmarking information.

b) Process 4: Create Threat Profile Process 4 serves two functions. The functions are consolidating the information that was gathered during the preceding processes, and setting the scope for the rest of the processes. Creating threat profiles consists of three primary activities. They are: •

Select critical assets – The team determines which assets will have a large adverse impact on the organisations if the identified security requirements of the assets are violated.

•

Refine security requirements for critical assets – Security requirements were identified in a preceding activity. This activity refines those security requirements for the critical assets as well as prioritises the security requirements.

•

Identify threats to critical assets – Concerns that were noted are used to develop a generic threat profile for the critical assets. The generic threat profile is then scrutinised to identify and correct any threats that have not been taken into account.

Phase 2: Identify Infrastructure Vulnerabilities Phase 2 is also known as the “technology” view. Whereas the first phase focused on the organisational view and constructed an employee or human view of the organisational assets and threats, this view focuses on the organisational computing infrastructure. The goal of this phase is to identify any technological vulnerabilities in the system. This phase focuses on the parts that were identified in the previous phase as critical assets.

45


a) Process 5: Identify Key Components Information from the preceding processes is used to determine how to evaluate the organisation’s computing infrastructure for technological vulnerabilities. During this process key classes of components are identified, for instance servers, laptops and wireless components. These classes assist in selecting specific components, evaluation processes and the extent to which the vulnerabilities will be evaluated. b) Process 6: Evaluate Selected Components This process’s primary goal is data collection and analysis. This goal is achieved by a single activity which is reviewing technology vulnerabilities and summarising the results. Prior to this process’s workshop, tools should be used to determine the technological vulnerabilities of the selected components of the critical assets. At the end of the preliminary technology vulnerability assessment and workshop a summarised vulnerability report with interpretation are produced by the risk analysis team. Phase 3: Develop Security Strategy and Plans Phase 3’s goal is to make sense of the information gathered during the two preceding phases. The “human” and “technological” views are consolidated to provide a holistic view of the organisational risk view. During this phase the risk analysis team develops security strategies. In order to develop security strategies the identified risks have to be analysed first. a) Process 7: Conduct Risk Analysis This process is the starting point of linking the identified critical assets to what is important for the organisation. It is important to look past consequences of an incident and identify the impact an incident will have on the organisation. The activities of process 7 are: •

Identify the impact of threats to the critical assets – This activity links the impact a threat has on an asset with that asset, which is important for an organisation as it brings the components in context with the objectives of the organisation.

46


•

Create risk evaluation criteria – This activity defines the risk tolerance of the organisation. A single set of criteria is created; there is no evaluation criteria set per asset.

•

Evaluate the impact of threats on the critical assets – The previous two activities lead to the evaluation of impacts of threats on the critical assets that will assist in guiding the risk mitigation strategy.

Although OCTAVE does not determine the probability of a threat exercising an asset’s vulnerability, this can be incorporated into this process of the assessment. b) Process 8: Develop Protection Strategy The previous process provides enough information for the team to develop tactical and strategic solutions to manage information security risk within the organisation. This process consists of four activities. •

Review risk information – During this activity the information that was gathered during the preceding process is gathered and reviewed.

•

Create protection strategy – A protection strategy defines the strategy that an organisation is undertaking to manage its internal security. The protection strategy incorporates short- to long-term activities. A catalogue of practices can be used during this activity.

•

Create mitigation plans – The mitigation plans identify how organisations are going to address risks specific to the critical assets. Mitigation plans include actions and countermeasures.

•

Create action list – An action list is the actions that the organisation is going to take in the near future without specific unspecialised activities, for instance policy changes or formal employee training.

Whereas CRAMM focuses on the technical nature of ISRM, OCTAVE focuses on the business nature of ISRM. There are methodologies that strike a balance between the technical and business nature of ISRM. One of these methodologies is the CORAS methodology.

47


3.6.3. CORAS CORAS is a research and technology development project under the Information Society Technologies (IST) Programme which is funded by the European Union [HOUM]. The project ran from January 2001 until July 2003. One of the project deliverables was the CORAS risk assessment platform released in September 2003 [IST 03] [HOUM]. The project included three commercial companies, seven research institutions and one university [IST 03]. This risk assessment platform is based on open-source technologies such as XML data structures, PNG pictures and a JAVA application server.

3.6.3.1. CORAS Approach CORAS is an open source ISRM method that was developed by a consortium of various types of institutions which included universities and commercial organisations. The consortium released a CORAS methodology for risk assessment platform during 2003. The article by Houmb et al. provides good additional information [HOUM]. The CORAS approach to risk management is based on the integration of the viewpoints of various methodologies on the requirements for risk management. The risk management methodology that is followed is that of the AS/NZS 4360. CORAS utilises different methods for risk analysis, semi-formal description methods and computerised tools [ALBE 01]. The methodology was developed to assess the security of critical systems, especially IT security [ALBE 01]. CORAS was developed to include all aspects related to the security of IT systems. These aspects are confidentiality, integrity, availability, non-repudiation, authenticity, accountability and reliability. The method was developed not only to investigate the system security, but also to be aware of the human and external environmental aspects. The CORAS risk management process is based on the AS/NSW 4360:1999 [ASNZ 99] risk management standard and the ISO/IEC 17799-1:2000 Code of Practice for Information Security Management [SABS 00] [SANS 03]. These standards are further supported by the ISO/IEC 13335-1:2001 Guidelines for the Management of IT Security and the IEC 61508:2000 Functional Safety of

48


Electrical/Electronic/Programmable Safety Related Systems [STØL]. The CORAS System Documentation Framework is based on the ISO/IEC 10746 series of Basic Reference Model for Open-Distributed Processing (RM-ODP). The CORAS platform is the computerised implementation of the CORAS Framework [IST 03]. It consists of subrepositories, a reusable element repository that stores reusable elements such as diagrams, tables and documentation, and an assessment repository that stores instantiated and extended reusable elements [IST 03]. CORAS utilises various methods in its subactivities. These methods have different attributes and approaches to risk assessment and through their interoperability in the CORAS platform, they increase the effectiveness of CORAS.

3.6.3.2. CORAS Processes Figure 3-12 (page 50) indicates the processes of the CORAS risk management methodology. As stated in the previous section, the CORAS risk management methodology is based on the AS/NSW 4360 risk management standard. Some small changes have been made to the processes. The first change is the three subprocesses in the risk analysis process. They are determine likelihood, determine consequence and estimate level of risk. The other change is the accept risk stage that was added after the risk evaluation process and before the risk treatment process. Each of the processes are discussed in more detail.

49


Figure 3-12: CORAS risk management processes

Establish the Context The context identification process is made up of four activities [IST 03] [HOUM]. These four activities should be executed in sequential order. They are: a) Identify Areas of Relevance This activity identifies any areas that will provide contextual information that will contribute to the success of the risk assessment and its subsequent management. Five subactivities make up this identification activity: 1. Risk management context – Define the strategies, objectives, scope, parameters and goals of the risk management programme.

50


2. Target of evaluation – Target of evaluation is the description of the system that is the object of the risk assessment. 3. Organisational context - Subactivity that collects information about the organisation and its capabilities, which includes the goals and objectives of the organisation. This subactivity ensures that the risk assessment is conducted within the scope, strategy and goals of the organisation. By establishing the organisational context, the parameters of accepting risk are established. CORAS refers to this as the risk evaluation criteria. 4. SWOT analysis - A SWOT analysis is a rough description of the organisation’s position in relation to the environment. SWOT analysis is the acronym for Strength-Weakness-Opportunity-Threat analysis. The result of a SWOT analysis is to provide a description of the opportunities that the organisation can take advantage of, and the threats that could affect the organisation or system. The other two components provide descriptions of the strengths and weaknesses of the organisation. 5. System description - The system that forms the target of evaluation should be documented at different levels of abstraction. Existing system documentation can be used. However, the documentation has to provide information

that

describes

the

system

boundaries,

stakeholders,

technology, object distribution and other supporting data [IST 03]. b) Identify and Value Assets Before the assets are identified and values assigned to them, value domains which should include scales have to be identified. These value domains can be quantitative or qualitative, with corresponding quantitative range values. After the value domains have been documented, the client and identified stakeholders, supported by the documentation from identification of relevant areas activity, have to identify the target of evaluation assets. The identified assets should be documented in the asset table. Each asset has to be assigned a value from the value domain and this information should be documented along with asset diagrams. c) Identify Policies and Evaluation Criteria The goal of this subactivity is to determine the security policies for relevant stakeholders. These policies are documented in the stakeholder policy table and

51


should include security requirements and objectives. These policies will assist the organisation in establishing evaluation criteria. The evaluation criteria are used in determining whether a risk is acceptable or not. It is important that the evaluation criteria be reflected in the same format as the risk values. d) Approval Once the above processes have been concluded to the satisfaction of the risk assessment leader or team, the results have to be presented to the client or sponsor. Two processes form the approval subactivity. The first step is to conduct a “walk-through” where all stakeholders have the opportunity to provide feedback on the assessment steps taken. Once all relevant stakeholders are satisfied, the client has to provide formal and binding approval by signing an approval registration form. Once the approval has been confirmed, the risk assessment team can commence with the remaining subprocesses. Identify Risks Risk identification in CORAS consists of three activities. The first two can be conducted in any order, and the third should be done after the first two have been completed. Risk identification is approached from two different angles: identifying threats to assets and identifying asset vulnerabilities. The identification of threats and vulnerabilities are usually iterative processes. a) Identify Threats to Assets External and internal threats to the assets of the organisation are determined by employing different methods. Threat identification sessions are scheduled by the risk assessment leader where structured brainstorming sessions are used in determining threats. During these sessions the different methods can be used for different levels of abstraction. b) Identify Vulnerabilities of Assets CORAS recommends that vulnerabilities be identified through questionnaires that are structured into themes [IST 03]. During this activity different aspects have to be considered, for instance judicial, physical and computational characteristics of critical systems.

52


c) Document Unwanted Incidents After the threats and vulnerabilities have been identified, they will be used in determining unwanted incidents. Unwanted incidents are scenarios which can cause the loss of asset value. During this activity the threats and vulnerabilities are combined and further analysis of the threats and vulnerabilities takes place. The results are documented in the unwanted incidents table. Analyse Risks The risk analysis process consists of two activities, which are the consequence and frequency evaluations. Different methods can be used in these two activities and the method selection depends on the results of the risk identification process. a) Consequence Evaluation The goal of this process is to analyse and evaluate the consequences of an unwanted incident. Consequence values are at enterprise level and are measured in loss of asset value. The consequences and corresponding values are recorded in the consequence table in the risk assessment platform. b) Frequency Evaluation Frequencies can be determined by historical data, simulations or subjective options. Other methods that can be employed are data mining, Markov analysis or published insurance data. Frequency descriptions and values are recorded in a frequency table. Evaluate Risks Risk evaluation consists of five activities that should be carried out in sequential order. This process focuses on evaluating the risks by determining the level of risk and prioritising risks. The process’s remaining activities focus on assigning themes to the risks. a) Determine Level of Risk Values are assigned to unwanted incidents according to their consequence and frequency values. The values that can be assigned are determined during the context identification process. Qualitative and quantitative values can be assigned to a risk.

53


b) Prioritise Risks Risks are prioritised according to the pre-specified evaluation criteria and the assigned risk values. During this activity the risk assessment team decides which risks will be accepted or managed according to the evaluation criteria. c) Categorise Risks into Risk Themes Assigning a risk to a risk theme makes the risk treatment more effective and efficient. Risk treatments can be determined for a theme instead of addressing each individual risk. Various characteristics are used as themes; themes can include policies, architecture, potential threats or vulnerabilities. d) Determine Interrelationships among Risk Themes To further facilitate the treatment of risks, relationships between the identified themes are determined. The interrelationships can result in cost-effective risk treatment strategies. e) Prioritise Resulting Risk Themes Once the risks have been assigned to themes, these themes have to be prioritised. Values can be assigned to a theme; these values are determined by the values of the risks grouped within the theme. Treat Risks All the processes and activities lead to the activity of addressing the identified and prioritised risks. Risk treatment within CORAS consists of two activities. a) Identify Treatment Options Five treatment options are considered for the risk themes. They are risk avoidance, transfer, retention, reducing frequency and consequences. Different approaches for each treatment option are available. The SWOT analysis that was performed earlier in the process can be applied for a better treatment fit for the organisation. b) Assess Alternative Treatment Approaches Selecting a treatment option for a risk theme does not necessarily mean it is the best option for the organisation. The treatment options have to be evaluated with respect to costs and benefits. They also have to be evaluated against the evaluation criteria, and should meet the requirements.

54


Report and Monitoring The results of the risk assessment are documented in the risk assessment report. This report is divided into three main parts. The first part provides information about the plan of the assessment. The second part consists of the results obtained from the risk assessment. The third part provides recommendations. These recommendations are the risk treatment recommendations identified as well as recommendations for further assessment. A risk assessment monitor table is used to track issues that were identified as well as document the assessment that is performed. This table also provides a method to indicate specific aspects or activities that require attention or that require specific investigation during the next assessment.

3.7. RESEARCH VALUE ISRM approaches differ but this chapter has shown that applying methodologies can include the other two approaches as supporting components. Figure 3-13 indicates that the three approaches have shared aspects, as discussed in section 3.3. However, the methodology approach is strengthened by harnessing the overlapping aspects of guidelines, standards and methodologies to address ISRM better.

Guidelines

Standards

Guidelines

Methodologies

Standards

Methodologies

Figure 3-13: ISRM approach focus

This approach of “using” guidelines and standards as part of methodologies allows organisations to have a systematic, standardised, directed, structured and process-driven approach to ISRM. Throughout this chapter the different approaches and the options available under each were discussed in detail. These discussions and approaches can be

55


combined according to organisational needs to address information security risks better.

3.8. CONCLUSION ISRM at operational level can be accomplished by three approaches. These approaches are standards, guidelines and methodologies. Each approach addresses ISRM differently. Standards require certain aspects to be adhered to in order to achieve a recommended level. Guidelines provide direction on how to implement ISRM programmes, while methodologies can employ guidelines and standards in a systematic approach to address information security risks. Three ISRM methodologies were discussed. CRAMM focuses more on the technical risks of an information technology system, and the OCTAVE methodology focuses more on identifying a handful of critical assets of business importance and identifying their risks. CORAS can incorporate different methodologies as part of its processes. CORAS focuses on business as well as technical aspects. The primary source of risk information for all three methodologies is questionnaires. The goal of this chapter was to provide an overview of ISRM methodologies. This was achieved by identifying three approaches and discussing them. Each approach had various products or documents which were discussed in more detail. The first objective was achieved by evaluating different ISRM products and documents. From these evaluations three generic approaches were identified. The evaluated material was then assigned to its respective approach and reviewed. The second objective was achieved by reviewing, discussing and evaluating the most prominent documents or products within each approach grouping. It is concluded that although there are different approaches to ISRM, the most appropriate approach is the implementation of ISRM methodologies. Therefore, methodologies are considered to be the focal ISRM approach throughout the dissertation. The approaches that were discussed in this chapter focus on the operational level of an organisation. These operational level approaches are instigated as a result

56


of strategic and tactical level managerial requirements. The next chapter focuses on the need for and the different ISRM approaches to meet the requirements at those levels.

57

C h a p te r 4

RGANISATIONAL GOVERNANCE AND INFORMATION SECURITY

O

4.1. INTRODUCTION In the previous chapter various approaches to managing risks at operational level were discussed. These approaches are implemented as a result of requirements placed on the organisations. Organisations, especially those that have external vested interests, have accountability and responsibility demands placed on them in terms of resources entrusted to them. Management has to demonstrate due diligence. The regulatory environment requires and provides guidance on corporate governance in this regard. At strategic and tactical level IT-specific governance products assist in IT related diligence. Organisations are not always aware of the requirements, specifically those regarding their information assets, that are imposed on them. The goal of this chapter is to determine what is required of strategic and tactical level management, who requires it and how these requirements can be met. In order to achieve this goal there are several objectives that have to be met. The first objective will focus on determining what is required of strategic and tactical level management. The second objective is to determine who places these requirements on management. The final objective will be to determine what options are available to management to meet these requirements. First of all, the managerial level focus is determined for this chapter, after which the structure is guided by the chapter objectives. The requirements and bodies imposing these requirements are discussed first. This is followed by the options available to management to meet the requirements. The next section defines the focus of the chapter in terms of the managerial levels.

58

Organisational Governance and Information Security

4.2. CHAPTER FOCUS The previous chapter focused on the operational managerial level approaches available to an organisation to address ISRM. This chapter investigates the need imposed by external entities on the organisation to have adequate ISRM programmes in place. Figure 4-1 provides a graphical representation of the managerial levels forming the focus of this chapter.

Strategic management

Long term

Tactical management

Medium term

Operational management

Short term

Figure 4-1: Chapter focus

The next section investigates what requirements are imposed on strategic and tactical level management, as well as who requires it.

4.3. STRATEGIC AND TACTICAL LEVEL REQUIREMENTS The strategic and tactical level requirements are predominantly imposed by the regulatory environment. The regulatory environment refers to the governmentcontrolled environment that proposes regulations or controls through statutory means [OXFO 80]. These legal means are either reports or recommendations of committees or laws of a country. The regulatory environment is not specific to a country. Governments across the world have become more aware of diligence in terms of organisational risk management practices than ever before. The laws and recommendations that are referred to in this section come from the United States of America, United Kingdom and South Africa. These laws and recommendations are discussed in the following sections.

59


4.3.1. King II The King Report on Corporate Governance for South Africa 2002 [KING 02] is a corporate governance recommendation report published by the King Committee which was established in 1992. It addresses the management accountability and responsibilities of organisations due to investors’ worries about the excessive concentration of power in the hands of management. The King II Report published in 2002 replaces the King Report published in 1994. As a result of the King II Report, legislation that addresses diverse areas was passed, such as the Labour Relations Act (1995), National Environmental Management Act (1997) and the Employment Equity Act (1998). The areas that are addressed by the King II Report are boards and directors, risk management, internal audit, integrated sustainability reporting, accounting and auditing, and compliance and enforcement. The section that is focused on in this document regarding the King II Report is section 2, Risk Management. The King II Report does not merely consider general and financial risk management, but emphasises information technology and risks associated with it. The emphasis includes risk management, electronic contracting and record retention. Special mention is made of international awareness of good corporate governance due to the borderless world of information technology and the impact of the Internet on international business.

4.3.2. Cadbury The Cadbury Report [CFAC 92] is the associated name of the report by the Committee of the Financial Aspect of Corporate Governance, United Kingdom. The Chairman of the Committee was Adrian Cadbury, from which the abbreviated report name is derived. The Committee recommended corporate governance (behaviour) that focuses on control and reporting functions of the board of an organisation. The report recommends that a board have a formal schedule of matters that will have to include risk management policies. A board should ensure that adequate control systems are in place for the financial management of an organisation. Furthermore, the board is accountable to the

60


shareholders. Information that is provided by the board to the shareholder should be of such a quality that shareholders can execute their responsibilities as owners. Since the majority of financial systems are information technology based, the financial controls should extend to include the IT environment. If the IT environment is at risk it could result in the loss of information integrity (information security, see section 2.2) and this directly impacts on the financial controls of the organisation. The report stipulates board accountability for implementing and maintaining controls to minimise the organisation’s exposure to risk.

4.3.3. Turnbull The Institute of Chartered Accountants in England and Wales released A Guidance for Directors on the Combined Code for Internal Controls [INCA 99], published by the Internal Control Party. The document provides clarity on what is expected of the board of directors of a company according to the Combined Code. The document is referred to as the Turnbull Report, as Nigel Turnbull was the Chairman of the Internal Control Party that issued it. The document addresses maintenance of a sound system of internal control, reviewing the effectiveness of internal controls, the board’s statement of internal control and internal audit. It states that an organisation’s internal control system plays a key role in risk management programmes. The internal control system reduces risk exposure and contributes to the safeguarding of assets. Management is responsible for the internal control system of an organisation. The control system should be selected based on the identification and evaluation of risks. All employees are responsible for internal control as part of their accountability for achieving the organisation’s goals. The control system includes information and communication processes and processes of monitoring the continuing effectiveness of the internal control system. These information and communication processes and systems must be reassessed if objectives and related risks change. The information and communication control systems within an organisation refer primarily to telecommunication and information technology infrastructure. By

61


following the recommendations of the Turnbull Report, the identification and evaluation of IT and information security risks should form part of the financial risk identification and evaluation.

4.3.4. Sarbanes-Oxley The Sarbanes-Oxley Act of 2002 [SOX 02] was enacted by the Congress of the United States of America to protect investors by improving the accuracy and reliability of corporate disclosure. Financial reporting and controls that ensure accurate disclosure are the focus of the Act, which makes the IT infrastructure an inherent focus as the majority of financial data and information is enabled by IT [ITGO 03]. The Act is divided into eleven titles with each title consisting of several sections. The Act addresses diverse aspects such as auditor independence, corporate responsibility, enhanced financial disclosure, analyst conflicts of interest and studies of reports. Although the Sarbanes-Oxley Act addresses the responsibility and accountability of organisations as a whole, two sections have a specific impact on the IT infrastructure [ITGO 03]. These sections are 302 and 404. Section 302: Corporate Responsibility for Financial Reports A financial statement signing officer is responsible for establishing and maintaining internal controls, has evaluated the effectiveness of the internal controls and presents conclusions adequately in the report. Although these controls refer to financial controls, they include the enabling technology. A financial statement signing officer is responsible for the information security controls as well. Section 404: Management Assessment of Internal Controls Section 404 requires that rules be prescribed by a commission requiring an annual report that will state the responsibility of management for establishing an adequate internal control structure. Furthermore, the report should contain an assessment of the effectiveness of the internal controls and processes for financial reporting. Since financial reporting is dependent on information technology, for instance, statement consolidation and e-transactions, the internal controls include information technology.

62


4.3.5. Electronic Communications and Transactions Act The Electronic Communications and Transactions Act, Act 25 of 2002 [ECT 02] was enacted by the Parliament of the Republic of South Africa to facilitate and regulate electronic communication and transactions. The Act addresses different areas which include facilitating electronic transactions, e-government services, cryptography providers, authentication service providers, domain name authority and administration, and cyber crime. The following are areas that are particularly applicable to information security: Consumer Protection Organisations have to ensure that transactions conducted by them are sufficiently secure. The organisation is liable for any damages suffered by the customer as a result of failing to secure the transactions. Protection of Personal Information Information that is collected by organisations may not be used other than as legally indicated to do so by the information owner, the client. Any information that is stored will have to be linked to its purpose of collection and stored for a period of a year after collection. Protection of Critical Databases Certain information that is deemed critical by the Minister of Communications has to be registered at a designator of the Minister. This critical information that is stored in a database is collectively referred to as critical databases. Audits can be requested from time to time on the critical databases that have been registered at the registration designator.

4.3.6. Promotion of Access to Information Act The Promotion of Access to Information Act [PAIA 00] or PROATIA addresses the right of access to information as outlined in the Constitution of South Africa. The Act is applicable to any information held by the state or any other person, which includes organisations. The Act addresses access to records of public bodies and private bodies. Subsections each address the right of access, publication and availability of

63


certain records, manner of access, grounds for refusal of access to records, and third party notification and intervention. Management is responsible for developing a manual on the procedures on how to access information. This manual has to be updated on a regular basis. Different sections of the Act have particular impact on information security. Some of these areas are: Mandatory protection of privacy of third party who is a natural person The information officer of an organisation must refuse access to information of an individual, if the disclosure of this information would be considered an unreasonable disclosure. This includes the information of a deceased individual. Mandatory protection of commercial information at third party Organisations must refuse access to information if the information concerns trade secrets of a third party such as financial, commercial, scientific or technical information. This section discussed the various external influences on an organisation’s ISRM requirements. The next section discusses the instruments organisations can implement at strategic and tactical level to address these requirements.

4.4. TOP LEVEL ISRM INSTRUMENTS The previous section addressed the legal requirements, accountability and responsibility for information security within the organisation. Management has to have guidance on addressing issues such as information security for which they are responsible. This section focuses on the different frameworks, guidelines and best practice products for tactical and strategic management. Top level ISRM instruments refer to any tools, be they books, software or guidelines that assist top level management in instituting ISRM at strategic and tactical managerial level. Three instruments are discussed in the next sections. They are ITIL, CobiT and the Basel II Accord.

64


4.4.1. ITIL ITIL is an IT service related set of books that focus on aligning the IT infrastructure with the service delivery needs of the organisation. ITIL is an acronym for Information Technology Infrastructure Library, which is owned and developed by the Office of Government Commerce (OGC) (United Kingdom) [ITIL04 02]. The OGC was amalgamated with the Central Computing and Telecommunication Agency (CCTA), which was responsible for collating and publishing industry best practices. The CCTA was also responsible for the CRAMM risk assessment methodology (see section 3.6.1).

4.4.1.1. ITIL Volumes ITIL consists of seven books that address specific functions within IT service delivery. The key elements of IT service management are addressed by two volumes [ITIL04 02], Service Support [ITIL05 02] and Service Delivery [ITIL06 02]. Figure 4-2 provides a graphical representation of the relationship between ITIL volumes. The diagram displays the “fit” of ITIL’s books between the business (left) and the technology (right). The books/volumes will be discussed from the top left to the bottom right.

y g o l o n h c e T

s s e n i s u B e h T

e h T

Figure 4-2: Relationships between ITIL volumes

Each of the ITIL volumes illustrated in Figure 4-2 is discussed below.

65


Planning to Implement Service Management Key issues which have to be taken into account when wanting to implement IT service management are discussed in this volume. It also addresses the benefits organisations can expect when implementing service management. The Business Perspective The Business Perspective volume focuses on delivering quality IT services. This is accomplished by providing guidance on the planning, delivering and management of issues such as business relationship management, partnerships and outsourcing, and the exploitation of information communication and technology [ITIL04 02] [ITIL07 02]. Service Delivery Service Delivery is concerned with evaluating and understanding the business and customer needs and designing an IT infrastructure to deliver the IT services [ITIL04 02]. Aspects that are addressed are configuration management, financial management for IT service, capacity management, IT service continuity management and availability management [ITIL04 02] [ITIL06 02]. Service Support This volume focuses on ensuring that the user has sufficient services to support the business functions. Areas that are addressed are service desk, incident management, problem management, change and release management [ITIL05 02]. ICT Infrastructure Management ICT is the acronym for information communication and technology. This is an area that is addressed superficially by organisations due to the rapidly evolving nature of the area [ITIL02 02]. This volume deals with ICT aspects starting with the identification of the business need, tender process, installation, deployment and ongoing support and maintenance [ITIL02 02] [ITIL04 02]. Security Management This volume is the latest addition to ITIL. It addresses the managing of security within the IT service management principle. It focuses on the process of implementing security requirements identified in the IT service level agreement rather than the business issues of security policy [ITIL04 02].

66


Application Management Application Management deals with managing applications from the initial business need, through the development life cycle up until retirement of the application [ITIL04 02]. Areas addressed in this volume are managing the business value, organising roles and function, control methods and techniques [ITIL03 02].

4.4.1.2. ITIL and Information Security Although ITIL is focused on IT service management, there is an inherent security focus of this subject area. Security requirements are the assurance that information is available and confidential and that integrity is maintained according to the business need (see section 2.2). Throughout the different volumes of ITIL there are aspects within each of the service management areas that directly address information security and to a great extent ISRM. Some of the prominent information security focus areas within ITIL are: Availability Management Availability was defined as one of the security requirements in Chapter 2 (see section 2.2.3). A whole section within the Service Delivery volume is dedicated to availability related aspects. These include management tools, cost of availability and managing availability. IT Service Continuity Management Continuity management is the business processes focused on recovering facilities which include physical infrastructure, data and processes within a specified time frame. Business continuity management can be considered a subset of ISRM as the business processes and technology have become so intertwined [ITIL06 02]. If the IT service levels of an organisation cannot be reinstated within the period, business processes will not or cannot function efficiently or effectively. In some instances all data can be lost. Pro-Active Problem Management According to ITIL, the proactive management of problems is identifying any before an incident occurs. The processes involved in proactive problem management are trend analysis and targeting preventative action. These processes are geared 67


towards identifying problems from analysing trends and focusing attention on areas that are identified as “hot spots” for problems [ITIL05 02]. Incident Management ITIL defines an incident as any event which is not part of the standard operation of a service and which causes or may cause an interruption to or a reduction in the quality of that service [ITIL05 02]. This definition has a striking resemblance to a definition of risk management (see Chapter 2). Incident management can be considered as part of the controlling (2.5.3) and monitoring (2.5.4) phases of an ISRM programme. ITIL is focused on aligning the IT processes and resources of the organisation with the goals and objectives of the organisation. This is a service level approach. However, there are instruments that focus on minimising the risks of information technology through implementing adequate controls. One of these instruments is discussed in the next section.

4.4.2. CobiT CobiT [COBI01 00] stands for Control Objectives for Information Technology and is released by the Information Systems Audit and Control Association. The most recent edition (three) was released in July 2000 and consists of various documents that address separate functions, for instance, auditing and implementation tool set. The underpinning concept of the CobiT framework is that control in IT is approached by looking at information that is needed to support the business objectives or requirements [COBI01 00]. This concept is further supported by looking at information as being the result of the combined application of IT related resources that need to be managed by IT processes [COBI01 00].

4.4.2.1. CobiT Structure CobiT consists of 34 IT processes, which are used to manage IT resources, and they are grouped into four domains (planning and organisation, acquisition and implementation, delivery and support, and monitoring). Each process within the framework specifies the business requirements for information as well as the

68


required IT resources. These three dimensions of CobiT are illustrated in Figure 4-3.

Information Criteria ry y rity u alit iducia c u Q Se F

Domains Processes Activities IT

s ce r u o es R

Figure 4-3: CobiT structure

The three dimensions of CobiT illustrated in Figure 4-3 are discussed. a) Business Requirements/Information Criteria The framework expresses business requirements in terms of information criteria [COBI03 00]. Information criteria within the framework are effectiveness, efficiency, confidentiality (2.2.1), integrity (2.2.2), availability (2.2.3), compliance and reliability. Each of these information criteria is assigned a primary or secondary rating for each of the 34 processes. Table 4-1 shows how the information criteria are grouped in quality, fiduciary and security business requirements. Table 4-1: CobiT information criteria grouping Quality Quality Cost Delivery

Fiduciary Effectiveness and Efficiency Compliance Reliability

Security Confidentiality Integrity Availability

Organisations have to identify a degree of importance for each of the information criteria based on their business needs and environment. This will provide management with an expression of their risk position.

69


b) IT Resources The IT resources, which are indicated for each process, identify the resources that are specifically managed by the processes and not only those that are involved in the process. Five IT resources are defined within the CobiT framework. They are data, application systems, technology, facilities and people. c) IT Processes The IT processes form the basic structure of CobiT. Within the four domains of planning and organisation, acquisition and implementation, delivery and support, and monitoring, there are various processes which total 34. Within each process there are activities that can be executed.

4.4.2.2. Management Guidelines Specific Aspects Management Guidelines is the latest addition to the CobiT product line. This new product introduces four aspects that assist management in better gauging the success of information technology and ISRM at the higher managerial levels. The four aspects are key goal indicators (KGIs), key performance indicators (KPIs), maturity models and critical success factors (CSFs). a) Key Goal Indicators Key goal indicators provide organisations with measures which will indicate whether a process has achieved its set goals [COBI03 00]. It is a measure of “what” has to be accomplished. These indicators should not be vague but be quantitatively measurable. b) Key Performance Indicators Key performance indicators or KPIs define measures which provide information on how well the IT processes are performing [COBI03 00]. Key performance indicators are focused on “how”; they are process driven. c) Maturity Models Maturity models within CobiT provide a method of scoring which enables organisations to grade themselves. This grading process is based on a six-point scale (0 to 5) [COBI03 00]. Maturity models also assist management in strategic decision-making.

70


d) Critical Success Factors Critical success factors or CSFs outline the most important issues or actions for management to achieve control over their IT processes [COBI03 00]. These actions or activities are executed at different levels of the organisation and follow a Plan-Do-Control-Correct cycle. This section briefly discussed the latest product of CobiT. There are, however, more CobiT products. The next section discusses all of the CobiT products.

4.4.2.3. CobiT Products CobiT is a set of products that assist management in determining the level of risks they are willing to accept, compared to the cost. These products also provide a method that enables management to benchmark the organisation’s processes by means of maturity models. Figure 4-4 provides a graphical representation of how the different products relate to each other. The layout of the products provides a telescopic breakdown of the control objectives. The Executive Summary provides high level information on CobiT, while the Audit Guidelines and Detailed Control Objectives provide more implementation type data, which is more detailed.

Figure 4-4: CobiT products

Executive Summary The Executive Summary provides an executive overview that explains the key concepts of CobiT. The key concepts that are outlined are the history and background of CobiT, a high level overview of the CobiT framework, target audience layout and the CobiT family of products.

71


Implementation Tool Set The Implementation Tool Set can be used to introduce CobiT into organisations. It consists of management awareness and IT control diagnostics, implementation guide, frequently asked questions, case studies and slide presentations. Framework The CobiT Framework [COBI01 00] explains how IT processes can be used to deliver information to the business process in order to meet its objectives. It consists of 34 high level processes that are grouped into four domains. The domains are planning and organisation, acquisition and implementation, delivery and support, and monitoring. The framework starts by looking at the business requirements, then evaluating which IT resources are to be used, affected or targeted and aligning them with IT processes to meet the business requirements. CobiT identifies seven business requirements and five IT resources. Management Guidelines The Management Guidelines will assist in answering the immediate concerns of those that have a stake in the organisation. The Management Guidelines consist of KPIs, CSFs, KGIs and maturity models which provide management measures to assess their organisation against the 34 CobiT IT processes [COBI03 00] (see section 4.4.2.2). These Management Guidelines are consistent and build upon the CobiT Framework, Control Objectives and Audit Guidelines. Maturity models are unique to the Management Guidelines product. Maturity models enable management to position themselves on a scale as well as target where they want to be. With the organisation’s current position and goals plotted, management is aware of the work involved in attaining their goal. Detailed Control Objectives The Detailed Control Objectives provide the understanding that is required to clearly define the policies and good practice for IT controls. They provide 318 specific, detailed control objectives for the 34 high level controls outlined in the CobiT Framework [COBI04 00]. The objectives outline specific results or purposes to be achieved by implementing the specific controls. This product is targeted at the management and staff of IT,

72


audit and business process owners. It allows for the translating of the process concepts that were outlined in the Framework to be implemented through specific controls. Audit Guidelines The CobiT Audit Guidelines [COBI05 00] provide a structure for auditing and assessing the controls that fit within the CobiT scheme. The audit guidelines are generic and high level to fit with the audit structures of individual organisations. The controls are audited in a generally accepted structure of identification and documentation, evaluation, compliance testing and substantive testing. Along with the audit structure outlined above, the Audit Guidelines also address the risk analysis as an alternative approach to the audit approach. For each process the high level control objectives, guidance on obtaining and understanding the process, evaluating procedure and compliance assessment procedures are listed. CobiT addresses the implementation of controls in various processes and domains of the IT function of an organisation. There are, however, certain high level instruments that are proposed by industry-specific bodies. The next section discusses one of these instruments.

4.4.3. BASEL II Accord The Basel Accord outlines the requirements placed on banks in terms of capital reserve requirements, as well as results of forums and committees that focus on the technological and risk management side of banking [BASE 01] [BASE 03]. Documents issued by the Bank of International Settlement (BIS), which issues all documents related to the Basel II Accord, are created by various committees. These committees have their own governing rules that are in line with the operations and governance of the BIS. According to the Basel Committee on Banking Supervision [BASE 03], the board of directors and senior management are responsible for developing the organisation’s risk management strategy. This includes the steps taken to make informed strategic decisions regarding the organisation’s e-strategies.

73


Along with strategic planning, management is responsible for the risks associated with outsourcing relationships, third-party dependencies of e-services, security processes and the protection of data against internal and external threat sources. Although management is responsible for risk management within banks, security controls related to electronic banking require special management attention [BASE 03]. Management has to implement security controls that enable audit trails, confidentiality of key banking information, appropriate authentication and physical access control, to name but a few. The Basel Committee on Banking Supervision releases documents that relate to various aspects associated with banking. These documents compile best practice for the banking industry and some documents make regulations that banks have to comply with, for instance capital reserves. Although various documents are released, two documents which have to be highlighted are Risk Management Principles for Electronic Banking, and The Implications of Electronic Trading in Financial Markets [BASE1 01]. Risk Management Principles for Electronic Banking The document entitled Risk Management Principles for Electronic Banking [BASE 01] addresses the risks that can realise from the ubiquitous and global nature of the open electronic networks. Pairing this concern with the increased dependency of banks on third parties to deliver the necessary information technology increases banks’ operational risks as a result of information security risks. The Basel Committee on Banking Supervision has identified 14 risk management principles for electronic banking to help banks to expand their existing risk management programmes to cover the electronic banking strategies. These 14 principles are only guidelines and not best practice recommendations. The 14 principles include the three information security requirements of availability, integrity and confidentiality. The Implications of Electronic Trading in Financial Markets The Basel Committee on the Global Financial System (CGFS) organised a working group to investigate the possible implications of electronic trading platforms on global financial markets.

74


Although several findings have been made, only some are outlined. From the investigations it was concluded that the use of electronic trading is increasing rapidly. Markets are currently more confident to trade electronically if the transactions involve a relatively small amount. However, after initial transactions the trading amounts are increasing. There are concerns regarding these electronic trading systems. Concerns focus on the adequate controls for availability (see section 2.2). This directly addresses the information security of the system and the need for adequate ISRM. The Basel II Accord Committee’s documents, reports and recommendations provide an indication that although there are generic high level ISRM tools that organisations can implement, certain industries have bodies that consolidate them for application in that specific industry.

4.5. RESEARCH VALUE This chapter provides a high-level view of the external forces that require information security risks to be adequately managed within organisations. Along with this high-level view the accountability and responsibility of risk management in organisations are defined. ISRM is becoming integrated into various instruments at this level. The high-level instruments address ISRM from different views.

4.6. CONCLUSION An organisation’s strategic and tactical level management are responsible and accountable for ISRM programmes at higher levels in the organisation. This accountability and responsibility are enforced by the regulatory environment. ISRM is required by the regulatory environment of various countries including South Africa, the United Kingdom and the United States of America. Various instruments are at the disposal of strategic and tactical level management. These instruments range from IT service level products (ITIL), IT governance products (CobiT) and industry-specific recommendations (Basel II). The goal of this chapter was to determine what is required from top level management, who requires it and how these requirements can be met. This goal was achieved by investigating specifically the regulatory environment. The

75


regulatory environment can have a holistic impact on the organisation in the case of non-compliance with requirements, for instance law suits. At the highest level governments require organisations to have ISRM programmes in place. It was determined that various types of instruments are available to top level management. The objectives that were set in order to achieve the chapter’s goal were met. The first and second objectives were met by determining the highest authority requiring ISRM to be employed, which is governments. These requirements are put in place by regulations, laws and recommendations. Several instruments were evaluated that enable top level management to employ ISRM programmes, and this achieved the final objective. It is clear that strategic and tactical level management are responsible for implementing and maintaining ISRM programmes in their organisations. Strategic and tactical level management have to translate this accountability and responsibility into processes and action in the organisation. Organisations are logically structured to achieve the organisational goals. The next chapter investigates the types of organisational structures and how these structures impact on ISRM programmes.

76

C h a p te r 5

RGANISATIONAL STRUCTURES AND

O

IS R M

5.1. INTRODUCTION The previous chapter indicated that ISRM can be implemented at operational level (Chapter 3) as well as at the higher managerial levels (Chapter 4). ISRM approaches and instruments are implemented in an organisation through its structures. However, each organisation has a different authoritative structure which is geared towards effectively and efficiently achieving the organisational goals. The organisational structure is not determined by the security goals, but by the organisational goals. The goal of this chapter is to establish the role of information technology within the different organisational structures; by accomplishing this, the role or place of ISRM will be determined. Information technology and its subcomponent of information security fulfil a certain function in an organisation. The first objective is to determine what this function is. The second objective is to identify several organisational structures and the role of IT in these structures. The third objective is to determine how these organisational structures impact on ISRM. The structure of the chapter is guided by the goal and objectives. Firstly, the role or function of information technology is determined, after which generic organisational structures are identified and discussed. These structures are then evaluated to determine their relationship towards risk management processes. The next section discusses the different functions in an organisation in order to determine what function information technology fulfils.

77

Organisational Structures and ISRM

5.2. ORGANISATIONAL FUNCTIONS Organisations exist for various reasons. These reasons can include providing better products at lower prices or uplifting the state of the community. In essence the majority of organisations exist to provide a profit for the owners and investors [GALB 02]. The purpose is defined in the organisation’s mission and vision statements and supported by the goal statements. The goals of the organisation are achieved through two functions. These functions are core business functions and supporting functions. These functions are illustrated in Figure 5-1. The mission, vision and goals are achieved through the core business functions, which in turn are enabled by the organisational supporting functions.

Figure 5-1: Functions of an organisation

Both are evaluated to determine which function IT fulfils.

5.2.1. Core Business Functions Core business functions or processes are activities that guide the overall directions of firms [HEJS 99] and focus on external customers. They are processes that cut across an organisation and represent the flow and transformation of information, decisions and materials or resources which are unique to an organisation [LOMP 00] in order to serve customers [AUJK 95]. Common core business functions can include order fulfilment, purchasing and servicing. To define the core business processes strategic management has to ask [AUJK 95] themselves several questions. The answers to these questions should describe who the customers are, how to add value, what products or services the

78


customers expect, and what steps have to be taken in order to meet the expectations. The above questions should be answered by the organisation’s mission, vision or goal statement [HEJS 99] [LOMP 00] [GALB 02]. These questions are generally answered by top management, which should subscribe to best practice, corporate governance and IT governance recommendations (see Chapter 4). These core business functions cannot deliver on the objective without specific functions that support them, for instance human resource management.

5.2.2. Supporting Business Functions Supporting business functions focus on internal customers. These functions are necessary to keep the organisation functioning but are not directly focused on meeting customer needs [AUJK 95] [GALB 02]. Information technology does not directly focus on customer needs but is required to expedite the customer service, procurement function, marketing and other business functions. Therefore, information technology is classified as a supporting function. Purely online organisations that only use electronic communication media depend heavily on the information technology infrastructure, but the technology infrastructure supports the actual service as an enabler to deliver the core product or service. In order to clarify the above statement, consider an organisation that primarily sells computers over the Internet. Although it uses an electronic communication medium to sell the goods (computers), it supports the primary function of selling products. A process which forms part of the core functions, for instance procurement, is supported by information technology. Various organisations can depend heavily on their technology infrastructure, for instance an ASP (application service provider) for enterprise resource planning. The fact that the organisation depends on the technology to deliver their product or service does not negate the fact that IT does not provide the service or product, but serves as a conduit. There is, however, a greater operational risk involved by depending solely on a single delivery channel.

79


Figure 5-2 indicates how the core business functions, supporting business functions and organisational structures interrelate. Determines Planning Level

Mission / Vision / Goals Drives Core Business Function 1

Resource - Planning Convergence Level

Core Business Function 2

Core Business Function 3

Organization Structure

Enables Supporting Business Functions

Delivers Organisational Resources

Drives

Human Resources

Information Technology

Delivers Inventory

Finance

Organises Figure 5-2: How the functions interrelate

The planning (strategic) level is responsible for the mission, vision and goals of the organisation. This drives the core business functions that are managed by the resource – planning convergence (tactical) level. The organisational (operational) level delivers on the supporting and core functions. All these functions are enabled by the organisational structure that is determined by the planning level’s goals, mission and vision. Organisations have various resources at their disposal. These resources must meet the requirements of the supporting functions, for instance the financial supporting function will require computers to enable them to record shipment related information. Therefore it requires financial knowledge (intangible resource) and computers (tangible IT resource). There are various supporting business functions that are present in different industries. Four of the most common supporting functions that are present in most industries are discussed in order to determine the relationship of the supporting business functions to information technology.

80


5.2.2.1. Financial The financial function of an organisation is a well established supporting business function with developed best practices [PWC 00] [SAIC 02]. These principles are required to be adhered to by law [KING 02]. Finance is a supporting function that impacts and is impacted by all business functions. A requirement of financial reporting is the reasonable representation of the financial position and performance of an organisation [SAIC 02]. This therefore requires the integrity of the financial information. Financial information should also be available when required and kept confidential to ensure competitive advantage [BASE 01]. The financial statements and the majority of accounting processes are computer based. ISRM directly addresses the confidentiality, availability and integrity of information in an IT environment. Therefore information technology risk management directly impacts the availability, integrity and confidentiality of financial statements.

5.2.2.2. Information Technology The Basel Committee on electronic banking [BASE 01] noted that the inherent characteristics of IT (speed, innovation, integration and globalisation) do not create new risks but modify the more traditional risks. In particular, the strategic, reputation, operation and legal risks are affected and thereby influence the overall risk profile of banking. This finding by the Basel Committee highlights the fact that an organisation of any kind is affected by information technology. Although information technology does not always introduce risk, it affects the organisation’s risk in another form, for instance an archiving organisation that had to mitigate fire and physical theft risk but now has to contend with integrity, confidentiality and availability on tangible and intangible threats in case of digital archiving and data warehousing. Although modern organisations use information technology extensively in most business functions, not all organisations depend equally on their information technology infrastructure.

81


Technology Dependence As stated, information technology is a supporting function alongside other supporting functions, but not all organisations are evenly dependent on technology. To illustrate three different types of organisations will be investigated. a) Highly Dependent An organisation that utilises an ASP which delivers the organisation’s online business-to-consumer, business-to-business and enterprise resource planning system (ERP) is highly dependent on the information technology infrastructure. This dependency on IT could cause the organisation to lose huge amounts of money, trust of customers and even result in bankruptcy if the infrastructure falters. b) Dependent The second organisation utilises information technology as a cost-effective communication medium with email, voice over network (voice over IP) and Internet conferencing for geographically disbursed offices and employees. Information in the organisation is captured from hard copies and stored on servers that can be accessed over a LAN or through dial-up accounts. The organisation is dependent on IT but can implement other methods or contingency plans. c) Facilitating An example of the third type of organisation is a government department where the primary information capturing method is paper-based and computer systems are utilised to confirm archived records or update information on a weekly basis. Information technology serves a facilitating role.

5.2.2.3. Human Resources Human resources refer to the management of the human assets within an organisation and include human resource planning. Human resources planning entails forecasting the organisation’s human resource needs and developing the steps to be taken to meet those requirements [HEJS 99]. Within human resources there are various risks. These risks can include loss of critical knowledge due to a key employee leaving, the loss in productivity or ineffective communication within the organisation [PWC 00]. These risks can be mitigated to an extent by information technology resources. For instance, critical 82


information can be stored in a central repository and productivity can be increased through data mining. Human resources are referenced by the various IT risk management methods and frameworks mentioned in Chapter 1. At the strategic level method [COBI01 00] people are referred to as a required resource for a control to be implemented. At tactical and operational level [ALBE 01] people are proactively addressed in security methods as they are fingered as the ultimate culprits of lacking security. People have to be educated in security and this usually falls under the human resources mandate. People constitute two of the threat sources, malevolent and accidental threats.

5.2.2.4. Purchasing/procurement The terms ‘purchasing’ and ‘procurement’ are used interchangeably. In this document purchasing refers to standardised acquisition of inventory, stationery or any other product or service that is acquired on a regular basis. Procurement refers to any irregular acquisitions such as retooling of a factory, upgrading or purchasing of computer systems in a supporting capacity. Purchasing as a supporting function can utilise computer-aided material resource planning and enterprise resource planning software that assists the organisation in managing inventory and resources more efficiently. These computer-based systems require that the information be accurate, available and, to a certain extent, confidential. Procurement is a business activity that is addressed by information security risk management [CRAM01 96] [ALBE 01] and IT governance [COBI01 00]. At governance level the organisation addresses the relevance of the technology to be acquired in relation to the goals of the organisation. At tactical level the procurement risks are addressed by the ISRM methods, for instance the logical access control of third-party support and installation crews. The core business functions and support function of an organisation discussed in this section have to be managed, grouped or coordinated so that all employees know what their functions are. The employees can be grouped in different ways; these groupings and how they relate are known as organisational structures,

83


which are governed by the goals of the organisation [GALB 02]. The next section discusses the various organisational structures that can be implemented.

5.3. ORGANISATIONAL STRUCTURES An organisational structure is a formal system of working relationships that both separates and integrates task and ultimately clarifies who should do what and addresses how the organisational efforts should be meshed [HEJS 99] [GALB 02]. It also determines the placement of power and authority within the organisations [GALB 02]. All structures have weaknesses [REW 01], so it is necessary to consider various aspects that can affect the structure [GALB 02] in order to minimise the weaknesses. These aspects are: •

Specialisation – The type and number of specialists to be used in performing the work. For instance, a programmer is necessary for a software development project.

•

Shape – The shape of the organisation design will depend on the number of people at each hierarchical level. The more people per grouping, the fewer the levels, which leads to a flatter organisational structure. The number of people per grouping is also referred to as span of control [GALB 02] [HEJS 99].

•

Distribution of power – Authority is the power to influence the actions of the employees [GALB 02] [HEJS 99]. The distribution of power refers to two concepts: ♦ Centralised – The concentration of decision-making at the top of an organisation or department [HEJS 99]. ♦ Decentralised – A high degree of delegated decision-making throughout an organisation or department [HEJS 99]. The decentralised distribution of power delegates the responsibility of security, which is in direct contrast to the recommended corporate and IT governance practices [COBI01 00] [KING 02].

84


•

Departmentalisation – Refers to the choice of departments to integrate the specialised work and form a hierarchical department.

The core and supporting functions do not determine the organisational structure, nor can they be represented by the organisational structure. The structure is only used to manage the different groupings of responsibilities. For instance, a human resource function in a software development company is not subordinate to the programming function. The human resources function/department assigns the human assets to achieve the core business function of delivering a software product. Single organisational structures are the focus of this chapter, not affiliated organisational structures. Single organisational structures refer to a single strategic management unit in the organisation. Cognisance has be taken of the fact that organisational structures can be split at strategic level but still form a single organisation. These types of organisational units (affiliated units) are referred to as SBUs or strategic business units. Within each of the SBUs or within a single organisation, there can be various structures. These structures organise functions into departments depending on the structure needs. Strategic business units and departmentalisation are discussed next.

5.3.1. Strategic Business Units A strategic business unit (SBU) is a division or a subsidiary of a firm that provides a distinct product or service and often has its own mission and goals [HEJS 99]. It can be summarised as a “mini-organisation” [THOG 97]. Within each of these business units a departmentalisation structure can be applied as it would be in a normal organisation with core business functions and supporting business functions. SBUs provide greater control over processes and implementation of processes, due to the lack of high-level bureaucracy [HEJS 99].

85


Figure 5-3: Strategic business units

Figure 5-3 highlights how the organisational structures have evolved from a multilayered hierarchical type of organisation with a relatively low span of control and numerous management levels in the 1980s to a relatively flatter organisation with more span of control [GALB 02] [HEJS 99]. These structures are evolving into more decentralised SBUs where authority and responsibility are distributed [HEJS 99]. The decentralisation of organisations at strategic level increases the permutations of risks as there are different systems, processes and structures within an organisational group. The increased combinations of risks make it more difficult to implement a coherent ISRM strategy. Since organisations can categorise their focus areas into supporting and core business functions, a structure within the organisation is required to delegate authority, assign responsibilities and ensure efficient management of resources. These structures can exist in an SBU or throughout a single organisation and are commonly referred to as departmentalisation.

5.3.2. Departmentalisation Departmentalisation is the process of subdividing work into tasks, and assigning employees and resources to focused groups within the organisation [HEJS 99]. These departments generally form hierarchies [GALB 02].

86


Hierarchical structures are natural to humans due to the leader-follower type of structure. Although they have been proven as an effective tool to get things done, they have been subject to considerable criticism and intense debate [AUJK 95] [GALB 02] [THOG 97]. The hierarchical structure, although flawed, will still be around for some time, albeit in a flatter form [GALB 02]. It is used more sparingly and in conjunction with other structures. The most common organisational structures will be discussed briefly: •

Functional departmentalisation

•

Geographic departmentalisation

•

Product departmentalisation

•

Customer departmentalisation

•

Project departmentalisation

•

Matrix departmentalisation

a) Functional Departmentalisation Functional departmentalisation is the grouping of employees according to their areas of expertise and the resources they draw on to perform a common set of tasks [HEJS 99] [LOMP 00]. Staff are grouped and located by speciality into functional departments each headed by a functional manager [LOMP 00] or a company director. This type is the most widely used and accepted form of departmentalisation [MCSL 94]. An example of this type of departmentalisation is a university [LOMP 00] where each department focuses on a specific educational area, for instance business management or economics. Figure 5-4 provides a graphical representation of functional departmentalisation.

87


CEO Finance Marketing

Human Resources Information Technology

Research and Development

Information Security Figure 5-4: Functional departmentalisation

In a functionally departmentalised organisational structure the information technology department is a vertical functional area. The department has a single manager who coordinates all the IT employees. Within the department a subfunctional structure can be implemented to address departmental areas, for instance software (operating system, applications) and hardware (upgrades, networking, servers). b) Geographic Departmentalisation Place or geographic departmentalisation is the grouping of all functions for a geographic area at one location under one manager [HEJS 99]. This type of departmentalisation was adopted by organisations that expanded their offerings across territories [GALB 02]. An industry in which this type of departmentalisation is efficient is in the mineral excavation industry where the organisation has to be situated close to the source, for instance gold or timber.

Figure 5-5: Geographic departmentalisation

88


The geographic departmentalisation is graphically represented in Figure 5-5. Due to the distributed nature of the organisational structure an information technology department can be situated at the distributed offices and as a centralised activity. The reasons for distributing the IT function to the geographical areas are to facilitate quicker response time for support as well as to overcome region-specific challenges, for instance lack of a telecommunication infrastructure. The centralised IT function can coordinate strategic level requests, for instance consolidation of digital information from regional offices, as well serve the supporting functions, for instance the centralised procurement function. c) Product Departmentalisation Product departmentalisation is the division of an organisation into self-contained units, each capable of designing, producing and marketing its own goods and/or services [HEJS 99]. See Figure 5-6 for a graphical representation. Product departmentalisation can be superseded by a functional structure [GALB 02].

Figure 5-6: Product departmentalisation

The IT function within product departmentalisation can be centralised to serve the supporting business functions and product departments, or it can be decentralised in order to be tailored to suit each product department’s individual requirements. For instance, the medical instruments product department would require different specialised IT skills than those required in the industrial products department.

89


d) Customer Departmentalisation Customer departmentalisation is the organising or grouping around the type of customer needs [HEJS 99]. Figure 5-7 illustrates an example of customer departmentalisation.

Figure 5-7: Customer departmentalisation

An example of an organisation that would benefit from such a structure is the banking industry [GALB 02]. As indicated in the above figure, a central information technology function will manage the overall account maintenance, while within each customer-orientated department the information technology and support function will be tailored to the customer needs. For instance, higher income clients might require Internet and telephone banking, while retail customers require pointof-sale systems to interact with the bank’s system. e) Project Departmentalisation A project can be defined as a temporary endeavour undertaken to accomplish a unique purpose [SCHA 02]. Projects normally involve several people performing interrelated activities, and the main sponsor for the projects is often interested in the effective use of resources to complete the project in an efficient and timely manner [SCHA 02]. Project departmentalisation is a hierarchical structure with a vertical project structure. The project structure refers to the use of traditional functional departments, such as personnel and finance, vertically integrated into the project while there can still be a centralised finance and human resources department in the organisation [LOMP 00]. Staff are grouped and placed accordingly into teams

90


headed by a project manager. There is duplication in such a division, for instance some projects require dedicated accounting staff, facilities and resources [LOMP 00]. Each member of staff has one clear boss [LOMP 00].

Figure 5-8: Project departmentalisation

Examples of this type of structure are university research centres [LOMP 00], construction projects and software development projects. Projects can be decentralised, centralised or both. The

IT

function

can

be

centralised

and/or

decentralised

in

project

departmentalisation: centralised IT to support the other supporting functions and decentralised IT to cater for the projects’ IT requirements. For instance, if the projects entail software development for different computer platforms the projects’ IT functions would address the platforms’ specifications. The centralised IT function would facilitate code warehousing and reusability. f) Matrix Departmentalisation The above departmentalisations can be seen as the vertical process of an organisation. In the vertical structure the information flows to the top and orders or process requests flow downwards to tactical and first line managers. There is, however, an organisational structure that utilises the vertical structures as well as lateral (horizontal) process that spans the vertical processes. This organisational structure is commonly referred to as a matrix organisation [HEJS 99] [GALB 02]. The matrix organisational structure is a hierarchical functional organisation overlaid with a horizontal project structure [LOMP 00]. Staff are grouped and located by speciality into functional departments headed by a functional manager,

91


who may be seconded to work on a project part time or full time headed by a project coordinator or manager [LOMP 00]. This type of organisational structure leads to an employee having more than one person to report to. This dual reporting structure is evident in Figure 5-9.

Figure 5-9: Matrix departmentalisation

There are three types of matrix organisations. These types are differentiated only by the way in which resources are assigned to the lateral process. The types are [LOMP 00]: •

Strong matrix: When the individuals from functional departments are assigned full time to the project.

•

Weak matrix: When the functional departments assign resource capacity rather than people to the project. Resource capacity refers to the availability of resources, for instance computer equipment or facilities.

•

Balanced matrix: When the functional departments assign both people and resource capacity to the project.

Some of the organisations that have implemented this type of structure include IBM and General Electric [STCJ 00]. This matrix structure is mostly implemented in parallel with other organisational structures. For instance, when an information security risk assessment is performed, the assessment team is assigned from other departments [ALBE 01] while their initial departmentalised designation is still recognised.

92


This section discussed generic organisational structures. These structures serve to deliver on the vision and mission of the organisation. However, these structures are used to implement ISRM as part of the organisation’s supporting function. The next section investigates how the structures interact or impact ISRM.

5.4. DEPARTMENTALISATION AND RISK MANAGEMENT The ways in which organisations are structured have an impact on the risk management in an organisation. Each of the organisational structures discussed in section 5.3 is discussed in relation to risk management in this section. The organisational structures that have similar impacts on risk management are grouped accordingly.

5.4.1. Functional and Matrix Departmentalisation In a functionally departmentalised organisation the IT responsibility and authority is centralised. This centralised structure allows for specialisation of departmental risk management. Since risk controls can be similar in different departments and since the departments influence each other, horizontal (lateral) functions have to be implemented. This structure has been discussed as a matrix structure. The matrix structure is how some ISRM methods [CRAM01 96] [IST 03] [ALBE 01] recommend risk assessment be done. The matrix structure seems to be a solution to risk management but has many drawbacks. Unless the organisation implements a balanced matrix structure, the risk management processes will suffer delays, indecision or uncoordinated actions. Since a parallel can be drawn between the matrix and project structures, the organisation should not regard risk management as a project but a continuous process [KING 02].

5.4.2. Geographic Departmentalisation The geographically departmentalised organisational structure decentralises some of the authority of information technology and the responsibility for its risk management. This decentralised structure requires strong mandates and standards in order to ensure that uniform risk management principles are applied.

93


The board will have to take responsibility for subordinate actions over which they do not have complete control.

5.4.3. Product, Customer and Project Departmentalisation The product, customer and project departmentalised structures have very similar centralised and decentralised IT functions. There is centralised IT to support the supporting functions and decentralised IT to support the product, customer and project groupings. These centralised and decentralised IT functions lead to duplication of actions, which results in wasted resources. There is little or no coordination of actions, difficulty in sharing knowledge and systems, limited problem-solving and, in the case of project departmentalisation, actions are only temporary. Each organisational structure has an impact on the way the IT and risk management function operates. The structure of the organisation is determined by organisational-specific aspects. These aspects include the supporting functions.

5.5. RESEARCH VALUE This chapter established that information technology and information security risks have a ripple effect on organisations. Because information technology is a supporting function to other supporting functions and it also supports the core business function, the effect of compromised information security on the organisation increases. ISRM is a decentralised problem. The organisational structures are not determined by the security requirements of the organisation; however, they impact on how information security is managed. The organisational structures, coupled with decentralisation of information, lead to a decentralised ISRM programme. ISRM communication cannot be a standardised system. There are too many variables regarding the organisational functions and structure to which the communication channels will have to conform. Therefore, a risk information communication solution will have to be flexible in its implementation.

94


5.6. CONCLUSION Each organisation is structured differently due to the differences in goals and resources of the organisations. When considering all the different resources, supporting business functions and organisational structure combinations, the task of managing risk, assigning authority and taking risk responsibility becomes a daunting task. Because different supporting functions work together to deliver a service, there is a need for an integrated risk management framework which can be applied in all types of organisational structures and which takes into consideration all the different supporting business functions. An integrated risk management framework is necessary to address the risk of an organisation on a holistic level. The goal of the chapter was to establish the role of information technology within different organisational structures. This goal was achieved by determining the different functions IT could fulfil. Two functions were identified and IT was classified as a supporting business function. Several generic organisational structures were determined to meet the second objective. These structures were evaluated to determine how they impact on ISRM within an organisation. Organisations have the ability to address information security risks through different approaches at strategic, tactical and operational level through the organisation’s structure. However, organisations face various risks in different disciplines within the organisation. These different disciplines function together as supporting and core functions. Organisations have to address risks that arise from all these functions, including information security risks. The next chapter focuses on the concept of integrating all the different risk management principles holistically in an organisation.

95

C h a p te r 6

ENTERPRISE-WIDE RISK MANAGEMENT 6.1. INTRODUCTION It was established in the previous chapter that ISRM is influenced by organisational structures and the ISRM approach has to be adaptable to the different structures. However, ISRM is not the only risk management programme that is conducted in an organisation. There are various other risk management programmes specific to the organisational functional silos. These programmes, coupled with the ambiguous terminology of approaches at the different managerial levels and the need for effective risk information communication, create a disjointed environment for ISRM communication. The goal of this chapter is to define and discuss the concept of organisational risk management from a holistic point of view to address the disjointed risk management environment. The chapter’s first objective is to determine what it is to view risks holistically. The second objective is to define terms that relate to this concept of holistic risk management. The third objective is to define a generic view of holistic risk management and the final objective is to identify the generic components of holistic risk management. The order of the sections is guided by the objectives of the chapter. The first section discusses holistic risk views. The second section defines terms that relate to the concept of holistic risk management. The third section discusses a generic view of holistic risk management and the final section elaborates on the generic components of holistic risk management. The next section discusses the concept of viewing risks holistically.

96

Enterprise-Wide Risk Management

6.2. HOLISTIC RISK VIEWS An organisation’s inherent purpose is achieving its goals which include risk management, for instance making sure all employees are working, not stealing from the organisation, and that stock arrives on time. Some organisations do not have a stipulated risk management methodology or process but the risk management principles are applied through common business practices. Although organisations have become proficient in managing specific risks, the risks are often managed in a “risk silo” manner [BROW], for instance a bank’s board of directors specifying the acceptable risk levels for each unit within the organisation and managing them accordingly within that “silo” or unit [DJDV 01]. The problem with risk silos are that risk managers do not realise how intertwined different risks can be and the effect the risk intersections can have on an organisation [BROW]. Other problems of risk “silo-ing” are [BROW]: •

Risks cannot be divided across organisational units. Each organisational unit is responsible for its risks; they cannot be shared or controlled with the resources of different units. For instance, a risk that faces two different units cannot be addressed by both units as a single front; each utilises its own resources to address the risk.

•

Different business units may perform similar tasks and employ duplicate systems.

•

Inconsistent data sources and assumptions may be introduced and valuation techniques and risk metrics may vary across the organisation.

•

Risk silo-ing prevents the organisation from gaining an accurate single picture of its risk profile, which could lead to the increase in an organisation’s operational risk.

In order to counter these problems organisations have to follow a holistic approach to address their risks. Holistic (holism) [OXFO 80] is defined as the “tendency in nature to produce wholes (bodies or organisms) from ordered groupings of unit structures”. In terms of an organisational risk management

97


holistic viewpoint, the risks of each unit should form a “whole” within the organisation. This practice has various advantages [MILL 91]. By implementing a framework that includes the complete range of risks, an organisation can make better cost-benefit decisions that can be based on financial and analytical information as well as common sense [AKSE]. Having a holistic risk view will also facilitate the future thinking within the organisation [AKSE], which will assist in better identifying opportunities. This will assist the organisation in having a greater likelihood of achieving their objectives [TRCA 01]. Holistic risk management has various other advantages. Some of these advantages are [MULL 99] [TRCA 01] [KPMG 01] [STSH 03]: •

Organisations understand their risks better on a holistic scale which allows them to systematically address the risks and thereby minimise losses and negative outcomes.

•

A holistic risk view increases the organisation’s confidence in its ability to manage risks. This can lead to greater public confidence in the organisation and improved services to stakeholders.

•

Leveraging economies of scope, in terms of holistic risk management, leads to improved risk and capital allocation, which can result in reduced risk capital costs.

•

A shared responsibility for managing risks builds the organisational capacity to address risk.

The concept of managing risk holistically is not new [MILL 91]. As a result of business liquidations and internal risk reviews, management has become more aware of the importance of a holistic risk management approach [LAM 00]. Managing risk holistically is made easier through technology and those organisations that apply today’s best practice technology first will achieve a competitive advantage [BROW]. A number of factors have contributed to the development of enterprise risk management. Recent advances in computing power provide the powerful modelling tools necessary to perform sophisticated risk management [DARC 01].

98


This section discussed the problems with the silo risk management approach and the solution, holistic risk management, to those problems. As with the definitions of risk and its components, there are several views on holistic risk management. Two terms are used interchangeably to describe holistic risk management. They are integrated risk management and enterprise-wide risk management. The terminology that will be used in this document is enterprise-wide risk management (ERM).

6.3. ENTERPRISE-WIDE RISK MANAGEMENT The purpose of this section is not to define ERM in terms of information technology, but to establish what the term ‘enterprise-wide risk management’ means and in what context it will be used within this document. There are varying and diverse terminologies describing holistic risk management. Definitions of ERM vary widely—but many agree that it is a top-down approach, based on and supportive of organisational strategy, that is focused on new ways to manage and optimise the risks of highest importance to the board and management [KPMG 01]. Most of the confusion surrounds the definition of integrated risk management and enterprise-wide risk management. The general viewpoint is that integrated risk management (IRM) is the precursor-definition of enterprise risk management [DARC 01] [LCBI 02]. Other definitions of ERM include corporate risk management, business risk management, holistic risk management and strategic risk management. The concept embodied by these definitions is encompassed in the definition of ERM as used in this document. The basic viewpoint as supported by various authors [BAMM 99] [BROW] [DARC 01] [LCBI 02] [MULL 99], committees [BASE 01] and bodies [TRCA 01] [KPMG 01] is that ERM is the approach to manage risks across the entire organisation. Although the basic viewpoint is quite simplistic, there are various aspects of ERM that have to be mentioned: •

All the risks within an organisation are taken into account.

•

All activities in the organisation have to be geared and optimised towards the ERM process.

•

It is a continuous approach.

99


•

ERM is a strategic decision.

•

ERM is the synergy of different viewpoints.

A major trend in risk management is the development of a risk aggregation process in organisations. Risk aggregation is the processes where a common measure of risk is applied across products, functional units and other organisational boundaries [BASE 03]. Basically, during the risk management process risk aggregation provides a common risk management measure and, at the end of the risk aggregation process, provides an aggregated measure based on a common risk measure. In this document the holistic risk management concept will be referred to as enterprise-wide risk management (ERM). Whereas integrated risk management can be interpreted as the integration of individual risk silos, ERM unmistakably refers to all risk silos of an organisation. This section defined the terminology that will be used to refer to the concept of holistic risk management. However, holistic risk management has only been briefly addressed in the preceding section. There are various aspects regarding ERM. The next section discusses the ERM view in more detail.

6.4. ENTERPRISE-WIDE RISK VIEW In Chapter 2 the different risk requirements of information technology were defined as confidentiality, availability and integrity. As with information technology, each functional risk has its own risk requirements. This section does not address each functional unit’s risk requirements, but will highlight the fact that risks can be logically grouped within organisations to facilitate ERM. Organisations, bodies and authors each have their own views on risk; Figure 6-1 provides an example of logical groupings of risks with a medium granularity. For instance ERM risks can be grouped into business and non-business risk. The nonbusiness grouping is further subdivided into event and financial risks. These groupings are generic and will depend on the organisation. Various other enterprise wide risks can be defined; however, this example only serves to indicate the nature of enterprise wide risks and the fact that it can be grouped into different portfolios.

100


Enterprise wide risk Business risks

Non business risks Event risks

Product risks Macroeconomic risks Technological risks

Legal risks Reputation risks Disaster risks Regulatory / political Risks

Financial risks

Credit loss Liquidity risks Operational risks Foreign exchange risks

Figure 6-1: General view of ERM

The diagram is a general ERM risk. Some of the risks will, from a certain viewpoint, be closely related to risks in other groupings, for instance macroeconomic risks and foreign exchange risk. The diagram serves as an illustration of how risks can be grouped at an ERM level. Each of the ERM groupings in Figure 6-1 is discussed in the following sections.

6.4.1. Business Risks Business risks can consist of product risks, macroeconomic risks and technological risks. Business risks refer to any risks that directly affect the delivery of the primary function of the organisation. For instance, if the primary function of the organisation is delivering technology products like DVDs to consumers, the risk groupings under business risk affects the function as follows: •

Product risk – If the product quality is inferior, it will affect the ability of the organisation to sell the product.

•

Macroeconomic risk – Macroeconomic risks refer to the area outside the immediate organisation market, for instance the target market, industry or competitors [GGHL 97]. The macroeconomic risks can include inflation, employment or purchasing behaviours. For instance, what impact will the sale of motor vehicles with DVD players for passengers have on our product sales; likewise the impact of increased unemployment?

101


•

Technological risk – A newer technology that threatens to take the place of DVDs as a home entertainment product.

Information technology risk can be classified into the business risk group because technology can assist organisations in delivering better quality products, identifying macroeconomic trends as well assisting them in delivering, controlling or countering business technological risks.

6.4.2. Event Risks Event risks are those risks that can be isolated to an occurrence of a single external event that impacts the organisation. The four event risks indicated in Figure 6-1 are discussed briefly: •

Legal risk – An example is a legal dispute that might have to be settled in court.

•

Reputation risk – Reputation risk has become increasingly important, especially within the Internet environment where users rely on a trust network. If, for instance, credit card information is stolen from an online vendor, clients will be apprehensive to trust the organisation with personal information again.

•

Disaster risk – Disaster risk is probably the most well known of risks. This risk group includes natural disasters, for instance earthquakes, tornados or floods. Other disaster risks are fire, bombings, electrical power surges etc.

•

Regulatory/political risk – Regulatory risks can impact an organisation by, for instance, governments imposing an import or export ban on products or services of an organisation. Along with the regulatory risks, the political risks can induce regulatory risk or political risk can include imposing a quota system.

Organisations tend to classify certain information security risks as an event risk, for instance a hacker accessing confidential information. This is evident by the “fire-fighting” ISRM tactics employed by organisations.

102


6.4.3. Financial Risks There is a notion that ERM is dominated by financial risk [LCBI 02]. This is not the case.

The

financial

overlapping

risk

components

referred

to

above

(macroeconomics, regulating and legal) refer to risks that can impact the organisation financially but they are not of a financial nature. Examples of four financial risk subgroupings are: •

Credit loss – Most organisations can buy inventory on credit. If an organisation loses credit or is blacklisted, its strategic and tactical options are limited if it is not in a favourable financial position.

•

Liquidity risk – Liquidity of an organisation refers to the financial state of the organisation, for instance the amount of cash on hand or the asset-liability ratio. The liquidity state of the organisation provides an indication to creditors of the ability of the organisation to repay its debts.

•

Operational risk – Operational risks are the risks that affect the operation of the organisation. Operational risks depend on the industry; in the context of the financial markets the operational risks can be classified as financial, while in a manufacturing industry they can be classified as a business risk.

•

Foreign exchange risk – Organisations that import inventory or conduct business internationally have a volatile financial risk in foreign exchange. Foreign exchange rates can change on a second-by-second basis. Organisations buy futures in order to counter this risk, but futures can induce further risks.

Information technology is employed to assist organisations in managing their financial information accurately and in a timely fashion. Information technology is responsible for the accurate representation of the financial position of the organisation. This accurate representation will impact the credit rating, liquidity state and operations of the organisation. IT is further responsible for the accurate and, especially, the timely information of foreign exchange information in order to effectively mitigate foreign exchange risks.

103


Various enterprise-wide risks are affected by information security. Therefore information security risks cannot be isolated to a specific enterprise-wide risk grouping. This section indicated that ERM can be subgrouped in order to make the process of holistic risk management easier. However, ERM consists of several components. These components span the subgroupings discussed in this section. The next section discusses the ERM components.

6.5. ENTERPRISE-WIDE RISK MANAGEMENT COMPONENTS The first and most important objective of ERM is achieving a common understanding of risk across functional and business units [EIMM 01]. The second objective is developing a better understanding of risk for competitive advantage [EIMM 01]; therefore ERM has to add value to the organisation. This objective requires that the organisation’s goals be the driving force for ERM. In order to clarify what ERM is and how it can be applied within an organisation, the seven components of ERM are discussed. The purpose of this discussion is to identify the role of information technology and its important information security subcomponent within the ERM view. The ERM components were proposed by James Lam [LAM 00], and are confirmed to be important by various ERM frameworks [TRCA 01] [BOOK 03] [COSO], research papers [LAM 00] and organisational models [EIMM 01] [AKSE] [WASO 01]. The seven components are illustrated in Figure 6-2.

Figure 6-2: ERM components

Figure 6-2 indicates the seven ERM components of corporate governance, data and technology resources, line management, portfolio management, risk transfer,

104


risk analytics and stakeholder management. These seven components are discussed in sections 6.5.1 to 6.5.7. The first component, corporate governance, consists of seven corporate governance responsibilities which should be managed at top management level. These corporate governance responsibilities are discussed in sections 6.5.1.1 to 6.5.1.7.

6.5.1. Corporate Governance Early models of risk management viewed risk as something that should be analysed and understood for its own sake [KPMG 01]. However, throughout the previous chapters and by investigating frameworks, it has become clear that risk management and especially enterprise-wide risk management should be driven by the organisational goals, mission, vision and culture which should determine the processes, policies, plans and initiatives. Corporate governance (Chapter 4) is responsible for all aspects related to the organisation. There are seven ERM responsibilities that will have to be addressed by top management. Although some responsibilities are mirrored in the major ERM components, they are discussed in this section as responsibility and not a component. Top level management is responsible for a risk management programme to be in place (see Chapter 4). Each of these responsibilities is discussed briefly.

6.5.1.1. Risk Appetite Risk appetite is also known as risk tolerance and risk utility (see 2.6.5). It is important for an organisation that the ability of an organisation to accept risk be documented. This documented risk tolerance provides guidance on the organisation’s ERM philosophy [LCBI 02] [LAM 00].

6.5.1.2. Resources Top management is responsible for ensuring that enough resources are made available to address any issues regarding ERM. The resources include human, technology, data, facilities and applications [ALBE 01] [LCBI 02] [EIMM 01]. Risk management is a cost centre, and the board needs to split resources between risk

105


management and profit centres. In general, the more resources are allocated to risk management, the better risk is measured and managed, but at the expense of lower profitability [DJDV 01].

6.5.1.3. Structure Structure refers to the establishment of a risk management structure which should include the responsibilities and role of the chief risk officer. After the structure has been established, accountability for the overall risk management function has to be defined [LCBI 02] (see Chapter 5). Responsibility refers to a single individual responsible for looking at how risk affects the overall enterprise [LCBI 02]. Responsibility is closely associated with the management or organisational structure which enables processes to be executed. The structure will require the organisation to determine whether the risk management function will be a centralised activity. If the risk management is a decentralised function, a committee structure can be implemented [LCBI 02] (see section 5.4). Management has to establish an infrastructure that supports the risk management process [LCBI 02]. The infrastructure will have to provide methods of communication, risk integration and risk aggregation. Information technology is considered to be the greatest enabler of enterprise-wide risk management [BROW]; therefore the infrastructure will be complemented by an information technology component.

6.5.1.4. Framework Top management is responsible for a risk framework [KING 02]. A framework is a mould or template into which processes, steps, methods or policies can be organised. The risk framework has to cater for event, business and financial risks and should be adapted to suit the organisational needs.

6.5.1.5. Processes Processes are courses of actions taken over time, for instance the building of a house. First a plan has to be drawn up, building material sourced, builders contracted, structures built and then signed off by a building inspector. A process has a set flow that has to be followed in order to provide a result. Different

106


processes run concurrently in organisations, hence the importance of frameworks to coordinate the processes. Top management is responsible for implementing the appropriate processes to address information security problems.

6.5.1.6. Culture ERM should be driven by the objectives of the organisation; it therefore includes the whole organisation. The way in which an organisation conducts itself is commonly referred to as the culture. The culture is not a set policy or process that can be followed, but a general unspoken, undocumented movement towards common goals. A risk culture has to be established where employees deal with risks as the whole organisation expects risks to be treated. The culture’s “tone setting” should be initiated from the top.

6.5.1.7. Learning Opportunities for a learning organisation should be provided, as this adds to the knowledge or intangible assets of the organisation (see section 2.3.1.2). In order to have a very effective risk management process the organisation must have some type of communication and feedback loop where not only is exposure accepted, but the effectiveness of the programmes is also monitored [LCBI 02]. For instance, if a risk is realised, an employee should report through a specified feedback infrastructure. The feedback should not be regarded as critique or fault finding, but the risk should be documented and countermeasures implemented to reduce the probability of the risk recurring.

6.5.2. Data and Technology Resources One of the greatest challenges for ERM is the aggregation of the underlying market and portfolio data. Portfolio data can include risk positions that are captured in different front- and back-office systems. There is no current vendor product that provides a total solution to enterprise-wide risk management [WASO 01] [LAM 00]. Despite the data and system challenges, companies should not wait until the perfect system solution is available before establishing an ERM programme. Companies should consider tapping into the power of the Internet in the design of their enterprise risk technology platform [WASO 01].

107


Taking into consideration the increasing dependence of organisations on information technology resources and the use of these resources to manage risks holistically, the importance of assuring the security of information within these systems is paramount. The data and technology resources as defined in context of the ERM components only refer to the tools as used to support the ERM processes and components. This component does not directly refer to the principle of IT or ISRM.

6.5.3. Line Management Organisations do not only consist of top management and employees. They are grouped functionally, logically or otherwise (see Chapter 5) and have various levels of management. Line management is the connection between the employees (the everyday function of the organisation) and top management. Line management is tasked with implementing and coordinating the processes that are required by the framework. The different line managers have to align their business strategy with the corporate risk policy. The framework will be supplied to the line management along with the areas for which they are responsible, for instance the assessment of information security. The line manager will then have to select the most appropriate, effective and efficient method or process to conduct the assessment. Line managers will have to coordinate their actions with other line managers, especially if a risk aggregation policy has to be followed.

6.5.4. Portfolio Management Investment and fund managers manage their risks in a portfolio. All the investments they make have certain expectations to fulfil with regard to the risks taken. Organisations invest in countermeasures to hedge them against risks or capitalise on opportunities, just like investors. Therefore organisations should manage their risks in portfolios where targets as well as risk limits are set [AKSE] [LAM 00] [KPMG 01]. The concept of a risk portfolio assumes that various risks share certain characteristics and/or interdependencies. Risks are considered in groups, based on how they relate to each other, and within these groups one or more risks may

108


rise or fall when other risks rise or fall. In addition, when one risk is transferred, another may arise. An example of this is outsourcing the IT function to reduce cost. Although the financial position of the organisation will increase, the organisation has opened itself to information technology risks in terms of information security. The outsourced organisation might not regard the information as private or confidential as employees in the organisation would.

6.5.5. Risk Transfer To reduce undesirable risks, management should evaluate derivatives, insurance and hybrid products on a consistent basis and select the most cost-effective alternative [LAM 00]. In a previous chapter different approaches used to reduce an organisation’s risk exposure were discussed. However, note has to be taken that traditional risk management mitigation controls are giving way to risk portfolio optimisation [KPMG 01], for instance grouping the loss of uninsurable risks such as loss of organisational information with insurable operational risks. One method of risk transfer is called integrated risk financing. Integrated risk financing is the process in which organisations bundle risks to reduce the costs of insurance or risk mitigation [EIMM 01].

6.5.6. Risk Analytics Risk analytics is the process in which several metrics are used to determine the most cost-effective structure to accomplish the risk objective [LAM 00] [EIMM 01]. Risk analytics can also be applied to information technology risks, for instance the rate of server failure can be measured and a probability of future failures calculated. Statistical methods such as Monte Carlo simulation and time series analyses are suitable for risks that have a large amount of data. Financial, credit and hazard risks are obvious candidates for statistical analysis, but such methods can be applied to certain operational risks as well. Qualitative assessments include scenario building, best guesses and consensus views on risk estimates. Such methods are useful for what are often thought of as intangible risks [EIMM 01].

109


6.5.7. Stakeholder Management Risk management is not only an internal management process but it should be used to improve risk transparency to key stakeholders. This includes periodic reports and updates on the major risks faced by the organisation as well as the review and approval of risk management policies for controlling these risks. Regulators need to know that sound business practices are in place and that business operations are in compliance with regulatory requirements. One of the most prominent regulatory stakeholders that dictate how operational risks are addressed in banks is the Basel II Report [BASE 03]. Another is the King II [KING 02] Report’s recommendation of an annual risk assessment of the organisation in South Africa. Others are the Turnbull Report (4.3.3), Cadbury Report (4.3.2) and Sarbanes-Oxley (4.3.4) Act. The seven ERM components are the building blocks of an ERM framework. Each of the components has a role to fulfil for an ERM strategy to be effective.

6.6. RESEARCH VALUE This chapter highlighted the fact that the various risk components of an organisation can be melded together for a holistic risk view in the organisation. However, this holistic view requires the clear understanding and integration of ERM components. These components and the holistic view of ERM are provided in this chapter. It has been established that information technology is the enabler of ERM. Information technology is also the risk aggregating enabler and supporting function to all the different risk silos in the organisation.

6.7. CONCLUSION Risk management is not only applicable to information security, but is a principle that has to be employed in every function of the organisation. By addressing risks in every function of the organisation and managing them throughout the organisation provides the organisation with a holistic view of its risks. This holistic risk view, referred to as enterprise-wide risk management, combines all the risk management data and information in the organisation to give an overview of the organisation’s risks. These risks can be grouped according to the organisational

110


requirement, which will facilitate better management of the processes. ERM consists of seven basic components. These components are discussed in section 6.5. The goal of this chapter was to define and discuss the concept of organisational risk management. This was achieved by discussing the concept of managing risks in an organisation holistically. This holistic view was defined as enterprise-wide risk management. In support of the goal, advantages, groupings and components related to ERM were discussed. The chapter’s first objective was to determine what it is to view risks holistically. This goal was achieved by outlining the disadvantages of a silo risk management approach and the gains from managing risks holistically. The concept of holistic risk management was clearly defined, along with related concepts to achieve the second objective. The third objective was to define a generic view of holistic risk management. This was achieved by providing an example of a generic grouping of risks which serves as an ERM view. The final objective was to identify the generic components of holistic risk management. This objective was achieved by identifying seven generic risk management components. It has been established that ERM consists of various components. These components work together to form a holistic front to risks an organisation might be facing. However, information technology is required to present this ERM front. This chapter discussed the advantages, terminology, groupings and components of ERM. These concepts have to be employed in organisations. This is accomplished through frameworks, methodologies and approaches. The next chapter addresses the applications of ERM in organisations.

111

C h a p te r 7

ENTERPRISE-WIDE RISK MANAGEMENT RAMEWORKS

F

7.1. INTRODUCTION In the previous chapter the components of enterprise-wide risk management were discussed. It was established that data and technology are becoming the enabler of this risk management principle. The technology enables the processes, but there still has to be a set of logical processes which constitute ERM. The goal of this chapter is to determine the implementation of ERM in organisations. The first objective is to determine what approaches are used to apply ERM in the organisation. The second objective is to determine what problems threaten the implementation of ERM. The third is to investigate the responsibility and accountability for ERM within the organisation. The chapter layout is guided by the objectives of the chapter. The first section discusses ERM frameworks. The second section identifies and discusses two general roadblocks to the implementation of ERM. The last section addresses the responsibility and accountability for ERM. A general approach to implementing ERM in an organisation has to be such that it takes into consideration the immeasurable permutations of risks, organisational structures and resources. The general approach to ERM is frameworks; this approach is discussed in the next section.

112

Enterprise-Wide Risk Management Frameworks

7.2. FRAMEWORKS Different approaches can be implemented to institute ERM in an organisation. However, ERM is a concept that has to be pliable to suit any type of organisation, holistically and from the top-down. It has to be applied to different types of organisations with varying resources and organisational structures. These variables make it difficult to develop generic processes that can be easily implemented. Therefore the best approach is the use of a framework. When considering the different components that make up ERM (see section 6.5), a framework is considered as one of the ERM components. That is why only frameworks are discussed as the ERM approach. A framework is a template or mould into which different processes, methods or steps can be placed in order to make risk management across the organisation easier. There is no single approach to ERM [WASO 01] [AKSE], nor do best practices exist [AKSE]. Therefore three frameworks are discussed. They are the Treasury Board of Canada – Integrated Risk Management Framework (section 7.2.1), Grant Thornton ERM Framework (section 7.2.2) and the COSO ERM Framework (section 7.2.3). In section 6.5.1.4 it was determined that management is responsible for implementing a risk management framework. These are frameworks that organisations can implement as the ERM framework component. The first framework is one proposed by the Treasury Board of Canada as an initiative by the government of Canada.

7.2.1. Treasury Board of Canada Integrated Risk Management Framework The Canada Integrated Risk Management (IRM) Framework [TRCA 01] proposed by the Treasury Board of Canada provides an organisation with a mechanism to develop an overall approach to manage strategic risks by creating the means to discuss, compare and evaluate substantially different risks on the same page. It applies to an entire organisation and covers all types of risks faced by that organisation (e.g. policy, operational, human resources, financial, legal, health and safety, environment, reputation) [TRCA 01]. No clear mention is made of ISRM; however, in the third element of practising IRM, information technology risk

113


management is regarded as an important discipline in the integration of IRM results. The purpose of the IRM Framework is to [TRCA 01]: •

provide guidance to advance the use of a more corporate and systematic approach to risk management;

•

contribute to building a risk-smart workforce and environment that allows for innovation and responsible risk-taking while ensuring legitimate precautions are taken to protect the public interest, maintain public trust and ensure due diligence; and

•

propose a set of risk management practices that departments can adopt, or adapt, to their specific circumstances and mandate.

Figure 7-1 provides a graphical representation of the systematic approach to risk management.

Figure 7-1: Treasury Board of Canada Integrated Risk Management Framework

The IRM Framework comprises four related elements. The four elements of the IRM Framework are presented as they might be applied: looking outward and across the organisation as well as at individual activities. This approach to managing risk is intended to establish the relationship between the organisation

114


and its operating environment, revealing the interdependencies of individual activities and the horizontal linkages. The four elements of the integrated framework (see Figure 7-1) are discussed. Element 1: Developing the Corporate Risk Profile An awareness and understanding of the current risk tolerances of various stakeholders is a key ingredient in establishing the corporate risk profile. The environmental scan will identify stakeholders affected by an organisation’s decisions and actions, and their degree of comfort with various levels of risk. Understanding the current state of risk tolerance of citizens, parliamentarians, interest groups, suppliers, as well as other government departments will assist in developing a risk profile and making decisions on what risks must be managed, how and to what extent. It will also help identify the challenges associated with risk consultations and communication. Developing the corporate risk profile includes the following steps: •

Identify the organisation’s risks through environmental scanning;

•

Assess the current status of risk management within the organisation;

•

Identify the organisation’s risk profile .

The corporate risk profile provides the necessary input to establish corporate risk management objectives and strategies. This element does not directly provide for or address information security risks. Element 2: Establishing an Integrated Risk Management Function Establishing an IRM function means setting up the corporate “infrastructure” for risk management that is designed to enhance understanding and communication of risk issues internally, to provide clear direction and demonstrate senior management support. It is essential that management provide a clear statement of its commitment to risk management and determine the best way to implement risk management in its organisation. Effective risk management cannot be practised in isolation, but needs to be built into existing decision-making structures and processes. As risk management is an

115


essential component of good management, integrating the risk management function into existing strategic management and operational processes will ensure that risk management is an integral part of day-to-day activities. In addition, organisations

can

capitalise

on

existing capacity

and

capabilities

(e.g.

communications, committee structures, existing roles and responsibilities) [TRCA 01]. The goals of the IRM function element are to: •

communicate, understand and apply management direction on risk management;

•

implement an approach to operationally integrate risk management and ensure that the implementation is executed through existing decisionmaking and reporting structures;

•

build capacity through the development of learning plans and tools.

This element does not directly provide for or address information security risks. Element 3: Practising Integrated Risk Management A common, continuous risk management process assists an organisation in understanding, managing and communicating risk. Emphasis on various points in the process may vary, as may the type, rigour or extent of actions considered, but the basic steps are similar. The results of risk management are to be integrated both horizontally and vertically into organisational policies, plans and practices. Vertically functional units, such as branches and divisions, need to incorporate these results into programmes and major initiatives. Information technology risk management is considered as a relevant discipline while integrating the results for risk management into practices at all the levels, for instance to assist in the gathering, processing and dissemination of the relevant risk information. The goals of practising integrated risk management are to: •

consistently apply a common risk management process at all levels;

116


•

integrate results of risk management practices at all levels into informed decision-making and priority setting;

•

apply tools and methods; and

•

consult and communicate with stakeholders on an ongoing basis.

Element 4: Ensuring Continuous Risk Management Learning While it is acknowledged that some departments are more advanced than others in moving towards the implementation of an IRM approach, there is growing appreciation across the public service for the need to strengthen risk management practices and develop a more strategic and organisation-wide focus. Implementing IRM will depend largely on an organisation’s state of readiness, overall priorities and the level of effort necessary to implement the various elements. As a result, developing a more mature risk management environment will require sustained commitment and will evolve over time. This framework is a step in establishing the foundation for integrated risk management in the public sector. It is acknowledged that to support and facilitate implementation, the development of specific tools and guidelines as well as sharing of best practices and lessons learned will be required. Goals of the fourth element: •

To establish a supportive work environment where learning from experience is valued, and lessons are shared;

•

To build learning plans into an organisation’s risk management practices;

•

To evaluate results of risk management to support innovation, learning and continuous improvement; and

•

To share experience and best practices, internally and across government.

This framework does not place a priority on IT and its related risks. It is a very high level, public service orientated and basic risk management framework that mostly addresses the process and the requirements for an enterprise-wide (integrated) risk management strategy. The overall risk management notion of the framework is to address the matter of trust, reputation and financial risk management in the public service.

117


The framework discussed in this section is focused on the public sector. There are other frameworks that are targeted and produced by commercial organisations. The next section discusses one of these frameworks.

7.2.2. Grant Thornton Enterprise-Wide Risk Management Framework The Grant Thornton ERM Framework [BOOK 03] involves a general risk management cycle. The cycle along with the resulting risk profile are displayed in Figure 7-2.

Figure 7-2: Grant Thornton ERM Framework and Risk Profile

The framework is cyclical with seven steps. The seven steps are comparable to the ISRM frameworks and methods discussed in Chapter 3. Although comparable to lower level frameworks or methods, Grant Thornton’s ERM Framework addresses risk management more holistically and at a strategic level. Each of the seven steps is discussed briefly. Step 1: Identify The first step involves processes to identify any risks inherent to the business and operations of the organisation. The inherent risks identification will assist in composing a risk profile. The framework further recommends that decentralised risk ownership be performed at individual activity levels, business levels or units.

118


Step 2: Measure Step 2 requires the organisation to determine if a risk is significant or not. This step further requires the organisation to determine ways in which the risks will be measured. The measurement methods can be determined in cash, fines, penalties, percentages or loss due to ineffective processes. Step 3: Assess During the assessment step, the risks are assessed on two dimensions: the likelihood of occurrence and the impact they will have on the organisation. The framework recommends voting technologies where each workshop or committee member can “vote” their assessment. The voting technologies then compile the results, transform the data into defined scales and provide the organisation with a correlated severity of risk assessment. At the end of the assessment step the resulting information is shown as a risk profile. The risk profile development phase is displayed in more detail in Figure 7-2. Step 4: Assign Response and Responsibility The risk profile provides the organisation with a layout of the risks within the organisation. It provides the organisation with a “plan” of action as it conveys what risks can impact on the organisation. Responses to the risks will have to be defined and resources assigned to mitigate the risks. During this step, management will have to decide which risks it is willing to accept or manage. The decision of determining which risks to accept will be determined by the organisation’s risk threshold/appetite. Step 5: Manage A person will be assigned the responsibility of managing the risks of the organisation. The responsibilities of the risk officer will include translating the risk responses into day-to-day actions. The person will also be responsible for developing the policies, managing insurance (risk transfer) plans etc. Step 6: Monitor If organisations make the commitment and invest resources in their risk management strategy, they would like to make sure that the results are sustained. In order to ensure that risks are managed effectively over time, the organisation

119


has to put processes in place that monitor the effect of the risk controls as well as monitor for new risks that may arise. Internal audit can be part of the internal monitoring process. Step 7: Report and Inform Risk management is a continuous process; therefore information will have to be gathered and communicated to relevant parties in order to identify new, altered or eliminated risks. The information will be useful in fine-tuning the risk management process, speeding up risk identification and ensuring effective monitoring, among other benefits. Another important party to inform is the organisation’s governing body. The governing body will require information on the progress, effectiveness and efficiency of the implemented processes. This “final” step will require a pre-defined information structure. Information technology only serves a supporting role in data collection and transformation. This framework provides a basic framework that can be tailored to different organisations in different industries. Each organisation will have to determine which strategy it is going to follow. This strategy will include determining whether or not a centralised or decentralised structure will be followed. The tailored ERM framework can only be implemented if several components are in place, for instance top level support, proactive risk strategy, accountability, resources and culture. These elements were discussed in Chapter 6. This framework was developed by a commercial company for ERM; however, there are frameworks that have been developed by commissions or industry bodies. The next section discusses one of these frameworks.

7.2.3. COSO Enterprise Risk Management Framework The COSO Framework was developed by the Committee of Sponsoring Organisations (COSO) of the Treadway Commission (USA) which was formed in the early 1990s after internal control shortcomings within organisations came to light [COSO]. The Commission comprises members of the financial community with the purpose of defining internal controls. The Commission published an integrated framework for internal control in 1992 but this was generally known only

120


by accounting academics and select attorneys. It has become more relevant since the promulgation of the Sarbanes-Oxley Act [SOX 02] of 2002. The framework was developed to provide organisations with a sound framework with integrated principles, common terminology and practical implementations. The secondary goal of the framework is to “educate” managers of risk management principles. The COSO Framework consists of three dimensions as illustrated by the cubic structure in Figure 7-3. Each plane (X-Y-Z) of the cube represents a COSO Framework dimension. The first dimension is the eight components that, according to COSO, comprise ERM. These components are to an extent consistent with the components addressed in section 6.5. The second dimension is the objectives of the ERM process, while the third dimension is the organisation and the components that make up the organisation, for instance subsidiaries and divisions.

Figure 7-3: COSO ERM Framework

Organisational Objectives The framework views the objectives of the organisation in four categories; they are distinct but can overlap. They are: 1. Strategic – The strategic objectives of the organisation are the high levels of the organisation that support and are aligned with the organisation’s mission, vision and goals. 2. Operations – The operational objectives include the effective and efficient management of the resources of the organisation.

121


3. Reporting – Organisations, specifically publicly traded organisations, have to have a reliable reporting system in place. Reporting ensures that management can make effective decisions. The reporting function of organisations is more often than not IT-based. 4. Compliance – Organisations have to adhere to regulations, laws or standards (see Chapter 4) that can be country, industry or geographically specific. Organisational Components The COSO Framework regards the different organisational components, which can be compared to the organisational structures, as a dimension of the ERM framework (see Chapter 5). For instance, by intersecting the organisational objectives, the organisational components and the ERM components, the ERM monitoring of the organisational compliance at each division and business unit, the ERM components and organisational objectives are addressed within each possible organisational structure. COSO ERM Components The COSO ERM Framework predominantly focuses on the different components the Committee of Sponsoring Organisations regard as relevant to ERM. These components are in line with the seven generic ERM components (see section 6.5). 1. Internal environment – The internal environment includes establishing the risk philosophy (risk tolerance), risk culture, ethical values and how management assigns responsibility and accountability. 2. Objective setting – ERM objectives should be set at the different levels within the organisation and should be kept consistent. The objectives should be aligned with the risk tolerance of the organisation. For instance, information technology objectives might include regular IT security training programmes at different organisation levels. 3. Event identification – The identification of potential events that can impact on the organisation. Negative events require management to assess the risk. The entire organisation has to be considered, as events do not occur in isolation, for instance the event of copied confidential files from a computer server.

122


4. Risk assessment – Risk assessment allows organisations to consider the impact an event can have on the organisation. Negative events should be assessed on an inherent and residual basis. 5. Risk response – Risk response answers the question: “how will management respond to events?” while considering cost versus benefit. To facilitate easier risk response, risks should be managed on a portfolio basis. 6. Control activities – Control activities include policies and procedures that help and assure management that the appropriate responses are carried out at different levels of the organisation. These activities can overlap. A control activity can include backing up critical information electronically to a secondary server and verification by a security officer. 7. Information and communication – Communication should occur horizontally and vertically within an organisation. Therefore an organisation will have to put a system in place that can facilitate this communication. The system should consider the detail (depth) and timeliness of the information. Computer systems can assist with this communication process by facilitating automatically generated reports to relevant employees in relevant detail. Management will have to provide a means for employees to understand the impact their work will have on other employees’ performance and work. 8. Monitoring – After procedures, processes and policies have been put in place, management will have to make sure of their effectiveness and efficiency. IT assists in both of these strategies as it is used in information correlation and processing. Information technology can be further implemented on an automatic monitoring basis that provides management with continuous ERM information. The COSO Framework components can be considered (although not specified) to be of a cyclical nature like the Grant Thornton and Canadian Treasury Department’s ERM Frameworks. The framework considers the objectives of the organisation in the four categories as well as the different components that make up an organisation. The preceding sections discussed three ERM frameworks that have been developed by the public sector, private sector and a commission. Although there are various ERM frameworks, there are still roadblocks that hinder the

123


implementation of ERM within organisations. The next section discusses some of these roadblocks.

7.3. ROADBLOCKS OF ENTERPRISE-WIDE RISK MANAGEMENT ERM has been proven to be an important ongoing process that must be integrated into the core of the business itself [BROW]. Although organisations are implementing ERM and regard it as an emerging best practice [PWC 00], there are roadblocks that hinder its implementation. Three of these roadblocks are discussed briefly.

7.3.1. The “Science” of Risk Management Risk management is not an exact science, as many of the risks an organisation faces are “soft” risks that are difficult, if not impossible, to quantify. Most operational risks fall into this category [BROW]. The majority of the ERM elements can be classified as “soft” issues. For instance at the highest level risk management involves three: •

Define, document and disseminate risk management policies and procedures.

•

Implement the systems to measure their risks.

•

Develop activities to manage the risk.

In essence organisations might be measuring the wrong risks or might be applying the wrong measurement to the right risk [BROW]. Certain elements of ISRM fall within this category, for instance the impact measure. However, some elements are factual, for instance quantifiable measures such as intrusion attempts or system uptime. The general risk management of information security leans towards the “soft” management issues.

7.3.2. IT and Infrastructure In this section information technology and its related terminology are used in terms of enabling tools and do not refer to the risks of these tools. The second roadblock involves IT and infrastructure. There is a tremendous amount of raw data and information that must be managed across processes

124


[BROW]. Multiple business entities within the firm are involved – each within their own needs and operating targets. Efficiently managing this process requires stateof-the-art IT and substantial infrastructure investment [BROW]. Removing the IT and infrastructure roadblock is arguably the easier of the two. Technological advances in computing power and software architecture have made ERM achievable now [BROW]. Today’s cutting-edge systems offer: •

Open source architecture – This type of architecture enables organisations to customise systems to organisational requirements due to the “open” source code at the organisation’s disposal.

•

Distributed processing

– Organisations can

have their

processing

requirements distributed, for instance running calculations like distributed Monte-Carlo on idling computer systems. •

Browser-based, n-tier architecture – A browser-based system enables a user to interact with systems on a familiar Internet basis while the n-tier architecture enables different systems (including legacy systems) to seamlessly integrate. By implementing a browser-based, n-tier architecture organisations reduce the costs of user interaction and system development, increase system scalability and reduce technical failure risk.

A major roadblock for ERM is responsibility and accountability. Who should be responsible for the ERM processes and coordination? Who should be accountable for the risks in the organisation? Although these points have been raised as an important component of ERM, as part of the ERM infrastructure they warrant further investigation.

7.3.3. Responsibility and Risk Accountability Before the two similar terms can be explained with regard to ERM, their contextual definitions have to be established. Responsibility refers to the entity in charge of actions or assets, while accountability can be described as when somebody can or should be held liable, he/she must suffer the consequences of actions taken [OXFO 80]. For instance, a parent is responsible for looking after a child. If the child commits a crime, the child has to suffer the consequences or punishment, i.e. be held accountable.

125


Somebody must be responsible for an ERM programme [LCBI 02]. There are two options available with regard to risk responsibility for an organisation [LCBI 02]: •

Risk committee – A committee can be formed to coordinate and facilitate the risk management process, but in order to be practical, organisations really need to assign one person that should be responsible within a committee, for instance a chairperson [LCBI 02] [AKSE].

•

Individual – An individual responsible for ERM is can be designated as the chief risk officer (CRO). This individual will be responsible for at least coordinating and facilitating the whole risk management process. CRO responsibilities should be defined by corporate governance [LAM 00] [AKSE] [LCBI 02]. This job requires a range of knowledge, experience and skill that is rarely found in one individual [AKSE] [DARC 01].

The next two sections investigate the concepts of responsibility and accountability more closely. This is followed by an investigation into high level and external requirements regarding risk responsibility and accountability. Responsibility Risk responsibility can be centralised or decentralised. Clearly if an individual is responsible for risk management, it will be a centralised responsibility. There are many benefits to centralising the entire spectrum of an organisation’s risk responsibility [AKSE]. The centralised risk management function can develop a common risk framework, policies and measurement methodologies. The commonality of approach gives senior management and decision-makers a clearer view of the interrelationships among various risks [AKSE]. Although a centralised risk management approach is recommended, within large multinational organisations a committee structure where individuals in different areas are held responsible for specific actions will be more feasible. Organisations can use a committee or individual structure and deciding whether it is a centralised or decentralised responsibility will depend on the organisation’s needs. Each organisation will have to decide what their needs are and how they will be best served with a structure and distribution strategy. For instance, a multinational organisation will benefit from a decentralised committee structure as each geographical area’s “uniqueness” can be incorporated in policies or

126


organisational culture. Table 7-1 outlines some advantages and disadvantages of each of the structures and distributions. Although some might have been indicated as disadvantages, they can serve as advantages for a specific organisation, depending on the organisational needs [BOOK 03].

Individual

Committee

Centralised

Control (+) Single responsibility (+) Communication (+) Shared culture (+)

Coordination (-) Shared responsibility (-) Shared knowledge (-)

Decentralised

Table 7-1: ERM distribution/responsibility

Travel (-) Working relationships (+ / -)

Coordination (-) Communication (-) Distributed organisation culture (-) Geographical uniqueness (+)

‘+’ indicates advantage and ‘-’ disadvantage

Regardless of whether risks are managed in a centralised manner, in a decentralised manner, or with a hybrid of these structures, a new organisational trend is to create ERM “programme offices” and appoint chief risk officers (CROs) who are responsible for developing and managing risk management strategy [KPMG 01]. In many instances, the CRO reports to the chief financial officer (CFO) or CEO and in some instances directly to the board of directors [LAM 00]. The next two sections discuss accountability and responsibility individually. This is followed with an examination of the high level and external requirements regarding responsibility and accountability. Accountability With regard to risk accountability, the best method is to hold a single person accountable for the risk management function [LCBI 02]. Organisations that have employed CROs can implement an organisational structure that conforms to one of the following accountability models [AKSE]: a) The Financial Risk Model The essence of this risk management model is the integration of financial risks only and the existence of a CRO to whom the market risk and credit risk functions report [AKSE]. The weakness of this approach is that responsibility for operational

127


risks remains fragmented among various organisational units or perhaps is addressed by a separate committee [AKSE]. b) The All-Risk Model The distinguishing characteristic of this model is a CRO who is responsible for the full scope of the company’s risks, including operational risks as well as credit and market risks [AKSE]. Typically, the role is a consultative one. The CRO maintains awareness of risk issues throughout the organisation, sets risk policy, measures risks, reports exposures and proactively thinks about operational risk [AKSE]. He or she does not manage the back office, information technology, or other areas in which risks occur [AKSE]. c) The Risk Governance Model An intriguing alternative to the all-risk approach is one that combines risk measurement with the related control functions under a single CRO [AKSE]. This approach is less consultative and more managerial [AKSE]. The CRO assumes a “watchdog” role and is responsible for internal audit and other compliance functions. The credit and market risk officers, who are responsible for approvals, work very closely with the CRO and may either be inside or outside the risk management structure [AKSE]. Risk accountability can be designated by the board of directors of an organisation or dictated by the regulatory environment. In South Africa the risk accountability burden is placed on the board of directors according to the King II Report on Corporate Governance [KING 02]. The regulatory environment and especially the board have an involvement in the ERM programme, and for that reason this subject will be discussed in more detail. Throughout this document it has been stated that risk management (including ERM) should be driven by organisational objectives (determined by the board) as well as the fact that the board should be held accountable for any risk related actions. The next section elaborates on the involvement of the board and regulatory environment in an ERM programme.

128


High Level and Externally Required Accountability and Responsibility The preceding sections discussed the accountability and responsibility of risk management in an organisation. In this section the involvement of the board and regulatory environment in risk management is highlighted. a) Board Involvement The board incurs expenses by employing a risk manager, and makes two related decisions: What resources to allocate to the risk management function and the degree of delegation to the risk manager. The risk manager in turn, based on his compensation contract, decides how much effort to put into actually managing risk. The actual effort chosen depends on both the actual resources allocated as well as the level of monitoring by the board, i.e. how much of the risk management function is delegated to the risk manager [DJDV 01]. Two alternative risk management systems are available to the board: one system with a high degree of delegation of responsibility and another with a low degree of delegation. The first system can be labelled as direct risk monitoring and the second as indirect risk monitoring. With a direct monitoring system the board observes all the decisions, whereas in the second system only the outcomes (earnings) are monitored [DJDV 01]. It has been mathematically proven [DJDV 01] that the first (direct) system will deliver the best outcomes. The board should further make employees within an organisation aware of risk management as part of management tools as it is generally low in all institutional levels [PUSC 02]. b) Regulatory Environment Involvement Organisations find themselves in various

industry

classifications.

Each

classification can have a certain level of regulations imposed upon it. For instance, organisations that trade their stock publicly have to adhere to annual audit reports. Each organisation might be expected to adhere to a different level of regulatory involvement. If organisations do not adhere to regulations the organisation could suffer severe repercussions. Therefore the responsibility and accountability structures within an organisation have to be clearly defined.

129


Depending on the regulating body, the regulations do not have to be adhered to by the letter. For instance, Basel Accord II, as applied to banks, gives a capital standard to banks for operational risk [LCBI 02] as well as a recommendation for information technology risk requirements. Certain regulations do not directly dictate information technology risk management but indirectly require it, for instance privacy laws require personal information to be stored confidentially. The information is stored in computer systems, which implies that the computer system has to be secure; hence information technology risk management. The regulatory environment has a set formula [LCBI 02]. To break away from that, organisations need to convince the regulators that they have better experience than that, and they are monitoring and controlling it [LCBI 02].

7.4. RESEARCH VALUE This chapter provides organisations with an overview of an appropriate approach to manage risks holistically within an organisation. Different frameworks are available to organisations to implement. It has been shown that although ERM frameworks address various risk management problems, there are still roadblocks that hinder their implementation. Technology has been identified as a supporting role within organisations in Chapter 5. It was also shown that ERM cannot function without the use of information technology. However, it has also been shown that information technology has a major impact on the functioning of the entire organisation. This important role of technology has taken a back seat to other risks in the organisation. ERM frameworks have to increase the importance of ISRM in the frameworks. The chapter also showed that risk accountability and risk responsibility, which although according to law should be placed at the top of level of the organisation, are disseminated among the organisational structures and ERM approaches. If organisations follow this route, the communication of risk information should be able to provide management with a clear view of the organisation’s risks.

130


7.5. CONCLUSION Frameworks were identified as the most appropriate approach to manage risks holistically in an organisation. Three different enterprise-wide risk management frameworks were discussed in this chapter. The three frameworks were developed by the public sector, private sector and a commission. Several roadblocks were identified that hinder the implementation of ERM in an organisation. These roadblocks include the inexact science of risk management, information technology and the responsibility and accountability of risk in an organisation. The goal of this chapter was to determine how ERM is applied within organisations. This goal was achieved by focusing on the framework ERM component as the best approach to implement ERM in the organisation. The first objective was achieved by discussing three ERM frameworks. All three frameworks included the seven generic components. Although technology plays an important role in ERM framework (it facilitates the integration, and aggregation of risk processes), there is no clear definition of its function in the frameworks. Information technology is used as the foundation for the ERM frameworks in order for it to function, but the frameworks do not provide for IT risk management at framework level. Three important roadblocks hamper the implementation of ERM frameworks; they were discussed to fulfil the second objective. These are the inexact science of risk management and IT and infrastructure. Information technology as an enabler of risk management has inherent risks. The frameworks discussed in the chapter regard IT as an important component of ERM but do not provide for its inherent risk on the ERM process. The third and probably the most noteworthy roadblock in ERM is risk accountability and risk responsibility. This chapter highlighted that information technology is used in addressing risks holistically in an organisation, even without organisations taking into consideration its inherent risks. Technology can and should be used to consolidate risk data and the technology should be flexible to be implemented in ERM frameworks. It is also clear that the strategic management of organisations has to meet the regulatory requirements imposed on them. They institute ERM frameworks which includes the risk management processes to be executed at tactical and operational level. However, as Chapter 3 and Chapter 4 indicate, the operational

131


level approaches produce extensive documents with risk information that is difficult to consolidate with requirements at strategic level. Chapter 6 and Chapter 7 highlights the fact that as with ISRM methodologies the ERM frameworks are continuous (section 6.3), proactive and systematic processes (section 7.2.1) that assist organisations in understanding (section 6.2), managing and communicating (section 7.2.1) risks from an organisational view. The goal of an organisation’s ERM strategy is to manage the organisation’s risks holistically in order to achieve its objectives (sections 6.5.1 and 7.2.1). ERM requires that a portfolio view of risks is taken (section 6.4 and 6.5.4). The next section addresses the issue of consolidating the results of operational ISRM approaches with the requirements of strategic level management.

132

C h a p te r 8

ORNMAN FRAMEWORK FOR ISRM METHODOLOGY EVALUATION

B

8.1. INTRODUCTION Chapter 2 provides terminology that assists in better communicating the results of operational level methodologies in Chapter 3 to strategic and tactical level management to meet the requirements as set out in Chapter 4. However, organisations have different structures and not straight linear structures of operational, tactical and strategic managerial levels. These structures require the risk information to be consolidated at a specific point; due to the hierarchical nature of organisations (see Chapter 5). This brought about the concept of addressing risks holistically in the organisation (Chapter 6) and it was found that the best approach is through frameworks (Chapter 7). The problem is how to effectively communicate the ISRM information to strategic management, irrespective of the organisational structure, ISRM approach or ERM framework. First it must be determined if the requirements of strategic management can be met by operational level instruments. It was established in Chapter 3 that the best approach to manage risks at operational level is through methodologies. Methodologies draw on the power of standards and guidelines (the other two approaches) to address risks. Chapter 3 discussed the ISRM methodologies that are employed at the operational level of an organisation to meet the requirements imposed on strategic management (see Chapter 4) [CFAC 92] [KING 02] [SOX 02] [INCA 99]. This leads to the increased importance of organisations employing adequate ISRM practices throughout the organisation as indicated in Chapter 7.

133

Bornman Framework For ISRM Methodology Evaluation

Currently there are no methods which assist organisations in determining which ISRM method is the best, in terms of IT governance recommendations, to be employed within an organisation. The goal of this chapter is to provide an instrument for determining which operational management level method can fulfil the requirements of ISRM at the strategic level of the organisation. This goal will be achieved through various objectives. The first objective is to determine a process for developing a comparative process for ISRM methods. The second objective is to develop a set of evaluation criteria to which the approaches can be compared. This will have to include the processes used to evaluate the methodologies. The third objective is to describe how the evaluation of the approaches is achieved and the final objective is to evaluate different approaches to illustrate how the evaluation process works. The chapter layout is guided by the chapter objectives. The first section discusses the approach followed in developing the approach to compare ISRM methodologies. This approach leads to evaluation criteria; the process of how the criteria were developed is discussed in the follow-up section. The development process consists of various processes which span three sections; these are discussed sequentially. The comparison framework is discussed along with the approach to evaluate methodologies against the criteria. Several methodologies are evaluated to illustrate the framework. The chapter concludes with a discussion on the limitations of the comparative framework. The next section discusses the approach selected in developing the comparative framework.

8.2. DEVELOPING AN APPROACH TO COMPARE ISRM METHODS The selection and implementation of an ISRM method is tasked to the tactical and, in some instances, the operational level of an organisation by the governing body of that organisation. The governing body, like the board of directors, is held accountable for any actions within the organisation [KING 02] [SOX 02] and “sponsors” the risk management requirements.

134


The strategic level recommendations and requirements can be regarded as the requirement criteria for evaluating different ISRM methods. ISRM falls within the IT governance scope [ITGO 03], and therefore an acceptable IT governance framework, method or approach should serve as the basis for the comparative approach. IT governance is the procedures, protocols, requirements and guidelines that recommend IT implementation within an organisation [COBI02 00]. Organisations must ensure that the ISRM methodology employed is in line with international best practice, as government regulations (see Chapter 4) can impact ISRM accountability and trading partners can require secure and reliable electronic communication. Although there are best practice frameworks and recommendations, a method must ensure that best practice is translated into processes

and

steps.

The

comparative

framework

must

embody

the

recommendations of the information security assessment process of an internationally accepted IT governance framework. A framework is selected as the appropriate approach as it is a flexible approach that can be implemented irrespective of organisational variables such as structure and resources (see Chapter 6 and Chapter 7). One internationally accepted IT governance framework is the CobiT Framework [COBI01 00]. CobiT serves as the starting point of the comparative framework as illustrated in Figure 8-1.

Figure 8-1: Comparative framework

CobiT is used as the foundation of the evaluation criteria. The evaluation criteria are placed into three groupings, of which the core risk management components

135


consist of several subgroupings that are the equivalent of the generic risk management processes discussed in section 2.5. CobiT is discussed in section 4.4.2, but certain aspects are revisited for clarity on why it was chosen as the basis of the Bornman Framework for ISRM Methodology Evaluation (BFME). CobiT can be used as a declaration of criteria for specific audit outcomes [ITGO01 00]. It is based on international best practice from various countries, including the United States of America, Europe, Australia, Canada and Japan; therefore it serves as a more than appropriate framework [COBI02 00]. Because of CobiT’s global implementation, it is a generic IT governance framework which enables it to be implemented in various industries. CobiT assists organisations in bridging the gap between business risks, technical issues and requirements of controls. CobiT consists of 34 controls, each addressing a specific aspect of IT governance. Although CobiT states that its goal is to reduce the overall IT related risks, the next section describes the process that was taken in selecting a single appropriate CobiT control.

8.3. SELECTION OF COBIT CONTROL In considering the CobiT domains and processes, each control has certain information criteria and required IT resources. The logical approach in selecting the appropriate information security controls is to base the selection on security goals or alternatively named information security requirements. Information security has three requirements (see section 2.2). They are confidentiality, integrity and availability (CIA) [SCHN 00] [PFLE 97]. All of the CobiT products provide a summary table. This table provides a quick reference guide to which controls address which information security requirements. The information criteria depicted in Table 8-1 (page 137) are from the CobiT summary table and rate the information requirements as either primary or secondary for each control.

136


Table 8-1: CobiT information criteria security requirements

P P P P

P P P P

Reliability

S P P

Compliance

P P P

Availability

Assess Risk Define and Manage Service Levels Manage Third-Party Services Ensure System Security Monitor the Processes Assess Internal Control Adequacy Obtain Independent Assurance Provide for Independent Audit

Integrity

Planning & Organization Delivery & Support Delivery & Support Delivery & Support Monitoring Monitoring Monitoring Monitoring

Confidentiality

Processes

Efficiency

Domain

Effectiveness

Information Criteria

P S S P S S S S

P S S P S S S S

P S S S S S S S

S S S S S P P P

S S S S S S S S

The control that is highlighted in Table 8-1 is the only CobiT control that lists confidentiality, integrity and availability as primary information criteria. There are other CobiT controls that regard one or two of the security requirements as primary or secondary, but the table lists all the controls where a primary or secondary value is assigned to all information criteria. The control that was identified to be focused specifically on ISRM is control Planning and Organisation O9 – Assess Risk. The Bornman Framework for ISRM Methodology Evaluation contains several criteria. The next section discusses the process taken in developing the evaluation criteria.

8.4. DEVELOPING THE EVALUATION CRITERIA In developing the comparative framework, the approach that was taken started with a review of the CobiT products. The Executive Summary, Management Guidelines, Framework, Implementation Toolset and Detailed Controls were reviewed. A single control was identified that directly addresses the assessment of risk. This control is the Planning and Organisation Control Nine (see section 8.3) Assess Risks, as it was the only CobiT control that lists the three primary information

security

requirements

(see

section

2.2)

as

primary

information/business requirements. A list of recommendations was compiled from the various areas within each CobiT product. Each product contains distinctive areas, for instance Considerations,

137


Enablers and Business Requirements. These distinctive areas were all considered in the development of the comparative framework. The list of recommendations was then logically grouped into three categories. The categories are based on the relative role of each criteria component to the other criteria components. The three categories have distinct purposes. They are: •

BFME core risk management components – These components are those criteria components that can be classified as part of the generic risk management processes. The processes can be further grouped into subgroupings such as identification, control and monitoring. The designation of criteria to this grouping was guided by the description of a generic risk management approach outlined in Chapter 2. These components were identified by organising the components in a flow chart according to the component prerequisites. Those components that did not form part of the risk management process flow or that were characterised as components of other components were regarded as supporting components.

Although the remaining criteria can be generally identified as a combination of processes, process considerations or attributes, they can be logically grouped according to their level of support provided to the core risk management components or particular grouping of core risk management components. The following two groupings have been identified: •

BFME process supporting components – Certain components are processes or process considerations that are unique to a specific grouping of the core risk management components. An example would be the balancing of controls which is unique to the control phase of the generic risk management approach.

•

BFME risk management supporting components – Seven of the identified criteria are supportive of all of the core risk management components. These supporting components provide processes or considerations for all of the processes. For instance, management input is considered a risk management supporting component as the input from management will provide buy-in and strategic or tactical support of all the processes.

138


Note that the comparative framework focuses on recommendations at business level rather than at operational or technical recommendations. CobiT is an extensive document with control objectives that address different IT areas within an organisation. It would be possible to develop criteria for other IT areas, for instance procurement, by basing them on the different CobiT objectives. This section discussed the criteria groupings; however, each grouping has several detailed criteria under them. The next section discusses these criteria in each grouping.

8.5. DETAILED CRITERIA This section provides detailed descriptions of each component of the BFME. Some of the components that were identified were duplicated in several of CobiT’s products. These duplicates were reconciled and are represented by a single component. The component descriptions are grouped according to the three categories illustrated in Figure 8-1; they are BFME core risk management components (section 8.5.1), BFME process supporting components (section 8.5.2) and BFME risk management supporting components (section 8.5.3). The first grouping that is considered is the BFME core risk management components.

8.5.1. BFME Core Risk Management Components The components listed below have been identified as the BFME core risk management components as they form part of or extend the generic risk management method explained in Chapter 2. There are some components that are individual processes while others can be grouped into subgroupings.

139


Figure 8-2: Core risk management component layout

Figure 8-2 provides a graphical representation of the component layout of the BFME’s core risk management component grouping. Each of the grouping’s components are discussed in the corresponding numbered sections. 8.5.1.1. Defined Risk Tolerance Profile

Each organisation is willing to accept a certain level of risk which is indicated by the risk tolerance profile. The profile provides an indication of the actions that should be taken with regard to risks, for instance which level of risk should be accepted or managed. Risk tolerance indicates the relative affinity of an organisation to accept risks. This action should be decided by the board of the organisation [KING 02]. Risks as well as the ability of an organisation to accept risks are ever-changing. The environment in which organisations exist is very dynamic and organisations have to adapt, and this might result in organisations’ changing their risk limits. Therefore risk limits have to be updated when appropriate. When an organisation changes its risk limits, the risk management programmes of the organisation will have to reflect the new limits. Although management can specify their risk acceptance without a formal tolerance measurement process, it is recommended that a process be put in place to examine the risk acceptance capacity of the organisation. The results of this process will form part of the risk tolerance profile of the organisation.

140


8.5.1.2. Risk Action Plan

A risk action plan defines the risk strategy of an organisation [KING 02]. An organisation generally has four actions that it can take with regard to risk. They are accepting, avoiding, transferring or controlling/managing the risk through costeffective controls. The risk action strategy of an organisation is determined by the risk tolerance profile. The ISRM method will have to employ a strategy that will avoid, mitigate or accept risks [COBI04 00]. Although there are four actions that can be taken (see section 2.5.3), CobiT only refers to three. The risk action plan is derived from three different sources: the risk tolerance profile, the identification process and the risk measurement process. The risk tolerance profile provides the parameters of what is acceptable or not. The identification process provides detail on the identified risks, while the risk measurement provides a relative indication of which risks pose the greatest threat to the organisation. These three inputs provide enough data for management to formulate a risk action plan on how to address the identified risks. 8.5.1.3. Risk Management Processes

Risk management, irrespective of organisational level or industry, follows certain risk management steps. Various risk management methods have different steps that vary in number and scope. However, when considering the Plan, Do, Check and Correct (PDCC) processes described within CobiT, generic risk management steps can be identified. They are identify, measure, control and monitor. The remaining evaluation criteria are defined within the subgroupings of the processes. a) Identification The identification process is the first subgrouping within the core risk management components. This subgrouping contains the identification processes of what are considered to be the essential risk elements [CRAM01 96] [ALBE 03]. Although some of the components that make up the identification process were discussed in detail in Chapter 2, they are briefly addressed here. •

Assets – Organisations consist of various assets that are utilised in fulfilling their goals and objectives. These assets can be grouped into tangible and intangible assets [SAIC 02]. It is important for risk management that a value be assigned to an asset [CRAM01 96] [IST 03] [ALBE01 00]. According to

141


financial guidelines AC 000 [FAEL 99] [SAIC 02], an asset can only be recognised in the financial statements of an organisation if the asset has a cost or value that can be measured reliably. See section 2.5.2 on measurement values for assets. •

Threats – A threat is an event that can have an effect on an organisation. Threats can be grouped according to their source, for instance human, accidental, technical failure or nature (see section 2.3.2).

•

Vulnerabilities – A vulnerability is a weakness inherent to an asset that can be taken advantage of by a threat [STON 01] (see section 2.3.3).

•

Consequences (impacts) – If a threat realises, it will have an impact on an asset. For instance, if a computer server does not function, employees might not be able to fulfil client requests. Impacts do not only have direct consequences on the asset in question but can have an effect on other areas of the organisation. To extend the above example, if the clients’ requests cannot be fulfilled, then clients will look for alternative vendors and this could result in lost future revenue for the organisation.

•

Cause and effect relationships – During the risk identification step the causes of the risks will have to be related to the effect that they could have on the organisation. In other words, the effects that a risk can have on the organisation will have to be linked or mapped to the cause. Cause and effect relationships assist management in better determining the actions to be taken.

•

Likelihood of threat – Likelihood can be defined as the qualitative description of probability or frequency [ASNZ 99]. There are always threats that could affect an organisation, but there has to be a likelihood that the threat will realise. If an organisation is situated in a landlocked country the likelihood of a typhoon (natural disaster) destroying communication infrastructure is relatively low. By determining the likelihood of threat organisations can determine the greatest risks to their assets. Some ISRM methods such as OCTAVE do not take likelihood into consideration [ALBE 01] [ALBE 03].

•

Safeguards – Safeguards are synonymous with controls. They are actions taken to reduce the impact or the probability of a risk. The safeguards can 142


include technical control or policies and procedures. Controls can be implemented to address identified risks. However, risk management is a cyclical process and after the initial cycle controls will be in place. The existing safeguards can be identified for each risk. b) Risk Measures Once the risk components have been identified, the risk assessment team or leader has to provide a way in which each risk’s severity can be unambiguously communicated to the relevant parties. In order to accomplish this values have to be assigned to the risk. The format of the measure values will have to be documented and communicated in a predefined format or the formats that have been applied during the risk identification process. Two general formats of measure can be used. They are quantitative and qualitative values (see section 2.5.2). •

Quantitative risk measures can be any numerical value, for instance a cash value, server down time or loss of revenue.

•

A qualitative risk measure is a relative value assigned to a risk, for instance high, medium or low. These measures were discussed in a previous chapter.

When measuring risk the values that could be assigned to a risk are the result of utilising the identified components such as the probability or frequency of a threatexploiting vulnerability. In the case of quantitative measure, the value that is assigned to the risk is a relative value. The relative value is used in determining which risk requires attention in relation to predefined parameters. Some methods which utilise software, for instance CRAMM, do internal calculations of risks of which the user is not aware [INSI01 03]. However, other methods have a transparent approach to risk calculation (see Chapter 3). c) Control Once the risks have been identified and a value assigned to them, management has to address these risks according to the risk action plan. According to CobiT, there are three control activities. They are:

143


•

Risk ranking – Risk ranking is the process in which the risks are ranked according to the organisational specification. The ranking of risks can be either quantitative or qualitative. It is the logical arranging of which risks to address first. These risk ranking values should be in the same format as the risk values [IST 03].

•

Control integration (control conflict management) – Some controls might conflict with others, for instance a firewall that blocks all but Internet-related communication ports and causes a proprietary communication program to malfunction, which in essence is a denial-of-service risk. The above example illustrates the firewall control that assures that confidentiality of information will have an impact on other areas of the organisation’s network by not providing access to important assets. A process to identify and manage any conflicting controls must be present.

•

Control purpose communication – The purpose of the controls has to be communicated to relevant parties, such as employees. For instance, the need for passwords will enable employees to have control over the use of information stored on the workstation. According to Tudor [TUDO 01], the security awareness and training are perhaps the most significant elements in an information security programme. Each employee is responsible for acting according to the enterprise’s risk culture and he or she has to be consistent within the risk culture.

d) Monitor When organisations implement controls they make an investment in their risk management programme. Organisations want a return on their investment and to ensure that their investment provides a return they have to ensure, on an ongoing basis, that the controls and the programme are effective and efficient. This is accomplished by monitoring various aspects of the programme. •

Facilitate the monitoring of controls – The cost-effective and efficient controls that are implemented will have to be monitored. Monitoring of the controls can include automated monitoring. Facilitating the monitoring of controls ties in with the objective third-party validation of the implemented controls. If an investment is made in certain controls to address risks,

144


management and stakeholders will have to be assured that the controls are effective and efficient. A control is effective if it addresses the event as it should and efficient when it fulfils its function without utilising excessive resources. •

Incident reporting processes – Incidents can constitute negative or positive events. For instance, a hacking attempt that was prevented by an implemented control can provide just as much information about the risk action plan as a successful hacking attempt. The incident reporting process has to be included in the security awareness and training programmes as the employees will have to know how to act when an incident occurs [TUDO 01]. Although reports can be generated by automated controls, the results/contents of the reports will have to be conveyed to the appropriate parties.

This section discusses the evaluation criteria that correspond to the generic risk management processes. Some criteria were found to support these generic risk management processes, and they are discussed in the next section.

8.5.2. BFME Process Supporting Components Two of the BFME core risk management component groupings have supporting components. These components add value or support the results and processes within the core risk management groupings. The two groupings that have supporting components are identification and control. The designations of the BFME core risk management groupings provide identification for the supporting components. The names of the BFME supporting component groupings are derived from their core risk management grouping and their function. Their names are BFME identification process supporting components, and BFME control process supporting components. 8.5.2.1. BFME Identification Process Supporting Components

The identification process supporting components support the components within the identification grouping of the core risk management components. The two BFME identification process supporting components are:

145


•

Different kinds of risks – A distinction will have to be made between the different kinds of risks. Kinds of risks refer to the groupings such as regulatory, technological and continuity. Kinds of risks are also deduced from the various threat sources, for instance internal-malevolent, externalmalevolent, accidental, natural and technical failure (see Chapter 2).

•

Identification considerations – IT and its security component do not exist in a closed system. They are affected by and affect other items and events, so when identifying risk there are other areas that have to be considered. CobiT regards the following risk areas as important: business, regulatory, technology, trading, partner and human resources [COBI01 00] [INCA 99].

8.5.2.2. Control Process Supporting Components

The control process supporting components support the components within the control grouping of the BFME core risk management components. •

Return on investment (ROI) calculations – ROI is a calculation that indicates to management the “usefulness” of their investments. ROI provides an organisation with an indication of the return the organisation is generating as a result of a certain level of investment made. ROI calculations can to an extent assist management in determining the cost-effectiveness of the information security investments made. Stevens [STEV 03] has highlighted a term ‘ROSI (return on security investment)’, which is the potential loss reduction divided by the cost of the controls. However, IT risks are unfortunately of such a nature that quantitative measures are rarely possible.

•

Control balance – Different types of controls can be implemented. Figure 8-3 indicates the progressive use of the different types of controls. Costeffective controls should be balanced between the following four types:

Figure 8-3: Control balance time line

146


The four types of controls indicated in Figure 8-3 are discussed below. ♦ Preventative – Preventative controls are those controls that have been implemented to proactively address risk by attempting to reduce the impact or probability of a risk before it realises. An example of this type of control is a firewall with predetermined communication rules. ♦ Detective – A well known detective control is intrusion detection systems. These systems detect unauthorised access to a system, for instance hackers. Detective controls are controls that detect the “occurrence” of a risk. ♦ Corrective – Corrective controls are controls that are activated after the fact. For instance, if a hacker gains unauthorised access to system a corrective control could be tracing the origin of the attacker and taking steps to limit access by increasing the firewall rules or disconnecting communication channels for a limited time. ♦ Recovery – Once a risk has realised, the organisation is faced with dealing with its consequences. For instance, if a natural disaster destroyed an organisation’s information centre, the recovery controls will include the preventative controls that enable backups of information, and the controls to recover the information and provide it to departments of the organisation that require it to function. •

Acceptance of residual risks – Organisations cannot always afford to address all risks; the remaining risk is referred to as residual risk (see Chapter 2). The residual risk also includes the risks that the organisation is willing to accept according to its determined risk appetite or tolerance. A process has to be in place to formally accept the residual risks. This process will have to include any measures the organisation takes to address the risks. Residual risk is the risk remaining when controlling measures have been implemented against the gross risk [STEV 03]. The risk tolerance profile that was defined as a core risk management component which included determining the acceptance risk level. This component addresses the formal acceptance of those remaining risks and forms part of the control

147


process supporting components because it is advisable to implement minimum controls to either address or monitor those risks. •

Third-party objectivity – Organisations employ the services of independent third

parties

to

verify

specific

functions

within

the

organisation.

Organisational risk controls and processes will have to be such that they assist with any third-party validation. According to the United States Federal Sentencing

Guidelines [STEV 03],

there

are lighter

penalties

for

organisations that have adopted and followed effective compliance programmes. These programmes have to be audited by an objective party to verify the compliance status of an organisation. Third-party objectivity is most often supported through formal documentation of implemented controls and monitoring documentation. This section discussed several evaluation criteria that support specific BFME core risk management components. The next section discusses components that support all the BFME core risk management components.

8.5.3. BFME Risk Management Supporting Components The risk management supporting components encompass the whole risk management processes. When evaluating a method against these components, the method as a whole should be taken into consideration. For instance, the defined risk ownership and responsibility should be evaluated for each BFME core risk management component and the BFME process supporting components. •

Defined risk ownership and responsibility – Risk management requires a specific owner (see section 7.3.3). This owner will be responsible for all the processes and actions comprising the risk management method. Certain organisations require a risk committee to be put in place, due to the size of the organisation, to be responsible for specific areas of risk management, but a single individual should ultimately be responsible within an organisation. A distinction will have to be made between risk responsibility and risk accountability. According to the King II Report [KING 02] and the Sarbanes-Oxley Act [SOX 02], the board is accountable although the responsibility can be delegated down within the organisation (see Chapter 6 and Chapter 7).

148


•

Risk management improvement project – ISRM methods must include improvement projects. The improvement projects refer to the continuous evaluation and improvement of the risk management processes. Some methods employed in improving risk management are through workshops and brainstorming sessions. Since the risks that can affect an organisation are ever-changing, organisations have to be vigilant for any changes in the environment as well as improve the identification, measurement, controlling and monitoring of the risk management process. The improvement projects of risk management can be facilitated by utilising maturity models, for instance the levels described in CobiT’s Management Guidelines [COBI03 00]. Feedback on the improvements is crucial. Once shortcomings in the risk action plan have been identified, they have to be resolved. Procedures will have to be communicated to employees on how to report shortcomings in the organisation’s risk programmes. The feedback should be used in improving the risk programmes of the organisation and a feedback structure should be in place to ensure that improvement projects are executed and that an indication is given of whether or not they are successful. Feedback is essential to ensure that the necessary actions are taken.

•

Policies and procedures – Policies and procedures are the formal documentation of the organisational risk culture. These policies and procedures will dictate how risks should be managed at different levels within the organisation. The risk policies and procedures are usually tasked to tactical and operational level by strategic management. The policies and procedures represent the risk culture and affinity to risk of the organisation. Policies will indicate the risk “path” the organisation wants to take [TUDO 01]; for instance, all employees will protect confidential information by using passwords for workstations. Procedures indicate the exact steps that employees need to follow [TUDO 01]; these procedures will usually be at a technical- and system-specific level. An example of a procedure will be “Click on the ‘Select new password’ button and enter a new password with a minimum

of

eight

characters

that

should

include

numerical

and

alphanumerical characters e.g. ‘MyPass4321’”.

149


•

Support documents – Support documents are required to assist in the thirdparty assessment of the risk management process as well as facilitation of risk monitoring, setting of risk limits and evaluation of control effectiveness. Other support documents will also have to serve as input for the risk management methods; these documents include business risks, operations and IT risk assessment documents. Any information gathered regarding risk identification, measurement, control implementation, monitoring, processes, procedures and protocols must be documented and maintained in a structured manner. During risk management a great deal of data is collected and various documents produced as output for different processes. These documents and data will have to be maintained to reduce work redundancy and incorrect risk assessments and to ensure that the correct risk actions are taken, among other things. The risk information will be used when organisations have to conduct a risk audit and when the risk management process is repeated.

•

Reassessments – Risks are ever-changing and new information security risks are introduced on a daily basis [INCA 99]. Therefore, structured risk reassessments will have to be done. The methods will have to be able to comply with or recommend a reassessment schedule. Updates of risk limits should form part of risk reassessment. Management will have to ensure that reassessments are catered for. The corporate governance regulations such as King II recommend an annual revision of risk management practices and risk limits.

•

Global and system level assessments – An implemented ISRM method will have to assess risks at system and global levels. System level is the hardware and software level within an organisation, while global level includes assessments that are not directly attributed to the system. Global level will include the effect humans and external elements can have on the system. By referring to the global and system level assessment, not just specific threat sources are singled out, for instance a technical failure that belongs to the system level. The system level assessment will take into consideration all the threat sources at system level, and global level assessment indicates other non-system related impacts and effects they will

150


have on the organisation. For instance, a risk of a virus deleting important proprietary information from a server is a system level threat, while the impact and real effect is the loss of business due to the inability to utilise an asset. •

Management input – Management requires timely and accurate information to direct the organisational strategies in the long run. Therefore, the ISRM method will have to facilitate the input of top management. Management is responsible and accountable for risk management programmes within their organisation. They require that any risks that could impact their medium- to long-term strategy be communicated to them. Therefore, management has to provide input into the planning, managing, controlling and monitoring of the risk management programme. By providing input during all phases of the risk management programme, they can be assured that all the relevant actions are completed and that the relevant information is communicated to applicable employees and management structures.

This section discussed all of the components that make up the evaluation criteria of the Bornman Framework for ISRM Methodology Evaluation. However, having the evaluation criteria only provides elements to which methods can be compared. The next section discusses the approach that has to be followed to evaluate methodologies against the evaluation criteria.

8.6. COMPARISON PROCESS In the previous section the components of the evaluation criteria were discussed. These evaluation criteria are a list of criteria with which a methodology has to comply. This section discusses the process that is followed in evaluating the methodologies against the list of criteria. To provide values that can be used to compare methodologies, an evaluation scale has to be developed. This evaluation scale has to take into consideration the flexibility of the different methodologies. The evaluation of methodologies against the criteria could take on various formats. The high level formats can be either qualitative or quantitative. Quantitative values would be ideal; however, each of the criteria has a qualitative description which

151


describes what is recommended for each criterion. Therefore, a qualitative approach with corresponding/relative quantitative values is applied. Qualitative values are used in conveying the alignment of methodologies with the criteria as they are less time-consuming (see section 2.5.2). The evaluator has to make an assessment of the methodology and assign a scale value according to the impression of the methodology against the criteria. Modern risk management methodologies have been developed to be applicable in numerous unique environments and therefore feature a certain flexibility in their application. This flexibility or adaptability of the methodologies has to be considered in the evaluation process. There is an inverse relationship between the compliance of a methodology with the evaluation criteria and the need for the method to be adaptable. For instance, if a method complies fully with the criteria there is no need for the method to be adaptable in order to comply, and if there is no compliance the method has to feature a high level of adaptability in order to comply. However, a more detailed compliance scale will provide more comparative information. The example above only refers to two states: high and none. The scale that is used in the evaluation of the methodologies is none, low, medium and high. This qualitative scale is applied in the evaluation of a method’s compliance and adaptability values. Figure 8-4 (page 153) provides a graphical representation of the inverse relationship between compliance and need for adaptability of a method. The figure uses the four-level scale indicated above.

152


Inverse Relationship of Compliance and Need for Methodology Adaptability

None

Low Medium High

Compliance Figure 8-4: Compliance and need for adaptability inverse relationship

The figure illustrates the corresponding inverse need for adaptability values of all the compliance scale values. Figure 8-5 provides an example of a single inverse value of compliance and need for adaptability. It illustrates that the medium compliance of methodology has a low need for adaptability in order to be fully compliant with the requirements of the BFME.

Determining Required Method Adaptability from Compliance

yti li ba tp ad A ro F de e N

hg i H m ui de M w oL en o N

None

Low Medium High

Compliance Figure 8-5: Example of inverse scale

This section discussed an appropriate scale to evaluate ISRM methodologies against the BFME evaluation criteria. The scale was used in the illustration of the inverse relationship between methodology compliance and the need for adaptability. The next section brings the evaluation criteria together with the evaluation scale.

153


8.7. APPLICATION OF SCALE The purpose of applying the scale during the evaluation process is to determine a single value that can be used to compare ISRM methodologies. In order to determine this single value the scale has to be applied to every evaluation criteria component in each of the criteria components outlined in 8.5. Three values have to be determined by the evaluator in order to determine the final compliance value. The values are: a) Initial compliance value – The initial compliance value is the evaluator’s impression of the unadapted methodology’s compliance with the particular evaluation criteria component. The scale values are discussed in section 8.6. b) Method adaptability – The evaluator assigns a scale value on the impression of how adaptable the method is to complying with the particular evaluation criteria. For instance if a method allows for the inclusion of additional information security components such as Donn Parker’s secondary components (see section 2.2.4), the adaptability of the methodology is high (qualitative scale value of 3). c) Need for adaptability – The need for adaptability is determined by using the inverse relationship discussed in 8.6 and illustrated in Figure 8-4. As the figure illustrates, medium compliance = low need for adaptability. These three values are entered into a table. Table 8-2 provides an example of the three values (compliance, adaptability and need for adaptability). Table 8-2: Example of evaluation process Core risk management components

Initial compliance

Method Adaptability

Need for adaptability

Final compliance

Defined risk tolerance profile

None

0

Low

1

High

3

1

Risk action plan

Low

1

Low

1

Medium

2

2

The final compliance value is calculated by adding the compliance value to the lowest value of adaptability or need for adaptability. This is illustrated by the “risk action plan” evaluation criteria component in Table 8-2. Low (1) + Low (1) = 2. The reason for using the lowest value is that there is only a certain level of adaptability required to meet the requirements (see section 8.6). A ceiling is placed on the

154


adaptability value of a methodology either by the methodology’s inherent adaptability or the required level of adaptability according to the scale (see section 8.6). Once final compliance values have been determined for all the evaluation criteria components, they are added together to determine the methodology’s final compliance value. This value is then used to compare methodologies with one another. Figure 8-6 provides a graphical representation of how the final compliance value is calculated. The above steps (a to c) are indicated in the figure.

Figure 8-6: Final Compliance Calculation Steps

This section discussed the process of applying the scales, which are discussed in section 8.6, to the BFME evaluation criteria to determine a final compliance value for a methodology. The next section discusses the application of the complete framework.

8.8. BFME IMPLEMENTATION The purpose of the Bornman Framework for ISRM Methodology Evaluation is to derive comparative values of methodology compliance for a set of evaluation criteria. The criteria were developed from an acceptable strategic level ISRM approach. These evaluation criteria were evaluated against the regulatory requirements of the King II Report, and the evaluation results are tabulated in

155


Appendix B. This evaluation against the King II Report indicates that the evaluation criteria comply with regulatory required risk management. Gather methodology information

Determine need for adaptability

Methodology

Evaluate methodology adaptability

Evaluate methodology compliance Bornman Framework for ISRM Methodology Evaluation

Evaluation scale Determine final compliance value

Determine methodology total compliance value Evaluate total compliance values Figure 8-7: BFME implementation

To evaluate methodologies within the BFME there are specific steps that have to be followed, as illustrated in Figure 8-7. These steps are outlined: 1. Gather methodology information – As much information as possible about various methodologies has to be gathered. The information can consist of various types of material, for instance software programs, user manuals, promotional information, consultations or methodology brochures. 2. Evaluate methodology compliance – The information that is gathered should be studied and the evaluator’s impression of the methodology’s compliance should be noted in the BFME table. 3. Evaluate methodology adaptability – While the methodology’s material is evaluated for compliance the evaluator’s impression on the methodology’s adaptability on a particular evolution criteria component should be noted in the BFME table. 4. Determine need for adaptability and final compliance values – The values that are determined in steps 2 and 3 should be used in conjunction with the inverse scale illustrated in Figure 8-4 to determine the final compliance value of the evaluating methodology.

156


5. Determine methodology total compliance value – Add each final compliance value together to determine the methodology’s total compliance value. 6. Evaluate total compliance values – The total compliance value is a value that can be a maximum of 84 (28 criteria x maximum value of 3). This maximum value can be used to calculate a percentage compliance value. These steps were used in the evaluation of several ISRM methodologies. The evaluation of the different methodologies is discussed in the next section.

8.9. ISRM METHOD EVALUATION RESULTS Numerous methodologies could have been evaluated, but only three ISRM methods were identified. Only three methodologies were selected in order to provide an example of the evaluation of diverse views. No clear set of criteria was established in the selection of the three ISRM methods. However, some aspects were considered such as the availability of the products, how current the methods were, whether or not the method could be applied to generic information systems and whether or not the product had a wide implementation base. The methodologies are the CCTA risk analysis and management method (CRAMM) (see section 3.6.1), the CORAS methodology for model-based risk assessment (see section 3.6.3) and the operationally critical threat, asset, and vulnerability evaluation (OCTAVE) method (see section 3.6.2).

These three

methods were discussed in Chapter 3. The majority of ISRM methods are proprietary with very little publicly available information apart from marketing literature. Often organisations do not have the available capital to purchase different ISRM methods in order to evaluate them. Therefore, the evaluation process was based on publicly available documentation obtained through printed material, presentation software, demonstration software or Internet published material. The material was reviewed within the comparative framework against the criteria as indicated in Appendix A. Each of the evaluated ISRM methods has its strong and weak elements. This section will describe the strong and weak areas of each method as has been highlighted by the comparative framework outlined above.

157


8.9.1. CORAS The information used for the evaluation process is part of the CORAS risk assessment platform which utilises XML (Extensible Mark-up Language) and is a Java

application

server-based

platform.

The

platform

includes

all

the

documentation required to install and operate the software, as well as detailed documentation regarding the CORAS methodology. The CORAS methodology documentation is separated into three levels: basic, decision and full. The documentation of each of these three levels was examined during the evaluation process. There are only three components of the BFME core risk management components that CORAS does not comply with, as indicated in Appendix A. They are the identification of existing safeguards, communication of control purpose and incident reporting. Although CORAS does not comply with these components, the adaptable nature of CORAS is such that the implementation of these components is easy. With regard to the process supporting components, the only subgrouping that CORAS is lacking in is the control subgrouping. CORAS has a low compliance for balanced control processes and no processes for residual risk controls. CORAS does not have risk management improvement projects support. However, all the shortcomings of CORAS are offset by an inherent ability to be easily adapted to facilitate change. As indicated in Appendix A, the CORAS methodology scores a compliance value of 74% with a need for adaptability value of 25% which, added together, provides a potential 99% compliance with the evaluation criteria.

8.9.2. OCTAVE Information used during the OCTAVE evaluation process was obtained from published literature [ALBE 03] and the OCTAVE criteria as published by the Carnegie Mellon University and CERT [ALBE 01]. Looking at the BFME core risk management components, OCTAVE scores a medium compliance with the defined risk tolerance profile. This shortcoming is easy to correct, however. There is less compliance with the subgrouping of

158


process within the BFME core risk management components. OCTAVE does not identify the likelihood or frequency of a risk occurring. This is a deliberate omission within OCTAVE; however, OCTAVE provides guidelines on how to implement this within this method. OCTAVE is a risk assessment methodology. Therefore the non-compliance with monitoring and minimum compliance with the controlling process reduces the total compliance value of OCTAVE. These non-compliance components also have a relatively low to medium capacity to be adapted or added to the method. Along with this non-compliance of the control and monitoring core risk management components, OCTAVE does not comply with the BFME control process supporting components. There is a low to medium adaptability of the method to accommodate these components. As with CORAS, OCTAVE does not comply with the risk management improvement project evaluation component. As indicated in Appendix A, OCTAVE achieves a 69% compliance value and a 21% need for adaptability value, which results in a possible 90% compliance value.

8.9.3. CRAMM CRAMM’s evaluation information was based on the CRAMM V Walkthrough and Overview Flash Presentation provided by Insight Consulting [INSI01 03]. CRAMM does not have a defined risk tolerance profile and has a low adaptability rating associated with it. The identification process grouping of the core risk management components is CRAMM’s strong point; CRAMM achieves high compliance levels with all the identification components, as indicated in Appendix A. Regarding the remaining core risk management components, the control purpose communication component rates low along with the non-compliance with the monitoring grouping, which indicates that CRAMM focuses on risk identification, measurement and control proposal and not the complete risk management process. The BFME supporting components, both process and risk management, provide interesting results. The identification process supporting components have low

159


and medium values; this is due to the software package with predefined threat and vulnerability listings. The control process supporting components rate medium to high and, combined with required adaptability value, provide maximum compliance values for this grouping. Risk management supporting components have only four components that do not achieve a high compliance rating. They are global and system level assessment, management input and risk management improvement projects, all due to the technical risk assessment nature of CRAMM. A medium rating is assigned to the defined risk ownership and responsibility component. As indicated in Appendix A, CRAMM achieves an overall 73% compliance value. This, coupled with a 19% need for adaptability value, provides CRAMM with a respectable 92% possible compliance level. This section discussed the evaluation results of various methodologies. However, the framework has some limitations. These limitations are discussed in the next section.

8.10. BFME LIMITATIONS The BFME framework and processes taken to evaluate ISRM methods form a structured approach which is based on best practice and complies with regulatory requirements. However, there are some limitations to the framework that have to be taken into account. •

ISRM methods such as OCTAVE have the ability to be customised to organisational needs. This ability can result in certain processes being excluded during the implementation of that particular methodology. The comparative framework does not take into consideration the customisation of a methodology. A distinction has to be made between customisation and adaptability. Customisation refers to the complete restructuring of the methodology. In the case of OCTAVE, the methodology evaluation is based on the OCTAVE methodology and not the OCTAVE criteria. The OCTAVE criteria can be used to create an approach based on recommendations that is dissimilar to the OCTAVE methodology. The BFME focuses on methodologies and not customisation approaches.

160


•

When organisations undertake ISRM, certain business and practical considerations are taken into account. These considerations include the estimated cost, time and resources required. The comparative framework and processes do not take these considerations into account as they are very subjective and differ between organisations.

•

The comparative framework and processes do not take into consideration the organisation’s scope statement and motivation for implementing ISRM. For instance, organisations might want only to identify and measure their risk without controlling or monitoring it.

•

According to CobiT, the risk strategy of an organisation should be in terms of avoidance, mitigation and acceptance. Another consideration, which CobiT does not refer to, could be the transfer of a risk. Transferring risk refers to shifting the burden or responsibility of a risk to a third party [ASNZ 99]. The transfer of risk is usually when the likelihood of a threat is low and the threat’s impact relatively high.

8.11. RESEARCH VALUE Organisations can use the developed framework to align their methodologies according to requirements of IT governance and corporate governance. This alignment is possible due to the framework’s compliance with CobiT and the King II Report. If organisations have not yet implemented an ISRM methodology at operational level, they can use the framework to evaluate methodologies or develop their own based on the framework. The scale that was developed to evaluate the methodologies takes into account the adaptability of a methodology. This scale can be used within other evaluation frameworks where qualitative evaluation is used and adaptability considerations required. The process followed in the development of the BFME can be implemented on other controls of CobiT to create other frameworks. These other frameworks can focus on other IT areas, for instance procurement or software development.

161


8.12. CONCLUSION This chapter presents a comparative framework based on the internationally accepted CobiT IT governance framework. Because the comparative framework is based on this internationally accepted IT governance framework, it is an objective method of comparing different attributes of ISRM methodologies. The comparative framework also provides an indication of whether or not an ISRM method is in line with IT governance recommendations. The comparative framework was used to evaluate three current ISRM methods. These methods were CRAMM, OCTAVE and CORAS. Subsequent to the evaluation, each of the methods revealed its strengths and weaknesses. Important aspects regarding ISRM methods came to light during this evaluation. Further research should be undertaken into striking a better balance between risk controls and developing better incident reporting processes and control integration management within ISRM methods. This comparative framework enables organisations to evaluate various ISRM methods without purchasing the methods. The comparative method provides organisations with a means of comparing ISRM methods based on published and/or noncommercial information and ensuring that their methods are in line with IT governance recommendations. The practical illustration of the comparative framework highlighted that there is still research potential in aligning ISRM methods with IT governance best practice recommendations. The goal of this chapter was to provide an instrument for determining which operational management level method can fulfil the requirements of strategic ISRM. This goal was achieved by developing the Bornman Framework for ISRM Methodology Evaluation. The BFME provides a set of criteria, which is based on a strategic management ISRM approach and which complies with strategic management requirements. The first objective was to determine a process for developing a comparative process for ISRM methods. This objective was achieved by outlining the process to develop a framework to evaluate methodologies. The second objective was to develop a set of evaluation criteria to which the approaches can be compared. This goal was achieved by discussing the set of criteria and the groupings that were developed from the CobiT set of products. The third objective was to describe how the evaluation of the approaches is achieved and the final objective 162


was to evaluate different approaches to illustrate how the evaluation process works. The framework’s implementation was discussed as an illustration of how it works and three different methodologies were evaluated. This chapter discussed an approach to determine which operational level ISRM methodology can provide risk information required for strategic management. It was found that the methodologies do not provide the required risk information that is essential to corporate and IT governance compliance. Therefore there is a need for a framework that will assist in the communication of risk information, which is either compliant or not, and originates from the implemented ISRM methodologies. The next section addresses the problem of how to communicate the required risk information.

163

C h a p te r 9

ORNMAN FRAMEWORK FOR ISRM INFORMATION COMMUNICATION

B

9.1. INTRODUCTION The previous chapter discussed the Bornman Framework for ISRM Methodology Evaluation (BFME) which enables an organisation to evaluate and select a methodology that can deliver on strategic ISRM requirements. If a methodology can provide the required information, the format in which the information is communicated is still limited by the methodology’s approach. These information communication processes or mediums are usually extensive documents that are unique to the methodology. This can overwhelm strategic management and they lose interest. Different approaches in the various SBUs, implemented tools and applied methodologies make the process of consolidating the ISRM information difficult. An approach to communicate the relevant operational management risk information to strategic management is required. The goal of this chapter is determine an approach that would provide management and the board with an overall representation of the organisation’s ISRM status by communicating relevant risk information. There are various objectives that have to be fulfilled on the way to achieving the goal. The first objective is to determine the best approach that can deliver on the risk information requirements. The second objective is to determine what information is necessary to be communicated. The third objective is to determine how the information can be communicated. The chapter’s layout is guided by the objectives of the chapter. The first section discusses the path taken to identify the ISRM communication approach. The second section discusses the approach that was developed to

164

Bornman Framework for ISRM Information Communication

facilitate better ISRM communication. The final section discusses the components that enable the approach to communicate ISRM information effectively. The next section discusses the approach that is taken to identify the ISRM communication approach.

9.2. IDENTIFY ISRM COMMUNICATION APPROACH The requirements of the strategic management level were determined in Chapter 4. These requirements were used to develop a comparative framework referred to as the Bornman Framework for ISRM Methodology Evaluation in Chapter 8. The BFME consists of several evaluation criteria against which methodologies can be evaluated in order to determine if they can provide relevant risk information. The BFME indicates what strategic risk information is needed. Therefore the logical approach in determining a risk information communication approach should be based on the evaluation criteria of the BFME. This logic leads to the development of a framework as the risk information communication approach. The next section evaluates the BFME as a viable foundation for the Bornman Framework for ISRM Information Communication (BFIC).

9.3. THE BFIC The communication framework is referred to as the Bornman Framework for ISRM Information Communication. This framework is based on the Bornman Framework for ISRM Methodology Evaluation (BFME), which consists of various evaluation criteria that are grouped into three groups. The evaluation criteria of the BFME form the basis of the BFIC indicators. The BFIC comprises indicators that provide management with relevant information regarding the organisation’s risk management programme. These indicators must be able to adequately communicate the risk status and goals of management and the board. The indicators also have to be based on best practice and conform to requirements set by government regulations.

165


The goal of the BFIC will be achieved if the framework can address the following four objectives: 1. Assist in communicating risk actions throughout the management structure (see Chapter 5). 2. Provide an overview of the information security risk status of the organisation at any given moment (see Chapter 6), as it should be in line with the King II Report. 3. Provide management with an overview of risk responsibility and accountability [KING 02]. 4. Indicate actions taken to address the information security risks that the organisation faces [KING 02]. The following section addresses each of the BFME criteria groupings as indicator groupings of BFIC.

9.3.1. BFIC Core Indicators The BFME core risk management components will serve as the core indicators of the BFIC. The BFIC core indicators (BCI) are the logical indicators of the outputs delivered from the generic risk management processes. For instance, the risk tolerance profile will provide information on the level of risk the organisation is willing to accept. The BFIC core indicators consist of 15 individual indicators. These 15 indicators can be logically grouped into 6 primary groupings which are in line with the generic risk management methodology addressed earlier. These groupings serve to simplify the presentation of information. The identification, risk control and risk monitoring groupings are the only groupings that have other core console indicators grouped under them, as indicated in Figure 9-1.

166


Figure 9-1: BFIC core indicators and respective groupings

As discussed in Chapter 8 the BFME core risk management components have process and risk management supporting components for each indicator. The next section elaborates on the roles of the two supporting component levels within the BFIC. 9.3.2. BFIC Supporting Indicators

The process supporting and risk management supporting components provide support and additional information of the BFIC core risk management components. These supporting components form part of the BFIC as the information that is provided by them, especially the BFME risk management supporting components, is vital to the compliance with the recommendations of corporate governance. The roles of the process supporting components and the risk management supporting components are discussed in the next two sections.

9.3.2.1. BFIC Process Supporting Indicators The BFIC process supporting indicators consist of two groupings of indicators. These groupings support the identification and risk control BFIC core indicators. Figure 9-2 provides an illustration of the BFIC process supporting indicators.

167


Figure 9-2: BFIC process supporting indicators

The BFIC process supporting indicators are derived from the BFME process supporting criteria discussed in section 8.5.2.

9.3.2.2. BFIC Risk Management Supporting Indicators The BFIC risk management supporting indicators provide information about all of the processes of the BFIC core and supporting indicators. However, the BFIC risk management supporting indicators can have an effect on each other, as illustrated in Figure 9-3.

Figure 9-3: Relationships between BFIC risk management supporting indicators

The interrelationships of the framework supporting indicators are illustrated by Figure 9-3. An example of the interrelationship is the management input and reassessment relationship. This relationship will provide information about the

168


changes in management input from each assessment conducted for each core risk management component. If these interrelationships are used in the development of the BFIC, the results will yield vast amounts of information, which will negate the purpose of the framework. The development of interrelated console supporting indicators will require further research. The different BFIC components discussed in this and the preceding sections together form the Bornman Framework for ISRM Information Communication, which is discussed in the next section. 9.3.3. The Complete BFIC

The BFIC consists of the six BFIC core indicator groupings (section 9.3.1) that are supported by the BFIC process supporting indicators (section 9.3.2.1). These BFIC core indicators provide the basic information of an organisation’s ISRM programme. Additional information is provided on each of the BFIC core indicators and BFIC process supporting indicators by the BFIC risk management supporting indicators (section 9.3.2.2). Figure 9-4 provides a graphical representation of the holistic view of the BFIC.

Figure 9-4: Bornman Framework for ISM Information Communication

169


Figure 9-4 illustrates the different levels of the console’s indicators. In order to illustrate the supporting indicators of a single BFIC core indicator, see Figure 9-5. Figure 9-5 indicates that the asset identification BFIC core indicator is part of the identification indicators grouping and its respective group’s supporting indicators. This BFIC core indicator is supported by the two BFIC process supporting indicators and the BFIC risk management supporting indicators. It becomes evident that each of the BFIC core indicators has supporting information that is unique to it. Assets Vulnerabilities

sr toa ci dn I reo C ICF B

ss ceo rP CI FB

sr toa ci dn I gn itr op pu S

Threats Consequences Cause and Affect Relationships Likelihood

1. Defined Risk Tolerance Profile 2. Risk Action Plan

Risk Ranking Control Purpose Communication Control Conflict Management

Safeguards

3. Identification

Considerations of Identification Different Categories of Risk

4. Risk Measures

5. Risk Control

Incident Reporting

6. Risk Monitoring

ROI Calculations Balanced Controls

Global and System Level Assessment

gn tir op pu St ne sr o m eg taic an dn a I M ks iR ICF B

Control Monitoring

Residual Risk Third Party Objectivity

Reassessments Defined Risk Ownership and Responsibility Risk Management Improvement Projects Management Input Risk Support Documentation Risk Assessment Policies and Documentation

Figure 9-5: BFIC component example

This section discussed the indicators that can provide information to strategic management.

However,

the

indicators

provide

more

information

to

management once measures are assigned to them. The measures can be compared to the temperature gauge on a car’s dashboard. The indicator is the temperature gauge, but the measure of hot or cold provides relevant information regarding the status of the engine. The next section discusses measures for each of the identified indicators.

170


9.4. GAUGING THE BFIC In the previous section the different indicators of the BFIC were identified and discussed. This section will elaborate on the values that will be presented to the user for every indicator. In order to assign values to the indicators, the different formats that can be used in the representation of the risk management status of an organisation have to be defined.

9.4.1. Indicator Levels As has been indicated throughout the document, risk management is a business area that has to be adaptable in various organisations. Not only the methodologies have to be flexible, but so do the measures applied by them. For instance, methodologies require that values be assigned to assets. These values can be qualitative-scale-based, monetary or relative quantitative values. In order to adequately represent the risk management results from the methodologies, the indicators have to be able to faithfully convey the methodology’s results in its desired, recommended or methodology-based value formats. At a high level any value, qualitative or quantitative, can be assigned to an indicator. However, an indicator as it is used in the BFIC will convey three distinct levels of values. Table 9-1 provides the purpose and an example of each of the levels of an indicator. Table 9-1: BFIC measure levels Indicator level Compliance level

Application level

Measures level

Indicator level purpose Indicates the compliance with and implementation of corresponding risk management attribute Provides information on how the attribute or process is applied within the organisation Conveys the measures of the particular console indicator

Example

Type

Yes, assets are identified

Binary

Assets are grouped into 7 distinct categories

Descriptive

Within each asset grouping there are varying numbers of assets as well as relative values

Indicative/representative

171


Each of the indicator levels are discussed in the following sections. a) Compliance Level The purpose of this value is to indicate the application or compliance level of the risk management programme. In the previous chapter a compliance scale was developed to evaluate different methodologies. This scale can be applied to this indicator level or binary values can provide a basic compliance value. However, the compliance level indicator value does not indicate the compliance level of the methodology or methodologies, but rather the application status of the methodology. For instance, if a methodology achieves a possible compliance level of high for asset identification, the only time the compliance level in the BFIC will indicate high is if all the assets have been identified and put into the methodology’s subsequent risk processes. b) Application Level Each methodology has a different approach to each of the evaluation components and core console indicators outlined in the previous and current chapters. Therefore, in order to accommodate the diverse approaches of the risk

management

methodologies

the

application

approach

of

the

methodologies has to be represented in the console. For instance, CRAMM, OCTAVE and CORAS utilise different asset groupings. CORAS even combines some asset groupings to form a higher asset grouping of systems. This application can be used in representing the different indicators’ values. c) Measures Level The first two indicator values described above provide management with an indication of compliance and a relative indication of the approach followed in the risk management methodology. Now a value has to be assigned to the indicators. Measures can be either qualitative or quantitative. The format used will be determined by the methodology employed and the approach required or recommended by the methodology. Methodologies such as CORAS recommend that the format in which risk will be represented has to be determined in the initial phases of the risk management programme and used throughout for consistency [IST 03]. For instance, if the value of assets is

172


initially defined as a qualitative value by the methodology or risk assessors, then the indicator measures should represent the methodology’s approach to measurement. This logic will be used in the representation of the risk management methodology’s results in the BFIC. The above section described the levels of each indicator that will be displayed in the BFIC. The next section will address the generic information that will be conveyed for each BFIC indicator.

9.4.2. Indicator Measures The layout of the BFIC indicators was defined to be consisting of three different levels: BFIC core indicators, BFIC supporting indicators and BFIC risk management supporting indicators. The generic information that will be displayed in the BFIC is discussed within each grouping. The generic values are derived from the attributes and nature of the indicator. The values only represent measures of that particular indicator and not a combination of values from different components. Only representing an indicator’s unique values will provide management with a representative indication of risk values and enable them to draw their own conclusions. It will also enable management to develop ratios from the high level “raw” values. The first grouping of indicators discussed are the BFIC core indicators.

9.4.2.1. BFIC Core Indicators As outlined above, the BFIC core indicators consist of 15 individual indicators. Each is addressed separately. Defined Risk Tolerance Profile The defined risk tolerance profile indicates the ability of the organisation to accept risk. The risk tolerance can be indicated by frequency and impact level that is acceptable to management. For instance, on a system with the value of $100 000.00 management is willing to accept risks totalling $25 000.00 per annum. This example indicates a 25% risk acceptance based on the system’s value. The value and the format in which it is conveyed will have to be determined by management, as they are the ones who dictate the value.

173


Risk Action Plan The goal of the risk action plan indicator is to provide management with an indication of how risks will be addressed. The risk action plan of the organisation is the result of the risk identification, measure and proposed control processes. The important information that has to be conveyed for management is the order of risks, an indicator of risk, impact on the organisation and the controls as indicated in Table 9-2. Table 9-2: Risk action plan measures Risk priority 1. 2. …

Risk Hardware theft Software deletion …

Impact Resources, time, software Resources …

Controls Physical security controls Redundancy systems …

This indicator provides a list of the most important risks to address and how to address them. Asset Each methodology has its own approach in identifying, grouping and valuing the assets of the organisation, target-of-evaluation or business unit. This methodology-specific asset representation or grouping will be used in the groupings of assets to be displayed on the console. For instance, CORAS uses seven asset groups [IST 03]; these groupings can be used in the BFIC. Values for each of the group’s values have to be assigned. If quantitative values are used, these could be represented by the monetary values of the identified assets. Qualitative values might indicate the relative importance of each asset group. An example of asset representation is illustrated in Table 9-3. Table 9-3: Asset measures Asset groups Human Physical Information Organisational Laws and regulations Software Other TOTAL

Asset group value Quantitative Qualitative $35 000.00 Medium $100 000.00 High $250 000.00 High $75 000.00 Medium $2 000.00 Low $25 000.00 Medium $30 000.00 Medium $517 000.00 Medium

174


The purpose of indicating the combined asset value provides management with a relative importance of assets that it controls. The asset values at this level will provide management with a holistic framework of how important it is to protect particular asset groupings. Threats New threats face on a regular basis and originate from various sources. Each organisation is threatened by a unique combination of threats. However, in order to present a generic representation of threats, they can be grouped according to their origin. The generic threat source groupings outlined in Chapter 2 serve as a guide for threat groupings in the console. These threat groupings

are

supported

by

the

majority

of

contemporary

ISRM

methodologies such as CRAMM, CORAS and OCTAVE. Table 9-4 provides an example of the number of threat sources represented by qualitative and quantitative values. Total values can also be included in the indicator. Table 9-4: Threat measures Threat source Human – accidental Human – malevolent Technical failure Natural (forces of nature) Internal threat total External threat total

Number of threats Quantitative 10 20 15 5

Number of threats Qualitative Medium Very high High Very low

20 30

Medium High

The purpose of a high level threat indicator will serve to indicate the organisation’s environmental exposure. For instance, the example above indicates that there is a high external human malevolent threat level towards the organisation. The measurements will provide management with an indication of which threat areas to address first. Vulnerabilities Vulnerabilities are unique to the asset combinations of the organisation or target-of-evaluation. Therefore it is necessary to represent vulnerabilities at a higher, generic level. An asset’s generic information security vulnerabilities have been identified as confidentiality, integrity and availability. These three vulnerabilities will be used in the representation of vulnerabilities in the BFIC.

175


Table 9-5 provides an example of how the vulnerability measures of different asset groupings can be communicated with qualitative values. The asset groupings depend on the asset groupings that organisations use or the asset groupings employed by the ISRM methodology used. Table 9-5: Vulnerability measures Assets Physical Hardware Software

Vulnerabilities Availability Confidentiality High Low High Low High High

Integrity Low Medium High

Vulnerabilities can be represented by qualitative values. The purpose of indicating the vulnerabilities in the BFIC is to provide management with an indication of vulnerability and its impact on the organisation. For instance, if the organisation’s primary business is to assure clients of data integrity, then this indicator will provide a measure of how in line the systems are with the organisation’s goals. Cause and Effect Relationships Cause and effect relationships are the result of linking identified threats and vulnerabilities. For instance, if a hacker gains unauthorised access to the organisation’s system, it could result in any of the identified vulnerabilities. The cause and effect relationship indicator will provide an indication of each threat’s resulting vulnerability exploitation. For instance, an accidental human threat could result in 10 breaches of confidentiality if the threat occurs, as indicated in Table 9-6.

Tthreat

Table 9-6: Cause and effect measures

Human – accidental Human – malevolent Natural (force of nature) Technical failure

Vulnerabilities Confidentiality Availability 10 15 4 10 0 6 1 8

Integrity 1 15 2 2

Note that the linking of the vulnerabilities and threats is the intersection of the threat and vulnerability core console indicators. Therefore if the values displayed in the cause and effect relationships are tallied, they should not

176


exceed the totals displayed in the respective threat and vulnerability core console indicators. Consequences Consequences are the resulting impact of a risk that is realised. For instance, a threat exploiting a vulnerability could have a negative impact on the organisation’s ability to attain its goals. Consequences are difficult to measure as they do not only impact on the system or business area in question, but can have far-reaching effects on the organisation. Consequence measures are determined by the methodology. If the methodology specifically dictates which areas of the organisation should be included in the consequence evaluation, they should be listed or serve as value groupings. These groupings might include operational, financial or strategic partnerships. Risk can be counted and assigned to the consequence groupings of the methodology. Table 9-7: Consequence measures Consequences Strategic partnerships Financial Operational

Value High Medium Medium

Table 9-7 provides an example which indicates that the total risks an organisation faces can have a high impact on the strategic partnerships of the organisation. The consequence indicator’s scope can be limited by the asset grouping, target of evaluation or any other parameter. Likelihood Likelihoods and frequency values of risks are areas that are defined by the particular ISRM methodology. For instance, some methodologies will utilise technical logs for frequency values (CRAMM), while other methodologies do not take any possibility or frequency values into consideration (OCTAVE). However, the question remains: if likelihood values form part of the console what should be displayed?

177


The actual use of the likelihood, probability or frequency should be indicated. It is particularly important to indicate whether or not these values are used in the methodology. As OCTAVE indicates, it is not necessary to have these values for risk management to function but the BFIC has to indicate this fact. Therefore the first indication should be the actual use or the lack of use, which should include supporting arguments for its absence. If a methodology determines the likelihood, probability or frequency of risks, what exactly should be displayed on the console? When considering the definition of a risk the measure that should be displayed becomes clear. A risk is when there is a likelihood that a threat will exploit a vulnerability of an asset; thus the likelihood of the intersection of a vulnerability and a threat.

Threats

Table 9-8: Likelihood measures

Human – accidental Human – malevolent Natural (force of nature) Technical failure

Confidentiality Highly likely Highly likely Highly unlikely Highly unlikely

Vulnerabilities Availability Highly likely Highly likely Highly unlikely Unlikely

Integrity Highly likely Highly likely Highly unlikely Unlikely

The threat and vulnerability groupings are derived from the methodology used. Table 9-8 provides an example of the likelihood measures. Each likelihood value intersects a threat exploiting a vulnerability. Safeguards Safeguards are usually associated with the managing of risks once they have been identified. However, CobiT recommends that existing safeguards be identified during the risk identification process. Safeguards can constitute various types, for instance insurance, technical controls and procedural controls. The controls and their combinations are unique to every organisation. Therefore their higher level groupings have to be used in order to make them applicable to all methodologies. Safeguards are controls that attempt to prevent risks, detect incidents, correct actions and recover from incidents. These four groupings are also balancing control groupings that are used later. Controls can fall within these groupings; some controls can fall into more than one. A control can address either a threat, a vulnerability or both.

178


Threats

Table 9-9: Safeguard measures

Preventative 3 5 6 5

Human –accidental Human – malevolent Natural (force of nature) Technical failure

Vulnerability Confidentiality Detective Corrective 3 2 5 3 4 4 4 7

Recovery 1 5 6 4

Table 9-9 indicates the different safeguards currently in place for the different threat sources for the confidentiality vulnerability grouped into the four different types of safeguards. Risk Measures The purpose of the risk measures core console indicator is to convey the results of the risk measurement process of the ISRM methodology used. Each methodology approaches the measurement of risks differently; while some utilise vast databases with corresponding qualitative or quantitative values, others might employ a system where the user assigns qualitative values. The goal of this indicator is to provide management with an indication of how risks are measured and the risk value per asset-threat theme. The indicator does not have to delve too deep into the intricacies of risk measurement but should represent the general approach used. Table 9-10 provides examples of the risk measures indicators. The table indicates that the risk of a threat originating from a natural source compromising the information security of the organisational software is very low. Table 9-10: Risk measures Asset grouping Software Client data

Threat theme Accidental Natural Malevolent - internal

Qualitative measure Medium Very low High

The purpose of indicating the risk measure as a “static” indicator will provide management with a legend to interpret the other indicators’ values. It will also provide management with the ability to communicate any risk parameters. Risk Ranking Risks are ranked according to predefined parameters, for instance the risks that will have the biggest impact on the organisation. These rankings are

179


based on the risk measures determined in the previous section. The risk ranking indicator can indicate various values. It can provide an indication of the greatest risks that the organisation faces or provide management with a risk count for each risk measure. An example of the latter measure is illustrated in Table 9-11. Table 9-11: Risk ranking measure Risk rank 1 2 3

Risk identifier Employee destroying proprietary data repository External hacker gaining access to system Power interruption causing unavailability of system

The goal of this indicator is to provide management with a high level indicator for risk exposure policy-setting. For instance, management can convey its intent to reduce the number of very high risks by 25% or its willingness for medium risks to increase by 10%. Control Conflict Management Control conflict management was described as the process to ensure that implemented controls do not adversely affect other aspects of the organisation, for instance introducing more threats. Different methodologies address this risk management component in different ways; the most popular is the grouping of controls into themes. The values that have to be communicated are the existence of a conflict between the controls implemented to address a threat theme and which control theme conflicts with it. Table 9-12: Control conflict measure Threat theme control

Conflict

Conflicting control theme

External hacker controls

Yes

Proprietary B2B system communication

Access control

No

--

Table 9-12 provides an example of the control conflict measure of the BFIC. It indicates that there is a conflict between the external hacker control theme and the proprietary B2B system communication.

180


Control Purpose Communication Different types of controls are implemented to address risks. These controls can include procedures and technical controls that have a direct effect on the functions that employees have to perform. In order to ensure that employees do not get frustrated and attempt to circumvent these controls, the purpose of and necessity for the controls have to be communicated to the employees. This indicator will more often than not be a binary indicator that states what processes are in place to inform employees of this fact. A brief indication of the processes can be provided, for instance seminars, informative emails, cartoon-based brochures and posters. Table 9-13 provides examples of the control purpose communication. Table 9-13: Control purpose communication measure Communication medium Seminar Email Posters

Target Strategic management Operational employees Employees

Frequency Annually Monthly Daily

Quantify 30 June – 4 July 1st day of month Divisional coffee bars

Control Monitoring Management is responsible for the ISRM investment and has to ensure that the controls and risk exposure of the organisation are continuously monitored. Management has to be assured that the controls that have been implemented are effective and efficient. Management also has to have assurance that the information that is provided for risk monitoring is accurate. Table 9-14 provides examples of the control monitoring measure. The indicator should convey the control, the number of recommended controls, the number of implemented controls, compliance with control recommendations and the results/consequences of the implementation or non-implementation of the control. Table 9-14: Control monitoring measure Control monitoring Control Logical access control

Firewall communication ports Employee passwords

Recommended controls 10 card controllers

Implemented controls 4 card controllers

No

2 open ports

5 open ports

No

30 user passwords

30 user passwords

Yes

Compliance

Results Prevented 5 unauthorised access Blocked 4 attempts

181


The values that are indicated can be based on information such as test-runs performed or control notes made during control implementation and testing phases. The values can also be based on incident reports that are collated and processed. Incident Reporting Incidents are events which directly affect the information security of the organisation. The incident reports can come from various sources which can include technical logs, employee reports, product vendor security bulletins or external audits. Management has to be made aware of incidents that were not foreseen or were not effectively addressed. Incident reports can assist management in realigning the risk management focus. The information that has to be communicated to management is about the type of incident, the asset that was affected, the frequency and the consequence of that incident. Table 9-15: Incident reporting measure Incident External hack Employee malicious act

Asset Financial data Database

Per quarter 2 1

Consequence Confidentiality compromised System destruction

Table 9-15 indicates that an external hacker attack caused the confidentiality of information to be compromised. This section discussed the BFIC core indicators. The next section discusses the BFIC processes supporting indicators.

9.4.2.2. BFIC Process Supporting Indicators The BFIC supporting indicators provide supporting information for the identification and control groupings of the BFIC core indicators. Each is discussed below. Considerations of Identification Considerations are components that are soft issues regarding the identification of risks, for instance business risk considerations. These considerations usually form part of the approach of the risk management methodology. If a methodology utilises questionnaires like CORAS does, the

182


questions can include these considerations. Note has to be taken of these considerations which should be communicated via the BFIC to management. It is a rather static indicator that will only change over a lengthy period. The value indicators will be in binary format as indicated in Table 9-16. Table 9-16: Consideration of identification measure Identification considerations Business environment Technology environment Regulatory and legal influences

Value Yes Yes No

The purpose of the consideration identification will provide management with an indication of the scope considered during the identification of risks. Different Categories of Risks The different categories of risks are relatively static values that will be displayed on the console. Different categories will include technology risks, business risks, operational risks, legal risks, environmental risks and human resources risks. As with considerations of the risk identification phase this indicator’s values will be in binary form and will only change once the risk identification approach of the risk management methodology changes. See Table 9-17. Table 9-17: Categories of risk measure Risk categories Technology risk Environmental risks Regulatory and legal risks Human resources risks

Value Yes Yes No Yes

Categories of risk utilise the outputs and results of the risk management programmes of other business areas as inputs for information security risk identification. ROI Calculations ROI calculation is the return on investment calculation, which is a very important management level indicator. However, a risk management calculation of similar calibre is the return on security investment, as discussed in section 8.5.2.2. The ROSI [STEV 03] calculation will be a single value

183


displayed on the console. Table 9-18 provides an example of a return on security investment calculation. Table 9-18: ROI calculation measure Return on security investment Total cost of security: $400 000 Potential loss reduction: $4 400 000 Return on security investment: $4 400 000/$400 000 = 1 100%

The purpose of any return of investment calculation is to measure the efficiency of implemented controls or investments. Balanced Controls Balanced controls were mentioned earlier in the chapter as the grouping of controls according to their type. The four types named in CobiT are preventative, detective, corrective and recovery. The purpose of this indicator is to provide management with a balanced indicator. This indicator can be ratios or counted quantitative values, as indicated in Table 9-19. Table 9-19: Balanced control measure Control type Preventative Detective Corrective Recovery TOTAL

Counter 25 50 30 35 140

Percentage 18% 36% 21% 25% 100%

Control direction Under Over Under Correct UNBALANCED

The above table provides an example of a ratio and quantitative values for the indicator. The preventative control has four controls for every detective and corrective control. This is echoed by the qualitative values. Residual Risk At the onset of the risk management programme, management is faced with the decision of the amount of risk the organisation is willing to accept. The risks that are identified are managed according to this risk tolerance level. Management bears the burden of the risks that they are willing to accept. However, they are not informed of what the risks are that they are going to accept, just the level. This indicator will provide management with a breakdown of risks that they are accepting (see Table 9-20).

184


Table 9-20: Residual risk measure Residual risk Risk calculation Risk tolerance

Value R20 000,00

Description Acceptable risk level

Calculated risk Controls Residual risk

R65 000,00 (R49 000,00) R16 000,00

Gross risk Control risk Below acceptable risk level

The gross risk is the total risk that the organisation is exposed to according to the risk measures. If the organisation implements controls that address risks to the impact of R49 000 the residual risk is R16 000. The accepted risks fall within the accepted

parameters

set. The

above

example

provides

management with a viewpoint of the risk exposure they are accepting. Third-party Objectivity Management authorises the existence of the organisation’s risk management programme and is accountable and responsible for its processes, results and failures. An extra dimension of assurance for management that will confirm that their risk management programme is executed as they require is the service of third-party vendors. These third-party vendors will have to ensure that the risk management programme falls within the required parameters set by management and the risk action plan. The indicator will have to provide management with an indication of third-party vendors utilised, and the stages of the risk management programme at which they were used. The indicators can be either binary or counted values if more than one vendor was responsible for a particular process. An example of this indicator is displayed in Table 9-21. Third parties exclude internal auditors. Table 9-21: Third-party objectivity measure Risk management process Risk identification Risk measure Control monitoring

Third party utilisation Yes No Yes

Number of third parties 2 3

Designation J. Peters, S. Smith InTime Risk Tools (3x)

9.4.2.3. BFIC Risk Management Supporting Indicators The BFIC risk management supporting indicators provide additional information to management regarding the soft issues of the complete information risk management methodology employed.

185


Each of the BFIC risk management supporting indicators is discussed separately. Global and System Level Assessment Global and system level assessment addresses the scope of the risk management programme. Global refers to the inclusion of the macro environment of the organisation’s information system, for instance the external factors such as other business areas of the organisation or legal and regulatory areas. The system level refers to the parameters set by the technology employed, for instance the networked environment of the computer system. This global and system level assessment indicator provides indications for all the risk management processes. Each of the global and system level assessment considerations should be listed. An example of this indicator is displayed in Table 9-22. Table 9-22: Global and system level assessment measure Core console indicator Control monitoring

Area of assessment Network access Physical access control Legal implications

Global level assessment Yes Yes Yes

System level assessment Yes N/A No

The above table indicates the different considerations for the global and system level assessment of the control monitoring process of the risk management programme. Reassessments Risk management is an iterative process that is recommended to be conducted on an annual basis. Information regarding the previous iteration, date of next assessment and the significant changes from the previous to the current assessment will provide management with an indication of their risk management programme’s progress, as illustrated in Table 9-23. Table 9-23: Reassessment measure Reassessment – Asset identification Previous assessment Asset groupings (2003) Human asset $10 000 Physical asset $25 000 Software $30 000

Current assessment (2004) $12 000 (+2 000) $20 000 (-5 000) $40 000 (+10 000)

Next assessment (2005) $$$-

186


This indicator will assist management in comparing any BFIC indicator with previous results and planning future goals for each indicator. Management Input Management at different levels of the organisation is responsible for the operations in that particular area of business within the organisation. The risk management programme would be more successful if input were provided from management that has a relative holistic viewpoint of the particular business area’s functionality, security requirements and impact the area can have on the information security of the organisation. Table 9-24 provides examples of this indicator. Table 9-24: Management input measure Threat identification Management level Operational Strategic

Participants 2 1

Areas Physical security contractor, human resource manager Human resource manager

Table 9-24 indicates the managerial input for a particular BFIC indicator (threat identification). This example illustrates that three managers of two different levels participated from various organisational areas. Risk Management Improvement Projects Risk management is a continuous process that has to evaluate the everchanging environment in which the organisation operates. This changing environment necessitates the need to improve the risk management approach. The methodologies have been proven to be adaptable but risk management improvement projects refer not only to the adapting of the methodology, but also to the improvement of activities of the risk management processes.

For

instance,

incident

reporting

might

be

improved

by

implementing a comprehensive automated logging system rather than manually evaluating system logs. An example of this indicator is shown in Table 9-25. Table 9-25: Incident reporting measure Incident reporting Project start date January 2004 July 2004

Projected end date July 2004 December 2004

Purpose Develop holistic log reporter base system Incorporate firewall logs into HLR (holistic log reporter)

187


Table 9-25 shows that the indicator conveys that two projects are planned to be executed sequentially, and the purpose of each project. Risk Assessment Policies and Procedures Risk management has to be conducted according to a set structure or plan. This is proven by the magnitude of risk management methodologies. Each methodology has set processes, guidelines, policies and procedures that govern the execution of each methodology. These documents provide guidance on what their goals are and how each process should be conducted. Management should be informed whether or not there are processes and policies for each of the steps in the risk management methodology. These risk assessment policies and procedures should refer not only to the documentation of the methodology, but to policies and procedures drawn up by the risk assessment team and responsible parties. Table 9-26: Risk policy and procedures measure Safeguard selection Policies – Yes (1 document) Required 1 \\safeg_sel_012004.doc

Procedures – Yes (2 documents) Required 4 \\safeg_sel_proc1.doc \\safeg_sel_proc2.doc

The example in Table 9-26 indicates that the incident reporting indicator has one policy and two procedural documents that dictate how incident reporting should be executed. The policies will provide high level and general requirements for incident reporting, while the procedural documents might address the incidents regarding internally and externally originated incidents. Risk Support Documentation Risk support documents are documents that are used within the risk management processes. These supporting documents provide documented information that can be used in the risk management programme. Supporting documents like a balance sheet based list of assets will be used in the identification of assets. The risk support documentation indicator will provide information about the different documents used in each of the risk management processes.

188


Table 9-27 provides an example of the supporting documentation indicator of the asset identification risk management process. Documents used as input for the process and documents produced in the process are listed. Table 9-27: Risk support documentation measure Asset identification Input documents Financial balance sheet System schematics Network topology diagrams

Output documents Target of evaluation asset list

Defined Risk Ownership and Responsibility Management and the board of directors of a company are held more accountable for actions within their organisation than ever before. This indicator will provide management with an overview of risk accountability and responsibility within the organisation, as shown in Table 9-28. Table 9-28: Risk ownership and responsibility measure Incident reporting Organisational level Strategic Tactical Operational

Accountability (0) (2) – J. Petersen / P. Johnson (1) – E. Lieberman

Responsibility (1) – R. Smith (1) – G. McArthur (2) – T. Locke/U. McIntire

The basic values that can be indicated are the number of managers responsible or accountable per risk management process for every organisational level. Employee names can be assigned to each level.

9.5. RESEARCH VALUE The Bornman Framework for ISRM Information Communication discussed in this

chapter

provides

management

with

a

structured

approach

to

communicate the information security risk information that is required by strategic management. The structure that is followed is in accordance with the risk information requirements established in Chapter 8. The structure provides management with a communication medium of risk information not only to strategic management, but to the tactical and operational levels of the organisation as well. BFIC provides management with a holistic view of the ISRM programme that is implemented in the organisation. Not only the processes results are 189


provided to management, but also the “soft” issues that are considered to be roadblocks in holistic risk management approaches.

9.6. CONCLUSION A framework was selected as the most appropriate approach to communicate the ISRM information within an organisation. This selection was based on the fact that the Bornman Framework for ISRM Information Communication is based on the Bornman Framework for ISRM Methodology Evaluation which was discussed in Chapter 8. The BFIC indicators are grouped in the same groups as the BFME. Each indicator in the BFIC provides management with specific information regarding the corresponding ISRM component. The goal of this chapter was to develop an approach to provide management and the board of a company with a holistic view of the organisation’s risk management programme’s results and approach. The Bornman Framework for ISRM Information Communication that was developed was proven to be inline with corporate and IT governance recommendations and requirements. The BFIC is a theoretical solution to the ISRM information communication problem and has not yet been tested in a real-world environment. In the next chapter a prototype is presented that illustrates the practical implementation of the BFIC. The BFIC fulfils the three objectives outlined in section 9.1. The first objective was to determine the best approach to fulfil the ISRM information requirements. The best approach was determined to be a framework. The second objective was to determine what information has to be communicated. This was determined by utilising the BFME that was based on the information security risk information requirements according to regulatory requirements and best practice. The third and final objective was to determine how the information will be communicated. This was achieved by developing indicators for each of the BFIC components. Four objectives were set for the BFIC to achieve its goal. These objectives were to assist communication through the management structure, provide an overview of the ISRM status, provide an overview of the responsibility and

190


accountability and indicate actions that were taken in the organisation. These objectives were achieved. Therefore, the BFIC achieves its goal of effectively and efficiently communicating ISRM information. The previous chapter discussed what information is required for strategic management, and provided a framework that assisted in selecting the most appropriate methodology to deliver on those requirements. This chapter discussed the framework to communicate the relevant information from the selected methodology to strategic management. Considering the fact that information technology has been identified as the enabler of holistic risk management in Chapter 7, the next chapter investigates how these frameworks can be joined with information technology to enable holistic ISRM.

191

BORNM AN

C h a p te r 1 0

ISK CONSOLE

R

10.1. INTRODUCTION In Chapter 8 and Chapter 9 two frameworks were discussed that allow organisations to select appropriate ISRM methodologies and pull information from them to enable management to make informed decisions regarding the organisation’s information security. In Chapter 6 it was determined that risk related information can be vast. In order to effectively manage risk information, information technology resources can be employed (see section 6.5.2). The goal of this chapter is to determine if information technology, coupled with the frameworks in Chapter 8 and Chapter 9, can facilitate holistic ISRM information communication. The goal will be achieved on the successful completion of several objectives. The first objective is to determine what the purpose of the prototype will be. The second objective is to determine what components will constitute the prototype. The third objective is to discuss how the information shown in the prototype was collected. The final objective is to discuss the functions of the prototype. The layout of the chapter is guided by the objectives. The first section discusses the objectives of the prototype. The second discusses the components of the prototype. The third outlines how the information is collected and the processes used to display it to strategic and tactical level management in the prototype. The final section elaborates on the prototype and its functions. The first section addresses the fit of the two frameworks, BFME and BFIC, into the ISRM programme of an organisation.

192

Bornman Risk Console

10.2. ISRM HOLISTIC FRAMEWORK Each of the developed frameworks (BFME and BFIC) serves a specific role within the holistic ISRM framework.

The relative position of each of the

frameworks, including the proof of concept prototype, is illustrated in Figure 10-1.

Figure 10-1: ISRM holistic framework

The BFME filters the ISRM methodologies into a methodology that delivers on the required information. Once the methodology is implemented, the BFIC “processes” the information and produces a standardised information security risk information set. This information set is then transformed through technological means. This technological means is the Bornman Risk Console, which is discussed in the chapter. These three components form a holistic framework that provides top management with a holistic ISRM picture. The next section discusses the goal and objectives of the prototype.

193


10.3. PROTOTYPE OBJECTIVES The goal of the prototype is to consolidate the operational managerial level ISRM information and provide the necessary information to strategic and tactical level management. In order to achieve this, the prototype has to use the Bornman Framework for ISRM Information Communication discussed in Chapter 9. This requires management to evaluate methodologies against the Bornman Framework for ISRM Methodology Evaluation (see Chapter 8) to determine if the ISRM approach employed by the organisation can provide the required information. The prototype will have to be able to show real-time information security risk information. This information will have to be based on factual data from an ISRM methodology that complies with the BFME. Figure 10-2 provides a graphical representation of the flow of how the risk information will be gathered. The diagram also indicates the role of each of the frameworks, BFME and BFIC, in interrelating to the processes.

Select ISRM methodology

Bornman Framework for ISRM Methodology Evaluation

Implement ISRM Collect Data Process information


Output risk information Figure 10-2: BRC objectives

The methodology should be selected subsequent to the evaluation of the BFME and implemented as illustrated in Figure 10-2. The data that is entered

194


into the methodology’s tools should be collected, processed and output in accordance with the BFIC which is derived from the BFME. In order to show that the operational managerial level risk information can be communicated effectively to strategic and tactical level management, the prototype is a software package. This software package is known as the Bornman Risk Console (BRC). The next section discusses the different components of the BRC.

10.4. BRC PROTOTYPE COMPONENTS The console consists of three primary components. All three components are necessary in order to provide the required information. Figure 10-3 provides a graphical representation of the three components of the BRC prototype.

Figure 10-3: BRC prototype components

The diagram indicates that the ISRM methodology and the BRC can have different

supporting

technologies;

however,

a

certain

technological

compatibility is required to communicate the risk data and information. In this instance the compatible supporting technology is the XML data format. Each of the BRC prototype components is discussed below.

10.4.1. Information Security Risk Management Methodology An ISRM methodology that has an existing tool or application that can export data into a manageable format is required. The methodology that is used in the prototype is the CORAS risk assessment platform (see 3.6.3). This methodology was selected as it proved to be the best methodology according to the BFME (see Appendix A).

195


The methodology provides a web-based interface that can be accessed through any Internet browser. Data that is entered through this interface is stored in an eXist XML Based Database [EXIS 04]. Data can be exported from this database into manageable XML data files.

10.4.2. Supporting Technology The underlying technology required for the BRC prototype is a Microsoft Windows based personal computer. The test system is a Microsoft Windows XP Service Pack 1 running on a Pentium IV 1.8 GHz processor with 256 MB RAM. Supporting software required is the Java platform version 1.4 [J2SE 04] or later and Microsoft .Net Framework version 1.1 [MICR 04]. XML [W3C 00] is the chosen file format for the CORAS platform as well as all the supporting data documents.

10.4.3. BRC Technology The console was developed in the Microsoft Visual Basic .Net language in Visual Studio .Net 2003. Since the .Net framework only functions on MS Windows operating systems the console cannot run on other operating systems without reprogramming the console. The CORAS platform can, however, be run on different operating systems as it is based on technology that is not platform-dependent. The technology enables the BRC prototype to function. However, the information transformation and the BRC prototype were developed through different processes. The following section discusses these processes.

10.5. BRC DEVELOPMENT Figure 10-4 provides a detailed account of the process followed in the development and information transformation processes of the data collection process and processes implemented to compensate for the selected methodology’s shortcomings.

196


Figure 10-4: Console data source flow diagram

The BRC was developed in three phases. Each phase represents a specific component of the BRC. Phase 1 focuses on the ISRM methodology (BFME); Phase 2 focuses on the supporting technology of the methodology and how this can be leveraged to provide the required information (BFIC), and phase 3 focuses on the BRC prototype. Phase 1 Phase 1 consisted of entering the ISRM process-related data through a webbased front end into a backend database. The methodology was selected as a result of the comparison framework outlined in Chapter 8. The comparison process ensured that the methodology that can provide the required output was selected. Phase 2 During phase 2 the data that was stored in the database was exported to an XML document. The XML data was compared to ensure that the data it contained provided the information necessary to fulfil the requirements of the console. Where the data did not provide compliant information, supporting information was generated from the ISRM

methodology processes.

Supporting information was stored in XML documents. The methodology and supporting data were consolidated to comply with the requirements of the console. Some methodologies require certain data to be entered into the tools before other data can be entered. In order to determine what data is required a table can be created which indicates what data is required for other data to be

197


entered. The CORAS methodology’s prerequisite processes are indicated in Appendix C. Phase 3 Phase 1 provided the source data for the console and phase 2 ensured that any shortcomings in the methodology’s data were supplemented by supporting data. Consolidating the data provided a console-compliant dataset. From the compliant dataset the console was developed to transform the data and provide decision-enabling information. This section and the preceding sections discussed the goals, objectives and processes that form the BRC. The next section discusses how these sections culminate in the BRC prototype.

10.6. BRC FUNCTIONS The information that is provided by the console is divided into three main categories or views. In order to access these categories, the methodology’s data has to be imported into the BRC. This is accomplished by opening the unedited XML source file which was exported from the methodology. Figure 10-5 provides a graphical representation of the managerial focus and the risk information’s detail level for each of the three main BRC categories or views.

Ove rv ie w

Conso le View

XML Data

BRC Prototype Detail Level

Figure 10-5: BRC prototype views

The figure provides a detail level relationship to managerial focus. For instance, it indicates that the overview has relatively little detail and is focused at strategic management.

198


Once the file has been loaded the user is presented with a breakdown of the risk assessment projects stored in the file. The user selects the project and immediately the overview of the risk assessments results are compared to the compliance levels of the console. Each of the three main BRC categories or views is discussed.

10.6.1. Overview The first tab window provides a traffic-light styled compliance console. From this console the user can immediately see which areas are non-compliant and might require attention. The traffic-light indicators are grouped according to the BRC’s functional groupings outlined in Chapter 9. A shaded indicator represents non-compliance, while an encircled indicator represents complete compliance. Next to each of the indicators the particular components’ names are displayed on buttons which, when clicked, will provide additional information on the component in the console view. Figure 10-6 is a screenshot that shows the groupings of components with their compliance indicators.

Figure 10-6: Console’s overview view

199


This view provides high level information security risk information for strategic and to some extent tactical level management. It enables these managerial levels to quickly focus on areas that require attention as they are already identified by the indicators. This is in line with the goal of the Treasury Board of Canada’s Integrated Risk Management Framework (section 7.2.1) to display enterprise-wide risks on a single page, however this is ISRM specific. This view indicates the high level compliance of BFIC indicators and not the detailed information of each indicator. The next section discusses how the indicators’ detail is displayed in the BRC.

10.6.2. Console Figure 10-7 provides a screenshot of the BRC’s console view. This view provides more detail of a single indicator which is represented in the overview view. To the left of the screen a tree view provides access to each console component’s information.

Figure 10-7: BRC console view

The identification-asset console grouping is displayed. This component has BFIC process supporting indicators (see 9.4.2.2) and BFIC risk management supporting indicators (see 9.4.2.3) associated with it. These indicators are

200


displayed to the right and bottom of the asset core console indicators (see 9.4.2.1). The asset identification indicators were used as an example in Figure 9-5, which indicated the BFIC core, process supporting indicators and risk management supporting indicators. By default the BFIC process supporting indicators and BFIC supporting indicators are hidden. Once the user clicks on their respective buttons they are displayed alongside the other values. Each of the different subgroupings of the supporting and process supporting groupings can be accessed via the tab buttons. Some of the data that is used in the console is only possible by correlating the methodology’s data with data that is stored in external data files. This is necessary for the areas that are not supported by the methodology or its software tool. However, when viewing the BRC the external data and the methodology data cannot be separated as they are seamlessly integrated. This view provides more detailed information focused on tactical and operational level management. Once a problem has been identified and displayed in the BRC’s overview, the BRC is the first “drilldown” level where more detailed causes of the non-compliant components can be identified. The information that is shown in this view enables lower level management to view risk in the format specified by the BFIC. It is a logical structure with information that is shown in a way that does not overwhelm the user. All the process supporting indicators and risk management supporting indicators are shown. The information that is shown in the BRC is based on raw data from the methodology. The next section discusses the raw data view in the BRC.

10.6.3. XML Data As indicated, the primary data storage medium of the console is based on the XML standard. Within the console XML data view the user is presented with a tree view that provides access to the raw data which the console uses to deliver decision information (see Figure 10-8).

201


Figure 10-8: BRC XML data view

The BRC XML data view provides a view of the raw data on which the risk information is modelled. This view enables users, specifically operational management and employees, to isolate or determine specific data entities that form the high level risk information. This data can be exported to other applications to be included in the ERM software programs. The data that is exported can be stored and imported in a modified BRC to provide ISRM information about business units, over time or for the whole organisation. This section discussed the functions of the BRC prototype. The BRC has several advantages and disadvantages for an organisation. Some of these advantages and disadvantages are highlighted as part of the BRC evaluation process.

10.7. BRC EVALUATION The BRC is the result of various processes, frameworks, technologies and tools which influence the BRC. These components can lead to several advantages or disadvantages. These advantages and disadvantages are briefly discussed in this section.

202


10.7.1. Advantages Advantages are aspects deemed to be helpful, useful and likely to bring success [OXFO 80]. The BRC was developed as a result of various processes; therefore it should be helpful and likely to bring success to the developed frameworks. This section briefly discusses some instances where it is helpful to the frameworks.

10.7.1.1. Multiple Projects The console has the ability to display ISRM information for different projects. These projects can be selected from the drop down list. It provides management with the option to consolidate the different risk management projects to have a holistic view of ISRM projects throughout the organisation. ISRM information from various strategic business units or departments can be consolidated in the BRC. For instance, consider the IT environment illustrated in Figure 10-9.

Figure 10-9: Console distributed nature

The BRC can consolidate the data of the methodology from various business units and deliver a report in real-time to the organisation’s risk manager.

10.7.1.2. Automated Information is automatically consolidated from lower managerial level systems. By automating the system, fewer human resources are required and the risk of data input integrity is minimised. The automated feature provides

203


the ability to have up-to-date information in terms of minutes and not days or months.

10.7.1.3. Tiered Data Information is shown at different levels. Operational, tactical and strategic management information is shown. If top level management requires information, it is at their disposal - they do not need to request detailed reports.

10.7.1.4. Open Data Environment The data that is used in the console is such that export filters can be applied to it. By exporting data from the console, data can be stored in data repositories/libraries for internal benchmarking, or integration with other proprietary systems. Due to the open data type of the BRC the information produced by the BRC can be seamlessly integrated into other systems.

10.7.1.5. Automated Risk Management Data Information that is produced at operational level of the organisation is automatically correlated. This correlated information is presented in a manner structured according to middle and top managerial requirements.

10.7.1.6. Real-time Data Breakdown Information is shown at three different levels for management. If management requires more detailed information, it is literally a click away. Management does not have to request detailed reports.

10.7.1.7. Real-time Control Systems The console draws its information from external sources and in a way that facilitates the automatic inclusion of security control data in the console’s source data. For instance, an intrusion detection system’s data logs can be included as real-time risk data and provide management with an up-to-theminute indication of control status in the BRC.

204


10.7.1.8. Standardised Risk Management Representation Information is presented at different granularities to facilitate the usefulness of the data at the different levels of the organisation. The information that is shown to the various levels of management is all based on the same facts. Consolidation, aggregation and summarising do not change the “message” of the data as it is shown to the various levels.

10.7.1.9. Interactive Sliders can be built into the console that will provide management with an indicator between set parameters (minimum and maximum values). This slider indicator can be changed by management and accordingly convey management’s risk objectives for each of the console’s components. This advantage directly addresses the enterprise-wide risk management objective of effectively conveying management’s risk direction horizontally and vertically within the organisation. The interactive nature of the BRC enables the board and top level management to have direct monitoring of risk decisions (see Board Involvement on page 129). Although there are numerous advantages to the BRC, there are some disadvantages that work against the BRC.

10.7.2. Disadvantages Disadvantages can be defined as those aspects that stand in the way of success [OXFO 80]. Although the disadvantages listed in this section hinder the application of BRC, they are not crippling and can be solved through technological solutions.

10.7.2.1. Data Format of Methodology Tools Methodologies with different processes to manage risks; the tools and applications involved are just as dissimilar. If the tools or applications that are used change, the console has to be reprogrammed to accommodate these tools. However, due to the “open” nature of the risk data storage approach (XML), middleware applications can be developed to alter the tools’ outputs and enable them to seamlessly provide source data for the existing console. If

205


no direct access to the data that is collected by the methodology tools is provided, the information that can be communicated in the BRC is limited.

10.7.2.2. Platform Dependency The console was developed in the Microsoft .Net environment, which limits the prototype to the MS Windows operating system. However, the risk assessment platform is computer platform independent. A console can be developed that utilises the same core technologies as the risk assessment platform. This will enable the console to be platform-independent as well.

10.8. RESEARCH VALUE Through the use of the BFME and BFIC and the implementation of information technology resources better risk information communication can be established between the different managerial levels of an organisation. Managerial levels do not have to communicate information that they think their superiors might require by trying to mould the risk data into specific information sets. Each level’s requirements can be met by their own instruments or tools and technology can provide the communication medium. This leads to true integrated risk management. The BRC provides management with a holistic view of the information security risk within their organisation. It allows drilldown into the detail levels that can provide more insight into the reasons for non-compliance of the ISRM programme. The BRC is not based on a set methodology’s tools but proves that the processes that were followed throughout the dissertation can integrate ISRM approaches at various managerial levels. This chapter integrates the offline risk management methodologies with online tools and instruments. By implementing the BRC, information security risk management can be integrated into the day-to-day management of the organisation. It enables management’s risk direction to be communicated effectively and, more important, to be understood (see section 7.2.1).

206


Through the combination of the different frameworks, which allows for different methodologies to be implemented and their information to be consolidated in a structured manner, ISRM is integrated vertically and horizontally in the organisation. One of the roadblocks of ERM, which was highlighted in section 7.3.2, is information technology. This roadblock was removed in terms of ISRM as the data is correlated and effectively communicated through technological means.

10.9. CONCLUSION The Bornman Risk Console Prototype was developed to prove that ISRM information can be communicated from operational level to top level management. This is accomplished by evaluating ISRM methodologies against the BFME and basing the BRC prototype on the BFIC. The console consists of three components: the methodology, supporting technology and the technology on which the console is based. A process was discussed for transforming the information for the console. Each of the console’s high level functions was discussed, along with the advantages and disadvantages of the console approach. The goal of this chapter was to determine if information technology, coupled with the frameworks in Chapter 8 and Chapter 9, can facilitate ISRM communication. This goal was achieved by developing the BRC prototype which collects and processes the data of a BFME-compliant methodology and presents risk information which is compliant with the BFIC. Each of the objectives was achieved in attaining the chapter’s goal. The first objective was achieved by discussing the purpose of the prototype. The second objective was achieved by defining the three components that make up the BRC prototype. Each of the components was discussed. The third objective was achieved by discussing the process that was followed towards creating the final BRC prototype. This process included the subprocesses associated with each of the BRC components. The final objective was achieved by providing a brief overview of the three main views of the BRC prototype.

207


The Bornman Risk Console proves that it is possible to communicate ISRM information throughout the organisation. This addresses the core purpose of the dissertation. However, the next chapter discusses the overall goal and objectives of the dissertation as stated in Chapter 1.

208

C h a p te r 1 1

CONCLUSION 11.1. INTRODUCTION “If a man will begin with certainties, he will end in doubts; but if he will be content to begin with doubts, he will end in certainties.” - Francis Bacon (1561-1626) This research was undertaken with many uncertainties and doubts regarding the field of ISRM. Francis Bacon’s words ring true in this dissertation as various certainties came to light. The goal of this chapter is to discuss the certainties that were determined. The first objective is to determine whether or not the research documented in this dissertation addresses the problem outlined in Chapter 1. The second objective is to determine what value the research holds. The third objective is to identify the lessons the author learned during the course of this research. The final objective is to provide possible research topics that flow directly from this research. The chapter’s layout is structured according to the objectives outlined above. The first section revisits the problem statement and determines whether the research solves the problem. The second section discusses the value the research provides to organisations and academics. The third section briefly highlights the lessons the author learned. Some lessons involve the identification of possible future research topics which are discussed in the fourth section. The chapter concludes with an epilogue.

209

Conclusion

11.2. REVISITING THE PROBLEM “To do successful research, you don't need to know everything; you just need to know of one thing that isn't known.” - Arthur Schawlow A single high level concept was highlighted in Chapter 1. This concept was ISRM communication. Throughout the dissertation this concept was the golden thread that guided the process to address the research problem. This concept assisted in breaking down the problem into manageable subsections or key areas. Each of these key areas is re-evaluated to define the successful completion of addressing the research problem. They are addressed in the order in which they were presented in Chapter 1.

11.2.1. Definitions and Concepts The business principle of risk management is riddled with ambiguous terminology. Therefore Chapter 2’s goal was to define various concepts associated with risk management, information security and ISRM. Various sources which included ISRM methodologies, standards and guidelines and risk management books were consulted. A set of definitions was compiled to present a cohesive set of terminology as used in the dissertation. These terms were defined in the context of risk management and information security to provide a complete view of how the terms relate.

11.2.2. Various Risk Management Needs Various

organisations

have

dissimilar

managerial,

resource

and

organisational structures. This complicates risk information communication within the organisation. Three generic managerial levels were identified and their respective needs determined in Chapter 2. Strategic and tactical needs and risk approaches were determined in Chapter 4, while the needs and risk approaches for operational level were determined in Chapter 3. These needs led to the development of the Bornman Framework for ISRM Evaluation, which was presented in Chapter 8. The framework provides a structure and evaluation

scale

for

organisations

to

determine

whether

an

ISRM

methodology can fulfil managerial risk information needs.

210

Conclusion

11.2.3. Risk Management Information The different approaches at the various managerial levels of an organisation produce disjointed risk information. Not only is the information disjointed, but the risk management approaches produce extensive documents that have to be consolidated to produce a holistic view of organisational ISRM information. The Bornman Framework for ISRM Methodology Evaluation (Chapter 8) provides a framework for evaluating the ability of a methodology to deliver required risk information. The Bornman ISRM Information Communication Framework (Chapter 9) provides a structure and indicators to communicate the risk management information effectively. These frameworks can provide operational risk management information in a structured, effective, efficient and timely manner to strategic and top level management. This was proven in Chapter 10 with the developed prototype which utilises both frameworks in delivering risk management information.

11.2.4. Risk Management Approaches Management has various options on how to approach ISRM. The overall approach of ISRM with the inclusion of standards and best practices into a framework provides management with a holistic risk management view. Irrespective of the different approaches that management can implement, the information that is required at strategic and tactical level is predetermined by government or organisational planning strategies. These requirements were determined in Chapter 4. The frameworks discussed in Chapter 8 and Chapter 9 are based on these requirements and provide processes for various approaches to be consolidated with the requirements.

11.2.5. Risk Management Communication This dissertation shows that ISRM communication is improved because specific aspects that contribute to this communication problem are addressed. Chapter 2 provides a set of terminology and concept definitions which establish a common language to communicate risk management information. Chapter 3 discussed in detail how ISRM information is produced, while Chapter 4 addressed the requirements of strategic and tactical level 211

Conclusion

management. These three chapters provided top level management with the means to communicate their requirements and operational management with the means to communicate information through the common risk language back to them. However, the communicated information is still in a very raw format. Chapter 9 and Chapter 10 prove that the huge amounts of information produced can be communicated to top management in a format that is summarised but still provides information that is required by them. The information that is communicated through the BRC is flexible as it draws from the tools of different methodologies. The information that is communicated is not restricted to a specific method.

11.2.6. Dynamic Environment If the environment is dynamic then the solution has to equal it. The prototype (Chapter 10) provides organisations with a tool that can do exactly that. Since the methodology that an organisation implements can provide risk information that is required (Chapter 8), the prototype can provide management with risk information in real-time. The risk information that is produced by the ISRM methodology is still produced in accordance with the methodology’s approach. The information is summarised as additional information for top management. The information is summarised electronically, dynamically, from the methodology as data is entered into its tools. Even if the ISRM cycle is not yet complete, the information that has been entered up to a certain stage can still provide management with decision-enabling information.

11.2.7. Silo Risk Management Risk management is usually conducted within the scope of its functional grouping which is governed by the organisational structure (Chapter 5). Organisations attempt to consolidate these risk silos through enterprise-wide risk management approaches (Chapter 6). These approaches require top management to be proficient in interpreting different types of risk data such as financial, operational and information security. The information that is

212

Conclusion

presented to the decision-makers should fulfil their needs (Chapter 8) and be presented in a manner that enables them to quickly understand its meaning. The prototype (Chapter 10) presented a dashboard which on a single page consolidates the information security risk data with three different indicators. This assists decision-makers in making timely and informed decisions based on up-to-date information. The organisational structures do not have an impact on communicating information on security risk management if the frameworks are implemented and supported by the BRC. This section focused on the key aspects of the problem addressed in this dissertation. The next section discusses the value that this research holds.

11.3. VALUE OF RESEARCH The research documented in this dissertation was to add value to the field of ISRM. This was accomplished by identifying a problem in the field and systematically addressing it through defined goals and objectives. This section outlines the overall value of the research to the field of ISRM.

11.3.1. New View of ISRM ISRM is a business principle that has evolved as information technology has evolved. This has translated into changes in approaches, processes, scope and methodologies. However, the cycle involved in ISRM stays the same. The solutions provided here change the view of ISRM. Organisations can have greater flexibility on how they approach ISRM, the information that they get and the way in which they get the information. The risk information that is presented to them and the way in which it is presented provides organisations with a holistic view of the organisation’s ISRM programme.

11.3.2. ISRM Integration Information is the basis of any modern organisation. Various departments within an organisation base their function on a common set of information. The solutions provided in this dissertation provide for a horizontally and vertically integrated ISRM solution for organisations. Risk information can be communicated horizontally between the different divisions or departments,

213

Conclusion

even if they employ different approaches. The risk information in the different departments and divisions can be effortlessly consolidated vertically in the organisation.

11.3.3. Streamline ISRM Throughout the dissertation specific aspects were considered that make up and influence the field of ISRM. This dissertation provides a logical breakdown of the different components and discusses various factors that should be considered in terms of ISRM. These breakdowns and discussions on their own provide a holistic view of the ISRM field. With this understanding, organisations can streamline the ISRM processes. Not only does the holistic view of ISRM provide a means to streamline the processes, but the solution that was developed provides instruments that will assist in tailoring processes. With the prototype and established communication processes through the developed frameworks, ISRM can be seamlessly integrated into the day-today running of the organisation.

11.3.4. ISRM Focus Management and governments have become more and more vigilant about factors that can impact their organisation and countries. This is the result of world events and closer inspection within their own organisations and countries. Governments and management are starting to realise the impact that unforeseen events can have on them. This has instigated a push for adequate risk management and due diligence. This dissertation highlights the fact that, irrespective of the risk management in other countries or in other areas of an organisation, one of the most important areas that has to be focused on is information security risk management. This focus is enforced through regulations and organisations will have a competitive advantage if they adhere to these regulations.

214

Conclusion

11.3.5. Roadblocks Implementing ISRM and more holistically enterprise-wide risk management has numerous roadblocks. Through the use of the BFME, BGIC and BRC these roadblocks have been removed. Information technology reduces the amount of risk information processes by automating it. It is also been proven that information technology further assists in managing the “soft” issues of ISRM. By adding value to the field of ISRM the author has learned various lessons. The next section highlights some of these lessons.

11.4. LESSONS LEARNED “Finally, I will not become any dumber” – Paul Erdös (Hungarian mathematician, 1913-1996) The words of Paul Erdös ring true as long as lessons are learned from any endeavour. This section highlights only some of the areas in which lessons were learned.

11.4.1. ISRM Integration ISRM is a risk management area that permeates all other risk management and business areas. Whereas, for instance, financial risk management, another risk area that impacts the organisation holistically, only impacts the scope of the organisation, information security impacts the operations of the organisation. Information is the basis of any modern organisation. Information security can be compared to the wise man building his house on the rock and the foolish man his house on the sand. ISRM ensures that all other aspects of the organisation can run smoothly. Organisations take information availability, integrity and confidentiality at face value; if the computer says so then that is the way it is supposed to be. ISRM has to ensure that.

11.4.2. ISRM Threat Focuses Information security is mostly regarded as a technical problem. However, the use of information technology has two other major components which enable

215

Conclusion

it to be effective in an organisation. They are processes and people. All three components have to be addressed for information security to be effective. Therefore, risk management is focused on the processes and people, with technology as a supporting component.

11.4.3. ISRM Influences Information security is not an issue that can be contained within an organisation. Although the risk management focus is centred on the business and the protection of its boundary, the external environment has to be taken into account. This boundary is becoming blurred as the external technology environment like the Internet is becoming integrated into day-to-day running of the organisation. ISRM influences all the areas of the organisation. Coupling these influences with the open-ended nature of modern organisations makes information security a difficult area.

11.4.4. ISRM Multiplicity As if information security and risk management were not difficult enough areas to understand, there are different views of what its components are and how it should be executed within the organisation. This multiplicity of ISRM concepts makes the implementation and adoption of ISRM in organisations very difficult.

11.4.5. Increased importance of ISRM Throughout the research it became quite apparent that ISRM as a business principle is moving away from a position where organisations feel they should implement it to where they know they have to implement it. This realisation is partly because of the governmental regulations, but more of information security being a vulnerability to an organisation as a whole. If an organisation loses information confidentiality, integrity or availability it has far-reaching consequences on all aspects of the organisation.

216

Conclusion

11.4.6. Information Security Risk Management Environment The field of information security risk management and, in particular, information security was a new area for the researcher. This environment was extensively researched and placed into context within an organisation taking into consideration management levels, business functions and organisational impacts.

11.5. POSSIBLE FUTURE RESEARCH “The outcomes of any serious research can only be to make two questions grow where one question grew before” – Thorstein Veblem This section briefly discusses some possible questions that grew from a single question.

11.5.1. Linking with Risk Awareness and Culture Employees have been fingered as the ultimate culprits of information security breaches. One principle within risk management is user awareness to control this risk. Since most ISRM methodologies employ questionnaires to determine risk levels, these questionnaires should be able to be used as part of user awareness as well as for risk identification. This questionnaire data can be automatically correlated and incorporated into the console for automated risk identification.

11.5.2. Development of a Risk Communication Protocol Certain methodologies have proprietary data formats to store the risk data that was collected through the assessments. In order to allow methodologies to “plug” into the console a risk communication protocol will solve this problem.

11.5.3. BFIC Implementation The Bornman Framework for ISRM Information Communication draws information from existing ISRM methodologies. However, this framework has not been implemented in a real-world environment. Research will have to be undertaken into the practical implementation and management of the framework in a real-world environment. 217

Conclusion

11.6. EPILOGUE Steven Covey writes in his book, The 7 Habits of Highly Effective People, that you have to begin with the end in mind. The author has found that this is not the case with research. As Isaac Asimov states: 'The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's funny..."' - Isaac Asimov Research is not about finding a solution to a problem and looking for supporting material on which to base assumptions in order for a specific approach to be proven, but through systematic study to achieve the “that’s funny” feeling. This leads to another of Steven Covey’s 7 habits that rings true in research: “Seek to understand, and then to be understood” – Steven Covey As a newcomer to the field of ISRM, the author has taken the process of understanding the field and developed solutions from the knowledge that was gained. This dissertation is the result of this understanding and the process of making him understood by others. Some final thoughts: “A person will only truly learn, if he teaches others” - Unknown “Education is not about passing or failing, but the ability to distinguish between what you know and what you don’t know” - Unknown

218

A

P P E N D IX

A

This appendix contains the results of an application of the Bornman Framework for ISRM Methodology Evaluation discussed in Chapter 8. Three different ISRM methodologies which are discussed in Chapter 3 are used in the evaluation. The methodologies that are evaluated are CORAS, OCTAVE and CRAMM. The evaluation criteria used are discussed in Chapter 8. The values that are assigned to the evaluation criteria for each methodology are values that form the evaluation scale discussed in section 8.6. Once a method achieves the highest compliance value of high (value 3), the evaluation value is assigned the maximum value of 3. Therefore, no adaptability or maximum adaptability value is required. The values are added up to determine the achieved values for each methodology. Each column can be a maximum of 84. Percentage values are calculated from the totals relative to the maximum value. The important column values are compliance, need for adaptability and final compliance columns. FINAL COMPLIANCE = Initial Compliance + Lowest Value of ((Adaptability of Method) OR (Need for Adaptability))

219

Appendix A

FINAL COMPLIANCE


Initial compliance

Adaptability of method

CORAS

Core risk management components Defined risk tolerance profile

High

3

3

Risk action plan

High

3

3

Identification Assets

High

3

3

Threats

High

3

3

Vulnerabilities

High

3

3

Consequences

High

3

3

Cause and effect relationships

High

3

3

Likelihood/frequency

High

3

3

Safeguards

None

0

Risk measures

High

3

3

Risk ranking

High

3

3

Control conflict management

High

3

3

Control purpose communication

None

0

High

3

High

3

3

Control monitoring

Low

1

High

3

Medium

2

3

Incident reporting

None

0

High

3

High

3

3

High

3

High

3

3

Control

Monitoring

220

Appendix A

Process supporting components Identification Considerations of identification

High

3

3

Different categories of risk

High

3

3

None

0

Medium

2

Medium

2

2

Low

1

Medium

2

Medium

2

3

Residual risk

None

0

High

3

High

3

3

Third-party objectivity

High

3

3

Global and system level assessment

High

3

3

Reassessment

High

3

3

Management input

High

3

3

Risk management improvement projects

None

0

Risk assessment policies and procedures

High

3

3

Risk support documentation

High

3

3

Defined risk ownership and responsibility

High

3

3

Control ROI calculations Balanced controls

Risk management supporting components

High

3

High

3

3

Method total

62

22

21

83

Max

84

84

84

84

74%

26%

25%

99%

%

221

Appendix A

FINAL COMPLIANCE


Adaptability

Initial compliance

OCTAVE

Core risk management components Defined risk tolerance profile Risk action plan

Medium

2

High

3

Low

1

3

High

3

3

High

3

3

Identification Assets Threats

High

3

3

Vulnerabilities

High

3

3

Consequences

High

3

3


High

3

3


None

0

Safeguards

High

3

3

Risk measures

High

3

3

Risk ranking

High

3

3


Low

1


High

3

Control monitoring

None

0

Medium

2

Medium

2

2

Incident reporting

None

0

Low

1

Low

1

1

High

3

High

3

3

Control

High

3

Medium

2

3 3

Monitoring

222

Appendix A


High

3

3


High

3

3

ROI calculations

None

0

Medium

2

Medium

2

2

Balanced controls

None

0

Medium

2

Medium

2

2

Residual risk

None

0

Low

1

Low

1

1

Third-party objectivity

None

0

Medium

2

Medium

2

2

Global and system level assessment

High

3

3

Reassessment

High

3

3

Management input

High

3

3


Low

1


High

3

3


High

3

3


High

3

3

Control

Risk management supporting components

High

3

Medium

2

3

Method total

58

22

18

76

Max

84

84

84

84

69%

26%

21%

90%

%

223

Appendix A

FINAL COMPLIANCE


Adaptability

Initial compliance

CRAMM

Core risk management components Defined risk tolerance profile

None

0

Low

1

Low

1

1

Risk action plan

High

3

3

High

3

3

Identification Assets Threats

High

3

3

Vulnerabilities

High

3

3

Consequences

High

3

3


High

3

3


High

3

3

Safeguards

High

3

3

Risk measures

High

3

3

Risk ranking

High

3

3


High

3

3


None

0

High

3

High

3

3

Control monitoring

None

0

Low

1

Low

1

1

Incident reporting

None

0

High

3

High

3

3

Control

Monitoring

224

Appendix A


Low

1

Low

1

Low

1

2

Medium

2

Medium

2

Low

1

3

Medium

2

Low

1

Low

1

3

High

3

Medium

2

High

3

Medium

2

Reassessment

High

3

Management input

Low

1

Low

1

Low

1

2


Low

1

Low

1

Low

1

2


High

3

3


High

3

3

Medium

2


Control ROI calculations Balanced controls Residual risk Third-party objectivity

3 Medium

2

Low

1

3 3

Risk management supporting components Global and system level assessment


Medium

2

Low

1

3 3

Low

1

Low

1

3

Method total

61

19

16

77

Max

84

84

84

84

73%

23%

19%

92%

%

225

A

P P E N D IX

B

This appendix contains a table that indicates the compliance of the Bornman Framework for Evaluating Information Security Risk Management Methodologies with the requirements of the King II Report [KING 02]. A row indicates a specific paragraph of the King II Report. Each column represents an evaluation criteria component. Compliance is indicated by a tick mark. This table illustrates that the evaluation criteria, which form the basis of the Bornman Framework for ISRM Information Communication, are in line with the requirements of the King II Report. Legend Symbol

Description Full compliance The solutions (BFME, BFIC and BRC) enables compliance

226

AP P E N D IX C This appendix provides a table that was used in the development of the prototype (Chapter 10). The rows indicate the different processes of the CORAS methodology and the columns the Bornman Framework for ISRM Information Communication components. The cells that have white circles show the CORAS processes that meet the requirements of the framework’s components. The blacked out cells indicate the prerequisite processes for the compliant processes to provide information.

227

AP P E N D IX D The Article A

COMPARATIVE

FRAMEWORK

FOR

EVALUATING

INFORMATION

SECURITY RISK MANAGEMENT METHODS was published in the proceedings of the ISSA (Information Security South Africa) 2004 conference held at Gallagher Estate in Midrand, South Africa, from 30 June to 2 July 2004.

228

Bibliography

B IB L IO G R A P H Y [AKSE]

Aksel K.H.; d.u.; Organizing a Financial Institution to Deliver Enterprise-Wide Risk Management; PricewaterhouseCoopers.

[ALBE 03]

Alberts C., Dorofee A.; 2003; Managing Information Security Risks – The OCTAVE SM Approach. Pearson Education. ISBN:0321-11886-3.

[ALBE 01]

Alberts C., Dorofee A.; 2001; OCTAVE SM Implementation Guide Version 2.0. Carnegie Mellon University.

[ASNZ 99]

Standards Australia, Standards New Zealand; 1999; Risk Management AS/NZS 4360:1999; Standards South Africa ARP 4360:2003; ISBN:0-626-14217-2.

[AUJK 95]

Ashkenas R.N., Ulrich D., Jick T., Kerr S.; 1995; The Boundaryless Organisation: Breaking the Chains of Organizational Structure; Jossey-Bass Publishing; ISBN: 0-78790113-X.

[BASE 01]

Basel Committee on Banking Supervision; 2001; Risk Management Principles for Electronic Banking; Bank of International Settlements.

[BASE1 01]

Basel Committee on the Global Financial System; 2001; The Implications of Electronic Trading in Financial Markets; ISBN 92-9131-613-X.

[BASE 03]

Basel Committee on Banking Supervision; 2003; Trends in Risk Integration and Affregation; Bank of International Settlements.

[BAMM 99]

Bandyopadhyay K., Mykytyn P.P, Mykytyn K.; 1999; A Framework for Integrated Risk Management in Information Technology; MSB University Press; ISSN: 0-002-5174-7.

[BOOK 03]

Booker F.M.; 2003; An ERM Framework: Developing Effective Risk Management Strategies to Protect Your Organisation; Grant Thornton; White Paper August 2003.

[BORN 04]

Bornman W.G., Labuschagne L.; 2004; A Comparative Framework for Evaluating Information Security Risk Management Methodologies. Conference proceedings of the 4th annual Information Security South Africa held in Midrand, South Africa.

229

Bibliography

[BRIN 04]

Briney, A.; 2004; Parker’s Plan; Information Security Magazine Online; Available from http:// infosecuritymag.techtarget.com/ articles/1999/parker.shtml; Accessed 14 December 2004

[BROW]

Brown J.P.W.; d.u.; Enterprise Risk Management; New Energy Associates – White Paper; Available from http://www.newenergyassoc.com; Accessed October 2003.

[CFAC 92]

The Committee of the Financial Aspects of Corporate Governance and Gee and Co. Ltd.; 1992; The Financial Aspects of Corporate Governance; Burgess Science Press, Great Britain.

[COBI01 00]

IT Governance Institute; 2000; CobiT 3rd Edition – Framework; Information Systems Audit and Control Foundation; ISBN: 1893209-14-8.

[COBI02 00]

IT Governance Institute; 2000; CobiT 3rd Edition – Executive Summary; Information Systems Audit and Control Foundation; ISBN: 1-893209-15-6.

[COBI03 00]

IT Governance Institute; 2000; CobiT 3rd Edition –Management Guidelines; Information Systems Audit and Control Foundation; ISBN: 1-893209-12-1.

[COBI04 00]

IT Governance Institute; 2000; CobiT 3rd Edition – Control Objectives; Information Systems Audit and Control Foundation; ISBN: 1-893209-17-2.

[COBI05 00]

IT Governance Institute; 2000; CobiT 3rd Edition –Audit Guidelines; Information Systems Audit and Control Foundation; ISBN: 1-893209-18-0.

[COBI06 00]

IT Governance Institute; 2000; CobiT 3rd Edition –Implementation Toolset; Information Systems Audit and Control Foundation; ISBN: 0-893209-16-14.

[CONR 03]

Conrow E.H.; 2003; Effective Risk Management: Some Keys to Success. American Institute of Aeronautics and Astronautics. ISBN: 1-56347-581-2.

[COSO]

The Committee of Sponsoring Organizations of the Treadway Commission; d.u.; Enterprise Risk Management Framework – Executive Summary (Draft); Available from http://www.erm.coso.org.

[CRAM01 96]

CCTA – The Central Computer and Telecommunication Agency; 1996; CRAMM Management Guide. Crown Copyright.

[CRAM02 96]

CCTA – The Central Computer and Telecommunication Agency; 1996; CRAMM User Guide. Crown Copyright.

230

Bibliography

[CRAM 03]

Insight Consulting - CRAMM Methodology; http://www.cramm.com; Accessed: 31 March 2003

[DARC 01]

D’Arcy S.P.; 2001; Enterprise Risk Management; Journal of Risk Management of Korea Volume 12, Number 1.

[DICT 04]

Dictionary.com; 2004; Terms; “Tactical”; http://www.dictionary.com; Accessed July 2004.

[DJDV 01]

Daníelsson J., Jorgensen B., de Vries C.G.; 2001; Incentives for Effective Risk Management; Tinbergen Institute; Available from http://www.tinbergen.nl.

[DPWS 01]

NSW Department of Public Works and Services Cataloguing-inPublication data; 2001; Risk management guideline; DPWS Report Number 01055.

[ECT 02]

Republic of South Africa; 2002; Electronic Communication and Transactions Act, 2002; Government Gazette, Volume 446.

[EGLI 04]

Eglin Air Force Base; 2004; Glossary; “Strategic Management”; www.eglin.af.mil/46tw/StrategicPlan/glossary.htm; Accessed July 2004.

[EIMM 01]

The Economist Intelligence Unit and MMC Enterprise Risk; 2001; Enterprise Risk Management: Implementing New Solutions (Executive Briefing); Brochure from MMC Enterprise Risk Inc.

[EXIS 04]

Exist-db.org; 2004; eXist Open Source XML Database; Available from http://exist.sourceforge.net/; Accessed 29 July 2004.

[FAEL 99]

Faul M.A., Everingham G.K., Lomax A.C.; 1999; Financial Accounting – Fifth Edition; Butterworths, South Africa; ISBN: 0409-10323-3.

[FRAM 03]

Frame J.D.; 2003; Managing Risk in Organisations: A Guide for Managers; Jossey-Bass. ISBN: 0-7879-6518-9.

[GALB 02]

Galbraith J.R.; 2002; Designing Organisations: An Executive Guide to Strategy, Structure and Process; Jossey-Bass; ISBN: 07879-5745-3.

[GGHL 97]

Griesel B.M., Greyling L., Heyns J. vd S., Loots A.E., Schoeman C.H.; 1997; Inleiding tot Ekonomie; Decorata Uitgewers; ISBN: 1-86813-8

231

Bibliography

[GUAR 86]

Guarro S.B., Garcia A.A, Wood C.C., Prassinos P.G.; 1986; Livermore Risk Analysis Methodology: A Quantitative Approach to Management of the Risk Associated with the Operation of Information Systems; Lawrence Livermore National Laboratory; Manuscript submitted for publication: Computer and Communication ’86 Conference.

[HEJS 99]

Hellriegel D., Jackson S.E., Slocum J.W. Jr.; 1999; Management – 8th Edition; International Thomson Publishing; ISBN: 0-5388762-7.

[HOUM]

Houmb S.H., den Braber F., Lund M.S., Stølen K.; d.u.; Towards a UML Profile for Model-Based Risk Assessment; Unpublished Manuscript.

[INCA 99]

The Institute of Chartered Accountants in England and Wales; 1999; Internal Control – Guidance for Directors on the Combined Code; ISBN: 1-84152-010-1.

[INSI01 03]

Insight Consulting; 2003; CRAMM Expert Walkthrough and Overview – CRAMM V (Computer Program).

[INSI02 03]

Insight Consulting; 2003; Risk Management – CRAMM V; CRAMM V Risk Management (Brochure); Available from http://www.insight.com.

[INSI03 03]

Insight Consulting; 2003; CRAMM V – Website; http://www.cramm.com; Accessed 17 March 2003.

[ISF 00]

Information Security Forum; 2000; FIRM: Fundamental Information Risk Management – Implementation Guide.

[ISF 03]

Information Security Forum; 2003; The Standard of Good Practice for Information Security.

[ISO 02]

ISO / IEC; 2002; ISO / IEC Guide 73, Risk Management – Vocabulary – Guidelines for use in standards.

[IST 03]

Information Society Technologies (IST) Programme; 2003; The CORAS methodology for Model-Based Risk Assessment – Platform Documentation; Platform available from http://coras.sourceforge.net.

[ITGO 03]

IT Governance Institute; 2003; IT Control Objective for SarbanesOxley; ISBN: 1-893209-67-9.

[ITIL01 02]

The Centre of IT Service Management; 2002; Planning to Implement IT Service Management; The Stationary Office; ISBN: 0-11-330877-9.

232

Bibliography

[ITIL02 02]

The Centre of IT Service Management; 2002; ICT Infrastructure Management; The Stationary Office; ISBN: 0-11-330865-5.

[ITIL03 02]

The Centre of IT Service Management; 2002; Application Management; The Stationary Office; ISBN: 0-11-330866-3.

[ITIL04 02]

The Centre of IT Service Management; 2002; Introduction to ITIL; Online brochure available from http://www.cism.com.sg.; Accessed June 2003.

[ITIL05 02]

The Centre of IT Service Management; 2002; Best Practice for Service Support; The Stationary Office; ISBN: 0-11-330865-5.

[ITIL06 02]

The Centre of IT Service Management; 2002; Best Practice for Service Delivery; The Stationary Office; ISBN: 0-11-330017-4.

[ITIL07 02]

The Centre of IT Service Management; 2002; The Story of ITIL ®; Online brochure available from http://www.cism.com.sg.; Accessed June 2003.

[J2SE 04]

Sun Microsystems; 2004; Java 2 Platform, Standard Edition; Software Package; Available from http://java.sun.com/j2se/1.4.2/download.html; Accessed 29 July 2004.

[KHWA 00]

Khawaja, A.; 2000; Enterprise-wide risk management and the impact of XML. ERisk.com – Unpublished Manuscript; Available online at www.erisk.com, 17 February 2000.

[KING 02]

King Committee on Corporate Governance; 2002; King Report on Corporate Governance for South Africa; Institute of Directors. ISBN: 0-620-28851-5.

[KPMG 01]

KPMG, US; 2001; Understanding Enterprise Risk Management: An Emerging Model for Building Shareholder Value; White Paper of KPMG’s Assurance and Advisory Services Centre. Available from http://www.kpmg.com.

[LABU 92]

Labuschagne L.; 1992; Inligtingsekerheid met spesifieke verwysing na Risiko-Ontleding. Rand Afrikaans University, Johannesburg, South Africa.

[LABU 99]

Labuschagne L., Eloff J.H.P.; 1999; Information Security Risk Management Methodologies Generations. Unpublished Manuscript.

[LAM 00]

Lam J.; 2003; Enterprise-wide risk management and the role of the chief risk officer; ERisk 2003 also available from http://www.erisk.com.

233

Bibliography

[LCBI 02]

Longley-Cook A.G., Bennet N.E., Isakina V.A.; 2002; Integrated Risk Management, Session 35PD; Proceedings of the 2002 Valuation Actuary Symposium held at Lake Buena Vista, Florida.

[LOMP 00]

Longnecker J.G., Moore C.W., Petty J.W.; 2000; Small Business Management: An Entrepreneurial Emphasis; South-West College Publishing; ISBN: 0-538-89015-0.

[MCGR 04]

McGraw-Hill Online Learning Centre; 2004; Glossary; “Strategic Management; Available from http://highered.mcgrawhill.com/sites. /0072443715/student_view0/glossary.html

[MCSL 94]

McGill M.E., Slocum J.W.; 1994; The Smarter Organisation: How to Build a Business that Learns to Adapt to Marketplace Needs; John Willey and Sons; ISBN:0-4715-9846-1.

[MICR 04]

Microsoft; 2004; Microsoft .Net; Available from: http://www.microsoft.com/net/; Accessed 29 July 2004.

[MILL 91]

Miller K.D.; 1991; A Framework for Integrated Risk Management in International Business; Purdue University; Article published in Journal of International Business Studies, Second Quarter, 1991.

[MULL 99]

Müller A.; 1999; Integrated Risk Management: A Holistic Risk Management Approach for the Insurance Industry; Unpublished Manuscript.

[NEUM 95]

Neuman P.G.; 1995; Computer Related Risks. The ACM Press. ISBN: 0-201-55805-X.

[OLIV 99]

Olivier M.S.; 1999; Information Technology Research: A Practical Guide; Martin S. Olivier.

[OXFO 80]

Oxford University Press; 1980; The Oxford Illustrated Dictionary; Book Club Associates London.

[PAIA 00]

Republic of South Africa; 2000; Promotion of Access to Information Act; Enacted by the Parliament of the Republic of South Africa.

[PARK 02]

Parker, D.B.; 2002; Motivating the Workforce to Support Security Objectives: A Long Term View; Fighting Computer Crime, A New Framework for Protecting Information (Chapter 16); John Wiley & Sons 1998

[PARK 04]

Parker, D.B.; 2004; Advancing Security; Information Security Magazine Online; Available from http://infosecuritymag.techtarget.com/articles/1999/parker2.shtml Accessed: 14 December 2004

234

Bibliography

[PELT 01]

Peltier, T.R.; 2001; Information Security Risk Analysis; Auerbach; ISBN: 0-8493-0880.

[PFLE 97]

Pfleeger C.; 1997; Security in Computing; Prentice Hall; ISBN:013-337486-6.

[PUSC 02]

The Public Service Commission; 2002; Integrated Risk Management in the Public Service – A Provincial Perspective; Report.

[PWC 00]

PricewaterhouseCoopers; 2000; Risk Management - Building Competitive Advantage for Tomorrow’s Leading Investment Managers; Brochure available from http://www.pwcglobal.com; Accessed October 2003.

[REW 01]

Rew S.; 2001; Beyond structures: Paper for a Performance and Innovation Unit; Seminar on the future structures of governments; Unpublished Manuscript.

[RISK 04]

RiskGlossary.com; 2004; Terms; “Operational Risk”; Available from http://www.riskglossary.com/articles/operational_risk.htm; Accessed July 2004.

[ROB 00]

Rob C., Coronel C.; 2000; Database Systems: Design, Implementation, and Management, Fourth Edition. Course Technology. ISBN: 0-7600-1090-0.

[SABS 00]

South African Bureau of Standards (SABS); 2000; Information Technology – Code of Practice for Information Technology Risk Management, SABS ISO/IEC 17799. ISBN: 0-626-12835-8.

[SAIC 02]

South African Institute of Chartered Accountants; 2001; SAIGR Handleiding; ISBN: 0-86983-387-1.

[SANS 03]

Standards South Africa; 2003; SANS 17799-2:2003 – Information security management systems, Part 2: Specification with guidance for use; Standards South Africa – South African National Standard; ISBN:0-626-14601-1.

[SCOL 01]

SC Magazine; 2001; CRAMM; West Coast Publishing; Reprinted from SC On-line. Available from http://www.cramm.com/downloads; Accessed October 2003.

[SCHA 02]

Schwalbe K., 2002; Information Technology Project Management, 2nd Edition; Thomson Learning; ISBN: 0-619-03528-5.

[SCHN 00]

Schneier B.; 2000; Secrets & Lies – Digital Security in a Networked World; John Wiley & Sons Inc.; ISBN: 0-471-253111.

235

Bibliography

[SOX 02]

Senate and House of Representatives of the United States of America; 2002; Sarbanes-Oxley Act of 2002; H.R. 3763.

[STCJ 00]

Strydom J.W., Cant M.C., Jooste C.J., 2000; Marketing Management; Juta and Co, Ltd.; ISBN: 0-7021-5159-9.

[STEV 03]

Stevens F.; 2003; Measuring the Value of Information Security; (Personal Presentation).

[STØL]

Stølen K., den Braber F., Dimitrakos T., Fredriksen R., Gran B.A, Houmb S., Lund M.S., Stamatiou Y.C., Aagedal J.Ø.; Modelbased Risk Assessment – The CORAS Approach; d.u.; Unpublished Article.

[STON 01]

Stoneburger G., Coguen A., Feringa A.; 2001. Risk Management Guide for Information Technology Systems. NIST – National Institute of Standards and Technology. Special Publication 80030. US Department of Commerce.

[STSH 03]

Stock M., Sharman R.; 2003; Enterprise Risk Management – Fit for the Future; WorldPower 2003, KPMG LLP – UK.

[THOG 97]

Thomas H., O'Neal D., Ghertman M.; 1997; Strategy, Structure and Style; John Wiley and Sons; ISBN: 0-471-96882-X.

[TUDO 01]

Tudor J.K.; 2001; Information Security Architecture – An Integrated Approach to Security in the Organisation. CRC Press. ISBN: 0-8493-9988-2.

[TRCA 01]

Treasury Board of Canada; 2001; Integrated Risk Management Framework; ISBN: 0-662-65673-3.

[WASO 01]

Wason S.; 2001; Enterprise Risk Management – Implementing New Solutions; MMC Presentation at AFIR Colloquium, Toronto September 7, 2001.

[W3C 00]

W3C; 2000; Extensible Markup Language (XML) 1.0 (Second Edition); Available from http://www.w3c.org/TR/2000/REC-xml20001006; Accessed on 30 June 2003.

236