Information Security Risk Analysis

Information Security Risk Analysis OTHER AUERBACH PUBLICATIONS A Standard for Auditing Computer Applications Martin K...

Author: Thomas R. Peltier

76 downloads 1776 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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

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

Computer Telephony Integration William Yarberry, Jr. ISBN: 0-8493-9995-5

Local Area Network Handbook, 6th Edition John P. Slone, Editor ISBN: 0-8493-9838-X

Data Management Handbook 3rd Edition Sanjiv Purba, Editor ISBN: 0-8493-9832-0

Multi-Operating System Networking: Living with UNIX, NetWare, and NT Raj Rajagopal, Editor ISBN: 0-8493-9831-2

Electronic Messaging Nancy Cox, Editor ISBN: 0-8493-9825-8

TCP/IP Professional Reference Guide Gilbert Held ISBN: 0-8493-0824-0

Enterprise Operations Management Handbook, 2nd Edition Steve F. Blanding, Editor ISBN: 0-8493-9824-X

The Network Manager’s Handbook, 3rd Edition John Lusa, Editor ISBN: 0-8493-9841-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

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: [email protected]


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 Routledge’s 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 networks—Security measures. 3. Risk assessment. I. Title. QA76.9.A25 P429 2001 005.8—dc21 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, microfilming, 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. Specific 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 identification 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.

v

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 Identification ..................................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 Definitions ...................................................................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 Management—A 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 O’Leary, the Director of the Computer Security Institute’s Education Resource Center. It was his encouragement to “Try it. If they don’t stone you, then you’re onto something.” John’s approach is always a bit more formal, but he encouraged me to find the path of least resistance. The next group that needs addressing is the British contingent. John Blackley (a Scot), who found it difficult that I could find 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 fits 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 first 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 O’Hanley for his enthusiastic backing of this book. ix

Introduction

The dictionary defines risk as “someone or something that creates or suggests a hazard.” In today’s 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 defines risk as “someone or something that creates or suggests a hazard.” In today’s 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

2


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 specific 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 benefit of a risk analysis is whether it is prudent to proceed. It allows management to examine all currently identified 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 classified as confidential 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.

Effective Risk Analysis

3

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 decision–making 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 identified 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, confidentiality, 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 organization’s 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 identified 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.

4


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 fiduciary responsibility to adequately protect the assets of the enterprise. With capital assets, it is easy to see that stealing property affects the enterprise’s ability to conduct business. So now, the security professional must help management identify intellectual property and implement effective, cost-efficient safeguards.

Risk Management Quality Assurance Requires Identification 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 classification policy and analysis methodology. The individual safeguards will differ depending on whether the availability, integrity, or confidentiality 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 modification or corruption


5

䡲 Confidentiality: 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-defined, and a methodology to assist users in determining the level of classification 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 benefit 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 confidence 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.

6


Asset Identification 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 first 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 find 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: Don’t spend resources to protect garbage. 3. The hacker likewise has a cost-benefit 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 classification 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 enterprise’s physical assets. In actuality, this is probably the least of the total investment and easier to recover.

7


Exhibit 1.3 Asset Identification: Networks and Software Networks

Software a

Front-end processors Workstations Modems Communication lines Data encryption tools Satellite connections Remote access security

Operating systems Utilities Compilers Database software Application software Catalogued procedure libraries

a

Be sure to consider both purchased third-party and inhouse developed software.

Exhibit 1.4 Asset Identification: Physical and Other Assets Physical

The building HVAC a Furniture Supplies Machinery Fire control systems a

Other

Employees Policies Procedures Customer confidence

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 definition 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 specific asset is cannot be over-emphasized. For all of the next few key points, the ability to agree on a common definition will speed the risk analysis process along.

Threat Identification Having identified 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 author’s favorite, “an expression of intention to inflict evil, injury, or damage.”

8


There can be an unlimited number of threats that may be of concern to an enterprise. Any number of “good” threats can be identified, such as fire, flood, 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 first 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-profile 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, modification, disclosure, or destruction of the information asset.


9

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 first way may be to review current risk management textbooks and develop a list of possible threats. The definitions 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 definitions 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 definitions 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 sufficient 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 10°F, 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 briefly, 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 flow 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 earth’s 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 flood: A flood 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 floods 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 flow or an overflow of rivers or streams from their natural or artificial 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 defined 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 classified 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 Pacific Ocean. This same tropical cyclone is known as a typhoon in the western Pacific 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 flow 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 snowflakes. 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 Pacific Ocean. This same tropical cyclone is known as a hurricane in the eastern North Pacific 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, definitions, and rates of occurrence are: National Hurricane Center (NHC): A branch of the Tropical Prediction Center, it is the office 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 Pacific. 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, specifically 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 flash floods, 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 flood warnings. It will be necessary to identify accidental threats and intentional threats. It cannot be stressed enough that the definitions will be the key to a successful risk analysis process. Too many times, risk teams attempt to determine the impact of a specific threat, while each member has his or her own understanding of what the specific threat means. Exhibit 1.7 lists accidental and intentional threats developed by John O’Leary, Director of the Education Resource Center of the Computer Security Institute. As one can see, some of the definitions will need to be examined and refined. As an example, “fire”; there are at least three definitions for fire that would take into account a small fire, a moderate fire, and a catastrophic fire. For team members to give creditable service to the risk analysis process, it will be necessary to have the definitions as precise as possible.

Factors Affecting Threats Identifying a threat is just the first 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 O’Leary, Director of the Education Resource Center of the Computer Security Institute.

Threat Definitions — Accidental Disclosure: The unauthorized or premature accidental release of proprietary, classified, company confidential, personal, or otherwise sensitive information. Electrical disturbance: A momentary fluctuation 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 conflagration 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 sufficient magnitude to cause delays in processing or monetary loss to the enterprise. Liquid leakage: A liquid inundation from sources other than a flood. 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 modified 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 sufficient magnitude to cause interruptions in the data transfer via telecommunications between computer terminals, remote or distributed processors, and host computing facility.

Threat Definitions — Intentional Alteration of data: An intentional modification, insertion, or deletion of data, whether by authorized users or not, that compromises the auditability, recoverability, availability, confidentiality, 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 modification, insertion, or deletion of operating system or application system programs, whether by an authorized user or not, that compromises the auditability, efficiency, recoverability, availability, confidentiality, or integrity of information, programs, the system, or resources controlled by the computer systems. Bomb threat: A notification of the existence of an explosive device at a facility, whether true or not. Disclosure: The unauthorized or premature intentional release of proprietary, classified, company confidential, 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 financial 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 classified 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 files. 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 fire-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 office complex was typical when it came to security officers in the lobby, an additional level of access for restricted areas, and a fire-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 dissatisfied? Is there unrest within the ranks? 䡲 Local economic conditions: is the surrounding area economically deprived? 䡲 Visibility: is the organization a high-profile company or agency? 䡲 Redundancies: are there backup systems in place? 䡲 Proficiency 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 identified, 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 specific weather threat during a

16


calendar year. The risk management team will need to research these findings 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 five-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 specific activity has occurred within its jurisdiction. This information, along with the information gathered by the enterprise’s 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 enterprise’s 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 flood area. A major flood 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 flood 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 fulfills 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 specific 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 five risk management principles, which have been implemented by organizations that have been identified 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 confidence in the organization. 2. Protect confidentiality of sensitive information (personal, financial, trade secret, etc.). 3. Protect sensitive operational data for inappropriate disclosure. 4. Avoid third-party liability for illegal or malicious acts committed with the organization’s 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-benefit 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 identified and implemented must address specific 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 specific programs may vary, the practices identified in the 1998 Government Accounting Office 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-benefit 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 enterprise’s 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 Institute’s 2000 Buyers Guide, there are 26 different advertisements for risk analysis products, software, and consulting services. The organizations that are most satisfied with their risk analysis process are those that have defined 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 quantified, 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/benefit assessment effort is essential. 䡲 The results can be expressed in management-specific 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 difficult 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 flexibility 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-benefit 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).

Definitions 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, modification, disclosure or destruction of information resources, applications or systems. Vulnerability: a weakness in a system, application, infrastructure, control or design flaw 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-benefit for implementation. By establishing a quality risk management team, this subjective analysis can rely on the expertise of the enterprise’s 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 first 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 first method examined is a ten-step process that establishes the risk analysis process from project planning to the final 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 definition 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 specific 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 specific 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, confidentiality, and availability of information being processed by specific applications or systems. Consider the types of information security challenges facing the organization, and use this to define 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.

Qualitative Risk Analysis

25

Step 2: Assemble a Competent Team It is essential that properly qualified 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 final 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 definitions for each. While this may be time-consuming for the first one or two risk analysis processes, once the list has been developed and “field-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 first and then go on to confidentiality issues. Or one can have them identify natural hazards and then accidental and finally 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 identified, 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 identified 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 fits into the Priority Table. It is necessary to establish what each category means so that the team members are working with the same definition of threat occurrence. The members can either do this task independently and then average the findings, 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 figures discussed in Chapter 1. Exhibit 2.2 Priority Table Medium to

Low to Low

Medium

Medium

High

High

1

2

3

4

5

27


Exhibit 2.3. Threat Evaluation Total Application Threats

Threat Priority

Fire

3

Water damage

2

Theft

2

Tornado

3

Loss Impact

Risk Factor

However, the difference here is not trying to find 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 find the perfect answer. Once the probability of occurrence has been determined, those figures 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 specific 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 Threat Priority

Loss Impact

Fire

3

5

Water damage

2

5

Theft

2

3

Tornado

3

5

Application Threats

Risk Factor

Step 6: Calculate Total Threat Impact During this step, the team adds the Threat Priority figure and the Loss Impact value to achieve the Risk Factor for each identified 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 Identification Worksheet. No enterprise has sufficient resources to examine all risks, regardless of their impact and probability. Therefore, it is necessary to determine which risk factors will be identified 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 Threat Priority

Loss Impact

Risk Factor

Fire

3

5

8

Water damage

2

5

7

Theft

2

3

5

Tornado

3

5

8

Application Threats

29


Exhibit 2.6 Safeguard Identification Worksheet Application Threats

Risk Factor

Fire

8

Tornado

8

Water damage

7

Theft

5

Possible Safeguards

Safeguard Cost

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 identified 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 Identification Worksheet (Exhibit 2.7). It may be beneficial to list all safeguards considered and rank them according to the team’s 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-Benefit 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 Identification Worksheet Application Threats

Risk Factor

Possible Safeguards

Safeguard Cost

Fire

8

Fire suppression system

$15,000

Tornado

8

Business continuity plan

$75,000

Water damage

7

Business continuity plan

$75,000

Theft

5

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-benefit 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 significant 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 identified control and all of the threats that this control would help alleviate.

Step 9: Rank Safeguards in Priority Order Once the cost-benefit 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-benefit 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 findings 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 sufficient to meet the enterprise’s 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 fiduciary 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 identified 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.


2.

3.

4.

5.

6.

7.

8.

33

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 findings. 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 findings of the QRA team, and the risk analysis process in particular. Threat Identification: 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 identified 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, confidentiality, and integrity. Be sure to include all definitions. This is important for all threats as well as categories. As a historical document, it is necessary to include a clear picture of the team’s 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 specific threat might occur and then its impact on the enterprise if it did occur. In the report, identify the definition 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 Identification: 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-Benefit Analysis: Management’s acceptance of the findings and recommendations depends on how well the QRA team’s cost-benefit analysis is understood. It is important, then, to ensure that the report identifies the process used and how it takes into consideration the business objectives of the enterprise. Safeguard Recommendations: The final, and probably most important, element is the QRA team’s recommendations. The recommendations can include the control to be implemented, the control alternative, or whether to accept the risk as the most beneficial 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. definitions c. threats by priority order d. research reports The Risk Analysis Report is a confidential 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 first process and then turns it ever so slightly to create a modified approach. This version was designed to overcome identified 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 confidence, or positive press. This method uses a “scoring system” to enable financial risks to be compared to non-financial 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 identified 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, confidentiality, and integrity, or impacts to disclosure, modification, 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 definitions of each of these elements. Additionally, it is necessary to agree on the definition 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 identification takes on a number of different approaches, but they all lead to the same result. The asset to be reviewed has been identified 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 specific asset is properly identified 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 specific level of employee; what is important is that the employee has sufficient knowledge to provide insight into how things can go wrong and what needs to be done to correct them. Once the scope statement is finalized and the definitions 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 first 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 Table

Financial Loss

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

