A METHODOLOGY FOR MANAGING INFORMATION-BASED RISK

Holmes E. Miller, Muhlenberg College, Allentown, PA. 18104

Kurt J. Engemann, Iona College, New Rochelle, NY 10801

ABSTRACT

Organizations often think of information security as a technological issue best left to technical specialists. While many security strategies undoubtedly rely on hardware and software solutions, the management processes surrounding security and the ongoing commitment of business and operations managers to security issues are no less important. In this paper we discuss a three-phase methodology for managing information-based risks, and present results of how a large money center bank implemented the methodology at numerous locations around the world. Our discussion focuses on the methodology, the implementation process, the results, and how similar efforts can be used in designing management processes to improve the security of information assets.

INTRODUCTION

Organizations competing in today's global and technological environment are increasingly vulnerable to information-based risk. Recent events involving Barings Bank and Citicorp (Carley and O'Brien, 1995; Smith, 1995); the Internet (Cheswick, 1995; McWilliams, 1995; Cohen, 1995); and computer networks (Charley, 1992; Stoll, 1989; Straub and Nance, 1990) illustrate information systems vulnerability. The National Research Council (1991) addressed computer security issues in a major study and proposed recommendations for system security, safety, reliability, and increasing public awareness of security issues. This analysis was thorough but was limited because it focused primarily on technology-based solutions. Because information flows meld technologies and processes, achieving information security requires more than just implementing technology-based solutions -- it requires management.

Historically, information security has been relegated to the backwaters of information processing organizations. In three surveys that ranked information systems issues in importance (Dickson et al., 1984; Brancheau and Wetherbe, 1987; Niederman, 1991) information security never made the "top ten". Paradoxically, although managers are aware how vulnerable they are to security breaches (Johnson, 1995; Anonymous, 1995), Wilson (1994) indicates that senior managers view information security issues as declining in importance. Results such as these imply that business and operations managers, who ultimately are responsible for information systems performance, must take ownership of information security issues.

In this paper we present a methodology for managing information-based risk. Our methodology differs from methodologies focused on end users and technicians because it involves senior business, operations and systems managers in the risk assessment and decision process. The methodology includes broad risk assessments and is apropos in an era of corporate downsizing and scarce resources, where the time and money required to perform many detailed risk assessments often is not available.

We developed this methodology while working for a money center bank's corporate staff group responsible for developing and implementing processes to manage operational risks. The bank's senior management was concerned that existing risk management processes, primarily based on EDP audits, missed potential risks and resulted in business managers reacting to rather than anticipating information-based risk. They and asked our group to develop and implement a proactive risk management process to identify and address risk problems. The resulting methodology is based on based on scenario analysis and decision analysis (Engemann and Miller, 1992), and supplements existing audit-based techniques. By identifying concerns with the greatest potential impact, it augments formal decision analysis techniques by filtering out low-impact issues and focusing the human and financial resources required by decision analysis on those issues which combine high likelihoods of occurrence and high losses.

Standard procedures used to assess information systems risk and design (Baskerville, 1993; Loch et al., 1992) include identifying what can go wrong, identifying existing controls, evaluating current exposures, identifying new controls, and evaluating these controls and recommending which of these should be implemented. Conventional risk analysis techniques use checklists and questionnaires based on known threats and static polices and procedures (Moulton, 1986; Palmer and Potter, 1990; Menkus, 1991). These approaches, however, are deficient because they may omit security risks not on the checklist; may invite a perpetrator to learn the current system and circumvent its controls; or may become obsolete when faced with technological change.

Our methodology also is based on identifying risks and evaluating controls, but relies heavily on scenario analysis (Parker, 1986; FitzGerald, 1990) which provides the flexibility to analyze risks for unique, dynamic environments. The methodology involves senior business, operations and systems managers in a process to manage information-based risks. In this paper, in addition to presenting the methodology, we will discuss how a program based on the methodology was implemented by a money center bank and how the methodology can supplement an existing information security program.

STUDY QUESTIONS

