- Email: [email protected]
Operationalizing IT Risk Management
COSE 2206.qxd
11/09/2003
11:46
Page 487
Operationalizing IT risk management global organisations conducted during 2002, it was found that all conducted some form of risk assessment to assist in the management of security risks. However, when we analysed the risks that they addressed, three of the four organisations had major gaps in their risk assessment coverage that could result in significant risks being missed . We wondered: why did the gaps exist; are there inhibitors to effective risk assessment; are there blind spots; are approaches to risk assessment deficient in some way; how could we make the process of risk assessment more robust but easier to do? This paper seeks to address some of these questions.
The gaps Many organisations struggle with risk assessment and some believe that it shouldn’t be practiced at all! Many do some form of risk assessment, but often badly, or incompletely. Some just don’t bother, preferring an approach which relies on standards and baselines to manage the common risks, some just ignore the problem and trust to hope. We looked at four major global organisations and found that although they all undertook risk assessment in one form or another, no organisation had a good overview
of all of the key risks, and three of the four had major gaps. The approaches to risk and the major gaps identified in the approaches are summarized in the table below:
Robert S. Coles & Rolf Moulton
In each of the organisations that we examined there were clear deficiencies in the process whereby they:
[email protected]
[email protected]
In a study of four major
1. Focussed on IT issues rather than risks related to the business 2. Did not: • get clear and unambiguous ownership by the real risk owners; • did not get clear buy-in from those who must implement the safeguards; • follow through with aggressive confirmation that the controls had been implemented and operated as designed. Having established that risk assessment seems to be very difficult to do well, we searched for why this might be so. We found a number of inhibitors to risk assessment which either encouraged organisations to do nothing, or resulted in the gaps that we found in the content and process of risk assessment.
Table 1
Company
Risk Approach Adopted
1
Adopted an effective risk management approach based on business process leaders with input from other stakeholders. Risk management approach led by IT.
2
3
4
Major gaps in Approach
Adopted a risk management approach based on business process leaders. Business process leaders assumed all risks related to information in IT operations belonged to the IT division. Informal team based approach risk management was adopted, including business and IT people.
Business Process Managers assumed that all of the risks related to information in IT applications belong to IT and therefore did not seek to assess or manage any IT risks. Business Process management did not participate in the IT aspects of risk management. They assumed that IT did this. Missed key risks related to infrastructure, and possibly others.
0167-4048/03 ©2003 Elsevier Ltd. All rights reserved.
487
COSE 2206.qxd
11/09/2003
11:46
Page 488
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
Robert S. Coles MBA, MBCS, CISM
Inhibitors
Robert is the Security Service Leader for KPMG LLP in the UK. He is responsible for the development and delivery of a wide range of security services from strategy and architecture to managed security services, implementation and testing and certification services. Robert is also a member of the Certified Information Security Manager exam board and BDD2 and Panel 3 the UK committees responsible for the development of BS7799.
There seems to be a number of “inhibitors” or reasons why organisations are either poor at assessing risks, or don’t bother at all.
Rolf Moulton, CISSP, CISA, CCP Rolf Moulton is Director of Risk Reduction Solutions, Inc., where he provides risk management and security consulting services to clients. He serves on the International Board of Referees of Computers & Security, and is a member of the Board of (ISC)2. He was formerly Head of IT Risk Management, and responsible for information security at Unilever; as well as a member of BDD2 the UK committee responsible for the development of BS7799. He also has served as Director of the Computer Security Services Unit at the Department of Investigation, City of New York, as was a senior security consultant at BP America.
488
The main reason for doing nothing appears to be management perceptions about how big a problem information risks actually are, time and resources needed to study the issue, and why any more effort was needed. For many managers, we believe, the decision making goes something like this: 1
we have suffered no significant losses in the past, so:
2
the current protection level must be about right, therefore:
3
risk assessment should not be a top priority for us right now.
Of course, the flaw in this logic is that this is effectively a blind gamble. There is no real consideration of specific risk events, or their potential impact. They are relying on luck rather than judgement. The logic changes pretty quickly when an organisation gets hit – there can be a knee jerk reaction to throw some money at resolving the immediate problem, recovering from the incident, but often this doesn’t address the route cause, just the effects. What is really needed is a continuing investment of time, money and energy to ensure that the risk management process is working. Sometimes the reason given for not undertaking risk assessment is the cost “we just don’t have enough time/energy/money to do it properly” – however, this is really just a manifestation of the logic noted above. It is just not high up enough on the management agenda because significant problems haven’t hit in the past. Some of the security managers that we spoke to in this study, as well as during interviews with other companies, said that they sometimes wished that they had a really big security breach
just to get some management attention to address some of the known problems. Sometimes the reason given is that there is no clear link between specific risks and controls that can be implemented to manage those risks. As an example, the information security manager at Company 1 commented that “business people don’t always understand security issues and therefore can’t see the point in spending money up front to get it right.” Others give the reason that technology is changing so quickly that there just isn’t time to undertake proper risk assessment and implement the desired level of control. By the time the assessment and design is finished – the technology has all changed and you have to start again. The reasons for doing risk assessment badly seem to be related to flaws in the processes and/or approaches and tools used. There are a number of different approaches to risk assessment, and when and how they are used may be related to the background and/or training of the person facilitating the approach. • Most from a security background generally take a traditional risk assessment approach focusing on Confidentiality, Integrity and Availability risks. The approach either starts with examining assets, and prioritises threat and vulnerability activity focused on the largest assets; or it starts with threats and prioritises activity based on the largest threats. The security perspective often excludes business processes entirely and focuses specifically on technical threats and vulnerabilities. • Additionally, those from a computer security background often focus on specific infrastructure platforms or systems and don’t generally address business processes. • Those from an audit background take a different approach from those with a security background, sometimes focusing on
COSE 2206.qxd
11/09/2003
11:46
Page 489
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
Business Process: Information Risk Management (BPIRM) Our approach has two elements: • a process for ensuring “ownership” of information risks by the real risk owners, identifying the risks to be managed, agreeing priorities and a very strong requirement for a feedback loop to ensure that controls are implemented as designed and monitored to ensure that they continue to function as implemented.
Assess risks, create risk profile for process and applications
RISKS Opportunities Contraints Threats Technologies Interdependance
NT
E EM
t PL es IM dt an ions nt t me olu ple l s Im ontro c
Define process, information and IT requirements
The overall BPIRM process has six components, linked by a feedback loop, as follows:
ASSESS
DEFINE
The process
Figure 1
INITIATE Identify business process goals, environmental factors and resource contraints
• a content model which provides focus to ensure that all the right people are involved in the decision making and all the right risk areas are considered, and that those decisions are communicated and implemented effectively. Standard Service Level Agreements (SLAs) between business process owners and “IT” are seen as a key component of the communications, implementation and follow-up process.
• Define – this phase identifies the requirements. Requirements might be information requirements (such as the need for key information to be generated on time, completely and accurately), process requirements (such as requirements for all customer orders to be met within a certain time period) or IT requirements (such as
GE
All of these approaches seem to be flawed as the different perspectives all miss important elements. So we synthesized a new approach, which we named Business Process: Information Risk Management. This approach combines what we felt was the best of the pure security focus, together with the best of the pure business focus, to come up with an approach to address all of the gaps in the organisations that we examined. It is a pragmatic approach that relies on an examination of potential losses as the key driver for controls design, rather than a theoretical examination of potential impacts and probabilities of threats and vulnerabilities.
• Initiate – this is the starting point. The purpose of this phase is to make sure that the focus is on determining what the business process is trying to achieve, what is needed to get the job done, and what could adversely impact hitting the targets. Kick off must start with the business process – this is where all of the impact of the risks ultimately hit. We start with an initial step of identifying the purpose and goals of the process. Without these it is difficult to assess how any individual risk which impairs the process would ultimately affect the business. We also look define and consider any external environmental factors to provide the context for the risk assessment, and any resource constraints that could affect the approach that we might take.
O inc pera ide te nts co , v ntro eri fy ls, m se rvi anag ce MA lev e NA els
business processes – and not really getting down to the technical detail.
Confirm adequacy of controls / redefine
CONFIRM
489
COSE 2206.qxd
11/09/2003
11:46
Page 490
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
peak response times not to exceed a certain maximum limit). These requirements relate to the key objectives that could fail to be met if a risk was to occur. They allow us to focus our risk assessment in the key areas of loss. • Assess – this is the core of the process which relates the requirements to how well the controls address them. This examines each of the loss areas and looks at how to control or otherwise mitigate/transfer any potential losses – either through minimising the impact, minimising the likelihood of the loss occurring, changing the business process, or transferring the risk. It looks at how controls can detect breaches and quantify losses and/or prevent them from happening. This process relies on using Reasonable Information Protection Levels (RIPLs) to allow easy configuration of rules to meet standard protection requirements that relate sensitivity of the information to controls within the overall business process, as well as the IT application and the infrastructure. • Implement – this is the process of establishing and testing the controls in operation. This phase of the process is the doing element – making sure that what has been designed is actually put in place and that service levels for the operation of the controls are realistic. • Manage – this is the daily operation of the controls. This part of the process is designed to ensure that control expectations are consistently defined in a Service Level Agreement (SLA); that service delivery is monitored that expectations are met; and that any incidents are reported, documented and effectively managed through to conclusion. • Confirm – this is the process of ensuring that risks and associated controls are actually being managed and are effective at the specified level(s). And, especially that
490
there is an ongoing process that takes into account new risks that may have arisen since the last assessment.
The content The BPIRM content model is used to guide the process to cover all of the key risk loss areas. The model is based on a “value-chain” standardised picture of a business which seeks to capture all of the key elements of a business process. Specifically, the BPIRM model provides the means for the risk manager to define and develop absolute clarity of risk ownership. It is intended for use within business processes. However, the model may be used with business applications where business processes are not adequately defined and/or to facilitate looking at subprocesses or components of larger integrated applications. In the outer layer, the executive leadership of an organization seeks to maximize the overall enterprise performance. It is also the overall business owner of risks related to the organization. Business processes are used to facilitate management of the organization. The number of processes and the complexity of the processes will vary. As an example, a process may involve product fulfillment. It could include making, delivering a product or service to a customer, as well as collecting a fee for that product or service. In turn, customer expectations may be influenced by perception of a need(s), what is required to meet that need, the products and services that are available to meet the need, and perceived “value.” For branded products, a perceived value that is higher than a competitor’s product is critical to long term brand value and reputation, and hence enterprise performance. At the core of the model is the process itself, and its constituent sub-processes and elements – these are made up from the data, information
COSE 2206.qxd
11/09/2003
11:46
Page 491
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
OVERALL BUSINESS OWNERSHIP Business process leadership and people resource
Information and IT people resource
CE
ion
ices
AN
tat pu
SE P
EF
OR M
Re
Reassurance
serv
Prod ucts &
GOVERNANCE
GOVERNANCE
CE
RI RP TE EN
Technology
e
cy
In the BPIRM model, process management has primary responsibility for risk management including responsibility for IT governance, even if it may be delegated to IT leadership for direct implementation as secondary risk owners. Where business process owners treat IT as a “blue box,” governance of the IT function may simply be cost minimization with a lack of any adequate risk management
Infrastructure NIGT. Op-system Network Server Workstation Third parties / suppliers
u val
Reassurance is an after the fact check to ensure that the governance function is properly executed by business leadership. The assumption is that reassurance is performed by an independent function, such as an internal audit department, that is not directly involved in management of the business process itself.
Priva
Information Applications
nd
Subprocesses Data
AN RM FO
PE Bra
Governance, which may also be termed as “due diligence,” is the assurance part of the process where quality control, adherence to corporate policies, and external laws and regulations are addressed.
SE RI
Governance and Reassurance note:
RP
Information and IT (sub) process leadership
Business process leadership and people resource This is the primary activities function that has overall responsibility for making and delivering the product or service; governance is an implied part of leadership. The employees who make and deliver the product or service are included within this layer. The IT process leadership is assumed to have little or no control of the management of this resource.
TE
The model has 7 layers within a business process ownership framework; some layers have multiple subcomponents. They are:
Figure 2
EN
and applications upon which the process is reliant. The model also considers the staff and management who operate the processes and the IT, and the technology and infrastructure upon which the applications are operated. Consideration is also given too those outside of the organisation – the third-parties (customers and suppliers) who are the inputs and outputs of the process.
and control. Governance is reflected as a cross layered component to ensure that this is not overlooked. The governance and reassurance roles are fundamental issues that the model seeks to differentiate and address.
IT process leadership IT process leadership is directly responsible for meeting overall business process information and IT requirements. This specifically includes the IT policies and guidance, as well as the IT compliance checking needed to meet overall corporate governance requirements. This function and the IT process may be fully or partially integrated into the business process, as depicted by the dashed line. Or, as noted above, business process leadership may treat IT as an isolated “blue box” and attempt to ignore the related values, liabilities and risks associated with the IT function and process.
IT people resource The people who are directly involved with the IT process/application(s) that converts data into information, as depicted in this layer. The layer includes the people who directly work on
491
COSE 2206.qxd
11/09/2003
11:46
Page 492
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
the process/application and may extend into the infrastructure layer. IT people may also include third parties and suppliers. Job functions can include information management, application designers, programmers, and software support. (Data entry would normally be performed by people as part of the business process, as described above.) Network support, desktop support, and other staff collectively referred to as “operations support” would normally be part of the infrastructure layer as described below.
Data>Subprocesses/Applications> Information IT subprocess/application are used to transform data into information. This is similar to the production line of a factory, except that it may be a continuous loop where the information may be stored and become input as data to the next cycle in the process.
Infrastructure Infrastructure includes IT operations people plus the communications and equipment that is needed to process data into information. This may layer may include: • infrastructure management; • information center(s) to physically house the equipment; • operating system and support; • communications network that connects people and equipment; • servers, which are computers used to store and process data/information; • desktops, laptops and other devices used to access the process/application.
Third parties/Suppliers Personnel who are not company employees and who are part of the IT process are considered as third parties. Third parties include the suppliers of IT and
492
communications equipment and services, as well as information services.
Technology Technology has been shown as a layer to represent the value and risks related to the use of technology itself. The BPIRM implementation approach addresses the weaknesses that we have found in other approaches in that: • Business risk takers own the process – the buy-in approach adopted by other models often does not fully engage with the risk takers; • There is absolute “clarity of responsibility” – the content model of BPIRM provides a modelling tool to help ensure that risks do not “slip through the gaps” of unclear ownership; • The process is “minimalist” and “practical” to get key stakeholders to fully engage and participate; • “Risk based SLAs” are used to ensure that risks and control requirements are fully specified, then met by the controls in operation.
Summary and Conclusions The objective of risk management is not to calculate a risk score value. Rather, the objective of risk management is to enable a risk owner to manage risk(s) by getting appropriate controls in place where they are needed. To do this, risk owners need to understand the real risks that the organisation is up against so that they can manage them in the context of the losses that are likely to be incurred. This requires that there be absolute clarity of responsibilities and an ongoing firm determination to make sure that appropriate and cost effective controls are implemented and continue to function as intended.
COSE 2206.qxd
11/09/2003
11:46
Page 493
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
Risk management needs to be properly focused on business processes that generate both revenue and liabilities so that the expected returns obtained are worth the resources spent. Conducting risk assessments should not be long, protracted and painful for business process managers, nor should they become an expensive and all-consuming end unto itself. Where a BPIRM analysis indicates further work is needed for information systems, IT managers may then wish to use detailed quantitative tools to work through the value and return on investment of alternative security measures.
We believe that the BPIRM model and approach provide a practical alternative to approaches that are currently being used. They focus on the real business risks and the owners of those risks. They are practical and minimalist, and they are intended to reduce the likelihood of the risk manager becoming consumed with the process and risk score values. This article is part of a planned series of articles on BPIRM and how to implement it. The authors will welcome comments from readers, especially those related to implementing the BPIRM model and process.
493
11/09/2003
11:46
Page 487
Operationalizing IT risk management global organisations conducted during 2002, it was found that all conducted some form of risk assessment to assist in the management of security risks. However, when we analysed the risks that they addressed, three of the four organisations had major gaps in their risk assessment coverage that could result in significant risks being missed . We wondered: why did the gaps exist; are there inhibitors to effective risk assessment; are there blind spots; are approaches to risk assessment deficient in some way; how could we make the process of risk assessment more robust but easier to do? This paper seeks to address some of these questions.
The gaps Many organisations struggle with risk assessment and some believe that it shouldn’t be practiced at all! Many do some form of risk assessment, but often badly, or incompletely. Some just don’t bother, preferring an approach which relies on standards and baselines to manage the common risks, some just ignore the problem and trust to hope. We looked at four major global organisations and found that although they all undertook risk assessment in one form or another, no organisation had a good overview
of all of the key risks, and three of the four had major gaps. The approaches to risk and the major gaps identified in the approaches are summarized in the table below:
Robert S. Coles & Rolf Moulton
In each of the organisations that we examined there were clear deficiencies in the process whereby they:
[email protected]
[email protected]
In a study of four major
1. Focussed on IT issues rather than risks related to the business 2. Did not: • get clear and unambiguous ownership by the real risk owners; • did not get clear buy-in from those who must implement the safeguards; • follow through with aggressive confirmation that the controls had been implemented and operated as designed. Having established that risk assessment seems to be very difficult to do well, we searched for why this might be so. We found a number of inhibitors to risk assessment which either encouraged organisations to do nothing, or resulted in the gaps that we found in the content and process of risk assessment.
Table 1
Company
Risk Approach Adopted
1
Adopted an effective risk management approach based on business process leaders with input from other stakeholders. Risk management approach led by IT.
2
3
4
Major gaps in Approach
Adopted a risk management approach based on business process leaders. Business process leaders assumed all risks related to information in IT operations belonged to the IT division. Informal team based approach risk management was adopted, including business and IT people.
Business Process Managers assumed that all of the risks related to information in IT applications belong to IT and therefore did not seek to assess or manage any IT risks. Business Process management did not participate in the IT aspects of risk management. They assumed that IT did this. Missed key risks related to infrastructure, and possibly others.
0167-4048/03 ©2003 Elsevier Ltd. All rights reserved.
487
COSE 2206.qxd
11/09/2003
11:46
Page 488
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
Robert S. Coles MBA, MBCS, CISM
Inhibitors
Robert is the Security Service Leader for KPMG LLP in the UK. He is responsible for the development and delivery of a wide range of security services from strategy and architecture to managed security services, implementation and testing and certification services. Robert is also a member of the Certified Information Security Manager exam board and BDD2 and Panel 3 the UK committees responsible for the development of BS7799.
There seems to be a number of “inhibitors” or reasons why organisations are either poor at assessing risks, or don’t bother at all.
Rolf Moulton, CISSP, CISA, CCP Rolf Moulton is Director of Risk Reduction Solutions, Inc., where he provides risk management and security consulting services to clients. He serves on the International Board of Referees of Computers & Security, and is a member of the Board of (ISC)2. He was formerly Head of IT Risk Management, and responsible for information security at Unilever; as well as a member of BDD2 the UK committee responsible for the development of BS7799. He also has served as Director of the Computer Security Services Unit at the Department of Investigation, City of New York, as was a senior security consultant at BP America.
488
The main reason for doing nothing appears to be management perceptions about how big a problem information risks actually are, time and resources needed to study the issue, and why any more effort was needed. For many managers, we believe, the decision making goes something like this: 1
we have suffered no significant losses in the past, so:
2
the current protection level must be about right, therefore:
3
risk assessment should not be a top priority for us right now.
Of course, the flaw in this logic is that this is effectively a blind gamble. There is no real consideration of specific risk events, or their potential impact. They are relying on luck rather than judgement. The logic changes pretty quickly when an organisation gets hit – there can be a knee jerk reaction to throw some money at resolving the immediate problem, recovering from the incident, but often this doesn’t address the route cause, just the effects. What is really needed is a continuing investment of time, money and energy to ensure that the risk management process is working. Sometimes the reason given for not undertaking risk assessment is the cost “we just don’t have enough time/energy/money to do it properly” – however, this is really just a manifestation of the logic noted above. It is just not high up enough on the management agenda because significant problems haven’t hit in the past. Some of the security managers that we spoke to in this study, as well as during interviews with other companies, said that they sometimes wished that they had a really big security breach
just to get some management attention to address some of the known problems. Sometimes the reason given is that there is no clear link between specific risks and controls that can be implemented to manage those risks. As an example, the information security manager at Company 1 commented that “business people don’t always understand security issues and therefore can’t see the point in spending money up front to get it right.” Others give the reason that technology is changing so quickly that there just isn’t time to undertake proper risk assessment and implement the desired level of control. By the time the assessment and design is finished – the technology has all changed and you have to start again. The reasons for doing risk assessment badly seem to be related to flaws in the processes and/or approaches and tools used. There are a number of different approaches to risk assessment, and when and how they are used may be related to the background and/or training of the person facilitating the approach. • Most from a security background generally take a traditional risk assessment approach focusing on Confidentiality, Integrity and Availability risks. The approach either starts with examining assets, and prioritises threat and vulnerability activity focused on the largest assets; or it starts with threats and prioritises activity based on the largest threats. The security perspective often excludes business processes entirely and focuses specifically on technical threats and vulnerabilities. • Additionally, those from a computer security background often focus on specific infrastructure platforms or systems and don’t generally address business processes. • Those from an audit background take a different approach from those with a security background, sometimes focusing on
COSE 2206.qxd
11/09/2003
11:46
Page 489
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
Business Process: Information Risk Management (BPIRM) Our approach has two elements: • a process for ensuring “ownership” of information risks by the real risk owners, identifying the risks to be managed, agreeing priorities and a very strong requirement for a feedback loop to ensure that controls are implemented as designed and monitored to ensure that they continue to function as implemented.
Assess risks, create risk profile for process and applications
RISKS Opportunities Contraints Threats Technologies Interdependance
NT
E EM
t PL es IM dt an ions nt t me olu ple l s Im ontro c
Define process, information and IT requirements
The overall BPIRM process has six components, linked by a feedback loop, as follows:
ASSESS
DEFINE
The process
Figure 1
INITIATE Identify business process goals, environmental factors and resource contraints
• a content model which provides focus to ensure that all the right people are involved in the decision making and all the right risk areas are considered, and that those decisions are communicated and implemented effectively. Standard Service Level Agreements (SLAs) between business process owners and “IT” are seen as a key component of the communications, implementation and follow-up process.
• Define – this phase identifies the requirements. Requirements might be information requirements (such as the need for key information to be generated on time, completely and accurately), process requirements (such as requirements for all customer orders to be met within a certain time period) or IT requirements (such as
GE
All of these approaches seem to be flawed as the different perspectives all miss important elements. So we synthesized a new approach, which we named Business Process: Information Risk Management. This approach combines what we felt was the best of the pure security focus, together with the best of the pure business focus, to come up with an approach to address all of the gaps in the organisations that we examined. It is a pragmatic approach that relies on an examination of potential losses as the key driver for controls design, rather than a theoretical examination of potential impacts and probabilities of threats and vulnerabilities.
• Initiate – this is the starting point. The purpose of this phase is to make sure that the focus is on determining what the business process is trying to achieve, what is needed to get the job done, and what could adversely impact hitting the targets. Kick off must start with the business process – this is where all of the impact of the risks ultimately hit. We start with an initial step of identifying the purpose and goals of the process. Without these it is difficult to assess how any individual risk which impairs the process would ultimately affect the business. We also look define and consider any external environmental factors to provide the context for the risk assessment, and any resource constraints that could affect the approach that we might take.
O inc pera ide te nts co , v ntro eri fy ls, m se rvi anag ce MA lev e NA els
business processes – and not really getting down to the technical detail.
Confirm adequacy of controls / redefine
CONFIRM
489
COSE 2206.qxd
11/09/2003
11:46
Page 490
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
peak response times not to exceed a certain maximum limit). These requirements relate to the key objectives that could fail to be met if a risk was to occur. They allow us to focus our risk assessment in the key areas of loss. • Assess – this is the core of the process which relates the requirements to how well the controls address them. This examines each of the loss areas and looks at how to control or otherwise mitigate/transfer any potential losses – either through minimising the impact, minimising the likelihood of the loss occurring, changing the business process, or transferring the risk. It looks at how controls can detect breaches and quantify losses and/or prevent them from happening. This process relies on using Reasonable Information Protection Levels (RIPLs) to allow easy configuration of rules to meet standard protection requirements that relate sensitivity of the information to controls within the overall business process, as well as the IT application and the infrastructure. • Implement – this is the process of establishing and testing the controls in operation. This phase of the process is the doing element – making sure that what has been designed is actually put in place and that service levels for the operation of the controls are realistic. • Manage – this is the daily operation of the controls. This part of the process is designed to ensure that control expectations are consistently defined in a Service Level Agreement (SLA); that service delivery is monitored that expectations are met; and that any incidents are reported, documented and effectively managed through to conclusion. • Confirm – this is the process of ensuring that risks and associated controls are actually being managed and are effective at the specified level(s). And, especially that
490
there is an ongoing process that takes into account new risks that may have arisen since the last assessment.
The content The BPIRM content model is used to guide the process to cover all of the key risk loss areas. The model is based on a “value-chain” standardised picture of a business which seeks to capture all of the key elements of a business process. Specifically, the BPIRM model provides the means for the risk manager to define and develop absolute clarity of risk ownership. It is intended for use within business processes. However, the model may be used with business applications where business processes are not adequately defined and/or to facilitate looking at subprocesses or components of larger integrated applications. In the outer layer, the executive leadership of an organization seeks to maximize the overall enterprise performance. It is also the overall business owner of risks related to the organization. Business processes are used to facilitate management of the organization. The number of processes and the complexity of the processes will vary. As an example, a process may involve product fulfillment. It could include making, delivering a product or service to a customer, as well as collecting a fee for that product or service. In turn, customer expectations may be influenced by perception of a need(s), what is required to meet that need, the products and services that are available to meet the need, and perceived “value.” For branded products, a perceived value that is higher than a competitor’s product is critical to long term brand value and reputation, and hence enterprise performance. At the core of the model is the process itself, and its constituent sub-processes and elements – these are made up from the data, information
COSE 2206.qxd
11/09/2003
11:46
Page 491
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
OVERALL BUSINESS OWNERSHIP Business process leadership and people resource
Information and IT people resource
CE
ion
ices
AN
tat pu
SE P
EF
OR M
Re
Reassurance
serv
Prod ucts &
GOVERNANCE
GOVERNANCE
CE
RI RP TE EN
Technology
e
cy
In the BPIRM model, process management has primary responsibility for risk management including responsibility for IT governance, even if it may be delegated to IT leadership for direct implementation as secondary risk owners. Where business process owners treat IT as a “blue box,” governance of the IT function may simply be cost minimization with a lack of any adequate risk management
Infrastructure NIGT. Op-system Network Server Workstation Third parties / suppliers
u val
Reassurance is an after the fact check to ensure that the governance function is properly executed by business leadership. The assumption is that reassurance is performed by an independent function, such as an internal audit department, that is not directly involved in management of the business process itself.
Priva
Information Applications
nd
Subprocesses Data
AN RM FO
PE Bra
Governance, which may also be termed as “due diligence,” is the assurance part of the process where quality control, adherence to corporate policies, and external laws and regulations are addressed.
SE RI
Governance and Reassurance note:
RP
Information and IT (sub) process leadership
Business process leadership and people resource This is the primary activities function that has overall responsibility for making and delivering the product or service; governance is an implied part of leadership. The employees who make and deliver the product or service are included within this layer. The IT process leadership is assumed to have little or no control of the management of this resource.
TE
The model has 7 layers within a business process ownership framework; some layers have multiple subcomponents. They are:
Figure 2
EN
and applications upon which the process is reliant. The model also considers the staff and management who operate the processes and the IT, and the technology and infrastructure upon which the applications are operated. Consideration is also given too those outside of the organisation – the third-parties (customers and suppliers) who are the inputs and outputs of the process.
and control. Governance is reflected as a cross layered component to ensure that this is not overlooked. The governance and reassurance roles are fundamental issues that the model seeks to differentiate and address.
IT process leadership IT process leadership is directly responsible for meeting overall business process information and IT requirements. This specifically includes the IT policies and guidance, as well as the IT compliance checking needed to meet overall corporate governance requirements. This function and the IT process may be fully or partially integrated into the business process, as depicted by the dashed line. Or, as noted above, business process leadership may treat IT as an isolated “blue box” and attempt to ignore the related values, liabilities and risks associated with the IT function and process.
IT people resource The people who are directly involved with the IT process/application(s) that converts data into information, as depicted in this layer. The layer includes the people who directly work on
491
COSE 2206.qxd
11/09/2003
11:46
Page 492
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
the process/application and may extend into the infrastructure layer. IT people may also include third parties and suppliers. Job functions can include information management, application designers, programmers, and software support. (Data entry would normally be performed by people as part of the business process, as described above.) Network support, desktop support, and other staff collectively referred to as “operations support” would normally be part of the infrastructure layer as described below.
Data>Subprocesses/Applications> Information IT subprocess/application are used to transform data into information. This is similar to the production line of a factory, except that it may be a continuous loop where the information may be stored and become input as data to the next cycle in the process.
Infrastructure Infrastructure includes IT operations people plus the communications and equipment that is needed to process data into information. This may layer may include: • infrastructure management; • information center(s) to physically house the equipment; • operating system and support; • communications network that connects people and equipment; • servers, which are computers used to store and process data/information; • desktops, laptops and other devices used to access the process/application.
Third parties/Suppliers Personnel who are not company employees and who are part of the IT process are considered as third parties. Third parties include the suppliers of IT and
492
communications equipment and services, as well as information services.
Technology Technology has been shown as a layer to represent the value and risks related to the use of technology itself. The BPIRM implementation approach addresses the weaknesses that we have found in other approaches in that: • Business risk takers own the process – the buy-in approach adopted by other models often does not fully engage with the risk takers; • There is absolute “clarity of responsibility” – the content model of BPIRM provides a modelling tool to help ensure that risks do not “slip through the gaps” of unclear ownership; • The process is “minimalist” and “practical” to get key stakeholders to fully engage and participate; • “Risk based SLAs” are used to ensure that risks and control requirements are fully specified, then met by the controls in operation.
Summary and Conclusions The objective of risk management is not to calculate a risk score value. Rather, the objective of risk management is to enable a risk owner to manage risk(s) by getting appropriate controls in place where they are needed. To do this, risk owners need to understand the real risks that the organisation is up against so that they can manage them in the context of the losses that are likely to be incurred. This requires that there be absolute clarity of responsibilities and an ongoing firm determination to make sure that appropriate and cost effective controls are implemented and continue to function as intended.
COSE 2206.qxd
11/09/2003
11:46
Page 493
Robert S. Coles & Rolf Moulton Operationalizing IT Risk Management
Risk management needs to be properly focused on business processes that generate both revenue and liabilities so that the expected returns obtained are worth the resources spent. Conducting risk assessments should not be long, protracted and painful for business process managers, nor should they become an expensive and all-consuming end unto itself. Where a BPIRM analysis indicates further work is needed for information systems, IT managers may then wish to use detailed quantitative tools to work through the value and return on investment of alternative security measures.
We believe that the BPIRM model and approach provide a practical alternative to approaches that are currently being used. They focus on the real business risks and the owners of those risks. They are practical and minimalist, and they are intended to reduce the likelihood of the risk manager becoming consumed with the process and risk score values. This article is part of a planned series of articles on BPIRM and how to implement it. The authors will welcome comments from readers, especially those related to implementing the BPIRM model and process.
493