Beating IT Risks

Figure 3.2—Project risk relationships

delivery by individual providers fails to meet your needs. When multiple suppliers are required to work together, a strategy that guides this ‘multi-source’ arrangement is essential – otherwise gaps, overlaps and disconnects occur and assuring the delivery of end-to-end services becomes extremely difficult.

Project risk relationships

Poor management of project risks can drive risks in the implemented service (see Figure 3.2). This translates as IT service continuity and information asset risks, including:

•A late or undelivered project results in a continued reliance on the existing, unimproved IT services.

•Delivery of new and different vulnerabilities, flaws and weaknesses along with the new system. New and changed systems go through a post-implementation period that requires heightened alertness and responsiveness in the user base and IT support team. Defects that must be fixed may require unwelcome outages.

•Information assets may not retain their integrity when being migrated across to the new system, with the introduction of anomalies and inconsistencies.

•Any gaps in training of the user base can become manifest as service degradation after go-live.

Poor management of project risks can drive risks in the implemented product, translating as applications and infrastructure risks, including:

•A ‘quick and dirty’ engineering approach within a project can result in a system that is difficult to operate, support, maintain and enhance.

•Even if the new solution has been effectively engineered, it is still new to the operators and a learning curve must be climbed. Ineffective training and

Note : * Research from Hovav and D’Arcy (2003) indicates that in general the sharemarket does not penalize companies that are not ‘Internet-specific’ companies when they experience such an attack.

The risks and impact of systems failing is the focus of Peter Neumann’s book Computer-Related Risks (1995) and a valuable on-line resource.16 The collection and analysis of diverse failures provides ample evidence that IT risks do in practice result in actual loss events in a wide variety of applications in different industries.

This exploration of the causes and effects points to a wide range of IT risks, catalogued on the following basis:

•Sources of problems arising in system development, including: system conceptualization, requirements definition, system design, hardware and software implementation, support systems, analysis of system concepts and design, analysis of the implementation, evolution and decommission; and

•Sources of problems in system operation and use, including: natural environmental factors, animals, infrastructure factors, hardware malfunctions, software misbehaviour, communication media failures, human limitations in system use

– installation, misuse of the overall environment or of the computer systems – unintentional and intentional misuse.

Importantly, Neumann sets out the system-related causes in the context of human causal factors. In most cases, computers share only part of the blame. Multiple contributing causes are also the rule rather than the exception, illustrating that a compartmentalized approach to managing IT risks is limiting.

Neumann’s focus is on understanding the impact on people and society at large from computer-related failures and drawing lessons to be learned, particularly for systems designers and developers (Neumann, 1998, 2000, 2002). Others have studied IT risks as seen by the public including Internet addiction, isolation, depression and cyber-stalking (Sjoberg and Fromm, 2001).

The ‘misbehaviour’ of computers studied by Neumann spans a wide range of computer systems including robotics, control systems, communication networks, and computers used in planes, ships, spacecraft, nuclear power plants, etc. We focus on a narrower range of computer system, dealing mainly with commercial IT systems within two categories: applications and infrastructure.

16 This topic is the focus of an online forum moderated by Peter Neumann: the Risks Forum newsgroup, or Risks to the Public in the Use of Computers and Related Systems, known as comp.risks in the USENET community, sponsored by the Association for Computing Machinery (ACM) Committee on Computers and Public Policy (CCPP), which Peter Neumann has chaired since 1985. An archival search and retrieval system is accessible at http://www.risks.org or http://catless.ncl.ac.uk/Risks/. A summary, Illustrative Risks to the Public in the Use of Computer Systems and Related Technology is accessible at http://www.csl.sri.com/users/neumann/illustrative.html.

Implementing an IT risk management capability

Given the universe of threats, the diversity of vulnerabilities and the shapeshifting nature of the IT risk landscape, how can you cope? How can you win?17 Is your organization crisis-prone or crisis-prepared (Mitroff and Alpaslan, 2003)?

Is your organization quietly establishing man-made disasters? (Apologies to those who prefer gender-neutral language, however the field of failures in complex systems has been somehow attributed to the male of the species [Pidgeon and O’Leary, 2000].)

We’ve established the need for an IT governance framework and provided an overview of the integrated IT risk portfolio management approach and the loss impacts it will help you guard against and mitigate. Now you need to get moving.

An effective IT risk management capability is one that meets your business needs,18 considering the following key design elements:

•Strategy and policy;

•Roles and responsibilities;

•Processes and approach;

•People and performance.

These elements are explored below with indicative questions and schedules that ensure that coverage is complete.

Strategy and policy

A set of IT risk management strategies and policies is required to define the overall objectives of IT risk management, establish the importance and priority of IT risk management, ensure adequate coverage of potential areas of IT risk and provide ground rules and principles for those managing risks.