Many risk management techniques result in business and operations managers reacting to discovered risks, rather than seeking out and managing risks. Though reacting to risks costs more than mitigating or controlling them, managers frequently are willing to take this chance because information-based risk issues involve ill-defined events with very small likelihoods of occurrence. Rather than seek to understand and solve the fundamental problems, managers may view the risks as nuisances to be deflected or explained and as a result, the risks remain. A methodology to manage information-based risk and make business and operations managers more comfortable with information security issues leads to benefits from new managerial perspectives on information security issues, increased support for the information security function, and reduced exposure to the risks themselves. With the above issues in mind, we sought to develop and implement a methodology which:

o was owned by the senior business, operations and systems managers;

o could be implemented at relatively low cost;

o was relatively complete in its coverage of risk issues;

o could be tailored to and implemented in various geographic, technological and organizational environments.

The study questions reflect the degree to which we achieved these goals. Because we participated in the process, our conclusions regarding the methodology's viability and effectiveness are anecdotal and based on one organization's results. But they provide insights for practitioners and researchers who wish to address these issues in more formal research environments.

THE METHODOLOGY

We will refer to the methodology and the resulting program as Information Security Management Planning (ISMP). ISMP is based on scenario analysis and decision analysis, but differs from these techniques in several ways. First, by integrating business, operations, and systems managers into the risk analysis process, ISMP increases non-technical managers' ownership of the process and of the information-based risk issues. Rather than an audit, the process is intended to identify risks before the auditors come. Second, ISMP is flexible and addresses issues specific to unique processing, geographic and organizational environments. It also avoids "security gaps" caused by ignoring risks in environments not covered by policies and procedures. Third, ISMP can be implemented at relatively low cost and ISMP projects can be completed in less time than more formal studies following more detailed risk assessment principles. Cost-benefit principles are used in the methodology's overall structure, both to identify areas with the most potential for detailed analysis and to develop cost-beneficial recommendations in the detailed analysis. However, formal cost-benefit analysis is used sparingly and only when warranted by large potential payoffs.

If conducted annually -- as recommended -- ISMP can identify potential risk events in their early stages and by preventing their occurrence, lead to lower risk management costs. Although developed for global money center bank, ISMP is general and can be used by organizations of all sizes. The actual ISMP process is shown in Figure 1 and consists of three phases: Preliminary Risk Assessment, Detailed Risk Assessment and Controls Implementation.

Preliminary Risk Assessment

The Preliminary Risk Assessment (PRA) is a structured session with senior business, operations, and systems managers, and takes about three hours. The PRA is conducted by the project manager, supported by a senior staff person from the area being studied responsible for information-based risk and a project analyst. The PRA's purpose is to highlight for further analysis, the key information-based risk issues and areas facing the business unit. Senior business managers are interviewed, not for their technical knowledge, but for their often unique perspectives on business implications of risk issues. Beyond their insights, senior manager's involvement and ongoing support is necessary for the program to succeed.

In the PRA the concept of risks and targets are used. Risks relate to what can go wrong and are categorized as fraud (how a perpetrator can manipulate information for financial gain), disclosure of information (how a perpetrator can steal or copy information and disclose it to external parties to gain something or to embarrass someone), and disruption of service (deliberately manipulating or destroying information, hardware and software to hurt the organization). Although errors may result in outcomes similar to those from intentional acts, the PRA focuses on deliberate acts, rather than on happenstance.

Targets are where risks can occur and reflect how the manager views the business. Targets can be functions, departments or even geographic entities. Typically, the project team develops a preliminary target list, which is approved or modified by the senior managers. Table 1 contains a sample of targets and risk ratings (see below) for a hypothetical stand-alone bank, which is similar in structure to the Asian pilot study site discussed below.

The resulting grid generates "target-risk combinations". The risk assessment involves the senior business manager's providing a risk rating for each target-risk combination, given the current controls. Highly rated risks include an explanation for why the rating was applied. For example in Table 1 the cell "Funds Transfer - Fraud" is rated "5" and includes the description "Telecommunication Employees Changing Information". In this case, two telecommunications clerks in a telex room could send and receive funds transfer messages and collude to change instructions before the transactions were released. PRA discussions often include specific concerns which are documented to guide developing detailed scenarios to be examined during the Detailed Risk Assessment (DRA).