Valuation Score

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 financial 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 specific objectives. As you can see, this table has ten values. That may be too fine 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 specific 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 modified (as seen in the discussion on business impact analysis) and the elements to be reviewed can also be modified to meet specific 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 final 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 identifiers (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


Disclosure

Modification

Unavailability

Destruction

Exhibit 2.10

Extent of Legal Implication Table

Extent of Legal Implication

Valuation Score

Under $5K

1

Between $5K and $10K

4


5

Between $50K and $1M and/or CIO liable for prosecution

8

Over $1M and/or Officers and/or Directors liable

10

Exhibit 2.11 Value to Competitor Table Value to Competitor

Valuation Score

Less than $50,000

1


4

Between $100K and $10M

5

Over $10M

7

Embarrassment

Confidentiality

Legal Impacts

User Disruption

Value asset groups in terms of the impact on business operations for breaches of availability, confidentiality, and integrity

Financial Loss

Exhibit 2.9 Sample QRA Worksheet

38


Exhibit 2.12

Enterprise Embarrassment Table

Enterprise Embarrassment

Valuation Score

Embarrassment restricted to within the project or work site

1

Embarrassment spread to other work areas of operating group or division

2

Embarrassment spread throughout the enterprise

3

Public made aware through local press coverage

5

Adverse national press

7

Stock price impacted

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 findings 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 identification 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 definitions 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


Exhibit 2.13

Threat Vulnerability Work Table

Probability

Impact Low

Medium

High

High

3

6

9

Medium

2

5

8

Low

1

4

7

each threat individually and then determine the specific 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 — fire 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 identified, 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 final process, the identification 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

Asset Under Review:

Destruction

Unavailability

Modification

Disclosure

Scores

Vulnerability Score Without Control

With Control

Threats:

level to the asset under review. Using the totals from Stage 1, the QRA team has identified those assets that are important to the enterprise. With the scores from Stage 2, the team has identified the threats that expose the enterprise and its assets to an unacceptable level of concern. As in the first 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 identified. 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 final 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 identifies the individual or department responsible for implementation of the countermeasure. Included in this identification 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 final 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 Erwin’s 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 difficult concept for the layperson to grasp. To ensure that the ISRA process is completed in a timely and efficient 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 specific 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-benefit 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 defined by three objectives: 1. Data integrity: the prevention of unauthorized or undesirable modification 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 specific 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 identification of the risks. Controls can then be identified based on the risks. Care must be taken not to define controls until the risks have been identified. This will ensure that only risk-based controls are applied. Exhibit 2.15

Risk Analysis Matrix Data Integrity

Sensitivity

Availability

Accidental Acts

Undesirable Event (error & omission)

Deliberate Acts

Unauthorized Event (fraud & misuse) Modification or Destruction of Information

Disclosure of Information

Unavailability of Information or Services


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 office, 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 flipcharts, 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 modified or destroyed accidentally, because of the change to the system that is being studied. The risks are then written on a flipchart for the participants to view. The process is repeated for the other headings until the matrix is filled. When all six categories have been reviewed, the team reviews the lists, makes any modifications 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 identified, the team can select controls (safeguards, standards, rules, etc.) that best protect against the specific 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 identified, a cost-benefit 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 fields • Repeat entry of data

• Fail to log-off after usage • Route output to incorrect printer • Send message to wrong person

• Media destroyed by accident • Flood, fire • Telecommunications outage


Deliberate Acts

• Enter, use, or produce false reports • Modify, replace, or reorder data • Misrepresent information

• Access without authorization • Disclose without authorization • Copy without authorization

• Destroy, damage, or contaminate data • Denial-ofservice attack • Sabotage

Unauthorized Event (fraud & misuse)

Modification or Destruction of Information



Exhibit 2.17

After: Matrix with Suggested Solutions Data Integrity

Sensitivity

Availability

Accidental Acts

• Edit checking • Desk checking • Checks and balances

• Access control • Segregation of duties • Physical security

• Backup • System design • Redundancies


Deliberate Acts

• Passwords • Sign on (unique userID) • Audit trails

• Passwords • Sign on • Waste disposal • Storage procedures • ACLs

• Offsite storage • Disaster plan • Physical security • Emergency procedures

Unauthorized Event (fraud & misuse)

Modification 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 identified 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 client’s needs and culture. This approach forces the team into a cost-benefit 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 specific 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 officers must be willing to accept management’s 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 first 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 definite 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 first 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 first 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 modification or corruption 2. Confidentiality: 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 defined owner of the asset must be the one to assign the value. For many organizations, the defining of an owner will be a difficult 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 organization’s proprietary rights and fiduciary 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 other’s best interest rather than one’s own best interest). There will be a need to establish two additional employee responsibility classifications. For most organizations, these classifications are: 䡲 Custodian: the employee charged with the responsibility of protecting the asset in accordance with the owner’s specific 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 sufficient 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 specific 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 organization’s 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

49

Value Analysis

Exhibit 3.1 Value Analysis Base 10 Scale Value in Dollars

Scale Value

1 or less

0

Up to 10

2

1,000

3

10,000

4

100,000

5

1,000,000

6

10,000,000

7

100,000,000

8

1,000,000,000

9

an elaborate system to determine finite values, it may be practical to create a value scale (see Exhibit 3.1). By assigning a scale value to a specific 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 first factor in the risk analysis process. The second step is to determine what value has been added to the asset to find 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 find 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 find 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 significantly 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 identified, it is necessary to find 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 efficient 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 five 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, first identify the occupations or job classifications 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 specific job classifications. The second step is to finalize the scope of the review. It could be the effects of certain job classification levels on controlling access to sensitive information, or the security of a specific LAN on the corporate network or a specific 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 one’s 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 specific jobs on sensitive information. Thus, the scope statement might be “Review of Human Resources department handling of confidential information.” To be successful in this review, one must have the definition of confidential 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 office 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 specific job plays. For nonspecific 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 confidential information, a risk analysis will concentrate on: 䡲䡲䡲䡲

unauthorized unauthorized unauthorized unauthorized

access modification disclosure destruction

55

Other Qualitative Methods

Exhibit 4.1

Vulnerability Analysis Worksheet

Destruction

Unauthorized Disclosure

Unauthorized Modification

Occupation

Unauthorized Access

Scope — Review of Human Resources department handling of confidential information.

Vice president of HR Senior managers Line managers (supervisors) Senior specialists Specialists Recruiters Diversity team lead Office 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 define what each of these review points means; that is, when reviewing “unauthorized access,” is the team to examine the job’s ability to gain access to confidential information in an unauthorized manner, or should one examine their ability to provide unauthorized access? These definitions 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 confidential 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 definitions. Once that is accomplished, then the team can begin to work the analysis in one of three ways. The first 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 confidential 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 modification, etc. The correct way is the way that works best for one’s enterprise. This author has observed that some government agencies have a difficult 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 inefficiently 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 specific 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 definitions. 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 one’s work will be suspect if any of the steps are faulty.

57


Exhibit 4.2

Blank Vulnerability Analysis Worksheet

1 2 3 4 5 6

– – – – – –

Destruction

Unauthorized Disclosure

Unauthorized Modification

Occupation

Unauthorized Access

Scope —

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 inflict 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 identified: 䡲䡲䡲䡲

fire flood fraud etc.

58


When attempting to establish a list of appropriate threats, it is necessary to ask questions on how a specific 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 identified by the team. These include: 䡲 The organization’s 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 organization’s operation facilities. Older buildings have a tendency to have less adequate fire 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 find 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 profile 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

Disclosure

Alteration of data

Flooding

Electrical disturbance

Alteration of Software

Hurricane

Electrical interruption

Bomb threat

Landslide

Emanation

Disclosure

Sandstorm

Fire

Sabotage

Snow/ice storm

Hardware failure

Fraud

Tornado

Liquid leakage

Riot/civil disorder

Tsunami

Human error

Strike

Volcanic eruption

Software error

Theft

Windstorm

Telecom interruption

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 definition of probability of occurrence and definitions of each threat. It is not sufficient to just have “fire” as a threat. There are at least three different levels of fire. To ensure that the team can give proper weight to each threat, the threat must be properly defined. 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: 䡲䡲䡲䡲䡲䡲䡲

fire flood 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

2

Type of Threat

1

Note: The lower the score, the better.

High Impact

High Low ← →1 4←

3A

Human Impact

Probability

Exhibit 4.4 Hazard Impact Analysis Worksheet

3B

← →1 4←

Property Impact

3C

Low Impact

Business Impact

4

Sub Total

5

Weak Resources →4

Strong Resources ← 1←

5

External Resources

Internal Resources

6

Total

60 Information Security Risk Analysis


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 finally 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 figure 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 fighting 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 first three steps (i.e., assemble the team, develop a scope statement, and agree on definitions), 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

3



2

4

Virus (benign)

1

1

3A

1

1

4

High Impact


Tornado

Type of Threat

Human Impact

Probability

3B

3

1

4

← →1 4←

Property Impact

3C

1

2

4

Low Impact

Business Impact

Exhibit 4.5 Hazard Impact Analysis Worksheet: Steps 1 through 4 Complete

4

8

7

13

Sub Total

5

Weak Resources →4


5

External Resources

Internal Resources

6

Total


3



2

4

Virus (benign)

1

1

3A

1

1

4

High Impact


Tornado

Type of Threat

Human Impact

Probability

3B

3

1

4

← →1 4←

Property Impact

3C

1

2

4

Low Impact

Business Impact

Exhibit 4.6 Hazard Impact Analysis Worksheet: Completed Example

4

8

7

13

Sub Total

5

2

2

5

3

3

2

Weak Resources →4


2

External Resources

Internal Resources

6

13

12

17

Total


63

64


Exhibit 4.7

Threat Analysis Worksheet

Hardware failure

D

P

Evacuation — bomb threat

D

M

P

M

Catastrophic Damage

M

Repairable Damage

P

Loss of Software

Temporary Inaccessibility

LAN server outage

Potential Causes

Hardware Damage

Temporary Interruption

Effects on Operations

M

M

Note: M – May affect. P – Probably will affect. D – Definitely will affect.

Using the scope statement and the elements to be reviewed, the team then identifies the threats to that resource and then determines if that threat: 䡲䡲䡲䡲

M = May affect P = Probably will affect D = Definitely 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.


65

