Professional Documents
Culture Documents
Risk Analysis For IT
Risk Analysis For IT
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;
(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
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.
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
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
Alternatives
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
133
surveillance and audit process will uncover new intemal threats to IT assets. Therefore, management must periodically reevaluate the organization's exposure to loss.
134
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.
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.
136
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
Values of V
300 3K 30K
300 3K 30K
300K
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.
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
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.
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
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.
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.
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
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
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.
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
threat
preventive controls
assets
mitigative cxrrttols
ccrisequences
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
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.
145
(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
sar
(b) use fuzzy metrics t - Delphi Scenario and/or questicrmaire * Delphi (a) assign precise nuntier + Delphi (b) use fuzzy metrics + Delphi
* 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.
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.