Risk issues identified in the PRA are categorized according to overall risk ratings (defined on a 5 point scale with 5 indicating maximal risk) which reflect an event's likelihood of occurring and the magnitude of the loss if it does occur. The project team develops preliminary risk ratings for each target-risk combination which, after critical questioning and discussion, are amended by the senior managers. The ratings are ordinal and can be thought of as "expected loss categories". Risk ratings are used to cull areas to be studied further from those which, at present, need no further analysis.

The PRA process provides business managers with a structured forum to explicitly discuss information security issues in the context of their business. The rating process is a understandable way for them to increase their awareness of information-based risks, take increased ownership of information security management, and obtain their priorities regarding the issues discussed. The process also provides the operations and systems managers with a forum to voice their concerns and break down business manager barriers toward dealing with information security issues. Because of resource constraints, the PRA includes for further analyses in the DRA only target-risk combinations with relatively high ratings -- for example 4 or 5 -- as well as more general problem areas uncovered in the discussion. Managers also can specify "across the board" issues, such as confidentiality of information for all targets.

Detailed Risk Assessment

In the Detailed Risk Assessment (DRA) the project team develops about 15 to 20 detailed scenarios for each highly rated PRA target-risk combination and for other issues identified as requiring detailed analysis. The DRA project team's composition depends upon the organization being studied, its size, and the available resources, but includes the project manager and one or more supporting staff with operational experience, systems knowledge, creativity, and the ability to interface with managers.

The DRA procedure is sequential and takes from one to three months. Initially, project team members meet with managers from each target area to become familiar with the area and to get their insights regarding risk scenarios. Because managers may be defensive and downplay their risk exposure, the team must separate the objective facts from subjective comments, and emphasize that the project's purpose is to identify and address risks rather than to evaluate managerial performance. After preliminary information has been collected, the project team conducts a brainstorming session (the think-like-a-thief-phase) to identify for each target-risk combination a list of potential scenarios. Although master scenario lists can expedite this process, one must be careful since master lists create new risks and are a primer for a potential perpetrator to conduct a fraud, disclose information or disrupt service. If used, master lists must be distributed on a "need to know" basis under appropriate security.

After the brainstorming session, the project team reviews for each target-risk combination being considered the scenarios that were developed and eliminates those which are improbable or unrealistic. The team then combines, modifies, and identifies others. For each scenario, the team identifies potential perpetrators, reviews the existing controls, attaches a risk rating (again on a 1 to 5 scale) to the scenario reflecting the effectiveness of the current controls, identifies potential controls, and selects from these, controls to be implemented. When the list of scenarios for a target has been completed, the project manager and analyst meet with target's department manager or supervisor to review the scenarios, risk ratings, and controls, and make the necessary modifications. Involving the these managers provides detailed information about the scenarios and controls and gives the managers -- who will be responsible for implementing any changes -- ownership of the process.

In this process, DRA risk ratings need not reflect the PRA target-risk combination rating. Generally, DRA scenario's risk ratings usually are lower than PRA risk ratings because the PRA ratings are given by senior managers, who often are unfamiliar with details and rate risks for an entire area based one or two prominent cases. For example, "Funds Transfer - Fraud" is rated as a "5" in Table 1 but Table 2 contains a "Funds Transfer - Fraud" scenario with a risk rating of "2". This rating reflects that this specific scenario has a lower rating than that initially assigned to the class of potential "Funds Transfer - Fraud" scenarios.

The DRA process includes identifying, discarding and recommending potential controls. Cursory cost-benefit analysis often is sufficient to select or discard controls. For example, low-cost controls may have moderate or high impact and high-cost controls may have low impact. Formal decision analysis is usually unnecessary and may be problematic (Baskerville, 1993). Most of the time ISMP relies on old-fashioned management judgement to identify and select recommended controls. The only instance where more formal decision analysis occurs is when costly controls associated with scenarios with high risk ratings must be evaluated. In these high cost - high impact situations, the costs associated with formal decision analysis become warranted.

