You are on page 1of 20

Risk Analysis for Information Technology

REX KELLY RAINER.JR., CHARLES A. SNYDER,


and HOUSTON H. CARR is Assistant Professor in the Department of Managentient at Aubum University. His research interests include executive information systems, end-tiser computing, and current technology underlying information systems. He has published in the Journal of Management Information Systems, and MIS Quarterly, among other journals.
REX KELLY RAINER, JR.,

A. SNYDER is Professor and head of the Department of Management at Aubum University. His research interests include information resource management, end-user computing, and telecommunications managcmenL He has published in the Journal of Management Information Sysiems, Information and Management, the Academy of Management Review, as well as other journals.
CHARLES

is Associate Professor of Management and Coordinator of MIS Programs al Aubum University. His research interests include end-user computing and telecommunications management. He has published in Journal ofManagement Information Systems, MIS Quarterly, and Information and Management, among other journals. He is the author of Managing Erui User Computing.
HOUSTON H . CARR

ABSTRACT; As Information Technology (IT) has become increasingly important to the competitive position of firms, managers have grown more sensitive to their organization's overall IT risk management. Recent publicity concerning losses incurred by companies becauseofproblcms with their sophisticated information systems has focused attention on the importance of these systems to the organization. In an attempt to minimize or avoid such losses, managers are employing various qualitative and qtianiitative risk analysis methodologies. The risk analysis literature, however, suggests that these managers typically utilize a single methodology, not a combination of methodologies. This paper proposes a risk analysis process that employs a combination of qualitative and quantitative methodologies. This process should provide managers with a better approximation of their organization's overall information technology risk posture. Practicing managers can use this proposed process as a guideline in formulating new risk analysis procedures and/or evaluating their current risk analysis procedures.
KEY WORDS AND PHRASES;

computer security, MIS risk analysis, risk management.

(IT) RESOURCES are becoming increasingly essential for the firm's daily operations and su^ategic objectives. Risk management for IT resources has therefore assumed greater importance. As companies become more dependent upon IT. the consequences of loss of IT assets can be critical, as the following examples
INFORMATION TECHNOLOGY

An earlier version of this paper was presented at the 14th Symposium on Operations Research, Ulm, Germany. September 1989.

Journalo/McmagemantliforTHaihHSystems

/Summer 199t. Vol. 8. No. l,pp. 129-147 Copyright M.E. Shiipe, Inc., 1991

130

RAJNER, SNYDER, AND CARR

demonstrate:
AT&T's nationwide network suffered the most widespread malfunclion in its history due to a software failure. [10] Robert Morris, Jr. was convicted of breaking federal I aw when he introduced a computer virus into Internet, affecting more than 6,000 computers. [25] Transition to a new companywide computer system introduced system errors that caused reduced net income for the fourth quarter at Sun Microsystems Inc. [21] American Airline's Sabre reservation system crashed for 13 hours when data from an application program wiped out vital information. [45]

Parker stated the importance of IT to an organization when he noted that the amount of time that an organization can go without computer services, or the' 'mean time to bel!y-up," was steadily decreasing [36]. While IT risk management is a relatively new field, it is a natural extension of management's concern for the organization's overall risk posture. The objective of IT risk management is to minimize the total expected cost of loss by selecting and implementing an optimal combination of security measures [14, 20, 22, 34, 35]. In spite of the growing importance of IT risk management, a majority of companies do not have a tested, up-to-date risk management program [19,27,28,30,36,50]. The purpose of this paper is to examine risk analysis methodologies. First, the risk analysis process is placed in the context of the overall risk management process. The various risk analysis methodologies are discussed. The article then proposes a risk analysis process employing a combinalion of methodologies that practicing managers can use in their organizations.

The Risk Management Process