Questionnaires Another method of risk analysis is the development of a questionnaire. Questionnaires can be developed to meet a specific 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 filling 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 final 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 O’Leary, 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 Officer (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 O’Leary, the Computer Security Institute’s 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. O’Leary 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 definitions. 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 Officer (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 identified 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-benefit 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 field. 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 (first) phase. 20. The IP program is reviewed annually and modified 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 first. 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 figures are multiplied by is the annual rate of occurrence (as discussed in Chapter 1). Finally, the cost of one week’s delay is added to these figures to give an STL total. The team must establish what a single day’s loss to the enterprise might be. One way to do that is to take the annual revenues and divide that figure by 260 (the typical number of working days in a year), and this will give a ballpark figure on daily losses. The algorithm represents those elements that would be necessary to recover a specific 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 difficult 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 benefits.

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 definitions. 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-profile, E-business environment. Even with the change of focus, today’s organizations must still protect the integrity, confidentiality, 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 enterprise’s assets.

Facilitated Risk Analysis Process (FRAP) overview The Facilitated Risk Analysis Process (FRAP) was developed as an efficient 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 office 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, confidentiality, 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 specific 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 quantified 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. 䡲 Specific loss estimates are generally not needed to determine if a control is needed. After identifying and categorizing risks, the team identifies 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 team’s 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.

Facilitated Risk Analysis Process (FRAP)

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 identifies threats, prioritizes those threats, and identifies 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 first 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 beneficial 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 today’s environment. The key will be that the process will help identify business risks. The risk will be classified 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 definitions in the FRAP. There will be more definitions later; but for now, one must be sure that employees understand five key definitions: 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 modification or corruption. 4. Confidentiality: 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 identified and prioritized, then appropriate controls will be identified 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 office. The meeting should have the business manager (our representative), the project development lead, and the facilitator. There will be five 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 manager’s meeting and that individual is responsible for getting the room, setting the schedule, getting the materials needed (overhead, flip charts, coffee and doughnuts). 5. Agreement on definitions. The pre-FRAP session is where the agreement on FRAP definitions is completed. There needs to be agreement on the definitions of the review elements (integrity, confidentiality, 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 first is to have the FRAP team review all identified 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 fluent 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 configured. Applications programming is the individuals who will either create the new application or customize existing application or third-party software to meet the functional owner’s 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 conflict 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 firewall administrator. The next four groups are all classified as “if appropriate.” The audit staff is a group that can offer some good ideas, but they often impact the free flow 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 specific 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. 䡲 Reflect: 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 person’s vision of options or alternatives and to reinforce action points that can help resolve any conflict or crisis.

76


䡲 Center: helping the team to accept other’s views and build confidence 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 facilitator’s 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 difficult to control.

As the FRAP facilitator, it will be necessary to develop one’s own FRAP toolkit. This toolkit should include: 䡲䡲䡲䡲䡲

flipcharts 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 author’s 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 identified 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 floor. 䡲 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 flipchart first. 䡲 Help the scribe ensure that all issues are recorded: bring a scribe along to record what is posted on the flipcharts. 䡲 One conversation at a time: here is where one’s 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 flexibility 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 identified and discussed. Typically there are five 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 fiveminute overview of the process under review (the visual model). Finally, the definitions will be reviewed and each member should be given a copy of the definitions. 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, confidentiality, and availability) and identifies risks, threats, concerns, and issues for each element. The process for brainstorming is that the facilitator will display the definition and some working examples of risks. The team is then given three minutes Exhibit 5.2. Brainstorming Definition and Sample Risks Examples of Risks (NOT a complete list) Threats to Confidentiality

• • • • • •

access without authorization disclose without authorization observe or monitor transactions copy without authorization packet sniffing on network contractor accessing confidential information

Definition: Confidentiality: 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 enterprise’s vulnerability to the risk and the business impact if the risk were to occur. These definitions are agreed upon at the pre-FRAP meeting and are presented to the team during the introduction. A typical set of definitions 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 significant, the control must be improved. 䡲 Medium Vulnerability: some weakness exists; and where the business impact potential is severe or significant, 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. 䡲 Significant Impact (Medium): will cause significant 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 first 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 finished, the facilitator will review the work and where there appears to be a conflict, 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 five 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 office 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

Vulnerability

Business Impact High

Medium

Low

High

A

B

C

Medium

B

B

C

Low

C

C

D

The FRAP session will generate three deliverables: 䡲 identification 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 identified in this FRAP process. The key to Exhibit 5.4 is: Risk = actual risk voiced by FRAP team member (double-outline) Type = integrity, confidentiality, or availability risk Priority = priority level A, B, C, or D (bold outline) Controls = controls identified to help mitigate the risk

81


Exhibit 5.4 FRAP Session Deliverables Risk #

Risk

Type

Priority

Controls

1

Information accessed by personnel not intended to have access

INT

B

3, 5, 6, 11, 12, 16

2

Unclear or non-existent versioning of the information

INT

B

9, 13, 26

3

Database could be corrupted by hardware failure, incorrect, or bad software

INT

D

4

Data could be corrupted by an incomplete transaction

INT

C

5

Ability to change data in transit and then changing it back in order to cover the activity

INT

C

6

A failure to report integrity issues

INT

A

7, 11, 12, 13, 20, 21

7

Incompletely run process or failure to run a process that could corrupt the data

INT

B

1, 2, 12, 13, 14, 15, 18, 20, 21, 25

8

Lack of internal processes to create, control, manage data across functions

INT

A

7, 13, 17, 20, 23, 25

9

No notification of integrity problems

INT

A

7, 13, 26

10

Information being used in the wrong context

INT

B

11, 12, 19

11

Third-party information may have integrity issues

INT

B

7, 13, 26

12

Third-party access to information

INT

A

3, 4, 5

The final process in the FRAP session is to identify controls for those risks identified 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 modified 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

1

Backup

Backup requirements will be determined and communicated to the service provider, including a request that an electronic notification that backups were completed be sent to the application system administrator. The service provider will be requested to test the backup procedures.

2

Recovery Plan

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.

3

Access Control

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.

4

Access Control

Access sourced: implement a mechanism to limit access to confidential information to specific network paths or physical locations.

5

Access Control

Implement user authentication mechanisms (such as firewalls, dial-in controls, secure ID) to limit access to authorized personnel.

6

Access Control

Implement encryption mechanisms (data, end-toend) to prevent unauthorized access to protect the integrity and confidentiality of information.

7

Application Control

Design and implement application controls (data entry edit checking, fields requiring validation, alarm indicators, password expiration capabilities, checksums) to ensure the integrity, confidentiality, and availability of application information.

8

Acceptance Testing

Develop testing procedures to be followed during applications development and during modifications to the existing application that include user participation and acceptance.

9

Change Management

Adhere to a change management process designed to facilitate a structured approach to modifications, to ensure appropriate steps and precautions are followed. “Emergency” modifications should be included in this process.

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.

11

Policy

Develop policies and procedures to limit access and operating privileges to those with business need.

12

Training

User training will include instruction and documentation on the proper use of the application. The importance of maintaining the confidentiality of user accounts, passwords, and the confidential and competitive nature of information will be stressed.

13

Audit/Monitor

Implement mechanisms to monitor, report, and audit activities identified as requiring independent reviews, including periodic reviews of userIDs to ascertain and verify business need.

14

Backup

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.

15

Training

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.

16

Access Control

Operations controls: mechanisms to protect the database against unauthorized access, and modifications made from outside the application, will be determined and implemented.

17

Interface Dependencies

Operations controls: systems that feed information will be identified and communicated to the service provider to stress the impact to the functionality if these feeder applications are unavailable.

18

Maintenance

Operations controls: time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants. (continues)

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.

20

Service Level Agreement

Acquire service level agreements to establish level of customer expectations and assurances from supporting operations.

21

Maintenance

Acquire maintenance and supplier agreements to facilitate the continued operational status of the application.

22

Physical Security

In consultation with facilities management, facilitate the implementation of physical security controls designed to protect the information, software, and hardware required of the system.

23

Management Support

Request management support to ensure the cooperation and coordination of various business units, to facilitate a smooth transition to the application.

24

Proprietary

Proprietary controls

25

Corrective Strategies

The development team will develop corrective strategies, such as reworked processes, revised application logic, etc.

26

Change Management

Production Migration controls, such as search and remove processes to ensure data stores are clean.

The controls can be identified 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 first 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 finished. Those three steps are: 1. risks identified 2. risks prioritized 3. controls identified

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 five deliverables: 1. 2. 3. 4. 5.

Cross-reference sheet identification of existing controls consulting with owner on open risks identification 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 identifies all the risks that would be impacted by that single control. For example, in Row 2 in Exhibit 5.4, the FRAP team has identified 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 sufficient), 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

9

Control Number


Control Description

Exhibit 5.6 Cross-reference Sheet Example

Unclear or non-existent versioning of the information Impact to business by using information that is incorrect Not responding to requests in a timely manner E-business integrity policies conflict with existing corporate policies Wrong document or data is published Incorrect use of the modification 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 confidentiality 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

16 23 25 29 35

40

44 47

50 9

Risk

2

Risk #

AVA

CON

CON

CON

B

B

B

A

A

B

INT

CON

A

A

A

B

B

Priority

INT

INT

INT

INT

INT

Type


BY WHO

Owner & IP

Operations

HR Owner & Operations Owner Owner

ACF2 has been implemented and the access control list will be reviewed to identify authorized users.

Change management procedures already in place

Employee training sessions scheduled

Backup SLA to be reviewed with operations

SLA with service provider to be implemented


Selected Controls for Action Plan

OWNER ACTION

Exhibit 5.7

8/20/00

8/20/00

7/31/00

8/15/00

complete

7/15/00

WHEN

ADDITIONAL COMMENTS


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 find 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 five deliverables: a. Scope statement b. Visual diagram c. Team members d. Meeting Mechanics e. Definitions i. risk ii. control iii. review elements (integrity, confidentiality, availability) iv. vulnerability impact 2. The FRAP session, which normally lasts about four hours and has three deliverables: a. identified 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. identification of existing controls c. selection of controls for open risks or acceptance of risk

89


Exhibit 5.8

Sample of Final Report Letter

Date:

(enter date)

To:

Mr. Owner IS Security Center of Excellence (SCoE) Manager Owner/Owner’s Representative

From:

Ms. Facilitator IS Information Management Center of Excellence (IMCoE) Manager

Subject:

Facilitated Risk Analysis

The Information Protection group facilitated a Risk Analysis session on the functionality named below. The Risk Analysis attendees identified 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 identified 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:

Mr. Owner

Facilitator:

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 identified on the attached Risk Analysis Action Plan could cause the integrity, confidentiality, availability of this system/application’s 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/Owner’s Representative IS Security Center of Excellence (SCoE) Manager

_________________________ Date

______________________________________________________

_________________________ Date

IS Information Management Center of Excellence (IMCoE) Manager

90


Most organizations agree that risk considerations and related cost-benefit 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 financial 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 financial (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 specific individual need-toknow; its loss or compromise may cause severe financial, legal, regulatory, or reputation damage to the company.

Medium

Used only by specific authorized groups with legitimate business need; may have significant adverse impact; possible negative financial impact.

Low

Information for internal business use within the company; may have adverse impact; negligible financial impact.

The project lead and the business manager are asked to complete the questionnaire to assess the application’s 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 identified 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 first 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 classification 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 financial twist to them. The first is looking for a project cost in the total budget approved. When developing prescreening questions, the values plugged into these questions will need to reflect a particular enterprise. The values shown in Exhibit 6.2 are for a fictional financial company. Thus, the first 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 final question in this example attempts to determine the level of penalty imposed by regulatory organizations if the

Other Uses of Qualitative Risk Analysis

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 final three questions will require input from the financial 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 five values, as shown in Exhibits 6.3 and 6.4. This number is due to the fact that the service provider had five levels of information classification 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

$500,001–$1.5 million

Medium $1 million or less

$1–$49 million

$50 million or more

Regulatory/ Compliance Impact

Confidential — Information that, if disclosed, could violate the privacy of individuals, reduce competitive advantage, or damage the company

Restricted — Information that is available to a specific subset of the employee population when conducting company business

Internal use — Information that is intended for use by all employees when conducting business

Public — Information that has been made available to the public through authorized company channels

2

3

4

5

10 days or more

6–9 days

73 hours–5 days

25–72 hours

24 hours or less

Longest Tolerable Outage

No regulatory or compliance issues

Limited financial penalties

Substantial financial penalties

Top Secret — Information that, if disclosed, could cause severe impact to the company’s competitive advantage or business strategies

Information Classification

Less than $1000

$1000 to $9999

$10,000 or more

Customer Impact: Number of Customers Impacted

1

Impact Value

Exhibit 6.3 Pre-screening Example 2

$500,000 or less

$1.5 million or more

High

Low

Project Cost: Total Approved Budget

Impact Value

Financial Impact: Daily Dollar Amount of Transactions Processed

Exhibit 6.2 Pre-screening Financial Questions


95


Exhibit 6.4 Impact Value

Pre-screening Example 2: Second Set of Questions

Disclosure

Contractual Obligations

1

National or international press coverage

Unable to meet external obligations

2

State or local press coverage

Delay in meeting external obligations

3

Incident known throughout the company

Unable to meet internal obligations

4

Incident known only at the division or department level

Delay in meeting internal obligations

5

Little or no impact

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 modifies 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 flow, 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 five 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 financial

For time criticality, the team asked the user community two questions. How long can the system be down before business operations are impacted?

Longest Tolerable Outage Period during Peak

24 hours or less

25–72 hours

73 hours–5 days

6–9 days

10 days or more

5

4

3

2

1

Time Sensitivity

BIA Loss Impact Table

Impact Value

Exhibit 6.5

Little or no negative impact Minor exposure to unsafe work environment

Major exposure to unsafe work environment

Serious injury

Loss of life

Loss of multiple lives

Health and Safety

Company division

— Few if anyone — Company group

0–1K

Company organization

Local or state — press — organization

National or international — press — organization

Embarrassment (comes to the attention of)

1001–10K

10,001–100K

100,001–500K

More than 500,000

Customer Satisfaction (dissatisfied customers)

Intangible Loss (dollar loss difficult to estimate)

$0–$50K

$50,001– $100K

$100,001– $1M

$1,000,001– $10M

More than $10M

Financial

Tangible Loss



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 five 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 financial staff is interviewed to determine how much is enough. To assist in this process, a financial impact worksheet (see Exhibit 6.6) is developed. There are some problems with the figures 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 figure 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 figures generated from a worksheet such as this. This author recommends that the first value to be presented to management for one day’s 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 first day’s 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 figures 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 fines Legal fines Cost of money (Ex. revenue collection delayed) Loss of competitive advantage Loss of investor confidence Loss of customer confidence Adverse public opinion Reporting delay (financial 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.

5

4

3

2

1

Weight =

(Day of Wk, Wk of Mon, Mon of Yr)

Peak Activity Period

NO

(Yes = 1, No = 0)

(Impact Value)*

Interrupt Service?

Is It Likely that an Outage Can Delay Installation, Delivery, Restoration, or Interrupt Service?

Longest Tolerable Outage Period During Peak

Time Cirticality

Minimum Impact Score =

(Name)

Key Business Processes or Business Functions Supported by the Application/System

Exhibit 6.7 BIA Worksheet

(Impact Value)

Health & Safety

(Impact Value)

Embarrassment

Total Impact Score =

(Impact Value)

Customer Satisfaction

Business Loss Impact Value

0.00

(Impact Value)

Financial


99

100


Risk analysis is not done to fulfill 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 benefits 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 identification 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 find 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 office locations, each containing a major data center: 䡲 Princeton, New Jersey 䡲 Houston, Texas 䡲 Monrovia, California

101

102 Exhibit 7.1


Scope/Business Process Identification

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 define the scope and identify the business processes after the pre-FRAP meeting and record them here. Definition: SCOPE STATEMENT

Definition: 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

Action Plan

Risk


Unclear or nonexistent versioning of the information

Database could be corrupted by hardware failure, incorrect, 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


Risk #

1

2

3

4

5

6

INT

INT

A

C

C

D

INT

INT

B

B

Priority

INT

INT

Type

Application: U Rent It System (URIS)

Exhibit 7.2

7, 11, 12, 13, 20, 21

9, 13, 26

3, 5, 6, 11, 12, 16

Controls

Employee training sessions scheduled

Change management procedures already in place

ACF2 has been implemented and the access control list will be reviewed to identify authorized users

Owner Action

FRAP Date: 1/8/2001

HR

Operations

Owner & IP

By Who

8/15/2000

complete

7/15/2000

When

(continues)

Additional Comments

Case Study

103

Risk


Lack of internal processes to create and control, manage data across functions



Third-party information may have integrity issues


Data updated internally but not being made externally

Risk #

7

8

9

10

11

12

13

INT

INT

INT

INT

INT

INT

INT

Type


Exhibit 7.2 Action Plan (Continued)

B

A

B

B

A

A

B

Priority

11, 12, 13, 19

3, 4, 5

7, 13, 26

11, 12, 19

7, 13, 26

7, 13, 17, 20, 23, 25

1, 2, 12, 13, 14, 15, 18, 20, 21, 25

Controls



Backup SLA to be reviewed with Operations

Owner Action

FRAP Date: 1/8/2001

Owner

Owner

Owner & Operations

By Who

8/20/2000

8/20/2000

7/31/2000

When

Additional Comments


Verification of authentication of originator of request

Denied access to information that you are authorized to access

Impact to business by using information that is incorrect

Security and authorization procedures are so bureaucratic as to hamper the business process

Control process so complicated that they are ignored

Personnel making changes are not adequately trained

Information could be published without proper authorization

Corporate embarrassment due to unauthorized changing of information

14

15

16

17

18

19

20

21

INT

INT

INT

INT

INT

INT

INT

INT

B

B

B

B

A

B

C

B

3, 4, 5, 6, 11, 12, 13, 16, 19, 22, 24

11, 12, 13, 19, 24

11, 12, 13, 19

3, 6

3, 6, 19, 23, 25

9, 11, 12, 13, 16, 26

6

(continues)

Case Study

105

Corporate information damaged due to information leakage

Not responding to requests in a timely manner

Internal personnel deliberately modifying data for personal/group gain/reason

E-business integrity policies conflict with existing corporate policies

Unwarranted trust in a third-party business partner

Unrecorded changes to system/application software or data

23

24

25

26

27

Risk

22

Risk #

INT

INT

B

B

A

B

INT

INT

A

B

Priority

INT

INT

Type



1, 2, 7, 25, 26

9, 11, 12

1, 2, 3, 4, 11, 12, 13, 16

7, 9, 15

4

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


E-business corporate policies cannot be implemented in other countries

Wrong document or data is published

Information from partners or suppliers has integrity problems

Audit and/or data integrity legislation causes integrity loss (trans-border)

Legal implications to the business due to misuse of trademarks and registration

Use of an out-of-date copy of the data

Synchronization issues using recovery media

Incorrect use of the modification process in the application development process (change code without testing)

28

29

30

31

32

33

34

35

INT

INT B

C

C

B

INT

INT

B

B

INT

INT

A

A

INT

INT

7, 8, 9, 16, 25

3

13

7, 12, 13, 17, 22

7, 8, 9, 26

20

(continues)

Case Study

107

Risk

Old data or documents are not removed

Modification of data due to virus introductions

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 clear documentation defining or qualifying the information

Information/data is incorrectly labeled

Risk #

36

37

38

39

40

41

1

CON

INT

INT

INT

INT

INT

INT

Type



B

B

B

A

B

B

C

Priority

7, 11, 12, 13, 23,

11, 12, 13, 23

8, 13, 23, 25

3, 5, 11, 12, 13, 20

8, 13, 23, 25

2, 10, 11, 12, 13

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


Shoulder-surfing of information

Information/data is incorrectly classified

Information/data is shared before it is released through proper channels

Access to customer, employee, or partner supplier lists are made available unknowingly

Ex-developers still have access to secure data

Use of insecure systems to transmit sensitive information/data

Disclosure of information and violation of the privacy laws

Information on laptops is unprotected

Complex processes for enabling secure e-mail capability

2

3

4

5

6

7

8

9

10

CON

CON

CON

CON

CON

CON

CON

CON

CON

B

A

B

A

A

C

B

B

C

6, 11, 12, 13, 25

4, 6, 22, 24

11, 12, 23

7, 10

4, 7, 13, 16, 20

11, 12

11, 12, 13

(continues)

Case Study

109

Risk

Government legislation prevents proper protection of sensitive information

Clear definition of confidentiality rules

Inability of the company to access confidential information between two parties at a later time

Improper protection of password lists

Uncontrolled access to printed confidential information

Introduction of “back doors” into software, data, and applications

Sensitive and nonsensitive information are mixed

Risk #

11

12

13

14

15

16

17

B

B

CON

A

CON

CON

C

B

CON

CON

B

B

Priority

CON

CON

Type



7, 8, 11, 12, 25

11, 12, 13

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


Disgruntled admin staff with high security privileges

Downstream effects are not thoroughly analyzed before a change is applied

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

Authentication for access to sensitive information is inadequate

18

19

20

21

22

23

24

25 A

B

CON

CON

B

A

A

A

B

A

CON

CON

CON

CON

CON

CON

3, 4, 5, 6, 13, 16

7, 11, 12, 13, 15, 19, 23

3, 11, 12, 13

3, 11, 12, 13

3, 11, 12, 13

3, 11, 12, 13

(continues)

Case Study

111

Risk

Collection of information in one place can cause confidentiality issues

Ability to assume another’s identity

Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally)

Assumption that developers require access to sensitive information

Access to sensitive information through the test environment

Individuals are unaware how to publish or store information on the Web

Risk #

26

27

28

29

30

31

CON

CON

CON

CON

CON

CON

Type



C

B

C

B

A

C

Priority

3, 5, 13, 16

3, 4, 13, 16

3, 5, 6, 7, 13, 16

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


Confusion over where to store sensitive information

Unclear/unknown process for classifying data

Granting access to individuals who do not have a business need for access

Information about internal systems is inadvertently released for potential later attacks

Sharing userIDs

Access to backups is not properly controlled

Broad security access is granted for simplification sake

Confidentiality contracts are unenforceable

Personal information for staff might be posted on the Internet without authorization

32

33

34

35

36

37

38

39

40

B A

CON

B

CON

CON

B

B

CON

CON

B

C

CON

CON

B

B

CON

CON

9, 12, 13, 15, 26

23

3, 7, 13

14, 20, 22

12

7, 13, 15

11, 12, 13, 19, 20

11, 12, 13, 19

(continues)

Case Study

113

Risk

False sense of security due to firewall mentality

Third-party breaks of confidentiality agreements

Unclear definition of sensitive information in joint-venture activities

New technologies leading to breaches of confidentiality

Effort and planning involved in changing a security access model

How to explain confidentiality to nonemployees

Risk #

41

42

43

44

45

46

CON

B

B

A

CON

CON

A

B

A

Priority

CON

CON

CON

Type



12

23

7, 9, 13, 26

13, 15, 23

13, 23

12, 13, 23

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


Loss of sales and increased costs due to release of competitive advantage information without company knowledge

Packet sniffing outside the Internet site by unauthorized personnel

Penalties for confidentiality agreement violations not sufficient to deter inappropriate activities

Electronic eavesdropping of company sites

Hackers could bring site down

Intruders gaining physical access to computer facilities

Hardware failure of the Internet server

47

48

49

50

1

2

3

C

B

AVA

AVA

B

B

C

B

B

AVA

CON

CON

CON

CON

22

1, 2, 3, 5, 6, 10, 21, 22,

3, 5, 6, 7, 9

5, 13

3, 4, 5, 6, 7, 9

(continues)

Case Study

115

Risk

Communication provider service outage

Hosting site lacks physical protection of information

Manual process fails when E-commerce site is unavailable

Links to back office systems fail

Overly complex system design

Incorrectly made hardware or software changes

Unanticipated volumes/usage projections

Contingency planning procedures not tested

Risk #

4

5

6

7

8

9

10

11

AVA

AVA

AVA

AVA

AVA

AVA

AVA

AVA

Type



B

B

B

B

C

B

B

C

Priority

1, 2, 8, 14, 20, 21

20, 25

8, 9

25

8, 12, 17

20, 22

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


No guarantee of server availability by service provider

Industrial action/strike at service provider

Normal planned maintenance will cause system unavailability

Topology design precludes effective/acceptable global service availability

Inadequate funding for backup capability

Planned attack by protesters

Business partner unavailability

Hardware configuration is inadequate for high availability

Technical resources lack proper training

Congestion on the Internet causes user dissatisfaction

12

13

14

15

16

17

18

19

20

21

AVA

AVA

AVA

AVA

AVA

AVA

AVA

AVA

AVA

AVA

B

B

B

C

A

C

C

B

D

D

13, 20

12, 15

13, 18, 20

3, 5, 10, 16, 22

18, 20, 21

(continues)

Case Study

117

Risk

Applications design flaws may cause resource thrashing or internal resource contention

Critical application may not be critical to service provider

E-commerce application is designed to work with only a limited set of clients

Introduction of virus may cause system/information unavailability

Insufficient monitoring of Web site may fail to report unavailability

Router or firewall failure may cause inaccessibility to services

Risk #

22

23

24

25

26

27

AVA

AVA

AVA

AVA

AVA

AVA

Type



B

B

A

C

B

C

Priority

13, 18, 20, 22

13, 20

1, 2, 10

12, 13, 20

Controls

Owner Action

FRAP Date: 1/8/2001

By Who

When

Additional Comments


Deferred Issue

Deferred Issue

Deferred Issue

4

5

Deferred Issue

A

3

There were no deferred issues

1

AVA

C

Deferred Issue

Loss of customers due to site unavailability

29

AVA

2

Backups are insufficient

28 13, 18, 20, 21

Case Study

119

120 Exhibit 7.3


Final Report

Date:

(enter date)

To:

Mr. Owner IS Security Center of Excellence (SCoE) Manager Owner/Owner’s Representative

From:

Ms. Facilitator IS Information Management Center of Excellence (IMCoE) Manager

Subject:


The Information Protection group facilitated a Risk Analysis session on the functionality named below. The Risk Analysis attendees identified 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 identified 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:

Mr. Owner

Facilitator:

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 identified on the attached Risk Analysis Action Plan could cause the integrity, confidentiality, and/or availability of this system/application’s 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/Owner’s Representative IS Security Center of Excellence (SCoE) Manager

_________________________ Date

______________________________________________________

_________________________ Date

IS Information Management Center of Excellence (IMCoE) Manager

121

Case Study

Exhibit 7.4. Controls List Control Number

Class

Control Description

1

Backup


2

Recovery Plan

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.

3

Access Control


4

Access Control

Access sourced: Implement a mechanism to limit access to confidential information to specific network paths or physical locations.

5

Access Control


6

Access Control


7

Application Control


8

Acceptance Testing


9

Change Management

Adhere to a change management process designed to facilitate a structured approach to modifications, to ensure appropriate steps and precautions are followed. “Emergency” modifications should be included in this process, (continues)

122


Exhibit 7.4. Controls List (Continued) Control Number

Class

Control Description

10

Anti-virus


11

Policy


12

Training


13

Audit/ Monitor


14

Backup

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.

15

Training

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.

16

Access Control

Operations controls: Mechanisms to protect the database against unauthorized access, and modifications made from outside the application, will be determined and implemented.

17


Operations controls: Systems that feed information will be identified and communicated to the service provider to stress the impact to the functionality if these feeder applications are unavailable.

18

Maintenance

Operations controls: Time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants.

123

Case Study

Exhibit 7.4. 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.

20



21

Maintenance

Acquire maintenance or supplier agreements to facilitate the continued operational status of the application.

22

Physical Security


23

Management Support


24

Proprietary


25


The development team will develop corrective strategies such as reworked processes, revised application logic, etc.

26

Change Management

Production migration controls such as search and remove processes to ensure data stores are clean.

Control Description


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.

Control

1

2

Exhibit 7.5 Control/Risks Cross-reference List



25

27


11



1

24


27



24

7


Risk Description

7

Risk

INT

INT

INT

AVA

AVA

AVA

INT

INT

INT

Type

B

B

B

A

B

B

B

B

B

Concern


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. Third-party access to information

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.

12 17 18 21 24 32 39


25 Information accessed by personnel not intended to have access


11

1


1

Exhibit 7.5 Control/Risks Cross-reference List (Continued)

3


37

A

B

B

B

B

A

A

B

A

B

B

B

(continues)

INT

INT

INT

INT

INT

INT

INT

INT

AVA

AVA

AVA

INT

Case Study

125

Control

Control Description

Risk Description

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 Authentication for access to sensitive information is inadequate Ability to assume another’s 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 simplification 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

Risk

20 21 22 23 25 27 28

30 38 47

50 1 17

AVA

AVA

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

Type

A

B

B

B

B

B

B

A

A

B

A

A

A

Concern




4

5

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

6 9 25 28

47



24

12

Corporate information damaged due to information leakage

22



21

1


12

A

B

B

B

A

A

A

B

B

B

A

(continues)

INT

INT

CON

CON

CON

CON

CON

INT

INT

INT

INT

Case Study

127

Control Description

Implement encryption mechanisms (data, endto-end) to prevent unauthorized access to protect the integrity and confidentiality of information.

Control

6

Ability to assume another’s 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 sniffing outside the Internet site by unauthorized personnel Electronic eavesdropping of company sites Hackers could bring site down Planned attack by protesters

27 30 47

48 50 1 17

Verification of authentication of originator of request


25

14

Timely reporting in status of users, customers, suppliers, developers, etc.

39



21

1

Risk Description

Risk


INT

INT

AVA

AVA

CON

CON

CON

CON

CON

CON

INT

INT

Type

B

B

A

B

B

B

B

B

A

A

A

B

Concern


7


Ability to assume another’s 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

27 47

50 1



25

9

Complex processes for enabling secure e-mail capability

10



9

8


21


Control process so complicated that they are ignored

18

6


17

A

A

A

B

B

B

A

A

B

A

B

B

A

(continues)

INT

INT

INT

AVA

CON

CON

CON

CON

CON

CON

INT

INT

INT

Case Study

129

Control

Control Description

Risk Description

Third-party information may have integrity issues Not responding to requests in a timely manner Unrecorded changes to system/application software and/or data Wrong document or data is published Information from partners or suppliers has integrity problems Incorrect use of the modification 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 another’s identity

Risk

11 23 27 29 30 35

1 6 7 17 24

27


CON

CON

CON

CON

CON

CON

INT

INT

INT

INT

INT

INT

Type

A

B

B

A

A

B

B

B

A

B

A

B

Concern


8


Information about internal systems is inadvertently released for potential later attacks Broad security access is granted for simplification in sake New technologies leading to breaches of confidentiality 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

Incorrect use of the modification 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

35 38 44 47

50 29

35

38 40 17 6

AVA

B

B

B

B

B

A

(continues)

CON

INT

INT

INT

INT

B

B

CON

CON

A

B

B

CON

CON

CON

Case Study

131

Control Description


Control

9

Impact to business by using information that is incorrect Not responding to requests in a timely manner E-business integrity policies conflict with existing corporate policies Wrong document or data is published Incorrect use of the modification 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 confidentiality

16 23 25 29 35

40 44


11 Unclear or nonexistent versioning of the information


9

2

Risk Description

Risk


CON

CON

INT

INT

INT

INT

INT

INT

AVA

AVA

Type

A

A

B

A

A

A

B

B

B

B

Concern




10

11

Data updated internally but not being made externally


25

13


17



1

10

Use of insecure systems to transmit sensitive information/data

7



37

6


9


Electronic eavesdropping of company sites

50

1

Loss of sales and increased costs due to release of competitive advantage information without company knowledge

47

B

B

A

B

A

A

B

A

B

B

B

B

(continues)

INT

INT

INT

INT

AVA

AVA

AVA

CON

INT

AVA

CON

CON

Case Study

133

Control

Control Description

Risk Description

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 E-business integrity policies conflict with existing corporate policies Modification of data due to virus introductions Timely reporting in status of users, customers, suppliers, developers, etc. Incomplete or nonexistent of clear documentation defining or qualifying the information Information/data is incorrectly labeled Information/data is incorrectly classified Information/data is shared before it is released through proper channels

Risk

16 19 20 21 24 25 37 39 41

1 3 4


CON

CON

CON

INT

INT

INT

INT

INT

INT

INT

INT

INT

Type

B

B

B

B

A

B

A

B

B

B

B

B

Concern


Disclosure of information and violation of the privacy laws Complex processes for enabling secure e-mail capability Clear definition of confidentiality 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 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

8 10 12 17 20 21 22 23 24

32 33

B

B

B

B

A

A

A

B

B

B

B

(continues)

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

Case Study

135

Control Description


Control

12


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

6 7 10 13 16 19 20 21 24

Risk Description

1

Risk


INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

Type

B

B

B

B

B

B

B

B

A

B

Concern


E-business integrity policies conflict with existing corporate policies Information from partners or suppliers has integrity problems Modification of data due to virus introductions Timely reporting in status of users, customers, suppliers, developers, etc. Incomplete or nonexistent of clear documentation defining or qualifying the information Information/data is incorrectly labeled Information/data is incorrectly classified 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 definition of confidentiality 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

25 30 37 39 41

1 3 4 8 10 12 17 20 21

A

A

B

B

B

B

B

B

(continues)

CON

CON

CON

CON

CON

CON

CON

CON

B

B

INT

CON

A

B

B

A

INT

INT

INT

INT

Case Study

137

Control

Control Description

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 Sharing userIDs Personal information for staff might be posted on the Internet without authorization False sense of security due to firewall mentality How to explain confidentiality 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

23 24

32 33 36 40 41 46 6 20 23

Risk Description

22

Risk


AVA

AVA

AVA

CON

CON

CON

CON

CON

CON

CON

CON

CON

Type

B

B

B

B

A

A

B

B

B

B

B

A

Concern


13


Unclear or non-existent versioning of the information

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 and control, manage data across functions No notification 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

2

6 7 8 9 11 13 16 19 20 21 24

B

B

B

B

B

B

B

A

A

B

A

B

(continues)

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

Case Study

139

Control

Control Description

Information from partners or suppliers has integrity problems Audit or data integrity legislation causes integrity loss (trans-border) Modification of data due to virus introductions 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 defining or qualifying the information Information/data is incorrectly labeled Information/data is incorrectly classified Ex-developers still have access to secure data ‘B’ and complex processes for enabling secure e-mail capability Clear definition of confidentiality rules Allocation of security privileges not known to the organization

31 37 38 39 40 41

1 3 6 10 12 20

Risk Description

30

Risk


CON

CON

CON

CON

CON

CON

INT

INT

INT

INT

INT

INT

INT

Type

A

B

B

A

B

B

B

B

A

B

B

B

B

Concern


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 Authentication for access to sensitive information is inadequate Ability to assume another’s 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 simplified in sake

21 22 23 24

25 27 28

30 32 33 35 38

B

B

B

B

B

B

A

A

B

B

A

A

(continues)

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

Case Study

141

Control

Control Description

Risk Description

Personal information for staff might be posted on the Internet without authorization False sense of security due to firewall mentality Third party breaks of confidentiality agreements Unclear definition of sensitive information in joint-venture activities New technologies leading to breaches of confidentiality Packet sniffing outside the Internet site by unauthorized personnel Hardware configuration is inadequate for high availability Congestion on the Internet causes user dissatisfaction Critical application may not be critical to service provider Insufficient monitoring of Web site may fail to report unavailability Router or firewall failure may cause inaccessibility to services Loss of customers due to site unavailability

Risk

40 41 42 43 44 48 19 21 23 26 27 29


AVA

AVA

AVA

AVA

AVA

AVA

CON

CON

CON

CON

CON

CON

Type

A

B

B

B

B

B

B

A

A

B

A

A

Concern



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.

14

15


Access to backups is not properly controlled Contingency planning procedures not tested Incompletely run process or failure to run a process that could corrupt the data

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 definition of sensitive information in joint-venture activities

7

37 11 7

23 24

35 40 43

A

A

B

B

A

B

B

B

B

(continues)

CON

CON

CON

CON

INT

INT

AVA

CON

INT

Case Study

143

Control Description


Control

16 Information accessed by personnel not intended to have access

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 modification 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 another’s identity Unknowingly/knowingly releasing information to activist organization (deliberately or accidentally)

16 21 24 35

6 25 27 28

Technical resources lack proper training

Risk Description

1

20

Risk


CON

CON

CON

CON

INT

INT

INT

INT

INT

AVA

Type

B

A

A

A

B

B

B

B

B

B

Concern


Operations controls: Systems that feed information will be identified 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.

17

18


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

Normal planned maintenance will cause system unavailability Hardware configuration is inadequate for high availability Router or firewall failure may cause inaccessibility to services Loss of customers due to site unavailability

30 6 7

14 19 27 29


17 8

Access to sensitive information through the test environment

30

A

B

B

B

B

B

B

A

A

B

(continues)

AVA

AVA

AVA

AVA

INT

AVA

INT

INT

AVA

CON

Case Study

145

Control Description


Control

19


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

13 17 19 20 21 24

32 33

Risk Description

10

Risk


CON

CON

CON

INT

INT

INT

INT

INT

INT

Type

B

B

B

B

B

B

A

B

B

Concern


20



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 E-business corporate policies cannot be implemented in other countries 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 configuration is inadequate for high availability

6

7 8 28 39 6 33 37 5 10 11 14 19

B

B

B

B

B

B

B

A

A

A

A

B

A

(continues)

AVA

AVA

AVA

AVA

AVA

CON

CON

CON

INT

INT

INT

INT

INT

Case Study

147

Control Description


Control

21

Hackers could bring site down Contingency planning procedures not tested Normal planned maintenance will cause system unavailability Loss of customers due to site unavailability

1 11 14 29

Loss of customers due to site unavailability

29


Router or firewall failure may cause inaccessibility to services

27

7

Insufficient monitoring of Web site may fail to report unavailability

26


Critical application may not be critical to service provider

23

6

Congestion on the Internet causes user dissatisfaction

Risk Description

21

Risk


AVA

AVA

AVA

AVA

INT

INT

AVA

AVA

AVA

AVA

AVA

Type

A

B

B

B

B

A

A

B

B

B

B

Concern




22

23

Hosting site lacks physical protection of information Planned attack by protesters Router or firewall failure may cause inaccessibility to services

5 17 27

E-business product is not designed to meet user expectations

Intruders gaining physical access to computer facilities

2

38


1


Access to backups is not properly controlled

37

17


9


Information from partners or suppliers has integrity problems

30

8


21

INT

INT

INT

B

A

A

B

A

B

B

B

B

A

B

B

(continues)

AVA

AVA

AVA

AVA

AVA

CON

CON

INT

INT

Case Study

149

24

Control

Proprietary Controls

Control Description

Disclosure of information and violation of the privacy laws Wrong use of the security administration procedures in applications with sensitive information Confidentiality contracts are unenforceable False sense of security due to firewall mentality Third-party breaks of confidentiality agreements Unclear definition of sensitive information in joint-venture activities Effort and planning involved in changing a security access model

8 24

39 41 42 43 45


Information/data is incorrectly labeled

1

21

Incomplete or non-existent of clear documentation defining or qualifying the information

41

Information could be published without proper authorization

Unclear strategy from the business to support the use of E-business transactions

40

20

Risk Description

Risk


INT

INT

CON

CON

CON

CON

CON

CON

CON

CON

INT

INT

Type

B

B

B

A

B

A

B

B

B

B

B

B

Concern


25

The development team will develop corrective strategies, such as reworked processes, revised application logic, etc.

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 modification 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

8 17 27 35

38 40 10 17 8 10


7

9

B

B

B

B

B

(continues)

AVA

AVA

CON

CON

INT

B

B

INT

INT

B

A

A

B

A

INT

INT

INT

INT

CON

Case Study

151

Control Description

Production migration controls such as search and remove processes to ensure data stores are clean

Control

26

Unclear or nonexistent versioning of the information No notification of integrity problems Third-party information may have integrity issues Impact to business by using information that is incorrect 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 confidentiality

9 11 16 27 29 40 44

Risk Description

2

Risk


CON

CON

INT

INT

INT

INT

INT

INT

Type

A

A

A

B

B

B

A

B

Concern


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 flood-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 five 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 someone’s 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 flux and morale is low. 7. Neither Boswerth nor Wheels R Us has an up-to-date fixed 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 firms 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 definitions a. risk b. control c. review elements (integrity, confidentiality, 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 fixed 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

Security Policy

POLICY

1 1 1 1 1 1

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 define 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?

3 = Somewhat Unclear 1

2 = Fairly Clearly

2

2

2

2

2

2

3

3

3

3

3

3

4

4

4

4

4

4

4

4 = Unclear

Rating/Value 1 2 3 4

1. Is there an information security policy in place? (1 = Yes; 4 = No)

1 = Clearly

A.

Factors

Prelim Score

Action Item

Comments

Final Score

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.

I.


1 1

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?

2

1 1

1

3. Is the information classification policy followed?

4. Is an information classification 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 specific information resources are to be handled?

2

2

1

2. Does the information classification policy address all enterprise information?

2

1

2 = Being Implemented

1. Is there a reasonable and usable information classification policy? (1 = Yes; 4 = No)

1 = Completed

2

2

2

2

2

3 = In Development

1

3. Are standards in place to supplement the policies and procedures?

DOCUMENT HANDLING

1

2. Are the policies and procedures continually evaluated against current enterprise business needs?

C.

1

3 = In Development

1. Are procedures in place to implement the information security policy?


PROCEDURES

1 = Completed

B.

3

3

3

3

3

3

3

3

3

4

4

4

4

4

4 = Haven’t Begun

4

4

4

4

4

4 = Haven’t Begun

(continues)

Questionnaire

159

Factors

Security Policy (Continued)

1 1 1 1

3. Does the handbook identify the importance of the security policy?

4. Does the handbook address the employee’s responsibilities?

5. Does the handbook stress the degree of employee personal accountability?

6. Does the handbook make clear the consequences of noncompliance?

1 1

2.

3.

TOTAL SCORE

1

1.

OTHER FACTORS

1

2. Does the handbook cover the entire policy?

2

2

2

2

2

2

2

2

3 = In Development 1


3

3

3

3

3

3

3

3

Prelim Score

4

4

4

4

4

4

4

4

4

4 = Haven’t Begun


1. Is there an information security employee handbook in place? (1 = Yes; 4 = No)

1 = Completed

D. SECURITY HANDBOOK

I. Action Item Comments

Final Score


AND

• Most activities have been implemented • Most employees are aware of the program

• Many activities have been implemented • Many employees are aware of the program and its objectives

• Some activities are under development • Most management endorses IP objectives

• Policies, standards, procedures are missing or not implemented • Management and employees are unaware of the need for a program

If the SCORE is...

23 to 40

41 to 58

59 to 76

77 to 92

Interpreting the Total Score

• IP policy and supporting documents are being developed • An IP team has been identified

Fair

• Management has expressed a need for IP policies and procedures • Audit comments are pending

• IP policy is being rolled out • Supporting standards and procedures are being developed • Employee awareness has begun

Solid

Poor

• Information Protection (IP) policy is implemented • Supporting standards and procedures are integrated into the workplace • Information classification policy and methodology have been implemented

ACTIONS might include...

Superior

The Assessment Rate is …

Use this table of Risk Assessment questionnaire score ranges to assess resolution urgency and related actions.

Questionnaire

161

1

6. Is an annual report on the level of information security compliance issued to management?

1. Does the enterprise have enough employees to support current business goals?

1

1

5. Does the security group have the authority to submit needed security policy changes throughout the enterprise?

PERSONNEL ISSUES

4

1

4. Are resources adequate to find and staff an effective information security program?

B.

4

1

3. Does the information security program have its own line item in the budget?

4

4

4

4

1

2. Are employees able to perform their duties efficiently and effectively while following security procedures?

4

1

ORGANIZATIONAL SUITABILITY

Rating/Value 1 4

1 = YES

1. Does senior management support the information security program?

A.

Factors

RATING SCALE:

4 = NO Prelim Score

Action Item Notes

Final Score

Security policies and procedures can be rendered useless if the organization does not support the information security program.

II. Originizational Suitability


1

5. Are contractor personnel subject to conficentiality agreements?

6. Are contract personnel subject to the same policies as employees?

7. Is access to sensitive/confidential information by contract personnel monitored?

1 1 1

1 1 1

1. Do employees know the business goals and direction?

2. Do employees receive security related training specific to their responsibilities?

3. Are employees receiving both positive and negative feedback related to security on their performance evaluations?

4. Is security-related training provided periodically to reflect changes and new methods?

5. Are system administrators given additional security training specific to their jobs?

6. Is there a regular security awareness and training program in place?

TRAINING AND EDUCATION

1

4. Does the enterprise have sufficient expertise to implement an information security awareness program?

C.

1

3. Are employees properly trained to perform their tasks?

2

2

2

2

2

2

2

1 1

2

1

2. Are employees and project managers aware of their responsibilities for protecting information resources?

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

4

4

4

4

(continues)

Questionnaire

163

1 1 1 1 1

1 1 1

2. Are exceptions to security policies and procedures justified 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?

6. Are audits performed on a regular basis?

7. Are unscheduled/surprise audits performed?

8. Has someone been identified as responsible for reconciling audit results?

2

2

2

2

2

2

2

2

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4


1. Are the security policies and procedures routinely tested?

D. OVERSIGHT AND AUDITING

Factors

II. Originizational Suitability (Continued) Prelim Score

Action Item

Comments

Final Score


1

1 1 1

2. Are appropriate/key application users involved with developing and improving application methodology and implementation process?

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

1

APPLICATION DEVELOPMENT AND MANAGEMENT

1. Has an application development methodology been implemented?

E.

2

2

2

2

2

3

3

3

3

3

4

4

4

4

4

Questionnaire

165

AND





If the SCORE is...

31 to 65

66 to 85

86 to 105

106 to 124


• Search for a CIO has begun • IP group has been identified • Employees have been informed that changes are under way • Management has a plan for an IP program • Audit has identified the need

Poor

• CIO is being considered • Mission statement is under development • Initial employee awareness process has begun

• CIO and mission has been chartered • Employee training is an ongoing process • Awareness training program is in place • IP objectives are reviewed annually


Fair

Solid

Superior




Physical Security

1 1 1

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 confidential information?

1 1 1 1 1

1. Are areas containing sensitive information properly secured?

2. Are workstations secured after-hours?

3. Are keys and access cards properly secured?

4. Is confidential information properly secured?

5. Are contract cleaning crews activities monitored?

AFTER-HOURS REVIEW

1

3. Is there an additional level of control for after-hours access?

B.

1

2. Is access to computing facilities controlled?

2

2

2

2

2

2

2

2

2

2

2

3

3

3

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

4

4

4



1

PHYSICAL AND FACILITIES

1 = YES

1. Is access to buildings controlled?

A.

Factors

RATING SCALE: Prelim Score

Action Item

4 = In Development Notes

4 = NO

(continues)

Final Score

The security of the equipment and the buildings used by an organization is as important as the security of a specific platform.

III.

Questionnaire

167

1 1 1

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 modifications need to be implemented?

1 1 1 1

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?

D. CONTINGENCY PLANNING

1

2. Have employees been trained as to when the IRT should be notified?

2

2

2

2

2

2

2

2

2

3

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

4


1

INCIDENT HANDLING

Factors

Physical Security (Continued)

1. Has an Incident Response Team (IRT) been established?

C.

III. Prelim Score

Action Item Notes

Final Score


1

8. Have ERPs been tested for effectiveness?

TOTAL SCORE

2

1

7. Have Emergency Response Procedures (ERPs) been implemented? 2

2

1

6. Have departments, business units, groups, and other such entities implemented business continuity plans that supplement the data center DRP?

2

1

5. Are Service Level Agreements (SLAs) that identify processing requirements in place with all users and service providers?

3

3

3

3

4

4

4

4

Questionnaire

169

AND





If the SCORE is...

23 to 40

41 to 58

59 to 76

77 to 92


Poor

• Access to sensitive areas is being defined • Incidents are handled locally • Backups are sent off-site

• 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 generally restricted • Emloyees are aware of fire safety procedures • Contingency plans have been developed

Solid

Fair

• Access to sensitive areas is restricted via automated mechanism • An Incident Response Team has been implemented • Contingency plans have been tested annually


Superior




Business Impact Analysis, Disaster Recovery Plan

2

1

1 1

3. The BIA is reviewed and updated regularly with special attention to new technology, business changes, and migration of applications to alternative platforms.

4. Critical period timeframes have been identified for all applications and systems.

5. Senior management has reviewed and approved the prioritized list of critical applications.

2

2

2

1

2. Backup planning includes identification of all critical date, programs, documentation, and support items (critical resources) required performing essential tasks during recovery period.

2

3

3

3

3

3

4

4

4

4

4



1

BUSINESS IMPACT ANALYSIS (BIA)

1 = YES

1. A business impact analysis (BIA) has been conducted on all applications and systems to determine the business processes impacted.

A.

Factors


Action Item


4 = NO

(continues)

Final Score

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.

IV.

Questionnaire

171

2

1

1 1 1

1

3. Listings of current emergency telephone numbers for police, fire department, medical aid, and company officials are strategically located throughout the facility and at off-site locations.

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.

7. Lead times for communication lines and equipment, specialized devices, power hookups, construction, firewalls, computer configurations, and LAN implementation have been factored into the DRP.

2

2

2

2

2

1

2. A “worst-case” scenario DRP to recover normal operations within prescribed timeframes has been implemented and tested.

2

3

3

3

3

3

3

3

4

4

4

4

4

4

4


1

DISASTER RECOVERY PLAN (DRP)

Factors

Business Impact Analysis, Disaster Recovery Plan (Continued)

1. A corporate disaster recovery plan coordinator has been named and a mission statement identifying scope and responsibilities has been published.

B.

IV. Prelim Score

Action Item Notes

Final Score


1

10. Contingency arrangements are in place for hardware, software, communications, software, and staff.

1

1

3. Appropriate user representatives have an active role in creating and reviewing control reliability and backup provisions for relevant applications.

4. Appropriate user representatives participate in the DRP tests.

1

2. Insurance coverage for loss of hardware and business impact is in place.

TOTAL SCORE

1

1. Provisions are in place to maintain the security of processing functions in the event of an emergency.

OTHER ISSUES

2

1

2. Training sessions are conducted for all relevant personnel on backup, recovery, and contingency operating procedures.

2

2

2

2

1

2

2

2

2

1. Bachup and recovery procedures are tested at least annually.

TESTING

1

9. Automatic restart and recovery procedures are in place to restore data files in the event of a processing failure.

C.

1

8. At least one copy of the DRP is stored at the backup site and is updated regularly.

3

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

4

Questionnaire

173

AND





If the SCORE is...

21 to 36

37 to 52

53 to 67

68 to 84


DRP is in place and has been tested Employees are trained in DRP roles BIAs are reviewed annually DRP coordinator has been identified

• DRP task force has been formed • Critical applications assessment has begun • Critical resources are being identified • Backups are stored off-site • Audit has identified a weakness in DR planning • Management is aware of its responsibility

Poor

• DRP is written • Employees are aware of their roles in the DRP • Management supports and has budgeted for FRP

• • • •


Fair

Solid

Superior




Technical Safeguards

1 1 1 1 1 1 1 1 1

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?

2

2

2

2

2

2

2

2

2

2

3

3

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

4

4



1

NETWORK INFRASTRUCTURE

1 = YES

1. Is the network environment partitioned?

A.

Factors


Action Item


4 = NO

Technical safeguards enforce the security policies and procedures throughout the network infrastructure.

V.

(continues)

Final Score

Questionnaire

175

1 1 1 1 1 1 1 1 1

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?

2

2

2

2

2

2

2

2

2

2

3

3

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

4

4


1

Factors

Technical Safeguards (Continued)

11. Are report logs reviewed and reconciled on a regular basis?

V. Prelim Score

Action Item

Notes

Final Score


2

2 2

1 1 1 1

4. Are other products in place to augment the firewall level of security?

5. Are the firewalls maintained and monitored 7 × 24

6. Have services offered across the firewall 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 firewall) been implemented?

TOTAL SCORE

2

1

3. Has the firewall been tested to determine if outside penetration is possible?

2

2

1

2. Has a risk analysis been conducted to determine if the protocols allowed maintain an acceptable level of risk?

2

1

FIREWALLS

1. Are protocols allowed to go across the firewall?

B.

3

3

3

3

3

3

3

4

4

4

4

4

4

4

Questionnaire

177

AND





If the SCORE is...

28 to 56

57 to 75

76 to 94

95 to 112


Poor

• Management has expressed a concern for network security • Internet connection is being considered

• Subject matter experts have been identified • Policy and procedures development team has been identified • Firewall implementation is underway

• Network security policy is being approved • Network and desktop standards are under development • Firewall administrator job description has been developed

Solid

Fair

• Network secrity policies and standards are implemented • System and LAN administrators are trained in security issues • Firewalls are implemented and monitored


Superior




Telecommunications Security

1 1

1

1 1

1

2. All employees have been made aware of the telecommunications policy.

3. Employees authorized for Internet access are made aware of the organization’s proprietary information and what they can discuss in open forums.

4. Employees using cellular or wireless phones are briefed on the lack of privacy of conversations when using unsecured versions of this technology.

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.

7. The organization has a published policy on prosecution of employees and outsiders if found guilty of serious premeditated criminal acts against the organization.

2

2

2

2

2

2

2

3

3

3

3

3

3

3

4

4

4

4

4

4

4



1

POLICY

1 = YES

1. There is a published policy on the use of organizational telecommunications resources.

A.

Factors


Action Item


4 = NO

(continues)

Final Score

Enterprises must take precautions to protect their information when being transmitted via various telecommunication processes.

VI.

Questionnaire

179

1 1 1

5. When possible, the mainframe security program is used to control dial-in access to specific 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.

1. Security, application, and network personnel actively work to ensure control inconvenience is as minimal as possible.

1

1

4. Are audit trails reviewed and corrective action taken on a regular basis?

PRACTICES

1

3. Financial applications available via dial-in have audit trails established to track access and transaction usage.

C.

1

2. Access to databases reachable via dial-in has an access control in place to prevent unauthorized access.

2

2

2

2

2

2

2

2

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4


1

STANDARDS

Factors

Telecommunications Security (Continued)

1. A threshold is established to monitor and suspend repeated unsuccessful dial-in attempts.

B.

VI. Prelim Score

Action Item Notes

Final Score


2

2

2

1

1

1

1

1

5. Messages and transactions coming in via phone lines are serially numbered, time stamped, and logged for audit investigation and backup purposes.

6. Employees are made aware of their responsibility to keep remote access codes secure from unauthorized access and usage.

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.

8. Removal of portable computers from the campus location must be done through normal property removal procedures.

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

2

1

4. Telephone usage logs are reviewed on a regular basis to discover potential usage abuse.

2

2

2

1

3. Special procedures and audited “firecall” userIDs have been established for application, system, and network troubleshooting activities.

2

1

2. Personnel independent of the operations staff and security administration review tamper-resistant logs and audit trails.

3

3

3

3

3

3

3

3

4

4

4

4

4

4

4

4

Questionnaire

181

AND





If the SCORE is...

23 to 40

41 to 58

59 to 76

77 to 92


Poor

• Management has expressed a concern for telecommunication security • Audit has identified weaknesses in telecommunications security

• Subject matter experts have been identified • Policy and procedures development team has been identified • Telecom standards implementation is underway

• Telecommunications security policy is being approved • Standards are under development • System and report logs are being generated

Solid

Fair

• Telecommunications security policies and standards are implemented • Telecom administrators are trained in security issues • Usage reports are monitored • Discrepancies are investigated


Superior




Appendix B

Facilitated Risk Analysis Process (FRAP) Forms Scope/Business Process Identification 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 define the scope and identify the business processes after the Pre-FRAP meeting and record them here. Definition:

A Scope Statement describes.........

SCOPE STATEMENT

To implement PeopleSoft HRMS to replace existing Payroll & HR Systems

Definition: 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

Payroll

Business Process 2

Human Resource System

Business Process 3 Business Process 4 Business Process 5 183

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

2

3

4

5

6

7

8

9

10

11

12

13

Type

INT

Risk

1

Risk #

Priority

Controls

Owner Action

Application: Payroll and Human Resource Information System (PHARIS)

ACTION PLAN

By Who

When

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.

Additional Comments

FRAP Date:


INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

INT

CON

CON

CON

CON

CON

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

1

2

3

4

5

(continues)

Facilitated Risk Analysis Process (FRAP) Forms

185

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

CON

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

Type

CON

Risk

6

Risk #

ACTION PLAN (Continued)

Priority

Controls

Owner Action

By Who

When

Additional Comments


CON

CON

CON

25

26

27

Deferred Issue

Deferred Issue

Deferred Issue

Deferred Issue

2

3

4

5

The risks below were determined to be of minor concern. Controls for risks of minor concern will not be implemented at this time.

Deferred Issue

1

28

CON

24


187

188


FRAP ATTENDEES NAME

Information Owner

(owner’s name)

Information Owner Representative Project Leader Primary Application Analyst Backup Application Analyst Technical Personnel Technical Personnel

Facilitator Scribe

(facilitator’s name)

PHONE

189


FINAL REPORT Date:

(enter date)

To:

(enter Owner’s position)

From:

Supervisor, Information Protection

Subject:


The Information Protection group facilitated a Risk Analysis session on the system/application named below. The Risk Analysis attendees identified 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 identified 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:

(owner’s name)

Facilitator:

(facilitator’s 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 identified on the attached Risk Analysis Action Plan could cause the integrity, confidentiality, and/or availability of this system/application’s 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/Owner’s Representative

_________________________ Date

______________________________________________________ ISO Project Leader

_________________________ Date

190


CONTROLS LIST Control Number

Class

Control Description

1

Backup

Backup requirements will be determined and communicated to PSOU, including a request that an electronic notification that backups were completed be sent to the application system administrator. Operations will be requested to test the backup procedures.

2

Recovery Plan

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.

3

Access Control


4

Access Control


5

Access Control


6

Access Control


7

Application Control


8

Acceptance Testing


9

Change Management

Adhere to a change management process designed to facilitate a structured approach to modifications of the application, to ensure appropriate steps and precautions are followed. “Emergency” modifications should be included in this process,


191

CONTROLS LIST (Continued) Control Number

Class

Control Description

10

Anti-Virus


11

Policy


12

Training


13

Review


14

Backup


15

Training

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.

16

Access Control


17


Operations controls: Systems that feed information will be identified and communicated to PSOU to stress the impact to the functionality if these feeder applications are unavailable.

18

Maintenance

Operations controls: Time requirements for technical maintenance will be tracked and a request for adjustment will be communicated to management if experience warrants. (continues)

192


CONTROLS LIST (Continued) Control Number

Class

Control Description

19

Training


20



21

Maintenance


22

Physical Security


23

Management Support


24

Proprietary


25


The development team will develop corrective strategies such as reworked processes, revised application logic, etc.

26

Change Management

Production migration controls such as search and remove processes to ensure data stores are clean.


193

RISK LIST Risk #

Risk Type

Risk Description

1

Integrity

Unauthorized internal access

2

Integrity

Unauthorized external access

3

Integrity

Improper editing routines for data entry functions

4

Integrity

Improper editing routines for external feeds

5

Integrity

Timeliness of external feeds

6

Integrity

Program bugs

7

Integrity

Lack of change control process (including testing)

8

Integrity

Lack of version control process (especially true when software is workstation resident)

9

Integrity

Computer viruses

10

Integrity

Corrupted database

11

Confidentiality


12

Confidentiality


13

Confidentiality

Unattended workstations

14

Confidentiality

Hardcopy management (including production, distribution, and destruction)

15

Confidentiality

User awareness of the information classification being dealt with

16

Availability


17

Availability


18

Availability

Computer viruses

19

Availability

External feeds unavailable

20

Availability

Mainframe unavailable

21

Availability

Servers unavailable (database or application)

22

Availability

Wide area network unavailable

23

Availability

Program bugs

24

Availability

Lack of application disaster recovery plan

25

Availability

Lack of proper backups

26

Availability

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 Identification 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 financial loss dollar estimates in Column G of the Comments Table. Note: Use the Financial Loss Estimation Worksheets described below to assist in identification 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. identified during the FBIA process. Any comments or notes can also be recorded for future reference. Financial Loss Impact Worksheets There are five Financial Loss Impact Worksheets to assist with Column I of the Loss Impact Worksheet described above. The first 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.

a

Peak Activity Period (day of wk, wk of mon, mon of yr)

Key Business Processes or Business Functions Supported by the Application/System (name)

D

Minimum Impact Score =

Weight =

E Is it likely that an outage can delay installation, delivery, restoration, or interrupt service? (Yes = 1, No = 0)

Interrupt Service? NO

Longest Tolerable Outage Period During Peak (Impact Value)a

Time Criticality

C

B

Health & Safety (Impact Value)

F

G

H

Embarrassment (Impact Value)

0.00

Financial (Impact Value)

I

Recommended Criticality Tier NA

TOTAL IMPACT SCORE =

Customer Satisfaction (Impact Value)

Business Loss Impact Value

____________________________________________________________

Impact Values can be found on the Loss Impact Valuation Table

5

4

3

2

1

A

FBIA Attendees:

Application/System:_____________________________________ Date:________________

Time Sensitivity and Loss Impact Identification

Business Impact Analysis (BIA) Forms

197

25–72 hours

73 hours–5 days

6–9 days

10 days or more

4

3

2

1

Little or no negative impact Minor exposure to unsafe work environment

Major exposure to unsafe work environment

Serious injury

Loss of life

Loss of multiple lives

Health & Safety

0–1K

1001–10K

10,001–100K

100,001–500K

more than 500,000

Customer Satisfaction (Dissatisfied Customers)

- Few if anyone - Company group

Company division

Company organization

Local or state - press - organization

National or international - press - organization

Embarrassment (Comes to Attention of)

Intangible Loss (Dollar Loss Difficult to Estimate)

$0–$50K

$50,001– $100K

$100,001– $1M

$1,000,001– $10M

More than $10M

Financial

Tangible Loss

Note: This table was designed to only be used to assign an Impact Value to one of the five columns to the right. It does not equate items in the same row in the second through sixth columns.

24 hours or less

Longest Tolerable Outage Period During Peak

5

Impact Value

Time Sensitivity

Loss Impact Valuation Table


0

0

0

0

0

2

3

4

5

Key Business Process

B

1

A

Application/System: D Health & Safety

C

Longest Tolerable Outage Period

(Notes or other details obtained during the facilitated session)

Comments Table

Customer Satisfaction

E

Embarrassment

F

Financial

G

Business Impact Analysis (BIA) Forms

199

200


FINANCIAL LOSS IMPACT WORKSHEET Application/System: Business Process 1: A

B

Type of Impact

Estimated Dollar Loss if Unavailable Just Beyond “Longest Tolerable Outage Period”

Loss of sales Regulatory fines Legal fines Cost of money (e.g., revenue collection delayed) Loss of competitive advantage Loss of investor confidence Loss of customer confidence Adverse public opinion Reporting delay (financial 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 office. There will be a change in application language from Cobol to an Oracle database using C++. Results of Risk Analysis Describe specific 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 specific risks: Shared files on server will lead to update problems Remote access could increase hacker activity Payroll office not as secure as Data Center Data Sensitivity — Accidental and Deliberate Acts List of specific risks: LAN administrator will have access to server Office shared with non-company personnel Sensitive information left on desk in office Data Availability — Accidental and Deliberate Acts List of specific risks: Backup no longer done by Operations LAN not covered in Data Center DRP Payroll office 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 files” 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 identified and cannot be controlled must be documented here.

Appendix E

Threat Definitions Threat Definitions 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 sufficient 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 10°F, 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 briefly, 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 flow 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 earth’s 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 flood: A flood 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 floods 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 flow or an overflow of rivers or streams from their natural or artificial 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 defined 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 classified 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 Pacific Ocean. This same tropical cyclone is known as a typhoon in the western Pacific 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 Definitions

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 flow 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 snowflakes. 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 Pacific Ocean. This same tropical cyclone is known as a hurricane in the eastern North Pacific 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, classified, company confidential, personal, or otherwise sensitive information. Electrical disturbance: A momentary fluctuation 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 conflagration 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 ofsufficient magnitude to cause delays in processing or monetary loss to the enterprise. Liquid leakage: A liquid inundation from sources other than a flood. 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 modified 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 sufficient 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 modification, insertion, or deletion of data, whether by authorized users or not, that compromises the auditability,

Threat Definitions

207

recoverability, availability, confidentiality, or integrity of the information produced, processed, controlled, or stored by the information processing systems. Alteration of software: An intentional modification, insertion, or deletion of operating system or application system programs, whether by an authorized user or not, that compromises the auditability, efficiency, recoverability, availability, confidentiality, or integrity of information, programs, the system, or resources controlled by the computer systems. Bomb threat: A notification of the existence of an explosive device at a facility, whether true or not. Disclosure: The unauthorized or premature intentional release of proprietary, classified, company confidential, 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 financial 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 classified 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 files. Vandalism: The malicious and motiveless destruction or defacement of property.

Other Definitions 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 office 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, specifically 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 office in Oklahoma City that issues tornado watches and attempts to predict tornado activity beforehand. (Tornado warnings are usually issued by local NWS offices 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 offices 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 offices.

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 fibrous 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 Definitions

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 20°F 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 flat 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 specified 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 deflected 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 flat base and a bulging upper portion resembling cauliflower. 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 Niño: A large-scale weakening of the tradewinds and warming of the surface layers in the equatorial eastern and central Pacific 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 flood-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 flooding or high water on streets, underpasses and around storm drains. Fog: A cloud with its base at the earth’s surface. Freeze: A condition occurring over a widespread area when the surface air temperature remains below freezing for a sufficient 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 32°F and –40°F. 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 significant 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 32°F/0°C. 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 fluctuation greater than 10 knots during a period less than 30 seconds. Gust-front: The boundary between air flowing into a thunderstorm and the precipitation-cooled air flowing 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 Definitions

211

High Wind Advisory: An advisory that sustained surface winds exceeding 25 mph over land are either predicted or occurring for an unspecified 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 unspecified 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 Pacific, the season is from June through November. The season begins two weeks earlier in the Eastern Pacific. Hurricane Warning: Hurricane conditions are expected within 24 hours. Complete all storm preparations and evacuate if directed by local officials. Hurricane Watch: Hurricane conditions (heavy rain, tidal flooding, 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 Niña: A large-scale cooling of the surface layers in the equatorial eastern and central Pacific Ocean. Lake effect: Warm lake water modifies 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 reflected 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 flurry: 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 Definitions

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 influenced by a cooler air mass. Warning: A public notice issued by the National Weather Service when a certain hazard (tornado, severe thunderstorm, flood, 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, flood, or winter storm) is possible. Waterspout: To ignore the technical differences, essentially a tornado over water. Can ruin a boater’s 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 –20°F. 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 significant inconveniences and may be hazardous. This can often be called a Snow Advisory or a Freezing Rain Advisory for the specific 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


officers and support staff. Twelve officers 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 officers undergo extensive background investigation and successfully complete 16 weeks of police academy training in the law, arrest procedures, driving skills, firearms, and physical fitness; and are certified by the Kentucky Law Enforcement Council. Mandatory, individual training programs ensure that each officer maintains his/her proficiency in law enforcement and emergency medical procedures, first aid, and CPR. Officers 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 Sheriff’s Department, and the Kentucky State Police. Cooperative efforts between University and local law enforcement agencies provide for accurate and prompt notification 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 officer. Students, faculty, staff, and guests of the University are encouraged to report emergencies and criminal activity to the Public Safety Office. 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 Office when the button is pushed. University law enforcement officers 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 firearms, ammunition or other weapons, including any dangerous article or substance with the potential to injure a person, is prohibited.

215

Threat Definitions

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 Trafficking in marijuana Trafficking within 1000 yds. school Unlawful transaction (minor) alcohol Wanton endangerment Total Cases Opened by MSU Police

1996

Rate

1997

Rate

1998

Rate

19 0 9 23 2 34 8 11 0 1 4 0 0 1

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

11 0 12 34 1 25 3 3 5 1 3 1 0 0

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

6 2 5 8 0 39 3 1 2 0 1 0 1 0

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

1 0 1 0 7 0

0.0001 0.0000 0.0001 0.0000 0.0008 0.0000

0 1 2 0 15 1

0.0000 0.0001 0.0002 0.0000 0.0017 0.0001

0 0 0 0 4 0

0.0000 0.0000 0.0000 0.0000 0.0004 0.0000

11

0.0013

11

0.0013

4

0.0004

11 1 3 0 1 2 0 3 1 0 2 5 1 111 0 0

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

17 0 0 3 0 0 0 0 1 0 3 3 1 87 1 2

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

11 0 0 0 0 0 1 0 0 0 3 1 1 88 1 0

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

2

0.0002

1

0.0001

0

0.0000

1 276

0.0001

1 246

0.0001

2 184

0.0002

Note: D.U.I. is NOT a criminal offense in Kentucky; it is a traffic 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 conflict 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 enterprise’s risk analysis program will reflect 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 first remember discussing risk analysis with Will at the 1991 Computer Security Institute’s (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 identified industry expert, sought me out to discuss the course and what he could do to help. Ozierz’s 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 Ozier’s section on Selecting the Best Automated Risk Management Tool, Wherein he identifies 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 Ozier’s 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 Office (GAO) has issued GOA/AIMD-98-68 Information Security Management, which offers risk management solutions to the problems identified 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 find 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 identifies “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 beneficial 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 first be defined.

Annualized Loss Expectancy or Exposure (ALE) This value is derived from the following algorithm (see also, later in this section, the definition 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 significant 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 definition for annualized rate of occurrence [ARO]) in addition to the SLE, the significance of specific risk factors is addressed and integrated into the information risk management process. Thus, risk is more accurately portrayed, and cost-benefit 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 superficially, 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 unjustified 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 defined 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 quantified. If all measurable risk elements — asset value, impact, threat frequency, safeguard effectiveness, safeguard costs, uncertainty, and probability — are quantified, 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 finite 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.0–1.0. A probability of 1.0 expresses certainty that the subject event will occur within the finite 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 first 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 final 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 specified 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 0–100 percent, to which a safeguard may be characterized as effectively minimizing a vulnerability (see the definition 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 threat’s frequency of occurrence or its significance. The SLE represents only one element of risk, the expected monetary effect of a specific threat event.

Threat This defines 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 confidence in the value of any element of the risk assessment. Uncertainty is typically measured


225

inversely with respect to confidence, from 0.0–100 percent (i.e., if uncertainty is low, confidence 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 identification and assessment of risk as well as with cost-justified 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 identification of background, scope, constraints, objectives, responsibilities, and management support. Clear project-sizing statements are essential to a well-defined and well-executed risk assessment project.

Asset Identification and Valuation This is the identification of assets and their replacement costs and the further valuing of information asset availability, integrity, and confidentiality. These values may be expressed in monetary or nonmonetary terms. This task is analogous to a BIA.

Threat Analysis This is the identification of threats that may affect the target environment. (This may be integrated with the next task, vulnerability analysis).

Vulnerability Analysis This is the identification 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 identification of risk-mitigating measures that eliminate or minimize vulnerabilities.

Cost/Benefit 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 benefit less the annualized cost to achieve mitigated risk yields the net benefit. 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 significant 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 conflict 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/benefit 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 identification 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 significantly 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 confidentiality, 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 superficially 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 Office of Management and Budget developed OMB A-71, a regulation that, in its Appendix C, established the first 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, difficulties 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 difficult if not impossible to express, with confidence in monetary terms. They further believed that related statistical data were unreliable or nonexistent. Despite the problems, the underlying methodology was sufficiently 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 quantified 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 difficult efforts necessary to perform quantitative risk assessments.

The NIST Framework In an attempt to develop a definitive 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 group’s efforts was the recognition of


Exhibit F1.1

229

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 oversimplified 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 fire) 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 fire and $60,000 for misuse of resources appears to indicate that the risks of fire and misuse of resources are the same. Managers refused to accept such an analysis. Intuitively they understood that fire is a greater threat. Management was willing to spend substantial sums to

$1.0M

$1.0M

Fire

Misuse of resources

Threat ID

Asset Value

Exposure Factor

0.5 0.00005

×

× × =

=

=

$50

$500,000

Single Loss Expectancy

×

×

×

1000

0.1

Annualized Rate of Occurrence

Exhibit F1.2 Oversimplified Algorithms Cannot Distinguish Between Threat Types

=

=

=

$50,000

$50,000

Annualized Loss Expectancy



231

avoid or prevent a devastating fire, 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 fire was represented to be less than the risk of misuse of resources. No manager bought that story. Clearly, fire 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 first warned then fired. 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 Office. Kelly AFB, Texas @RISK. Palisade Corp. Newfield, 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. Newfield, 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. Profile Analysis Corp. Ridgefield, 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 efficiency and focus the analyst’s attention on the most significant 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 superfluous information gathering and the unnecessary analysis and refinement of insignificant 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 significant 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 final form after multiple exposure drafts, and the Broad Functional Principles first exposure draft is about to be released. It is expected that the International Information Security Foundation (I2SF), formed to secure financial 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 significantly to the understanding and implementation of sound information security while providing further support for credible risk assessment. An added benefit 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 Certified 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, reflecting the perceived — and demonstrable — consequences the loss of information availability, confidentiality, or integrity can have on an organization. This report stipulates the use of quantitative, probabilistic risk assessment. In other words, management must consider the financial value of assets at risk — in monetary terms; impact, frequency, and expected loss for a variety of threats; and cost/benefit analysis of selected risk mitigation measures. A revision of OMB A-130 Appendix C, released 1996, has, unfortunately, clouded the issue significantly. While talking of the need to identify threats, vulnerabilities, expected loss potentials, and probability, as well as safeguards and risk mitigation cost/benefit 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 financial 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 state’s Office 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 difficult 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. Difficulties 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 significant and which is superfluous 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 significantly. 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 defined 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 identifies 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 justification 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 specific Information Technology environment at a specific 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 definitive 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-specific threat experience into its risk-modeling algorithms. The current databases of threat frequency (and exposure factors) have an 80 percent confidence level. As the population of BDSS users’ grows, and as users threat experience is tabulated for BDSS, the confidence 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, artificial 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 flexibility 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 fiduciary 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 find 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 define and promote to management an integrated risk management approach that can identify control shortcomings and quantify the financial 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 identifies 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/benefit 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 auditor’s concern for compliance as well as management’s need to cost-effectively manage risk.

Selecting the Best Automated Risk Management Tool Having defined 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, confidentiality, 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 specific lack of controls in the target environment, attendant financial 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/benefit 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 identified 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/benefit 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-specific threat frequency Threats Questions Vulnerabilities Quantitative data Mapping Overrides Project sizing: detail Project sizing: summary Threat-specific 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 identified, final 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 efficiently by modifying the risk model to reflect 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 firm 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 Council’s “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 21–23, 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 Quantification 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 traffic, 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 traffic 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 financial transactions, critically important data flows 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 organization’s security profile.

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 glorified 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 bank’s cash management system, an altered 911 message at a police station that said, “We’re 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 profit 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 firewalls or automating audit logs, are sometimes difficult 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 Influences — 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 Office Report to Congress In May of 1996, the General Accounting Office (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 deficiencies be corrected expeditiously, as they are identified; 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 first 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 financial 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 President’s Commission on Critical Infrastructure Protection The following month (July 1996), the Clinton White House announced an Executive Order, establishing the President’s Commission on the Critical Infrastructure Protection (PCCIP). Modeled after the NSTAC (a coalition of communications companies and the Federal government), the PCCIP’s 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 fighting 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 identified eight critical infrastructures, including: 1. 2. 3. 4. 5. 6. 7. 8.

telecommunications electrical power systems gas and oil storage and transportation banking and finance transportation water supply systems emergency services (medical, fire, 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 confine 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 President’s Commission on the Critical Infrastructure Protection’s report was released in November 1997. The report concurred with many of the findings 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 insufficiently 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 final 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 organization’s information systems and resources not just adequately, but cost-effectively. The risk assessment process examines a set of five 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, fifth, what controls could one put in place that would reduce the loss if a threat occurred, or eliminate the threat altogether? The five 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 modification, 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, finding sources for threat data, doing a survey to find 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. Define system’s assets. Determine relevant threat profiles. 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 difficult 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 office equipment. Valuing information is much more difficult. 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 confidentiality 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 confidentiality 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-benefit 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 difficult 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 findings 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 findings could reflect 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 identified 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 difficult to aggregate, automated questionnaires now exist that allow risk analysts to interview users electronically. Survey questions start with a control standard that outlines the official 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 find it difficult 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 find 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 specific 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 difficult 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 scientific 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 file. 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 final results from a profile 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 officer, 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 first 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-Benefit Analysis — Getting More Bang for Your Buck The cost-benefit 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-benefit 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 findings: 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 files 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 final 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 expert’s 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 find. It is a way of looking at a large organization in a consistent and quantifiable 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 Technology’s 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 Office of the Secretary of Defense. She is a member of the American Society for Industrial Security’s 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 reflect 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 find themselves responding to emergencies without predetermined procedures to * Martinez, Jose, “Integrated Risk Management—A 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 significant 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-defined 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 classification and control decisions regarding an automated file, 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 file 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 file or database 䡲 defining precautions for controlling access to and preserving the security and integrity of files and databases that have been classified as requiring such precautions 䡲 authorizing access to the information in accordance with the classification 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 file or database 䡲 filing incident reports to corporate security management in a thorough, timely fashion The ownership responsibilities must be performed through the life cycle of the file or database until its proper disposal. Business or application

260


managers who have been designated owners of automated or manual files 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 file 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 specific 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 specific 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 specific 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 classification 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 difficult 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. Specifically, executive management ensures that the corporation’s information assets are protected from the effects of damage, destruction, and unauthorized or accidental modifications, access, or disclosure.

Information Security Management Information security management oversees corporate policies and procedures designed to protect the corporation’s 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 define 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 classification 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 files or data files 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 findings, 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 first 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 confidential, and which data can be viewed as public information. This process is called classification 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. Specifically, the information or data must be protected from


263

loss, unauthorized or accidental modification, destruction, or inappropriate disclosure. The designated owner of the automated or manual file 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 first identifies the automated or manual files and databases that should be classified as confidential or sensitive, and identifies systems (i.e., applications) that are critical to corporate project operations. Asset classification involves the systematic identification of applications (i.e., systems) that are critical to corporate operations, and the identification of files or databases that are sensitive, confidential, 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 Classification Under asset classification, four categories of information exist: 䡲䡲䡲䡲

critical applications or data confidential information sensitive information public information

Critical Applications or Data These are defined 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 significant negative effect on the health and safety of public or employees, on the fiscal 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.

Confidential Information This information requires special precautions to protect it from unauthorized or accidental access, disclosure, or dissemination. Automated or manual systems that process confidential 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 modifications or destruction. Specifically, sensitive information requires maintenance of integrity or assurance as to its accuracy and completeness. Sensitive information may also be classified as confidential or public information. Examples of sensitive information are financial and operating information. The controlling factor for confidential is dissemination, and the one for sensitive information is integrity. Typically, sensitive information includes records of corporate financial transactions and most legal matters. The data owner is responsible for making the determination as to whether a file or database should be classified as confidential or sensitive and for defining 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 classified as confidential. Public information may be classified 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 identified 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 benefits derived from minimizing vulnerabilities (and subsequent losses) through the restriction of unauthorized access, prudent architecture or strategic planning that reflects knowledge of potential threats and vulnerabilities, and through the implementation of contingency planning for orderly business resumption.

Risk Analysis The risk analysis process identifies and assesses risks associated with corporate information assets and defines cost-effective approaches to managing such risks. The analysis identifies 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 floods) or man-made (e.g., virus, hacking, and sabotage). The risk analysis process should be carried out with sufficient 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 identification of corporate information assets that are at risk, with primary emphasis on critical applications and data 䡲 the identification 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 identification 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 findings 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 benefit 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 identifies 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 corporation’s critical applications 䡲 the identification and evaluation of alternative resumption strategies 䡲 the preparation of a cost-benefit analysis for each alternative and the selection of best alternative 䡲 the determination of specific resumption procedures and the time frame for their execution 䡲 the identification of individuals and teams within the corporation that would be responsible for managing and implementing specific resumption procedures The business resumption plan must be tested periodically to determine its accuracy and completeness and the staff’s 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 modification, destruction, disclosure, loss, or access to automated or manual records and files, 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 modification, destruction, disclosure, loss, or access to automated or manual files 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 confidential documentation, protecting passwords, message authentication and data encryption, and privacy and confidentiality. 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 officially 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 benefits from less accidental modification, 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 reflects all three programs fully implemented and addresses all critical applications and sensitive and confidential databases and files. 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 corporation’s information assets. The process identifies safeguards or measures to either prevent the data or asset from being violated by a threat, or identifies mitigative measures to minimize negative consequences to other data assets or systems. A cost-benefit 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 reflect the security needs based on asset classification (i.e., critical, sensitive, or confidential). 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 classification 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. Management’s 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 briefings, management can understand not only the need for such a program, but also how the various elements interrelate to support each other and to benefit the company. Assigning the responsibility of managing a risk containment program to an individual at a sufficiently 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 management’s view of prudent business practices for minimizing risk exposure to computing systems. As a precursor to a risk analysis process, corporate asset classification 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 classification 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 define cost-effective approaches to managing these risks. By defining the present computing environment, vulnerabilities, and threats — natural or man-made — can be identified. Based on existing safeguards, the analysis will determine the need for additional safeguards necessary to protect the information asset. It will be management’s decision on whether the additional expense is merited based on the value and consequences of the data asset’s 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 classified information assets (i.e., critical, confidential, 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 corporation’s 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 defined disaster declaration criteria, identification of critical application by platform, order of business resumption, identification 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 defined 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 defining 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 findings gleaned through the risk analysis process provide feedback to those performing the evaluation. Additional safeguards can then be recommended to minimize identified vulnerabilities and threats. Based on these findings, 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-benefit 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 significant 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, 184–187 cost-effective, 71 selected controls for, 87 URIS, 103–119 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 classification, 263

common threats to, 8 identification, 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 definition, 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, 171–174 business impact analysis, 171 disaster recovery plan, 172–173 testing, 173 forms, 195–200 application/system BIA instructions, 195–196 comments table, 199 financial loss impact worksheet, 200 loss impact valuation table, 198 time sensitivity and loss impact identification, 197 loss impact table, 96 worksheet, 99

C Capital assets, 4 Case study, 101–155 available tools, 155 company outline, 101–154 problem, 154 Change management, 82, 84, 121, 123, 190, 192 CIO, see Corporate Information Officer 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 Confidentiality, 5, 69, 72, 78, 193 Contingency implementation costs, 68 planning, 168–169 Contraband, promoting, 215 Control(s) access, 121, 122, 190, 191 action plan, 87 application, 121, 190 assurance, 29 avoidance, 29 detection, 29 elements, 202


identification, 85 list, 121–123, 190–192 operations, 122, 191 recovery, 29 risk-based, 43 /risks cross-reference list, 124–152, 194 Controlled substance, possession of, 215 Convection, 209 Coriolis force, 209 Corporate embarrassment, 95 Corporate Information Officer (CIO), 67 Cost-benefit 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 finding, 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, 171–174 business impact analysis, 171 disaster recovery plan, 172–173 testing, 173 Disclosure, 206, 207 Disorderly conduct, 215 DOD, see Department of Defense DOE, see U.S. Department of Energy

275

Index

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 Niño, 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, identification 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

F Facilitated Risk Analysis Process (FRAP), 2, 21, 31, 69–90, 101 need for, 71–88 FRAP facilitator, 75–77 FRAP session, 78–85 FRAP team, 73–75 introducing FRAP to enterprise, 71–72 post–FRAP meetings, 85–88 pre-FRAP meeting, 72–73 overview, 69–71 Facilitated Risk Analysis Process (FRAP) forms, 183–194 action plan, 184–187 control/risks cross-reference list, 194

controls list, 190–192 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 flood, 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

G GAAP, see Generally accepted accounting principles Gale, 10, 204 GAO, see General Accounting Office GASSP, see Generally accepted system security principles General Accounting Office (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

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 confidential, 54, 263 custodians of, 260 identification 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), 257–271 implementation, 269–271 management and staff responsibilities, 260–262 business and project management, 261–262 business and project personnel, 262


executive management, 261 information security management, 261 internal auditor, 262 technical management, 261 risk management building blocks, 262–264 asset classification, 263–264 inventory, 264 risk management elements, 264–267 business resumption planning and testing, 266 information security, 266–267 risk analysis, 265–266 risk model, 257–258 roles and responsibilities, 259–260 custodians of information, 260 data ownership, 259–260 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 Niña, 211 Lawrence Livermore Laboratory Risk Analysis Methodology (LRAM), 231

277

Index

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

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

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 Nor’easter, 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

O Occluded front, 211 Operations controls, 83, 122, 191 Operator/user error, 206 Opportunity, description of, 45, 201 Organization suitability, 162–166 application development and management, 165 organizational suitability, 162 oversight and auditing, 164 personnel issues, 162–163 training and education, 163 Out-of-control processes, 45, 202

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, 168–169 facilities, 167 incident handling, 168 Precipitation, 205 President’s Commission on Critical Infrastructure Protection, 248–249 Priority matrix, sample, 80 Product support, 242 Program bugs, 193 Project sizing, 226 Proprietary rights, 48 Public image, 47 Public intoxication, 215 Public Safety Office, 214

Q QRA, see Qualitative risk analysis Qualitative methods, other, 53–68 hazard impact analysis, 56–61 hazard impact analysis process, 59–61 understanding threats, 57–58 questionnaires, 65–66 single-time loss algorithm, 66–68 threat analysis, 61–64 vulnerability analysis, 53–56

278 Qualitative risk analysis (QRA), 23–46 other uses of, 91–100 application pre-screening, 93 business impact analysis, 93–98 impact analysis, 91–93 overview, 23–24 second QRA process, 34–41 asset valuation, 35–38 risk evaluation, 38–39 risk management, 39–41 theory, 24–34 assembling of competent team, 25 calculation of total threat impact, 28–29 cost-benefit analysis, 30–31 identification of safeguards, 29–30 identifying threats, 25–26 impact priority, 27 prioritizing of threats, 26–27 ranking of safeguards in priority order, 31–32 risk analysis report, 32–34 scope statement, 24 30-minute risk analysis, 41–45 documentation, 45 ISRA objectives, 41–42 ISRA overview, 41 out-of-control process, 45 process, 43 risk analysis matrix, 42 risk-based controls, 43–45 Quality assurance program, risk analysis as part of, 3 Quantitative risk analysis, 19 Questionnaire, 65, 157–182 business impact analysis, disaster recovery plan, 171–174 organizational suitability, 162–166 physical security, 167–170 security policy, 158–161 technical safeguards, 175–178 telecommunications security, 179–182

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, 201–202


Resisting arrest, 215 Resource impact, 91 Return on investment ratio (ROI), 254 Riot/civil disorder, 207 Risk(s) -based controls, 43 definition of, 1, 21 documentation, 70 evaluation, 34, 38, 226 factor determination sheet, 26, 33, 50 identification of, 80 list, 193 mitigation measures, 239 model, 257, 258 prioritization of, 80 Risk analysis, 73, 100, 223 database, 218 definition 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, 1–21 definitions, 21 frequently asked questions, 1–3 how long risk analysis should take, 2 measurement of success of risk analysis, 2–3 what results of risk analysis tell organization, 2 what risk analysis can analyze, 2 when risk analysis should be conducted, 1–2 who should conduct risk analysis, 2 who should review results of risk analysis, 2 why risk analysis should be conducted, 1 identification of information as enterprise asset, 4–5 risk analysis as part of quality assurance program, 3–4 risk management objectives, 17–21 standard risk analysis methodology, 5–17 asset identification, 6–7 elements of threats, 8–12

Index

factors affecting threats, 12–15 threat identification, 7–8 threat occurrence rates, 15–17 Risk analysis opinions, 217–219 “Integrated Risk Management —A Concept for Risk Containment,” 218–219 “New Trends in Risk Management,” 218 “Risk Assessment and Management,” 217–218 Risk assessment, 223, 224 automating, 255 conducting, 239 history of, 227 methodology, 250 Risk assessment, new trends in, 245–256 automating of risk assessment, 255 background, 245–247 Information Age, 246 political influences, 247 decision point, 255–256 new directives and guidelines, 247–249 FBI/CSI 1997 survey, 247–248 General Accounting Office report to Congress, 247 President’s Commission on Critical Infrastructure Protection, 248–249 Report of Defense Science Board, 249 Senate Permanent Subcommittee on Investigations, 248 risk assessment defined, 250 risk assessment methodology, 250–255 cost-benefit analysis, 254 finding threat data, 251 managing risk assessment, 252 questions, 253–254 reporting results to management, 254–255 valuing assets, 251 vulnerability assessment, 252–253 Risk assessment and management, 221–243 audit approach for risk management, 238–242 conducting risk assessment, 239 identifying risk mitigation measures, 239–242 securing management support for integrated risk management program, 238–239 selecting best automated risk management tool, 239 central tasks of risk management, 225–227 asset identification and valuation, 225 cost/benefit analysis, 226 final report, 226–227

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, 232–235 current issues affecting acceptance of information risk management, 235 legal developments, 234–235 regulatory developments, 234 technical developments, 233 key terms and concepts of risk assessment, 221–225 annualized loss expectancy or exposure, 221–222 annualized rate of occurrence, 222 business impact analysis, 222 exposure factor, 222 probability, 223 qualitative or quantitative, 222–223 risk, 223 risk analysis, 223 risk assessment, 223–224 risk management, 224 safeguard, 224 safeguard effectiveness, 224 single loss expectancy or exposure, 224 threat, 224 uncertainty, 224–225 vulnerability, 225 new directions in risk assessment and management, 235–238 improving hardware and system performance, 237–238 information valuation, 236 integrated risk management, 236–237 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, 227–232 changing priorities during 1980s, 228–229 problems, 229–232 sponsorship, research, and development during 1970s, 227–228 Risk management, 34, 39 audit approach for, 238

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 definition of, 21 effectiveness, 224 identification, 33 implementation, 73 ranking of in priority order, 31 recommendations, 33 technical, 175–178 firewalls, 177 network infrastructure, 175–176 Sandstorm, 10, 205 Scope/business process identification, 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, 167–170 after-hours review, 167 contingency planning, 168–169 facilities, 167 incident handling, 168 policy, 158–161 document handling, 159 policy, 158 procedures, 159 security handbook, 160 telecommunications, 179–182 policy, 179 practices, 180–181 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 flurry, 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, 175–178 firewalls, 177 network infrastructure, 175–176 Telecommunications interruption, 13, 206 security, 179–182 policy, 179 practices, 180–181 standards, 180 Terrorist threatening, 215 Theft, 8, 14, 207, 215 Third-party software, 154 Threat(s), 250 accidental, 59, 06 analysis, 64, 225

281

Index

data, finding, 251 definitions, 13, 21, 203–215 accidental threats, 206 intentional threats, 206–207 natural threats, 203–206 organizations, 207–208 public safety department, 213–214 weather, 208–213 deliberate, 59 evaluation total, 27 factors affecting, 12 frequency, 19 data, 237 site-specific, 241 good, 57 identification, 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 identification 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

U Uncertainty, 224 Uninterrupted Power Supply (UPS), 153 UNIX platform, 154 UPS, see Uninterrupted Power Supply U Rent It System (URIS), 103–119, 154 URIS, see U Rent It System U.S. Department of Energy (DOE), 228

U.S. Department of Health and Human Services (DHHS), 235

V Value analysis, 47–51 generally accepted accounting principles, 49–50 paralysis by analysis, 50 properties of information security value analysis, 47–48 purpose of assigning value to assets, 48 reason for valuing assets, 48–49 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 definition 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

Y Yellow snow, 11, 206 Y2K listing of applications, 155

Information Security Risk Analysis

Information Security Risk Analysis

Risk Analysis and Security Countermeasure Selection