Because of the potential for errors of omission and commission, the project team must avoid overlooking a risk or improperly classifying a control's impact. This requires knowledge and ingenuity in identifying scenarios and controls. While these errors do happen, reviewing scenarios and controls with operations and systems supervisors and mid-level managers serves as a check which minimizes their occurrence.

The DRA's final step occurs when senior department and division managers review the scenarios and preliminary recommendations. These meetings can change the project findings -- for example, new scenarios may be added, existing controls may be discarded, and new controls may be recommended. After this review, the project team prepares for their senior managers a final list of findings and recommendations, ranging from controls that already have been implemented to recommendations which either require formal cost-benefit analysis or which provide requirements for current or future systems development.

Controls Implementation

Controls Implementation begins with the senior managers who participated in the Preliminary Risk Assessment reviewing the study findings and recommendations with special attention paid to answering questions posed in the PRA. Recommended controls most frequently close security gaps for "high risk" scenarios, reduce risk exposure at minimal cost, or scrap obsolete controls which are holdovers from previous years and now address non-existent risks. Beyond presenting information and closing the study circle, Controls Implementation also is used to obtain senior management's support for subsequent implementation efforts and their continued commitment to the process.

Actually implementing the recommended controls is ISMP's final phase. Each year, the ISMP cycle should begin anew. Targets and risks that were not be investigated one year may be investigated the next, and targets and risks that were investigated may be revisited when technological changes affect the underlying dynamics. This helps ensure that the process and its results are "evergreen" and that new personnel become familiar with risk environments that are constantly changing.

CASE STUDY

This section discusses how we implemented the ISMP methodology and gives some results and conclusions. As participants we focused on development and implementation rather than on ex-post analysis more appropriate in research settings and thus our findings are anecdotal.

Study Approach

The bank that implemented ISMP had many products and businesses in the United States and abroad. Most businesses had their own dedicated operations units and a corporate operations and systems department provided functional support and limited centralized processing services. The bank's Product and Production Risk Executive initiated the ISMP program and during the implementation period, was promoted to head the entire Corporate Operations and Systems Department. Two key program tenets were that information security risks should include -- but not be limited to -- systems issues and that business managers should proactively identify and control risks outside audits discovered them, and certainly before actual risk events occurred.

Before implementing ISMP, we pilot tested the methodology in the bank's U.S. loan processing division and an Asian country with a corporate and a small consumer bank. These sites were selected because they represented domestic and foreign environments and two common organizational forms: A large transaction processing division for one product family and a stand-alone business which processed fewer transactions for many products. Two people from our group and two from the site being studied were on the pilot test teams. Each pilot project took about two months.

Though computer systems security is critical to any information security study, ISMP examined more than "computer risks" because many information-based risks are not necessarily computer based. For one target, telex messages were authenticated via computer algorithms. Once accepted by the system, the messages were printed, stamped, and placed in an in-box on an employee's desk. Changing a telex's electronic text before verification was highly unlikely, but changing the paper on the desk was much easier. This illustrates a overlooked vulnerability that information-based risks often are surprisingly "low tech" and occur at the boundary between computer systems and human beings.

The pilot studies' objective was to develop and implement the ISMP process. Both projects were successful although for the overseas project the managers and staff were more engaged by the issues and the process. The most significant changes to the ISMP process and procedures involved preselecting "strawman" targets and risk ratings, and developing lists of generic scenarios rather than starting each PRA and DRA anew; the above methodology includes these revisions.

Pilot study results and recommendations were presented to the product and operations managers of the loan processing division, and to the country manager of the Asian location and were discussed and implemented according to business-specific timetables. For those areas where the methodology needed to be changed, changes were made. An example of this concerned procedures regarding holding collateral documents for loans. Other recommendations for changes that all units of the corporation would have to make were tabled. For example, line-by-line code reviews were recommended for the Asian country but the country manager was reluctant to approve unless the reviews were part of a corporate policy, and implementing this recommendation was deferred.