Some of these policies will include the adoption of national or international standards in certain areas (such as US NIST, 2003). You may need to go further, to question whether the standards are good enough, or whether it is necessary to develop internal standards, recognizing that adoption of standards as points of reference does not automatically mean that 100% compliance is necessarily the goal.

Your IT risk management policies should be formally documented and endorsed by the IT governance team (refer to Chapter 2) and communicated actively throughout the organization, providing useful answers to questions such as:

17To keep an eye on who is winning, check the high-level scoreboards: incident statistics on attacks on US Federal Government sites are tracked at www.fedcirc.gov (one more attempt by the bad guys) and cybercrime convictions at www.usdoj.gov/criminal/ cybercrime/cccases (registering the ‘slam dunks’ for the good guys).

18The requirements of public sector vs private sector organizations in managing IT risk are likely to be significantly divergent ( Jordan and Musson, 2001).

•How is IT risk management integrated with wider business risk management activities?

•To what extent is decision-making with respect to IT risks delegated and what are the authorities at different levels of management?

•What are your classes of IT risk and how is each class of risk managed? Obviously we’d suggest the IT risk portfolio seven as your starting point!

•What is the company’s overall risk appetite and how should all employees interpret this when dealing with IT risks?

•What are the critical potential impacts on the business from IT risks that are the primary focus for risk management effort?

•How are funds and resources to be allocated to IT risk management activities?19

•What constitutes a material risk that, if identified, should be reported and if so, to whom should it be reported?

•Which risks are managed proactively – that is, in advance of the defined unwanted and unwelcome event – and which risks are managed reactively, after the occurrence of one or more unwanted and unwelcome events?

Because everyone in the organization becomes a participant in the IT governance and risk management processes, it is critical that policies are promoted widely. Many organizations have IT ‘fair use policies’ that specify the rights and responsibilities of IT users in the organization. Generally these are extensive series of prohibitions that ensure that employees use the provided technology substantially as intended. They are seldom encouraging or facilitating, and have policing status.

Looking beyond the need to clearly articulate the edicts, there are many positive contributions to good IT governance that can be made by technology users, given sufficient guidance and opportunity. Perhaps IT risk management adoption can be adopted in a more voluntary and active fashion in the same way that many take the responsibility to be alert and aware for terrorism or security risks in their day-to-day lives with little instruction.

Roles and responsibilities

IT risk management activities must be built into people’s jobs rather than left to the virtuous or diligent to carry out under their own initiative.20

19 The objective of IT risk management cannot be to eliminate risk completely. Rainer et al. (1991) describe the purpose of risk management as to find the optimum combination of loss prevention and cost. Pfleeger (2000) uses the concept of risk leverage as the risk reduction delivered for a particular expenditure.

20 Sauer et al. (1997) argue ‘undesirable risk-related behaviours can be a logical outcome of a particular form of organization’.

Roles need first to be defined and subsequently the right people need to be selected and allocated to perform these roles. The framework of responsibilities is perhaps best first drawn up in matrix form, considering the different types of IT risks and the risk management lifecycle. We provide examples of those who may take specific responsibilities in Table 3.2.

The examples within this matrix illustrate that each IT risk class has different roles and responsibilities. An individual may ‘wear many hats’ in dealing with IT risks, based on the roles they hold.

Some important considerations include:

•Separation of duties – ensuring that for each class of risk an independent role undertakes monitoring and review activities;

•Balancing the need for specialist input – contributing an understanding of a process, system or specific risk, and managerial decision-making – weighing up all the factors and determining a course of action;

• Fitting IT risk management roles into existing structures where there is a natural fit. For example, risk management treatment actions would be naturally aligned with the project manager for project risks;

•Creating new IT risk management roles when required, for example, a cross-functional business continuity coordination role; and

•Allocating joint responsibilities when necessary and ensuring all slots are taken.

Processes and approach

A repeatable and predictable IT risk management capability is founded on a set of processes that are understood and followed consistently. The risk management process need not be complex. The risk management lifecycle comprises the following steps, deployed in different ways for different types of risks:

1.Identification / discovery – getting IT risks on the radar of management;

2.Assessment / analysis – understanding the IT risk in the context of the whole portfolio of IT risks and assessing the likelihood of occurrence and potential impact on the business;

3.Treatment – determining the best option from many possible courses of action for treating the risk, planning out and completing the required actions; and

4.Monitoring and review – following up to ensure what was planned was actually done and to understand any further changes in the IT risk portfolio.

An escalation process is required in cases where the normal risk management approach proves insufficient. The completion of the risk lifecycle also requires a formal closure process step (i.e. taking previously identified risks off the management radar when they are no longer significant or relevant).