Information Security Risk Analysis

Information Security Risk Analysis
OTHER AUERBACH PUBLICATIONS

A Standard for Auditing Computer Applications Martin Krist ISBN: 0-8493-9983-1 A Technical Guide to IPSec Virtual Private Networks James S. Tiller ISBN: 0-8493-0876-3 Analyzing Business Information Systems Shouhong Wang ISBN: 0-8493-9240-3 Application Servers for E-Business Lisa M. Lindgren ISBN: 0-8493-0827-5 Broadband Networking James Trulove, Editor ISBN: 0-8493-9821-5 Communications Systems Management Handbook, 6th Edition Anura Gurug and Lisa M. Lindgren, Editors ISBN: 0-8493-9826-6 Computer Telephony Integration William Yarberry, Jr. ISBN: 0-8493-9995-5 Data Management Handbook 3rd Edition Sanjiv Purba, Editor ISBN: 0-8493-9832-0 Electronic Messaging Nancy Cox, Editor ISBN: 0-8493-9825-8 Enterprise Operations Management Handbook, 2nd Edition Steve F. Blanding, Editor ISBN: 0-8493-9824-X Enterprise Systems Architectures Andersen Consulting ISBN: 0-8493-9836-3 Enterprise Systems Integration John Wyzalek, Editor ISBN: 0-8493-9837-1 Healthcare Information Systems Phillip L. Davidson, Editor ISBN: 0-8493-9963-7 Information Security Architecture Jan Killmeyer Tudor ISBN: 0-8493-9988-2 Information Security Management Handbook, 4th Edition, Volume 2 Harold F. Tipton and Micki Krause, Editors ISBN: 0-8493-0800-3 IS Management Handbook, 7th Edition Carol V. Brown, Editor ISBN: 0-8493-9820-7 Information Technology Control and Audit Frederick Gallegos, Sandra Allen-Senft, and Daniel P. Manson ISBN: 0-8493-9994-7 Information Security Risk Analysis Thomas Peltier ISBN: 0-8493-0880-1 Internet Management Jessica Keyes, Editor ISBN: 0-8493-9987-4 Local Area Network Handbook, 6th Edition John P. Slone, Editor ISBN: 0-8493-9838-X Multi-Operating System Networking: Living with UNIX, NetWare, and NT Raj Rajagopal, Editor ISBN: 0-8493-9831-2 TCP/IP Professional Reference Guide Gilbert Held ISBN: 0-8493-0824-0 The Network Managers Handbook, 3rd Edition John Lusa, Editor ISBN: 0-8493-9841-X Project Management Paul C. Tinnirello, Editor ISBN: 0-8493-9998-X Effective Use of Teams in IT Audits, Martin Krist ISBN: 0-8493-9828-2 Systems Development Handbook, 4th Edition Paul C. Tinnirello, Editor ISBN: 0-8493-9822-3
AUERBACH PUBLICATIONS
www.auerbach-publications.com TO Order: Call: 1-800-272-7737 Fax: 1-800-374-3401 E-mail: orders@crcpress.com
THOMAS R. PELTIER
Boca Raton London New York Washington, D.C.
This edition published in the Taylor & Francis e-Library, 2005. To purchase your own copy of this or any of Taylor & Francis or Routledges collection of thousands of eBooks please go to www.eBookstore.tandf.co.uk.
Library of Congress Cataloging-in-Publication Data

Peltier, Thomas R. Information security risk analysis / Thomas R. Peltier. p. cm. Includes bibliographical references and index. ISBN 0-8493-0880-1 (alk. paper) 1. Computer security. 2. Computer networksSecurity measures. 3. Risk assessment. I. Title. QA76.9.A25 P429 2001 005.8dc21 00-050244 CIP This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. Neither this book nor any part may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, microlming, and recording, or by any information storage or retrieval system, without prior permission in writing from the publisher. The consent of CRC Press LLC does not extend to copying for general distribution, for promotion, for creating new works, or for resale. Specic permission must be obtained in writing from CRC Press LLC for such copying. Direct all inquiries to CRC Press LLC, 2000 N.W. Corporate Blvd., Boca Raton, Florida 33431. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identication and explanation, without intent to infringe.
2001 by CRC Press LLC Auerbach is an imprint of CRC Press LLC No claim to original U.S. Government works International Standard Book Number 0-8493-0880-1 Library of Congress Card Number 00-050244 ISBN 0-203-99750-6 Master e-book ISBN
Dedication
To Lisa, never a risk only an asset.
Contents
Acknowledgments......................................................................ix Introduction................................................................................xi Chapter 1 Effective Risk Analysis................................................................1 Chapter 2 Qualitative Risk Analysis ..........................................................23 Chapter 3 Value Analysis ...........................................................................47 Chapter 4 Other Qualitative Methods.......................................................53 Chapter 5 Facilitated Risk Analysis Process (FRAP) ................................69 Chapter 6 Other Uses of Qualitative Risk Analysis .................................91 Chapter 7 Case Study...............................................................................101 Appendix A Questionnaire ..........................................................................157 Appendix B Facilitated Risk Analysis Process (FRAP) Forms ..................183 Scope/Business Process Identication ..................................183 Action Plan ..............................................................................184 Final Report.............................................................................189 Controls List ............................................................................190 Risk List ...................................................................................193 Control/Risks Cross Reference List........................................194 Appendix C Business Impact Analysis (BIA) Forms.................................195 Appendix D Sample of Report ....................................................................201 Appendix E Threat Denitions ...................................................................203 Appendix F Other Risk Analysis Opinions................................................217 F1. Risk Assessment and Management................................221 Will Ozier F2. New Trends in Risk Management .................................245 Caroline Hamilton F3. Integrated Risk ManagementA Concept for Risk Containment......................................................257 Jose Martinez Index ..............................................................................................................273
vii
Acknowledgments
Those who take sole credit for any task completed or process developed have forgotten where they came from and who helped them get to where they are now. When discussing risk analysis, many people do not want to have their names associated in any way with the process. This is one of those tasks that needs to be done, and the best way to do it is to make the task as simple as possible. Over the years, I have been able to learn the process of risk analysis from the best teachers around my peers. First on my list of acknowledgments is my mentor and friend, John OLeary, the Director of the Computer Security Institutes Education Resource Center. It was his encouragement to Try it. If they dont stone you, then youre onto something. Johns approach is always a bit more formal, but he encouraged me to nd the path of least resistance. The next group that needs addressing is the British contingent. John Blackley (a Scot), who found it difcult that I could nd enough material to talk about risk analysis for two days. Gareth Davies (a Welshman), who introduced me to the subject of qualitative risk analysis. David Lynas (an Irishman), who showed me how risk analysis ts into proper security architecture. Also part of this group is the big Canadian, Dan Erwin, who introduced the concept of facilitation to risk analysis. Finally, the team that helped me put together the Facilitated Risk Analysis Process (FRAP); Lisa Bryson, the project lead; Sherry Giardino, the rst facilitator; Mike Kadar, the technical expert; and the rest of the team. The creation of a book is a team effort that requires the contribution of many people. Thus, I would be remiss if I did not acknowledge the efforts of the many people who were instrumental in converting the writings of this author into the book you are now reading. It is always important to have the backing of the acquisitions editor and publisher; however, it is even better to have enthusiastic support for a writing project. Thus, I would like to thank Rich OHanley for his enthusiastic backing of this book.
ix
Introduction
The dictionary denes risk as someone or something that creates or suggests a hazard. In todays environment, it is one of the many costs of doing business or providing a service. Information security professionals know and understand that nothing ever runs smoothly for very long. Any manner of internal or external hazard or risk can cause a well-running organization to lose competitive advantage, miss deadlines, or suffer embarrassment. As security professionals, management is looking to us to provide a process that allows for the systematic review of risk, threats, hazards, and concerns and provide costeffective measures to lower risk to an acceptable level. This book will review the current practical application of cost-effective risk analysis.
xi
Chapter 1
Effective Risk Analysis

The dictionary denes risk as someone or something that creates or suggests a hazard. In todays environment, it is one of the many costs of doing business or providing a service. Information security professionals know and understand that nothing ever runs smoothly for very long. Any manner of internal or external hazard or risk can cause a well-running organization to lose competitive advantage, miss deadlines, or suffer embarrassment. As security professionals, management is looking to us to provide a process that allows for the systematic review of risk, threats, hazards, and concerns and provide costeffective measures to lower risk to an acceptable level.
Frequently Asked Questions About Risk Analysis

Why Should a Risk Analysis Be Conducted?
Management is charged with showing that due diligence is performed during decision-making processes for any enterprise. A formal risk analysis provides the documentation that due diligence is performed. A risk analysis also lets an enterprise take control of its own destiny. With an effective risk analysis process in place, only those controls and safeguards that are actually needed will be implemented. An enterprise will never again face having to implement a mandated control to be in compliance with audit requirements.
When Should a Risk Analysis Be Conducted?

A risk analysis should be conducted whenever money or resources are to be spent. Before starting a task, project, or development cycle, an enterprise should conduct an analysis of the need for the project. Understanding the
1
concepts of risk analysis and applying them to the business needs of the enterprise will ensure that only necessary spending is done.
Who Should Conduct the Risk Analysis?

Most risk analysis projects fail because the internal experts and subject matter experts are not included in the process. A process such as the Facilitated Risk Analysis Process (FRAP) takes advantage of the internal experts. No one knows systems and applications better than the people who develop and run them.
How Long Should a Risk Analysis Take?

It should be completed in days not weeks or months. To meet the needs of an enterprise, the risk analysis process must be able to complete it quickly with a minimum of impact into the employees already busy schedule.
What Can a Risk Analysis Analyze?

Risk analysis can be used to review any task, project, or idea. By learning the basic concepts of risk analysis, the organization can use it to determine if a project should be undertaken, if a specic product should be purchased, if a new control should be implemented, or if the enterprise is at risk from some threat.
What Can the Results of a Risk Analysis Tell an Organization?

The greatest benet of a risk analysis is whether it is prudent to proceed. It allows management to examine all currently identied concerns, prioritize the level of vulnerability, and then to select an appropriate level of control or to accept the risk. The goal of risk analysis is not to eliminate all risk. It is a tool to be used by management to reduce risk to an acceptable level.
Who Should Review the Results of a Risk Analysis?

A risk analysis is rarely conducted without a senior management sponsor. The results are geared to provide management with the information it needs to make informed business decisions. The results of a risk analysis are normally classied as condential and are provided only to the sponsor and to those deemed appropriate by the sponsor.
How Is the Success of the Risk Analysis Measured?

The tangible way to measure success is to see a lower bottom line for cost. Risk analysis can assist in this process by identifying only those controls that need to be implemented.
Another way that the success of a risk analysis is measured is if there is a time when management decisions are called into review. By having a formal process in place that demonstrates the due diligence of management in the decisionmaking process, this kind of inquiring will be dealt with quickly and successfully.
Risk Analysis as Part of a Quality Assurance Program

To be effective, a risk analysis process must be accepted as part of the business process of the enterprise. The risk management professional looks to ensure that the analysis process supports the business objectives or mission of the organization. There are no such things as audit requirements or security requirements. There are only business or mission requirements. An effective risk analysis will search for the business needs of the enterprise and will address safeguards to meet those needs. To be successful, the needs of the customer must be identied and met. Every time a risk analysis is to be conducted, the risk management professional must meet with the client to determine what is to be reviewed, what kinds of risks are to be examined, and what the client needs as a deliverable or results from the process. Most of this book focuses on the key elements of an information security risk analysis: the integrity, condentiality, and availability of information resources. These are only initial examples of what can be examined by an effective risk analysis process. This book reviews a number of risk analysis methods and critiques each of them. By looking at different methods, the reader will be able to build a risk analysis process that will meet his or her organizations special needs. As part of a quality assurance process, risk analysis should be one of four key elements to be completed prior to any application, system, project, or process going into production. Each of the four elements identied above can use the basic qualitative risk analysis process to develop methodologies to assist the business units in completing these tasks. By ensuring that a process is in place to assist the business units, there is a greater chance that these tasks will actually be completed. By doing so, the quality of the products delivered will improve. Implementing controls after development has begun will increase their cost by nearly eightfold. By examining what is needed in the analysis phase of the System Development Life Cycle (SDLC) (see Exhibit 1.1) and having an effective risk management program, the costs for controls will be held to a reasonable level. According to Systems Management magazine, top IS project managers were asked what functional capability they most needed to be successful; the number one answer was risk management. Projects often have involuntary risks imposed on them, risks the project-lead does not recognize or understand and therefore has not agreed to. As a result, the project manager is often surprised by negative consequences and the project sponsor suffers unmet expectations.
Exhibit 1.1
System Development Life Cycle
The risk analysis process must be geared to support the business or mission of the enterprise. Many times, one hears the user community being told that certain controls are being implemented because the controls are audit requirements or security requirements. There are no such requirements; there are only business or mission requirements. Auditors review the level of compliance to approved enterprise policies and procedures and issue comments that address weaknesses or variances from existing documentation. The role of security (whether physical or information) is to assist management in meeting its duciary responsibility to adequately protect the assets of the enterprise. With capital assets, it is easy to see that stealing property affects the enterprises ability to conduct business. So now, the security professional must help management identify intellectual property and implement effective, cost-efcient safeguards.
Risk Management Quality Assurance Requires Identication of Information as an Enterprise Asset

Every enterprise has is own set of requirements for the protection of information assets, which are usually documented through an information classication policy and analysis methodology. The individual safeguards will differ depending on whether the availability, integrity, or condentiality is being considered. Therefore, the goal of an enterprisewide information quality assurance program is to preserve the: Integrity: the information is as intended without inappropriate modication or corruption
Condentiality: the information is protected from unauthorized or accidental disclosure Availability: authorized users can access applications and systems when required to perform their jobs The process for classifying information needs to be well-dened, and a methodology to assist users in determining the level of classication needs to be developed as part of the risk management quality assurance process (methods to actually complete this process are discussed later). To assist the information risk management process, it will be necessary to have the users visualize the elements that make up the value of the information asset. These might include some, all, or more of the following: 1. 2. 3. 4. 5. 6. 7. 8. 9. cost of producing the information value of the information on the open market cost of reproducing the information if destroyed benet the information brings to the enterprise in meeting its business objectives or mission repercussion to the enterprise if the information was not readily available advantage it would give to a competitor if they could use, change, or destroy the information cost to the enterprise if the information was released, altered, or destroyed loss of client or customer condence if the information was not held and processed securely loss of public credibility and embarrassment if the information was not secure
The value of a particular information resource must be determined by the business unit managers who use the resource. This process cannot be discharged to the Information Security staff, to Information Systems, or to any other third party; it must remain with the business unit.
Standard Risk Analysis Methodology

No matter what risk analysis process is used, the method remains the same: 1. Identify the asset to be reviewed. 2. Ascertain the threats, risks, concerns, or issues to that asset. 3. Prioritize the risk or determine the vulnerability of the threat to the asset. 4. Implement corrective measures, controls, safeguards, or accept the risk. 5. Monitor the effectiveness of the controls and assess their effectiveness.
Asset Identication
The team conducting or facilitating the risk analysis process will often be viewed by management and employees as, at best, pure overhead and, at worst, a hindrance to job completion (see Exhibit 1.2). To minimize negative reactions and to be sure that important safeguards are implemented, the very rst step in risk analysis is to identify the assets that must be protected. A properly focused risk analysis will ensure the proper balance between meeting business objectives or the mission of the enterprise and the need for proper controls. Another way to look at the problem is to nd the balance between a fortress mentality and the open campus.
Exhibit 1.2 Balancing Controls versus Business Objectives
The Only Safe Asset is a Dead Asset Life is full of trade-offs and protecting assets is no different 1. The only safe asset is a dead asset. Or at least a locked away one. If no one can get to it, no one can harm it. The only problem is, it is not exactly useful in this state. So, the extent of controls is always a trade-off between putting the asset to use and restricting its misuse and abuse. 2. The time and money spent on securing an asset has to be weighed against the likelihood of loss: Axiom: Dont spend resources to protect garbage. 3. The hacker likewise has a cost-benet trade-off. If it takes too long to enter, the criminal will go elsewhere. But remember one of the key rules of combat: Make it too tough for the enemy to get in and you will not be able to get out.
What then is an asset? An accountant might say that an asset is anything of value. However, many times the asset in question is a tangible piece of property that can be seen. Enterprises now are dividing assets into at least two major headings: Physical: those items that can be seen Logical: the intellectual property of the enterprise Other classication levels might include people, physical and environmental, telecommunications, hardware, software and data or information (see Exhibits 1.3 and 1.4). Another list might include topics such as hardware, software, data and information, and people and procedures. All too often, management tends to focus on the enterprises physical assets. In actuality, this is probably the least of the total investment and easier to recover.
Exhibit 1.3 Asset Identication: Networks and Software

Networks Software a
Front-end processors Workstations Modems Communication lines Data encryption tools Satellite connections Remote access security
a
Operating systems Utilities Compilers Database software Application software Catalogued procedure libraries
Be sure to consider both purchased third-party and inhouse developed software.
Exhibit 1.4 Asset Identication: Physical and Other Assets

Physical Other
The building HVAC a Furniture Supplies Machinery Fire control systems

a
Employees Policies Procedures Customer condence
Heating, ventilation, and air conditioning.
When identifying physical assets, it might be necessary to look into the physical location of the enterprise. As will be discussed, the location of an enterprise can be an asset or a threat. The proper denition of the asset to be reviewed in the risk analysis process will be vital to the success of the process. The ability to precisely identify what a specic asset is cannot be over-emphasized. For all of the next few key points, the ability to agree on a common denition will speed the risk analysis process along.
Threat Identication
Having identied the assets that need to be protected, one must begin to look for and identify the threats to those assets. What then is a threat? Based on the context in which it is used, threat can mean a number of things, none of them typically good. A threat is normally looked upon as an intent to do something bad to someone or something. According to Webster, a threat is an indication of an impending undesirable event or, this authors favorite, an expression of intention to inict evil, injury, or damage.
There can be an unlimited number of threats that may be of concern to an enterprise. Any number of good threats can be identied, such as re, ood, or fraud. It is very important to consider threats, no matter how unlikely they might seem. What about the threat of a nuclear holocaust? Has it increased or decreased since the end of the Cold War? What about the threat of terrorist bombing? Has this increased over the past ten years? Have natural disasters increased over the past ten years? For the rst and third threats, the answer is yes. Nuclear proliferation has increased, as have natural disasters. Bombings have remained somewhat constant over the past 30 years, but there have been two high-prole events since the 1993 bombing of the World Trade Center and the 1995 Oklahoma City bombing. Only those threats with a likelihood of zero (e.g., a hacker threat to a system with no dial-up capabilities) can be ignored. A starting point would be to consider those threats that might actually impact an enterprise, as shown in Exhibit 1.5.
Exhibit 1.5 Common Threats to Assets
Fire Fraud Earthquake Extortion Ice storm Misappropriation of services Volcanic eruption Flood Denial of service Embezzlement Hurricane Theft Unauthorized access
Elements of Threats
When examining threats, experts identify three elements that are associated with threat: 1. The agent is the catalyst that performs the threat. The agent can be human, machine, or nature. 2. The motive is something that causes an agent to act. These actions can be either accidental or intentional. Based on the elements that make up an agent, the only motivating factor that can be both accidental and intentional is human. 3. The results are the outcome of the applied threat. For the information security profession, the results normally lead to a loss of access, unauthorized access, modication, disclosure, or destruction of the information asset.
For most risk management professionals, it will be necessary to identify possible threats. There are a number of ways that this can be accomplished. The rst way may be to review current risk management textbooks and develop a list of possible threats. The denitions on weather conditions can be found on various Web sites relating to weather conditions (see also Exhibit 1.6). Many local news stations have their own Web site with denitions of the most common forms of weather found in a particular community. This is an ideal source for local terms. The Weather Channel has a site for common denitions for global conditions. To obtain an understanding of local conditions, it is recommended that local Web sites be researched.
Exhibit 1.6 Natural Threats
Air pollution: The soiling of the atmosphere by contaminants to the point that may cause injury to health, property, plant, or animal life, or prevent the use and enjoyment of the outdoors. Alberta Clipper: A fast-moving, snow-producing weather system that originates in the lee of the Canadian Rockies. It moves quickly across the northern United States, often bringing gusty winds and cold Arctic air. Black blizzard: A local term for a violent dust storm on the south-central Great Plains that darkens the sky and casts a pall over the land. Blizzard: A severe weather condition characterized by low temperatures, winds 35 mph or greater, and sufcient falling or blowing snow in the air to frequently reduce visibility to 1/4 mile or less for a duration of at least three hours. A severe blizzard is characterized by temperatures near or below 10F, winds exceeding 45 mph, and visibility reduced by snow to near zero. Cold air funnel: Funnel clouds, usually short-lived, that develop from relatively small showers or thunderstorms when the air aloft is very cold. Cold air funnels may touch down briey, but in general are less violent than most other types of tornadoes. Cyclone: An area of closed pressure circulation with rotating and converging winds, the center of which is a relative pressure minimum. The circulation is counterclockwise in the Northern Hemisphere and clockwise in the Southern Hemisphere. Also called a low pressure system and the term used for a tropical cyclone in the Indian Ocean. Other phenomena with cyclonic ow may be referred to by this term, such as dust devils, tornadoes, and tropical and extratropical systems. The opposite of an anticyclone or a high pressure system. Drifting snow: Snow particles blown from the ground by the wind to a height of less than six feet. Earthquake: A sudden, transient motion or trembling of the earths crust, resulting from the waves in the earth caused by faulting of the rocks or by volcanic activity. Erosion: The movement of soil or rock from one area to another by the action of the sea, running water, moving ice, precipitation, or wind. Flash ood: A ood that rises and falls quite rapidly with little or no advance warning, usually as the result of intense rainfall over a relatively small area. Flash oods can be caused by situations such as a sudden excessive rainfall, the failure of a dam, or the thaw of an ice jam. (continues)
10 Exhibit 1.6 Natural Threats (Continued)
Flood: High water ow or an overow of rivers or streams from their natural or articial banks, inundating adjacent low-lying areas. Funnel cloud: A violent, rotating column of air visibly extending from the base of a towering cumulus or cumulonimbus cloud toward the ground, but not in contact with it. It is reported as FC in an observation and on the METAR. Gale: On the Beaufort Wind Scale, a wind with speeds from 28 to 55 knots (32 to 63 mph). For marine interests, it can be categorized as a moderate gale (28 to 33 knots), a fresh gale (34 to 40 knots), a strong gale (41 to 47 knots), or a whole gale (48 to 55 knots). In 1964, the World Meteorological Organization dened the categories as near gale (28 to 33 knots), gale (34 to 40 knots), strong gale (41 to 47 knots), and storm (48 to 55 knots). Hail: Precipitation that originates in convective clouds, such as cumulonimbus, in the form of balls or irregular pieces of ice, which comes in different shapes and sizes. Hail is considered to have a diameter of 5 mm or more; smaller bits of ice are classied as ice pellets, snow pellets, or graupel. Individual lumps are called hailstones. It is reported as GR in an observation and on the METAR. Small hail and snow pellets are reported as GS in an observation and on the METAR. Hurricane: The name for a tropical cyclone with sustained winds of 74 miles per hour (65 knots) or greater in the North Atlantic Ocean, Caribbean Sea, Gulf of Mexico, and in the eastern North Pacic Ocean. This same tropical cyclone is known as a typhoon in the western Pacic and a cyclone in the Indian Ocean. Ice storm: A severe weather condition characterized by falling, freezing precipitation. Such a storm forms a glaze on objects, creating hazardous travel conditions and utility problems. Lake effect snow: Snow showers that are created when cold dry air passes over a large warmer lake, such as one of the Great Lakes, and picks up moisture and heat. Lightning: A sudden and visible discharge of electricity produced in response to the buildup of electrical potential between cloud and ground, between clouds, within a single cloud, or between a cloud and surrounding air. Monsoon: The seasonal shift of winds created by the great annual temperature variation that occurs over large land areas in contrast with associated ocean surfaces. The monsoon is associated primarily with the moisture and copious rains that arrive with the southwest ow across southern India. The name is derived from the word mausim, Arabic for season. This pattern is most evident on the southern and eastern sides of Asia, although it does occur elsewhere, such as in the southwestern United States. Sandstorm: A strong wind carrying sand particles through the air. They are lowlevel occurrences, usually only ten feet in height to not more than 50 feet above the surface. Due to the frequent winds created by surface heating, they are most predominant during the day and die out in the night. Visibility is reduced to between 5/8ths and 6/16ths statute mile, and if less than 5/16ths, then the storm is considered a heavy sandstorm. It is reported as SS in an observation and on the METAR.
11
Exhibit 1.6 Natural Threats (Continued)

Severe thunderstorm: A thunderstorm with winds measuring 50 knots (58 mph) or greater, 3/4-inch hail or larger, or tornadoes. Severe thunderstorms may also produce torrential rain and frequent lightning. Smoke: Small particles produced by combustion that are suspended in the air. A transition to haze may occur when the smoke particles have traveled a great distance (25 to 100 miles or more), and when the larger particles have settled out. The remaining particles become widely scattered through the atmosphere. It is reported as FU in an observation and on the METAR. Snow: Frozen precipitation in the form of white or translucent ice crystals in complex branched hexagonal form. It most often falls from stratiform clouds, but can fall as snow showers from cumuliform ones. It usually appears clustered into snowakes. It is reported as SN in an observation and on the METAR. Surge: The increase in seawater height from the level that would normally occur was there no storm. Although the most dramatic surges are associated with hurricanes, even smaller low-pressure systems can cause a slight increase in the sea level if the wind and fetch are just right. It is estimated by subtracting the normal astronomic tide from the observed storm tide. Tornado: A violently rotating column of air in contact with and extending between a convective cloud and the surface of the earth. It is the most destructive of all storm-scale atmospheric phenomena. Tornadoes can occur anywhere in the world given the right conditions, but are most frequent in the United States in an area bounded by the Rockies on the west and the Appalachians in the east. Tsunami: An ocean wave with a long period that is formed by an underwater earthquake or landslide, or volcanic eruption. It may travel unnoticed across the ocean for thousands of miles from its point of origin and builds up to great heights over shallower water. Also known as a seismic sea wave, and incorrectly, as a tidal wave. Typhoon: The name for a tropical cyclone with sustained winds of 74 miles per hour (65 knots) or greater in the western North Pacic Ocean. This same tropical cyclone is known as a hurricane in the eastern North Pacic and North Atlantic Ocean, and as a cyclone in the Indian Ocean. Yellow snow: Snow that is given golden, or yellow, appearance by the presence of pine or cypress pollen.
Other sources for national weather conditions, denitions, and rates of occurrence are: National Hurricane Center (NHC): A branch of the Tropical Prediction Center, it is the ofce of the National Weather Service that is responsible for tracking and forecasting tropical cyclones over the North Atlantic, Caribbean, Gulf of Mexico, and the Eastern Pacic. National Meteorological Center (NMC): Now incorporated into the National Centers for Environmental Prediction, it was the division of the National
12
Weather Service that produced, processed, handled, and distributed meteorological and oceanographic information to users throughout the Northern Hemisphere, specically U.S. governmental organizations. National Oceanic and Atmospheric Administration (NOAA): A branch of the U.S. Department of Commerce, it is the parent organization of the National Weather Service. It promotes global environmental stewardship, emphasizing atmospheric and marine resources. National Severe Storms Forecast Center (NSSFC): As of October 1995, the responsibilities of this Center were divided into two branches, the Storm Prediction Center and the Aviation Weather Center. National Severe Storms Laboratory (NSSL): A branch of the National Oceanic and Atmospheric Administration, it provides accurate and timely forecasts and warnings of hazardous weather events, especially ash oods, hail, lightning, tornadoes, and other severe windstorms. National Weather Association (NWA): An organization whose membership promotes excellence in operational meteorology and related activities, recognizing the professional as well as the volunteer. National Weather Service (NWS): A primary branch of the National Oceanic and Atmospheric Administration, it is responsible for all aspects of observing and forecasting atmospheric conditions and their consequences, including severe weather and ood warnings. It will be necessary to identify accidental threats and intentional threats. It cannot be stressed enough that the denitions will be the key to a successful risk analysis process. Too many times, risk teams attempt to determine the impact of a specic threat, while each member has his or her own understanding of what the specic threat means. Exhibit 1.7 lists accidental and intentional threats developed by John OLeary, Director of the Education Resource Center of the Computer Security Institute. As one can see, some of the denitions will need to be examined and rened. As an example, re; there are at least three denitions for re that would take into account a small re, a moderate re, and a catastrophic re. For team members to give creditable service to the risk analysis process, it will be necessary to have the denitions as precise as possible.
Factors Affecting Threats

Identifying a threat is just the rst part of the analysis phase. It is also necessary to determine just how vulnerable the enterprise is to that threat. There are a number of factors that impact a threat. There are nearly as many factors affecting the threat and its impact on the enterprise as there are threats. Geographical location can have an impact on the threat model. If located in the Midwest, some natural threats will not be an area of concern. There
13
Exhibit 1.7 Accidental and Intentional Threats

Developed by John OLeary, Director of the Education Resource Center of the Computer Security Institute.
Threat Denitions Accidental

Disclosure: The unauthorized or premature accidental release of proprietary, classied, company condential, personal, or otherwise sensitive information. Electrical disturbance: A momentary uctuation in the electrical power source, consisting of either a voltage surge (peak), voltage dip, or interruptions of less than one-half hour. Electrical interruption: A long-term disruption in the electrical power source, usually greater than one-half hour. Emanation: The inadvertent emanation or transmission of data signals from components of computers, computer peripherals, and word processors, which may be recorded by monitoring equipment. Environmental failure: An interruption in the supply of controlled environmental support provided the operations center. Environmental controls would include air quality, air conditioning, humidity, heating, and water. Fire: A conagration affecting information systems either through heat, smoke, or suppression agent damage. This threat category can be further broken down into minor, major, and catastrophic. Hardware failure: A unit or component failure of sufcient magnitude to cause delays in processing or monetary loss to the enterprise. Liquid leakage: A liquid inundation from sources other than a ood. Examples of this include burst or leaking pipes, and the accidental discharge of sprinklers. Operator/User error: An accidental, improper, or otherwise ill-chosen act by an employee that results in processing delays, equipment damage, lost data, or modied data. Software error: Any extraneous or erroneous data in the operating system or applications program that results in processing errors, data output errors, or processing delays. Telecommunications interruption: Any communications unit or component failure of sufcient magnitude to cause interruptions in the data transfer via telecommunications between computer terminals, remote or distributed processors, and host computing facility.
Threat Denitions Intentional

Alteration of data: An intentional modication, insertion, or deletion of data, whether by authorized users or not, that compromises the auditability, recoverability, availability, condentiality, or integrity of the information produced, processed, controlled, or stored by the information processing systems. (continues)
14
Exhibit 1.7 Accidental and Intentional Threats (Continued)

Alteration of software: An intentional modication, insertion, or deletion of operating system or application system programs, whether by an authorized user or not, that compromises the auditability, efciency, recoverability, availability, condentiality, or integrity of information, programs, the system, or resources controlled by the computer systems. Bomb threat: A notication of the existence of an explosive device at a facility, whether true or not. Disclosure: The unauthorized or premature intentional release of proprietary, classied, company condential, personal, or otherwise sensitive information. Employee sabotage: A deliberate action taken by an employee, group of employees, or non-employee(s) working together with an employee(s) to disrupt enterprise operations. Enemy overrun: A forceful occupation of an activity by a force whose intentions are inimical to the government. Fraud: A deliberate unauthorized manipulation of hardware, software, or information with the intent of nancial gain for the perpetrator. Riot/Civil disorder: A group unrest (whether organized or not) which causes widespread and uncontrollable suspension of law and social order. Strike: An organized employee action (union or not, legal or not) designed to halt or disrupt normal business operations. Strikes can be categorized as unfair labor practice, economic, or unprotected strikes. Theft: The unauthorized appropriation of hardware, software, media, computer supplies, or data of a classied nature but included in the disclosure category. Unauthorized use: An unauthorized use of computer equipment or programs. Examples of this include the running of personal programs such as games, inventories; browsing other les. Vandalism: The malicious and motiveless destruction or defacement of property.
are very few dust storms in Lincoln, Nebraska. While Detroit and the northern states and cities are accustomed to handling ice and snow, just the threat of an inch of snow can send southern cities into a panic. Beyond the natural threats, geography can also impact the infrastructure supporting an enterprise. The northeastern United States has too many people and businesses for the existing support infrastructure. Telecommunications, power, electricity, and roads are stretched to their capacity and any additional impact can and often does cause problems. The facility that an enterprise is housed in can impact threats. Depending on the age of the building, it can either be an asset or a threat. Do not be confused by thinking that only newer construction is safer. In many instances, the older structures are able to withstand some pretty impressive happenstance. Look to see the construction of the complex and determine if there is an active re-suppression system installed and tested.
15
Who the facility is shared with and who the neighbors are can affect the level or vulnerability the threat is to an enterprise. During a recent physical security review, a particular seven-story ofce complex was typical when it came to security ofcers in the lobby, an additional level of access for restricted areas, and a re-suppression system that is tested. The biggest threat to the enterprise was the fact that it shared the building with non-company law enforcement agencies. Other factors that might impact the level of vulnerability include: Information sensitivity: what kinds and type of information does the enterprise generate? Employee emergency training: have employees been trained to respond to emergency incidents? Are there procedures in place that will assist employees during an emergency? Protection and detection features: are there additional asset protection features in place? Can the enterprise detect when a threat is happening? Employee morale: are employees unusually dissatised? Is there unrest within the ranks? Local economic conditions: is the surrounding area economically deprived? Visibility: is the organization a high-prole company or agency? Redundancies: are there backup systems in place? Prociency level of employees: are employees properly trained? Written procedures: are there written desk procedures in place? Are these procedures used to train backup personnel? Employee security awareness: do employees attend annual security awareness sessions? Past prosecutions: has the enterprise ever sought relief in the courts for attacks on their assets? Has information been turned over to law enforcement for criminal prosecution? Any or all of these factors can increase or decrease the level of impact a threat may have on an enterprise and its assets.
Threat Occurrence Rates

Once assets and threats have been identied, it will be necessary to establish some link between the two. One of the most basic forms of risk analysis in a process known as an Annual Loss Exposure (ALE). The ALE takes the value of an asset and then uses the likelihood of a threat occurrence in a formula to calculate the ALE: the asset value (V) multiplied by the likelihood (L) of the threat (V L = ALE). Getting and understanding the likelihood of an occurrence is going to take some work. For natural threats, the local and national weather center can and do track the number of occurrences of a specic weather threat during a
16
calendar year. The risk management team will need to research these ndings and then develop a table. This table can be an average based on the number of occurrences, divided by the number of years. Or, one can track the number of occurrences over a ve-year period and develop a rate of occurrence, with the lowest number at one end of the range and the highest number at the other. For all other types of threats (accidental or deliberate), it will be necessary to do additional research. For criminal activities, the risk management team can look to local law enforcement, the FBI, and state agencies. Each entity keeps a log of the number of times a specic activity has occurred within its jurisdiction. This information, along with the information gathered by the enterprises internal audit and security staffs, will provide the rates of occurrence similar to those found through the weather bureaus. For some threats, it may be necessary to contact the enterprises insurance company to ascertain if there is any information that can shared. Do not forget to review the system incident logs to determine errors, omissions, hardware failure, software bugs, and other types of system-related threats. Once the leg work has been done, one can use something like the table in Exhibit 1.8 to show annual rates of occurrence.
Exhibit 1.8 Annualized Loss Multiplier Table
Never Once in 300 Years Once in 200 Years Once in 100 Years Once in 50 Years Once in 25 Years Once in 5 Years Once in 2 Years Yearly Twice a Year Once a Month Once a Week Once a Day 1/300 1/200 1/100 1/50 1/25 1/5 1/2 1/1 1/.5 12/1 52/1 365/1 0.0 0.00333 0.005 0.01 0.02 0.04 0.20 0.50 1.0 2.0 12.0 52.0 365.0
The ALE would work as follows. A $3 million data center is located in a ood area. A major ood that would destroy the data center occurs once every 100 years. Value = $3 million Likelihood = once every 100 years (using Exhibit 1.8, L = 0.01) $3 million 0.01 = $30,000.
17
Insurance companies use the ALE to assist them in determining what kind of premium they should charge. For the risk management professional, this form of risk analysis is often misleading. The loss if a ood occurred is not $30,000, but actually $3,000,000. Among the problems associated with using the ALE method is not knowing where in the cycle the vulnerability is.
Risk Management Objectives

Risk analysis allows organizations to put into focus their information security objectives (see Exhibit 1.9). Over the years, nine objectives have emerged. Each of these objectives maps back to ensuring that the enterprise fullls its business objectives, mission statement, or charter. Although the nature of an operation will differ from others, these information security principles can serve as a guide in developing a risk analysis process that meets specic needs. An important factor in successfully implementing an effective information security quality assurance process is to implement a total risk management architecture. This architecture must be linked to the information security policies and standards and must address the risk of doing business in an automated environment on an ongoing basis. The single most important factor in the establishment of an effective quality assurance program is the unbiased support of senior management. The nine objectives are supported by ve risk management principles, which have been implemented by organizations that have been identied by the information security as having a leadership role. The principles are seen as the elements of the risk management cycle (see Exhibit 1.10). Actually, four are principles and one is the management element. In each successful implementation of an effective information security quality assurance process,
Exhibit 1.9 Information Security Objectives
1. Maintain customer, constituent, stockholder, or taxpayer condence in the organization. 2. Protect condentiality of sensitive information (personal, nancial, trade secret, etc.). 3. Protect sensitive operational data for inappropriate disclosure. 4. Avoid third-party liability for illegal or malicious acts committed with the organizations systems. 5. Ensure that organization computer, network, and data are not misused or wasted. 6. Avoid fraud. 7. Avoid expensive and disruptive incidents. 8. Comply with pertinent laws and regulations. 9. Avoid a hostile workplace atmosphere.
Source: GAO/AIMD 98-68.
18
Exhibit 1.10
Risk Management Cycle
there has been established a central management focal point that has been charged to: Establish an effective, easy-to-use risk analysis process. Facilitate the risk analysis process. Provide consulting support for information security-related questions. Keep management informed as to the status of safeguards and controls. The ability of enterprises to understand risks and the associated cost-benet trade-offs is the primary focus of an effective business-enabled security program. Security or risk analysis cannot be viewed as an end unto itself. To conduct a risk analysis to meet some audit requirement or regulatory commitment is a waste of precious resources. Controls that are identied and implemented must address specic business needs and risks. Understanding the business risks associated with information security is the starting point of the risk management or information quality assurance program. The other four phases of the Risk Management Cycle contain practices that support the effectiveness of the overall program. While specic programs may vary, the practices identied in the 1998 Government Accounting Ofce report GAO/AIMD-98-68 Information Security Management are fairly well-accepted industry practices. 1. Assess Risk and Determine Needs: a. Recognize information resources as an essential enterprise asset. b. Develop a practical risk analysis process that links controls to business needs.
19
c. Hold business managers accountable to protect the information resources. d. Manage risk on a continuing basis. 2. Implement Appropriate Policies and Related Controls: a. Link policies to business risks. b. Implement standards to support the policies. c. Distinguish between standards and guidelines. d. Make policy support a management review issue. 3. Promote Awareness: a. Continually educate users and others on the risks and related policies and controls. b. Report to management, on an annual basis, the state of businessrelated risks. 4. Monitor and Evaluate Policy and Control Effectiveness: a. Monitor factors that affect risk and indicate security effectiveness. b. Use results to direct future efforts and hold managers accountable. c. Be alert to new monitoring tools and techniques. Risk considerations and related cost-benet trade-offs are the primary focus of an effective risk analysis program. Security is not an end unto itself. It is the enabler for the business or mission of the enterprise. Controls and safeguards are judged effective in the way that they support the business process. Any control that impacts the ability to discharge the enterprises mission is of no value and should be removed.
Which Risk Analysis Process is Best?

There are as many different styles and types of risk analysis as there are enterprises trying to run them. In the Computer Security Institutes 2000 Buyers Guide, there are 26 different advertisements for risk analysis products, software, and consulting services. The organizations that are most satised with their risk analysis process are those that have dened a relatively simple process that can be adapted to various business units and involve a mix of individuals with knowledge of business operations and technical aspects of the systems or resources being analyzed. Whether the risk analysis process is automated or not, there are generally two major categories for risk analysis: quantitative and qualitative. Take a few minutes to examine the two major processes and identify the pros and cons for each.
Quantitive Risk Analysis

Quantitative risk analysis attempts to assign independently objective numeric values (e.g., monetary values) to the components of the risk analysis and to the level of potential losses. When all elements (asset value, threat frequency,
20
safeguard effectiveness, safeguard costs, uncertainty, and probability) are quantied, the process is considered to be fully quantitative. Quantitative Pros: The results are substantially based on independently objective processes and metrics. Great effort is put into asset value determination and risk mitigation. Cost/benet assessment effort is essential. The results can be expressed in management-specic language (e.g., monetary value, percentages, probabilities). Quantitative Cons: Calculations can be complex. Historically, it only works well with a recognized automated tool and associated knowledge base. It requires large amounts of preliminary work. It is generally not presented on a personal level. Participants cannot be easily coached through the process. It is difcult to change directions. Qualitative risk analysis does not attempt to assign numeric values to the risk analysis components. It relies on scenarios or in asking what if type questions. It is subjective in nature. Qualitative Pros: Calculations are simple (there are none). It is not necessary to determine the monetary value of assets. It is not necessary to quantify threat frequency. It is easier to involve non-security and non-technical staff. It provides exibility in process and reporting. Qualitative Cons: It is subjective in nature. Results rest solely with the quality of the risk management team assembled. Limited effort is required to develop monetary value for targeted assets There is no basis for the cost-benet analysis of risk mitigation.
Different Methods
Throughout the remainder of the book different risk analysis methods are discussed, but the primary focus is on qualitative risk analysis processes. Each section begins with an overview of the process, a step-by-step explanation of the process, and then examples of the completed process. Chapter 2 discusses
21
the theory of qualitative risk analysis and subsequent chapter build on that knowledge with working examples of how the theory has been put into practice. The review concludes with a detailed look at the most widely accepted and used risk analysis process the Facilitated Risk Analysis Process (FRAP).
Denitions
Risk: the probability that a particular threat will exploit a particular vulnerability. Risk analysis: the process of identifying assets and threats, prioritizing the threat vulnerability and identifying appropriate safeguards. Safeguard: protective measures implemented to ensure asset are available to meet business requirements. Threat: an event with the potential to cause unauthorized access, modication, disclosure or destruction of information resources, applications or systems. Vulnerability: a weakness in a system, application, infrastructure, control or design aw that can be exploited to violate system integrity.
Chapter 2
Qualitative Risk Analysis

Qualitative risk analysis is a technique that can be used to determine the level of protection required for applications, systems, facilities and other enterprise assets. It is a systematic examination of assets, threats, and vulnerabilities that establishes the probabilities of threats occurring, the cost of losses if they do occur, and the value of the safeguards or countermeasures designed to reduce the threats and vulnerabilities to an acceptable level. The qualitative methodology attempts only to prioritize the various risk elements in subjective terms.
Overview
Qualitative risk analysis provides for a systematic examination of the holy trinity of Assets Threats Vulnerabilities. It also provides for a review of proposed countermeasures and safeguards to determine the best cost-benet for implementation. By establishing a quality risk management team, this subjective analysis can rely on the expertise of the enterprises internal experts. The entire process is subjective in nature and therefore the team must be properly screened and populated with knowledgeable personnel. Qualitative risk analysis is a technique that can be used to determine the level of protection required for applications, systems, facilities, or other enterprise assets. During the systematic review of assets, threats, and vulnerabilities, the team will be able to establish the probabilities of threats occurring, the cost of losses if they do occur, and the value of the safeguards or countermeasures designed to reduce the threats and vulnerabilities to an acceptable level. The qualitative methodology attempts only to prioritize the various risk elements in subjective terms. The remainder of this chapter examines three qualitative risk analysis processes. The rst one is a ten-step Qualitative Risk Analysis (QRA). This will form the basis for all other examples of QRA. The second QRA provides
23
24
examples of how to include tangible and intangible aspects of asset evaluation. The third one is titled the 30-Minute Risk Analysis and it only takes three days to complete.
Qualitative Risk Analysis: The Theory

The rst method examined is a ten-step process that establishes the risk analysis process from project planning to the nal report. Each of the steps builds upon the previous step. In examining the two qualitative risk analysis processes, try to move beyond just a narrow interpretation of how each step in the process is used. One will see that by being able to explore other possibilities, the risk analysis process for an enterprise will be better able to evolve.
Step 1: Develop a Scope Statement

Every successful project begins with a denition of what is to be accomplished. For risk analysis, this involves describing what is to be examined. This could be a physical environment such as a data center; a specic system such as a VAX cluster supporting research and development; a processing entity such as the corporate WAN or a subsection of the network such as the payroll administration LAN; or a specic application such as accounts payable. In creating a statement of work or a scope statement, it is customary to begin with identifying the sponsor. This is normally the owner of the application, system, data, or process. The owner is typically described as the management person responsible for the protection of the asset in question. In most organizations, the sponsor is not an Information Systems (IS) person. To limit the possibility of scope creep, it is necessary to establish the boundaries on what is to be examined. An application that uses the corporate network to pass data is within the scope of a normal risk analysis. However, conducting a corporate analysis of the security of the Internet may be counterproductive. Keep the focus on those processes that the organization can effect change. The scope statement will next want to address the overall objectives of the analysis. For information security, these objectives are normally the impact of threats on the integrity, condentiality, and availability of information being processed by specic applications or systems. Consider the types of information security challenges facing the organization, and use this to dene the objectives. When conducting a risk analysis, it is necessary to state the concerns as to how they impact the business objectives or the mission of the organization, and not on how they impact security objectives. Proper controls are implemented because there is a strong business need, not so that the business unit will be in compliance with security requirements. Keep the business of the organization foremost in the discussions during the risk analysis process.
25
Step 2: Assemble a Competent Team

It is essential that properly qualied and competent personnel be selected to become members of the QRA team. Many information security professionals attempt to conduct the risk analysis either alone or just with other members of the security group. To be effective, the risk analysis process must have representatives from at least the following areas: functional owners system users systems analysis applications programming database administration auditing (if appropriate) physical security communication networks legal (if necessary) processing operations management systems programming (operating systems) information security The key members of this team are the owner and the users. Make certain that there is representation from every business unit affected by the asset under review. This will assist in the acceptance of the nal results or the analysis. By ensuring proper representation, the controls agreed upon will come from the owners and users, and not as an edict from security or audit.
Step 3: Identify Threats

Members of the QRA team determine which threats can cause harm to the asset under review. This can be done in a number of different ways. One way is to provide a list of threats and have the team members choose those that they feel apply to the current situation. This requires that the QRA lead have time to develop such a list and the proper denitions for each. While this may be time-consuming for the rst one or two risk analysis processes, once the list has been developed and eld-tested, it can be used for every risk analysis. However, there is a major drawback to this method; too often, the team members look only to the list for answers and do not offer additional ideas. To combat this possibility, the team can brainstorm ideas. One way of doing this is to have the team members use Post-it notes and write down all of their ideas and then post them for review by the team members. All duplicates will have to be combined and then the threats can be divided into categories. One may want the team to think of only integrity risks or threats rst and then go on to condentiality issues. Or one can have them identify natural hazards and then accidental and nally deliberate threats. The key in brainstorming is to get all of the ideas out and categorized.
26 Exhibit 2.1 Risk Factor Determination Sheet

Asset Under Review: Threats Threat Priority
Impact Priority
Risk Factor
Once all applicable threats have been identied, they are then entered into the Risk Factor Determination Sheet, as shown in Exhibit 2.1.
Step 4: Prioritize Threats

Once the threats have been entered onto the Risk Factor Determination Sheet, the QRA team will determine how often each of the identied threats is likely to occur. Because this is a qualitative risk analysis, the frequencies are expressed as low to high and can be given a numeric value by applying the assigned number as shown in Exhibit 2.2. Each team member determines where each threat ts into the Priority Table. It is necessary to establish what each category means so that the team members are working with the same denition of threat occurrence. The members can either do this task independently and then average the ndings, or each threat can be reviewed and consensus found one-by-one. Another way to express the threat occurrence rate is the probability of occurrence. This is very similar to the charts and gures discussed in Chapter 1.
Exhibit 2.2 Priority Table
Low to Low Medium to Medium
Medium 2
High 4
High
27
Exhibit 2.3. Threat Evaluation Total

Application Threats Threat Priority Loss Impact Risk Factor
Fire Water damage Theft Tornado
3 2 2 3
However, the difference here is not trying to nd an absolute numerical probability, but to rely more on the knowledge of the team. This is why the makeup of the team is very important. It is their experience that allows this process to move forward at a more rapid rate than if the QRA required stopping until each threat could be mathematically calculated. In qualitative risk analysis, the trade-off is for faster, pretty good results, rather than expending large amounts of resources trying to nd the perfect answer. Once the probability of occurrence has been determined, those gures are recorded in the Threat Priority column, as shown in Exhibit 2.3.
Step 5: Impact Priority

At this point, members of the QRA team are to estimate the loss impact if the threat were to occur. Step 4 was to determine the probability of the threat occurring; this step is to determine the impact to the asset under review if the specic threat were to occur. To make certain that the results are as complete as possible, the team members should review each threat as if there are no controls in place. Later steps allow the business unit to determine the effectiveness of the controls and how they will reduce the impact of the threat. The team then approaches each threat as they did in the previous step. Working either independently or as a group, the team computes the Risk Factor and enters that value into the proper place on the risk determination worksheet. If the team decides to work independently, it is then necessary to provide discussion time once the averages are calculated. If one team member ascribed a value at either end of the scale and the average comes out at the other end, then there should be some discussion to ensure consensus. The table shown in Exhibit 2.2 is used again in this step. The threat impact averages or consensus values are then entered into the Loss Impact column, as shown in Exhibit 2.4.
28 Exhibit 2.4 Loss Estimate Consensus

Application Threats Threat Priority
Loss Impact
Risk Factor
3 2 2 3
5 5 3 5
Step 6: Calculate Total Threat Impact

During this step, the team adds the Threat Priority gure and the Loss Impact value to achieve the Risk Factor for each identied threat, as shown in Exhibit 2.5. The risk factors will range from a low of 2 to a high of 10. After all of the risk factors have been calculated, the QRA team must sort the entire worksheet by the values in the Risk Factor column, in order of priority, from the highest value to the lowest value. Those with a risk factor of 6 or greater are then moved to the Safeguard Identication Worksheet. No enterprise has sufcient resources to examine all risks, regardless of their impact and probability. Therefore, it is necessary to determine which risk factors will be identied for further review. The value 6 requires any threat to have an impact and probability score of at least medium for each factor. It can have a Low and a High for a 6 or a Low-to-Medium and a
Exhibit 2.5 Risk Factor
Application Threats Threat Priority Loss Impact Risk Factor
3 2 2 3
5 5 3 5
8 7 5 8
29
Exhibit 2.6 Safeguard Identication Worksheet

Application Threats Risk Factor Possible Safeguards Safeguard Cost
Fire Tornado Water damage Theft
8 8 7 5
Medium-to-High for a 6; in each case, the threat must be placed in the middle or to the right on the concern scale (see Exhibit 2.6).
Step 7: Identify Safeguards

In this step, the QRA team analyzes the identied weaknesses and searches for technical, administrative, and physical controls that offer a cost-effective, acceptable level of protection to the asset under review. The model for information protection objectives has been established as consisting of four layers: avoidance, assurance, detection, and recovery. The team should concentrate on controls that allow the mission of the enterprise to function while providing an adequate level of protection. It may be prudent to establish a list of possible controls in each of the layers that will help the enterprise meet its business objectives. 1. Avoidance controls are proactive safeguards that attempt to minimize the risk of accidental or intentional intrusions. 2. Assurance controls are tools and strategies employed to ensure the ongoing effectiveness of the existing controls and safeguards. 3. Detection controls are techniques and programs used to ensure early detection, interception, and response of security breaches. 4. Recovery controls are planning and response services to rapidly restore a secure environment and investigate the source of the breaches. Examples of controls and safeguards for each of the security layers include the following: 1. Avoidance a. encryption and authentication b. system security architecture
30
c. facilitated risk analysis process d. Information awareness program e. Information security program f. Interruption prevention g. Policies and standards h. Public key infrastructure i. Secure application architecture j. Secure communications plans 2. Assurance a. application security review b. standards testing c. penetration testing d. periodic perimeter scans e. vulnerability assessment 3. Detection a. intrusion detection b. remote intrusion monitoring 4. Recovery a. business continuity planning b. business impact analysis c. crisis management planning d. disaster recovery planning e. incident response procedures f. investigation tools In addition to the controls discussed above, some threats might require a physical safeguard or some combination of the controls. The team should consider additional safeguards and countermeasures and determine the cost for implementing and maintaining the proposed controls. The team then enters its recommended safeguard and its associated cost in the Possible Safeguards and Safeguards Cost columns of the Safeguard Identication Worksheet (Exhibit 2.7). It may be benecial to list all safeguards considered and rank them according to the teams recommendation (see Exhibit 2.7). This allows management to see what was considered and then to see what the QRA team is recommending as the proper safeguard. It is also possible that one safeguard may reduce the risk exposure of more than one threat, thus increasing its cost-effectiveness.
Step 8: Cost-Benet Analysis

This is probably the most important step of any risk analysis process. Every control will cost something to the enterprise. The cost might be money to purchase and install the control. It might be human resources to develop and implement controls such as policies and standards, or it might be as simple as turning on an audit trail. In each incident, the way the enterprise does
31
Exhibit 2.7 Completed Safeguard Identication Worksheet

Application Threats Risk Factor Possible Safeguards Safeguard Cost
Fire Tornado Water damage Theft
8 8 7 5
Fire suppression system Business continuity plan Business continuity plan
$15,000 $75,000 $75,000
business will be altered. Another way to look at this is that the culture of the organization will be changed. In examining other forms of risk analysis, one will be shown a number of ways to do a cost-benet analysis. During Step 8, the analysis should be very thorough to ensure that the safeguards recommended for implementation meet the business objectives and provide an adequate level of asset protection. Because one is using qualitative risk analysis, it may be necessary to conduct Step 6 again. That is, review the impact of the threat with the proposed control in place. There should be a signicant reduction impact value before the control is accepted. The analysis process should identify those safeguards that offer the maximum amount of protection at a minimum cost. In other words, it is always best to implement controls that will affect more than one threat. This is known as getting more bang for the buck. As discussed in Chapter 5 for the Facilitated Risk Analysis Process (FRAP), one of the most important report forms sent to the client is a cross-reference listing of each identied control and all of the threats that this control would help alleviate.
Step 9: Rank Safeguards in Priority Order

Once the cost-benet analysis has been performed, the QRA team should list them in order of priority for selection by the asset owner. Because resources are limited, management relies on the team to provide them with adequate information. The team needs to determine how the priority order will be presented. It may choose how many threats a safeguard can control. Or it may choose a dollar level, or an impact on productivity, or whether the safeguard can be developed internally, or if it will require third-party assistance.
32
The key to developing the priority list is to determine what works best within a particular enterprise and then working to meet those objectives. The location of the priority listing will become part of the Risk Analysis Report and should be referenced in the Executive Overview section of the report. There should be a discussion on how the team arrived at its priority ranking. Include enough detail to ensure that management can make an informed decision. The team must understand that management may decide to accept the risk. The process of risk analysis is to ensure that management has performed its due diligence. As part of this process, management needs to have a documented cost-benet analysis to ensure that it has the information required to make these business decisions.
Step 10: Risk Analysis Report

The results of the risk analysis process must be presented to management in the form of a report. The report serves two purposes: to report the ndings and to serve as a historical document. Once completed, the risk analysis process allows management to implement control and safeguards that it deems to be sufcient to meet the enterprises business objectives. This is the overriding reason that organizations implement risk analysis as part of the Analysis Phase of a Project Development Methodology or the System Development Life Cycle. However, it is the historical element of the risk analysis process that is often the most important. Having a well-documented approach to decisionmaking and having a library of reports that chronicles this process provides management with the support it needs to show that it has lived up to its duciary responsibility to protect the assets of the enterprise. For many organizations, the only time the Risk Analysis Report will ever see the light of day is when some third party is attempting to determine how decisions were made. By issuing a report that contains, at a minimum, the elements discussed in this section, the enterprise will have documentation to defend its position. A sample table of contents the Risk Analysis Report might include the following: 1. Introduction: a. Background: This should detail why the risk analysis process was undertaken, the business reasons leading to commit resources to complete the QRA. b. Assess the Scope Statement: Include the actual scope statement and explain how it was determined that this would be the project or asset to be reviewed. A review of how the QRA met the deliverables identied in the scope statement is also part of this discussion. If any elements were not completed or dropped from the original scope, an explanation should also be included.
33
2.
3.
4.
5.
6.
7.
8.
c. Explanation of approach: Chronicle the approach used as the QRA process. Include a brief outline of the steps and the expected deliverables from each step. Executive Overview: In one or two pages, discuss the entire process and ndings. Include as part of this overview a reference to the Appendix that lists the team members. Make certain that the executive overview clearly states the ndings of the QRA team, and the risk analysis process in particular. Threat Identication: Discuss the process used to identify threats, issues, concerns, risks, etc. Also include how the threats were categorized. This would include a review of the categories identied by the QRA team as the ones to be used in the review and how this was determined. Typically, for an information security risk analysis, the categories are availability, condentiality, and integrity. Be sure to include all denitions. This is important for all threats as well as categories. As a historical document, it is necessary to include a clear picture of the teams thinking or state of mind at the time of the review. Risk Factor Determination: During this phase, the QRA team determined the probability that a specic threat might occur and then its impact on the enterprise if it did occur. In the report, identify the denition of probability or vulnerability and impact. Discuss the process used and how the Risk Determination Factors were established. While the team strives for consensus, sometimes it cannot be reached. This would be the place to put any discussion on threat priority disagreement. Safeguard Identication: It is necessary to be very thorough in discussing how the team determined what safeguards were available and how the recommendation was reached. Management will want to know who was contacted to determine what was available. The who would include any benchmarking that was conducted. One of the ways to sell a recommendation to management is to tell them what others in the industry are doing. Include information on any research that was conducted with groups such as the Gartner Group, Meta, Giga, or other industry advisor organizations. Cost-Benet Analysis: Managements acceptance of the ndings and recommendations depends on how well the QRA teams cost-benet analysis is understood. It is important, then, to ensure that the report identies the process used and how it takes into consideration the business objectives of the enterprise. Safeguard Recommendations: The nal, and probably most important, element is the QRA teams recommendations. The recommendations can include the control to be implemented, the control alternative, or whether to accept the risk as the most benecial course of action. Appendix: There are a number of items that need to be recorded as part of the historical documents that support the risk analysis. Recommended appendices include:
34
a. team members b. denitions c. threats by priority order d. research reports The Risk Analysis Report is a condential document and its access should be restricted to a limited group determined by the owner of the asset under review. Although there may be a team that conducted the risk analysis process, the report belongs to the sponsoring manager.
Conclusion
Qualitative risk analysis is among the easiest methodologies to perform; it is also the most subjective. The quality of the risk analysis results produced are in direct correlation to the professionalism and knowledge of the QRA team assembled and the objectivity of the process facilitator. The results achieved by a professionally led team, utilizing this form of methodology, is as valid as those realized through the utilization of more labor-intensive and timeconsuming quantitative processes.
Qualitative Risk Analysis: Another Approach

The second QRA process examined herein was presented by Gareth Davies at a Southeast Michigan Computer Security Special Interest Group meeting in 1991 in the Detroit area. This process takes the standard ideas seen in the rst process and then turns it ever so slightly to create a modied approach. This version was designed to overcome identied shortcomings in traditional risk analysis. In particular, these developers needed to address less tangible risks. They could see where a value of loss for a physical asset could be found; their problem was in developing a common methodology that would address such assets as reputation, customer condence, or positive press. This method uses a scoring system to enable nancial risks to be compared to non-nancial risks. This process allows the QRA team to take secondary impacts into consideration. Instead of ten steps, this process uses three stages (Asset Valuation, Risk Evaluation, and Risk Management) that map fairly well to the initial process we just reviewed. As the different risk analysis processes are reviewed, it is necessary to remember that each methodology begins with the same two processes: identify the asset and assemble the team. As part of the initial scope statement phase, it is necessary to identify the functional owner of the asset. This individual or group of individuals acts on behalf of the enterprise to manage the asset and make the decisions necessary to ensure the asset is properly protected for unauthorized use, access, disclosure or destruction. The functional owner is normally identied as the senior
35
management individual within the business unit or department where the asset is created or is the primary user of the asset. Where an asset is shared across a number of departments, it is recommended that those departments determine who will act as their spokesperson. Most enterprises that employ this form of decision-making process rotate the responsibility annually. That way, the needs of the many are properly weighed against the needs of the few. In addition to what asset is to be reviewed, it is necessary to determine what business or control impacts will be assessed. That is, whether the risk analysis will examine threats to availability, condentiality, and integrity, or impacts to disclosure, modication, unavailability, or destruction. The risk analysis can be used to investigate any element of the business process or mission of the enterprise. It is during the scope statement deliverables that these questions need to be answered. It is necessary for the risk analysis facilitator and the functional owner to agree on the denitions of each of these elements. Additionally, it is necessary to agree on the denition of vulnerability and impact. It is the functional owner who sponsors the risk analysis, provides the resources for the effort, decides the safeguards that are to be implemented, and keeps control of the QRA report. Asset identication takes on a number of different approaches, but they all lead to the same result. The asset to be reviewed has been identied and a project scope statement has been drafted. As discussed in the previous example, the scope statement is the most important element of the risk analysis process. It ensures that the specic asset is properly identied and that all team members have a clear understanding of what is to be reviewed. The other consistent process in every methodology is the assembly of the QRA team. It is necessary to ensure that a good representation of a cross-section of the business enterprise be part of the team. As discussed above, the important members are the asset owner and the users of the asset. It is strongly recommended that the QRA team be made up of personnel that have been with the enterprise long enough to know how things work and where there might be problems. It is not necessary to have a specic level of employee; what is important is that the employee has sufcient knowledge to provide insight into how things can go wrong and what needs to be done to correct them. Once the scope statement is nalized and the denitions agreed upon, it will be time to assemble the team. Each of the stages of this qualitative risk analysis process are now examined.
Stage 1: Asset Valuation

After the initial steps have been completed and the QRA team has been assembled, the rst task is to determine what the impact would be to the enterprise if the asset is compromised. In this example, this QRA uses a series of tables to help the team identify the impact of various threats.
36 Exhibit 2.8
Financial Loss
Financial Loss Table

Valuation Score
Less than $2,000 Between $2K and $15K Between $15K and $40K Between $40K and $100K Between $100K and $300K Between $300K and $1M Between $1M and $3M Between $3M and $10M Between $10M and $30M Over $30M
1 2 3 4 5 6 7 8 9 10
The values found in the tables are the result of meetings with various departments and business units and getting their expert input into what would constitute a level of loss for the enterprise. For example, Exhibit 2.8 displays a Financial Loss Table and the values here represent what the nancial staff indicate are levels of concern. When meeting with support staff, try to get the low value and the high value. For the low end, one might do this by asking at what level of loss or impact would the enterprise feel the need to make some form of correction. At the other end of the table, one will want to capture the value of when the enterprise would be in very serious trouble. Once the two ends are met, then one can work to develop the number of gradations needed to meet specic objectives. As you can see, this table has ten values. That may be too ne a gradation for a particular enterprise; this author recommends trying to limit the number of possibilities while still capturing the necessary information. The more choices available to the team members, the greater the possibility for confusion. In the QRA process, the team will be asked to assign a value to specic categories based on tables developed through discussions with the departments responsible for those activities. The process reviewed in this chapter is only an example of what can be done. The tables can be modied (as seen in the discussion on business impact analysis) and the elements to be reviewed can also be modied to meet specic needs. Using a matrix such as the one shown in Exhibit 2.9, the team enters its scores. As in the discussion above, the team can either discuss each entry and then reach consensus before entering a score, or the process can allow for individual scores that are then averaged. If the latter is used, it is necessary to provide time for discussion to reach a nal consensus. In Exhibit 2.9, the QRA team chose again to identify loss in dollar values. The numbers could have been represented in lost production time, lost sales volume, lost transactions, or any other set of identiers (see Exhibits 2.10, 2.11, and 2.12). It will be necessary to work with the distribution or delivery departments for the goods or services that the enterprise delivers. Every enterprise delivers some product; thus, the team must identify that product and work with the .appropriate departments to ascribe values for loss or impact.
37
Exhibit 2.9 Sample QRA Worksheet

Value asset groups in terms of the impact on business operations for breaches of availability, condentiality, and integrity
User Disruption
Disclosure
Modication
Unavailability
Destruction
Exhibit 2.10
Under $5K
Extent of Legal Implication Table

Valuation Score
Extent of Legal Implication
1 4 5 8 10
Between $5K and $10K Between $10K and $50K Between $50K and $1M and/or CIO liable for prosecution Over $1M and/or Ofcers and/or Directors liable
Exhibit 2.11 Value to Competitor Table

Value to Competitor Valuation Score
Less than $50,000 Between $50K and $100K Between $100K and $10M Over $10M
1 4 5 7
Embarrassment
Condentiality
Financial Loss
Legal Impacts
38 Exhibit 2.12
Enterprise Embarrassment Table

Valuation Score
Enterprise Embarrassment
Embarrassment restricted to within the project or work site Embarrassment spread to other work areas of operating group or division Embarrassment spread throughout the enterprise Public made aware through local press coverage Adverse national press Stock price impacted
1 2 3 5 7 10
Using the tables developed by the team with assistance from the various supporting units, the QRA team completes the worksheet to determine a value for the asset under review. The key in this process is to identify any assets where compromise would cause a value of X. It is the responsibility of the QRA team and management to identify exactly the value of X; in most instances, it will be a threshold that causes management to wince. Once these assets have been properly valued, the team presents its ndings to the sponsoring entity. This acts as a checkpoint that the process is functioning as it is intended to and that management is ready to authorize Stage 2 of this QRA.
Stage 2: Risk Evaluation

During the Risk Evaluation stage, the QRA team establishes threats that may impact the assets and then assesses vulnerabilities to the threats. As discussed in Chapter 1, the identication of threats can be done any number of ways. The key is to create a list of as many threats, concerns, issues, threats, etc. as possible. Trying to develop a complete list is the important task in this stage of the QRA. Once the list of threats is complete, the QRA team rates the threat according to the probability of occurrence and the impact the threat would cause to the asset or to the mission of the enterprise. As discussed in the previous section, one must establish clear denitions of: exactly what each threat is what probability of occurrence means what the impact to the asset or mission means In this QRA example, the team uses the worksheet shown in Exhibit 2.13 to assign the appropriate Vulnerability Score. The team can either discuss
39 Threat Vulnerability Work Table

Impact Low High Medium High
Exhibit 2.13
Probability
Medium
Low
each threat individually and then determine the specic score, or it can have the members score each threat and then average the results. In the latter case, there must be enough time for the members to discuss discrepancies in individual scoring. If a threat is not applicable to the asset under review, then the team enters a value of N/A on the Vulnerability Worksheet (Exhibit 2.14), as opposed to assigning a value of 1. The scores from the asset valuation process allow the team to identify those assets that could cause an impact to the enterprise mission if they were compromised. Because most organizations do not have unlimited resources, this process allows the QRA team to concentrate its efforts on those assets that have real impact. It is usually best to examine the threat without regard to existing controls and then perform a second review taking into consideration existing controls. When performing the second process, it is necessary to identify the control that will counter the threat. This is usually done by identifying the threat: Fire; and then the control: Fire re suppression system. This total is then entered into the last column of the Vulnerability Analysis Worksheet (i.e., With Control ). Once those assets have been identied, the threat evaluation process allows the team to identify threats to those assets and then determine the vulnerability the enterprise has to those threats. These two stages lead to the nal process, the identication of controls that can be implemented to lower the vulnerability to the threat to a management acceptable level.
Stage 3: Risk Management

The most important element of any risk analysis process is the recommendations of controls and safeguards that will help mitigate the threat or vulnerability
40 Exhibit 2.14 Vulnerability Analysis Worksheet
Scores Unavailability Modication Destruction
Disclosure
Vulnerability Score Without Control With Control
Asset Under Review: Threats:
level to the asset under review. Using the totals from Stage 1, the QRA team has identied those assets that are important to the enterprise. With the scores from Stage 2, the team has identied the threats that expose the enterprise and its assets to an unacceptable level of concern. As in the rst process discussed in this chapter, the team is charged with making recommendations to the sponsor. The team will document existing countermeasures and map the Vulnerability Analysis results to what the level of exposure is with the safeguards in place. Once that has been completed, the team then concentrates on those threats for which there are no existing countermeasures identied. It is here that management will want the QRA team to provide leadership and recommendations. Countermeasures must be shown to provide a cost-effective level of control and still allow the enterprise to meet its mission or business objectives. The countermeasures can act in one of four ways: 1. 2. 3. 4. reduce the likelihood that the threat will occur reduce the impact if the threat were to occur detect the threat if it does occur provide the means to recover if the threat were to occur
41
The QRA team must recommend to management which countermeasures appear to be most effective and which ones can control more than one threat. Once the report is complete, the team documents the results and obtains nal sponsor signoff. This normally completes the risk analysis process, but there are two more activities that make the process even more complete. The report normally identies the individual or department responsible for implementation of the countermeasure. Included in this identication process is the expected implementation date. There should be steps taken to ensure that some level of follow-up is conducted to ensure that the countermeasures are being implemented in a timely manner. The review of the implementation process is normally conducted by the Audit Staff. The nal element of an effective risk analysis process is scheduling the next review of the asset. Nothing within an enterprise remains constant, so it is necessary to schedule a follow-up QRA. This process should be scheduled every 18 months to two years. Using the initial QRA as a baseline, the enterprise will be able to mark its improvement of protecting assets.
The 30-Minute Risk Analysis

In July 1992, the Computer Security Institute Alert published an article on Dan Erwins interesting twist on qualitative risk analysis under review. Dan has determined that it is the role of the security specialist and project leads to be the facilitators of the risk analysis process. The process of Information Security Risk Analysis (ISRA) is a difcult concept for the layperson to grasp. To ensure that the ISRA process is completed in a timely and efcient manner requires a trained facilitator.
ISRA Overview
The ISRA is a formal methodology that is used by a designer, manager, or security analyst to help identify security needs, develop action plans, analyze costs, and assign responsibilities. The process allows a facilitator to perform a subjective risk analysis on a specic system, application, or other corporate asset. The ISRA involves system users from the very beginning, by requiring them to voice their concerns and to choose effective controls. The ISRA should be part of the system development life cycle feasibility phase and cost-benet studies of new systems. It can also be used on existing systems prior to major updates, during periods of change, or as required by management.
ISRA Objectives
As with most security-related process from the mid-1970s on, the ISRA is used to identify undesirable or unauthorized events, concerns, risks, threats, etc.,
42
not in terms of their effect on information security, but in terms of their effect on the business process or mission of the enterprise. The function of information security can be dened by three objectives: 1. Data integrity: the prevention of unauthorized or undesirable modication or destruction of data/information and source code 2. Data sensitivity: the prevention of unauthorized or undesirable disclosure of information 3. Data availability: the prevention of the loss of accessibility of data or system services Many controls will be effective in meeting all three objectives. However, some controls are specic to one objective and may even be detrimental to the other objectives. The Risk Analysis Matrix will help the user, designer, or security specialist choose the most appropriate and cost-effective controls. When using the ISRA process, it is also useful to analyze what risks are being protected from: Accidental acts: undesirable acts (errors and omissions) Deliberate acts: unauthorized acts (fraud and misuse)
The Risk Analysis Matrix

Combine the three security objectives and the two security risks to form a matrix (Exhibit 2.15). This matrix can then be used to facilitate a discussion that will lead to the identication of the risks. Controls can then be identied based on the risks. Care must be taken not to dene controls until the risks have been identied. This will ensure that only risk-based controls are applied.
Exhibit 2.15 Risk Analysis Matrix
Data Integrity Accidental Acts Sensitivity Availability Undesirable Event (error & omission) Unauthorized Event (fraud & misuse) Modication or Destruction of Information Disclosure of Information Unavailability of Information or Services
Deliberate Acts
43
The Process
To perform a risk analysis, the facilitator assembles experts on all elements of the system/opportunity being analyzed. For example, if the project required the company to install a LAN in a sales ofce, then the risk analysis team must involve someone from the sales staff, someone from clerical, the functional management team, a LAN technical expert, a hardware or software support person, and someone from information security. The facilitator doing the risk analysis need not be an expert in the system being studied. Their role in this process to pose questions, provide background information, and gently nudge those present to participate. It is important for the facilitator to appear to remain neutral at all times. As discussed in the other qualitative risk analysis processes, the team is most important. Choosing the right people is critical to the success of the process. If the right people are in the room, they will know what the risks are and what controls are acceptable. Because this is a subjective risk analysis, the answers derived from the process are only as good as the people who gave them. A brainstorming technique is used to prompt the participants to identify risks using the matrix. The matrix is posted on ipcharts, and then each box is dealt with one at a time. The participants are asked to identify risks to their data based on the opportunity being studied. For example, if the opportunity being studied is: much of the data processed by this system is being moved from a mainframe to a client/server-based application. What are the risks associated with this change? Box-by-box, this opportunity is reviewed and the risks listed. Each attendee is asked to come up with three things that could cause their data to be modied or destroyed accidentally, because of the change to the system that is being studied. The risks are then written on a ipchart for the participants to view. The process is repeated for the other headings until the matrix is lled. When all six categories have been reviewed, the team reviews the lists, makes any modications or enhancements, and then performs a reality check. This list of risks is then used to identify the controls required (see Exhibit 2.16).
Risk-Based Controls
Once the risks are fully identied, the team can select controls (safeguards, standards, rules, etc.) that best protect against the specic risk. By using this method, there is almost always a choice of controls. This means the client can choose the control that best suits their way of doing business and personal preference. Once the controls that suit the business needs are identied, a cost-benet analysis is performed to help choose the most cost-effective controls (see Exhibit 2.17). In most cases, there is no need to quantify the cost of the risk only the cost of the various controls. For example, if the risk is that someone might steal a computer, the controls list might include
44 Exhibit 2.16
Completed Risk Analysis Matrix (with Sample Risks)

Data Integrity Sensitivity Availability
Accidental Acts
Enter incorrect data Modify incorrect elds Repeat entry of data
Fail to log-off after usage Route output to incorrect printer Send message to wrong person Access without authorization Disclose without authorization Copy without authorization
Disclosure of Information
Media destroyed by accident Flood, re Telecommunications outage
Undesirable Event (error & omission)
Deliberate Acts
Enter, use, or produce false reports Modify, replace, or reorder data Misrepresent information
Modication or Destruction of Information
Destroy, damage, or contaminate data Denial-ofservice attack Sabotage

Unavailability of Information or Services
Unauthorized Event (fraud & misuse)
Exhibit 2.17
After: Matrix with Suggested Solutions

Data Integrity Sensitivity Availability
Accidental Acts
Edit checking Desk checking Checks and balances Passwords Sign on (unique userID) Audit trails
Access control Segregation of duties Physical security Passwords Sign on Waste disposal Storage procedures ACLs
Disclosure of Information
Backup System design Redundancies
Undesirable Event (error & omission)
Deliberate Acts
Offsite storage Disaster plan Physical security Emergency procedures

Unavailability of Information or Services
Unauthorized Event (fraud & misuse)
Modication or Destruction of Information
45
an armed guard, a big dog, a surveillance camera, a locked door, or a list of replacement suppliers. Most team members and the client know the basic value of the risk without doing a lot of calculations to determine that a guard dog in the computer room may not be the answer. The question is then which of the other choices work best and which can the enterprise afford. A control must be implemented to eliminate or lower to an acceptable level each identied risk. It should be noted that one control can often impact a number of risks. There are often a couple of controls that will affect the same risk; in such an instance, list all the controls. The team should not be limited in any way as to the controls that they can select. Technology-based controls are no better than non-technology-based controls. The decision of which control is based on what best suits the clients needs and culture. This approach forces the team into a cost-benet mode and ensures that a $2000 solution is not being applied to a $5 problem.
Documentation
When the session is complete, a document is drawn up detailing the results of the process and stating the conclusions and action plan. The document should include the following topics: Description of opportunity: Describe change and its effect on security (Move data from mainframe to client/server). Risk analysis process: Describe specic risk to enterprise information assets, including: data integrity data sensitivity data availability Describe the control elements required. Describe controls that will be put in place: What, Who, When. Describe out-of-control processes: those risks where the most costeffective control is to accept the risk or where there is no current control available.
Out-of-Control Process
The risk analysis process cannot solve all the problems. The risks one cannot control or cannot afford to control must be documented for management review and endorsement. These out-of-control processes are then taken to management for action. Security ofcers must be willing to accept managements decision to accept controls that present an acceptable level of control.
46
Final Notes
Trade-offs must sometimes be made between business objectives and security. These trade-offs need not always be resolved in favor of security, but only management can accept risk. Accidents, errors, and omissions account for more losses than deliberate acts. Nearly 65 percent of information losses are caused by accidents. Of all problems and risks, 70 percent of the attacks come from internal sources. Therefore, controls that reduce the potential for harmful effects from accidents are also a rst step toward reducing the opportunities for fraud and misuse. Security against deliberate acts can only be achieved if a potential perpetrator believes these is a denite probability of being detected.
Conclusion
Qualitative risk analysis is a process that allows enterprises to evaluate tangible and intangible exposures to the assets of the organization. It provides for a logical and consistent method to review threats and their impacts to the assets under review. The two methods reviewed in this chapter are the building blocks that will be used to review other methods in the following chapters. Chapter 3 examines three different forms of qualitative risk analysis. Each one will provide the tools needed to modify the methods presented to make a custom process for a particular enterprise. Chapter 4 discusses the most widely used QRA the Facilitated Risk Analysis Process (FRAP). Finally, Chapter 5 examines ways to use the processes to do pre-screening of assets and business impact analysis.
Chapter 3
Value Analysis
The rst step in any risk analysis methodology is to determine what an asset is to the organization. An asset can be anything that is physical (such as a building, a computer, etc.), logical (such as data or an application, etc.), or it can be an intangible (such as your public image). Any organization asset must be of some value or it should be scrapped or never created in the rst place. A key question to ask during an information systems risk analysis process is: what is it worth to the enterprise to continue to run the current application or system?
Properties of Information Security Value Analysis

For the computer and information security professional, value analysis should focus on three properties: 1. Integrity: information is as intended, without unauthorized or undesirable modication or corruption 2. Condentiality: information has not undergone unauthorized or undesirable disclosure 3. Availability: the availability of an application or system, and its information, is protected To be effective, a general rule for setting a value on an asset is that the dened owner of the asset must be the one to assign the value. For many organizations, the dening of an owner will be a difcult task. There are, however, some general guideline that will assist in determining who would meet this responsibility. Typically, the owner is the senior-level person who has been assigned to exercise the organizations proprietary rights and duciary responsibilities for the asset in question.
47
48
Proprietary rights: pertaining to property ownership and the various rights related to ownership (i.e., possession, control, use, etc.) Fiduciary responsibility: pertaining to the legal relationship that gives rise to a duty of one to act on the behalf of another with the highest standard of trust, good faith (i.e., to act in the others best interest rather than ones own best interest). There will be a need to establish two additional employee responsibility classications. For most organizations, these classications are: Custodian: the employee charged with the responsibility of protecting the asset in accordance with the owners specic directions User: the individual or organization that has been authorized to use access the asset by the owner.
Purpose of Assigning Value to Assets

One is not trying to get an exact value for an asset; in fact, it is often sufcient just to know that one asset is worth more than another. There are probably thousands of ways to ascribe a value to an asset. The purpose of value analysis is to rank assets and to get a reasonable idea about which assets require some investment to protect them. The ultimate result of all of this work is to make sure that appropriate effort is invested to protect a specic asset, but not so much that the cost of protection or analysis exceeds the value of the asset.
Why Value Assets?

The overall purpose of risk analysis is to identify exposures and the value of the asset that may be at risk. By attempting to identify those systems, applications, and services that have value to the organization, it will be possible to identify and implement control processes that will reduce the risk of exposure. The value analysis process allows organizations to use a methodology to rank assets, identify control measures, and allow management to make an informed business decision on what should be implemented. When attempting to establish the value of an asset, it is often prudent to use local currency as the basic measure. The reasons for this are simple: It is easy to understand. It is more likely to be valued correctly. Because the organizations bottom line is measured in currency, employees and management are most likely to accept the results. One of the problems in attempting to assign a value to an asset is that, too often, the value is subjective. Rather than spend time attempting to develop
Value Analysis
49 Exhibit 3.1 Value Analysis Base 10 Scale

Value in Dollars Scale Value
1 or less Up to 10 1,000 10,000 100,000 1,000,000 10,000,000 100,000,000 1,000,000,000
0 2 3 4 5 6 7 8 9
an elaborate system to determine nite values, it may be practical to create a value scale (see Exhibit 3.1). By assigning a scale value to a specic asset, the relative ranking of assets can be established. Using the Base 10 Scale, the number of relative value for an asset is assigned based on an order of magnitude. If an asset has a value between $10,000 and $100,000, it will be assigned a relative ranking value of 5. If more precision is needed, then other scale values can be created. Scales like this can be used in two ways: Employees can be asked to estimate a loss between $500 and $1000, or whatever the interval of interest. Or, the table can be used by employees to rank exposures relative to a known exposure: if they ranked event B as about 100 times worse than event A. The main disadvantage in using a scale to get a relative ranking is that senior management is normally conditioned to think in monetary terms. The scale value may not have the same impact as actual monetary values. This form of analysis allows the ranking of assets relative to one another. For many organizations, monetary values are best because they allow comparisons and also because management is more comfortable with them. If it is expensive or impractical to get exact amounts, then a scale method may be one way to assist in converting guesses to subjective values.
Generally Accepted Accounting Principles (GAAP)

A very old and accepted method of establishing the value of an asset is to use accounting standards. This process is performed in three steps:
50
1. Locate the book (purchase) value of an asset. 2. Determine the accumulated depreciation. 3. Then, adding the two values The cost of a new workstation is $4000 The typical depreciation cycle is three years The formula is: B(purchase price) + ( D) (depreciation) = V (current value) Exhibit 3.2 shows the book value for a workstation that was purchased two years ago.
Exhibit 3.2 Risk Factor Determination Sheet
Purchase Value Depreciation Factor Current Value
$4000.00
$1333.33 per year
$1334.00
For accountants, this method may make sense. However, for information security professionals, this method may not lead to the true value of an asset. One will want to include upgrades and enhancements. The book value of an asset is only the rst factor in the risk analysis process. The second step is to determine what value has been added to the asset to nd its approximate current true value. By including the intrinsic value, a clearer picture of the total investment or value of the asset is gained. The intrinsic elements of an asset might include software upgrades, enhancements, customizations, and data. For these values it may only be possible to estimate the reinstallation costs or redevelopment costs. Part of a risk analysis process will show the need for backups of not only the data, but also for the programs and systems.
Paralysis By Analysis
The process of analysis can become bogged down by the inclusion of too much detail. One must be able to nd a happy medium between too little information and too much information. This is not easy. By its very nature, analysis will generate huge quantities of information. When attempting to determine the value of an asset, try to keep the objective in mind.
Conclusion
Protecting the assets of an organization will require some level of cost, either in actual budget dollars or employee resources. When considering the implementation of controls, it will be necessary to balance the cost of the control
Value Analysis
51
against the risk of doing without the asset. Risk analysis is a process used to estimate the potential effects that may result from system or application vulnerabilities and to assess the damage that may result if certain threats occur. The goal of value analysis is to attempt to nd the true value of an asset by taking into account the intangible or intrinsic elements that affect the ultimate value of an asset. A simple diskette may have a replacement value of a dollar or less. However, the information contained on that diskette could signicantly increase the intrinsic value. The ultimate goal of risk analysis is to implement cost-effective controls that will reduce risks to an acceptable level. Before any controls can even be identied, it is necessary to nd the value of an asset to the organization. Using a formal methodology, and understanding all the elements that go into making an asset what it is, allow one to meet computer and information security goals in an efcient and timely manner.
Chapter 4
Other Qualitative Methods

To date, no one risk analysis technique has been created that will satisfy the needs of every enterprise. This chapter reviews a number of risk analysis techniques, which, combined with the material presented thus far, provides a number of alternatives from which to choose. Thus, to reinforce the risk analysis process, this chapter examines variations on the theme established in Chapter 1. By examining the different methods and processes, the reader will be able to blend his or her own special risk analysis process. Chapter 5 examines the Facilitated Risk Analysis Process (FRAP) and Chapter 6 discusses variations on the FRAP theme. This chapter examines ve different risk analysis processes: 1. 2. 3. 4. 5. vulnerability analysis hazard impact analysis threat analysis questionnaires single-time loss algorithm
Vulnerability Analysis
This form of risk analysis was presented to the computer security community by Donn Parker and is a process that analyzes the vulnerabilities of a department with respect to the people who work there. The process examines the jobs involved, the skills required to perform those jobs, the current working conditions, and the adequacy of controls. A vulnerability analysis is normally conducted to see the current level of conditions, and then six to nine months later to determine how the new controls are working. To begin the process, rst identify the occupations or job classications being used within the target area. The target area can be as small as
53
54
a workgroup or as large as a division or business unit. The process works best if copies of the job descriptions and a current organization chart are available. Review all of the tasks being done and link them to specic job classications. The second step is to nalize the scope of the review. It could be the effects of certain job classication levels on controlling access to sensitive information, or the security of a specic LAN on the corporate network or a specic application. There are two main points to understand when discussing scope and vulnerability analysis. First, it is vitally important to properly describe exactly what is being reviewed. As discussed in previous chapters, the key to a successful risk analysis is to have the scope statement correct. Second, the only restriction placed on what can be reviewed is ones imagination or enterprise needs. Take a minute or two to examine what topics might be a subject for a vulnerability review. As discussed above, the risk analysis could examine the effects of specic jobs on sensitive information. Thus, the scope statement might be Review of Human Resources department handling of condential information. To be successful in this review, one must have the denition of condential information accessible to the vulnerability analysis team. It is then necessary to identify the various job titles within the Human Resources department. These might include the following: vice president of Human Resources senior managers line managers (supervisors) senior specialists specialists recruiters diversity team lead ofce administrators contractors custodial staff vendors information systems support Once all of the job titles have been established, it is necessary to have their job descriptions available to ensure each team member has the same understanding of the roles the specic job plays. For nonspecic activities such as contractor, vendor, or other third party, the team must develop an enterprisewide description that can be used in other reviews. With the scope statement and the job titles, the last item the team needs to establish for the review is what effects need to be reviewed. Typically, for condential information, a risk analysis will concentrate on: unauthorized unauthorized unauthorized unauthorized access modication disclosure destruction
55
Exhibit 4.1
Vulnerability Analysis Worksheet

Unauthorized Access Unauthorized Modication Unauthorized Disclosure
Scope Review of Human Resources department handling of condential information.

Destruction
Occupation
Vice president of HR Senior managers Line managers (supervisors) Senior specialists Specialists Recruiters Diversity team lead Ofce administrators Contractors Custodial staff Vendors Information systems support
1 2 3 4 5 6 Greatest risk Great risk Moderate risk Limited risk Low risk No risk
As with the job titles, it will be necessary to dene what each of these review points means; that is, when reviewing unauthorized access, is the team to examine the jobs ability to gain access to condential information in an unauthorized manner, or should one examine their ability to provide unauthorized access? These denitions need to be made prior to the start of the review. Once completed, the Vulnerability Analysis Worksheet might look something like the one shown in Exhibit 4.1. Using the materials discussed in Chapter 2 on the qualitative risk analysis process, the team will assess each job title on its effects on condential information. The team is to rank each job from a high of Greatest Risk to a low of No Risk. This can be done in a number of ways. Each process, however, must begin with all team members understanding and agreeing with all denitions. Once that is accomplished, then the team can begin to work the analysis in one of three ways. The rst method is to have each team member do the analysis individually. Then, each of the scores are added together and divided by the number of
56
team members to obtain an average. Once this is complete, the team can discuss those job titles that had discrepancies. As with any qualitative risk analysis, it is the quality of the team that will lead to quality results. Another method is to, as a team, review the job title for its impact on condential information; this can be done by looking at each job one-by-one and determining its impact in each of the four categories. This requires that the team be together and that each process be discussed if there is any disagreement in the ranking. A variation on the second method, which looks across the worksheet horizontally, is to examine each category vertically; that is, at unauthorized access for each job title, then move on to unauthorized modication, etc. The correct way is the way that works best for ones enterprise. This author has observed that some government agencies have a difcult time working a vulnerability analysis because every job is a greatest risk. That is correct if there are no controls in place. Even the most inefciently run enterprise has some level of controls in place, even if they are only applied by individual departments or some employees. This process will allow the review team to identify the level of risk associated with each job title and then propose controls that can help lower the risk level to an acceptable level. The review does not mean that any of these occupations would do anything unauthorized; but by understanding where the risks lie, effective controls can be put in place. The result of the vulnerability analysis is to identify a level of threat by job assignment. A blank Vulnerability Analysis Worksheet is provided in Exhibit 4.2.
Hazard Impact Analysis

Where the vulnerability analysis looks at jobs and attempts to determine their impact to certain resources, the hazard impact analysis (HIA) was developed by the Federal Emergency Management Administration (FEMA) and the Michigan State Police to determine the hazards a site is most susceptible and vulnerable to experience. The process examines the types of hazards (normally natural threats), and the impacts to staff, property, and business. The process lends itself to those attempting to establish where limited resources are going to be spent to protect against some specic hazards. Because it has been awhile since reviewing the standard set of processes in a risk analysis, take just a minute to review the basics: 1. 2. 3. 4. 5. Assemble the internal experts (the risk analysis team). Develop a scope statement or risk analysis opportunity statement. Agree on the denitions. Ensure the team understands the process. Conduct the risk analysis.
It is important that these steps be followed, regardless of what risk analysis process one decides to use or create. The results of ones work will be suspect if any of the steps are faulty.
57
Exhibit 4.2
Scope
Blank Vulnerability Analysis Worksheet

Unauthorized Access Unauthorized Modication Unauthorized Disclosure
Occupation
1 2 3 4 5 6
Greatest risk Great risk Moderate risk Limited risk Low risk No risk
In HIA, it is necessary to identify the types of threats that need to be examined. So, what then is a threat?
Understanding Threats
What is a threat? Based on the context in which it is used, threat can mean a number of things typically, none of them good. A threat is normally looked upon as an intent to do something bad to someone or to some enterprise. According to Webster, a threat is an indication of an impending undesirable event or, my favorite, an expression of intention to inict evil, injury, or damage. There may be an unlimited number of threats that can be of concern to an enterprise. Any number of good threats can be identied: re ood fraud etc.
Destruction
58
When attempting to establish a list of appropriate threats, it is necessary to ask questions on how a specic threat might impact an organization. It is very important to consider threats, no matter how unlikely they may seem. Remember, a risk analysis is also a historical document that will allow others to see what threats were discussed and the reasons why they were deemed less important than others. As discussed in Chapter 1, there are three basic elements that make up a threat. Generally speaking, these elements are: 1. The agent: the catalyst that performs the threat. The agent can be human, machine, or nature. 2. The motive: something that causes an agent to act. Breaking motive down by agent, the only one that can be both accidental and intentional is the human agent. 3. The results: for risk analysis team, the results would be an impact on the resources being reviewed if the threat were to happen. There are factors that can impact the threats identied by the team. These include: The organizations geographical location where you are located. Some areas of the world are impacted by the aging of the infrastructure that supports the business process. The organizations operation facilities. Older buildings have a tendency to have less adequate re control systems in place and often the cabling need of information processing is inadequate. The kind of information the organization processes or generates. Financial institutions and those that provide services are always going to be targets for fraud. The visibility of the organization. This can be examined two ways. The physical visibility: can an outsider nd the organization quickly? Is the facility one of the landmarks everyone uses for directions? Oh, the shop you are looking for is just down the street from JR Enterprises. The other form of visibility is the prole of the organization. Some groups just do not like the way others earn their living or do not agree with their politics. Emergency training for personnel. Employee morale. Are all of the employees happy with their jobs, family, boss, and life? If so, this is probably one of the only enterprises where this might be true. No matter how hard an organization tries, there are always going to be some employees who have a morale problem. Determining threats can be done in a number of ways, and many of these were discussed in Chapter 1. For the purpose of the HIA process, one can use the threats listed in Exhibit 4.3.
59
Exhibit 4.3. Sample Threat Table

Natural Threats Accidental Deliberate
Earthquake Flooding Hurricane Landslide Sandstorm Snow/ice storm Tornado Tsunami Volcanic eruption Windstorm
Disclosure Electrical disturbance Electrical interruption Emanation Fire Hardware failure Liquid leakage Human error Software error Telecom interruption
Alteration of data Alteration of Software Bomb threat Disclosure Sabotage Fraud Riot/civil disorder Strike Theft Vandalism
Hazard Impact Analysis Process

Once the preliminary processes are complete, the team then examines each threat to determine probability of occurrence. As discussed above, the team must have a working denition of probability of occurrence and denitions of each threat. It is not sufcient to just have re as a threat. There are at least three different levels of re. To ensure that the team can give proper weight to each threat, the threat must be properly dened. Using the worksheet displayed in Exhibit 4.4, the team examines each threat. In column 1 (Type of Threat), the team enters the types of threats: re ood tornado virus fraud electrical outage bomb threat Once those are entered, the team scores the probability of occurrence, either through group discussion and consensus or working individually and averaging the scores. The higher the number entered into column 2, the higher the probability that the threat will occur. It might be necessary to provide guidelines for the numbering scheme, similar to what was done in Chapter 2. The team will want to concentrate on the threat and probability; the impact is reviewed later. Once the probability has been established, the team next looks at impact. The effects of impact are divided into three categories: human property business
60
Exhibit 4.4 Hazard Impact Analysis Worksheet

Property Impact Business Impact Sub Total Internal Resources External Resources Total
Probability
Human Impact
Type of Threat
High Low 4 1 4 1 Low Impact
High Impact
Strong Resources 1
Weak Resources 4
3A
3B
3C
Note: The lower the score, the better.
61
Each impact should be assessed individually, so it is probably better to review all Human impact elements and then move over to Property and nally Business. In reviewing impact, the team should address impact as if there are no controls in place. The controls come into play later. Once the impacts have been scored, the threat totals can be added and that gure entered into the Sub Total column (see Exhibit 4.5). A threat with a subtotal between 10 and 16 should be given extra attention. The next area to be reviewed is resources that can lessen the impact of the threat. Note that these are reversed from the impact numbers. The team will want to identify existing internal controls that can help reduce the impact. This is a two-step approach: identify the safeguard resource and then determine its effectiveness in ghting the impact. For example, in the threat of the Tornado, internal resources that could reduce the impact might be evacuation plans, evacuation drills, warning system (PA, alarm), or physical security staff monitoring weather bulletins. If there are internal controls in place, then the team enters their values in column 5. External controls for this scenario might include local tornado warning alarms, local weather bureau alerts, and building location. These two totals are then added to the Sub Total value (remember, they are reversed value: stronger is lower and weaker is higher), as shown in Exhibit 4.6. If there are no internal or external resources, then the value is 4. The key to working with the HIA process is some common sense. The chances of a tornado hitting a building is very low; but if it does hit, then the impact will be very high. So, look for controls that will help, but that are also in line with reality. Save the budget for those threats that have higher probability and impact. Look at the recent virus attacks; none have been destructive, but they have been so persistent that the clean-up costs are now tagged in the billions.
Threat Analysis
This is a variation of the HIA process just discussed. Instead of assigning a numeric value to a threat, the team attempts to determine how the threat might impact certain elements of the business process. In addition to the normal qualitative risk analysis rst three steps (i.e., assemble the team, develop a scope statement, and agree on denitions), the team will identify those elements it wants to review. This is similar to what occurred in the vulnerability analysis process discussed earlier in this chapter. The team can look at as many or as few elements as it desires. In Exhibit 4.7, the Scope statement wants to review the effects of threats on the data center operation. The team has selected six elements to examine: 1. 2. 3. 4. 5. 6. temporary interruption temporary inaccessibility hardware damage loss of software repairable damage catastrophic damage
62
Exhibit 4.5 Hazard Impact Analysis Worksheet: Steps 1 through 4 Complete

Property Impact Business Impact Sub Total Internal Resources External Resources Total
Probability
Human Impact
Type of Threat
High Low 4 1 4 1 Low Impact
High Impact
Strong Resources 1
Weak Resources 4
Tornado 1 3 1 8 2 7
13
Virus (benign)
Electrical interruption
3A
3B
3C
Exhibit 4.6 Hazard Impact Analysis Worksheet: Completed Example

Property Impact Low Impact Business Impact Sub Total Internal Resources External Resources Total
Probability
Human Impact
Type of Threat
High Low 4 1 4 1
High Impact
Strong Resources 1
Weak Resources 4
Tornado 1 3 1 8 2 2 7 2
13
2 3 3
17 12 13
Virus (benign)
Electrical interruption
3A
3B
3C
63
64 Exhibit 4.7 Threat Analysis Worksheet
Effects on Operations Temporary Inaccessibility Catastrophic Damage Temporary Interruption
Potential Causes
LAN server outage Hardware failure Evacuation bomb threat
P D D
M P M P M M M
Note: M May affect. P Probably will affect. D Denitely will affect.
Using the scope statement and the elements to be reviewed, the team then identies the threats to that resource and then determines if that threat: M = May affect P = Probably will affect D = Denitely will affect NA = Not Applicable, or can be left blank The threat analysis process, like the others, can examine any number of elements. The risk analysis team is only restricted in what it can think of to review. Which method works best for a particular organization? That is a question one has to experiment with to determine what works best. To make the last two risk analysis processes (hazard impact analysis and threat analysis), work best it will be important to ensure that the threats reviewed are actually threats that can impact the enterprise. Review the Scope statement and make sure it describes exactly what is going to be reviewed. Once the analysis process is complete, the team must determine where additional controls are required, as well as develop a set of recommendations for the sponsor and management.
Repairable Damage
Hardware Damage
Loss of Software
65
Questionnaires
Another method of risk analysis is the development of a questionnaire. Questionnaires can be developed to meet a specic resources requirement or can be used to review a broader area. An important key to developing an effective risk analysis questionnaire is to remember the audience. Who will be lling out the forms? Will it be auditors, or security administrators, or managers? The level of the question language must meet the needs of the audience. The number of questions must also be limited. Typically, a series of 20 questions per topic should be the outer limit. This is not a hard-and-fast rule, but the goal of a questionnaire is to get the user community to complete the document. When this author worked for a large multi-national corporation, the information security program was given 20 questions each year. Normally, they were divided into ten that usually remained constant and the other ten were used to assess the topic stressed that past year.
Risk Analysis Questionnaire Process

Each question is reviewed for compliance to an existing enterprise policy, procedure, standard, or other regulation. If the reviewer answered YES, then in COMMENTS section, the reviewer should enter what methods were used to determine that the unit was in compliance with the question. If the reviewer answered NO, then the COMMENTS section is used to identify the steps to be taken to move the unit into compliance, and by what date. The DATE column is the date that the question was reviewed and the INITIALS are those of the reviewer (the individual who made the YES/NO determination). On the nal page of each questionnaire section, the business unit manager is required to sign. This is a way to ensure that the results have been reviewed with management. A typical questionnaire might look something like the one displayed in Exhibit 4.8. A series of information security program questions might look like those listed in Exhibit 4.9. The Computer Security Institute has prepared the Information Protection Assessment Kit (IPAK), which is a self-administered test intended to help an organization determine how well its information protection program is doing. The questionnaire was developed through the efforts of industry experts such as John OLeary, CSI Director of Education; Cheri Jacoby, partner with Pricewaterhouse Coopers, LLP; Dan Erwin, Information Security Specialist at Dow Chemical; Fred Trickey and Tom Peltier, Netigy Corporation; Mike Gregorio of the Coca-Cola Company; and Charles Cresson Wood, of Baseline Software. The IPAK is available through CSI for a nominal fee.
66 Exhibit 4.8 Sample Risk Analysis Questionnaire

Information Protection Yes/ No Comments
Date
Initials
1. A Corporate Information Ofcer (CIO) has been named and the CIO is responsible for implementing and maintaining an effective IP program. 2. The Information Protection (IP) program supports the business objective and/or mission statement of the organization. 3. An enterprisewide IP policy has been implemented. 4. An individual has been assigned as the corporate information protection coordinator and overall responsibility for the IP program implementation has been assigned. 5. The IP program is an integral element of sound management practices.
Single-Time Loss Algorithm

John OLeary, the Computer Security Institutes Director of Education Resource Center, introduced the concept of the Single-Time Loss algorithm for risk analysis. This process takes some of the elements of quantitative risk analysis and adds some qualitative aspects. OLeary uses his background in mathematics to express the variables of a threat in a formula. The structure of this process is very similar to that of the methods examined heretofore. It requires that the key elements of risk analysis be done: 1. 2. 3. 4. 5. Assemble the internal experts (the risk analysis team). Develop a scope statement or risk analysis opportunity statement. Agree on the denitions. Identify the threats. Identify the requirements to recover from the threat.
67
Exhibit 4.9 Sample Information Security Program Questionnaires

Information Protection Program and Administration
1. A Corporate Information Ofcer (CIO) has been named and the CIO is responsible for implementing and maintaining an effective IP program. 2. The Information Protection (IP) program supports the business objective or mission statement of the organization. 3. An enterprisewide IP policy has been implemented. 4. An individual has been assigned as the corporate information protection coordinator and overall responsibility for the IP program implementation has been assigned. 5. The IP program is an integral element of sound management practices. 6. IP is identied as a separate and distinct budget item (approximately 1 to 3 percent of the overall ISO budget). 7. Senior management is aware of the business needs for an effective IP program, and is committed to support its success. 8. An effective risk analysis process has been implemented to assist management in identifying potential threats, probability of threat occurrence, and possible countermeasures. 9. IP controls are based on cost-benet analysis utilizing risk analysis input. 10. IP responsibilities and accountability for all employees with regard to IP are explicit. 11. Each business unit, department, agency, etc. has designated an individual responsible for implementing the IP program for that organization. 12. The IP program is integrated into a variety of areas, both within and outside the computer security eld. 13. Comprehensive information protection policies, procedures, standards, and guidelines have been created and disseminated to all employees and appropriate third parties. 14. An ongoing IP awareness program has been implemented for all organization employees. 15. A positive, proactive relationship with the audit staff has been established. 16. Employees have been made aware that their activities may be monitored. 17. An effective program to monitor IP program-related activities has been implemented. 18. Employee compliance with IP-related issues is an annual appraisal element. 19. The system development life cycle addresses IP requirements during the Initiation or Analysis (rst) phase. 20. The IP program is reviewed annually and modied when necessary.
68
This risk analysis process requires two brainstorming sessions: one to identify and prioritize the threats and another session to identify the recovery elements. The latter session may take longer than the rst. For a threat like an earthquake, a completed algorithm might look something like the following: (Total asset value + Contingency implementation costs + Data reconstruction costs) 0.25 + (Cost of 1-week delay) = STL This formula takes the value of the asset and adds that to the cost of implementing the business contingency plan plus the cost of data reconstruction. The determination of data reconstruction will include many factors, for example, the availability of backup media, the staff available to process the jobs, the new media to copy the backup to, and the time to do all of these tasks. The 0.25 that these gures are multiplied by is the annual rate of occurrence (as discussed in Chapter 1). Finally, the cost of one weeks delay is added to these gures to give an STL total. The team must establish what a single days loss to the enterprise might be. One way to do that is to take the annual revenues and divide that gure by 260 (the typical number of working days in a year), and this will give a ballpark gure on daily losses. The algorithm represents those elements that would be necessary to recover a specic asset or resource if a certain threat was to occur. The formulas can be used in two ways: (1) the team can actually develop values for each element and work the formula, which might be a difcult task; or (2) the team can use the complexity of the formulas to help prioritize the threats and identify where safeguards will provide the most benets.
Conclusion
Which risk analysis process will work best for a particular person and a particular organization? Only that person/organization will be able to determine. Before this decision can be made, it will be necessary to examine as many as possible. This chapter has presented variations on qualitative risk analysis themes. The keys to each process are the same: 1. 2. 3. 4. 5. Assemble the internal experts (the risk analysis team). Develop a scope statement or risk analysis opportunity statement. Agree on the denitions. Ensure that the team understands the process. Conduct the risk analysis.
The next two chapters examine the Facilitated Risk Analysis Process (FRAP) and then three variations on this process to the reader in pre-screening application and conducting a business impact analysis.
Chapter 5
Facilitated Risk Analysis Process (FRAP)

Most enterprises are attempting to manage the same types of risks that face every other organization. With the changing business culture, the successful security teams have had to modify the process of responding to new risks in the high-prole, E-business environment. Even with the change of focus, todays organizations must still protect the integrity, condentiality, and availability of information resources upon which they rely. While there is an increased interest in security by upper management, the fact remains that the business of the enterprise is business. The security program must assist the business units by providing high-quality reliable service in helping them protect the enterprises assets.
Facilitated Risk Analysis Process (FRAP) overview

The Facilitated Risk Analysis Process (FRAP) was developed as an efcient and disciplined process for ensuring that information security-related risks to business operations are considered and documented. The process involves analyzing one system, application, or segment of business operation at a time and convening a team of individuals that includes business managers who are familiar with business information needs and technical staff who have a detailed understanding of potential system vulnerabilities and related controls. The sessions, which follow a standard agenda, are facilitated by a member of the project ofce or information protection staff; this person is responsible for ensuring that the team members communicate effectively and adhere to the agenda. During the session, the team brainstorms to identify potential threats, vulnerabilities, and resultant negative impacts on data integrity, condentiality,
69
70
and availability. Then the team will analyze the effects of such impacts on business operations and broadly categorize the risks according to their priority level. The team does not usually attempt to obtain or develop specic numbers for the threat likelihood or annual loss estimates unless the data for determining such factors is readily available. Instead, the team relies on its general knowledge of threats and vulnerabilities obtained from national incident response centers, professional associations and literature, and their own experience. When assembling the team, it is the experience that allows them to believe that additional efforts to develop precisely quantied risks are not cost-effective because: Such estimates take an inordinate amount of time and effort to identify and verify or develop. The risk documentation becomes too voluminous to be of practical use. Specic loss estimates are generally not needed to determine if a control is needed. After identifying and categorizing risks, the team identies controls that could be implemented to reduce the risk, focusing on the most cost-effective controls. Unlike the 30-Minute Risk Analysis, the team will use a starting point of 26 common controls designed to address various types of risk. Ultimately, the decision as to what controls are needed lies with the business managers, who take into account the nature of the information assets and their importance to business operations and the cost of controls. The teams conclusions as to what risks exist, what their priority is, and what controls are needed are documented and sent along to the project lead and the business manager for completion of the action plan. Here, the security professional can assist the business unit manager in determining which controls are cost-effective and meet their business needs. Once each risk has been assigned a control measure or has been accepted as a risk of doing business, then the senior business manager and technical expert participating sign the completed document. The document and all associated papers are owned by the business unit sponsor and are retained for a period of time to be determined by the records-management procedures (usually seven years). Each risk analysis process is divided into four distinct sessions: 1. The pre-FRAP meeting takes about an hour and involves the business manager, project lead and facilitator. 2. The FRAP session takes approximately four hours and includes seven to 15 people, although sessions with as many as 50 and as few as four people have occurred. 3. FRAP analysis and report generation usually takes four to six days and is completed by the facilitator and scribe. 4. The post-FRAP session takes about an hour and has the same attendees as the pre-FRAP meeting.
71
The remainder of this chapter examines why FRAP was developed, what each one of the four phases entail, and what are the deliverables from each phase.
The Need for FRAP

Prior to the development of the FRAP, risk analysis was often perceived as a major task that required the enterprise to hire an outside consultant and could take an extended period of time. Often, the risk analysis process took weeks to complete and represented a major budget item. By hiring outside consultants, the expertise of the in-house staff was often overlooked and the results produced were not acceptable to the business unit manager. The results of the old process were business managers who did not understand the recommended controls, did not want the recommended controls, and often undermined the implementation process. What was needed was a risk analysis process driven by the business managers, takes days instead of weeks or months, is cost-effective, and uses in-house experts. The FRAP meets all of these requirements and adds another in that in can be conducted by someone with limited knowledge of a particular system or business process, but with good facilitation skills. The FRAP is a formal methodology developed through understanding how the previously developed qualitative risk analysis processes modify them to meet current requirements. It is driven by the business side of the enterprise and ensures that controls enable the business process to meet its objectives. There is never a discussion about controls such as security or audit requirements. The FRAP focuses on the business need and the lack of time that can be spent on such tasks. By involving the business units, the FRAP uses them to identify risks and threats. Once resource owners are involved in identifying threats, they generally set up and look for assistance in implementing cost-effective controls to help limit the exposure. The FRAP allows the business units to take control of their resources. It allows them to determine what safeguards are needed and who will be responsible for implementing those safeguards. The results of the FRAP are a comprehensive document that identies threats, prioritizes those threats, and identies controls that will help mitigate those threats. It provides the enterprise with a cost-effective action plan that meets the business needs to protect enterprise resources while conducting business. Most importantly, with the involvement of business managers, the FRAP provides a supportive client or owner who believes in the action plan.
Introducing the FRAP to an Enterprise

When beginning the FRAP, it will be necessary to explain what the FRAP is and how it works. This will be necessary for the rst few months of the
72
introduction of the process to an enterprise. One might want to conduct FRAP overview sessions to assist in this process. It will be most benecial to conduct these sessions initially with the applications and systems development groups. Eventually, the business units should be introduced to the process. It will be necessary to sell this service to the business community. Use some of the arguments discussed above, but let them know that this costeffective process will allow the business units to control their own destiny. The FRAP has been implemented to assist the enterprise in meeting business objectives and that the completion of a risk analysis process is the cost of doing business in todays environment. The key will be that the process will help identify business risks. The risk will be classied as undesirable or unauthorized events not in terms of their effect on security or audit requirements, but in terms of their effect on completing the business objectives or mission of the enterprise. It will be necessary to ensure that all employees understand some basic denitions in the FRAP. There will be more denitions later; but for now, one must be sure that employees understand ve key denitions: 1. Risk: a potential event that will have a negative impact on the business objectives or mission of the enterprise. 2. Control: a measure taken to avoid, detect, reduce, or recover from a risk to protect the business process or mission of the enterprise. 3. Integrity: information is as intended, without unauthorized or undesirable modication or corruption. 4. Condentiality: information has not undergone unauthorized or undesirable disclosure. 5. Availability: applications, systems, or information resources are accessible when necessary. The FRAP objectives are to identify potential undesirable or unauthorized events, risks, that could have a negative impact on the business objectives or mission of the enterprise. Once these risks have been identied and prioritized, then appropriate controls will be identied to help mitigate the risk level. The team will examine all types of risks, whether accidental or deliberate. The facilitator will assist the team through the brainstorming process by asking leading questions. Try to get the team to examine other courses of risk. What do you think of this? or What would happen if this occurred?
The Pre-FRAP Meeting

The pre-FRAP meeting is the key to the success of the project. The meeting normally lasts about an hour and is usually conducted at the client ofce. The meeting should have the business manager (our representative), the project development lead, and the facilitator. There will be ve key components that come out of this one-hour session.
73
1. Scope statement. The project lead and business manager need to create a statement of opportunity for review. They are to develop in words what exactly is going to be reviewed. The scope statement was discussed in Chapter 2 and should be reviewed for content. 2. Visual model. There needs to be a visual model. This is a one-page or foil diagram depicting the process to be reviewed. The visual model is used during the FRAP session to acquaint the team with where the process begins and ends. 3. Establish the FRAP team. A typical FRAP has between seven and 15 members and has representatives from a number of business and support areas. The makeup of the FRAP team is discussed later in this chapter. 4. Meeting mechanics. This is the business unit managers meeting and that individual is responsible for getting the room, setting the schedule, getting the materials needed (overhead, ip charts, coffee and doughnuts). 5. Agreement on denitions. The pre-FRAP session is where the agreement on FRAP denitions is completed. There needs to be agreement on the denitions of the review elements (integrity, condentiality, availability). In addition to the review elements, it will be necessary to agree on: a. risk b. control c. impact d. vulnerability During the pre-FRAP session, it will be important to discuss the process for prioritizing the threats. There are two schools of thought for how to go about this process. The rst is to have the FRAP team review all identied threats as if there are no controls in place. This will establish the ideal logical control set. This will allow the FRAP to be used a gap analysis between as-is and to-be demonstrating the gap and vulnerability. The second method is to assess threats with existing controls in place. The key phrase here is assess. There are three phases in the information protection process: 1. Risk analysis: to review the existing environment, identify threats, prioritize threats, and recommend safeguards 2. Safeguard implementation: determine and implement those safeguards that make sound business sense 3. Security assessment: review the safeguards (controls) and determine their effectiveness
The FRAP Team

During the pre-FRAP meeting, the business manager and project lead will need to identify who should be part of the FRAP session. The ideal number
74
of participants is between seven and 15. It is recommended that representatives from the following areas be included in the FRAP process: functional owner system user system administrator systems analysis systems programming applications programming database administration information security physical security telecommunications network administration service provider auditing (if appropriate) legal (if appropriate) human resources (if appropriate) labor relations (if appropriate) There are no hard and fast rules as to who should attend; but to be successful, the functional business owner and system users should be part of the FRAP. It is their business process that will be reviewed and it will be important that they be part of the process. The system(s) group is also an important part of the FRAP team. The system administrator is normally found in the user department and has had some training in the new application or system, and is the initial point of contact for users when they have problems. The systems analysis group is composed of those bilingual individuals that speak uent business and information systems. That can be vital in ensuring that what is spoken at a FRAP meeting is understood by all parties. The systems programming group consists of those individuals who support the platforms and ensure that the current operating environment is working and properly congured. Applications programming is the individuals who will either create the new application or customize existing application or third-party software to meet the functional owners needs. The database administrators are the technical individuals who understand how the mechanics of the database works and are often responsible for ensuring that database security mechanisms are working properly. Information security should have a representative as part of the FRAP team. Many FRAPs are facilitated by someone from information security, but this is often a conict of interest. The facilitator should have an aura of neutrality about them. Physical security (or someone from facility engineering) should be part of the team. This will bring a perspective of viewing concerns from the physical operations of the environment.
75
If the resource under review is going to access the network, or other telecommunication devices, then representatives from those areas must be part of the process. Any Web-based applications will require representatives form the Internet support organization, including the Web master and the rewall administrator. The next four groups are all classied as if appropriate. The audit staff is a group that can offer some good ideas, but they often impact the free ow of information. Unless there exists a very good working relationship with the audit staff, it is recommended that they not take part in the FRAP session. The audit team will see the results of the FRAP later and will probably use the output when they conduct an audit of the resource. The legal staff is normally too busy for every FRAP. However, if there is a resource under review that has a major impact on the enterprise, it will probably be appropriate to extend an invitation to the legal department. This author recommends meeting with legal staff to discuss what theFRAP is and to establish guidelines as to when they need to either be part of the process or to see specic risk concerns. Whenever a resource under review is going to impact employees, then Human Resources and, for represented employees, Labor Relations need to be involved in the FRAP. This list is not all inclusive, nor does it represent the correct mix of players if the FRAP moves away from the traditional information security risk analysis. The key here is to understand that to be a successful FRAP, there must be representation from a wide spectrum of employee groups.
The FRAP Facilitator

Facilitation of a FRAP requires the use of a number of special skills. These skills can be improved by attending special training and by facilitating. The skills required include the ability to: Listen: having the ability to be responsive to verbal and non-verbal behaviors of the attendees. Being able to paraphrase responses to the subject under review and to be able to clarify the responses. Lead: getting the FRAP session started and encouraging discussion while keeping the team focused on the topic at hand. Reect: repeating ideas in fresh words or for emphasis. Summarize: being able to pull themes and ideas together. Confront: being able to feed back opinions, reacting honestly to input from the team and being able to take harsh comments and turn them into positive statements. Support: creating a climate of trust and acceptance. Crisis intervention: helping to expand a persons vision of options or alternatives and to reinforce action points that can help resolve any conict or crisis.
76
Center: helping the team to accept others views and build condence for all to respond and participate. Solve problems: gathering relevant information about the issues at hand and help the team establish an effective control objective. Change behavior: look for those who appear not to be part of the process and bring them into the active participation. Basic facilitation rules must be observed by all facilitators if the FRAP is to be successful. FRAP leaders must: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Observe carefully and listen to all that the team says and does. Recognize all input and encourage participation. Be observant of nonverbal responses. Never lecture; listen and get the team involved. Never lose sight of the objective. Stay neutral (or always appear to remain neutral). Learn to expect hostility, but never become hostile. Avoid being the expert authority. The facilitators role is to listen, question, enforce the process, and offer alternatives. Adhere to time frames and be punctual. Use breaks to free a discussion. Be there to serve the FRAP team. Stop the FRAP if the group is sluggish and difcult to control.
As the FRAP facilitator, it will be necessary to develop ones own FRAP toolkit. This toolkit should include: ipcharts masking tape and push pins color pens/markers tent cards session agreements The session agreements were developed a number of years ago, and some of this authors team members have had theirs laminated and post them in the FRAP session room (see Exhibit 5.1). The agreements require that: Everyone participates: one will see how this happens in the FRAP session process Everyone stays with identied roles: the facilitator will facilitate and the scribe will scribe, everyone else will participate.
77
Everyone sticks to the agenda/current focus: the scope statement and visual will be posted or given to all attendees. All ideas have equal value: whereas George Orwell said that all animals are equal, but some are more equal than others, equality is stressed here. Everyone listen to other points of view: get the team to actually listen to the speaker and not just wait for their turn with the token. No plops all issues are recorded: Jack Durner of the Mendon Group gave us this term; nothing plops onto the oor. Deferred issues will be recorded: if an item is outside the scope of what is under review, then it is recorded on the deferred issues list and will have someone assigned to look into the issue. Post the idea before discussing it: get it on the ipchart rst. Help the scribe ensure that all issues are recorded: bring a scribe along to record what is posted on the ipcharts. One conversation at a time: here is where ones facilitation skills will be tested. One angry person at a time: this author usually volunteers for the job. Apply the 3 to 5 minute rule: all discussions must be concluded within the agreed to time frame. Be: prompt fair nice creative Have fun.
Exhibit 5.1
FRAP Session Agreements (Developed by Jack Durner)
78
The FRAP Session

The FRAP session is generally scheduled for four hours. Some organizations have expanded the process to last as long as three days, but typically, the four-hour limit is based on busy schedules and the exibility of the FRAP. The FRAP session can be divided into three distinct sections, with nine elements driving out three deliverables. Phase 1: Logistics during this phase, the FRAP team will introduce itself, giving name, title, department, and phone number (all of this will be recorded by the scribe). The roles of the FRAP team will be identied and discussed. Typically there are ve roles: 1. 2. 3. 4. 5. owner project lead facilitator scribe team member(s)
During this initial phase, the FRAP team will be given an overview of the process that they are about to take part in. They will also be exposed to the scope statement, and then someone from the technical team will give a veminute overview of the process under review (the visual model). Finally, the denitions will be reviewed and each member should be given a copy of the denitions. Once the preliminaries are complete, the FRAP team will begin the brainstorming process (see Exhibit 5.2). This is Phase 2, which takes each review element (integrity, condentiality, and availability) and identies risks, threats, concerns, and issues for each element. The process for brainstorming is that the facilitator will display the denition and some working examples of risks. The team is then given three minutes
Exhibit 5.2. Brainstorming Denition and Sample Risks
Examples of Risks (NOT a complete list) Threats to Condentiality
access without authorization disclose without authorization observe or monitor transactions copy without authorization packet snifng on network contractor accessing condential information
Denition: Condentiality: information has not undergone unauthorized or undesirable disclosure.
79
to write down risks that are of concern to them. The facilitator will then go around the room getting one risk from each team member. Many will have more than one risk, but the process is to get one risk and then move to the next person. In this way, everyone gets a turn at participating. The process continues until everyone passes (that is, there are no more risks that the team can think of). The brainstorming process continues until each of the review elements has been completed. Once this process is complete, it is recommended that the team be given a coffee break. When the team members come back into the conference room, have them review the risks posted around the room and then take a few minutes to clean up duplicate risks and make any edits where deemed appropriate. Once the cleanup is complete (only allow about 10 to 15 minutes for this process), the team will now concentrate on prioritizing the risks. This is done by determining the enterprises vulnerability to the risk and the business impact if the risk were to occur. These denitions are agreed upon at the pre-FRAP meeting and are presented to the team during the introduction. A typical set of denitions might be: High Vulnerability: a very substantial weakness exists in the systems or the operational routine; and where the business impact potential is severe or signicant, the control must be improved. Medium Vulnerability: some weakness exists; and where the business impact potential is severe or signicant, the controls can and should be improved. Low Vulnerability: the system is already well-constructed and operated correctly. No additional controls are needed to reduce vulnerability. Severe Impact (High): likely to put the enterprise out of business or severely damage its business prospects and development. Signicant Impact (Medium): will cause signicant damage and cost, but the enterprise will survive. Minor Impact (Low): the type of operational impact one expects to have to manage as part of ordinary business life. The team would be aided by using the priority model shown in Exhibit 5.3. The box selected will correspond to a letter grade assigned to the risk as its priority. The response from the FRAP team will be as follows: A corrective action must be implemented B corrective action should be implemented C requires monitoring D no action required There are a number of different ways in which the team can assign the priority to each risk. The three most popular are:
80
1. The facilitator goes over each risk one by one and the team discusses each risk and then reaches consensus. 2. The facilitator reviews the rst three or four risks to ensure that the team has the right idea on how the process works, and then each team member is given a colored marker and asked to assign a priority. If they have no opinion, then they leave that one blank and move on to the next risk. When the team is nished, the facilitator will review the work and where there appears to be a conict, the facilitator will open up the process for discussion. As an example, where there are 15 FRAP team members, and ten assign a value of C to the risk and ve assign either an A or a B, then the facilitator will want to discuss the issue to ensure that C is the most correct answer. 3. A third method that can be used is that the facilitator gives each team member ten dots (the kind that can be purchased at any ofce store and are self-adhesive). Each team member is allowed to vote for ten major risks. Those with dots will require a control; those without are considered minor risks.
Exhibit 5.3 Sample Priority Matrix
Business Impact High Medium Low
High Vulnerability
Medium
Low
The FRAP session will generate three deliverables: identication of risks prioritization of risks suggested controls for major or high-priority risks In Exhibit 5.4, the area in the double-outlined area indicates some of the 120 risks that were identied in this FRAP process. The key to Exhibit 5.4 is: Risk = actual risk voiced by FRAP team member (double-outline) Type = integrity, condentiality, or availability risk Priority = priority level A, B, C, or D (bold outline) Controls = controls identied to help mitigate the risk
81
Exhibit 5.4 FRAP Session Deliverables

Risk # Risk Type Priority Controls
1 2 3
Information accessed by personnel not intended to have access Unclear or non-existent versioning of the information Database could be corrupted by hardware failure, incorrect, or bad software Data could be corrupted by an incomplete transaction Ability to change data in transit and then changing it back in order to cover the activity A failure to report integrity issues Incompletely run process or failure to run a process that could corrupt the data Lack of internal processes to create, control, manage data across functions No notication of integrity problems Information being used in the wrong context Third-party information may have integrity issues Third-party access to information
INT INT INT
B B D
3, 5, 6, 11, 12, 16 9, 13, 26
4 5
INT INT
C C
6 7
INT INT
A B
7, 11, 12, 13, 20, 21 1, 2, 12, 13, 14, 15, 18, 20, 21, 25 7, 13, 17, 20, 23, 25
INT
9 10 11 12
INT INT INT INT
A B B A
7, 13, 26 11, 12, 19 7, 13, 26 3, 4, 5
The nal process in the FRAP session is to identify controls for those risks identied as requiring them. When the invitation to the FRAP session was sent out, the business manager included a list of 26 controls, as shown in Exhibit 5.5, that will be used during this phase of the FRAP session. The list of controls is contained in the documentation for the FRAP and currently is part of an Excel spreadsheet. The 26 controls are an amalgamation of controls developed by various FRAP facilitators over the past few years. The Controls List is used as a starting point for the FRAP team and can be modied or added to as required by the team. If any changes are made during the session, then those changes must be made in the Excel Tab titled Controls.
82 Exhibit 5.5 FRAP Controls List

Control Number Class
Control Description
Backup
Backup requirements will be determined and communicated to the service provider, including a request that an electronic notication that backups were completed be sent to the application system administrator. The service provider will be requested to test the backup procedures. Develop, document, and test recovery procedures designed to ensure that the application and information can be recovered, using the backups created, in the event of loss. Implement an access control mechanism to prevent unauthorized access to information. This mechanism will include the capability of detecting, logging, and reporting attempts to breach the security of this information. Access sourced: implement a mechanism to limit access to condential information to specic network paths or physical locations. Implement user authentication mechanisms (such as rewalls, dial-in controls, secure ID) to limit access to authorized personnel. Implement encryption mechanisms (data, end-toend) to prevent unauthorized access to protect the integrity and condentiality of information. Design and implement application controls (data entry edit checking, elds requiring validation, alarm indicators, password expiration capabilities, checksums) to ensure the integrity, condentiality, and availability of application information. Develop testing procedures to be followed during applications development and during modications to the existing application that include user participation and acceptance. Adhere to a change management process designed to facilitate a structured approach to modications, to ensure appropriate steps and precautions are followed. Emergency modications should be included in this process.
Recovery Plan
Access Control
Access Control
Access Control
Access Control
Application Control
Acceptance Testing
Change Management
83
Exhibit 5.5 FRAP Controls List (Continued)

Control Number Class Control Description
10
Anti-virus
1) Ensure LAN administrator installs the corporate standard anti-viral software on all computers. 2) Training and awareness of virus prevention techniques will be incorporated in the organization IP program. Develop policies and procedures to limit access and operating privileges to those with business need. User training will include instruction and documentation on the proper use of the application. The importance of maintaining the condentiality of user accounts, passwords, and the condential and competitive nature of information will be stressed. Implement mechanisms to monitor, report, and audit activities identied as requiring independent reviews, including periodic reviews of userIDs to ascertain and verify business need. Operations controls: training for a backup to the system administrator will be provided and duties rotated between them to ensure the adequacy of the training program. Operations controls: application developers will provide documentation, guidance, and support to the operations staff (service provider) in implementing mechanisms to ensure that the transfer of information between applications is secure. Operations controls: mechanisms to protect the database against unauthorized access, and modications made from outside the application, will be determined and implemented. Operations controls: systems that feed information will be identied and communicated to the service provider to stress the impact to the functionality if these feeder applications are unavailable. Operations controls: time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants. (continues)
11
Policy
12
Training
13
Audit/Monitor
14
Backup
15
Training
16
Access Control
17
Interface Dependencies
18
Maintenance
84 Exhibit 5.5 FRAP Controls List (Continued)

Control Number Class
Control Description
19
Training
User controls: implement user programs (user performance evaluations) designed to encourage compliance with policies and procedures in place to ensure the appropriate utilization of the application. Acquire service level agreements to establish level of customer expectations and assurances from supporting operations. Acquire maintenance and supplier agreements to facilitate the continued operational status of the application. In consultation with facilities management, facilitate the implementation of physical security controls designed to protect the information, software, and hardware required of the system. Request management support to ensure the cooperation and coordination of various business units, to facilitate a smooth transition to the application. Proprietary controls The development team will develop corrective strategies, such as reworked processes, revised application logic, etc. Production Migration controls, such as search and remove processes to ensure data stores are clean.
20
Service Level Agreement Maintenance
21
22
Physical Security
23
Management Support
24 25
Proprietary Corrective Strategies Change Management
26
The controls can be identied generally in two ways: The facilitator can go to each high-priority risk and have the team call out the number of the risk that they feel will help alleviate that risk. The facilitator can work the rst three or four priority risks and then allow the team to get back up and write down their choices. If a risk that they would choose has already been selected, it is not necessary to put it up there again. The team needs to understand that what they select is not what will be implemented. For example, in Row 7 of Exhibit 5.4, the team selected nine possible controls. The business manager, project lead, and facilitator will work together in the post-FRAP meeting to determine which one or two controls will work best. The FRAP team must understand that trade-offs must be made between business objectives and risks. Every control or safeguard will impact the
85
business process in some manner as resources are expended to implement the control. Accidents, errors, and omissions generally account for more losses than deliberate acts. No control can or should be 100 percent effective. The ultimate goal is to achieve an acceptable level of security. The FRAP will not eliminate every risk. Management has the duty to determine which risks it will implement controls on and which ones to accept. The FRAP team is to assist management in making that informed business decision. The FRAP session is complete when the three deliverables are nished. Those three steps are: 1. risks identied 2. risks prioritized 3. controls identied
Post-FRAP Meetings
Just as the 30-minute risk analysis is a misnomer, so is the concept that the FRAP can be completed in four hours. As observed, the pre-FRAP meeting takes an hour and the FRAP session will take approximately four hours. These two together are only the information-gathering portion of the risk analysis process. To get a complete report, the business manager, project lead, and facilitator will have to complete the action plan. The post-FRAP process has ve deliverables: 1. 2. 3. 4. 5. Cross-reference sheet identication of existing controls consulting with owner on open risks identication of controls for open risks Final report
At its current level of technical advancement, the Cross-reference Sheet is the most time-consuming process for the facilitator and scribe. This document takes each control and identies all the risks that would be impacted by that single control. For example, in Row 2 in Exhibit 5.4, the FRAP team has identied three controls (9, 13, 26) that would help control this risk. The Cross-reference Sheet for Control Number 9 would look like the table in Exhibit 5.6. In this example, Control 9 would help mitigate 11 different risks. The Crossreference Sheet helps the business manager determine where scarce resources can best be used. Once the Cross-reference Sheet is complete (two working days should be sufcient), the Action Plan and Cross-reference Sheet are sent to the business manager. As above, the FRAP session will generate a report like the one shown in Exhibit 5.7. With the Action Plan and the Cross-reference Sheet, the facilitator
86
Exhibit 5.6 Cross-reference Sheet Example

Risk # Risk Type Priority
Control Number
Control Description
9 16 23 25 29 35 E-business integrity policies conict with existing corporate policies Wrong document or data is published Incorrect use of the modication process in the application development process (change code without testing) Personal information for staff might be posted on the Internet without authorization New technologies leading to breaches of condentiality Loss of sales and increased costs due to release of competitive advantage information without company knowledge Electronic eavesdropping of company sites 9 Incorrectly made hardware or software changes Not responding to requests in a timely manner INT INT INT INT Impact to business by using information that is incorrect INT
Unclear or non-existent versioning of the information
INT
B B A A A B
Adhere to a change management process designed to facilitate a structured approach to modications, to ensure appropriate steps and precautions are followed. Emergency modications should be included in this process.
40
CON
44 47
CON CON
A B
50
CON AVA
B B
Exhibit 5.7
BY WHO WHEN ADDITIONAL COMMENTS
Selected Controls for Action Plan
OWNER ACTION
ACF2 has been implemented and the access control list will be reviewed to identify authorized users. Operations complete
Owner & IP
7/15/00
Change management procedures already in place
Employee training sessions scheduled Owner & Operations Owner Owner
HR
8/15/00 7/31/00 8/20/00 8/20/00
Backup SLA to be reviewed with operations
SLA with service provider to be implemented
SLA with service provider to be implemented
87
88
and project lead normally sit down to determine which controls are already in place. Once this is completed, they then meet with the business manager to review the document and recommend which controls can help those risks that are still open. The framed items in Exhibit 5.7 were already closed; that is, controls were already in place. In most risk analysis processes, when the team gets down to this level, they nd that nearly 80 percent of the risks already have some form of control in place. For those open risks, the facilitator, project lead, and business manager determine which controls will be most cost-effective and then determine who will implement them and by what date. Remember, if a third party will be required to implement the control, then some discussion with them must take place to determine the completion date. Once all open risks have either an assigned control or that the owner has indicated in the comment section that they are accepting the risk, the Final Report, as shown in Exhibit 5.8, is ready to be initiated.
Conclusion
The Facilitated Risk Analysis Process (FRAP) is currently the most widely used form of qualitative risk analysis being used today. The FRAP consists of three major parts: 1. The pre-FRAP Meeting which last about 1 hour and has ve deliverables: a. Scope statement b. Visual diagram c. Team members d. Meeting Mechanics e. Denitions i. risk ii. control iii. review elements (integrity, condentiality, availability) iv. vulnerability impact 2. The FRAP session, which normally lasts about four hours and has three deliverables: a. identied risks b. prioritized risks c. suggested controls 3. The post-FRAP process, which can take up to ten days and has three elements: a. creation on the Cross-reference Sheet b. identication of existing controls c. selection of controls for open risks or acceptance of risk
89
Exhibit 5.8
Date: To:
Sample of Final Report Letter

(enter date) Mr. Owner IS Security Center of Excellence (SCoE) Manager Owner/Owners Representative Ms. Facilitator IS Information Management Center of Excellence (IMCoE) Manager Facilitated Risk Analysis
From: Subject:
The Information Protection group facilitated a Risk Analysis session on the functionality named below. The Risk Analysis attendees identied the risks and controls shown on the attached Action Plan. The attendees included you, or your representative, to ensure that the concerns of your organization were properly addressed. The Action Plan shows which of the controls identied during the Risk Analysis have been, or will be implemented. You should have made the decisions as to if and when the controls will be implemented. FRAP Date: 6/8/00
System/Application: IS E-commerce Functionality Owner: Facilitator: Mr. Owner Ms. Facilitator
Please read the Statement of Understanding below, sign it, and return it to me. STATEMENT OF UNDERSTANDING: I, the Owner, understand that the risks identied on the attached Risk Analysis Action Plan could cause the integrity, condentiality, availability of this system/applications information to be negatively impacted. I have decided to implement the controls according to the schedule on the attached Risk Analysis Action Plan. I understand that any risks which are not controlled could adversely affect corporate information and company business. I am aware that a copy of the Risk Analysis Action Plan will be forwarded to the Audit organization. ______________________________________________________ Owner/Owners Representative IS Security Center of Excellence (SCoE) Manager ______________________________________________________ IS Information Management Center of Excellence (IMCoE) Manager _________________________ Date _________________________ Date
90
Most organizations agree that risk considerations and related cost-benet trade-offs are the primary focus of effective security programs. Security cannot be viewed as an end in itself, but as a set of policies and processes designed to support business operations. Implementing a risk analysis process that is to use and geared to support the business processes will make acceptance of controls that much easier. Information and the systems that process these resources are critical assets essential to supporting the business or mission of any enterprise and must be protected. An effective risk analysis process ensures that these business needs are met.
Chapter 6
Other Uses of Qualitative Risk Analysis

Given a basic understanding of qualitative risk analysis, one can use the concepts to improve the work process at an enterprise. As part of a misunderstood group, security and audit professionals are often viewed by the rest of the organization as non-value-added elements of the enterprise. One way to overcome this misconception is to implement processes that streamline the control review requirements. Not every application or system needs to have a formal risk analysis process or a business impact analysis. What is needed is a formal process that allows for a pre-screening of applications and systems to determine needs. By using the processes learned in qualitative risk analysis, one will be able to develop a quick formal process that could save time and money. The key is to start by understanding what is the business objective or mission of the enterprise. Using this information as a base, develop a set of questions that can be completed by the project lead and the business manager. These questions allow the development team to determine if a formal risk analysis or business impact analysis must be completed. Two different approaches to the pre-screening process are examined: (1) an impact analysis process used by a nancial institution, and (2) a process used by a major information systems service provider.
Impact analysis
The pre-screening process looks for the impact of the new application or system on two important elements of the enterprise: the sensitivity of the data involved and the resource impact. Resource impact includes nancial (internal and external) and customer impact.
91
92
Exhibit 6.1 Pre-screening Sensitivity Questions for Impact Analysis

Impact Value Sensitivity of Data
High
Extreme sensitivity restricted to specic individual need-toknow; its loss or compromise may cause severe nancial, legal, regulatory, or reputation damage to the company. Used only by specic authorized groups with legitimate business need; may have signicant adverse impact; possible negative nancial impact. Information for internal business use within the company; may have adverse impact; negligible nancial impact.
Medium
Low
The project lead and the business manager are asked to complete the questionnaire to assess the applications level of impact on the enterprise and the type of technology used by the application. If the application is considered low risk or low impact, then an implementation of baseline controls is all that is required. If the application comes back as low but the business manager does not want the baseline controls, then a formal risk analysis must be conducted. For those applications identied as high impact or high risk, a formal risk analysis and business impact analysis must be scheduled. It is the responsibility of the business unit to complete the pre-screening questionnaire and to schedule any additional follow-up sessions. The project lead is asked two series of questions. The rst series deals with the sensitivity of the data. Exhibit 6.1 provides an example of how the questions might look. The questions are based on the information classication policy of the company and provide the project lead and business manager with three levels of impact: high, medium, and low. Once the sensitivity of the data has been determined, then the questionnaire requests four additional answers. These next four questions all have a nancial twist to them. The rst is looking for a project cost in the total budget approved. When developing prescreening questions, the values plugged into these questions will need to reect a particular enterprise. The values shown in Exhibit 6.2 are for a ctional nancial company. Thus, the rst question tries to get a picture of the budget for this project. The second question attempts to get a feel for the transaction value on a daily basis. This question leads directly to a business impact analysis review and ultimately a level of requirement for contingency planning. The third question is similar to the second, but looks for a response in a little different manner. Here, the number of customers impacted by the new transaction, application, or system is addressed. The threshold of pain for customers impacted will have to be determined by the business unit that deals with customer satisfaction. The nal question in this example attempts to determine the level of penalty imposed by regulatory organizations if the
93
application or system is unavailable. The thresholds here must be established by the regulatory affairs unit of an enterprise. Thus, for this organization, the second set of questions will require input from the budget process. Most organizations set a percentage level of the overall information systems budget as the threshold for impact in this category. The nal three questions will require input from the nancial staff, customer satisfaction, and regulatory affairs, as shown in Exhibit 6.2. If any of the responses come out High, then a formal risk analysis and business impact analysis must be scheduled. If two responses are Medium, then a meeting between the security team and the business unit must be called. If all of the answers are Low, the business unit must implement the standard set of baseline controls.
Application Pre-screening
Another example of application/system pre-screening was developed for a major service provider. This one looked at two key elements: the sensitivity of the information being handled and the criticality of the system being run. Where the impact analysis process used Low, Medium, and High, this process had ve values, as shown in Exhibits 6.3 and 6.4. This number is due to the fact that the service provider had ve levels of information classication in its policy. If the client answers a 1 or a 2 to either question, then a formal risk analysis and business impact analysis must be conducted. If the answer to both questions is 3, 4, or 5, then they are asked two additional questions. The key to the pre-screening process is to get input from the department that understands the threshold levels and impacts on the enterprise. This process, if properly established, will allow the business units to bypass unneeded control mechanisms while still providing an appropriate level of security. Being able to build on the information that has gone before allows one to create a risk management program that will be cost-effective and acceptable to the user community. Nothing will cause quicker success faster implementing processes that cut down on the number of controls and making the process easy to perform. The remainder of this chapter examines two more uses of qualitative risk analysis by exploring its use in Business Impact Analysis (BIA). It becomes clear that qualitative risk analysis usage is restricted only to what one can think of to do with it.
Business Impact Analysis

The principal objective of the Business Impact Analysis (BIA) is to determine the effect of mission-critical information system failures on the viability and operations of enterprise core business processes. By using all of the techniques discussed in this book, one should be able to create a facilitated process for
94
Exhibit 6.2 Pre-screening Financial Questions

Customer Impact: Number of Customers Impacted Regulatory/ Compliance Impact Financial Impact: Daily Dollar Amount of Transactions Processed
Impact Value
Project Cost: Total Approved Budget
High $1$49 million $1 million or less Less than $1000 $1000 to $9999 Limited nancial penalties
$1.5 million or more
$50 million or more
$10,000 or more
Substantial nancial penalties No regulatory or compliance issues
Medium
$500,001$1.5 million
Low
$500,000 or less
Exhibit 6.3 Pre-screening Example 2

Longest Tolerable Outage
Impact Value
Information Classication
Top Secret Information that, if disclosed, could cause severe impact to the companys competitive advantage or business strategies
24 hours or less
Condential Information that, if disclosed, could violate the privacy of individuals, reduce competitive advantage, or damage the company
2572 hours
Restricted Information that is available to a specic subset of the employee population when conducting company business
73 hours5 days
Internal use Information that is intended for use by all employees when conducting business
69 days 10 days or more
Public Information that has been made available to the public through authorized company channels
95
Exhibit 6.4
Impact Value
Pre-screening Example 2: Second Set of Questions

Contractual Obligations
Disclosure
1 2 3 4 5
National or international press coverage State or local press coverage Incident known throughout the company Incident known only at the division or department level Little or no impact
Unable to meet external obligations Delay in meeting external obligations Unable to meet internal obligations Delay in meeting internal obligations Little or no impact
BIA. Once the critical resources are scored, the organization can then identify appropriate controls to ensure that the business continues to meet its business objectives or mission. Similar to the use of scoring tables developed with the assistance of other departments, the BIA works the same process. The enterprise must determine what elements are important and then develop a process to score those elements. The BIA uses those tables to examine the business processes, establish their priorities, and what other processes are dependent on them. As discussed in Chapter 2, there are a number of elements that can be considered in the BIA process. Tables created for use in Chapter 2 included Enterprise Embarrassment, Value to Competitor, Legal Implication, Cost of Disruption, and Financial Loss. The BIA process reviewed here takes similar tables and modies them to meet a particular business requirements. Part of the BIA process comes from the risk analysis process itself. When reviewing system and application availability, the results of this process will lead the business manager to see the need for a BIA. The process will review the business areas for vulnerability, such items as cash ow, telecommunication systems, computer operations, or critical dependencies. Exhibit 6.5 shows an example of a typical BIA element schedule. In this example, the developers determined that there are ve key elements that need to be assessed to determine the relative criticality between systems and applications. These elements are: 1. 2. 3. 4. 5. time criticality health and safety customer satisfaction embarrassment nancial
For time criticality, the team asked the user community two questions. How long can the system be down before business operations are impacted?
96
Exhibit 6.5
Intangible Loss (dollar loss difcult to estimate) Health and Safety Customer Satisfaction (dissatised customers) Embarrassment (comes to the attention of)
BIA Loss Impact Table

Tangible Loss Financial
Time Sensitivity
Impact Value
Longest Tolerable Outage Period during Peak
24 hours or less
Loss of multiple lives Loss of life 100,001500K Local or state press organization
More than 500,000
National or international press organization
More than $10M $1,000,001 $10M $100,001 $1M
2572 hours
3 Major exposure to unsafe work environment Little or no negative impact Minor exposure to unsafe work environment 01K 100110K
73 hours5 days
Serious injury
10,001100K
Company organization Company division
69 days
$50,001 $100K Few if anyone Company group $0$50K
10 days or more
97
This question would normally generate a response measured in hours. The second question asked would be: what is the longest period of time you have been unable to access the system or application? The typical response would normally generate a response of days (e.g., two to three days). Thus, the real time criticality is somewhere between X number of hours and X number of days. For health and safety issues, the team met with the Health and Safety unit and discussed with them the levels of concern for the review. This enterprise wanted to stick strictly to health and safety issues of employees. The team and the department were able to quickly determine element 1 and element 5 and then were able to work through the other three elements. As a note, the BIA team selected 5 as the value range because they were developing the business continuity plan and were driven by the recovery category for each application and system. Category 5 would have to be recovered in 24 hours or less and category 1 in ten days or more. To facilitate the business continuity plan software, they decided to go with ve levels. One should use the number of levels that make the most sense for a particular enterprise. The customer satisfaction levels were established through discussions with the customer liaison staff. This group handled customer requests and had data on thresholds of complaint levels. Corporate embarrassment was reviewed with the legal staff and the corporate communications (public relations) units. These groups can help quantify when enough is enough. Finally, the nancial staff is interviewed to determine how much is enough. To assist in this process, a nancial impact worksheet (see Exhibit 6.6) is developed. There are some problems with the gures that this will generate. The worksheet takes into account the effects of outages during the most critical time of the business cycle for each business process. Thus, the value obtained from the review includes loss of sales in addition to other costs of doing business in an outage situation. The total business impact from each of these sheets can add up to more than the revenue generated in annual sales by the enterprise. While this gure may be correct, it will require some quick discussion to make management understand that an outage of ten days can lead to losses beyond the annual gross income. One must be very careful as to how one uses the gures generated from a worksheet such as this. This author recommends that the rst value to be presented to management for one days outage be something along the lines of the total gross revenue divided by 260 (the typical number of working days in a year). Thus, if the enterprise has an annual gross income of $50 million, then the rst days losses would equal ($50,000,000 / 260 = $192,307.69). Once an understanding of annual revenues has been established, then one can discuss the increasing costs of being out of business. Once the values for each element are determined for each business process affected by the application or system, then those gures are plugged into a table like the one seen in Exhibit 6.7.
98 Exhibit 6.6 Financial Impact Worksheet
Type of Impact
Estimated Dollar Loss if Unavailable Just Beyond Longest Tolerable Outage Period
Loss of sales Regulatory nes Legal nes Cost of money (Ex. revenue collection delayed) Loss of competitive advantage Loss of investor condence Loss of customer condence Adverse public opinion Reporting delay (nancial reports, etc.) Cost of disruption to business Replacement of employees Elimination of work backlog Use of alternate procedures Loss of productive time Replacement of lost information Equipment repair or replacement Decreased employee morale Operating delay
BIA Conclusion
Business Impact Analysis is an example of what can be done once the basics of qualitative risk analysis are mastered. The only limit imposed is what one can think of to use the process for.
Conclusion
The uses of qualitative risk analysis are limited only by what one can think of to do. The pre-screening process can provide the information security or audit group with some important image enhancements when the business units see how important it is to smooth out the business cycle. The goal of an effective risk management process is to implement controls only where necessary.
Exhibit 6.7 BIA Worksheet

Business Loss Impact Value
Time Cirticality
Peak Activity Period Health & Safety Embarrassment (Impact Value) (Impact Value) (Impact Value) Customer Satisfaction Is It Likely that an Outage Can Delay Installation, Delivery, Restoration, or Interrupt Service? (Yes = 1, No = 0)
Key Business Processes or Business Functions Supported by the Application/System
Longest Tolerable Outage Period During Peak
Financial (Impact Value)
(Name)
(Day of Wk, Wk of Mon, Mon of Yr)
(Impact Value)*
Weight =
Minimum Impact Score = NO Total Impact Score = 0.00
Interrupt Service?
99
100
Risk analysis is not done to fulll audit requirements. It is not done because Information Security mandated it. It is not done to be in compliance with laws and regulations. Risk analysis is done because it makes sound business sense. Being able to identify the assets of the organization, and determine what threats are out there and what safeguards are available, ensure that the limited resources of any organization will be put where they will do the most good. Risk analysis supports the business objectives or mission of the enterprise and is conducted because it will improve the bottom line. Risk analysis is an essential component in the successful management of any organization. It is a process that must start from the inception of the project, and continue until the application or system is completed and its expected benets have been realized. Risk analysis must focus on the areas of highest risk within the scope of the review, with continual monitoring of other areas of the project to identify any new or escalating risks. The success of a risk analysis strategy therefore depends on: the commitment of senior management the skills and experience of the risk management team in the identication of risks and the development of effective risk controls the risk management team and the business unit working closely together to identify and manage information asset risks the risk analysis process being ongoing the use of a consistent risk analysis process regular reporting of performance of safeguards meeting the needs of the organization
Chapter 7
Case Study
To best understand the concepts discussed in Chapter 5 on the Facilitated Risk Analysis Process (FRAP), I nd it best to work a case study to reinforce the concepts. What is laid out in this chapter is a scenario about an enterprise and then the elements of a FRAP and what steps must be taken when. Exhibits 7.1 through 7.5 are completed summary forms for this organization.
Company Outline
Boswerth Enterprises, Inc. Boswerth is a $2 billion transportation company. Boswerth has a consumer business that rents trucks to individuals through franchise operations and also through company-owned facilities. Boswerth also has a commercial business that rents trucks to other companies, on both long- and short-term bases. The consumer business is in a multitude of places, from fairly large storefront operations to the backlot of gas stations, and rentals are handled via a dial-up system. All rentals are handled via an online system (U Rent It System [URIS]). The commercial business is run through three major ofce locations, each containing a major data center: Princeton, New Jersey Houston, Texas Monrovia, California
101
102 Exhibit 7.1 Scope/Business Process Identication
Application/System: U Rent It System (URIS) Pre-FRAP Date: 1/8/2001
The project leader and information/application/system owner are told in the pre-FRAP meeting what is meant by a Scope Statement and Key Business Processes. They dene the scope and identify the business processes after the pre-FRAP meeting and record them here. Denition: SCOPE STATEMENT
Denition: A Key Business Process is any high-level business process that relies on information supplied by the application/system described above. KEY BUSINESS PROCESSES Business Process 1 Business Process 2 Business Process 3 Business Process 4 Business Process 5
Exhibit 7.2
FRAP Date: 1/8/2001
Action Plan
Case Study
Application: U Rent It System (URIS)
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
Information accessed by personnel not intended to have access
INT
3, 5, 6, 11, 12, 16
ACF2 has been implemented and the access control list will be reviewed to identify authorized users Change management procedures already in place Operations complete
Owner & IP
7/15/2000
Unclear or nonexistent versioning of the information D
INT
9, 13, 26
Database could be corrupted by hardware failure, incorrect, bad software C
INT
Data could be corrupted by an incomplete transaction C
INT
Ability to change data in transit and then changing it back in order to cover the activity A 7, 11, 12, 13, 20, 21
INT
A failure to report integrity issues
INT
Employee training sessions scheduled
HR
8/15/2000 (continues)
103
104
Exhibit 7.2 Action Plan (Continued)

FRAP Date: 1/8/2001
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
Incompletely run process or failure to run a process that could corrupt the data A 7, 13, 17, 20, 23, 25 SLA with service provider to be implemented SLA with service provider to be implemented Owner Owner 8/20/2000
INT
1, 2, 12, 13, 14, 15, 18, 20, 21, 25
Backup SLA to be reviewed with Operations
Owner & Operations
7/31/2000
Lack of internal processes to create and control, manage data across functions A 7, 13, 26
INT
No notication of integrity problems B B 7, 13, 26 11, 12, 19
INT
8/20/2000
10
Information being used in the wrong context
INT
11
Third-party information may have integrity issues A B 11, 12, 13, 19 3, 4, 5
INT
12
Third-party access to information
INT
13
Data updated internally but not being made externally
INT
14
Verication of authentication of originator of request C
INT
Case Study
15
Denied access to information that you are authorized to access B 9, 11, 12, 13, 16, 26 3, 6, 19, 23, 25
INT
16
Impact to business by using information that is incorrect A
INT
17
Security and authorization procedures are so bureaucratic as to hamper the business process B 3, 6
INT
18
Control process so complicated that they are ignored B 11, 12, 13, 19 11, 12, 13, 19, 24
INT
19
Personnel making changes are not adequately trained B
INT
20
Information could be published without proper authorization B
INT
21
INT
105
Corporate embarrassment due to unauthorized changing of information
3, 4, 5, 6, 11, 12, 13, 16, 19, 22, 24 (continues)
106

FRAP Date: 1/8/2001
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
22
Corporate information damaged due to information leakage A 7, 9, 15
INT
23
Not responding to requests in a timely manner B 1, 2, 3, 4, 11, 12, 13, 16 9, 11, 12
INT
24
Internal personnel deliberately modifying data for personal/group gain/reason A
INT
25
E-business integrity policies conict with existing corporate policies B
INT
26
Unwarranted trust in a third-party business partner B 1, 2, 7, 25, 26
INT
27
Unrecorded changes to system/application software or data
INT
Case Study
28
E-business corporate policies cannot be implemented in other countries A B 7, 12, 13, 17, 22 13 7, 8, 9, 26
INT
20
29
Wrong document or data is published
INT
30
Information from partners or suppliers has integrity problems B
INT
31
Audit and/or data integrity legislation causes integrity loss (trans-border) B 3
INT
32
Legal implications to the business due to misuse of trademarks and registration C C B 7, 8, 9, 16, 25
INT
33
Use of an out-of-date copy of the data
INT
34
Synchronization issues using recovery media
INT
35
Incorrect use of the modication process in the application development process (change code without testing)
INT
107
(continues)

FRAP Date: 1/8/2001
108
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
36 B B 8, 13, 23, 25 3, 5, 11, 12, 13, 20 2, 10, 11, 12, 13
Old data or documents are not removed
INT
37
Modication of data due to virus introductions
INT
38
E-business product is not designed to meet user expectations A
INT
39
Timely reporting in status of users, customers, suppliers, developers, etc. B 8, 13, 23, 25
INT
40
Unclear strategy from the business to support the use of E-business transactions B 11, 12, 13, 23
INT
41
Incomplete or nonexistent clear documentation dening or qualifying the information B 7, 11, 12, 13, 23,
INT
Information/data is incorrectly labeled
CON
Case Study
2 B B 11, 12 11, 12, 13
Shoulder-surng of information
CON
Information/data is incorrectly classied
CON
Information/data is shared before it is released through proper channels C
CON
Access to customer, employee, or partner supplier lists are made available unknowingly A A 7, 10 4, 7, 13, 16, 20
CON
Ex-developers still have access to secure data
CON
Use of insecure systems to transmit sensitive information/data B 11, 12, 23
CON
Disclosure of information and violation of the privacy laws A B 6, 11, 12, 13, 25 4, 6, 22, 24
CON
Information on laptops is unprotected
CON
10
Complex processes for enabling secure e-mail capability
CON
109
(continues)

FRAP Date: 1/8/2001
110
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
11
Government legislation prevents proper protection of sensitive information B B 11, 12, 13
CON
12
Clear denition of condentiality rules
CON
13
Inability of the company to access condential information between two parties at a later time C A
CON
14
Improper protection of password lists
CON
15
Uncontrolled access to printed condential information B
CON
16
Introduction of back doors into software, data, and applications B 7, 8, 11, 12, 25
CON
17
Sensitive and nonsensitive information are mixed
CON
Case Study
18
Disgruntled admin staff with high security privileges B
CON
19
Downstream effects are not thoroughly analyzed before a change is applied A 3, 11, 12, 13 3, 11, 12, 13 3, 11, 12, 13 3, 11, 12, 13 7, 11, 12, 13, 15, 19, 23
CON
20
Allocation of security privileges not known to the organization A
CON
21
Removal of access to the developers after the project is complete A B
CON
22
Trade secrets are sold without detection
CON
23
Distribution lists have personnel who are not authorized B
CON
24
Wrong use of the security administration procedures in applications with sensitive information A 3, 4, 5, 6, 13, 16
CON
25
Authentication for access to sensitive information is inadequate
CON
111
(continues)
112

FRAP Date: 1/8/2001
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
26
Collection of information in one place can cause condentiality issues A B 3, 4, 13, 16 3, 5, 6, 7, 13, 16
CON
27
Ability to assume anothers identity
CON
28
Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally) C
CON
29
Assumption that developers require access to sensitive information B 3, 5, 13, 16
CON
30
Access to sensitive information through the test environment C
CON
31
Individuals are unaware how to publish or store information on the Web
CON
32
Confusion over where to store sensitive information B 11, 12, 13, 19, 20
CON
11, 12, 13, 19
Case Study
33
Unclear/unknown process for classifying data C
CON
34
Granting access to individuals who do not have a business need for access B 7, 13, 15
CON
35
Information about internal systems is inadvertently released for potential later attacks B B B 3, 7, 13 14, 20, 22 12
CON
36
Sharing userIDs
CON
37
Access to backups is not properly controlled
CON
38
Broad security access is granted for simplication sake B A 9, 12, 13, 15, 26 23
CON
39
Condentiality contracts are unenforceable
CON
40
Personal information for staff might be posted on the Internet without authorization
CON
113
(continues)
114

FRAP Date: 1/8/2001
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
41 B 13, 23
False sense of security due to rewall mentality
CON
12, 13, 23
42
Third-party breaks of condentiality agreements A 13, 15, 23
CON
43
Unclear denition of sensitive information in joint-venture activities A 7, 9, 13, 26
CON
44
New technologies leading to breaches of condentiality B 23
CON
45
Effort and planning involved in changing a security access model B 12
CON
46
How to explain condentiality to nonemployees
CON
Case Study
47
Loss of sales and increased costs due to release of competitive advantage information without company knowledge B 5, 13
CON
3, 4, 5, 6, 7, 9
48
Packet snifng outside the Internet site by unauthorized personnel C
CON
49
Penalties for condentiality agreement violations not sufcient to deter inappropriate activities B 3, 5, 6, 7, 9
CON
50
Electronic eavesdropping of company sites B 1, 2, 3, 5, 6, 10, 21, 22, 22
CON
Hackers could bring site down B
AVA
Intruders gaining physical access to computer facilities C
AVA
Hardware failure of the Internet server
AVA
115
(continues)
116

FRAP Date: 1/8/2001
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
4 B 20, 22
Communication provider service outage
AVA
Hosting site lacks physical protection of information B 8, 12, 17
AVA
Manual process fails when E-commerce site is unavailable C B B 8, 9 25
AVA
Links to back ofce systems fail
AVA
Overly complex system design
AVA
Incorrectly made hardware or software changes B 20, 25
AVA
10
Unanticipated volumes/usage projections B 1, 2, 8, 14, 20, 21
AVA
11
Contingency planning procedures not tested
AVA
12
No guarantee of server availability by service provider D B 18, 20, 21
AVA
Case Study
13
Industrial action/strike at service provider
AVA
14
Normal planned maintenance will cause system unavailability C
AVA
15
Topology design precludes effective/acceptable global service availability C A C B 13, 18, 20 3, 5, 10, 16, 22
AVA
16
Inadequate funding for backup capability
AVA
17
Planned attack by protesters
AVA
18
Business partner unavailability
AVA
19
Hardware conguration is inadequate for high availability B B 13, 20 12, 15
AVA
20
Technical resources lack proper training
AVA
21
AVA
117
Congestion on the Internet causes user dissatisfaction
(continues)

FRAP Date: 1/8/2001
118
Risk #
Risk
Type
Priority
Controls
Owner Action
By Who
When
Additional Comments
22
Applications design aws may cause resource thrashing or internal resource contention B 12, 13, 20
AVA
23
Critical application may not be critical to service provider C
AVA
24
E-commerce application is designed to work with only a limited set of clients A 1, 2, 10
AVA
25
Introduction of virus may cause system/information unavailability B 13, 20
AVA
26
Insufcient monitoring of Web site may fail to report unavailability B 13, 18, 20, 22
AVA
27
Router or rewall failure may cause inaccessibility to services
AVA
28 A 13, 18, 20, 21
Backups are insufcient
AVA
Case Study
29
Loss of customers due to site unavailability
AVA
There were no deferred issues
Deferred Issue
Deferred Issue
Deferred Issue
Deferred Issue
Deferred Issue
119
120 Exhibit 7.3

Date: To:
Final Report
(enter date) Mr. Owner IS Security Center of Excellence (SCoE) Manager Owner/Owners Representative Ms. Facilitator IS Information Management Center of Excellence (IMCoE) Manager Facilitated Risk Analysis
From: Subject:
The Information Protection group facilitated a Risk Analysis session on the functionality named below. The Risk Analysis attendees identied the risks and controls shown on the attached Action Plan. The attendees included you, or your representative, to ensure that the concerns of your organization were properly addressed. The Action Plan shows which of the controls identied during the Risk Analysis have been, or will be implemented. You should have made the decisions as to if and when the controls will be implemented. FRAP Date: 1/8/2001
System/Application: U Rent It System (URIS) Owner: Facilitator: Mr. Owner Ms. Facilitator
Please read the Statement of Understanding below, sign it, and return it to me. STATEMENT OF UNDERSTANDING: I, the Owner, understand that the risks identied on the attached Risk Analysis Action Plan could cause the integrity, condentiality, and/or availability of this system/applications information to be negatively impacted. I have decided to implement the controls according to the schedule on the attached Risk Analysis Action Plan. I understand that any risks which are not controlled could adversely affect corporate information and company business. I am aware that a copy of the Risk Analysis Action Plan will be forwarded to the Audit organization. ______________________________________________________ Owner/Owners Representative IS Security Center of Excellence (SCoE) Manager ______________________________________________________ IS Information Management Center of Excellence (IMCoE) Manager _________________________ Date _________________________ Date
Case Study
121
Exhibit 7.4. Controls List

Backup
Backup requirements will be determined and communicated to the service provider, including a request that an electronic notication that backups were completed be sent to the application system administrator. The service provider will be requested to test the backup procedures. Develop, document, and test, recovery procedures designed to ensure that the application and information can be recovered, using the backups created, in the event of loss. Implement an access control mechanism to prevent unauthorized access to information. This mechanism will include the capability of detecting, logging, and reporting attempts to breach the security of this information. Access sourced: Implement a mechanism to limit access to condential information to specic network paths or physical locations. Implement user authentication mechanisms (such as rewalls, dial-in controls, secure ID) to limit access to authorized personnel. Implement encryption mechanisms (data, end-toend) to prevent unauthorized access to protect the integrity and condentiality of information. Design and implement application controls (data entry edit checking, elds requiring validation, alarm indicators, password expiration capabilities, checksums) to ensure the integrity, condentiality, and availability of application information. Develop testing procedures to be followed during applications development and during modications to the existing application that include user participation and acceptance. Adhere to a change management process designed to facilitate a structured approach to modications, to ensure appropriate steps and precautions are followed. Emergency modications should be included in this process, (continues)
Recovery Plan
Access Control
Access Control
Access Control
Access Control
Application Control
Acceptance Testing
Change Management
122
Exhibit 7.4. Controls List (Continued)

10
Anti-virus
1) Ensure LAN administrator installs the corporate standard anti-viral software on all computers. 2) Training and awareness of virus prevention techniques will be incorporated in the organization IP program. Develop policies and procedures to limit access and operating privileges to those with business need. User training will include instruction and documentation on the proper use of the application. The importance of maintaining the condentiality of user accounts, passwords, and the condential and competitive nature of information will be stressed. Implement mechanisms to monitor, report, and audit activities identied as requiring independent reviews, including periodic reviews of userIDs to ascertain and verify business need. Operations controls: Training for a backup to the system administrator will be provided and duties rotated between them to ensure the adequacy of the training program. Operations controls: Application developers will provide documentation, guidance, and support to the operations staff (service provider) in implementing mechanisms to ensure that the transfer of information between applications is secure. Operations controls: Mechanisms to protect the database against unauthorized access, and modications made from outside the application, will be determined and implemented. Operations controls: Systems that feed information will be identied and communicated to the service provider to stress the impact to the functionality if these feeder applications are unavailable. Operations controls: Time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants.
11
Policy
12
Training
13
Audit/ Monitor
14
Backup
15
Training
16
Access Control
17
18
Maintenance
Case Study
123
Exhibit 7.4. Controls List (Continued)

19
Training
User controls: Implement user programs (user performance evaluations) designed to encourage compliance with policies and procedures in place to ensure the appropriate utilization of the application. Acquire service level agreements to establish level of customer expectations and assurances from supporting operations. Acquire maintenance or supplier agreements to facilitate the continued operational status of the application. In consultation with facilities management, facilitate the implementation of physical security controls designed to protect the information, software, and hardware required of the system. Request management support to ensure the cooperation and coordination of various business units, to facilitate a smooth transition to the application. Proprietary controls The development team will develop corrective strategies such as reworked processes, revised application logic, etc. Production migration controls such as search and remove processes to ensure data stores are clean.
20
21
22
Physical Security
23
Management Support
24 25
26
Exhibit 7.5 Control/Risks Cross-reference List

Risk Risk Description Type Concern
124
Control
Control Description
Backup requirements will be determined and communicated to the service provider, including a request that an electronic notication that backups were completed be sent to the application system administrator. The service provider will be requested to test the backup procedures. 24 27 1 11 25 7 Hackers could bring site down Contingency planning procedures not tested Introduction of virus may cause system/information unavailability Incompletely run process or failure to run a process that could corrupt the data Internal personnel deliberately modifying data for personal/group gain/reason Unrecorded changes to system/application software or data INT INT AVA AVA AVA INT
Incompletely run process or failure to run a process that could corrupt the data
INT
B B B B A B
Develop, document, and test, recovery procedures designed to ensure that the application and information can be recovered, using the backups created, in the event of loss. 24 27
Internal personnel deliberately modifying data for personal/group gain/reason Unrecorded changes to system/application software or data
INT INT
B B
Case Study
37 1 11 25 1 Information accessed by personnel not intended to have access Introduction of virus may cause system/information unavailability AVA INT Contingency planning procedures not tested AVA Hackers could bring site down AVA B B A B
Modication of data due to virus introductions
INT
Implement an access control mechanism to prevent unauthorized access to information. This mechanism will include the capability of detecting, logging, and reporting attempts to breach the security of this information. 12 17 18 21 24 32 39 Third-party access to information
INT INT INT INT INT INT INT
A A B B B B A
Security and authorization procedures are so bureaucratic as to hamper the business process
Control process so complicated that they are ignored
Corporate embarrassment due to unauthorized changing of information Internal personnel deliberately modifying data for personal/group gain/reason Legal implications to the business due to misuse of trademarks and registration Timely reporting in status of users, customers, suppliers, developers, etc.
Exhibit 7.5 Control/Risks Cross-reference List (Continued)

(continues)
125
Control
Control Description
Risk
Risk Description
Type
Concern
126
20 21 22 23 25 27 28 Ability to assume anothers identity Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally) Access to sensitive information through the test environment Broad security access is granted for simplication in sake Loss of sales and increased costs due to release of competitive advantage information without company knowledge Electronic eavesdropping of company sites Hackers could bring site down Planned attack by protesters Authentication for access to sensitive information is inadequate Distribution lists have personnel who are not authorized Trade secrets are sold without detection CON CON CON CON CON Removal of access to the developers after the project is complete CON A A B A A B
Allocation of security privileges not known to the organization
CON
30 38 47
CON CON CON
B B B
50 1 17
CON AVA AVA
B B A
Case Study
Access sourced: Implement a mechanism to limit access to condential information to specic network paths or physical locations. 21 Corporate embarrassment due to unauthorized changing of information INT B
12
Third-party access to information
INT
22 24 6 9 25 28 Internal personnel deliberately modifying data for personal/group gain/reason Ex-developers still have access to secure data Information on laptops is unprotected Authentication for access to sensitive information is inadequate Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally) Loss of sales and increased costs due to release of competitive advantage information without company knowledge Information accessed by personnel not intended to have access Third-party access to information
Corporate information damaged due to information leakage
INT INT CON CON CON CON
B B A A A B
47
CON
Implement user authentication mechanisms (such as rewalls, dial-in controls, secure ID) to limit access to authorized personnel. 12
INT
INT
A (continues)
127

128
Control
Control Description
21 39 25 27 30 47 Ability to assume anothers identity Access to sensitive information through the test environment Loss of sales and increased costs due to release of competitive advantage information without company knowledge Packet snifng outside the Internet site by unauthorized personnel Electronic eavesdropping of company sites Hackers could bring site down Planned attack by protesters Information accessed by personnel not intended to have access Authentication for access to sensitive information is inadequate Timely reporting in status of users, customers, suppliers, developers, etc. INT CON CON CON CON
INT
B A A A B B
48 50 1 17 1
CON CON AVA AVA INT
B B B A B
Implement encryption mechanisms (data, endto-end) to prevent unauthorized access to protect the integrity and condentiality of information. 14
Verication of authentication of originator of request
INT
17 18 21 9 10 25 27 47 Ability to assume anothers identity Loss of sales and increased costs due to release of competitive advantage information without company knowledge Electronic eavesdropping of company sites Hackers could bring site down A failure to report integrity issues Authentication for access to sensitive information is inadequate Complex processes for enabling secure e-mail capability Information on laptops is unprotected CON CON CON CON CON Corporate embarrassment due to unauthorized changing of information INT B A B A A B Control process so complicated that they are ignored INT B
Security and authorization procedures are so bureaucratic as to hamper the business process
INT
Case Study
50 1 6
CON AVA INT
B B A
Design and implement application controls (data entry edit checking, elds requiring validation, alarm indicators, password expiration capabilities, checksums) to ensure the integrity, condentiality, and availability of application information. 8 9
Lack of internal processes to create and control, manage data across functions No notication of integrity problems
INT INT
129
A (continues)

130
Control
Control Description
11 23 27 29 30 35 Information from partners or suppliers has integrity problems Incorrect use of the modication process in the application development process (change code without testing) Information/data is incorrectly labeled Ex-developers still have access to secure data Use of insecure systems to transmit sensitive information/data Sensitive and nonsensitive information are mixed Wrong use of the security administration procedures in applications with sensitive information Ability to assume anothers identity Wrong document or data is published Unrecorded changes to system/application software and/or data INT INT INT INT Not responding to requests in a timely manner INT
Third-party information may have integrity issues
INT
B A B A B B
1 6 7 17 24
CON CON CON CON CON
B A A B B
27
CON
35 38 44 47 Loss of sales and increased costs due to release of competitive advantage information without company knowledge Electronic eavesdropping of company sites Wrong document or data is published New technologies leading to breaches of condentiality CON CON Broad security access is granted for simplication in sake CON B A B
Information about internal systems is inadvertently released for potential later attacks
CON
Case Study
50 29
CON INT
B A
Develop testing procedures to be followed during applications development and during modications to the existing application that include user participation and acceptance. 35
Incorrect use of the modication process in the application development process (change code without testing) E-business product is not designed to meet user expectations Unclear strategy from the business to support the use of E-business transactions Sensitive and nonsensitive information are mixed Manual process fails when E-commerce site is unavailable
INT
38 40 17 6
INT INT CON AVA
B B B B
131
(continues)

132
Control
Control Description
9 11 2 Unclear or nonexistent versioning of the information INT Contingency planning procedures not tested AVA
Incorrectly made hardware or software changes
AVA
B B B
Adhere to a change management process designed to facilitate a structured approach to modications, to ensure appropriate steps and precautions are followed. Emergency modications should be included in this process. 16 23 25 29 35 Impact to business by using information that is incorrect Not responding to requests in a timely manner E-business integrity policies conict with existing corporate policies Wrong document or data is published Incorrect use of the modication process in the application development process (change code without testing) Personal information for staff might be posted on the Internet without authorization New technologies leading to breaches of condentiality
INT INT INT INT INT
B A A A B
40 44
CON CON
A A
47
Loss of sales and increased costs due to release of competitive advantage information without company knowledge Electronic eavesdropping of company sites Incorrectly made hardware or software changes Modication of data due to virus introductions INT AVA CON B B B
CON
Case Study
50 9 37
10
1) Ensure LAN administrator installs the corporate standard anti-viral software on all computers. 2) Training and awareness of virus prevention techniques will be incorporated in the organization IP program. 7 1 17 25 1 Planned attack by protesters Introduction of virus may cause system/information unavailability Information accessed by personnel not intended to have access A failure to report integrity issues Information being used in the wrong context Data updated internally but not being made externally Hackers could bring site down Use of insecure systems to transmit sensitive information/data
CON AVA AVA AVA INT
A B A A B
11
Develop policies and procedures to limit access and operating privileges to those with business need. 6 10 13
INT INT INT
A B B
133
(continues)

134
Control
Control Description
16 19 20 21 24 25 37 39 41 Corporate embarrassment due to unauthorized changing of information Internal personnel deliberately modifying data for personal/group gain/reason E-business integrity policies conict with existing corporate policies Modication of data due to virus introductions Timely reporting in status of users, customers, suppliers, developers, etc. Incomplete or nonexistent of clear documentation dening or qualifying the information Information/data is incorrectly labeled Information/data is incorrectly classied Information/data is shared before it is released through proper channels Information could be published without proper authorization Personnel making changes are not adequately trained INT INT INT INT INT INT INT INT
Impact to business by using information that is incorrect
INT
B B B B B A B A B
1 3 4
CON CON CON
B B B
Case Study
8 10 12 17 20 21 22 23 24 Allocation of security privileges not known to the organization Removal of access to the developers after the project is complete Trade secrets are sold without detection Distribution lists have personnel who are not authorized Wrong use of the security administration procedures in applications with sensitive information Confusion over where to store sensitive information Unclear/unknown process for classifying data Sensitive and nonsensitive information are mixed Clear denition of condentiality rules CON CON CON CON CON CON CON Complex processes for enabling secure e-mail capability CON B B B A A A B B
Disclosure of information and violation of the privacy laws
CON
32 33
CON CON
B B
(continues)
135

136
Control
Control Description
12
User training will include instruction and documentation on the proper use of the application. The importance of maintaining the condentiality of user accounts, passwords, and the condential and competitive nature of information will be stressed. 6 7 10 13 16 19 20 21 24 A failure to report integrity issues Incompletely run process or failure to run a process that could corrupt the data Information being used in the wrong context Data updated internally but not being made externally Impact to business by using information that is incorrect Personnel making changes are not adequately trained Information could be published without proper authorization Corporate embarrassment due to unauthorized changing of information Internal personnel deliberately modifying data for personal/group gain/reason INT INT INT INT INT INT INT INT INT
Information accessed by personnel not intended to have access
INT
A B B B B B B B B
25 30 37 39 41 Incomplete or nonexistent of clear documentation dening or qualifying the information Information/data is incorrectly labeled Information/data is incorrectly classied Information/data is shared before it is released through proper channels Disclosure of information and violation of the privacy laws B and complex processes for enabling secure e-mail capability Clear denition of condentiality rules Sensitive and nonsensitive information are mixed Allocation of security privileges not known to the organization Removal of access to the developers after the project is complete Timely reporting in status of users, customers, suppliers, developers, etc. INT INT Modication of data due to virus introductions INT B A B Information from partners or suppliers has integrity problems INT B
E-business integrity policies conict with existing corporate policies
INT
Case Study
1 3 4 8 10 12 17 20 21
CON CON CON CON CON CON CON CON CON
B B B B B B B A A
137
(continues)

138
Control
Control Description
22 23 24 Wrong use of the security administration procedures in applications with sensitive information Confusion over where to store sensitive information Unclear/unknown process for classifying data Sharing userIDs Personal information for staff might be posted on the Internet without authorization False sense of security due to rewall mentality How to explain condentiality to nonemployees Manual process fails when E-commerce site is unavailable Technical resources lack proper training Critical application may not be critical to service provider CON Distribution lists have personnel who are not authorized CON
Trade secrets are sold without detection
CON
A B B
32 33 36 40 41 46 6 20 23
CON CON CON CON CON CON AVA AVA AVA
B B B A A B B B B
Case Study
13
Implement mechanisms to monitor, report, and audit activities identied as requiring independent reviews, including periodic reviews of userIDs to ascertain and verify business need. 6 7 8 9 11 13 16 19 20 21 24 No notication of integrity problems Third-party information may have integrity issues Data updated internally but not being made externally Impact to business by using information that is incorrect Personnel making changes are not adequately trained Information could be published without proper authorization Corporate embarrassment due to unauthorized changing of information Internal personnel deliberately modifying data for personal/group gain/reason Lack of internal processes to create and control, manage data across functions Incompletely run process or failure to run a process that could corrupt the data A failure to report integrity issues INT INT INT INT INT INT INT INT INT INT INT A B A A B B B B B B B
Unclear or non-existent versioning of the information
INT
139
(continues)
Exhibit 7.5 Control/Risks Cross-reference List (Continued) 140

Control
Control Description
30 31 37 38 39 40 41 E-business product is not designed to meet user expectations Timely reporting in status of users, customers, suppliers, developers, etc. Unclear strategy from the business to support the use of E-business transactions Incomplete or nonexistent of clear documentation dening or qualifying the information Information/data is incorrectly labeled Information/data is incorrectly classied Ex-developers still have access to secure data B and complex processes for enabling secure e-mail capability Clear denition of condentiality rules Allocation of security privileges not known to the organization Modication of data due to virus introductions INT INT INT INT INT Audit or data integrity legislation causes integrity loss (trans-border) INT B B B A B B
Information from partners or suppliers has integrity problems
INT
1 3 6 10 12 20
CON CON CON CON CON CON
B B A B B A
Case Study
21 22 23 24 Wrong use of the security administration procedures in applications with sensitive information Authentication for access to sensitive information is inadequate Ability to assume anothers identity Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally) Access to sensitive information through the test environment Confusion over where to store sensitive information Unclear/unknown process for classifying data Information about internal systems is inadvertently released for potential later attacks Broad security access is granted for simplied in sake CON Distribution lists have personnel who are not authorized CON Trade secrets are sold without detection CON A B B
Removal of access to the developers after the project is complete
CON
25 27 28
CON CON CON
A A B
30 32 33 35 38
CON CON CON CON CON
B B B B B
141
(continues)

142
Control
Control Description
40 41 42 43 44 48 19 21 23 26 27 29 New technologies leading to breaches of condentiality Packet snifng outside the Internet site by unauthorized personnel Hardware conguration is inadequate for high availability Congestion on the Internet causes user dissatisfaction Critical application may not be critical to service provider Insufcient monitoring of Web site may fail to report unavailability Router or rewall failure may cause inaccessibility to services Loss of customers due to site unavailability Unclear denition of sensitive information in joint-venture activities Third party breaks of condentiality agreements CON CON CON CON AVA AVA AVA AVA AVA AVA False sense of security due to rewall mentality CON
Personal information for staff might be posted on the Internet without authorization
CON
A A B A A B B B B B B A
14
Operations controls: Training for a backup to the system administrator will be provided and duties rotated between them to ensure the adequacy of the training program. 37 11 7 Incompletely run process or failure to run a process that could corrupt the data Contingency planning procedures not tested AVA INT Access to backups is not properly controlled CON B B B
Incompletely run process or failure to run a process that could corrupt the data
INT
Case Study
15
Operations controls: Application developers will provide documentation, guidance, and support to the operations staff (service provider) in implementing mechanisms to ensure that the transfer of information between applications is secure. 23 24 Not responding to requests in a timely manner Wrong use of the security administration procedures in applications with sensitive information Information about internal systems is inadvertently released for potential later attacks Personal information for staff might be posted on the Internet without authorization Unclear denition of sensitive information in joint-venture activities
INT CON
A B
35 40 43
CON CON CON
B A A
143
(continues)
144

Control
Control Description
20 1 Information accessed by personnel not intended to have access INT
Technical resources lack proper training
AVA
B B
16
Operations controls: Mechanisms to protect the database against unauthorized access, and modications made from outside the application, will be determined and implemented. 16 21 24 35 Impact to business by using information that is incorrect Corporate embarrassment due to unauthorized changing of information Internal personnel deliberately modifying data for personal/group gain/reason Incorrect use of the modication process in the application development process (change code without testing) Ex-developers still have access to secure data Authentication for access to sensitive information is inadequate Ability to assume anothers identity Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally) INT INT INT INT
B B B B
6 25 27 28
CON CON CON CON
A A A B
Case Study
30 17 8 Lack of internal processes to create and control, manage data across functions INT Planned attack by protesters AVA A A
Access to sensitive information through the test environment
CON
17
Operations controls: Systems that feed information will be identied and communicated to the service provider to stress the impact to the functionality if these feeder applications are unavailable. 30 6 7 Information from partners or suppliers has integrity problems Manual process fails when E-commerce site is unavailable Incompletely run process or failure to run a process that could corrupt the data
INT AVA INT
B B B
18
Operations controls: Time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants. 14 19 27 29
Normal planned maintenance will cause system unavailability Hardware conguration is inadequate for high availability Router or rewall failure may cause inaccessibility to services Loss of customers due to site unavailability
AVA AVA AVA AVA
B B B A
145
(continues)
146

Control
Control Description
19
User controls: Implement user programs (user performance evaluations) designed to encourage compliance with policies and procedures in place to ensure the appropriate utilization of the application. 13 17 19 20 21 24 Data updated internally but not being made externally Security and authorization procedures are so bureaucratic as to hamper the business process Personnel making changes are not adequately trained Information could be published without proper authorization Corporate embarrassment due to unauthorized changing of information Wrong use of the security administration procedures in applications with sensitive information Confusion over where to store sensitive information Unclear/unknown process for classifying data INT INT INT INT INT CON
10
Information being used in the wrong context
INT
B A B B B B
32 33
CON CON
B B
20
Acquire service level agreements to establish level of customer expectations and assurances from supporting operations. 7 8 28 39 6 33 37 5 10 11 14 19 Timely reporting in status of users, customers, suppliers, developers, etc. Ex-developers still have access to secure data Unclear/unknown process for classifying data Access to backups is not properly controlled Hosting site lacks physical protection of information Unanticipated volumes/usage projections Contingency planning procedures not tested Normal planned maintenance will cause system unavailability Hardware conguration is inadequate for high availability E-business corporate policies cannot be implemented in other countries Lack of internal processes to create and control, manage data across functions INT INT INT CON CON CON AVA AVA AVA AVA AVA Incompletely run process or failure to run a process that could corrupt the data INT B A A A A B B B B B B B
A failure to report integrity issues
INT
Case Study
147
(continues)
148

Control
Control Description
21 23 26 27 29 6 Router or rewall failure may cause inaccessibility to services Loss of customers due to site unavailability A failure to report integrity issues Insufcient monitoring of Web site may fail to report unavailability Critical application may not be critical to service provider AVA AVA AVA AVA INT
Congestion on the Internet causes user dissatisfaction
AVA
B B B B A A
21
Acquire maintenance or supplier agreements to facilitate the continued operational status of the application. 7 1 11 14 29
Incompletely run process or failure to run a process that could corrupt the data Hackers could bring site down Contingency planning procedures not tested Normal planned maintenance will cause system unavailability Loss of customers due to site unavailability
INT AVA AVA AVA AVA
B B B B A
22
In consultation with facilities management, facilitate the implementation of physical security controls designed to protect the information, software, and hardware required of the system. 30 9 37 1 2 5 17 27 8 Planned attack by protesters Router or rewall failure may cause inaccessibility to services Lack of internal processes to create and control, manage data across functions Hackers could bring site down Intruders gaining physical access to computer facilities Hosting site lacks physical protection of information Access to backups is not properly controlled Information on laptops is unprotected CON CON AVA AVA AVA AVA AVA INT Information from partners or suppliers has integrity problems INT B A B B B B A B A
21
INT
Case Study
23
Request management support to ensure the cooperation and coordination of various business units, to facilitate a smooth transition to the application. 17 38
Security and authorization procedures are so bureaucratic as to hamper the business process E-business product is not designed to meet user expectations
INT INT
A B
149
(continues)

150
Control
Control Description
40 41 Incomplete or non-existent of clear documentation dening or qualifying the information Information/data is incorrectly labeled Disclosure of information and violation of the privacy laws Wrong use of the security administration procedures in applications with sensitive information Condentiality contracts are unenforceable False sense of security due to rewall mentality Third-party breaks of condentiality agreements Unclear denition of sensitive information in joint-venture activities Effort and planning involved in changing a security access model Information could be published without proper authorization Corporate embarrassment due to unauthorized changing of information CON CON CON INT
Unclear strategy from the business to support the use of E-business transactions
INT
B B
1 8 24
B B B
39 41 42 43 45 20 21
CON CON CON CON CON INT INT
B A B A B B B
24
Proprietary Controls
9 7 Incompletely run process or failure to run a process that could corrupt the data Lack of internal processes to create and control, manage data across functions Security and authorization procedures are so beaurocratic as to hamper the business process Unrecorded changes to system/application software or data Incorrect use of the modication process in the application development process (change code without testing) E-business product is not designed to meet user expectations Unclear strategy from the business to support the use of eBusiness transactions B and complex processes for enabling secure e-mail capability Sensitive and nonsensitive information are mixed Overly complex system design Unanticipated volumes/usage projections INT INT INT INT INT B
Information on laptops is unprotected
CON
Case Study
25
The development team will develop corrective strategies, such as reworked processes, revised application logic, etc. 8 17 27 35
A A B B
38 40 10 17 8 10
INT INT CON CON AVA AVA
B B B B B B
151
(continues)
152

Control
Control Description
26
Production migration controls such as search and remove processes to ensure data stores are clean 9 11 16 27 29 40 44 Unrecorded changes to system/application software or data Wrong document or data is published Personal information for staff might be posted on the internet without authorization New technologies leading to breaches of condentiality Third-party information may have integrity issues Impact to business by using information that is incorrect No notication of integrity problems INT INT INT INT INT CON CON
Unclear or nonexistent versioning of the information
INT
A B B B A A A
Case Study
153
The data centers have each experienced problems that resulted in extended outages: Princeton. Heavy snow caused roof collapse, which in turn took down the main transformer and phone switch. The outage lasted a week. Houston. The data center is located in a ood-prone area and heavy rains regularly cause the building to be inaccessible to employees. The last major hurricane to hit Houston in 1983 caused an electrical outage that lasted a week. All critical servers are not protected by an Uninterrupted Power Supply (UPS) and the generator is old, inadequate, and has not been tested in ve years. Monrovia. The data center is located west of the San Andreas Fault. Poor power feeds cause frequent brownouts and power outages. The UPS is inadequate to allow proper shutdown of client/server systems. Other important facts about the Boswerth operation include: 1. No formal procedures for backups and no offsite storage contracts are in place. If and when backups are made, they are usually stored on top of the server or taken to someones desk. 2. Physical security is lax to nonexistent at each site. 3. A random audit conducted on logs at various sites revealed that customer transaction information has been altered. 4. Employees are sharing access and many user passwords are set to never expire. 5. The company has outsourced virtually all of its IT functions not to one, but to many different vendors. 6. A much larger transportation company (Wheels R Us) has recently acquired Boswerth, so management is in a state of ux and morale is low. 7. Neither Boswerth nor Wheels R Us has an up-to-date xed assets system, so there are no reliable records of hardware, software, etc. 8. Systems and applications documentation is out-of-date and, for the most part, cannot be located. 9. Each of the commercial locations has a data center that is run by an outsource vendor. 10. IT is staffed by a combination of outsource vendor employees, transitioned employees from the original transportation company (Boswerth), and transitioned employees from the purchasing company (Wheels R Us), all of whom are now employees of the outsource vendor. 11. Many of the more experienced IT staff and business employees have left the company, and have been replaced by either vendor employees and now by employees of Wheels R Us. A variety of consulting organizations and Big 5 accounting rms have been on-site for various reasons.
154
Some of their studies have resulted in layoffs. The staff is mistrustful of consultants, as they have been burned or had their time wasted by these many studies. The general feeling is that the studies have not brought any valueadded results. The Information Security function was also outsourced, along with data center functions.
The Problem
The must important (it generates the primary revenue) application and asset that Boswerth has brought to the acquisition is the U Rent It System (URIS). The new owner, Wheels R Us, has contracted you to conduct a risk analysis on this application. The application is: Third-party software (PeopleSide, Inc.) was purchased three years ago and customized by Boswerth personnel. Software is run on a UNIX platform and draws data from the MVS legacy systems. The commercial side of the house connects using T-1 connection. Local franchises use dial-in access but are now switching to Internet connection using local ISPs.
Task Number 1
Conduct the one-hour Pre-FRAP meeting and create the following: 1. 2. 3. 4. 5. scope statement (see Exhibit 7.1) visual diagram team members meeting mechanics denitions a. risk b. control c. review elements (integrity, condentiality, availability) d. vulnerability impact
Task Number 2
Identify the deliverables from the FRAP session.
Case Study
155
Task Number 3
Using the FRAP example report, complete the missing steps, and create a closing letter (see Exhibit 7.3).
Available Tools
The following materials are available to assist in the FRAP: An outdated organizational chart, which was compiled before the acquisition. Disaster Recovery Plan from 1989, which has not been updated or tested. A list of the vendors and their responsibilities within the company, including: Vendor 1 Data center operations: responsible for the hardware and operating system software and oversight of the day-to-day running of the data centers Vendor 2 Data center personnel: outsourced from Vendor 1, Vendor 2 provides the personnel who staff the data centers Vendor 3 Applications developer for the new xed assets system Vendor 4 Applications developer for new URIS system Vendor 5 Hardware vendor: responsible for outdated hardware, running operating system that is no longer supported; client has a contract with them to keep this hardware running, as they are the only source of parts/repair; the dial-up system that handles their consumer business runs on this system The resources available for the FRAP include: the CIO, who just came onboard from Wheels R Us a systems programmer who has been with Boswerth for 15 years operations manager from Vendor 1, who has been with the organization for 18 months IT manager from Vendor 2, who has been with the organization for six months Y2K listing of applications that has not been updated since it was completed in late 1999
Appendix A
Questionnaire
157
158
I.
Security Policy
A security policy is the basis of any security effort, and provides a framework with which to assess the rest of the organization. It is, therefore, the starting point for a Security Assessment.
Rating/Value 1 2 3 4 Prelim Score Action Item Comments Final Score
Factors
A.
4 = Unclear 1 1 1 1 1 1 1 2 2 2 3 3 3 4 4 4 2 3 4 2 3 4 2 3 4 4
POLICY
1 = Clearly
2 = Fairly Clearly
3 = Somewhat Unclear
1. Is there an information security policy in place? (1 = Yes; 4 = No)
2. Does the policy state what is and is not permissible?
3. Does the scope of the policy cover all facets of information?
4. Does the policy dene and identify what is classed as information?
5. Does the policy support the business objectives or mission of the enterprise?
6. Does the policy identify management and employee responsibilities?
7. Does the policy make clear the consequences of noncompliance?
B.
3 = In Development 1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 4 = Havent Begun
PROCEDURES
Questionnaire
1 = Completed
2 = Being Implemented
1. Are procedures in place to implement the information security policy?
2. Are the policies and procedures continually evaluated against current enterprise business needs?
3. Are standards in place to supplement the policies and procedures?
4. Are the procedures and standards evaluated to determine their level of impact to the business process?
5. Does the project management methodology uphold the security practices?
C.
3 = In Development 1 1 1 1 2 2 3 3 2 3 4 4 4 4
DOCUMENT HANDLING
4 = Havent Begun
1 = Completed
1. Is there a reasonable and usable information classication policy? (1 = Yes; 4 = No)
2. Does the information classication policy address all enterprise information?
3. Is the information classication policy followed?
4. Is an information classication methodology in place to assist employees in identifying levels of information within the business unit?
5. Is there an information handling matrix that explains how specic information resources are to be handled?
4 (continues)
159
160
I.
Rating/Value 1 2 3 4 Comments Prelim Score Action Item Final Score
Security Policy (Continued)
Factors
D. SECURITY HANDBOOK
3 = In Development 1 1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 4 4 = Havent Begun
1 = Completed
1. Is there an information security employee handbook in place? (1 = Yes; 4 = No)
2. Does the handbook cover the entire policy?
3. Does the handbook identify the importance of the security policy?
4. Does the handbook address the employees responsibilities?
5. Does the handbook stress the degree of employee personal accountability?
6. Does the handbook make clear the consequences of noncompliance?
OTHER FACTORS 1 1 1 2 2 2 3 3 3 4 4 4
1.
2.
3.
TOTAL SCORE
Interpreting the Total Score The Assessment Rate is ACTIONS might include...
Use this table of Risk Assessment questionnaire score ranges to assess resolution urgency and related actions.
Questionnaire
If the SCORE is...
AND
23 to 40
Most activities have been implemented Most employees are aware of the program
Superior
Information Protection (IP) policy is implemented Supporting standards and procedures are integrated into the workplace Information classication policy and methodology have been implemented IP policy is being rolled out Supporting standards and procedures are being developed Employee awareness has begun IP policy and supporting documents are being developed An IP team has been identied Management has expressed a need for IP policies and procedures Audit comments are pending
41 to 58
Many activities have been implemented Many employees are aware of the program and its objectives Fair
Solid
59 to 76
Some activities are under development Most management endorses IP objectives Poor
77 to 92
Policies, standards, procedures are missing or not implemented Management and employees are unaware of the need for a program
161
162
II. Originizational Suitability
Security policies and procedures can be rendered useless if the organization does not support the information security program.
RATING SCALE:
Rating/Value 1 4 Notes Prelim Score Action Item
1 = YES
4 = NO
Final Score
Factors
A.
1 1 1 1 1 4 4 4 4 4
ORGANIZATIONAL SUITABILITY
1. Does senior management support the information security program?
2. Are employees able to perform their duties efciently and effectively while following security procedures?
3. Does the information security program have its own line item in the budget?
4. Are resources adequate to nd and staff an effective information security program?
5. Does the security group have the authority to submit needed security policy changes throughout the enterprise? 1 4
6. Is an annual report on the level of information security compliance issued to management?
B.
PERSONNEL ISSUES
1 4
1. Does the enterprise have enough employees to support current business goals?
2. Are employees and project managers aware of their responsibilities for protecting information resources? 1 1 1 1 1 2 3 4 2 3 4 4 4 4
Questionnaire
3. Are employees properly trained to perform their tasks?
4. Does the enterprise have sufcient expertise to implement an information security awareness program?
5. Are contractor personnel subject to concentiality agreements?
6. Are contract personnel subject to the same policies as employees?
7. Is access to sensitive/condential information by contract personnel monitored?
C.
1 1 1 2 3 4 2 3 4 2 3 4
TRAINING AND EDUCATION
1. Do employees know the business goals and direction?
2. Do employees receive security related training specic to their responsibilities?
3. Are employees receiving both positive and negative feedback related to security on their performance evaluations? 1 1 1 2 2 3 3 2 3 4 4 4
4. Is security-related training provided periodically to reect changes and new methods?
5. Are system administrators given additional security training specic to their jobs?
6. Is there a regular security awareness and training program in place?
163
(continues)
164
II. Originizational Suitability (Continued)

Rating/Value 1 2 3 4 Prelim Score Action Item Comments Final Score
Factors
D. OVERSIGHT AND AUDITING

1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4
1. Are the security policies and procedures routinely tested?
2. Are exceptions to security policies and procedures justied and documented?
3. Are audit logs or other reporting mechanisms in place on all platforms?
4. Are errors and failures tracked?
5. When an employee is found to be in non-compliance with the security policies, has appropriate disciplinary action been taken? 1 1 1 2 2 2 3 3 3
6. Are audits performed on a regular basis?
4 4 4
7. Are unscheduled/surprise audits performed?
8. Has someone been identied as responsible for reconciling audit results?
E.
1 1 2 3 4 2 3 4
Questionnaire
APPLICATION DEVELOPMENT AND MANAGEMENT
1. Has an application development methodology been implemented?
2. Are appropriate/key application users involved with developing and improving application methodology and implementation process? 1 1 1 2 3 4 2 3 4 2 3 4
3. Is pre-production testing performed in an isolated environment?
4. Has a promotion to production procedures been implemented?
5. Is there a legacy application management program?
TOTAL SCORE
165
166
If the SCORE is...
AND
31 to 65
Superior
CIO and mission has been chartered Employee training is an ongoing process Awareness training program is in place IP objectives are reviewed annually CIO is being considered Mission statement is under development Initial employee awareness process has begun Search for a CIO has begun IP group has been identied Employees have been informed that changes are under way Management has a plan for an IP program Audit has identied the need
66 to 85
Solid
86 to 105
106 to 124
III.
Rating/Value 1 2 3 4 Notes Prelim Score Action Item
Physical Security
4 = In Development 4 = NO
Final Score
The security of the equipment and the buildings used by an organization is as important as the security of a specic platform.
Questionnaire
RATING SCALE:
1 = YES
Factors
A.
1 1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4
PHYSICAL AND FACILITIES
1. Is access to buildings controlled?
2. Is access to computing facilities controlled?
3. Is there an additional level of control for after-hours access?
4. Is there an audit log to idenify the individual and the time of access for non-standard hours access?
5. Are systems and other hardware adequately protected from theft?
6. Are procedures in place for the proper disposal of condential information?
B.
1 1 1 1 1 2 2 2 2 2 3 3 3 3 3
AFTER-HOURS REVIEW
4 4 4 4 4 (continues)
1. Are areas containing sensitive information properly secured?
2. Are workstations secured after-hours?
3. Are keys and access cards properly secured?
4. Is condential information properly secured?
167
5. Are contract cleaning crews activities monitored?
168
III.
Rating/Value 1 2 3 4 Notes Prelim Score Action Item Final Score
Physical Security (Continued)
Factors
C.
1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4
INCIDENT HANDLING
1. Has an Incident Response Team (IRT) been established?
2. Have employees been trained as to when the IRT should be notied?
3. Has the IRT been trained in evidence gathering and handling?
4. Are incident reports issued to appropriate management?
5. After an incident, are policies and procedures reviewed to determine if modications need to be implemented?
D. CONTINGENCY PLANNING
1 1 1 1 2 2 2 3 3 3 4 4 4 2 3 4
1. Has a Business Impact Analysis (BIA) been conducted on all systems, applications, and platforms?
2. Is there a documented data center Disaster Recovery Plan (DRP) in place?
3. Has the data center DRP been tested within the past 12 months?
4. Are system, application, and data backups sent to a secure off-site facility on a regular basis?
5. Are Service Level Agreements (SLAs) that identify processing requirements in place with all users and service providers? 1 2 3 4
Questionnaire
6. Have departments, business units, groups, and other such entities implemented business continuity plans that supplement the data center DRP? 1 1 2 3 4 2 3 4
7. Have Emergency Response Procedures (ERPs) been implemented?
8. Have ERPs been tested for effectiveness?
TOTAL SCORE
169
170
If the SCORE is...
AND
23 to 40
Superior
Access to sensitive areas is restricted via automated mechanism An Incident Response Team has been implemented Contingency plans have been tested annually Access to sensitive areas is generally restricted Emloyees are aware of re safety procedures Contingency plans have been developed Access to sensitive areas requires sign-in Employees contact the Help Desk when there is a problem Contingency plans are being developed Access to sensitive areas is being dened Incidents are handled locally Backups are sent off-site
41 to 58
Many activities have been implemented Many employees are aware of the program and its objectives
Solid
59 to 76
Fair
77 to 92
IV.
Business Impact Analysis, Disaster Recovery Plan
Questionnaire
Being able to recover critical systems is important to every organization. To be successful, an enterprise must establish a method to rank applications and systems (BIA) and to recover them in a timely manner.
RATING SCALE:
1 = YES
4 = In Development
4 = NO
Final Score
Factors
A.
1 2 3 4
BUSINESS IMPACT ANALYSIS (BIA)
1. A business impact analysis (BIA) has been conducted on all applications and systems to determine the business processes impacted. 1 2 3 4
2. Backup planning includes identication of all critical date, programs, documentation, and support items (critical resources) required performing essential tasks during recovery period. 1 2 3 4
3. The BIA is reviewed and updated regularly with special attention to new technology, business changes, and migration of applications to alternative platforms. 1 1 2 3 2 3 4 4
4. Critical period timeframes have been identied for all applications and systems.
5. Senior management has reviewed and approved the prioritized list of critical applications.
(continues)
171
172
IV.
Business Impact Analysis, Disaster Recovery Plan (Continued)
Factors
B.
1 2 3 4
DISASTER RECOVERY PLAN (DRP)
1. A corporate disaster recovery plan coordinator has been named and a mission statement identifying scope and responsibilities has been published. 1 2 3 4
2. A worst-case scenario DRP to recover normal operations within prescribed timeframes has been implemented and tested. 1 2 3 4
3. Listings of current emergency telephone numbers for police, re department, medical aid, and company ofcials are strategically located throughout the facility and at off-site locations. 1 1 1 2 3 4 2 3 4 2 3 4
4. The backup site is remote from hazards that endanger the main data center.
5. Contracts for outsourced activities have been amended to include service providers responsibilities for DRP.
6. Procedures are in place to ensure that adequate supplies of critical preprinted forms are available in the event of an emergency. 1 2
7. Lead times for communication lines and equipment, specialized devices, power hookups, construction, rewalls, computer congurations, and LAN implementation have been factored into the DRP.
8. At least one copy of the DRP is stored at the backup site and is updated regularly. 1 1 2 3 4 2 3 4
Questionnaire
9. Automatic restart and recovery procedures are in place to restore data les in the event of a processing failure.
10. Contingency arrangements are in place for hardware, software, communications, software, and staff.
C.
1 1 2 3 4 2 3 4
TESTING
1. Bachup and recovery procedures are tested at least annually.
2. Training sessions are conducted for all relevant personnel on backup, recovery, and contingency operating procedures. 1 2 3 4
3. Appropriate user representatives have an active role in creating and reviewing control reliability and backup provisions for relevant applications. 1 2 3 4
4. Appropriate user representatives participate in the DRP tests.
OTHER ISSUES
1 1 2 2 3 3 4 4
1. Provisions are in place to maintain the security of processing functions in the event of an emergency.
2. Insurance coverage for loss of hardware and business impact is in place.
TOTAL SCORE
173
174
If the SCORE is...
AND
21 to 36
Most activities have been implemented Most employees are aware of the program Solid
Superior
DRP is in place and has been tested Employees are trained in DRP roles BIAs are reviewed annually DRP coordinator has been identied
37 to 52
DRP is written Employees are aware of their roles in the DRP Management supports and has budgeted for FRP DRP task force has been formed Critical applications assessment has begun Critical resources are being identied Backups are stored off-site Audit has identied a weakness in DR planning Management is aware of its responsibility
53 to 67
Some activities are under development Most management endorses IP objectives
68 to 84
Poor
V.
Technical Safeguards
4 = In Development 4 = NO
Final Score
Technical safeguards enforce the security policies and procedures throughout the network infrastructure.
Questionnaire
RATING SCALE:
1 = YES
Factors
A.
1 1 1 1 1 1 1 1 1 1 2 2 3 3 2 3 4 4 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4
NETWORK INFRASTRUCTURE
1. Is the network environment partitioned?
2. Are the desktop platforms secured?
3. Are host systems and servers as well as application servers secured?
4. Are passwords and accounts being shared?
5. Are unsecure user accounts (e.g., guest) still active?
6. Are temporary user accounts restricted and disabled in a timely fashion?
7. Have employees been trained on proper password management?
8. Are users of all company-provided network resources required to change the initial default password?
9. Are the passwords required to use current tools as secure as the tools allow them to be?
10. Do network and system administrators have adequate experience to implement security standards?
175
(continues)
176
V.
Rating/Value 1 2 3 4 Prelim Score Action Item
Technical Safeguards (Continued)

Notes Final Score
Factors
11. Are report logs reviewed and reconciled on a regular basis? 1 1 1 1 1 1 1 1 1 2 2 2 2 3 3 3 3 2 3 4 4 4 4 4 2 3 4 2 3 4 2 3 4 2 3 4
12. Are permissions being set securely?
13. Are administrators using appropriate tools to perform their jobs?
14. Is there a current network diagram available?
15. Are Access Control Lists (ACLs) maintained on a regular basis?
16. Is there a remote access procedure in place?
17. Are critical servers protected with appropriate access controls?
18. Is the network infrastructure audited on a regular basis?
19. Are network vulnerability assessments conducted?
20. Are changes/improvements made in a timely fashion following network vulnerability assessments?
B.
1 1 1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4
FIREWALLS
Questionnaire
1. Are protocols allowed to go across the rewall?
2. Has a risk analysis been conducted to determine if the protocols allowed maintain an acceptable level of risk?
3. Has the rewall been tested to determine if outside penetration is possible?
4. Are other products in place to augment the rewall level of security?
5. Are the rewalls maintained and monitored 7 24
6. Have services offered across the rewall been documented?
7. Has a Demilitarized Zone (DMZ) or Perimeter Network (a segment of network between the router that connects to the Internet and the rewall) been implemented?
TOTAL SCORE
177
178
If the SCORE is...
AND
28 to 56
Superior
Network secrity policies and standards are implemented System and LAN administrators are trained in security issues Firewalls are implemented and monitored Network security policy is being approved Network and desktop standards are under development Firewall administrator job description has been developed Subject matter experts have been identied Policy and procedures development team has been identied Firewall implementation is underway Management has expressed a concern for network security Internet connection is being considered
57 to 75
Many activities have been implemented Many employees are aware of the program and its objectives
Solid
76 to 94
Fair
95 to 112
Poor
VI.
Telecommunications Security
Questionnaire
Enterprises must take precautions to protect their information when being transmitted via various telecommunication processes.
RATING SCALE:
1 = YES
4 = In Development
4 = NO
Final Score
Factors
A.
1 1 1 2 3 4 2 3 4 2 3 4
POLICY
1. There is a published policy on the use of organizational telecommunications resources.
2. All employees have been made aware of the telecommunications policy.
3. Employees authorized for Internet access are made aware of the organizations proprietary information and what they can discuss in open forums. 1 2 3 4
4. Employees using cellular or wireless phones are briefed on the lack of privacy of conversations when using unsecured versions of this technology. 1 1 2 3 2 3 4 4
5. Terminating employees have their calling cards and voice-mail passwords disabled.
6. Temporary and contract personnel have their calling cards and voice-mail passwords disabled when their assignment ends. 1
7. The organization has a published policy on prosecution of employees and outsiders if found guilty of serious premeditated criminal acts against the organization.
179
(continues)
180
VI.
Telecommunications Security (Continued)
Factors
B.
1 1 1 1 1 1 1 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4 2 3 4
STANDARDS
1. A threshold is established to monitor and suspend repeated unsuccessful dial-in attempts.
2. Access to databases reachable via dial-in has an access control in place to prevent unauthorized access.
3. Financial applications available via dial-in have audit trails established to track access and transaction usage.
4. Are audit trails reviewed and corrective action taken on a regular basis?
5. When possible, the mainframe security program is used to control dial-in access to specic applications.
6. Company proprietary data, satored on portable computers is secured from unauthorized access.
7. Users of all company-provided communication systems are required to change the default or initial password.
C.
1
PRACTICES
2 3 4
1. Security, application, and network personnel actively work to ensure control inconvenience is as minimal as possible.
2. Personnel independent of the operations staff and security administration review tamper-resistant logs and audit trails. 1 2 3 4
Questionnaire
3. Special procedures and audited recall userIDs have been established for application, system, and network troubleshooting activities. 1 1 2 3 4 2 3 4
4. Telephone usage logs are reviewed on a regular basis to discover potential usage abuse.
5. Messages and transactions coming in via phone lines are serially numbered, time stamped, and logged for audit investigation and backup purposes. 1 2 3 4
6. Employees are made aware of their responsibility to keep remote access codes secure from unauthorized access and usage. 1 2 3 4
7. Portable computer users are provided with a mechanism to allow backup of appropriate sensitive information or critical application to a server or portable storage media. 1 2 3 4
8. Removal of portable computers from the campus location must be done through normal property removal procedures. 1 2 3 4
9. Employees are briefed on their responsibility to protect the property (physical and logical) of the company when working away from the campus environment.
TOTAL SCORE
181
182
If the SCORE is...
AND
23 to 40
Superior
Telecommunications security policies and standards are implemented Telecom administrators are trained in security issues Usage reports are monitored Discrepancies are investigated Telecommunications security policy is being approved Standards are under development System and report logs are being generated Subject matter experts have been identied Policy and procedures development team has been identied Telecom standards implementation is underway Management has expressed a concern for telecommunication security Audit has identied weaknesses in telecommunications security
41 to 58
Solid
59 to 76
77 to 92
Poor
Appendix B
Facilitated Risk Analysis Process (FRAP) Forms

Scope/Business Process Identication Application/System: Payroll and Human Resource Information System (PHARIS) Pre-FRAP Date: The Project Leader and information/application/system Owner are told in the Pre-FRAP meeting what is meant by a Scope Statement and Key Business Processes. They dene the scope and identify the business processes after the Pre-FRAP meeting and record them here. Denition: SCOPE STATEMENT A Scope Statement describes......... To implement PeopleSoft HRMS to replace existing Payroll & HR Systems
Denition: A Key Business Process is any high-level business process that relies on information supplied by the application/system described above. KEY BUSINESS PROCESSES Business Process 1 Business Process 2 Business Process 3 Business Process 4 Business Process 5
183
Payroll Human Resource System
184
ACTION PLAN
Application: Payroll and Human Resource Information System (PHARIS) FRAP Date:
Controls Owner Action By Who When Additional Comments
Risk #
Risk
Type
Priority
INT
This is where one would enter any comments or discussion that occurred during the FRAP relative to Risk #1, its controls, or anything else noteworthy.
INT
INT
INT
INT
INT
INT
INT
INT
10
INT
11
INT
12
INT
13
INT
14
INT
15
INT
16
INT
17
INT
18
INT
19
INT
20
INT
21
INT
22
INT
23
INT
24
INT
25
INT
26
INT
27
INT
28
INT
CON
CON
CON
CON
CON (continues)
185
186
ACTION PLAN (Continued)

Controls Owner Action By Who When Additional Comments
Risk #
Risk
Type
Priority
CON
CON
CON
CON
10
CON
11
CON
12
CON
13
CON
14
CON
15
CON
16
CON
17
CON
18
CON
19
CON
20
CON
21
CON
22
CON
23
CON
24
CON
25
CON
26
CON
27
CON
28
Deferred Issue
Deferred Issue
Deferred Issue
Deferred Issue
Deferred Issue
The risks below were determined to be of minor concern. Controls for risks of minor concern will not be implemented at this time.
187
188
FRAP ATTENDEES
NAME PHONE
Information Owner Information Owner Representative Project Leader Primary Application Analyst Backup Application Analyst Technical Personnel Technical Personnel
(owners name)
Facilitator Scribe
(facilitators name)
189
FINAL REPORT
Date: To: From: Subject: (enter date) (enter Owners position) Supervisor, Information Protection Facilitated Risk Analysis
The Information Protection group facilitated a Risk Analysis session on the system/application named below. The Risk Analysis attendees identied the risks and controls shown on the attached Action Plan. The attendees included you, or your representative, to ensure that the concerns of your organization were properly addressed. The Action Plan shows which of the controls identied during the Risk Analysis have been, or will be implemented. You should have made the decisions as to if and when the controls will be implemented. FRAP Date: System/Application: Payroll and Human Resource Information System (PHARIS) Owner: Facilitator: (owners name) (facilitators name)
Please read the Statement of Understanding below, sign it, and return it to me in 749 GO. STATEMENT OF UNDERSTANDING: I, the Owner, understand that the risks identied on the attached Risk Analysis Action Plan could cause the integrity, condentiality, and/or availability of this system/applications information to be negatively impacted. I have decided to implement the controls according to the schedule on the attached Risk Analysis Action Plan. I understand that any risks that are not controlled could adversely affect corporate information and company business. I am aware that a copy of the Risk Analysis Action Plan will be forwarded to the Audit organization.
______________________________________________________ Owner/Owners Representative ______________________________________________________ ISO Project Leader _________________________ Date _________________________ Date
190
CONTROLS LIST
Backup
Backup requirements will be determined and communicated to PSOU, including a request that an electronic notication that backups were completed be sent to the application system administrator. Operations will be requested to test the backup procedures. Develop, document, and test recovery procedures designed to ensure that the application and information can be recovered, using the backups created, in the event of loss. Implement an access control mechanism to prevent unauthorized access to information. This mechanism will include the capability of detecting, logging, and reporting attempts to breach the security of this information. Access sourced: Implement a mechanism to limit access to condential information to specic network paths or physical locations. Implement user authentication mechanisms (such as rewalls, dial-in controls, secure ID) to limit access to authorized personnel. Implement encryption mechanisms (data, end-toend) to prevent unauthorized access to protect the integrity and condentiality of information. Design and implement application controls (data entry edit checking, elds requiring validation, alarm indicators, password expiration capabilities, checksums) to ensure the integrity, condentiality, and availability of application information. Develop testing procedures to be followed during applications development and during modications to the existing application that include user participation and acceptance. Adhere to a change management process designed to facilitate a structured approach to modications of the application, to ensure appropriate steps and precautions are followed. Emergency modications should be included in this process,
Recovery Plan
Access Control
Access Control
Access Control
Access Control
Application Control
Acceptance Testing
Change Management
191
CONTROLS LIST (Continued)

10
Anti-Virus
1) Ensure LAN administrator installs the corporate standard anti-viral software on all computers. 2) Training and awareness of virus prevention techniques will be incorporated in the organization IP program. Develop policies and procedures to limit access and operating privileges to those with business need. User training will include instruction and documentation on the proper use of the application. The importance of maintaining the condentiality of user accounts, passwords, and the condential and competitive nature of information will be stressed. Implement mechanisms to monitor, report, and audit activities identied as requiring independent reviews, including periodic reviews of userIDs to ascertain and verify business need. Operations controls: Training for a backup to the system administrator will be provided and duties rotated between them to ensure the adequacy of the training program. Operations controls: Application developers will provide documentation, guidance, and support to the operations staff (PSOU) in implementing mechanisms to ensure that the transfer of information between applications is secure. Operations controls: Mechanisms to protect the database against unauthorized access, and modications made from outside the application, will be determined and implemented. Operations controls: Systems that feed information will be identied and communicated to PSOU to stress the impact to the functionality if these feeder applications are unavailable. Operations controls: Time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants. (continues)
11
Policy
12
Training
13
Review
14
Backup
15
Training
16
Access Control
17
18
Maintenance
192
CONTROLS LIST (Continued)

19
Training
User controls: Implement user programs (user performance evaluations) designed to encourage compliance with policies and procedures in place to ensure the appropriate utilization of the application. Acquire service level agreements to establish level of customer expectations and assurances from supporting operations. Acquire maintenance or supplier agreements to facilitate the continued operational status of the application. In consultation with facilities management, facilitate the implementation of physical security controls designed to protect the information, software, and hardware required of the system. Request management support to ensure the cooperation and coordination of various business units, to facilitate a smooth transition to the application. Proprietary controls The development team will develop corrective strategies such as reworked processes, revised application logic, etc. Production migration controls such as search and remove processes to ensure data stores are clean.
20
21
22
Physical Security
23
Management Support
24 25
26
193
RISK LIST
Risk # Risk Type Risk Description
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Integrity Integrity Integrity Integrity Integrity Integrity Integrity Integrity Integrity Integrity Condentiality Condentiality Condentiality Condentiality Condentiality Availability Availability Availability Availability Availability Availability Availability Availability Availability Availability Availability
Unauthorized internal access Unauthorized external access Improper editing routines for data entry functions Improper editing routines for external feeds Timeliness of external feeds Program bugs Lack of change control process (including testing) Lack of version control process (especially true when software is workstation resident) Computer viruses Corrupted database Unauthorized internal access Unauthorized external access Unattended workstations Hardcopy management (including production, distribution, and destruction) User awareness of the information classication being dealt with Unauthorized internal access Unauthorized external access Computer viruses External feeds unavailable Mainframe unavailable Servers unavailable (database or application) Wide area network unavailable Program bugs Lack of application disaster recovery plan Lack of proper backups Lack of plan to restore backups
Risks when software is not developed in-house include: No agreed timeframe to repair system or program bugs No agreed timeframe to repair corrupted database Lack of database expertise Vendor solvency Vendor access to production database Lack of version control and testing criteria
194 CONTROL/RISKS CROSS-REFERENCE LIST

Control Control Description Risk
Risk Description
Type
Concern
Appendix C
Business Impact Analysis (BIA) Forms

APPLICATION/SYSTEM BUSINESS IMPACT ANALYSIS INSTRUCTIONS The sheets described below are used to perform the Business Impact Analysis (BIA). The purpose of the BIA is to identify impacts to key business processes if an application or system becomes unavailable for an unacceptable period of time. The BIA supplies information needed to develop a Business Continuity Plan. The Information Protection group can facilitate the Business Impact Analysis and can provide assistance with Business Continuity Planning. Time Sensitivity and Loss Impact Identication Worksheet 1. Line 1 Enter name of the application or system and the date. 2. Column B: Enter the key business processes or business functions supported by the application or system. 3. Column C: Enter the period that a business unit is most dependent upon the business process. The period may be a particular hour(s) of day, day(s) of week, week(s) of month, or month of year. It could also be unscheduled, such as during a storm. 4. Column D: Using the Business Impact Valuation Table, enter the longest tolerable outage period Loss Impact Value. Enter the actual period (hours, days) in Column C of the Comments Table. 5. Column E: If the business process is unavailable, indicate if it could affect delivery of service to customers. 6. Column F: Using the Valuation Table, enter the impact to Health & Safety if the application or system caused the business process to be unavailable for a time just longer than the Longest Tolerable Outage Period. Enter comments in Column D of the Comments Table.
195
196
7. Column G: Using the Valuation Table, enter the impact to Customer Satisfaction if the application or system caused the business process to be unavailable for a time just longer than the Longest Tolerable Outage Period. Enter comments in Column E of the Comments Table. 8. Column H: Using the Valuation Table, enter the Embarrassment impact if the application or system caused the business process to be unavailable for a time just longer than the Longest Tolerable Outage Period. Enter comments in Column F of the Comments Table. 9. Column I: Using the Valuation Table, enter the Financial impact if the application or system caused the business process to be unavailable for a time just longer than the Longest Tolerable Outage Period. Enter nancial loss dollar estimates in Column G of the Comments Table. Note: Use the Financial Loss Estimation Worksheets described below to assist in identication of Financial Loss Impact. 10. Repeat steps 3 through 9 for all key business processes. Business Loss Impact Valuation Table This table was designed to allow a uniform impact value to be assigned to both tangible and intangible losses. The impact value can is used to determine the criticality of the business process to the company. Comments Table (Actual data, comments, etc. obtained during the FBIA) This table was designed to record the actual time periods, dollars, etc. identied during the FBIA process. Any comments or notes can also be recorded for future reference. Financial Loss Impact Worksheets There are ve Financial Loss Impact Worksheets to assist with Column I of the Loss Impact Worksheet described above. The rst worksheet is for Business Process 1, the second for Business Process 2, etc. 1. Column B: For each type of impact listed, estimate the dollar loss if the business process were unavailable for a time just longer than the Longest Tolerable Outage Period.
Time Sensitivity and Loss Impact Identication
Application/System:_____________________________________ Date:________________
FBIA Attendees:
D Business Loss Impact Value E F G H I
____________________________________________________________
Time Criticality
Key Business Processes or Business Functions Supported by the Application/System (name) Longest Tolerable Outage Period During Peak (Impact Value)a Health & Safety (Impact Value) Customer Satisfaction (Impact Value)
Peak Activity Period (day of wk, wk of mon, mon of yr)
Is it likely that an outage can delay installation, delivery, restoration, or interrupt service? (Yes = 1, No = 0)
Embarrassment (Impact Value)
Financial (Impact Value)
Weight =
Minimum Impact Score = TOTAL IMPACT SCORE = 0.00 Recommended Criticality Tier NA
Interrupt Service? NO
Impact Values can be found on the Loss Impact Valuation Table
197
198
Loss Impact Valuation Table

Intangible Loss (Dollar Loss Difcult to Estimate) Health & Safety Customer Satisfaction (Dissatised Customers) Embarrassment (Comes to Attention of) Tangible Loss Financial
Time Sensitivity
Impact Value
Longest Tolerable Outage Period During Peak
24 hours or less
Loss of multiple lives
more than 500,000
National or international - press - organization Local or state - press - organization Company organization Company division - Few if anyone - Company group
More than $10M
2572 hours
Loss of life
100,001500K
$1,000,001 $10M $100,001 $1M $50,001 $100K $0$50K
3 100110K 01K
73 hours5 days
Serious injury
10,001100K
69 days
Major exposure to unsafe work environment
10 days or more
Little or no negative impact Minor exposure to unsafe work environment
Note: This table was designed to only be used to assign an Impact Value to one of the ve columns to the right. It does not equate items in the same row in the second through sixth columns.
Comments Table
(Notes or other details obtained during the facilitated session)
Application/System: C Health & Safety Customer Satisfaction D E F Embarrassment G Financial
Key Business Process
Longest Tolerable Outage Period
199
200
FINANCIAL LOSS IMPACT WORKSHEET Application/System: Business Process 1:

A Type of Impact B Estimated Dollar Loss if Unavailable Just Beyond Longest Tolerable Outage Period
Loss of sales Regulatory nes Legal nes Cost of money (e.g., revenue collection delayed) Loss of competitive advantage Loss of investor condence Loss of customer condence Adverse public opinion Reporting delay (nancial reports, etc.) Cost of disruption to business Replacement of employees Elimination of work backlog Use of alternate procedures Loss of productive time Replacement of lost information Equipment repair or replacement Decreased employee morale Operating delay
Total Estimated Loss = $0 Total Loss Impact Value = N/A
Appendix D
Sample of Report
Risk Analysis Review & Recommendations for Internal Controls (Project Name Here)
Description of Opportunity Describe the project in terms of what is going to change and its effect on the business process. For example: The reporting database of the Timekeeping System will move from the mainframe located in the Central Data Center to a server located in the Payroll ofce. There will be a change in application language from Cobol to an Oracle database using C++. Results of Risk Analysis Describe specic risk to company information asset based on review of the six elements of the Risk Analysis Matrix. Data Integrity Accidental and Deliberate Acts List of specic risks: Shared les on server will lead to update problems Remote access could increase hacker activity Payroll ofce not as secure as Data Center Data Sensitivity Accidental and Deliberate Acts List of specic risks: LAN administrator will have access to server Ofce shared with non-company personnel Sensitive information left on desk in ofce Data Availability Accidental and Deliberate Acts List of specic risks: Backup no longer done by Operations LAN not covered in Data Center DRP Payroll ofce has a history of electrical problems
201
202
Control Elements Required Describe controls that are/will be put in place (What Who When) Procedures and training will be put in place to control shared les Remote access will require additional authentication Change Control procedures will be implemented for LAN applications On-site printer will be procured Backup procedures will be implemented for server A Business Impact Analysis will be conducted to determine need for DRP Describe Out of Control processes All risks that have been identied and cannot be controlled must be documented here.
Appendix E
Threat Denitions
Threat Denitions
Natural Threats
Acid rain: Cloud droplets or raindrops combining with gaseous pollutants, such as oxides of sulfur and nitrogen, to make falling rain or snow acidic. Alberta Clipper: A fast-moving, snow-producing weather system that originates in the lee of the Canadian Rockies. It moves quickly across the northern United States, often bringing gusty winds and cold Arctic air. Air pollution: The soiling of the atmosphere by contaminants to the point that may cause injury to health, property, plant, or animal life, or prevent the use and enjoyment of the outdoors. Beach erosion: The carrying away of beach materials by wave action, currents and tides, or wind. Black blizzard: A local term for a violent dust storm on the south-central Great Plains that darkens the sky and casts a pall over the land. Blizzard: A severe weather condition characterized by low temperatures, winds 35 mph or greater, and sufcient falling or blowing snow in the air to frequently reduce visibility to 1/4 mile or less for a duration of at least three hours. A severe blizzard is characterized by temperatures near or below 10F, winds exceeding 45 mph, and visibility reduced by snow to near zero. Cold air funnel: Funnel clouds, usually short-lived, that develop from relatively small showers or thunderstorms when the air aloft is very cold. Cold air funnels may touch down briey, but in general are less violent than most other types of tornadoes. Cyclone: An area of closed pressure circulation with rotating and converging winds, the center of which is a relative pressure minimum. The circulation is counterclockwise in the Northern Hemisphere and clockwise in the Southern Hemisphere. Also called a low pressure system and the term
203
204
used for a tropical cyclone in the Indian Ocean. Other phenomena with cyclonic ow may be referred to by this term, such as dust devils, tornadoes, and tropical and extra-tropical systems. The opposite of an anticyclone or a high pressure system. Downburst: A severe localized downdraft that can be experienced beneath a severe thunderstorm. Earthquake: A sudden, transient motion or trembling of the earths crust, resulting from the waves in the earth caused by faulting of the rocks or by volcanic activity. Erosion: The movement of soil or rock from one area to another by the action of the sea, running water, moving ice, precipitation, or wind. Flash ood: A ood that rises and falls quite rapidly with little or no advance warning, usually as the result of intense rainfall over a relatively small area. Flash oods can be caused by situations such as a sudden excessive rainfall, the failure of a dam, or the thaw of an ice jam. Flood: High water ow or an overow of rivers or streams from their natural or articial banks, inundating adjacent low-lying areas. Funnel cloud: A violent, rotating column of air visibly extending from the base of a towering cumulus or cumulonimbus cloud toward the ground, but not in contact with it. It is reported as FC in an observation and on the METAR. Gale: On the Beaufort Wind Scale, a wind with speeds from 28 to 55 knots (32 to 63 mph). For marine interests, it can be categorized as a moderate gale (28 to 33 knots), a fresh gale (34 to 40 knots), a strong gale (41 to 47 knots), or a whole gale (48 to 55 knots). In 1964, the World Meteorological Organization dened the categories as near gale (28 to 33 knots), gale (34 to 40 knots), strong gale (41 to 47 knots), and storm (48 to 55 knots). Hail: Precipitation that originates in convective clouds, such as cumulonimbus, in the form of balls or irregular pieces of ice, which comes in different shapes and sizes. Hail is considered to have a diameter of 5 mm or more; smaller bits of ice are classied as ice pellets, snow pellets, or graupel. Individual lumps are called hailstones. It is reported as GR in an observation and on the METAR. Small hail and snow pellets are reported as GS in an observation and on the METAR. Haze: Fine dry or wet dust or salt particles dispersed through a portion of the atmosphere. Individually, these are not visible but cumulatively they will diminish visibility. Humidity: Generally the measure of the water vapor content of the air. Hurricane: The name for a tropical cyclone with sustained winds of 74 miles per hour (65 knots) or greater in the North Atlantic Ocean, Caribbean Sea, Gulf of Mexico, and in the eastern North Pacic Ocean. This same tropical cyclone is known as a typhoon in the western Pacic and a cyclone in the Indian Ocean. Ice storm: A severe weather condition characterized by falling, freezing precipitation. Such a storm forms a glaze on objects, creating hazardous travel conditions and utility problems.
Threat Denitions
205
Lake effect snow: Snow showers that are created when cold dry air passes over a large warmer lake, such as one of the Great Lakes, and picks up moisture and heat. Lightning: A sudden and visible discharge of electricity produced in response to the buildup of electrical potential between cloud and ground, between clouds, within a single cloud, or between a cloud and surrounding air. Monsoon: The seasonal shift of winds created by the great annual temperature variation that occurs over large land areas in contrast with associated ocean surfaces. The monsoon is associated primarily with the moisture and copious rains that arrive with the southwest ow across southern India. The name is derived from the word mausim, Arabic for season. This pattern is most evident on the southern and eastern sides of Asia, although it does occur elsewhere, such as in the southwestern United States. Precipitation: Any form of water particles, liquid or frozen, that fall from the atmosphere and reach the ground. Rain: Liquid water precipitation generally with a diameter greater than 0.5 mm. Sandstorm: A strong wind carrying sand particles through the air. They are low-level occurrences, usually only ten feet in height to not more than 50 feet above the surface. Due to the frequent winds created by surface heating, they are most predominant during the day and die out in the night. Visibility is reduced to between 5/8ths and 6/16ths statute mile, and if less than 5/16ths, then the storm is considered a heavy sandstorm. It is reported as SS in an observation and on the METAR. Snow: Frozen precipitation in the form of white or translucent ice crystals in complex branched hexagonal form. It most often falls from stratiform clouds, but can fall as snow showers from cumuliform ones. It usually appears clustered into snowakes. It is reported as SN in an observation and on the METAR. Storm surge: A rise above the normal water level along a shore caused by strong onshore winds and/or reduced atmospheric pressure. The surge height is the difference between the observed water level and the predicted tide. Thunder: The sound produced by a stroke of lightning as it repidly heats the air surrounding the bolt. Tornado: A violently rotating column of air in contact with and extending between a convective cloud and the surface of the earth. It is the most destructive of all storm-scale atmospheric phenomena. They can occur anywhere in the world given the right conditions, but are most frequent in the United States in an area bounded by the Rockies on the west and the Appalachians in the east. Tropical storm: A tropical cyclone in which the one-minute sustained surface wind ranges from 39 to 73 mph. Tropical storms pose a threat to life and property in coastal areas. Tsunami: An ocean wave with a long period that is formed by an underwater earthquake or landslide, or volcanic eruption. It may travel unnoticed across the ocean for thousands of miles from its point of origin and builds
206
up to great heights over shallower water. Also known as a seismic sea wave, and incorrectly, as a tidal wave. Typhoon: The name for a tropical cyclone with sustained winds of 74 miles per hour (65 knots) or greater in the western North Pacic Ocean. This same tropical cyclone is known as a hurricane in the eastern North Pacic and North Atlantic Ocean, and as a cyclone in the Indian Ocean. Yellow snow: Snow that is given golden, or yellow, appearance by the presence of pine or cypress pollen.
Accidental Threats
Disclosure: The unauthorized or premature accidental release of proprietary, classied, company condential, personal, or otherwise sensitive information. Electrical disturbance: A momentary uctuation in the electrical power source, consisting of either a voltage surge (peak), voltage dip, or interruptions of less than one-half hour. Electrical interruption: A long-term disruption in the electrical power source, usually greater than one-half hour. Emanation: The inadvertent emanation or transmission of data signals from components of computers, computer peripherals, and word processors, which may be recorded by monitoring equipment. Environmental failure: An interruption in the supply of controlled environmental support provided the operations center. Environmental controls would include air quality, air conditioning, humidity, heating, and water. Fire: A conagration affecting information systems either through heat, smoke, or suppression agent damage. This threat category can be further broken down into minor, major, and catastrophic. Hardware failure: A unit or component failure ofsufcient magnitude to cause delays in processing or monetary loss to the enterprise. Liquid leakage: A liquid inundation from sources other than a ood. Examples of this include burst or leaking pipes, and the accidental discharge of sprinklers. Operator/User error: An accidental, improper, or otherwise ill-chosen act by an employee that results in processing delays, equipment damage, lost data, or modied data. Software error: Any extraneous or erroneous data in the operating system or applications program that results in processing errors, data output errors, or processing delays. Telecommunications Interruption: Any communications unit or component failure of sufcient magnitude to cause interruptions in the data transfer via telecommunications between computer terminals, remote or distributed processors, and host computing facility.
Intentional Threats
Alteration of data: An intentional modication, insertion, or deletion of data, whether by authorized users or not, that compromises the auditability,
Threat Denitions
207
recoverability, availability, condentiality, or integrity of the information produced, processed, controlled, or stored by the information processing systems. Alteration of software: An intentional modication, insertion, or deletion of operating system or application system programs, whether by an authorized user or not, that compromises the auditability, efciency, recoverability, availability, condentiality, or integrity of information, programs, the system, or resources controlled by the computer systems. Bomb threat: A notication of the existence of an explosive device at a facility, whether true or not. Disclosure: The unauthorized or premature intentional release of proprietary, classied, company condential, personal, or otherwise sensitive information. Employee sabotage: A deliberate action taken by an employee, group of employees, or non-employee(s) working together with an employee(s) to disrupt enterprise operations. Enemy overrun: A forceful occupation of an activity by a force whose intentions are inimical to the government. Fraud: A deliberate unauthorized manipulation of hardware, software, or information with the intent of nancial gain for the perpetrator. Riot/Civil disorder: A group unrest (whether organized or not) which causes widespread and uncontrollable suspension of law and social order. Strike: An organized employee action (union or not, legal or not) designed to halt or disrupt normal business operations. Strikes can be categorized as unfair labor practice, economic, and unprotected strikes. Theft: The unauthorized appropriation of hardware, software, media, computer supplies, or data of a classied nature but included in the disclosure category. Unauthorized use: An unauthorized use of computer equipment or programs. Examples of this include the running of personal programs such as games, inventories; browsing other les. Vandalism: The malicious and motiveless destruction or defacement of property.
Other Denitions
Organizations
National Climatic Data Center (NCDC): The archive center for climate, observational, and forecast data from the National Weather Service (NWS). National Hurricane Center (NHC): The ofce of the National Weather Service responsible for tracking and forecasting tropical cyclones; located in Miami, Florida. National Meteorological Center (NMC): Now incorporated into the National Centers for Environmental Prediction, it was the division of the National Weather Service that produced, processed, handled, and distributed meteorological and oceanographic information to users throughout the Northern Hemisphere, specically U.S. governmental organizations.
208
National Oceanic and Atmospheric Administration (NOAA): A branch of the U.S. Department of Commerce, it is the parent organization of the National Weather Service. It promotes global environmental stewardship, emphasizing atmospheric and marine resources. National Severe Storms Forecast Center (NSSFC): As of October 1995, the responsibilities of this Center were divided into two branches, the Storm Prediction Center and the Aviation Weather Center. National Severe Storms Laboratory (NSSL): NOAA ofce in Oklahoma City that issues tornado watches and attempts to predict tornado activity beforehand. (Tornado warnings are usually issued by local NWS ofces when possible tornadoes are detected.) National Weather Association (NWA): An organization whose membership promotes excellence in operational meteorology and related activities, recognizing the professional as well as the volunteer. National weather service (NWS): The division of NOAA that is responsible for tracking and warning about weather events, usually NOT including tornado watches and hurricane advisories, which typically are issued from the NSSL and Hurricane Center, respectively. However, regional NWS ofces often issue warnings and some types of watches related to severe weather, and work closely with the Hurricane Center and NSSL to provide timely information and warnings to the public about any weather concerns within their area. NOAA Weather Radio (NWR): The voice of the National Weather Service with 24-hour-a-day broadcasts of weather information, forecasts, and warnings. It is programmed from local National Weather Service ofces.
Weather
Air mass: A widespread body of air with consistent temperature and moisture characteristics. Air pressure: The pressure exerted by the weight of air above a given point, usually expressed in millibars (mb) or inches of mercury (in. Hg). Altocumulus: A principal cloud type, white and/or gray in color, present in the mid-altitudes with a cumuliform-like shape. Altostratus: A principal cloud type, gray or bluish in color, present in the mid-altitudes with a sheet or brous appearance. Anemometer: An instrument that measures wind speed. Anticyclone: An area of high pressure around which the winds circulate in a clockwise direction in the Northern Hemisphere. It is usually responsible for fair, dry weather. Backdoor cold front: A cold front that approaches from the north-northeast instead of from the usual west-northwest direction. Barometer: An instrument for measuring atmospheric pressure. Beaufort Wind Scale: A system of estimating and reporting wind speed devised by British Rear-Admiral, Sir Francis Beaufort in 1805, based on observations of the effects of the wind.
Threat Denitions
209
Bermuda high: An area of high pressure centered over the western Atlantic Ocean. This weather system produces a southerly wind that often moves warm, humid air into the Northeast. Biometeorology: The portion of the science of meteorology that deals with the effects of weather and climate on health and the human body. Blizzard warning: Snow, strong winds and low temperatures will combine to produce a blinding snow, deep drifts, and life-threatening wind chill. In the Washington, D.C. area, this means temperatures below 20F and winds above 35mph. Blowing snow: Wind-driven snow that reduces visibility near the ground. Blowing snow can be falling snow or snow that has already accumulated but is picked up and blown by strong winds. Ceiling: The height of the lowest layer of clouds reported as broken or overcast and not thin. Cirrocumulus: A principal cloud type featuring cirrus clouds with vertical development. Cirrostratus: A principal cloud type featuring cirrus clouds with a at or sheet-like appearance. Cirrus: A principal cloud type present at high altitudes above 18,000 feet and composed of ice crystals. Clear: Sky condition with less than one-tenth cloud coverage. Climate: The statistical collective of weather records during a specied period of time. Cold front: The front edge of a cold air mass. It often produces precipitation and, frequently, severe weather. Condensation: The process by which a gas changes into a liquid. Convection: An atmospheric motion that is predominately vertical; warm air rising or cold air sinking or both. Coriolis force: An apparent force on moving particles produced by the rotation of the earth. In the Northern Hemisphere, the wind is deected to the right by the coriolis force. Cumulonimbus: A principal cloud type, dense and vertically developed, that produces heavy precipitation. It features an anvil shape on top and a dark base. Cumulus: A principal cloud type of vertical elements having a at base and a bulging upper portion resembling cauliower. Dew: Moisture that condenses on objects near the ground. Dewpoint: The temperature to which the air must be cooled for water vapor to condense. The larger the spread of temperature and dewpoint, the drier the air. This spread is called the dewpoint depression. Doppler radar: A radar that determines the velocity of falling precipitation either toward or away from the radar unit. Drifting snow: Uneven distribution of snowfall. Snow depth caused by strong surface winds. Drizzle: Very small, numerous, slowly falling water droplets, with diameters less than 0.5 mm.
210
El Nio: A large-scale weakening of the tradewinds and warming of the surface layers in the equatorial eastern and central Pacic Ocean. Fair: Less than 4/10 opaque cloud cover, no precipitation, and no extremes in temperature, visibility, or wind. Flood Warning: Flooding has been reported or is imminent. Take the necessary precautions if you are in a ood-prone area. Flood Watch: Flooding is possible within the watch area. Sometimes this is called a Flash Flood Watch or an Urban and Small Stream Advisory to indicate the possibility of rapidly rising water and ooding or high water on streets, underpasses and around storm drains. Fog: A cloud with its base at the earths surface. Freeze: A condition occurring over a widespread area when the surface air temperature remains below freezing for a sufcient time to damage certain agricultural crops. Freezing rain/Drizzle: Occurs when supercooled rain or drizzle freezes upon contact with surfaces such as the ground, trees, power lines, etc. The supercooled temperature range for liquid water is between 32F and 40F. Front: The leading edge of an air mass; the transition zone between two distinct air masses. Frontal types include cold fronts, warm fronts, occluded fronts, and stationary fronts. Frost/Freeze Warning: Below-freezing temperatures are expected during the growing season and may cause signicant damage to plants and crops. Frost: A covering of ice produced by deposition on exposed surfaces when the air temperature falls below the frost point. Ice crystals produced from water vapor that has frozen on a surface at or below 32F/0C. Frostbite: The partial freezing of exposed parts of the body, causing injury to the skin and sometimes to deeper tissues. GOES: Geostationary Operational Environmental Satellite. Gust: A brief, sudden increase in wind speed with a uctuation greater than 10 knots during a period less than 30 seconds. Gust-front: The boundary between air owing into a thunderstorm and the precipitation-cooled air owing out of the storm. An arcus or shelf cloud may be seen above its surface position. There is a noticeable wind shift and temperature drop that occur when the gust-front passes by (similar to a cold front). Heat Advisory: Issued when the Heat Index is expected to exceed 105 during the day and 80 during the night for at least two consecutive days. Heat Index: Also known as the apparent temperature, it is a non-physical value that combines the effect of the air temperature and amount of moisture in the air to illustrate how it feels. Heavy snow: In general, snowfall is accumulating at the rate of either four inches or more in 12 hours or less, or six inches or more in 24 hours or less. Heavy surf: Large waves breaking on or near the shore resulting from swells spawned by a distant storm. Heavy Surf Advisory: A forecast of heavy (high) surf that may pose a threat to life or property.
Threat Denitions
211
High Wind Advisory: An advisory that sustained surface winds exceeding 25 mph over land are either predicted or occurring for an unspecied period of time. High Wind Warning: A warning for sustained surface winds greater than 40 mph, lasting more than an hour or winds over 58 mph over land that are either predicted or occurring for an unspecied period of time. High: An area of high pressure around which the wind blows clockwise in the Northern Hemisphere and counterclockwise in the Southern Hemisphere. Hurricane season: The part of the year having a relatively high incidence of hurricanes. In the Atlantic, Caribbean, Gulf of Mexico, and Central Pacic, the season is from June through November. The season begins two weeks earlier in the Eastern Pacic. Hurricane Warning: Hurricane conditions are expected within 24 hours. Complete all storm preparations and evacuate if directed by local ofcials. Hurricane Watch: Hurricane conditions (heavy rain, tidal ooding, and winds above 75 mph) are possible within 36 hours. Prepare to take immediate action in case a warning is issued. Jet Stream: Relatively strong winds concentrated within a narrow band in the atmosphere. La Nia: A large-scale cooling of the surface layers in the equatorial eastern and central Pacic Ocean. Lake effect: Warm lake water modies the weather along its shore and for some distance downwind. Low: A cyclonic storm that often forms along a front, around which the wind blows counterclockwise in the Northern Hemisphere and clockwise in the Southern Hemisphere. Meteorology: The study of atmospheric phenomena. Nor easter: An intense low-pressure system that tracks along the east coast of the United States, producing strong northeast winds, large waves, and intense precipitation. Occluded front: A composite of two fronts that usually occurs when a cold front overtakes a warm front. Overcast: Sky condition when greater than 9/10 of the sky is covered by clouds. Paroemieology: The study of weather folklore. Partly cloudy: Sky condition when between 3/10 and 7/10 of the sky is covered by clouds. Pressure: The force exerted by the weight of air above a given point, usually expressed in millibars (mb) or inches of mercury (in. Hg). Radar: A device used to detect precipitation by sending an electromagnetic signal and measuring the intensity of the reected energy (RAdio Detection And Ranging). Radiosonde: An instrument connected to a weather balloon that collects meteorological data as it ascends through the atmosphere. Relative humidity: The percent of the amount of water vapor in the air compared to the capacity for water vapor in the air.
212
Ridge: An elongated area of high pressure in the atmosphere. Scattered clouds: A sky condition when between 1/10 and 5/10 of the sky is covered by clouds. Sea breeze: A local wind that blows from a sea or ocean toward land. It is caused by the temperature difference between cool air above the water and the warmer land. The leading edge of the breeze is termed a sea breeze front. Severe thunderstorm: A thunderstorm with winds measuring 50 knots (58 mph) or greater, 0.75-inch hail or larger, or tornadoes. Severe thunderstorms may also produce torrential rain and frequent lightning. Severe Thunderstorm Warning: Issued when severe weather has been reported or is being indicated by Doppler radar. Warnings indicate imminent danger and the appropriate action should be taken. A warning is issued when a thunderstorm may produce wind gusts over 55 mph and/or 0.75-inch or larger hail. Severe Thunderstorm Watch: An outlined area where severe thunderstorms are more likely to occur within a certain timeframe. On News-4, this may sometimes be referred to as a watch box. During a watch, one should keep informed and watch the weather situation closely. Shower: Liquid precipitation with frequent changes in intensity or sudden stops or starts. Sleet: A type of frozen precipitation, consisting of small pellets produced by the freezing of raindrops as they fall. Smoke: Small particles produced by combustion that are suspended in the air. A transition to haze may occur when the smoke particles have traveled great distances (25 to 100 miles or more), and when the larger particles have settled out. The remaining particles become widely scattered through the atmosphere. It is reported as FU in an observation and on the METAR. Snow urry: Also referred to as a snow shower, a very light and brief period of snowfall. Snow squall: Intense showers or bands of locally heavy snow, often produced by the lake effect. Squall line: A non-frontal band, or line, of thunderstorms. Stationary front: A transition zone between air masses, with neither advancing upon the other. Stratus: A principal cloud type, gray in color, present at low altitudes with a uniform base. Surge: The increase in seawater height from the level that would normally occur was there no storm. Although the most dramatic surges are associated with hurricanes, even smaller low-pressure systems can cause a slight increase in the sea level if the wind and fetch are just right. It is estimated by subtracting the normal astronomic tide from the observed storm tide. Tornado Warning: A tornado has been reported or is being indicated as possible by Doppler radar. Immediate action should be taken. Tornado Watch: Same as a severe thunderstorm watch, but tornadoes are also possible in the Watch area.
Threat Denitions
213
Tropical depression: A tropical cyclone in which the maximum one-minute sustained surface wind is 38 mph or less. They form from a tropical wave or tropical disturbance. Tropical disturbance: A discrete system of apparently organized convection originating in the tropics or subtropics, having a non-frontal migratory character and maintaining its identity for 24 hours or more. Tropical Storm Warning: Tropical storm force winds are occurring or are expected within 24 hours. Tropical Storm Watch: Tropical storm force winds between 37 and 74 mph are possible in the next 36 hours. Trough: An elongated area of low atmospheric pressure. Virga: Falling precipitation that evaporates before reaching the ground. Warm front: The leading boundary of a warm air mass that is often moving into an area inuenced by a cooler air mass. Warning: A public notice issued by the National Weather Service when a certain hazard (tornado, severe thunderstorm, ood, or winter storm) is imminent. Watch: A public notice issued by the National Weather Service when conditions are such that a certain hazard (tornado, severe thunderstorm, ood, or winter storm) is possible. Waterspout: To ignore the technical differences, essentially a tornado over water. Can ruin a boaters day. Also can move over land and become a tornado. A tornadic waterspout is a tornado over water that can be very strong, while a true waterspout is actually somewhat different and much weaker (like an F0 tornado.) Wind chill: The accelerated heat loss from exposed skin due to increased wind speed. As a general rule, dangerous wind chill occurs at temperatures of 20F. Winter Storm Warning: Same as a Watch except conditions are expected to begin within 24 hours or have already begun. Winter Storm Watch: Severe winter conditions, such as accumulations of heavy snow and ice of four inches or more possible within the next 36 to 48 hours. Winter Weather Advisory: Winter weather conditions are expected to cause signicant inconveniences and may be hazardous. This can often be called a Snow Advisory or a Freezing Rain Advisory for the specic expected weather. A Snow Advisory is for less than four-inch accumulations.
Public Safety Department

The safety and security of all members and guests of the campus community are of primary concern to the University. The Department of Public Safety, under the administration of the V.P. of Administrative Services, is responsible for campus security at Murray State University and exists to provide a safe and secure learning and working environment for the University community. The Public Safety Department operates 24 hours a day, seven days a week with a highly effective and professionally trained body of law enforcement
214
ofcers and support staff. Twelve ofcers are sworn to assist, serve, and protect members of the University community and affords each member of the community freedom from the fear and anxiety of crime. MSU law enforcement ofcers undergo extensive background investigation and successfully complete 16 weeks of police academy training in the law, arrest procedures, driving skills, rearms, and physical tness; and are certied by the Kentucky Law Enforcement Council. Mandatory, individual training programs ensure that each ofcer maintains his/her prociency in law enforcement and emergency medical procedures, rst aid, and CPR. Ofcers conduct vehicle and foot patrols on campus and are charged with the enforcement of state and local laws, as well as University policies and regulations. The Public Safety Department maintains a working relationship with the Murray City Police Department, Calloway County Sheriffs Department, and the Kentucky State Police. Cooperative efforts between University and local law enforcement agencies provide for accurate and prompt notication and reporting of any incidents which may occur at off-campus locations in accordance with Uniform Crime Reporting, a periodic review of off-campus incidents performed by a University investigating ofcer. Students, faculty, staff, and guests of the University are encouraged to report emergencies and criminal activity to the Public Safety Ofce. To report an emergency, dial 911 from any university telephone or push the button on any exterior emergency telephone on campus. The exterior emergency phones automatically connect to the Public Safety Ofce when the button is pushed. University law enforcement ofcers with arrest authority are immediately dispatched to the site of the complaint. We strongly encourage adherence to all University, local, state, and federal laws and rules of conduct, as well as a modicum of common sense to assure maximum security. The possession, use, storage, or sale of alcohol, illegal drugs, or drug paraphernalia on grounds or property controlled by the University and/or while engaged in University business is prohibited. Possession or use of rearms, ammunition or other weapons, including any dangerous article or substance with the potential to injure a person, is prohibited.
Threat Denitions
215
1996 Rate 1997 Rate 1998 Rate
Criminal Offenses
Alcohol intoxication Arson Assault Burglary Concealed weapon Criminal mischief Criminal trespass Disorderly conduct Drinking in a public place False name Harassing communication Hate crime Homicide Illegal transport/delivery alcohol Indecent exposure Loitering Menacing Motor vehicle theft Possession alcohol by minor Possession controlled substance Possession drug paraphernalia Possession marijuana Promoting contraband Public intoxication Rape Receiving stolen property Resisting arrest Robbery Sexual abuse Stalking Suicide Terrorist threatening Theft auto plate Theft of mail Theft by unlawful taking Trafcking in marijuana Trafcking within 1000 yds. school Unlawful transaction (minor) alcohol Wanton endangerment Total Cases Opened by MSU Police
19 0 9 23 2 34 8 11 0 1 4 0 0 1 1 0 1 0 7 0 11 11 1 3 0 1 2 0 3 1 0 2 5 1 111 0 0 2 1 276
0.0023 0.0000 0.0010 0.0028 0.0002 0.0041 0.0009 0.0013 0.0000 0.0001 0.0004 0.0000 0.0000 0.0001 0.0001 0.0000 0.0001 0.0000 0.0008 0.0000 0.0013 0.0013 0.0001 0.0003 0.0000 0.0001 0.0002 0.0000 0.0003 0.0001 0.0000 0.0002 0.0006 0.0001 0.0106 0.0000 0.0000 0.0002 0.0001
11 0 12 34 1 25 3 3 5 1 3 1 0 0 0 1 2 0 15 1 11 17 0 0 3 0 0 0 0 1 0 3 3 1 87 1 2 1 1 246
0.0012 0.0000 0.0014 0.0040 0.0001 0.0029 0.0003 0.0003 0.0005 0.0001 0.0003 0.0001 0.0000 0.0000 0.0000 0.0001 0.0002 0.0000 0.0017 0.0001 0.0013 0.0020 0.0000 0.0000 0.0003 0.0000 0.0000 0.0000 0.0000 0.0001 0.0000 .0003 .0003 0.0001 0.0103 0.0001 0.0002 0.0001 0.0001
6 2 5 8 0 39 3 1 2 0 1 0 1 0 0 0 0 0 4 0 4 11 0 0 0 0 0 1 0 0 0 3 1 1 88 1 0 0 2 184
0.0007 0.0002 0.0005 0.0009 0.0000 0.0046 0.0003 0.0001 0.0002 0.0000 0.0001 0.0000 0.0001 0.0000 0.0000 0.0000 0.0000 0.0000 0.0004 0.0000 0.0004 0.0012 0.0000 0.0000 0.0000 0.0000 0.0000 0.0001 0.0000 0.0000 0.0000 0.0003 0.0001 0.0001 0.0103 0.0001 0.0000 0.0000 0.0002
Note: D.U.I. is NOT a criminal offense in Kentucky; it is a trafc violation.
Appendix F
Other Risk Analysis Opinions

Included in this book are articles created by other risk analysis industry leaders. These articles were published by Aurebach Publications and are part of their very thorough series on security management issues. Each of these articles was selected for a number of reasons. First of all, they provide additional viewpoints. Second, while they may initially seem to be in conict with each other and the material presented in this book, they are in fact exactly what the reader needs: more subjective information. Some of the phrases may be different from what has been presented in this book. What the reader must look for is the message. Concentrate on what is being said and use all of the information presented to create your own risk analysis process. Your enterprises risk analysis program will reect your own opinions and views.
Risk Assessment and Management, by Will Ozier

Will Ozier and this author have traveled in the same conference circles for years. I rst remember discussing risk analysis with Will at the 1991 Computer Security Institutes (CSI) 18th Annual Conference in Miami Beach. CSI had just recently asked me to conduct two-day workshops on risk analysis and Will, being an identied industry expert, sought me out to discuss the course and what he could do to help. Ozierzs article, entitled Risk Assessment and Management, will reinforce the concepts and principles discussed throughout this book. Where one sees a difference in terms, remember to look at the concept. One will see that where a term may be a little different, the concept is the same.
217
218
One of the most important elements of this article is Oziers section on Selecting the Best Automated Risk Management Tool, Wherein he identies risk management software packages and develops a checklist for comparing these products. The list of products is from 1997, so one may want to access a more current listing of available products. These can be obtained from sources such as Gartner, Meta, GIGA, DataPro, or the CSI Buyers Guide. When reviewing commercially available products, do not to forget to identify what operating environment the product works with. In addition to risk software, many vendors offer risk analysis services using their own process. Use Oziers checklist as a starting point for the development of a checklist for your own enterprise. As a starting point, be sure to include in checklist items such as budget requirements, to include initial cost, annual maintenance fees, and consulting support. One will also want to include the technical support available to implement an automated risk analysis software product and what platforms or operating systems the software will require. A discussion about training availability should be done with each vendor and what level of administrative support will be required to keep the risk analysis database current. Finally, if possible, attempt to get the names of current users. If there is a users group, this would be a good group to meet with to discuss their efforts in implementing the software.
New Trends in Risk Management, by Caroline R. Hamilton

This author has had the great good fortune to meet and work with Caroline Hamilton, who has a unique and refreshing personality and takes a nononsense approach to risk analysis. This article takes the reader into areas discussed in Chapter 6 and reinforces the concepts discussed there. In the section headed New Directives and Guidelines, Hamilton provides quotes to reports that have been updated. The General Accounting Ofce (GAO) has issued GOA/AIMD-98-68 Information Security Management, which offers risk management solutions to the problems identied in the report referenced in this article. Additionally, the Computer Security Institute (CSI) issues the annual FBI/CSI Computer Crime Survey and has its results available on their Web site (www.gocsi.com). The reader will nd that there may be some differences in word usage, but the concepts remain the same. Use this material to help develop your own risk analysis process.
Integrated Risk Management A Concept for Risk Containment, by Jose Martinez

Jose Martinez is a consultant in the San Francisco Bay area and his article brings the concept of integrated risk management back for another discussion.
Other Risk Analysis Opinions
219
Just as in the GAO article discussed in Chapter 1, Martinez takes those concepts and builds on them by introducing the idea of an owner being responsible for the protection of enterprise assets. In the section entitled Roles and Responsibilities, Martinez discusses data ownership. The person responsible for the implementation of risk, should view this responsibility as the asset functional owner. Owner will be a key word in any set of policies implemented by an enterprise. Make certain that the phrase used meets all legal requirements. Martinez identies Management and Staff Responsibilities in the next section of the article. Please take note of the key roles that Executive Management plays in this risk management process. It will be necessary to establish this level of responsibility throughout the enterprise. Part of this process will be accomplished by policy, and the acceptance will be accomplished through an awareness program and monitoring for compliance. This article is a blueprint for an effective information security program developed through the implementation of a risk management program. The concepts here will help the reader understand where risk analysis resides within an enterprisewide information security program. Use the contents of this article and the GAO report discussed in Chapter 1, along with the NIST Special Publication 800-12 An Introduction to Computer Security: The NIST Handbook, as guides in developing your own program.
Other Resources
The Auerbach publication Information Security Management Handbook offers a section on Risk Management. The articles in this section are also benecial in that they provide additional sources of risk analysis thought and implementation. This handbook is updated annually, so be certain to get the most current copy.
Appendix F1
Risk Assessment and Management*

Will Ozier
The information risk management process of identifying, assessing, and analyzing risk is poorly understood by many people. Although information risk management is a relatively new and powerful concept, it is often shunned or given half-hearted support even when regulation requires it precisely because it is not well understood. Yet there are information risk management tools available and evolving that are capable of enabling management to identify, understand, and manage information risk.
Key Terms and Concepts of Risk Assessment

To discuss the history and evolution of information risk assessment and analysis, several terms whose meanings are central to this discussion must rst be dened.
Annualized Loss Expectancy or Exposure (ALE)

This value is derived from the following algorithm (see also, later in this section, the denition for Single Loss Expectancy [SLE]): For Single Loss Annualized Rate = Annualized Loss Expectancy of Occurrence Expectancy To effectively identify risk and to plan budgets for information risk management and risk mitigation activity, it is helpful to annualize loss expectancy
* Ozier, Will, Risk Assessment and Management, Data Security Management, AIMS, CRC Press LLC, 1995.
221
222
for threats that have a signicant chance of occurring. For example, the preceding algorithm shows that the ALE for a threat (with an SLE of $1 million) that is expected to occur about once in 10,000 years is $1 million divided by 10,000, or only $100. When the expected threat frequency is considered (see the denition for annualized rate of occurrence [ARO]) in addition to the SLE, the signicance of specic risk factors is addressed and integrated into the information risk management process. Thus, risk is more accurately portrayed, and cost-benet analysis of risk reduction measures is better supported.
Annualized Rate of Occurrence (ARO)

This risk element represents the frequency with which a threat is expected to occur on an annualized basis. For example, a threat occurring once in ten years has an ARO of 1/10 or 0.1; a threat occurring 50 times in a given year has an ARO of 50.0. The possible range of frequency values is from 0.0 (the threat is not expected to occur) to some whole number whose magnitude depends on the type and population of threat sources. For example, the upper value could exceed 100,000 events per year for frequently experienced threats such as misuse of resources.
Business Impact Analysis (BIA)

This process is often conducted in place of a risk assessment to establish (1) what is at risk and (2) the impact on an organization if a threat event occurs and denies the organization the use of the impacted resources. The BIA may be done either qualitatively or quantitatively. The BIA may be compared, at least supercially, to the Single Loss Exposure (SLE) described below. As with the SLE, the BIA does not consider the probability of the event or the loss. Thus, it provides little budgetary support, only the stark illustration that a disaster affecting the information technology environment could be, well, catastrophic to the organization. This realization often galvanizes management to spend often unjustied sums on Contingency Planning for the business units and the Information Technology environment.
Exposure Factor (EF)

This risk element represents a measure of the magnitude of loss or impact on the value of an asset, expressed within a range from 0 to 100 percent loss arising from a threat occurrence. This term is used in the calculation of SLE, which is dened later in this section.
Qualitative or Quantitative
These terms indicate the method of categorizing risk and information risk management techniques. There is a spectrum across which these terms apply,
Risk Assessment and Management
223
virtually always in combination, which may be described as the degree to which the risk management process is quantied. If all measurable risk elements asset value, impact, threat frequency, safeguard effectiveness, safeguard costs, uncertainty, and probability are quantied, the process may be characterized as fully quantitative. It is virtually impossible to conduct a purely quantitative risk management project because the quantitative measurements must be applied to the qualitative properties of the target environment. However, it is possible to conduct a purely qualitative risk management project. A vulnerability analysis, for example, may identify only the presence or absence of risk-mitigating safeguards (though even this simple qualitative process has a quantitative element in its binary method of evaluation). In summary, risk assessment techniques should be described not as either qualitative or quantitative, but in terms of the degree to which such elementary factors as asset value, exposure factor (impact), and threat frequency are assigned quantitative values.
Probability
This is the chance or likelihood, in a nite sample, that an event will occur. For example, the probability of rolling a six on a single roll of a die is 1/6, or 0.16667. The possible range of probability values is 0.01.0. A probability of 1.0 expresses certainty that the subject event will occur within the nite interval.
Risk
This is the potential for loss, best expressed as the answer to four questions: What could happen? (What is the threat?) How bad could it be? (What is the consequence?) How often might it happen? (What is the frequency?) How certain are the answers to the rst three questions? (What is the degree of uncertainty?)
Risk Analysis
This is the process of analyzing a target environment and the relationships of its risk-related attributes. The analysis should identify threats, and threat vulnerabilities, associate these vulnerabilities with potentially affected assets, identify the potential for and nature of an undesirable result, and identify and evaluate risk-mitigating safeguards.
Risk Assessment
This represents the reported results of a risk analysis process. The reported results of risk analysis can be said to provide an assessment or measurement
224
of risk, regardless of the degree to which quantitative techniques are applied. For consistency in this article, the term risk assessment is used to characterize both the process and the result of analyzing and assessing risk.
Risk Management
This is the process of identifying risks, risk-mitigating measures, the budgetary effect of implementing decisions related to the acceptance, avoidance, or transfer of risk. The nal phase of risk management includes the process of assigning priority to, budgeting, implementing, and maintaining appropriate risk-mitigating measures in a continuous or periodic cycle of analysis, assessment, and management or administrative action.
Safeguard
This is a risk-mitigating measure that acts to detect, prevent, or minimize loss associated with the occurrence of a specied threat or category of threats. It is also described as a control or countermeasure.
Safeguard Effectiveness
This is the degree, expressed as a percentage, from 0100 percent, to which a safeguard may be characterized as effectively minimizing a vulnerability (see the denition of vulnerability later in this section) and mitigating associated risks.
Single Loss Expectancy or Exposure (SLE)

This is a value derived from the following algorithm to establish the expected monetary loss for each occurrence of a threat event: the SLE, or similar value, is often an end result of a business impact analysis (BIA). A BIA typically stops short of evaluating the related threats frequency of occurrence or its signicance. The SLE represents only one element of risk, the expected monetary effect of a specic threat event.
Threat
This denes an undesirable event that could occur (e.g., a tornado, theft, or computer virus infection).
Uncertainty
This is the degree to which there is less than complete condence in the value of any element of the risk assessment. Uncertainty is typically measured
225
inversely with respect to condence, from 0.0100 percent (i.e., if uncertainty is low, condence is high).
Vulnerability
This is the absence or weakness of a risk-mitigating safeguard: it is a condition that has the potential to allow a threat to occur with greater frequency or greater impact.
Central Tasks of Risk Management

The following section describes the assessment tasks central to the comprehensive information risk management process. These tasks provide concerned management with the identication and assessment of risk as well as with cost-justied recommendations for risk mitigation, thus allowing the execution of well-informed management decisions whether to avoid, accept, or transfer risk cost-effectively. The degree of quantitative Asset Value Exposure Factor = Single Loss Expectancy orientation determines how the results are characterized and, to some extent, how they are used.
Project Sizing
This is the identication of background, scope, constraints, objectives, responsibilities, and management support. Clear project-sizing statements are essential to a well-dened and well-executed risk assessment project.
Asset Identication and Valuation

This is the identication of assets and their replacement costs and the further valuing of information asset availability, integrity, and condentiality. These values may be expressed in monetary or nonmonetary terms. This task is analogous to a BIA.
Threat Analysis
This is the identication of threats that may affect the target environment. (This may be integrated with the next task, vulnerability analysis).
Vulnerability Analysis
This is the identication of vulnerabilities that could increase the chance or the expected magnitude of loss of a threat occurring in the target environment.
226
Risk Evaluation
This is the association and evaluation of information regarding threats, vulnerabilities, assets, and asset values in order to measure the related chance of loss and the expected magnitude of loss, usually in monetary terms and typically on an annualized basis.
Safeguard (Controls and Countermeasures) Analysis

This is the evaluation of risk associated with threat, assets, vulnerability combinations with respect to the identication of risk-mitigating measures that eliminate or minimize vulnerabilities.
Cost/Benet Analysis
This is the valuation of the degree of risk mitigation that is expected to be achieved by implementing the selected risk-mitigating measures (safeguards). The gross benet less the annualized cost to achieve mitigated risk yields the net benet. Tools such as present value and return on investment are applied to further measure safeguard cost-effectiveness.
Interim Reports and Recommendations

These key reports are issued during this process to document signicant activity, decisions, and agreements related to the project: Project sizing. This report presents the results of the project sizing task. The report is issued to senior management for its review and concurrence. This report, when accepted, assures that all parties understand and concur in the nature of this project. Asset valuation. This report details and summarizes the results of the asset valuation task as appropriate. It is issued to responsible senior management for their review and concurrence. Such review helps prevent conict about value later in the process. Risk evaluation. This report presents management with a documented assessment of risk in the current environment. Management may choose to accept that level of risk (a potentially legitimate management decision) with no further action or to proceed with a risk-reduction analysis.
Final Report
This report includes the interim reports as well as recommendations from the safeguard analysis, selection, and supporting cost/benet analyses. There are numerous variations in this risk management process, based on the degree to which the technique applied is quantitative and how thoroughly
227
all steps are executed. For example, the asset identication and valuation analysis could be performed independently as a BIA; the vulnerability analysis could also be executed independently. It is commonly but incorrectly assumed that information risk management is concerned only with catastrophic threats, that it is related only to contingency planning. A well-conceived and well-executed risk assessment can also effectively identify and quantify the consequences of a wide array of threats that can and do occur as a result of ineffectively implemented or nonexistent management and operational controls. A well-run and integrated information risk management program can help management to signicantly improve the cost-effective performance of its information systems environment and to ensure cost-effective compliance with regulatory requirements. The integrated risk management concept recognizes that many, often uncoordinated units within an enterprise play an active role in managing the risks associated with the failure to assure the condentiality, availability, and integrity of information.
A Review of the History of Risk Assessment

To better understand the current issues and new directions in risk assessment and management, it is useful to review the history of their development. The following sections present a brief overview of key issues and developments, from the 1970s to the present.
Sponsorship, Research, and Development During the 1970s

During the early 1970s, the National Bureau of Standards (now the National Institute of Standards and Technology [NIST]) perceived the need for a riskbased approach to managing information security. The Guideline for Automatic Data Processing Physical Security and Risk Management (FIPSPUB-31, June 1974), though touching only supercially on the concept of risk assessment, recommends that the development of the security program begin with a risk analysis. Recognizing the need to develop a more fully articulated risk assessment methodology, NIST engaged Robert Courtney and Susan Reed to develop the Guideline for Automatic Data Processing Risk Analysis (FIPSPUB65, Aug. 1979). At about the same time (July 1978), the Ofce of Management and Budget developed OMB A-71, a regulation that, in its Appendix C, established the rst requirement for periodic execution of quantitative risk assessment in all government computer installations and other computer installations run on behalf of the government. As use of FIPSPUB-65 expanded, difculties became apparent. Chief among these were the lack of valid data on threat frequency and the lack of a standard for valuing information. A basic assumption of quantitative approaches to risk management is that objective and reasonably credible quantitative data is
228
available or can be extrapolated. Conversely, a basic assumption of qualitative approaches to risk management is that reasonably credible numbers are not available or are too costly to develop. In other words, to proponents of qualitative approaches, the value of assets (particularly the availability of information, typically expressed as a function of the cost of its unavailability) was considered difcult if not impossible to express, with condence in monetary terms. They further believed that related statistical data were unreliable or nonexistent. Despite the problems, the underlying methodology was sufciently well-founded for FIPSPUB-65 to become the de facto standard for risk assessment. During the early 1970s, the U.S. Department of Energy (DOE) initiated a study of risk in the nuclear energy industry. The standard of technology for nuclear engineering risk assessment had to meet rigorous requirements for building credible risk models based primarily on expert opinion, given the lack of experience with nuclear threats. The resulting document, the Nuclear Regulatory Commission Report Reactor Risk Safety Study (commonly referred to as the WASH 1400 Report) was released in October 1975. The rigorous standards and technical correctness of the WASH 1400 Report found their way into the more advanced information risk management technologies, as the need for a technically sound approach became more apparent.
Changing Priorities During the 1980s

During the 1980s, development of quantitative techniques was impeded by a shift in federal government policy regarding the use of quantitative risk assessment. On December 12, 1985, OMB A-130, Appendix III, which required a formal, fully quantied risk analysis (only in the circumstance) of a largescale computer system, replaced OMB A-71, Appendix C, which required quantitative risk assessment for all systems, regardless of system size. For those whose pressing concern was to comply with the requirement (rather than to proactively manage risk), this minor change in wording provided relief from what was perceived to be the more difcult efforts necessary to perform quantitative risk assessments.
The NIST Framework

In an attempt to develop a denitive framework for information risk assessment that is technologically sound and meets the varying needs of a multitude of information processing installations, NIST established and sponsored the International Computer Security Risk Management Model Builders Workshop during the late 1980s. The results of this NIST-sponsored effort served to provide a more comprehensive, technically credible federal guideline for information risk management. An early result of this working groups efforts was the recognition of
229
Exhibit F1.1
NIST information risk management framework.
the central role uncertainty plays in any risk assessment. The central role is illustrated in the NIST Information Risk Management Framework in Exhibit F1.1.
Problems
During the 1980s, implementation of risk assessment methodologies encountered major obstacles. Manually executed risk assessment projects could take from one to two work months for a high-level, qualitative analysis to two or more work years for a large-scale, in-depth quantitative effort. Recommendations resulting from such lengthy projects were often out of date, given changes that would occur in the information processing environment during the course of the project before they were delivered. Efforts often bogged down when attempts were made to identify asset values (especially the values of intangible assets) or to develop valid threat frequency data. Another problem resulted from use of oversimplied risk assessment algorithms (based on FIPSPUB-65) that were incapable of discriminating between the risks of a low-frequency, high-impact threat (e.g., a re) and a high-frequency, low-impact threat (e.g., misuse of resources). Exhibit F1.2 illustrates this problem. The resultant ALE of $50,000 for re and $60,000 for misuse of resources appears to indicate that the risks of re and misuse of resources are the same. Managers refused to accept such an analysis. Intuitively they understood that re is a greater threat. Management was willing to spend substantial sums to
230
Exhibit F1.2 Oversimplied Algorithms Cannot Distinguish Between Threat Types

Annualized Rate of Occurrence Annualized Loss Expectancy =
Threat ID
Asset Value =
Exposure Factor
Single Loss Expectancy
Fire 0.00005 = $50
$1.0M
0.5 = $500,000
0.1 1000
= =
$50,000 $50,000
Misuse of resources
$1.0M
231
avoid or prevent a devastating re, but it would spend only minor sums on programs to prevent misuse of resources. This sort of anomaly seriously undermined the credibility of quantitative risk assessment approaches. In response to such concerns, some software packages for automated information risk management were developed during the 1980s. Several stand out for their unique advancement of important concepts. RISKPAC, a qualitative risk assessment software package, did not attempt to fully quantify risks but supported an organized presentation of the users subjective ranking of vulnerabilities, risks, and consequences. Although this package was well received, concerns about the subjective nature of the analysis and the lack of quantitative results that could be used for information security budget decisions persisted. As can readily be seen, the ALE for each threat, based on the classic algorithm, is $50,000 and $60,000, respectively. Thus, given these ALE values, the risk of re was represented to be less than the risk of misuse of resources. No manager bought that story. Clearly, re is a more devastating threat when it occurs, and substantial monetary sums might be spent to avoid or minimize it. To prevent misuse-of-resources losses, however, minor sums might be spent on a policy statement and awareness programs making it clear that anyone caught misusing resources would be rst warned then red. Thus, the credibility of quantitatively oriented information risk management techniques suffered yet another blow. Momentum continued to build, however, toward the development of automated information risk management technology that was easy to use, technically credible, and cost-effective. Several packages stand out for their unique advancement of important concepts. During the mid-1980s, work began simultaneously on two risk assessment offerings that represented a technological breakthrough: the Bayesian Decision Support System (BDSS) and the Lawrence Livermore Laboratory Risk Analysis Methodology (LRAM). LRAM was later automated and became ALRAM. Both BDSS and ALRAM applied technically advanced risk assessment algorithms from the nuclear industry environment to information security, replacing the primitive algorithms of FIPSPUB-65. Although both packages use technically sound algorithms and relational database structures, there are major differences between them. BDSS is an expert system that provides the user with a comprehensive knowledge base that addresses vulnerabilities and safeguards as well as threat exposure factors and frequency data. All are fully mapped and cross-mapped for algorithmic risk modeling and natural language interface and presentation. ALRAM, however, requires an expert to build and map knowledge bases and then to conduct a customized risk assessment. The Buddy System, an automated qualitative software package, can be used to determine the degree to which an organization is in compliance with an array of regulatory information security requirements. This package has been well received in government organizations. Several other risk management packages were introduced during the 1980s, though some have not survived. A list of risk management software packages is provided in Exhibit F1.3.
232 Exhibit F1.3 Risk Management Software Packages
ARES. Air Force Communications and Computer Security Management Ofce. Kelly AFB, Texas @RISK. Palisade Corp. Neweld, New York Bayesian Decision Support System (BDSS). OPA, Inc. The Integrated Risk Management Group Control Matrix Methodology for Microcomputers. Jerry FitzGerald & Associates. Redwood City, California COSSAC. Computer Protection Systems, Inc. Plymouth, Michigan CRITICALC. International Security Technology. Reston, Virginia CRAMM. Executive Resources Association. Arlington, Virginia GRA/SYS. Nander Brown & Co. Reston, Virginia JANBER. Eagon. McAllister Associates, Inc. Lexington Park, Maryland LAVA. Los Alamos National Laboratory. Los Alamos, New Mexico MARION. Coopers & Lybrand (U.K.-based). London, England Micro Secure Self Assessment. Boden Associates. East Williston, New York Predictor. Concorde Group International. Westport, Connecticut PRISM. Palisade Corp. Neweld, New York QuikRisk. Basic Data Systems. Rockville, Maryland RA/SYS. Nander Brown & Co. Reston, Virginia RANK-IT. Jerry FitzGerald & Associates. Redwood City, California RISKCALC. Hoffman Business Associates, Inc. Bethesda, Maryland RISKPAC. Prole Analysis Corp. Ridgeeld, Connecticut RISKWATCH. Expert Systems Software, Inc. Long Beach, California The Buddy System Risk Analysis and Management System for Microcomputers. Countermeasures, Inc. Hollywood, Maryland
Information risk management software can help improve organizational efciency and focus the analysts attention on the most signicant risk factors. Even relatively primitive risk assessment software can reduce the work effort by 20 percent to 30 percent; some knowledge-based packages have demonstrated work reduction of 80 percent to 95 percent. Knowledge-based packages are particularly effective in helping analysts to bypass superuous information gathering and the unnecessary analysis and renement of insignicant information.
Current Developments in Risk Assessment and Management

There is a growing acceptance of information risk assessment as a valid and valuable management tool. This is particularly true of quantitative techniques. Several factors have played a role in this growing acceptance, including technical and legal developments. In fact, recent trends indicate a shift toward quantitative tools, as experience with qualitative tools has graphically demonstrated their inability to provide the necessary support for budgetary decision-making.
233
Technical Developments
Technical progress in the following two areas has played a signicant role in the increasing acceptance of information risk assessment as a management tool: Substantial research, done in part to facilitate automated approaches, has gone a long way toward establishing the credibility of relevant threat frequency data. Research and experience with information valuation techniques has demonstrated that credible and meaningful information values, including the value of availability, can be developed with no more than reasonable effort. The development of user-friendly, readily accessible, microcomputer-based information risk management software has helped to improve acceptance of the concept and utility of information risk assessment technology. The use of statistically sound processes and algorithms based on risk assessment technology from the nuclear industry has enhanced the technical credibility of the more advanced, quantitative information risk assessment software. In 1992, the Committee to Develop Generally Accepted System Security Principles (GASSPC) was established to execute recommendation #1 of the National Research Council report Computers at Risk, to develop and promulgate generally accepted system security principles (GASSP). This internationally populated GASSPC continues work, on a voluntary basis, to accomplish this complex task. Their approach has been to establish a framework, an authoritative foundation of related works, and a hierarchy of increasingly detailed principles (Pervasive Principles, Broad Functional Principles, and Detailed Principles), all developed and accepted through a two-staged consensus process, drawing on the authoritative foundation. This effort is being coordinated with a number of professional and industry organizations in the United States and abroad. At the time of this writing, the Pervasive Principles are being issued in nal form after multiple exposure drafts, and the Broad Functional Principles rst exposure draft is about to be released. It is expected that the International Information Security Foundation (I2SF), formed to secure nancial support and provide governance for the GASSPC (also as recommended by the CAR report), will be funded and begin more aggressive support for the GASSP project in the near future. Development and acceptance of the GASSP is expected to contribute signicantly to the understanding and implementation of sound information security while providing further support for credible risk assessment. An added benet is provision of a reliable framework by which the insurance industry can begin writing and offering previously unavailable lines of insurance targeting information security risks.
234
Regulatory Developments
The American Institute of Certied Public Accountants (AICPA) published, in 1994, the Committee of Sponsoring Organizations (COSO) Treadwell Commission Report Internal Control, Integrated Framework, for implementation in 1997. This report recognizes the important role of risk and the need to identify and manage the risks that may affect an organization. While risks in all areas of business or mission activity are recognized for consideration, the risks associated with information and the Information Technology environment are singled out, reecting the perceived and demonstrable consequences the loss of information availability, condentiality, or integrity can have on an organization. This report stipulates the use of quantitative, probabilistic risk assessment. In other words, management must consider the nancial value of assets at risk in monetary terms; impact, frequency, and expected loss for a variety of threats; and cost/benet analysis of selected risk mitigation measures. A revision of OMB A-130 Appendix C, released 1996, has, unfortunately, clouded the issue signicantly. While talking of the need to identify threats, vulnerabilities, expected loss potentials, and probability, as well as safeguards and risk mitigation cost/benet analysis, it explicitly eschews risk analysis. Further, due to budgetary constraints, the NIST Risk Model Builders Workshop series has been suspended, and NIST no longer participates in the GASSP project (see below), leaving the United States as one of the few countries not having government representation on the GASSP Committee.
Legal Developments
The federal government has taken a leadership position on information risk management by implementing several laws and regulations addressing computer security and information risk management. These laws and regulations include: OMB-A-130, Appendix III (Dec. 1985). This regulation spells out requirements for conducting information risk assessment in all federal computer facilities. The Computer Security Act of 1987. This law requires every federal organization to submit a computer security plan to NIST for review and approval. These plans are to include information risk assessment. BC-177, BC-226, and BC-229. These regulations require federally chartered banks to prepare business resumption and disaster recovery plans and to assess risk in so doing. BL-22-88. This regulation expands on BC-177, BC-226, and BC-229 to address contingency planning for all nancial institutions. There are many who advocate extending these requirements to include all private sector organizations whose work relates to national security. State and some local governments have established information security requirements that include information risk assessment. California, at the direction
235
of the states Ofce of Information Technology, has successfully implemented an information security and risk management policy in the State Administrative Manual requiring quantitative risk assessment. In 1987, the Florida Information Resource Commission successfully implemented an information risk management policy requiring qualitative risk assessment, and that commission is now considering converting this policy to require the use of quantitative risk assessment technology. Numerous other states are at various stages of developing policies and regulations on information risk management. The U.S. Department of Health and Human Services (DHHS) is encouraging state agencies that interact with DHHS to assess risk by offering expanded federal funding for systems development and support if information risk assessment projects are executed on state information processing systems. The U.S. Department of Labor is similarly encouraging information risk assessment at the state level.
Current Issues Affecting the Acceptance of Information Risk Management

Several problems persist that limit the acceptance of information risk management. In general, management lacks awareness and understanding of the need and capability to manage risk, except for basic issues related to insurance. Some managers simply choose to ignore all but the most obvious risks because they consider the chance of a major threat to be remote. Others view the concept of proactive integrated risk management as an unproductive expense or an impediment to productivity. Some argue that it is difcult if not impossible to obtain reliable data on which to base a risk assessment, such as threat frequency and effect and exposure factors. Most ominous are those managers who do not want to know what risks they have unknowingly accepted for fear of losing their jobs. Although software and databases capable of providing and analyzing such data are available, knowledge of their existence is not yet widespread. Difculties in executing manual risk assessments have also contributed to resistance. Manual information risk assessment is a tedious, time-consuming, and expensive process requiring expert support. With manual assessments, the volume of data to be gathered and analyzed can be daunting; deciding which information is signicant and which is superuous can further cloud the issue, especially for inexperienced analysts. Recommendations are typically issued many months from the time observations were made; during this time, the target environment may have changed signicantly. Updating a risk assessment manually is equally impractical.
New Directions in Risk Assessment and Management

As technical and conceptual problems are solved, expanding awareness, use, and development of information risk management technologies can be
236
expected. Substantial groundwork in several areas should provide a basis for continued progress in the evolution and acceptance of these tools. These developments are discussed in the following sections.
Information Valuation
The Information Systems Security Association (ISSA), a professional association for information security practitioners, sponsored a Corresponding Committee for Information Valuation that began work in late 1988. More than 4000 work hours were expended on development of the Guideline for Information Valuation. This committee of leading experts completed and formally released the Guideline for Information Valuation in 1993, which establishes a rigorous and systematic approach to valuing information. As most quantitative information risk management technologies require a monetary valuation of information assets, this guideline provides a solid basis for executing an information risk assessment.
The NIST Framework for Product Design and Evaluation

Participants in the International Computer Security Risk Management Model Builders Workshop series, sponsored by NIST, completed development of a framework for information risk assessment. This framework dened the terms, concepts, and methodologies of information risk management for developers of methodologies and automated tools and for users who need to evaluate these methodologies and tools. In particular, the framework explicitly identies uncertainty as a central element of risk that must be effectively addressed in any meaningful risk assessment. Developers are given clear direction as to the essential elements of the risk assessment, which will permit them to develop competitive features without losing focus on these essential design elements. Users are provided with a metric for evaluating whether methodologies and tools satisfy essential requirements of their organizations. Although this framework was developed primarily as a guide for federal organizations, it is expected to be accepted by other government organizations as well as the private sector. It is expected that the framework will amend or replace FIPSPUB-65.
Integrated Risk Management

Information risk management is often the responsibility of several diverse business units, often with little or no management relationship among them. Integrated risk management methodologies provide a common metric device by which these diverse organizational units can coordinate and responsibly manage risk. By providing an independent assessment of risk, integrated risk management tools can provide objective budgetary justication for a reallocation of
237
existing resources or the allocation of new resources and can allow management to set budgetary and task priorities that are clearly in the best interests of the organization. Of perhaps equal importance, management is provided with a credible basis to make informed decisions whether to accept, avoid, or transfer risk. Note that each of these choices is within the legitimate domain of well-informed management.
Strategic Risk Management

Risk assessment was originally conceived to assess the risks in a specic Information Technology environment at a specic time. Increasingly, it is being used (now that advances in automation and tools has enabled complex whatif modeling to be done in minutes if not seconds) to evaluate risk strategically among a variety of alternative strategies. Risk assessment has often provided denitive decision support in this application.
Reliability of Threat Frequency Data

Substantial research has been conducted in the past few years to establish statistically sound threat frequency data. As described earlier in this article, the BDSS risk assessment software product includes, as part of its extensive and well-researched knowledge base, a threat frequency database that permits users to integrate site-specic threat experience into its risk-modeling algorithms. The current databases of threat frequency (and exposure factors) have an 80 percent condence level. As the population of BDSS users grows, and as users threat experience is tabulated for BDSS, the condence level is expected to increase to 90 percent or greater. Other researchers are also accumulating information systems experience data. Continued research and development in this area should help to dispel concern about the credibility of threat frequency data.
Knowledge-Based Automation
Products that apply knowledge engineering principles help manage the inherently subjective processes of risk assessment. The cross-fertilization of knowledge bases, articial intelligence technology, and risk assessment methodologies is expected to continue, leading to more powerful tools to support the risk analyst.
Improving Hardware and System Performance

Rapid improvements in microcomputers, storage media, operating system software, and display capacity and performance has facilitated the development of powerful automated tools that could not have been effectively supported on microcomputers even a few years ago. Risk analysts are now able to use
238
these tools to execute what-if analyses in real-time and will soon have access to custom-developed risk models of their information systems environments. Increased computer power and exibility will allow probabilistic risk assessment technology to be incorporated into such areas as real-time emergency management to support decision-making in critical, high-risk situations.
Regulatory Requirements
Continuing incidents of computer abuse and disaster are helping promote an informed awareness of risk and the ability to manage risk. This concern, in turn, is leading to increased legislation as well as criminal and civil litigation. Particularly noteworthy is the increase in liability litigation for negligence and duciary loss. Formal risk assessments will be used as an accepted defense in negligence cases that are based on alleged failure to exercise due care: the risk assessment can be used to determine whether the defendant has employed due care. Periodic use of risk management procedures and tools will be shown to help protect senior management from liability in cases alleging failure to adequately control resources.
An Audit Approach for Risk Management

The EDP auditor and others concerned with minimizing risk will nd risk assessment to be a useful management tool for identifying an optimal, costeffective mix of management, operational, and environmental controls. The approach discussed in the following sections will assist auditors in their participation in the implementation of an integrated risk management program.
Securing Management Support for an Integrated Risk Management Program

The auditor is in a key position to help dene and promote to management an integrated risk management approach that can identify control shortcomings and quantify the nancial consequences of these shortcomings, whether a mainframe, client/server, or mixed environment is targeted. At this phase, the auditor must clarify the responsibilities of auditors and managers in implementing this approach. The auditor is responsible for developing a risk model of the target environment that identies control weaknesses, potential consequences, and a general set of recommendations. Information systems management is responsible for executing the balance of the risk assessment, including the analysis and selection of appropriate risk-reducing safeguards and controls and a cost/benet analysis that provides executive management with sound budgetary support for recommended corrective action. Such an integrated approach to risk management encourages the development of more
239
balanced solutions that address the auditors concern for compliance as well as managements need to cost-effectively manage risk.
Selecting the Best Automated Risk Management Tool

Having dened the organizational strategy for managing the project, the senior information systems and other relevant management should establish the criteria for selecting the risk assessment tool, perform the evaluation, and select the tool that best supports their needs. Exhibit F1.3 provides a selected listing of risk assessment software tools. Exhibit F1.4 provides a checklist for evaluating these tools.
Conducting the Risk Assessment

At this phase, the auditor should participate in a comprehensive risk assessment, looking at as many areas of control as possible to develop a risk model of the target environment that is appropriate to the scope, constraints, and objectives of the project. The participants establish basic asset values including the value of information availability, condentiality, and integrity, and conduct threat and vulnerability analyses supported by the selected risk assessment tool. In support of these activities, the project team should prepare interim reports, including project sizing, asset valuation, and threat and vulnerability analysis. Management should review and sign off on these reports. Management agreement as to the accuracy of this information is essential to ensure the utility of subsequent analyses and recommendations. The results of all preceding analysis are then compiled into a risk assessment report that documents the specic lack of controls in the target environment, attendant nancial risk, and a risk-mitigating course of action recommended by the project team.
Identifying Risk Mitigation Measures

Following its review of the recommendations, management may assign priorities to be considered for risk reduction analysis. These priorities should be assigned on the basis of an evaluation of need and the ability to fund riskmitigating measures, given resource constraints. Informed acceptance of risk is a legitimate management prerogative. The risk reduction phase of the project is typically conducted by the project team and reviewed by line management or support staff in the target environment. Observing management priorities, these individuals are responsible for implementing and maintaining risk-mitigating measures (i.e., controls and safeguards) as well as evaluating their effectiveness. A cost/benet analysis should be performed to determine the most costeffective mix of risk mitigation measures to recommend. Line managers may wish to consult with audit staff at key points during this process.
240 Exhibit F1.4
Checklist for Risk Analysis Software Package Evaluation
Product Attributes
Methodology Qualitative only Quantitative only Both qualitative and quantitative Uncertainty accommodated directly Tracks with FIPSPUB-65 and the NIST framework Databases Provided Threat population Threat frequency Threat sources identied Questions Vulnerabilities Exposure factors Safeguards Safeguard cost Security Log-on or password Multilevel access control Encrypted data and results Utility Overall ease of use Menu driven Organizational Natural language interface Interactive save Replicability Ease of update Risk acceptance criteria Graphic probabilistic analysis Comparative threat analysis (before and after safeguards) Event tree logic Multisite exposure zone summary analysis Automatic threat or vulnerability mapping Automatic threat or vulnerability safeguard mapping Safeguard cost/benet analysis Safeguard effectiveness (percentage) Safeguard ROI analysis
241
Exhibit F1.4 (Continued)

Product Attributes
Utility (continued) Safeguard present value analysis Automatic database coordination Error prevention controls In-process print capabilities User-Generated Capability Remote data acquisition: magnetic Remote data acquisition: paper What-if capability Site-specic threat frequency Threats Questions Vulnerabilities Quantitative data Mapping Overrides Project sizing: detail Project sizing: summary Threat-specic notes (before and after safeguards) Denial-of-use notes Recommendations: summary Recommendations: detail Vulnerabilities summary Report Capability Executive summary with graphic results Management-oriented format and structure Graphic representation of results Detail of Narrative Qualitative Analysis Threat and vulnerability mapping Safeguard and threat mapping Detail and tabular quantitative analysis Print and display: variable report elements Print and display: loss analysis Print and display: full report Cover pages Table of contents Page headers and footers ASCII generation (continues)
242 Exhibit F1.4 (Continued)

Product Attributes
Product Support On-site training available On-site risk assessment execution support available Telephone hot-line support Scheduled enhancements User community involvement in design enhancements User input to threat databases Detailed documentation Online help
Once the optimum cost-effective mix of risk-mitigating measures has been identied, nal recommendations are submitted to executive management and others as appropriate. This integrated approach provides for objective risk assessment and management that is coordinated among all parties involved in the control of risk. It also provides management with the ability to monitor risk mitigation performance. Once key risk models have been built, subsequent audits can be executed even more efciently by modifying the risk model to reect the current risk environment and to satisfy changing requirements for risk control.
Recommended Course of Action

Although the history of information risk assessment has been troubled, continuing research and development has succeeded in solving key problems, creating a powerful new generation of risk management tools. As awareness of the existence of credible tools grows and as regulatory activity expands, it is expected that organizations will adopt a more proactive and integrated risk management posture. Information risk management tools and methodologies will help these organizations to improve overall information security within timely and cost-effective budgets.
About the Author

Will Ozier is president and founder of the information security rm of OPA, Inc. The Integrated Risk Management Group Petaluma, California. He is an expert in risk assessment and contingency planning, with broad experience in consulting for many Fortune 500 companies as well as the federal government. Ozier conceived, developed, and now directs the marketing and evolution of the leading expert risk assessment package, BDSS. He is a member
243
of the Computer Security Institute Advisory Council and has chaired the ISSA Information Valuation Committee, which devised standards for valuing information. He currently chairs the Committee to Develop Globally Accepted System Security Principles as recommended in the National Research Councils Computer at Risk Report.
Recommended Reading
1. Comptroller of the Currency, Administrator of National Banks. End-User Computing. Banking Circular-226. Washington, D.C., January 25, 1988. 2. Comptroller of the Currency, Administrator of National Banks. Information Security. Banking Circular-229. Washington, D.C.. May 31, 1988. 3. Federal Deposit Insurance Corp. Federal Financial Institutions Examination Council Supervisory Policy on Contingency Planning. Report BL-22-88. Washington, D.C., July 14, 1990. 4. Guarro, S.B. Risk Analysis and Risk Management Models for Information Systems Security Applications. Reliability Engineering and System Safety (1989). 5. International Computer Security Risk Model Builders Workshop. National Institute of Standards and Technology. Santa Fe, NM, August 2123, 1990. 6. Mohrm J. Fighting Computer Crime with Software Risk Analysis. Journal of Information Systems Management, 1, No. 2 (1984). 7. Ozier, W. Disaster Recovery and Risk Avoidance/Acceptance. Data Processing & Communications Security, 14, No. 1 (1990). 8. Ozier, W. Risk Quantication Problems and Bayesian Decision Support System Solutions. Information Age, 11, No. 4 (1989). 9. U.S. Senate and House of Representatives. Computer Security Act of 1987. Public Law 100-235. Washington, D.C., January 8, 1988
Appendix F2
New Trends in Risk Assessment*

Caroline R. Hamilton
Risk management has reached a new level of importance in the information age. The growth of networked information systems and distributed computing has created a potentially dangerous environment. This article provides an overview of current approaches to assessing risk in the modern environment.
Risky Business The Background

Risk management is a process one uses hundreds of times every day. From deciding whether to cross the street, deciding to take a shortcut home to avoid trafc, deciding to purchase health insurance, or change jobs, each decision is based on principles of risk management. For example, every time someone crosses a city street, it involves a risk management decision. Is the light green? How fast if the trafc coming? How important is it to get across the intersection quickly is there a $1000 bill laying on the curb? Is one being chased by a man with a gun? All these considerations are analyzed in a split second and the decision is made across the street now, even against the light; or wait until the walk sign lights up. Risk management has reached a new level of importance in the information age. The growth of networked information systems and distributed computing has created a potentially dangerous environment. From trade secrets, proprietary information, troop movements, sensitive medical records and nancial transactions, critically important data ows through these systems. Independent reports, such as the recently published FBI/CSI Computer
* Hamilton, Caroline R., New Trends in Risk Assessment, Data Security Management, AIMS, April 1995.
245
246
Crime Survey, detail the losses which have been sustained by information systems over the last 12 months. More than one hundred million dollars in losses were reported by 249 organizations in this single report. With losses of this magnitude, organizations are becoming increasingly concerned with their potential exposure and looking for ways to evaluate their organizations security prole.
The Information Age

Our society depends on fast, accurate transmission of information. Everything from e-mail, stock quotes, credit ratings, bank balances, travel arrangements, even the weather, are all tracked by computer systems. Just ten years ago, most employees worked with dumb terminals which performed a prescribed set of functions. These terminals have migrated into personal computers on every desk, most linked to the Internet. Even prisoners are requesting modem access to conduct their in-prison business enterprises. The availability of all this information and the ease of intercepting it has created an environment where hackers are gloried as harmless whiz kids, although the damage they do to a computer system may take weeks to undo. More serious incidents include the ten million dollars taken electronically from a major banks cash management system, an altered 911 message at a police station that said, Were too busy eating donuts to come to the phone, and a prostitution ring that operated for over a year on a state government network. Another problem in this new information society is the lessening of loyalty of employees to their organizations. Private companies have right-sized and downsized and tried to trim overhead to keep prot margins high. Both federal and state governments have also been pushed to reduce their budgets and do more work with less employees. The old days of having a job for life, where the company looked out for and protected its employees, are over. The resulting lowering of morale contributes to a risky business environment, where the goals of the individual may no longer match the goals of the organization where they work. Risk assessment began as a process applied to large mainframes and data centers, which were in stand-alone, tightly controlled environments. However, as personal computers replaced dumb terminals on every desktop, and as these personal computers are increasingly linked to the Internet, computer security problems multiply. Hardware solutions, such as installing rewalls or automating audit logs, are sometimes difcult to justify to senior management, and where installed, have not always prevented security breaches. The interest in risk assessment as an effective method of analyzing these complex systems has increased dramatically over the last 12 months, and serves two purposes: to identify existing weaknesses in the systems, and to cost-justify and prioritize the cost of additional safeguards.
New Trends in Risk Assessment
247
Political Inuences Risk Management and the Republican Contract with America
The mood in the U.S. Congress is one of increasing accountability in government. In item three of the Republican Contract with America, risk management is discussed as a potential requirement for federal managers in such diverse departments as the Labor Department and the Environmental Protection Agency. When eventually turned into legislation, it would require federal managers to cost-justify changes they make, including detailing how much the proposed change would cost, balanced against the money it would save the government.
New Directives and Guidelines

The General Accounting Ofce Report to Congress
In May of 1996, the General Accounting Ofce (GAO), the audit branch of the Federal government, released their report to Congress with the intriguing title, Computer Attacks at Department of Defense Pose Increasing Risks (GAO/AIMD-96-84 Defense Information Security). Using statistics from the Defense Information Systems Agency, as well as results of its own investigations, the report details more than 160,000 successful attacks against Department of Defense (DOD) computer systems. The report state, since the level of protecion varies from installation-to-installation, the need for corrective measures should be assessed on a case-by-case basis by comparing the value and sensitivity of information with the cost of protecting it and by considering the entire infrastructure. In summarizing its results, the GAO report recommended more stringent security policies and that the Department of Defense mandate risk assessments. In addition, the report included recommendations that DOD develop Departmentwide policies for prevention, detection, and response to attacks. (Currently, each branch of the service has its own, and sometimes different, security policies). The report also recommended that the Defense Department mandate that: all security incidents be reported; that risk assessments be performed routinely to determine vulnerability to attacks; that vulnerabilities and deciencies be corrected expeditiously, as they are identied; and that the damage from intrusions be expeditiously assessed to ensure data/system integrity.
The FBI/CSI 1997 Survey

The Computer Security Institute in San Francisco teamed with the Computer Crime Squad of the FBI in 1996 to do the rst FBI/CSI Computer Crime Survey.
248
The survey was conducted to provide statistical data on the state of computer crime and computer security; to quantify information losses and to further cooperation between law enforcement and organizations to report computer crimes. In 1997, the second survey was completed and the results were shocking. The sampling base included 5000 information security professionals, of which 563 completed the survey. From these organizations, 249 reported losses of over $100 million from computer crime. Losses ranged from averages such as nancial fraud (26 responses averaging $957,384); theft of proprietary information (21 responses averaging $954,666); telecommunications fraud (35 responses averaging $647,437); unauthorized access (22 responses averaging $181,436); sabotage (14 responses averaging $164,840); and system penetration, with 22 responses averaging $132,250.
Senate Permanent Subcommittee on Investigations

In June of 1996, one month after the GAO report was released, U.S. Senator Sam Nunn convened the Senate Permanent Subcommittee on Investigations to hold hearings on Security in Cyberspace. The report of the Subcommittee stressed the importance of vulnerability assessments to securing computer systems. The report stated, vulnerability testing and assessment of government and government interest computer systems is the best method of enhancing awareness of the vulnerabilities of our information infrastructure. The staff recommendations included emphasizing that the federal government promote regular vulnerability assessments of government agencies, especially agencies outside of the Department of Defense. Other safeguards recommended by the Subcommittee were that the United States must formulate national policy to promote the security of its information infrastructure; creation of a National Information Infrastructure Threat Center with real-time, 24-hour operational capabilities; and the creation of an international computer crime bureau with emergency response capability. The Subcommittee report was widely reported in the national press.
The Presidents Commission on Critical Infrastructure Protection

The following month (July 1996), the Clinton White House announced an Executive Order, establishing the Presidents Commission on the Critical Infrastructure Protection (PCCIP). Modeled after the NSTAC (a coalition of communications companies and the Federal government), the PCCIPs mission was to assess the scope and nature of the vulnerabilities of, and threat to, critical infrastructures;and recommend a comprehensive national policy and implementation strategy for protecting critical infrastructures from physical and cyber threats and assuring their continued operations.
249
The Gulf War had heightened security awareness by pointing out how many private resources were used in ghting the Persian Gulf War. Commercial long-distance lines and even cell phones formed a piece of the U.S. war effort. Yet these resources were not under the direct control of the Department of Defense, or even the Federal government. The PCCIP identied eight critical infrastructures, including: 1. 2. 3. 4. 5. 6. 7. 8. telecommunications electrical power systems gas and oil storage and transportation banking and nance transportation water supply systems emergency services (medical, re, police, rescue) continuity of government
Representatives from the highest levels of both government agencies and large private companies made up the PCCIP. In addition, the structure of the PCCIP included a task force (the Interim Coordinating Mission) to provide/coordinate guidance to detect, prevent, halt, or conne an attack and to recover and restore service; to issue threat and warning notices in the event advance information is obtained about a threat; and to provide training and education on methods of reducing vulnerabilities, and conduct after-action analysis. The Presidents Commission on the Critical Infrastructure Protections report was released in November 1997. The report concurred with many of the ndings from the Senate Permanent Subcommittee on Investigations Report, recommending vulnerability assessment as one the most effective safeguards for government AND private information systems. The report noted that, Government leaders are insufciently aware of the vulnerabilities. It goes on to recommend a broad program of awareness and education, a major effort directed toward encouraging information sharing, as well as an increased emphasis on vulnerability assessments and quantitative risk management process.
Report of the Defense Science Board

The nal major report issued in 1996 was the Report of the Defense Science Board. This lengthy report featured a series of recommendations, including designating a Czar for Information Warfare, establishing a Center for Intelligence/Threat Assessments, and establishing a Center for Information WarfareDefense Operations. In addition, the report recommended a program to assess infrastructure dependencies/vulnerabilities; that DOD raise the bar with high pay-off, low-cost items like training; and increasing awareness. These diverse reports have one common thread all of them recommend increasing vulnerability assessments and mandating risk assessments.
250
What is Risk Assessment?

Risk assessment is a method of determining what kinds of controls are needed to protect an organizations information systems and resources not just adequately, but cost-effectively. The risk assessment process examines a set of ve variables. First, what is one trying to protect, how much is it worth, and how much depends on it? Second, what could potentially threaten the asset? Third, what weakness exists that would allow the threat to materialize? Fourth, if the threat occurs, what kind of loss could you have? And, fth, what controls could one put in place that would reduce the loss if a threat occurred, or eliminate the threat altogether? The ve variables include: 1. Assets Whatever one is trying to protect. Assets can include databases, information, personnel, facilities, applications, computer hardware and software, and communications hardware and software. 2. Threats Threats are events that could happen at any time. Even impeccable security cannot eliminate every threat such as hurricanes, earthquakes, or fraud but one can diminish the impact if the threat occurs, or reduce its likelihood of occurrence. Examples of threats include natural disasters (e.g., cold, storms, lightning, subsidence), as well as embezzlement, espionage, sabotage, loss of key personnel, and theft. 3. Vulnerabilities Vulnerabilities are weaknesses in the organization that would create a condition which would allow the threat to cause an impact to the organization by triggering a loss. Examples of vulnerability areas include access control, administration, accountability, compliance, policy, operating procedures, and training. 4. Losses Loss categories include direct loss, disclosure losses, loss of data integrity, losses due to data modication, and losses due to delays and denials of service. 5. Safeguards Safeguards are security controls which, when put in place, can eliminate, reduce, or mitigate the impact of a threat occurrence. Examples of safeguards would include biometric controls such as retina scanning and the use of encryption, awareness programs, redundant power sources, audit trails, visitor controls, and electronic monitoring.
Risk Assessment Methodology

The risk assessment process includes gathering information about assets, nding sources for threat data, doing a survey to nd the vulnerabilities, and then matching the information to see what combination of asset/threat/vulnerability could trigger a loss, and then deciding what safeguards can be put
251
in place to reduce or eliminate the potential loss. The risk analysis manager must evaluate thousands of different combinations in order to write a comprehensive report.
Steps in a Risk Assessment

There are six steps in a risk assessment: 1. 2. 3. 4. 5. 6. Set parameters for risk analysis. Dene systems assets. Determine relevant threat proles. Survey all system users to discover vulnerabilities. Analyze all data. Write the report.
Valuing Assets
Finding values for organizational assets is one of the most difcult tasks associated with risk assessment. It is relatively easy to assign present-value replacement costs to assets such as hardware systems, software, and physical assets such as a building, tape drives, and ofce equipment. Valuing information is much more difcult. Databases may contain very sensitive information; how can the analyst put a dollar value on the database? It is probable that the database is backed up somewhere and therefore its replacement cost will probably be less than $1000.00. However, if the database contains a list of police informants, or a list of recently diagnosed HIV-positive individuals, there are additional values that must be determined based on three components: (1) the condentiality requirements of the database, (2) the expectations of availability of the database, and (3) the requirements for integrity of the database. In medical records, for example, patients may sue a hospital if the condentiality of their medical records is compromised.
Finding Threat Data

Use of threat data is an important part of the risk assessment. Calculating frequency of occurrence for threats is an essential element of the cost-benet analysis. If a threat is expected to occur only once every 20 years, it is unlikely that the organization will spend millions to protect against the threat unless, of course, the threat would cause a catastrophic loss, even with a one-time occurrence. Threat data can be obtained through research at national respositories of such data, through compilation of media accounts, by reviewing weather information for the last 100 years, and by reviewing actuarial tables, to name a few common sources. Comprehensive threat data is very difcult to get and usually those who have the best threat data are the most uninterested in sharing it.
252
Managing the Risk Assessment

Risk assessment is a management process and, by its nature, should involve the entire organization. Because the vulnerability discovery process will include questioning many different parts of the organization, it is vitally important to the eventual acceptance of the risk assessment ndings that different departments be involved in the initial setup of the analysis. Mid-level managers may feel threatened that another group is asking questions of their employees. They may worry that the ndings could reect negatively on their performance as supervisors. In addition, if the survey questions are not approved prior to their use by the various supervisors and department heads, the results they generate might be discounted and not taken seriously. For these reasons, it is important to set up a risk analysis team within the organization. The team members will include representatives from each department included in the analysis process. Team members will review questions, identify the correct standards for their areas, assist the risk analyst in arriving at current asset replacement values, and serve as administrative support for the surveys in their respective areas of responsibility.
Vulnerability Assessment
Risk assessment is composed of two parts: the vulnerability assessment and the countermeasure (safeguard) assessment. The vulnerability assessment looks at an existing systems or facility and evaluates its existing security, including how personnel are complying with existing policies and guidelines. The result of the vulnerability assessment will present a detailed roadmap of all the existing weaknesses in the present system, including information on how widespread the problem is, and which individuals identied the weakness (vulnerability). Surveying people who use the systems under review is a critical part of the vulnerability assessment. While paper surveys are laborious and difcult to aggregate, automated questionnaires now exist that allow risk analysts to interview users electronically. Survey questions start with a control standard that outlines the ofcial policy of the organization. Questions should be set up to validate compliance against published policies, guidelines, and directives. There is little point to asking questions unrelated to requirements, because the organization would nd it difcult to enforce compliance if it was not a requirement. The risk analysis manager is the analyst in charge. However, there may be other individuals in the organization who can make major contributions. According to the audit guidelines for risk assessment, the more people one interviews, the more likely one is to nd a vulnerability. Individuals should not be asked to answer more than 50 to 100 questions that are directly related to their job. For example, network users might answer questions related to
253
whether they use their passwords, whether they log off their terminals when they leave their station, or whether they have attended basic data security training. Database administrators will answer a few general questions, but also more specic questions related to their job.
The Questions
Asking good questions is at the very heart of the risk assessment and also forms the core of the vulnerability assessment. Questions should always be compliance based and directly linked to a control standard or control objective. If one asks questions that are not linked to standards, and discovers major problems, the path will not exist to force compliance. Limiting the number of questions to ask is one of the most difcult aspects of the analysis. Employees may be nervous when they are asked to answer questions related to how they perform their jobs. It is important to ensure that these individuals understand that the risk assessment is a scientic process, and that any data gathered in the risk assessment will be seen by only one individual (the risk analysis manager), and that their comments will not be reviewed by their supervisor, nor will they end up in their personnel le. Random surveys are often used to predict election results, from local precincts in a particular city, to federal elections, where the network news teams are able to predict the nal results from a prole of only a few key states. In these examples, random samples are usually less than 1%. In a risk assessment, a random sample is not desirable. Instead, the objective should be to question as many people as possible. The more individuals one questions, the better the chances of discovering a vulnerability. It is unrealistic to think that people will answer more than 50 to 100 questions. To avoid individuals having to answer questions that do not relate to their area, in a risk assessment, questions are divided into job categories, or what is called functional areas. Functional areas are pieces of a job. By dividing questions into these categories, for example, Michael Smith may answer 20 questions for network users, 20 questions for personnel management (which is his area), and 15 general organization questions. More specialized personnel, such as a facilities manager, the physical security ofcer, or a database administrator, will answer questions that relate only to his or her particular area. Questions start as control standards. The standard might be: Passwords should be changed every month. One might cite a reference representing where this standard originated, for example, Telecom Security Directive 3, p. 4, para. 5. The question statement asks the user how well they comply with this standard on a percentage scale from 0 to 100. The zero answer means the user never complies with the standard. An answer of 100 means the user complies with the standard 100 percent of the time; and the user is encouraged to answer with any percentage in between.
254
In addition, users should be allowed two additional options in answering. The rst is the opportunity to answer not applicable, if the question does not apply to them; and secondly, to answer I do not know, if they do not know the answer.
Cost-Benet Analysis Getting More Bang for Your Buck

The cost-benet analysis combines information from the vulnerability assessment along with relevant threat data and asset information such as presentday replacement values; criticality, integrity, and availability of the information contained in the system under review; as well as how completely safeguards are currently being implemented. In reviewing the existing security controls, it is important to indicate percentages of current implementation. For example, maybe the visitor badging policy is only 70 percent implemented, meaning that it is implemented on weekdays, but not on weekends. In actual risk assessments, completing implementation of an existing control to 100 percent is often the most cost-effective solution. The result of the cost-benet analysis will be to create a return on investment ratio (ROI), balancing the value of the information against the cost of controls to protect it. By establishing ROI data, managers and directors can make more informed decisions regarding which controls to implement, based strictly on initial cost, but also on the current threat exposure of the organization. The accountability that is a built-in component of risk assessment is increasingly attractive to top-level management, both in the federal sector, as well as in private industry where board members and shareholders want quantitative numbers to use in assessing the security level of an organization and making the resultant management recommendations.
Reporting Results to Management

The value of a risk assessment will be judged by how well it is presented to management. The vulnerability assessment report, in particular, usually comes as a surprise to upper management, who are shocked to see how many of the organizational directives are not being complied with. Typical results of a vulnerability assessment done on a local area network often includes the following ndings: 50 percent of LAN users do not memorize passwords; users do not always log-off terminals; supervisors loan passwords to new employees; no clear separation of duties; network les are not always labeled; and the disaster recovery plan may not have been fully implemented throughout the organization. In most risk assessments, during the course of the analysis, there will be glaring problems that will be undercovered during the course of the analysis. Often, the problem is so severe that it must be corrected immediately, instead of waiting until the nal risk assessment report has been written and approved. In these cases, the report can be written to indicate that several vulnerabilities
255
were discovered during the course of the analysis and were immediately corrected. The analyst in charge of the analysis must be able to explain to management how the analysis was conducted, who was included in the survey population, and how the numbers were calculated.Knowledge in these three areas will make the analysis results defensible and will enhance the overall value of the analysis.
Automating the Risk Assessment

The new emphasis on the need for risk assessment is causing a renewed interest in automated risk analysis software tools, which can reduce the time involved in a big risk assessment by more than 60 percent. A manual risk assessment on a major computer system, including the personnel, the facilities, any remote sites, a network of over 1000 users tied to a mainframe, may take from six months to one year to analyze using a manual method. Using an automated software program can cut the time from six months to six weeks. The risk analysis manager will spend most of his time on this analysis, enlisting help from other departments, facilities managers (to provide some threat data), accounting (to help establish asset values), and from all the departments that will be included in the review. Most automated risk assessment programs include an expert knowledge base. These programs have captured an experts working knowledge of risk assessment relationships and modeled them into a software format. As a result, these programs can be used by much less experienced managers and will still produce an excellent result. In addition, software can reduce interviewer bias and allow an organization to survey a number of different locations and directly compare them. Most importantly, automating the risk assessment task, which is a combinatoric nightmare, can reduce the time needed to analyze a large wide area network from six months to three weeks.
The Decision Point How to Apply the Results of the Risk Assessment
A high-level risk assessment is, in itself, the most cost-effective safeguard one can nd. It is a way of looking at a large organization in a consistent and quantiable manner, with defensible results. It also provides a way of baselining across an organization and it will identify the weak areas so those can be revisited with a more intensive analysis at a later date. Corporate policies and government regulations are being constantly rewritten to address the networked environment, and risk assessments are becoming increasingly important in the management of information systems.
256
About the Author

Caroline R. Hamilton is President of Risk Watch, Inc., a company specializing in security assessment software. She is a charter member of the National Institute of Standards and Technologys Risk Management Model Builders Workshop, and recently served on the working group to create a Defensive Information Warfare Risk Management Model, under the auspices of the Ofce of the Secretary of Defense. She is a member of the American Society for Industrial Securitys Standing Committee on Computer Security, and is working with the U.S. Coast Guard and the Maritime Security Council to create technical guidelines for risk assessment.
Appendix F3
Integrated Risk Management A Concept for Risk Containment*

Jose Martinez
As the dependence and reliance on computers continue to grow, networks and auxiliary devices that constitute these systems are also expanding, and so is the vulnerability to service disruptions and compromises. Systems are undergoing downsizing to reect the high-end processing and storage capacity now available in platforms other than mainframes. Workstations and highend personal computers provide processing capabilities that can meet most users needs. Decentralized computing environments are easier to access, because more potential points of entry exist. In this rush to embrace new technology, manual or paper-based documentation is often overlooked. Ultimately, paper-based systems provide the necessary documentation with respect to legal considerations, data retrieval of paper documents, and backup to automated or manual systems in the event of major disruptions to electronic computer operations. Any effort to identify critical data must include manual systems and an effective records retention schedule. Management must wrestle with the issue of open systems to encourage productivity or restrict access to data assets both physically and logically to preserve data integrity.
Risk Model
Data processing professionals, data owners, and end users too often nd themselves responding to emergencies without predetermined procedures to
* Martinez, Jose, Integrated Risk ManagementA Concept for Risk Containment, EDP Auditing, AIMS, CRC Press LLC, Boca Raton, FL.
257
258
Exhibit F3.1
Risk Model
address such occurrences. Policies and procedures to ensure timely business resumption and integrity of data assets either are not developed or are improperly implemented due to various reasons, including improper vision or strategy, lack of resources, and lack of executive level-management support. The end result is loss of processing, possible denigration of system or data integrity, and lost productivity. It is also necessary to address threats that might impinge on the processing needs of the end users. The concept of risk should be explored to understand the complexities of risk containment. The essential components of a risk model are: the threat, the asset, preventative measures, mitigative measures, and consequences. The logical relationship between the threat initiator (e.g., a human attacker, such as a saboteur, or a natural force, such as an earthquake), the potential target assets (e.g., computer and communications hardware, software, or data), and the consequences that would have resulted when the threat agent reaches the assets (e.g., destruction of hardware, disclosure of information, and loss functionality) are represented in Exhibit F3.1. These logical links are referred to as the propagation path from threat, to asset, to consequences. The existing security controls (i.e., safeguards) are intended to check and limit the progression of the threat initiator along the depicted path. Preventative controls are placed on the path from threat to assets and have the intended function of preventing the threat agent from affecting the assets in any signicant way. Mitigative controls are positioned along the path from assets to consequences, and have the intended purpose of limiting and minimizing losses in those cases in which the preventative controls fail to keep the threat from affecting the assets. Management must make the decision to implement preventative and mitigative controls to minimize risk exposure to data assets. The cost-effectiveness of each additional measure is evaluated in relationship to the value of the asset and the probability of intrusion or denigration. Successful implementation of controls that deny or limit risks to data assets can be viewed as a function of concerted participation of all parties. The effectiveness of their participation is determined by well-dened roles and responsibilities.
Integrated Risk Management A Concept for Risk Containment
259
Roles and Responsibilities

Security considerations must be an integral part of the planning, development, and operation of any automated or manual information system. Each business function (i.e., system) requires the support and ongoing participation of owners, custodians, and users of information.
Data Ownership
Data ownership is vested in the organizational unit that has the responsibility for making classication and control decisions regarding an automated le, database, or paper documentation. Ownership should be assigned by corporate management for these media. Normally, responsibility for automated and manual information resides with the manager of the application that employs the information. When information is used by more than one application, consideration for determining ownership responsibility includes: the application that collected the information the application that is responsible for the accuracy and integrity of the information the application that budgets the costs incurred in gathering, processing, storing, and distributing the information the application that has the most knowledge of the useful value of the information the application that would be most affected, and to what degree, if the information were lost, compromised, delayed, or disclosed to unauthorized parties The responsibilities of the designated owner consist of: classifying each le or database for which he or she has been given responsibility in accordance with the need for precautions in controlling access to and preserving the security and integrity of the le or database dening precautions for controlling access to and preserving the security and integrity of les and databases that have been classied as requiring such precautions authorizing access to the information in accordance with the classication of the information and need for access to that information monitoring and ensuring compliance with corporate security policies and procedures affecting the information, which includes identifying the level of acceptable risk for each le or database ling incident reports to corporate security management in a thorough, timely fashion The ownership responsibilities must be performed through the life cycle of the le or database until its proper disposal. Business or application
260
managers who have been designated owners of automated or manual les and databases must coordinate these responsibilities with corporate information security management.
Custodians of Information
The custodians of information are employees or an organizational unit, such as a data center or information processing facility, which act as caretakers of an automated or manual le or database. The responsibilities of such a custodian consist of: complying with applicable law and administrative policy complying with any additional security policies and procedures established by the owner of the automated or manual information and the corporate information security management advising the owner of the information and the corporate information security manager of vulnerabilities that may present a threat to the information and of the specic means of protecting that information notifying the owner of the information and the corporate information security management of any actual or attempted violations of security policies, practices, and procedures
User of the Information

The user of the information is an individual that has specic limited authority granted by the owner of the information to view, change, add to, disseminate, or delete such information. The responsibilities of a user of information consist of: using corporate information assets for corporate business only. complying with applicable laws and administrative policies, including copyright and license requirements, as well as any additional security policies and procedures established by the owner of the information and the corporate information security management. notifying the owner of the information and the corporate information security management of any actual or attempted violations of security policies, practices, and procedures. The determination of ownership, custodian, and user responsibilities is specic to the data processed by an automated or manual system. For example, a data owner of one application could be the custodian or user of others.
Management and Staff Responsibilities

To ensure proper implementation of any risk containment program, all involved parties must be aware of their respective responsibilities as they
261
relate to risk management. Because crucial activities, such as asset classication and inventory, require involvement at all levels, coordination and awareness of other interdependent activities are of paramount importance. Risk management is a complex concept to understand due to its esoteric nature. For example, the loss of data on a hard disk is difcult to quantify. Factors such as lost productivity, reconstruction efforts, and consequences of the loss of the asset may not be easy to quantify. Loss or theft of a personal computer in terms of replacement cost is a tangible item, which is more easily understood and appreciated.
Executive Management
Executive management ensures the establishment and maintenance of an information security or risk management program that minimizes risk exposure to corporate information assets. Specically, executive management ensures that the corporations information assets are protected from the effects of damage, destruction, and unauthorized or accidental modications, access, or disclosure.
Information Security Management

Information security management oversees corporate policies and procedures designed to protect the corporations information assets. Typical security management duties include: implementation of policies and procedures to support the establishment and maintenance of a risk management program, and establishment of training programs to promote security awareness to management and line staff.
Technical Management
Data processing managers ensure that management, assigned owners, users, and custodians are provided with the necessary technical support services with which to dene and select cost-effective security controls, policies, and procedures. In addition, data processing management is charged with implementing systems controls necessary to identify actual or attempted violations of security polices and procedures and, subsequently, to notify appropriate parties.
Business and Project Management

Business and project management establish necessary procedures to comply with information risk management policies and procedures and ensure the appropriate classication of applications for business resumption considerations and access controls. In addition, management ensures the proper
262
planning, development, and establishment of security policies and procedures for paper les or data les for which the project has ownership responsibility. It also ensures that custodians of project information are provided with the appropriate direction to implement security controls and procedures.
Business and Project Personnel

Business and project personnel implement and monitor data quality assurance functions to ensure the integrity of the data; to observe all applicable laws, regulations, and corporate security policies and procedures; and to identify security vulnerabilities and, accordingly, inform project management and corporate security management.
Internal Auditor
Internal auditors examine corporate information security policies and procedures to determine the effectiveness of those policies and procedures, to identify inadequacies within the existing security and risk management program, to identify possible corrective action, to apprise management of ndings, to review and evaluate the effectiveness of controls for automated or manual information systems that are either under development or currently in operation, and to participate in the corporate risk analysis process.
Risk Management Building Blocks

Fundamental to the implementation of any risk management program are the answers to these two questions: What kind of assets are there and how important are they to the ability to process? What kind of liability is associated with the potential loss or denigration of those data assets? To answer the rst question, one must have an idea as to what types of data assets are owned by the corporation. That is, of all applications that are critical to ongoing operations, which data are sensitive or condential, and which data can be viewed as public information. This process is called classication of data assets. It serves the purpose of properly identifying security requirements that drive the selection of appropriate controls to protect the information. Information that is entered, processed, stored, generated, or disseminated by automated or manual information systems must be protected from internal data or programming errors or from misuse by individuals within or outside the organization. Specically, the information or data must be protected from
263
loss, unauthorized or accidental modication, destruction, or inappropriate disclosure. The designated owner of the automated or manual le or database is responsible for classifying that information. Corporate management must know what is critical to corporate operations to ensure that appropriate safeguards are in place to respond to system threats and business disruptions. Identifying the vulnerabilities and assessing the risk associated with corporate information assets (i.e., risk analysis) requires an approach that rst identies the automated or manual les and databases that should be classied as condential or sensitive, and identies systems (i.e., applications) that are critical to corporate project operations. Asset classication involves the systematic identication of applications (i.e., systems) that are critical to corporate operations, and the identication of les or databases that are sensitive, condential, and public information to ensure proper risk management practices. Inventory of hardware and software gives an indication of potential monetary loss. Other costs can be attributed to reconstruction of lost data and lost productivity.
Asset Classication
Under asset classication, four categories of information exist: critical applications or data condential information sensitive information public information
Critical Applications or Data

These are dened as applications that are so important to the corporation that its loss or unavailability is unacceptable. With critical applications or data, even short-term unavailability of the information provided by the application would have a signicant negative effect on the health and safety of public or employees, on the scal or legal integrity of corporate operations, or on the continuation of essential corporate programs. The corporate risk analysis process must identify and classify critical applications of information technology. In establishing priorities, corporate management should consider that applications may become more critical as the period of unavailability increases and that cyclical processing cycles (i.e., monthly, quarterly, or annually) may have an effect on the categorization of the applications or data.
Condential Information
This information requires special precautions to protect it from unauthorized or accidental access, disclosure, or dissemination. Automated or manual systems that process condential information require adequate controls to safeguard
264
against violating individual rights to privacy or to protect the corporation in case of inadvertent disclosure. The disclosure of this type of information is limited by contractual obligation, including proprietary computer software, proprietary considerations, and trade secrets.
Sensitive Information
This information requires special precautions to protect it from unauthorized or accidental modications or destruction. Specically, sensitive information requires maintenance of integrity or assurance as to its accuracy and completeness. Sensitive information may also be classied as condential or public information. Examples of sensitive information are nancial and operating information. The controlling factor for condential is dissemination, and the one for sensitive information is integrity. Typically, sensitive information includes records of corporate nancial transactions and most legal matters. The data owner is responsible for making the determination as to whether a le or database should be classied as condential or sensitive and for dening any special security precautions that must be followed to control access and to ensure the integrity of the information.
Public Information
This is information that is not classied as condential. Public information may be classied as sensitive.
Inventory
Hardware and software and support equipment (e.g., furniture) should be inventoried periodically to determine replacement cost, description of inventory item, ownership, custodianship, location, application supported, and auditability of the procurement system. The more decentralized and complex a corporation might be, the easier it is to lose track of computer hardware, software, and support equipment. Minimally, an inventory system should list tangible assets (i.e., hardware, application software, and support equipment) by manufacturer, vendor, model serial number, quantity, and replacement cost. Hardware and software inventory should be inventoried by platform with the respective owner, custodian, and user identied for responsibility and accountability. The inventory should be updated because hardware and software are either purchased or become obsolete.
Risk Management Elements

A risk management program should contain three key elements: risk analysis, information security, and business resumption planning and testing. The
265
combination of these three elements dictates the effectiveness of any risk containment program of data assets. Each element requires a concerted effort and support by all levels of management and end users for there to be any tangible results. The initial and ongoing costs are offset by short- and longterm benets derived from minimizing vulnerabilities (and subsequent losses) through the restriction of unauthorized access, prudent architecture or strategic planning that reects knowledge of potential threats and vulnerabilities, and through the implementation of contingency planning for orderly business resumption.
Risk Analysis
The risk analysis process identies and assesses risks associated with corporate information assets and denes cost-effective approaches to managing such risks. The analysis identies the probable consequences or risks associated with the vulnerabilities and provides the basis for establishing a cost-effective security program and evaluates the effectiveness of business resumption planning and testing. Threats can be natural (e.g., earthquakes and oods) or man-made (e.g., virus, hacking, and sabotage). The risk analysis process should be carried out with sufcient periodicity to ensure that the corporate risk management approach is realistic in response to the current risks associated with corporate data assets. The goals of the risk analysis should encompass: the adequate response to vulnerabilities and to disasters; elimination or minimization of the likelihood of an accidental or deliberate act; and elimination or minimization of the effects of a disaster on corporate operations. The risk analysis process should include: the assignment of responsibilities for risk assessment, including appropriate participation of executive, technical, and project management the identication of corporate information assets that are at risk, with primary emphasis on critical applications and data the identication of threats to information assets the assessment of vulnerabilities to information assets the determination of probable loss or consequences, based on quantitative or qualitive evaluation, of a realized threat for each vulnerability and the estimation of the likelihood of such occurrence the identication and estimation of cost-effective protective measures that could eliminate or reduce the vulnerabilities to an acceptable level the selection of cost-effective security management measures to be implemented the preparation of a report for submittal to executive or senior management that documents ndings and recommendations of risk assessment Management must determine two key factors: acceptable loss probability and acceptable loss threshold. These two considerations are very subjective
266
and may change dramatically depending on the data owner, application, and data.
Business Resumption Planning and Testing

The purpose of business resumption planning is to ensure the continuity of computing operations for support of critical applications to produce the greatest benet from the remaining limited resources and to achieve a systematic and orderly migration toward resumption of all computing services. Of paramount importance is the most expedient restoration of services for those applications deemed critical to the continuity of business operations. The owners of information play an important part in the business resumption planning process and in the development and implementation of a business resumption plan. This plan is a management tool that identies the computer applications critical to corporate needs, information necessary for those applications, and corporate plans for resuming operations following a disaster. The business resumption plan may include the following: the establishment of a business resumption planning team, which would be responsible for the detailed technical analysis and planning function the assessment of the resource requirements (equipment, communications, data, software, personnel, and time) required for the corporations critical applications the identication and evaluation of alternative resumption strategies the preparation of a cost-benet analysis for each alternative and the selection of best alternative the determination of specic resumption procedures and the time frame for their execution the identication of individuals and teams within the corporation that would be responsible for managing and implementing specic resumption procedures The business resumption plan must be tested periodically to determine its accuracy and completeness and the staffs ability to mitigate a disaster effectively.
Information Security
Information security encompasses the use of physical and logical data access controls to ensure the proper use of data and to prohibit unauthorized or accidental modication, destruction, disclosure, loss, or access to automated or manual records and les, as well as loss, damage, or misuse of information assets. Policies and procedures must be established to ensure that hazards are eliminated or their effects minimized. The protection of data assets may include:
267
the physical protection of information processing facilities and equipment; maintenance of application; and data integrity the assurance that automated or manual information systems perform their critical functions appropriately, in a timely manner, and under adequate controls the protection against unauthorized disclosure of information the assurance of the continued availability of reliable and critical information A system should be developed and implemented that documents information incidents that involve unauthorized or accidental modication, destruction, disclosure, loss, or access to automated or manual les and databases, as well as incidents that involve loss, damage, or misuse of information assets. Through prompt investigation of incidents, patterns can be analyzed for selection of appropriate deterrents (i.e., safeguards). Training programs should be developed to address information security requirements and their importance to corporate operations and activities of personnel. Some areas of possible training include public access to information, use of corporate resources for personal purposes, disposal of condential documentation, protecting passwords, message authentication and data encryption, and privacy and condentiality. Security awareness of employees is an important activity in minimizing misuse of information assets. Information security programs may include: distributing copies of corporate security policies and procedures and obtaining signed acknowledgment from each employee; security policies and procedures as part of new-hire orientation and regular training classes on information security-oriented topics; and bulletin boards, newsletters, and posters that focus on the importance of information security. The more creative and innovative the effort, the more interest that will be generated by employees. For example, a major corporation initiated a Security Awareness Fair Day in which employees, through visual aids and games (with prizes), were encouraged to demonstrate their knowledge of good security practices. Included as prizes were posters, Post-it pads with security messages and practices, and other items to spur interest. Videos were shown on a continuous basis, and food was available to encourage attendance. Managers ofcially sanctioned employees time to visit the fair in response to a message from the president that extolled the virtues and importance of the event. Through proper training that raises the awareness of the end user, the corporate computing environment benets from less accidental modication, destruction, or disclosure of data.
Integrated Risk Management

The concept of integrated risk management (IRM) recognizes the need for the implementation of a risk containment program with three, interrelated basic
268
Exhibit F3.2
Integrated Risk Management Model
elements: risk analysis, business resumption planning and testing, and information security. It is prudent for management to adopt a proactive, as well as a reactive approach to risk management. The implementation of these three programs also encompasses proactive as well as reactive approaches to managing risk. The optimal computing environment scenario reects all three programs fully implemented and addresses all critical applications and sensitive and condential databases and les. These data assets are then located in the area labeled IRM in Exhibit F3.2, which indicates an area of minimized risk exposure. The risk analysis process provides a proactive methodology to identify vulnerabilities and threats to the corporations information assets. The process identies safeguards or measures to either prevent the data or asset from being violated by a threat, or identies mitigative measures to minimize negative consequences to other data assets or systems. A cost-benet analysis of selected safeguards determines the appropriateness of the measure and provides management with the analysis necessary to make a prudent judgment. Business resumption planning and testing provides an orderly business resumption plan in the event of an outage or disaster. Testing the plan ensures that the plan can be used effectively to mitigate a disaster. However, the true test of the plan is the actual declaration of a disaster and subsequent use of the plan. Information security requires the development and implementation of policies and procedures that will minimize risk exposure to information assets. Appropriate logical and physical access controls are put in place to reect the security needs based on asset classication (i.e., critical, sensitive, or condential). Breaches in security or incidents are reported and investigated to
269
determine their causes and effects. Security awareness training is fundamental to an effective information security program. Statistics have indicated that most intrusions are caused by employees. A security awareness program educates the end user to adhere to information security policies and procedures.
Integrated Risk Management Implementation

Intergrated risk management (IRM) implementation elements depict the critical path that a comprehensive risk containment program should take to ensure proactive as well as reactive measures to minimize system risk exposures. Exhibit F3.3 shows the relationship among asset classication or inventory, risk analysis, business resumption planning testing, and information security. The implementation of an IRM program begins with the most important requisite executive or senior management commitment. Without this support, risk management becomes viewed as an optional activity in addition to the ongoing required tasks. Business or project management tends to view the implementation of risk management programs as additional duties to perform, often with no additional resources. Managements support is required
Exhibit F3.3
Integrated Risk Management Elements
270
to reinforce the necessity of IRM. Along with this commitment, management should be aware of the need for risk management. Through executive-level briengs, management can understand not only the need for such a program, but also how the various elements interrelate to support each other and to benet the company. Assigning the responsibility of managing a risk containment program to an individual at a sufciently senior level of management is a necessary step to ensure success of the program. The individual assigned the responsibility for managing a risk containment program should be viewed as being a representative of executive-level managements view of prudent business practices for minimizing risk exposure to computing systems. As a precursor to a risk analysis process, corporate asset classication and a hardware and software inventory are assigned to data owners for completion. Both are fundamental to not only risk analysis, but also to business resumption planning and information security. Before the potential risk exposure can be assessed, a complete asset inventory with replacement costs is essential. Without knowing the aggregate value of the data assets at risk, the risk analysis process evaluations may yield too conservative a picture of risk exposure. By the classication of applications, suggested safeguards can be viewed in light of the value of the asset to the processing or information needs of the corporation. The risk analysis process will then identify and assess risks associated with information assets and dene cost-effective approaches to managing these risks. By dening the present computing environment, vulnerabilities, and threats natural or man-made can be identied. Based on existing safeguards, the analysis will determine the need for additional safeguards necessary to protect the information asset. It will be managements decision on whether the additional expense is merited based on the value and consequences of the data assets loss. The risk analysis process assesses the effectiveness of the information security program. Information security policies and procedures are reviewed for appropriateness, completeness, currency, and relevance. Physical and logical access controls are evaluated based on the level of security needed to protect system integrity or paper documents for classied information assets (i.e., critical, condential, and sensitive). An incident reporting system (or lack of) is reviewed to determine trends of system intrusions. Additional safeguards can then be recommended to management. An information security program should also be proactive rather than entirely reactive. A comprehensive security awareness training and general system application end-user education will, to some extent, diminish programming and operator errors, general user errors, and unintentional destruction of printed matter. This effort can be enhanced by the development and distribution of an information security manual to all staff, which delineates acceptable computing practices and procedures, records retention schedules, and depository considerations.
271
The risk analysis process reviews the corporations business resumption procedures. The procedures should be formalized in a business resumption plan that is oriented toward an expeditious resumption of critical application processing in the event of a major disruption. The plan should be checked for: clearly dened disaster declaration criteria, identication of critical application by platform, order of business resumption, identication of the alternate or backup processing site, minimum processing requirements of critical application, and processing schedules in the event of a catastrophic event. A systematic approach to business resumption must be contained in the plan that uses teams of technical and management staff to address elements or phases of business resumption, including alternate processing site processing and primary site reconstruction (if necessary). Duties and responsibilities should be well dened with levels of authority to avoid confusion in the event of a disaster. Periodic testing of the plan must be performed to validate its currency and to ensure full implementation in the event of a disaster. Testing also serves the purpose of dening weaknesses in the resumptions teams and overall business resumption planning methodology. Results should be documented to assist in updating or modifying the plan to be more responsive to the current computing environment. Both information security and business resumption planning and testing ndings gleaned through the risk analysis process provide feedback to those performing the evaluation. Additional safeguards can then be recommended to minimize identied vulnerabilities and threats. Based on these ndings, the scope of the risk analysis may be expanded or the periodicity of the risk analysis increased for risk containment purposes. The risk analysis process culminates with a report to executive or senior management, which advises them of system vulnerabilities and threats, as well as suggested safeguards. A cost-benet study is performed to determine the monetary effect of additional safeguards in relation to value of the protected asset. Through this feedback, management can then make business decisions that are based on a systematic risk assessment methodology.
Conclusion
Through the integrated risk management approach, data owners are able to use programs that are both proactive and reactive in protecting information assets. Management plays a signicant role in minimizing risk exposure to corporate computer systems by their support.
About the Author

Jose Martinez is a consultant in the San Francisco Bay area.
Index
A
Acceptance testing, 82, 121, 190 Access control, 82, 83, 121, 122, 190, 191 Accidental acts, 42 Accidental threats, 59, 206 Acid rain, 203 Action plan, 184187 cost-effective, 71 selected controls for, 87 URIS, 103119 Air mass, 208 pressure, 208 pollution, 9, 203 Alberta Clipper, 9, 203 Alcohol illegal transport/delivery of, 215 intoxication, 215 possession of by minor, 215 ALE, see Annual Loss Exposure Anemometer, 208 Annualized loss multiplier table, 16 Annualized rate of occurrence (ARO), 222 Annual Loss Exposure (ALE), 15, 221, 229 Anticyclone, 208 Anti-virus, 83, 122, 191 Application(s) control, 82, 121, 190 pre-screening, 93 programming, 25, 74 ARO, see Annualized rate of occurrence Arson, 215 ASCII generation, 241 Assault, 215 Asset(s), 250 assigning value to, 48 capital, 4 classication, 263 common threats to, 8 identication, 6, 7, 225 valuation, 34, 35, 226 Assurance controls, 29 Audit requirement, 18 Automation, knowledge-based, 237 Availability, 5 Avoidance controls, 29
B
Backdoor cold front, 208 Backup, 121, 190 Barometer, 208 Bayesian Decision Support System (BDSS), 231 BDSS, see Bayesian Decision Support System Beach erosion, 203 Beaufort Wind Scale, 208 Bermuda high, 209 BIA, see Business Impact Analysis Biometeorology, 209 Black blizzard, 9, 203 Blizzard, 9, 203 Blizzard warning, 209 Blowing snow, 209 Bomb threat, 14, 59, 64, 207 Boswerth Enterprises, Inc., 101, 153 Brainstorming, 43, 68, 69 denition, 78 process, 79 Burglary, 215 Business loss impact valuation table, 196 objectives balancing controls versus, 6 trade-offs between security and, 46 resumption planning and testing, 266
273
274
Business Impact Analysis (BIA), 30, 93, 195, 222, 224 disaster recovery plan, 171174 business impact analysis, 171 disaster recovery plan, 172173 testing, 173 forms, 195200 application/system BIA instructions, 195196 comments table, 199 nancial loss impact worksheet, 200 loss impact valuation table, 198 time sensitivity and loss impact identication, 197 loss impact table, 96 worksheet, 99
C
Capital assets, 4 Case study, 101155 available tools, 155 company outline, 101154 problem, 154 Change management, 82, 84, 121, 123, 190, 192 CIO, see Corporate Information Ofcer Climate, 209 Cold air funnel, 9, 203 Cold front, 209 Cold War, 8 Comments table, 196, 199 Communication harassing, 215 networks, 25 Computer Security Act, 234 Computer Security Institute (CSI), 217, 218, 247 Computer viruses, 193 Concealed weapon, 215 Condensation, 209 Condentiality, 5, 69, 72, 78, 193 Contingency implementation costs, 68 planning, 168169 Contraband, promoting, 215 Control(s) access, 121, 122, 190, 191 action plan, 87 application, 121, 190 assurance, 29 avoidance, 29 detection, 29 elements, 202
identication, 85 list, 121123, 190192 operations, 122, 191 recovery, 29 risk-based, 43 /risks cross-reference list, 124152, 194 Controlled substance, possession of, 215 Convection, 209 Coriolis force, 209 Corporate embarrassment, 95 Corporate Information Ofcer (CIO), 67 Cost-benet analysis, 33, 226, 254 Criminal mischief, 215 Criminal trespass, 215 Crisis intervention, 75 management planning, 30 Cross-reference sheet, 86 CSI, see Computer Security Institute Customer satisfaction, 95, 97 Cyclone, 9, 203
D
Data alteration of, 13, 206 assets, 268 availability, 42, 201 center personnel, 155 integrity, 42, 69, 201 ownership, 259 reconstruction, 68 sensitivity, 42, 91, 92, 201 threat nding, 251 frequency, 237 Database administrators, 74 Deliberate acts, 42 Deliberate threats, 59 Denial of service, 8 Department of Defense (DOD), 247, 248 Detection controls, 29 Dewpoint, 209 DHHS, see U.S. Department of Health and Human Services Disaster recovery plan, business impact analysis, 171174 business impact analysis, 171 disaster recovery plan, 172173 testing, 173 Disclosure, 206, 207 Disorderly conduct, 215 DOD, see Department of Defense DOE, see U.S. Department of Energy
Index
275
controls list, 190192 FRAP attendees, 188 risk list, 193 False name, 215 FBI, 16 FBI/CSI Computer Crime Survey, 245=246 Federal Emergency Management Administration (FEMA), 56 FEMA, see Federal Emergency Management Administration Fiduciary responsibility, 48 Final report letter, sample of, 89 Financial impact worksheet, 98 Financial loss impact worksheets, 196, 200 table, 36 Fire, 8, 57, 59, 206, 229 Flash ood, 9, 204 Flood, 8, 10, 57, 59, 204 Flood watch, 210 FRAP, see Facilitated Risk Analysis Process Fraud, 8, 14, 17, 57, 59 Freezing rain, 210 Frost, 210 Frostbite, 210 Functional business owner, 74 Funnel cloud, 10, 204
Doppler radar, 209 Downburst, 204 Drifting snow, 9, 209 Drinking in public place, 215 Drizzle, 209 Drug paraphernalia, possession of, 215 Due diligence, 1
E
Earthquake, 8, 9, 204, 258 E-business environment, 69 EF, see Exposure factor Electrical disturbance, 13, 206 Electrical outage, 59 El Nio, 210 E-mail, 246 Emanation, 13, 206 Embezzlement, 8 Emergency services, 249 Employee morale, 15, 58 sabotage, 14, 207 security awareness, 15 Encryption, 29 Enemy overrun, 14, 207 Enterprise asset, identication of information as, 4 embarrassment table, 38 introducing FRAP to, 71 Environmental failure, 13, 206 Erosion, 9, 204 Evacuation drills, 61 Excel spreadsheet, 81 Executive overview, 33 Exposure factor (EF), 222 Extortion, 8
G
GAAP, see Generally accepted accounting principles Gale, 10, 204 GAO, see General Accounting Ofce GASSP, see Generally accepted system security principles General Accounting Ofce (GAO), 218, 247 Generally accepted accounting principles (GAAP), 49 Generally accepted system security principles (GASSP), 233 Geostationary Operational Environmental Satellite, 210 Government, continuity of, 249 Gust-front, 210
F
Facilitated Risk Analysis Process (FRAP), 2, 21, 31, 6990, 101 need for, 7188 FRAP facilitator, 7577 FRAP session, 7885 FRAP team, 7375 introducing FRAP to enterprise, 7172 postFRAP meetings, 8588 pre-FRAP meeting, 7273 overview, 6971 Facilitated Risk Analysis Process (FRAP) forms, 183194 action plan, 184187 control/risks cross-reference list, 194
H
Hacking, 265 Hail, 10, 204 Harassing communication, 215 Hardware damage, 61 failure, 13, 64, 206
276
performance, improving, 237 vendor, 155 Hate crime, 215 Hazard impact analysis (HIA), 56, 60, 62, 63 Haze, 204 Heat index, 210 Heavy snow, 210 Heavy surf advisory, 210 HIA, see Hazard impact analysis High wind advisory, 211 Homicide, 215 Humidity, 204 Hurricane, 8, 10, 204 season, 211 warning, 211 watch, 211
I
Ice storm, 8, 10, 204 Impact analysis, 91, 92 Incident response procedures, 30 Indecent exposure, 215 Information awareness program, 30 condential, 54, 263 custodians of, 260 identication of as enterprise asset, 4 Protection Assessment Kit (IPAK), 65 public, 264 replacement of lost, 98, 200 resources, 72 security, 25, 74, 266 management, 261 objectives, 17 programs, 67, 267 value analysis, 47 Security Risk Analysis (ISRA), 41 sensitivity, 15, 264 society, problem in new, 246 Systems (IS), 24, 54 user of, 260 Information Systems Security Association (ISSA), 236 Information Warfare, Czar for, 249 In-prison business enterprises, 246 Insurance companies, 17 Integrated risk management (IRM), 257271 implementation, 269271 management and staff responsibilities, 260262 business and project management, 261262 business and project personnel, 262
executive management, 261 information security management, 261 internal auditor, 262 technical management, 261 risk management building blocks, 262264 asset classication, 263264 inventory, 264 risk management elements, 264267 business resumption planning and testing, 266 information security, 266267 risk analysis, 265266 risk model, 257258 roles and responsibilities, 259260 custodians of information, 260 data ownership, 259260 user of information, 260 Intentional threats, 206 Interface dependencies, 83, 122 Internal auditor, 262 International Information Security Foundation (I2SF), 233 Internet, 246 Intoxication, public, 215 Intrusion detection, 30 IPAK, see Information Protection Assessment Kit IRM, see Integrated risk management IS, see Information Systems I2SF, see International Information Security Foundation ISRA, see Information Security Risk Analysis ISSA, see Information Systems Security Association
J
Jet stream, 211
K
Kentucky Law Enforcement Council, 214
L
Lake effect snow, 10, 205 LAN security, 54 server outage, 64 technical expert, 43 users, passwords memorized by, 254 La Nia, 211 Lawrence Livermore Laboratory Risk Analysis Methodology (LRAM), 231
Index
277
Legal implication table, 37 Lightning, 10, 205 Liquid leakage, 13, 206 Loitering, 215 Loss(es), 250 estimate consensus, 28 impact valuation table, 198 LRAM, see Lawrence Livermore Laboratory Risk Analysis Methodology
O
Occluded front, 211 Operations controls, 83, 122, 191 Operator/user error, 206 Opportunity, description of, 45, 201 Organization suitability, 162166 application development and management, 165 organizational suitability, 162 oversight and auditing, 164 personnel issues, 162163 training and education, 163 Out-of-control processes, 45, 202
M
Mainframes, 257 Management support, 84 Marijuana, possession of, 215 Menacing, 215 Meteorology, 211 Misappropriation of services, 8 Monsoon, 10, 205 Motor vehicle theft, 215
P
Paralysis by analysis, 50 Paroemieology, 211 Passwords, 190, 253, 254 Payroll and Human Resource Information System (PHARIS), 183 PHARIS, see Payroll and Human Resource Information System Physical security, 74 after-hours review, 167 contingency planning, 168169 facilities, 167 incident handling, 168 Precipitation, 205 Presidents Commission on Critical Infrastructure Protection, 248249 Priority matrix, sample, 80 Product support, 242 Program bugs, 193 Project sizing, 226 Proprietary rights, 48 Public image, 47 Public intoxication, 215 Public Safety Ofce, 214
N
National Climatic Data Center (NCDC), 207 National Hurricane Center (NHC), 11, 207 National Institute of Standards and Technology (NIST), 227, 228, 229, 236 National Meteorological Center (NMC), 11, 207 National Oceanic and Atmospheric Administration (NOAA), 12, 208 National Severe Storms Forecast Center (NSSFC), 12, 208 National Severe Storms Laboratory (NSSL), 12, 208 National Weather Association (NWA), 12, 208 National Weather Service (NWS), 12, 208 Natural threats, 9, 59, 203 NCDC, see National Climatic Data Center NHC, see National Hurricane Center NIST, see National Institute of Standards and Technology NMC, see National Meteorological Center NOAA, see National Oceanic and Atmospheric Administration NOAA Weather Radio (NWR), 208 Noreaster, 211 NSSFC, see National Severe Storms Forecast Center NSSL, see National Severe Storms Laboratory NWA, see National Weather Association NWR, see NOAA Weather Radio NWS, see National Weather Service
Q
QRA, see Qualitative risk analysis Qualitative methods, other, 5368 hazard impact analysis, 5661 hazard impact analysis process, 5961 understanding threats, 5758 questionnaires, 6566 single-time loss algorithm, 6668 threat analysis, 6164 vulnerability analysis, 5356
278
Qualitative risk analysis (QRA), 2346 other uses of, 91100 application pre-screening, 93 business impact analysis, 9398 impact analysis, 9193 overview, 2324 second QRA process, 3441 asset valuation, 3538 risk evaluation, 3839 risk management, 3941 theory, 2434 assembling of competent team, 25 calculation of total threat impact, 2829 cost-benet analysis, 3031 identication of safeguards, 2930 identifying threats, 2526 impact priority, 27 prioritizing of threats, 2627 ranking of safeguards in priority order, 3132 risk analysis report, 3234 scope statement, 24 30-minute risk analysis, 4145 documentation, 45 ISRA objectives, 4142 ISRA overview, 41 out-of-control process, 45 process, 43 risk analysis matrix, 42 risk-based controls, 4345 Quality assurance program, risk analysis as part of, 3 Quantitative risk analysis, 19 Questionnaire, 65, 157182 business impact analysis, disaster recovery plan, 171174 organizational suitability, 162166 physical security, 167170 security policy, 158161 technical safeguards, 175178 telecommunications security, 179182
R
Radar, 211 Radiosonde, 211 Rain, 205 Rape, 215 Records retention schedules, 270 Recovery controls, 29 plan, 82, 121, 190 Relative humidity, 211 Report, sample of, 201202
Resisting arrest, 215 Resource impact, 91 Return on investment ratio (ROI), 254 Riot/civil disorder, 207 Risk(s) -based controls, 43 denition of, 1, 21 documentation, 70 evaluation, 34, 38, 226 factor determination sheet, 26, 33, 50 identication of, 80 list, 193 mitigation measures, 239 model, 257, 258 prioritization of, 80 Risk analysis, 73, 100, 223 database, 218 denition of, 21 facilitated, 120, 189 matrix, 42, 44 methodology, 5 process, 45 qualitative, see Qualitative risk analysis questionnaire process, 65 sample, 66 report, 32 results of, 201 software package evaluation, 240 30-minute, 41 ultimate goal of, 51 Risk analysis, effective, 121 denitions, 21 frequently asked questions, 13 how long risk analysis should take, 2 measurement of success of risk analysis, 23 what results of risk analysis tell organization, 2 what risk analysis can analyze, 2 when risk analysis should be conducted, 12 who should conduct risk analysis, 2 who should review results of risk analysis, 2 why risk analysis should be conducted, 1 identication of information as enterprise asset, 45 risk analysis as part of quality assurance program, 34 risk management objectives, 1721 standard risk analysis methodology, 517 asset identication, 67 elements of threats, 812
Index
279
interim reports and recommendations, 226 project sizing, 225 risk evaluation, 226 safeguard analysis, 226 threat analysis, 225 vulnerability analysis, 225 current developments in risk assessment and management, 232235 current issues affecting acceptance of information risk management, 235 legal developments, 234235 regulatory developments, 234 technical developments, 233 key terms and concepts of risk assessment, 221225 annualized loss expectancy or exposure, 221222 annualized rate of occurrence, 222 business impact analysis, 222 exposure factor, 222 probability, 223 qualitative or quantitative, 222223 risk, 223 risk analysis, 223 risk assessment, 223224 risk management, 224 safeguard, 224 safeguard effectiveness, 224 single loss expectancy or exposure, 224 threat, 224 uncertainty, 224225 vulnerability, 225 new directions in risk assessment and management, 235238 improving hardware and system performance, 237238 information valuation, 236 integrated risk management, 236237 knowledge-based automation, 237 NIST framework for product design and evaluation, 236 regulatory requirements, 238 reliability of threat frequency data, 237 strategic risk management, 237 recommended course of action, 242 review of history of risk assessment, 227232 changing priorities during 1980s, 228229 problems, 229232 sponsorship, research, and development during 1970s, 227228 Risk management, 34, 39 audit approach for, 238
factors affecting threats, 1215 threat identication, 78 threat occurrence rates, 1517 Risk analysis opinions, 217219 Integrated Risk Management A Concept for Risk Containment, 218219 New Trends in Risk Management, 218 Risk Assessment and Management, 217218 Risk assessment, 223, 224 automating, 255 conducting, 239 history of, 227 methodology, 250 Risk assessment, new trends in, 245256 automating of risk assessment, 255 background, 245247 Information Age, 246 political inuences, 247 decision point, 255256 new directives and guidelines, 247249 FBI/CSI 1997 survey, 247248 General Accounting Ofce report to Congress, 247 Presidents Commission on Critical Infrastructure Protection, 248249 Report of Defense Science Board, 249 Senate Permanent Subcommittee on Investigations, 248 risk assessment dened, 250 risk assessment methodology, 250255 cost-benet analysis, 254 nding threat data, 251 managing risk assessment, 252 questions, 253254 reporting results to management, 254255 valuing assets, 251 vulnerability assessment, 252253 Risk assessment and management, 221243 audit approach for risk management, 238242 conducting risk assessment, 239 identifying risk mitigation measures, 239242 securing management support for integrated risk management program, 238239 selecting best automated risk management tool, 239 central tasks of risk management, 225227 asset identication and valuation, 225 cost/benet analysis, 226 nal report, 226227
280
building blocks, 262 central tasks of, 225 cycle, 18 elements, 264 objectives, 17 software packages, 232 strategic, 237 tool, selecting best automated, 239 Robbery, 215 ROI, see Return on investment ratio
S
Sabotage, 265 Safeguard(s), 250, 267 analysis, 226 cost, 240 denition of, 21 effectiveness, 224 identication, 33 implementation, 73 ranking of in priority order, 31 recommendations, 33 technical, 175178 rewalls, 177 network infrastructure, 175176 Sandstorm, 10, 205 Scope/business process identication, 102 Scope statement, 24, 32, 66, 88, 154, 183 SDLC, see System Development Life Cycle Sea breeze, 212 Security assessment, 73 information, 266 physical, 74, 167170 after-hours review, 167 contingency planning, 168169 facilities, 167 incident handling, 168 policy, 158161 document handling, 159 policy, 158 procedures, 159 security handbook, 160 telecommunications, 179182 policy, 179 practices, 180181 standards, 180 trade-offs between business objectives and, 46 Security Awareness Fair Day, 267 Security in Cyberspace, hearings on, 248 Servers, unavailable, 193
Service level agreement, 84, 123, 192 Severe thunderstorm, 11, 212 Sexual abuse, 215 Shower, 212 Single loss expectancy (SLE), 221, 224 Single-time loss algorithm, 53, 66 SLE, see Single loss expectancy Sleet, 212 Smoke, 11, 212 Snow, 11, 205 urry, 212 squall, 212 Software alteration of, 14, 207 error, 13, 206 loss of, 61 package(s) risk analysis, 240 risk management, 232 third-party, 154 Squall line, 212 Stalking, 215 Stolen property, receiving, 215 Storm surge, 205 Strike, 14, 207 Suicide, 215 Surge, 11 Survey(s) questions, 252 random, 253 System(s) administrator, 74 analysis, 74 Development Life Cycle (SDLC), 3, 4 security architecture, 29
T
Technical management, 261 Technical safeguards, 175178 rewalls, 177 network infrastructure, 175176 Telecommunications interruption, 13, 206 security, 179182 policy, 179 practices, 180181 standards, 180 Terrorist threatening, 215 Theft, 8, 14, 207, 215 Third-party software, 154 Threat(s), 250 accidental, 59, 06 analysis, 64, 225
Index
281
U.S. Department of Health and Human Services (DHHS), 235
data, nding, 251 denitions, 13, 21, 203215 accidental threats, 206 intentional threats, 206207 natural threats, 203206 organizations, 207208 public safety department, 213214 weather, 208213 deliberate, 59 evaluation total, 27 factors affecting, 12 frequency, 19 data, 237 site-specic, 241 good, 57 identication, 7, 25, 33, 66 intentional, 206 natural, 9, 59, 203 population, 240 prioritizing of, 26 types, distinguishing between, 230 understanding, 57 vulnerability work table, 39 Thunder, 205 Thunderstorm, severe, 11 Time sensitivity and loss impact identication worksheet, 195, 197 Tornado, 11, 59, 205 warning, 212 watch, 212 Tropical depression, 213 Tropical disturbance, 213 Tropical storm, 205, 213 Trough, 213 Tsunami, 11, 205 Typhoon, 11, 206
V
Value analysis, 4751 generally accepted accounting principles, 4950 paralysis by analysis, 50 properties of information security value analysis, 4748 purpose of assigning value to assets, 48 reason for valuing assets, 4849 Value to competitor table, 37 Vandalism, 14, 207 VAX cluster, 24 Vendor solvency, 193 Virga, 213 Virus, 59, 265 Vulnerability(ies), 250 analysis worksheet, 39, 40, 55, 57 assessment, 30, 252 denition of, 21 high, 79 low, 79 medium, 79 score, 38
W
Wanton endangerment, 215 Warm front, 213 Warning, 213 Watch, 213 Water supply systems, 249 Weather, 208 Web-based applications, 75 Wheels R Us, 153, 154 Wind chill, 213 Winter storm warning, 213 Winter weather advisory, 213
U
Uncertainty, 224 Uninterrupted Power Supply (UPS), 153 UNIX platform, 154 UPS, see Uninterrupted Power Supply U Rent It System (URIS), 103119, 154 URIS, see U Rent It System U.S. Department of Energy (DOE), 228
Y
Yellow snow, 11, 206 Y2K listing of applications, 155

Information Security Risk Analysis

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Security Risk Analysis

Uploaded by

Copyright:

Available Formats

Information Security Risk Analysis

OTHER AUERBACH PUBLICATIONS