We then documented and disseminated the ISMP methodology to all bank departments in a succinct, user-oriented format and supported this with each pilot study documented as a case study. The documented case study was particularly helpful to users in the field because they could copy the format of the results, which helped ensure high quality and consistency across locations. As the bank's production risk management group, we coordinated the implementation process and provided consulting support and training for selected business and operations units implementing the project. Although we reviewed results and made suggestions for enhancements, we did not approve or disapprove study results -- the process was owned by the businesses themselves.

Study Results and Conclusions

The bank directed all business units to implement the ISMP methodology (over 70 domestic and international locations did). Implementation went smoothest for areas with clearly defined business and operations executives -- such as a country or stand-alone business. Implementation was more difficult in businesses with matrix structures where the business manager interviewed (such as a product manager) did not directly manage operations, but rather was a peer of the operations manager.

Most of the recommendations that were implemented were low cost - medium payoff and often involved changes in procedures. Recommendations requiring larger expenditures frequently depended on implementing corporate-wide policies or cross-business information systems, or on implementing larger business specific systems (see Baskerville, 1993 for a discussion of integrating information security into systems development methods). These recommendations served as input for later implementation efforts. Examples included controls affecting corporate policy changes, more detailed software reviews, and developing corporate guidelines for customized software purchased from vendors and used for transaction processing systems. Costly business specific controls usually were tied to MIS applications or transaction processing systems.

Our observations and feedback indicated that the methodology worked well. Business managers indicated that being forced, often for the first time, to confront information security issues was a valuable experience. The Preliminary Risk Assessment and Controls Implementation meetings initiated a conversation about risk that in itself was beneficial. For example, a manager who never thought about how a foreign exchange trader would perpetrate a fraud, suddenly played the role of a dishonest trader. The meetings also provided a forum for senior managers to voice their concerns about technologies which they used but were uncomfortable with, such as electronic mail and computer networks. Discussing risk was educational and provided an opportunity for managers to discuss information-based risk issues in a context other than responding to an audit.

Although the methodology heightened many business managers' awareness of information-based risk issues, it did not completely transform them. Indeed, when the senior executive responsible for the program was promoted, the driving force behind implementation disappeared and many managers held back on performing the methodology on the second of the planned yearly implementations. Our hypothesis regarding why this happened was that managers, even with a heightened sensitivity to security issues, in an era of downsized staffs and reduced budgets still opted to use scarce resources to fight immediate fires rather than to analyze potential risks which they viewed as improbable. Ensuring the ISMP process is used regularly requires managers to think for the long term and realize that allocating human and financial resources to judiciously control risks is cost-beneficial and is good business. Becoming more familiar with information-based risk issues -- which happens when ISMP is used on an ongoing basis -- helps do this, as does the organizational commitment that comes from continued senior manager support for the program.

For senior managers, we found that a succinct Preliminary Risk Assessment worked best. A longer, more detailed PRA -- while perhaps more appropriate analytically -- was not practical. Even at three hours, often attention waned and senior managers lost interest in participating in detailed discussions. As with any "preventive" program, measuring ISMP's success is difficult because one must try to quantify what didn't happen. We feel, however, that ISMP was successful because the process was implemented in many different business, operations, and systems environments and resulted in strengthening the bank's control posture. Projects were most successful when the project team could relate to business managers, understood processing area operations, and possessed creativity and intelligence.

The scenario based methodology of the DRA led to uncovering many business-specific scenarios and exposures that corporate policies did not address. One country manager was particularly pleased at the ability to tailor a corporate-driven program to address the specific needs of his operation. He indicated that this was a first. Using scenarios also proved effective because it helped capture different operations' variability. We believe that other organizations can use this methodology to their advantage. Some specific steps they can follow are:

1. Identify and document a need in the organization for using a methodology such as ISMP. For organizations with unaddressed information-based risks, where existing procedures have proved to be ineffective, or where resource requirements mandate either eliminating existing risk programs or implementing cost effective programs, ISMP is an attractive alternative.

2. Review the ISMP methodology and tailor it to suit the specific organizational culture. Examples of alterations could include changing the project team composition; lengthening or shortening the Preliminary Risk Assessments; changing the five point risk rating scale (see below); or using more formal risk analysis in the Detailed Risk Assessment -- for example, using quantitative estimates for event probabilities and losses rather than qualitative ratings.