loss prevention and reasonable cost. The purpose of risk management is to find that combination [16, 17], Simply stated, risk management seeks to avoid or lessen loss. Loss implies injury to, denial of access to, or destruction of, assets. The opportunity for a threat to impact an asset adversely is called a vulnerability. Risk is present when an asset is vulnerable to a threat. Assets associated with IT include data, hardware, software, personnel, iind facilities. Facilities consist of computer sites, the communications network plant, and associated subsystem installations [5,36]. Many authors have discussed the varied threats to IT resources [4,19,31, 34, 35, 49]. Table 1 lists these threats and shows that they may originate from physical sources, unauthorized access, and authorized access. Further, threats may originate from internal and extemal sources. The threats arising from authorized access are the most difficult to find and assess. The risk management life cycle (see Figure 1) begins with the risk analysis process, which analyzes IT assets, threats to those assets, and vulnerabilities of those assets. Risk analysis is discussed in the next section of this paper. Following risk analysis, several alternative security measures (or combinations
FOR EVERY ORG ANEATION THERE IS SOME COMBINATION of optimum

RISK ANALYSIS FOR INFORMATION TECHNOLOGY

131

Table 1 Potential Threats to IT (1) Physical Threats Equipment failure [19.20] Power interruption [19,20] Contaminants in the air [19,20] Weather [19.20] Fire [19.20] Humidity [19.20] Destruction or damage to facility or equipment by humans [19,20] Death or injury to key personnel [11,13] Personnel turnover [11,12] (2) Unauthorized physical or electronic access Microcomputer theft [10] Theft of data [20,42] Disclosure, modification, and/or destruction of data [10,52,53] Hackers [10] Viruses, bombs, worms [52] EDI fraud [2,6, 31] Phantom nodes on network [2,6,9,31,46] Voice mail fraud [2,6.31J Software piracy [ 10] (3) Authorized physical or electronic access I/S applications portfolio may be outdated or obsolete [8,29] Increase in end-user computing [1,19,26,41,44] increased end-user access to corporate data proliferation of end-user-developed applications

thereoO that address a particular risk are presented to management for an implementation decision. The cost of the security measures will be weighed against their effectiveness in reducing risk. Because 100 percent IT security is impossible, managers must evaluate the choice of security measures. In general, any security measure or combination of such measures must not cost more than it would cost to tolerate the problem addressed by the measure(s) [33]. Figure 2 indicates the trade-offs between increased costs and increased security measures. This figure also shows that there is some optimal point between security and cost. After management has decided on appropriate security measures, the implementation process is initiated and the security measures are installed. Next, a surveillance and audit process is necessary; this should incorporate testing and evaluation of the IT security system. Data are gathered so that the effectiveness ofthe security measures in reducing risk may be determined. There are two basic strategies for surveillance and audit of security systems [53]: (1) actively monitoring control systems as they are

132

RAINER. SNYDER. AND CARR

Qianges in EnvircaTment (New Ihreats) External Ihreats Results Risk Areilysis Intemal Threats Vulnerabilities Security Surveillance and Audit Security Measures Security Measure IitplementatiCT , Selected Security Measures Managernent Decision
Figure 1. The Risk Management Life Cycle

Generate Security Measure Alternatives

Alternatives

Cost of PrtJtection cost Increases

Expected

Level of protection increases Figure 2. Trade-offe between Cost of Protection and Cost of Loss challenged (e.g., control programs that monitor user logon procedures and keep a record of logon failures); (2) challenging the security system under controlled, simulated conditions (e.g., hiring outside personnel to attempt to infiltrate an organization's security mechanisms). The risk management process is cyclical for two reasons. First, the changing environmeni will generate new external threats for IT assets. Second, the security

RtSK ANALYSIS FOR INFORMATION TECHNOLOGY

133

surveillance and audit process will uncover new intemal threats to IT assets. Therefore, management must periodically reevaluate the organization's exposure to loss.

The Risk Analysis Process


the threats facing their IT assets and the vulnerabilities of those assets to the risks (see Figure 3). Risk analysis consists of identifying IT assets, identifying threats to those assets, and determining the vulnerability of asset(s) to threat(s). Risk analysis is the basis on which risk management decisions are made. However, risk analysis is also the point in the risk management process where the most difficulty arises. The fact that risk must often be expressed in perceptions makes any measure of risk highly subjective. The high degree of subjectivity associated with perception of risk means that management is often skeptical of risk analysis results, and is unwilling to make important decisions based on them. There are many methodologies currently in use that attempt to measure the loss exposure of IT assets. These methodologies may be categorized as quantitative or qualitative. Regardless of the methodology used, it should have certain desirable properties. First, it should be acceptable to management, the user eommunity, and the information systems department. Second, even though no single risk analysis methodology can consider all risks, it should be as comprehensive as possible, and be able to handle new technologies. Third, it should be logically sound. Fourth, it should be practical meaning that it should deliver optimum protection for ihe cost. Fifth, it should be open to continuing evaluation from all parties. Sixth, it should be conducive to learning, accompanied by clear documentation and records of deliberations. Quantitative Risk Analysis Methodologies Most quantitative methods are based on regarding loss exposure as a function of the vubierability of an asset lo a threat multiplied by the probability of the threat becoming a reality. These methods are called "expected value analyses," and include annualized loss expectancy (ALE) [34, 37, 38, 40], Courtney [37, 38], the Livermore Risk Analysis Methodology (LRAM) [22], and Stochastic Dominance [40]. It is important that managers involved in the risk analysis process reaeh consensus regarding the value of IT assets and probability estimates. Delphi techniques may be used in conjunction with any of the four quantitative methodologies to elicit values of IT assets as well as probability estimates of threat occurrence. The Delphi approach begins with an initial open solicitation step followed by multiple rounds of feedback, and may be used to identify issues and obtain con.sensus among participants. This technique is effective when participants are not in physical proximity, a situation typical with busy managers. For example, the risk analysis process using Delphi techniques might follow this scenario. Participants place initial values on IT assets and threat probabilities and the
RISK ANALYSIS IS THE PROCESS MAINAGERS USE to examine

134

RAINER. SNYDER, AND CARR

ASSET IUtWi'iFICATICN AND ANALYSIS

IHREAT ITFICA AND ANALYSIS

AND ANALYSIS

RISK ANALYSIS
Figure 3. The Risk Analysis Process

results are averaged. Each participant receives a list showing his or her individual value in relation to the average values. Participants may now change their values or provide a rationale(s) for not doing so. In subsequent rounds, participants receive the new average value, the previous average ranking(s), and their previous individual ranking(s). The process continues until consensus is reached or until consensus cannot be reached because individuals refuse to change their rankings. The Delphi technique is not the only approach that may be used to reach consensus. Managers may meet to brainstorm and negotiate. Group decision support systems would be valuable in these meetings for anonymous input and rapid attainment of consensus. Although only Delphi techniques are noted in the remainder of the paper, meetings (with or without GDSS) may be employed.

Annualized Loss Expectancy


Annualized Loss Expectancy (ALE) [34,37,38,40] first lists all IT assets. Then, with the help of users and other knowledgeable parties such as MIS/DP personnel and general management, potential threats to those assets are analyzed along with the loss

RISK ANALYSIS FOR INFORMATION TEaiNOLOGY

135

that would result from the realization of those threats. The vulnerability of each asset to a threat is expressed as some probability of occurrence per year. Multiplying the probability of occurrence per year by the expected loss yields the expected loss per year from a particular threat/vulnerability pair. The summation of tlic expected losses represents the total IT risk exposure. This figure represents what management may reasonably spend for security and preventive measures. Annualized Loss Expectancy Formula Total IT risk exposure = ^ (^, where vulnerability = V- = probability of occurrence per year, and expected loss = EL- = expected loss of (th threat/vulnerability pair.

Courtney
Courtney [37,38] modified the standard ALE approach by adopting scales of magnitude. In Courtney's method, dollar loss is expressed as a power of ten, and the estimated frequency of occurrence is selected from a range of magnitudes. The resulting estimates are used in a formula that yields a dollar estimate of the annualized expected loss or exposure that an organization might reasonably expect. Courtney Formula
JQ(pfl^3)

Total IT exposure =

where ;j = an integer representing orders of magnitude of estimated frequencies of a loss, and V = an integer representing orders of magnitude of lhe dollar impact of an asset's loss. Table 2, associated with the Courtney methodology, shows the integer values for v and p, and the corresponding values associated with each integer. Table 3, also associated with the Courtney methodology, shows the values of/? and V. and the expected dollar loss associated with each pair of p and v values. In Table 3, K represents SI,000 and M represents $1,000,000. For example, if the dollar impact of a threat to an asset is 510,000 (v = 4), and the estimated frequency of occurrence is once in three years (p = 3), the expected loss is S3333.33. The Courtney method results in a generalized measure of annualized expected loss and is therefore best suited for initial risk analysis. This method saves time, effort, and money, but it is inexact. Therefore, if greater accuracy is required, other quantitative risk analysis methodologies must be used.

Livermore Risk Analysis Methodology


The Livermore Risk Analysis Methodology (LRAM) [22] operates similarly to ALE. First, the LRAM methodology collects data regarding IT assets and then considers

136

RAINER. SNYDER, AND CARR

Table 2 Ranges of Magnitude for Courtney Methodology


V

dollar iirpact 0 10 100 1000 10,000 100,000 1,000,000 10,000,000

p 0 1 2 3 4 5 6 7

estimated frequency practically never cnce in 300 years cax in 30 years crce in 3 years onoe in 100 days anoe in 10 days cnoe per day ten tizoes per day

0 1 2 3 4 5 6 7

Table 3 Estimated Dollar Losses from Courdiey Methodology Values of P


1 1 2 3 4 5 6 7 2 3 4 300 3K 30K 300K 3M 3CH 5 300 3K 30K 300K 3M 3CN 30CH 6 3K 30K 300K 3H 3GM 30CM 7 30K 300K 3H 3CM 30CM

Values of V

300 3K 30K

300 3K 30K

300K

300 3K 30K 300K 3H

risk elements. Risk elements are combinations of risk initiators, their propagation paths (i.e., the means by which they can affect IT assets), possible resulting consequences, and applicable controls (see Figure 4). LRAM differs from ALE, however, in that it does not attempt to derive a total risk measure, but focuses instead on the risk produced by individual risk elements involving the occurrence of single event losses. LRAM Formula R (REi) = MPL (Q) X ^) x EF (T,),

where R (RE) is the annualized measure ofriskassociated with the ith risk element; MPL (C,) is the maximum potential loss (MPL) that can be estimated to result from unmitigated consequences ( Q of a threat to an asset; PCF (PMC,) is the probability of a control failure (PCF) of a combined set of preventive and mitigative controls (PMC); and EF (T,) is the expected fi^quency of a threat expressed as an annual probability.

RISK ANALYSIS FOR INFORMATION TECHNOLOGY

137

Stochastic Dominance
Stochastic Dominance [40] initially assumes that some disaster or risk has already occurred. The effects ofthe disaster are then analyzed over time by examining all areas of the organization that are susceptible to losses if IT assets are damaged or destroyed. Stochastic dominance describes these loss functions mathematically and uses computer simulation to analyze them. The stochastic dominance methodology answers the specific question of what type of contingency plan should be used if disaster strikes. Management does not have to estimate the probability that disaster might strike and damage IT assets. Rather, management estimates how long it will take to recover from a disaster, and how much the business will suffer during that time period. The stochastic dominance methodology defines three sequential stages in recovwy from a disaster. Stage I is the time period between the initial loss of processing capability and the actual operation ofthe contingency system. Stage II begins when Ihe contingency system starts operating, and ends when processing capability is first restored. Stage III is the time period necessary for full recovery of the information system to normal operations. Daily Loss Formulae for the Three Stages of Stochastic Dominance Stage I: daily loss = R[\e~^'^']\

where R = predisaster daily revenue, and t = number of days spent in stage I. Total stage I loss = summation of daily losses. Stage II: daily loss is equal to the loss incurred during the last day of Stage I. Total Stage II loss = summation of daily losses. Stage HI: daily loss = daily loss in stage II if 0 < / < 0.257; daily loss = DL, x e^^'"''''''^ <'"'^"^J, if t > 025T. DL2 = daily loss in stage II; T = total time spent in stage III. The stochastic dominance approach considers only major disastersUiat is, catastrophes that cause the loss of mainframe computing for the organization. This approach does not consider other, smaller threats, such as theft or modification of data (see Table 1). Advantages of Quantitative Risk Analysis Methodologies Quantitative risk analysis methodologies have several advantages. Participants must identify specific IT assets that are most susceptible to damage or disaster. Further, participants must identify IT assets that are most critical to the operation of the organization. Generating and testing contingency plans shows management where problems are likely to occur if damage or disaster occurs. Finally, testing the contingency plans will graphically demonstrate the value of IT assets to management.

138

RAINER, SNYDER, AND CARR

Disadvantages of Quantitative Risk Analysis Methodologies Quantitative risk analysis methodologies also have disadvantages. Estimating the probability of damage or loss of each IT asset is imprecise. In addition, the probability distribution of losses is highly skewed. Many circumstances can cause minor problems, but few circumstances can cause major problems. Quantitative risk analysis tends to average these events, thus blurring the differences between the extremes and implying similar solutions. Quantitative risk analysis techniques cannot literally define the contingency plan an organization should use. Finally, quantitative methodologies result in point estimates, which are statistically too high 50 percent ofthe time, and too low 50 percent of the time.

Qualitative Risk Analysis Methodologies


It may be neither necessary nor desirable to spend the time and effort required to perform a quantitative risk analysis. Management may decide that only a quick evaluation of the firm's IT risk posture is needed. In such cases, qualitative risk analysis approaches may be used. Qualitative methodologies attempt to express risk in terms of descriptive variables, rather than in precise dollar terms. These approaches are based on the assumption that certain threat or loss data cannot be appropriately expressed in dollars or discrete events, and that precise information may be unobtainable. These methodologies include Scenario Analysis [23,27,34,35], Fuzzy Meuics [23,34,35], and questionnaires [27, 34,35J. Delphi techniques could be used with any of the three methodologies presented here to clarify descriptive or natural language variables. Scenario Analysis [23,27, 34,35] In this methodology, a group of experts identifies IT assets and potential threats. The group then develops various scenarios describing how those assets might be subject to loss from ihe threats. These scenarios can be ranked in order of importance and will quickly identify the weakest parts of a security program. Scenarios are an excellent communication tool, in that they can graphically explain how a loss could result. Management can therefore visualize the risk. Scenarios can be especially useful in identifying vulnerability to intentional threats. Fuzzy Metrics [23,34,35] This methodology uses natural language values to describe assets, threats, and security mechanisms. Fuzzy metrics is statistically valid, but requires absolutely consistent definitions and understanding of the linguistic variables. Thens is also much debate about the best way to model the natural language expressions mathematically. Fuzzy metrics utilizes fuzzy descriptors. For example, assets may have values of large, medium, and small. Also, threats may have probabilities of occurrence of high,

RISK ANALYSIS FOR INI-ORMATION TECHNOLOGY

139

medium, and low. The simplest way for all participants in the risk analysis process to understand the descriptors is by labeling them. Participants may defme' 'large'' valued assets to be those from $1 million to $2 million, "medium" from Sl00,000 to SI million, and "small" less than $100,000. Further, participants may define "high" probabilities of threats to be from 0.7 to LO, "medium'' from 0.35 to 0.7, and' 'low'' less than 0.35. The most elementary method for mathematically modeling these descriptors is to use the mean of the range of each descriptor. In our example, the mean of "large" valued assets is$L5 million, that of "medium" assets is S55O,OOO, and that of "small" assets is S50,000. The mean of "high" probabilities is 0.85, "medium" is 0.525, and " l o w " is 0.175. Therefore, the expected loss of a large asset under high probability of a threat equals Sl.5 million multiplied by 0.85, or $1,275 million. Another method that can be used to yield expected losses is to calculate the ranges of such losses. For example, a large asset under high probability of a threat will yield expected losses from $700,000 to $2 million: low estimate = SI million x 0.7 = $700,000; high estimate = $2 million x LO = S2 million. The difficulty of mathematically modeling fuzzy descriptors is illustrated by noting that the midpoint of the range of expected losses is $ 1.35 million. This figure is higher than that obtained above by multiplying the mean of the large asset range and the mean of the high probability range ($1,275 million). Both figures are "correct." Questionnaires [27,34,35] Questionnaires regarding risk analysis are available from computer vendors, security companies, and publications on computer security. Questions are usually segregated into functional areas such as input, communications, processing, and output. They may also be listed by asset, such as hardware, software, personnel, etc. Questionnaires do provide an advantage. They typically ean identify glaring weaknesses often present in a firm where security has recently become a concern or where it has been neglected for a period of time. However, questionnaires do have disadvantages. They are generic, while companies have unique IT assets. They do not consider the probabilities associated with potential losses, nor do they consider the magnitude of those potential losses. Advantages of Qualitative Risk Analysis Methodologies These methodologies save time, effort, and expense over quantitative methodologies because IT assets need not have exact dollar values, nor do threats need to have exact probabilities. Further, qualitative methodologies are valuable in identifying gross weaknesses in a risk management portfolio.

t40

RAINER. SNYDER, AND CARR

Disadvantages of Qualitative Risk Analysis Methodologies Qualitative meLhodologies are inexact The variables used (i.e., low, medium, and high) must be labeled and understood by all parties involved in the risk analysis, including management. Management may consider qualitative meLhodologies suspect because they do not provide "exact" dollar values and probabilities.

A Proposed Risk Analysis Process


available to an organization. These methodologies may be applied singly or in combination to help determine the risk posture of the firm. However, the advantages and disadvantages of each methodology suggest that each one may best be applied to certain types of threats or certain areas of the organization. Therefore, a combination of methodologies provides the optimum process for risk analysis in the firm.
THERE ARE MANY RISK ANALYSIS METHODOLOGIES

Step 1: Use the Value Chain to Enumerate the Organization's Activities


Before beginning the risk analysis process, lhe firm must clearly understand all its various activities and the IT component of each. The value chain is a systematic way of examining all the activities a firm performs, and their interaction [39]. This concept divides the firm's activities into value activities, those essential, distinct, and interdependent actions that bring a product or service to a customer. These primary activities consist of inbound logistics, operations, outbound logistics, marketing and sales, and service. Inbound logistics consists of those activities associated with receiving, storing, and disseminating inputs to the product, such as material handling, inventory control, and returns to suppliers. Operations consists of those activities associated with transforming inputs into final product form, for example, machining, packaging, and assembly. Outbound logistics consists of those activities associated with collecting, storing, and physically distributing the product to buyers, such as warehousing, material handling, and order processing. Marketing and sales consists of those activities associated with providing a means by which buyers can purchase the product and inducing them to do so, including advertising, promotion, sales force, pricing, etc. Service consists of those activities associated with providing service to enhance or maintain the value of the product, such as installation, repair, training, and parts supply.

Step 2; Use the Value Chain to Enumerate the IT Component of Each Value Activity
The concept of the value chain has been employed to help managers understand how infonnation technology can be used to support their business activities [36]. Each value activity has a physical component and an information-processing component. The physical component consists of physical tasks necessary to perform the activity.

RISK ANALYSIS FOR INFORMATION TECHNOLOGY

141

The information-processing component includes the steps required to capture, manipulate, and channel the data to support the activity. Information systems technology is particularly extensive in the value chain, because every value activity creates and uses information [39]. Examples of IT eomponents of inbound logistics' value activities include inventory, purchasing, and order processing systems. Examples of IT components of operations' value activities include computer-assisted design, computer-aided manufacturing, and robotics. Examples of IT components of outbound logistics' value activities include inventory, materials handling, and order-processing systems. Examples of IT components of marketing and sales' value activities include multimedia and telecommunications. Examples of IT components of service value activities include telecommunications, desktop publishing, and scheduling the service force. To list and describe the IT assets that support each value activity, participants (users, MIS/DP personnel, general management) can use a qualitative methodology or combination of qualitative methodologies such as scenarios orquesUonnaires. Further, they can employ Delphi techniques to refine the completeness of the IT asset list and the characterization of IT assets.

Step 3: Use the Value Chain to Enumerate the Linkages between Value Activities and to Determine the IT Assets that Support Each Linkage
Linkages are relationships between the way one value activity is performed and the cost or performance of another. For example, in a fast-food store, the timing of promotional campaigns influences capacity utilization [39]. IT resources have an important role in linkages among value activities of all types, because the coordination and optimization of linkages requires information flow among activities. A good example of IT support of linkages is American Airline's Sabre reservations system. American leases terminals to travel agents, which allows automated reservations and ticketing. The system is also used inside American for ticketing and issuing boarding passes, as well as in route scheduling. American also sells listings on the system to other airlines. The important point of linkages is that the organization may notice the importance of IT assets in areas that might, in isolation, be considered noncritical. The importance of IT in some of the activities, such as operations, may be relatively obvious. At the same time, essential IT components in other activities may not readily be associated with the overall performance of the business. The performance of any activity may affeet the performance of any other. Thus, the value chain can clearly indicate to managers the IT component of each activity and, through linkage examination, reveal the importance to the total business system. To list and describe the IT assets that support each linkage, participants (users, MIS/DP personnel, general management) should use a qualitative methodology or combination of qualitative methodologies such as scenarios orquestionnaires. Further.

142

RAINER, SNYDER, At<D CARR

they should employ Delphi techniques to refine the completeness of the IT asset list and the characterization of IT assets.

Step 4: Use the Value Chain to Examine the Organizational Value System and to Determine IT Assets that Support Interorganizational Linkages Linkages exist between a firm's value chain and the value chains of suppliers and
customers. For example, a firm's inbound logistics' activities interact with a supplier's order entry system, a supplier's engineering staff works with a firm's technology development and manufacturing activities, or frequent supplier shipments can reduce afurm's inventory needs. Similar examples exist for linkages between the firm's value chain and customer value chains. The best example of IT resources that support interorganizational linkages is electronic data interchange (EDI). To list and describe the IT assets that support the value system's interorganizational linkages, participants (users, MIS/DP personnel, general management) should use a qualitative methodology or combination of qualitative methodologies such as scenarios and/or questionnaires. Further, they can employ Delphi techniques to refine the completeness of the IT asset list and the characterization of IT assets. Step 5: Determine the Value of the IT Assets Listed and Described in Steps 1 through 4 The organization has employed the value chain in an effort to catalog and describe all IT assets. The participants in the risk analysis process must now assign a value to each IT asset. There are two methods for assigning such values. The first is for the participants to assign an exact dollar value to each IT asset. Delphi techniques may be employed to refine assigned dollar values by helping the participants reach consensus. The second method is to employ fuzzy metrics and assign fuzzy descriptors such as high, medium, and low as values of IT assets. Again, Delphi techniques may be used with fuzzy metrics. Step 6: Enumerate the Possible Threats to IT Assets To list and describe the threats to IT assets, participants (users, MIS/DP personnel, general management) should use a qualitative methodology or combination of qualitative methodologies such as scenarios and/or questionnaires. Further, they may employ Delphi techniques to refine the completeness of the threat list and the characterization ofthe threats. Step 7: Determine the Vulnerability of I T Assets to Potential Threats At this stage of the risk analysis process, the organization has a list of all IT assets, values assigned to each IT asset, and a list of potential threats to IT assets. To determine

RISK ANALYSIS FOR INFORMATION TECHNOLOGY

143

the vulnerability of IT assets to threats, participants must first note that any asset may be vulnerable to more than one threat, and that one threat may impact more than one asset. Therefore, the participants should consider asset/threat pairs in the following manner. The assets and threats should be listed in side-by-side columns, and arrows drawn to represent threats that may impact an asset, as shown in Figure 5. The vulnerability of the asset to the threat must be assigned for each asset/threat pair. The participants may defme these vulnerabilities precisely by designating a number (e.g., the probability of threat 1 impacting asset 1 is 0.33), or by using fuzzy descriptors (e.g., the probability of threat 1 impacting asset 1 is medium). The participants may use Delphi techniques to refine probability numbers or fuzzy descriptors.

Step 8: Detennine the IT Risk Exposure for the Organization


Participants now have the information they need to determine the overall IT risk exposure for their organization. Participants have two possible paths, depending on the risk analysis process to this point. If the participants have assigned exact numerical values to IT assets, and the vulnerabilities of those assets to threats, they may use the quantitative methodologies of ALE, Courtney, or LRAM. The ALE, Courtney, and LRAM methods will result in precise dollar estimates for the firm's risk exposure. The Courtney method, however, is not as exact as the other two because it uses ranges of values in its calculations. An important point is that if the participants are performing risk analysis for a complete disaster, they should employ stochastic dominance and not one of the other quantitative methods. If the participants have assigned fuzzy descriptors to IT assets and the vulnerabilities of those assets to threats, they must use fuzzy metrics to describe the firm's risk exposure. Fuzzy metrics will result in descriptions (e.g., high, medium, and low) that will categorize the firm's risk exposure. Table 4 summarizes the risk analysis process and the methodologies applicable in each step. As yet, there is no empirical evidence to support the proposed risk analysis proeess. Substantiating the effectiveness of this process will require a field study of one or more organizations. The field study would examine the risk analysis process each firm uses. In addition, the study would ask each company how clearly it feels that its risk analysis proeess portrays the firm's overall IT risk posture.

Conclusion
It simply costs too much and is too inconvenient. Zalubsky [52] stiites that the root of the problem for the risk management process is the overall lack of awareness, attention, concern, and commitment from management. Further, Zimmerman [53] notes that, as a result of buying security, the firm will not be any better, it will merely be less likely to be any worse. Security personnel want management to invest corporate resources in system security measures
ONE HUNDRKD PERCENT SECURITY IS IMPOSSIBLE.

144

RAINER, SNYDER, AND CARR

threat

preventive controls

assets

mitigative cxrrttols

ccrisequences

Figure 4. LRAM Risk Elements

Threat 1^-

-Asset 1

Asset/Threat Pairs Threat Threat Threat Threat Threat 1, 1, 2, 2, 3, Asset 1 Asset 3 Asset 1 Asset 2 Asset 3

Threat 2 *^^^ * Asset 2 Threat 3 etc.


Figure 5. Asset-Threat Pairs

Asset 3 etc.

that will be unpopular with staff (because they bring new rules and restrictions), and that will show no apparent retum on investment. The most common situations that management faces are those in which threats are believed possible, but no empirical evidence is available. The best possible scenario for security personnel is a disaster that happens to the organization next door, because such an occurrence will graphically provide empirical evidence to management. The proposed risk analysis process using a combination of methodologies seems to be more effective than ihe use of any single methodology. A single risk analysis methodology is not flexible enough to properiy consider the wide variety of IT assets, threats, and vulnerabilities, and still give management a reasonable estimate of the organization's overall IT risk exposure. In addition, the proposed risk analysis process includes management in every step, thereby ensuring management participation. By using a combination of risk analysis methodologies, the firm can overcome these problems. In particular, it is important to note that the proposed risk analysis process does not use quantitative methodologies until the last step (Step 8). The reason for this late appearance is that a large amount of information must be determined before quantitative methodologies can be used with even rudimentary accuracy. Qualitative "brainstorming" methodologies are used to obtain this often imprecise information. Too many organizations, if they have a formal risk analysis process at all, simply use a single qualitative or quantitative methodology for the entire process. Such an approach is too simplistic for a process that is based solely on informed estimates. The risk analysis process proposed here can help with the difficulty of convincing management to invest in security measures. Properly used, this process will provide management with an idea of the importance and value of their IT assets, the threats to those assets, and the probability that those threats will succeed in harming the assets. This risk analysis process will provide management with a basis for logical and prudent investment in a risk management program.

RISK ANALYSIS FOR INFORMATION TECHNOLOGY

145

Table 4. The Risk Analysis Process and Applicable Methodologies


steps (1) >iumerate onganizaticnal value activities Methcxiologles

Scenario anchor questicrmaire + Delphi

(2) Enumerate IT axpcnent of each value activity (3) Enumerate linkages cinox| value activities and IT ocnpcnent that supports each (4) Determine IT assets that support interorganizationai lin>3ges

Scenario antVor questicnrHire + Delphi

Scenario ard/or questionnaire + Delphi

Scenario anchor questionnaire + Delphi

(5) Determine value of IT assets

(a) assign exact dollar values + Delphi

sar
(b) use fuzzy metrics t - Delphi Scenario and/or questicrmaire * Delphi (a) assign precise nuntier + Delphi (b) use fuzzy metrics + Delphi

(6) Enumerate possible threats (7) Detennine vulnerability of assets to threats

(8) Determine overall IT risk exposure

* if precise nuntsers heive been assigned, use: (a) Stochastic Daninance for a t o t a l Hi<g;<'st-jf>r (b) ALE, Courtney, ISiMi for other threats * if fuzzy metrics have been used, aiploy ftizzy metrics for fined calculaticffTS

REFERENCES
1. Alavi, M., and Weiss, I.R. Managing the risks associated with end-user computing. Journai of Management Informaiion Systems 2,3 (Winter 1985/86), 5-20. 2. Bacon, M. Assessing public network security. Telecommunications 23^ 12 (December 1983). 19-20. 3. Banking WorW. The management of risk. October 1988, 34-36. 4. Behesti, H.M., and Mattson, M.R. Computer based management infonnation systems and risk management. Focus on Managemeni (Society for Advanccmeni of Management) 1, 3. 5. Bendyna, N. Minimizing loss ihrough risk assessment. Infosystems (December

146 RAINER. SNYDER. AND CARR 1984), 66-67. 6. Briere. D., and Walton. LT. The best way to prevent a disaster: plan for one. Network World 6,47 (November 27.1989), pp. 1,31.34. 7. Business Week. How personal computers can trip up executives. September 24, 1984. 94-102. 8. Cash, J.L; McFarlan. F.W.; and McKenney, J.L. Corporate Information Systems Management, 2d ed. Homewood, IL: Richard D. Irwin. 1988. 9. Cohen, F. Design and protection of an information network under a partial ordering: a case study. Computers and Security 6 (1987). 332-338. 10. Com/nunications Week. Hacker's doings are costly. January 29,1990.14. 11. Crockford. N. An Introduction to Risk Management. Cambridge. MA: WoodheadFaulkner. 1980. 12. Crouch. E.A.C,, and Wilson, R. RiskJBenefit Aruilysis. Camhndge, MA: Ballinger, 1982. 13. Doherty, N.A. Corporate Risk Management. New York: McGraw-HiU. 1985, 14. Emmett, A. Managing risk. Network World, November 21.1988. 37-38.47. 15. Even-Tsur, D.. and Shulman, D. Designing built-in system controls, /OU/TW/ of Information Systems Management (Winter 1989). 28-36. 16. Farthing. D, How risk management is driven by insurance. National Underwriter, November 2, 1987.9.14-15. n.Farthing.D. Is risk management essential to corporate survival? i?i.vitMartd^emen/. February 1988.34-37. 18. Gerard.T. Evaluating adisasterrecoveryplan./Pj3/ace/erA/anagcr2.1 (January/Februaiy 1990), 36 41. 19. Gonnella. G. Making expensive decisions. Information Center 4,10 (October 1988), 32-35. 20. Gottfried. I.S. When disaster strikes. Journal of Inforrratlon Systems Management (Spring 1989). 86-89. 21. Greenstein, I. MIS snafu lost orders, could mean sun loss. Management Information Systems Week 10, 23 (June 5,1989), 4. 22.Guarro. S.B. Principles and procedures of the LRAM approach to information systems risk analysis and management. Computers and Security 6 (1987). 493-504. 23. Hammond. R. Improving productivity through risk management. In Umbaugh. R.F.. cd..Handbookof MIS Management, 2dai.Boslon:AueThach, 1988, 655-665. 24. Housel, T.J.; El Sawy, O.A.; and Donovan, P.F. Information systems for crisis management. MIS Quarterly 10, 4 (December 1986). 389-402. 25. Keller. J.J. Software bug closes AT&T's network, cutting phone sravice for millions in U.S. Wall Street Journal, January 16. 1990. A2. 26. King, J.L. Coping with the perils of expanding PC use. Journal of Information Systems Management 3,4 {VaW 1986), 66-70. 27. Lobel, J. Risk analysis in the 198O's. American Federation of Information Processing Societies Proceedings (National Computer Conference) 49 (May 19-22, 1980). 831-836. 28. Mansur, B.J. The night the lights went out in Georgia. Telecommunications23, 12 (December 1989). 67-68. 29. McFarlajT. F.W.. and McKenney, J. IS technology organization issues. In McFarlan, F.W.. and McKenney. J.. Corporate Information Systems Managemeru. Homewood, IL: irwin. 1983.2748. 30. Meall. L. Survivalof the fittest. >lccoim/ancy (March 1989), 140-141. 31. Morrisey. J. New security risks seen for '90s. PC Week, December 11.1989,55. 32. Murray. W. How much is enough? Expert says security efforts should pay. not cost. Computerworld, April 6. 1988, 30. 33. National Bureau of Standards. Guidelines for ADP risk analysis. Washington. DC: U.S. Department of Commerce, FIPS Publication 87. March 1981. 34. Newton. J.D. Developing and implementing an EDP disaster contingency plan for a small national bank. Unpublished master's thesis. Aubum University, 1987. 35. Newton. J.D., and Snyder, CA. Risk analysis for computerized information systems. Proceedings, Southern Management Association (1987), 306-308.

RISK ANALYSIS FOR INFORMATION TECHNOLOGY

147

36. Parker, D,B. Computer Security ManagemerU. Rcsion, VA: Reston Publishing, 1981. 37. Perschke, G.A.; Karabin, S.J.; and Brock, T.L. Four steps to infonnation security. Journal of Accountancy {April 1986), 104-111. 38. Pickard, R. Computer crime. Information Center 5,9 (September 1989), 18-27. 39. Porter, M.E., and Millar, V.E. How mformation gives you competitive advantage. Harvard Business Review (July-August 1985). 149-160. 40. Post, G. V., and Diltz, J.D. A stochastic dominance approach to risk analysis of computer systems. MIS Quarterly 10, 4 (December 1986), 363-375. 41. Pybum, PJ. Managing personal computer use: ihe role of corporate management information systems. Journal ofManagemeni Information Systems 3,2 (Winter 1986-87), 49-70. 42. Radding. A. Plans for a safer system. Computer Decisions (April 6, 1987), 36-38. 43. Ricmer, M.S. Fighting computer viruses through systems management. Information Center 5, 9 (September 1989). 11-17. 44- Rivard, S., and Huff, S.L. An empirical study of users as application developers./n^ormation and Management 8, 2 (January 1985), 89-102. 45. Scheier, R.L. American Airline's still shoring up SABRE. PC Week, June 26, 1989, 65. 46. Semilof,M. Network disaster planning. Communications WeeA, February 12, 1990, 33-35. 47. Sobol, M. DP alliance bolsters security. Computerworld. December 16, 1985. 59-60. 48. Stem, E. The lessons of Saii Francisco. Datacenier Manager 2, 1 (January/February 1990), 30-35. 49. Tate, P. Risk! the third factor. Datamation. April 15, 1988. 58-64. 50. Vitale, M.R. The growing risks of information systems success. M/^Guar/er/y 10. 4 (December 1986), 327-334. 51. Wood, C.C. The human immune system as an information systems security model. Compu/r.s am/5ecu/-iO'6 (1987), 511-516. 52. Zalubski. J. Threat of viruses must be taken seriously. Network World, July 31,1989, 29. 53. Zimmerman. J.S. Is your computer insecure? Da;ama/ion, May 15,1985.119-128.

You might also like