3. Obtain senior management commitment and support. Because ISMP makes often new demands on business and operations managers, selling senior management on the need for a proactive rather than reactive risk management program is essential.

4. Put into place a program management structure and identify people in each business unit who will be responsible for implementing the program on a yearly cycle. Formal structures help ensure program continuity and success.

5. Perform several case studies to obtain credibility -- including adjusting the methodology as necessary -- and when done, document and disseminate the results.

6. Implement a communication network -- for example, e-mail or user groups -- for areas working on the project to share their experiences and learn from each other.

7. Proceed with implementation and ongoing maintenance of the program.

Even though this application was in a large organization, nothing about the methodology requires a large organization's structure or resources. Indeed, the methodology worked best in "small" business environments such as overseas branches.

Further research to enhance the methodology falls in three areas:

o Research aimed at eliciting managers' views on risk in settings other than a formal Preliminary Risk Analysis where risks are quantified. Alternatives could draw on techniques used in marketing research such as focus groups, followed by briefing the participating managers regarding the key issues and areas to be addressed in the Detailed Risk Assessment.

o Research aimed at making the process of performing cost-benefit analysis of information-based risks itself more complete and more cost effective. Currently in the Detailed Risk Assessment, risk ratings combine likelihood of occurrence and magnitude of losses into a numerical rating for a scenario. This "low cost" solution also is a "low information" solution because rating categories combine likelihoods and losses into an ordinal measure. An alternative is to use a more classical risk analysis approach of uncoupling likelihood and magnitude and using expected losses or expected utilities. We chose not to do this because hundreds of scenarios had to be examined, and analyzing each scenario requires time and personnel resources -- not to mention data availability -- that were not available. Another option is to use weighted median approaches (Engemann, Miller, and Yager; 1996) which generate median losses. Median losses with and without control alternatives can then be compared with the control's costs in a cost-benefit analysis. Alternative approaches such as these yield quantitative estimates which facilitate using more formal cost-benefit analyses and yield more precise estimates of risk exposure and a control's impact.

o Research aimed at applying the concepts of organizational change to risk issues. To test the methodology itself, research would assess the results of ISMP in various settings and focus on the cost of implementation, the scope of implementation, and the risks uncovered.

In summary, ISMP is an effective way to apply decision analytic principles to proactively identify and control risk by marshalling resources to identify and analyze those risks that are most critical to the business. The methodology is proactive and engages business managers in the entire process, from initial assessment to final implementation. It is particular well suited to current business and technological environments where information-based risks are increasing and the resources to control those risks are becoming more scarce. For these reasons, ISMP can benefit many organizations which depend on information.

REFERENCES

Anonymous (1995). "Top Management Needs to Address Security", Info Canada, 20(2), IC13-IC14.

Baskerville, R. (1993). "Information Systems Security Design Methods: Implications for Information Systems Development", ACM Computing Surveys, 25(4), 375-414.

Brancheau, J.C. and Wetherbe, J.C. (1987). "Key Issues in Information System Management", MIS Quarterly, 11(1), 23-46.

Carley, W.M. and O'Brien, T.L. (1995). "How a Citicorp System was Raided and Funds Moved Around the World", Wall Street Journal, 226(50), 1, 18.

Charley, W. J. (1992). "Rigging Computers for Fraud or Malice is Often an Inside Job, Wall Street Journal, 220(42), 1.

Cheswick, W. (1995). "Is the Internet Secure? No.", Computerworld, 29(22), May 29, 1995), pp. 95-96.

Cohen, F.B. (1995), Protection and Security on the Information Superhighway, New York: Wiley.

Dickson, G.W., Leitheiser R.L., Weatherbe J.C., and Nechis, M. (1984). "Key Information Systems Issues for the 1980's", MIS Quarterly, 8(3), 135-159.

Engemann, K.J. and Miller, H.E. (1992). "Operations Risk Management at a Major Bank", Interfaces, 22(6), 140-149.

Engemann, K.J. , Miller, H.E., and Yager R.A. (1995). "Decision Making Using the Weighted Median Applied to Risk Management" Proceedings of the Third International Symposium on Uncertainty Modeling and Analysis, College Park, Md., 9-13.

FitzGerald, J. and FitzGerald, A. (1990). Designing Controls into Computerized Systems, 2nd. ed., Redwood City, CA: Jerry FitzGerald & Associates.

Johnson, J.T. (1995). "Enterprise Security - Better Safe than Sorry", Data Communications, 24(3), 110-127.

Loch, K.D., Carr, H.H. and Warkentin, M.E. (1992). "Threats to Information Systems: Today's Reality, Yesterday's Understanding", MIS Quarterly, 16(2), 173-186.

McWilliams, B. (1995). "Financial Insecurity", Computerworld, 29(26), 79-84.

Menkus, B. (1991). "Control is Fundamental to Successful Information Security", Computers and Security, 10(4), 293-297.

Moulton, R. (1986). Computer Security Handbook, Englewood Cliffs: Prentice Hall.

Niederman, F., Brancheau, J.C. and Wetherbe, J.C. (1991). "Information Systems Management Issues for the 1990's", MIS Quarterly, 15(4), 475-495.

National Research Council (1991). Computers at Risk, Washington, D.C.: National Academy Press.

Palmer, I.C. and Potter, G.A. (1990). Computer Security Risk Management, New York: Van Nostrand Reinhold.

Parker, D.B. (1986), Computer Crime: Computer Security Techniques, Washington, D.C.: U. S. Department of Justice, Bureau of Justice Statistics Document J29.2:C86.

Stoll, C. (1989). The Cuckoo's Nest, New York: Doubleday.

Straub, D.A. and Nance, W.D. (1990). "Discovering and Disciplining Computer Abuse in Organizations: A Field Study", MIS Quarterly, 14(1), 45-55.

Smith, C.R. (1995). "Risk Management: Avoiding Home-grown Rogue Traders", Bank Systems and Technology, 32(6), 26-28.

Wilson, T. (1994), "Security Awareness Down", CommunicationsWeek, (534), 47-50.

Fraud Disclosure of Disruption

Information of Service

Funds 5- Employees 2 3 - Contingency

Transfer Changing Information Plan Implemented

in Telecommunications

Department Room

Securities 2 3 3

Processing

Foreign 4 - Dealers 4 - Customer 5 - Backing Up

Exchange Trading for Information Trading Room

Own Account

Loan 4 - Changing 3 3

Processing Collateral

Documents

Corporate 2 5 - Customer Lists 1

Finance

Financial 2 3 2

Controls

Human 2 4 - Employee Records 3 - Check Payroll

Resources Processing

Data 2 2 3 - Contingency

Center Plans in place

Private 4 - "Hold Mail" 3 - Recent Study 2

Banking Accounts Could Be Completed

Modified

Legend: Note:

5 - Maximal Risk We defined risk

4 - High Risk to be a function

3 - Moderate Risk of the likelihood

2 - Low Risk of a loss and the

1 - Minimal Risk magnitude of the

loss if it occurs.

TABLE 1: PRELIMINARY RISK ASSESSMENT GRID

Target: Funds Transfer Risk: Fraud

Scenario: Modify information on a funds transfer telex (e.g. beneficiary account number or dollar amount) for purposes of initiating or abetting a fraud.

Perpetrator: Telex Operator

Funds Transfer Clerk

Department Supervisor

Risk Rating: 2 - recently investigated in audit

Existing Controls:

- All telex transactions are verified by second telex clerk;

- Dollar amounts are checked against hash totals;

- Customer expecting transaction would highlight any error that did not benefit him;

- Supervisors review of sent telexes would highlight change by operator;

- Telex supervisors have no access to system regarding making transaction changes;

- Changes are not allowed after verification is complete.

Potential Controls:

- Transaction-by-transaction check against original documents before release;

- Computerized system to telex link;

- Expert system to highlight "strange" accounts or dollar amounts.

Comments:

- Possibility of collusion between operator and verifier.

TABLE 2: DETAILED RISK ASSESSMENT: Sample Scenario