MUSC Information Security Guidelines: Risk Management
v 0.4 (DRAFT – 04 May 2005)
Table of Contents
Introduction
Purpose and Scope
Applicable MUSC Policies
Applicable MUSC Standards
Risk Assessment Concepts
Goals of the Risk Assessment Process
Risk Components
Identifying Threats and Vulnerabilities
Post-Implementation Notes
Quantitative vs. Qualitative Analysis
Assessing Probability (Frequency)
Post-Implementation Notes
Assessing Impacts
Calculating Risk
Selecting and Prioritizing Security Controls
Post-Implementation Notes
Documenting the Security Plan
Communicating the Security Plan
Risk Assessment Report
Core Assessment and Reporting Guidelines
System Identification
Risk Assessment Participants
System Characterization
Guidelines for Specific System Life Cycle Stages
Initiation Stage
Development/Procurement Stage
Implementation Stage
Post-Implementation Stage
Appendices
Appendix A: Risk Analysis Worksheet
Appendix B: Security Plan Summary
Appendix C: FIPS 199
Appendix D: Security Controls
Exhibits
Exhibit: Risk Analysis Worksheet
Exhibit: Sample Worksheet
Exhibit: Risk Assessment Report Cover Page
Exhibit: Sample Cover Page
Exhibit: Template (MS-Word)
Exhibit: System Network Diagram
Exhibit: Sample Network Diagram
Exhibit: System Functional Diagram
Exhibit: Sample System Functional Diagram
Exhibit: Threat-Vulnerability Matrix
- Introduction
1.1. Purpose and Scope
These guidelines are intended to help MUSC System Owners to meet the risk assessment and risk management responsibilities that are assigned to them by MUSC's information security policies.
These guidelines apply to all MUSC faculty, students and staff who serve in system ownership roles, in all of the entities that comprise the MUSC enterprise.
1.2. Applicable MUSC Policies
Information Security
Information Security – Risk Management
Information Security – Evaluation
Information Security – Documentation
1.3. Applicable MUSC Standards
MUSC Information Security Standards: Risk Management
2. Risk Assessment Concepts
2.1 Goals of the Risk Assessment Process
All information security risk assessments at MUSC serve the same basic purpose: to select a rational set of security controls or safeguards that will minimize the total cost of information security to the MUSC enterprise, while also meeting all regulatory requirements and accreditation standards. The total cost of security includes both the cost of security controls, and the cost of security breaches.
The fundamental goal of information security is to protect against threats to the confidentiality, integrity, and availability of information. This goal can be expressed in term of meeting three basic types of security objectives:
Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.
Availability: Ensuring timely and reliable access to and use of information.
When dealing with information protection, it is important to recognize that there is no such thing as perfect security. And while too little security leads to unacceptable risks, trying to impose too much security (or the wrong kinds of security) on the users, operators or administrators of a system is a waste of money, and isn't likely to be effective anyway. The goal of risk assessment is to determine the right amounts and the right kinds of security, needed to achieve a reasonable, appropriate, and responsible degree of protection, at the lowest possible total cost.
Risk assessment has two other important goals:
●Regulatory compliance
●Maintaining public confidence in MUSC
State and federal regulators, and the public at large, expect MUSC's senior management to exercise due diligence in assuring the protection of all the sensitive and critical information that is entrusted to MUSC's stewardship. Senior management in turn expects us to deliver appropriate information protection, and to deliver it efficiently. We cannot meet these expectations if we fail to understand our risks, if we fail to develop plans to manage our risks efficiently and effectively, or if we fail to execute those plans. This is what risk assessment is all about, and why it is such a critical piece of MUSC's information security program.
At a very high level, two components contribute to the total cost of security for a system. The first component is the summed cost of all the system's security components themselves. For example, the costs of administering user accounts and passwords, and the costs of setting up and operating routine data backup and recovery procedures. The other major cost component arises from the expected cost (damages) created by security breaches. For example, the costs of lawsuits, fines and reputation damage that would be incurred if a system were compromised and sensitive and/or critical information about patients or other customers were destroyed, or exposed to the wrong people.
As a rule, we expect that the more we invest in security controls for a system (as long as we invest our money rationally), the less we expect that we will need to spend on damages from security breaches, and vice versa. This general principle is illustrated in the following graph:
Figure 2.1-1: Optimal Level of Security
An effective risk assessment process for a given system is one that enables the owner of the system to locate and pursue the optimal level of security. The assessment process should lead not only to the right amount of security for a system, but also to the right types of security for the system. The latter objective can be achieved only by first identifying the most significant risks that affect the system, and then by selecting and implementing the most cost-effective controls for managing those risks. The most significant risks are those that contribute the most to the expected cost of security breaches.
The assessment process requires us to identify the most significant risks to a system, to understand the various techniques that can be used to control these risks, to understand the organization's ability and capacity to implement these controls, and last but not least, to be aware of any minimum security control standards that must be met as a result of security policies or regulations that apply to the system. Given the depth and breadth of knowledge and skills required, it should not be surprising that an effective risk assessment often requires a multi-disciplinary team effort. The more risks that potentially affect a system, and the more people within the MUSC enterprise that the system touches, the more important it is for you, as the system owner, to assemble a knowledgeable and skilled risk assessment team.
2.2. Risk Components
An information security risk can arise from anything that threatens the availability, integrity or confidentiality of information. Risks are a function of the specific threats and vulnerabilities that potentially affect your system, the probability (likelihood) of their affecting your system, and the potential impacts on your system, on the MUSC enterprise, and on individuals if they do occur.
2.3 Identifying Threats and Vulnerabilities
A threat is defined as the potential for a "threat-source" to intentionally exploit or accidentally trigger a specific vulnerability. In a somewhat circular fashion, a vulnerability is defined as a weakness in a system's security procedures, design, implementation, or internal controls, that could be accidentally triggered or intentionally exploited, and result in a violation of the system's security policies. For a violation (breach) to occur, both a threat and a vulnerability have to exist.
A specific type of security breach will result from a specific threat acting upon a specific vulnerability. In other words, a particular threat-vulnerability pair will, in a sense, define a particular type of security breach. For all practical purposes, the terms "security breach" and "threat-vulnerability pair" are equivalent.
The first step in assessing the risks to your system is to start developing a list of all the threat-vulnerability pairs that could affect your system. We strongly recommend that you use a Risk Analysis Worksheet to record the list of threat-vulnerability pairs that your assessment team generates. See Appendix A for more information on how to use our recommended Risk Analysis Worksheet tool.
But before they can identify potential threats and vulnerabilities, the members of your assessment team will need to have a solid understanding of how your system is put together (or how you expect it to be put together, if it is still in the conceptual or development stage). Network diagrams, information flow diagrams, and tables of hardware and software components are essential tools for understanding a system. The boundaries of your system, and its interfaces with external systems, network infrastructure components, and end-user devices, must also be clearly understood by the members of your assessment team. If you haven't already done so, you will need to develop the appropriate diagrams and tables, and familiarize your assessment team members with the architecture of your system, before going any further.
Developing a list of potential threat-vulnerability pairs is best done as an exercise involving the entire assessment team. Try to keep the team members focused on threats and vulnerabilities that they can reasonably anticipate, that have a non-negligible probability of occurring, and that would have a non-negligible impact if they did occur. Your list doesn't need to be 100% complete before you can move on to the next step in your assessment; your team can add to the list later if they realize that they have overlooked a significant threat or vulnerability.
2.3.1 Identifying Threats and Vulnerabilities: Post-Implementation
If you are performing a Post-Implementation risk assessment, then obviously your assessment team should be thoroughly familiar not only with the system's current architecture, but also with its current state. The assessment team needs to be aware of the results of any evaluations of the security controls that have already been implemented with the system. If no recent evaluation has taken place, then an overall evaluation of the system's current security controls should be completed before attempting a Post-Implementation risk assessment.
If the system's existing security controls are known to be working effectively, then the risk assessment team can focus all of its attention on assessing the "new" risk issues that arise from the specific environmental, operational, regulatory, or policy change(s) that motivated the Post-Implementation risk assessment in the first place. In other words, if all of the "old" risk issues are still under control, then the Post-Implementation assessment team does not really need to worry about them.
On the other hand, if recent evaluation has shown that any of the existing controls have not proved to be effective, then the assessment team needs to broaden the scope of its review to include all of the "old" underlying risk issues (threat-vulnerability pairs and/or policy/regulatory issues) that originally motivated the implementation of these "old" controls, that subsequently turned out to be ineffective. In other words, any Post-Implementation risk assessment team does need to worry about any "old" risk issues that are not under control.
2.4 Quantitative vs. Qualitative Analysis
The type of risk posed by a particular type of potential security breach is defined by the threat and the vulnerability that together create the risk of the potential breach. The level of risk depends on two additional factors:
●the probability that the threat will act upon the vulnerability
●the potential impact of the breach that would result
For the purposes of risk assessment, we usually express the probability of an event in terms of its expected frequency of occurrence.
There are two basic approaches to risk assessment: quantitative and qualitative.
In a quantitative assessment, your objective is to express the level of risk in cold, hard, monetary terms. To do this, you must first document a numerical probability for the probability of occurrence of each type of potential security breach; you'll have to use whatever valid historical frequency data you can find that would be applicable to your system. To quantify potential impacts, you need to compute an actual monetary value for the total expected losses from each type of security breach; you'll have to do a detailed and thorough financial impact analysis to compute this quantity.
In theory, a quantitative risk assessment is ideal for risk-based decision-making, because it allows the risk assessment team to precisely compute the level of risk from each type of potential breach, and express the level of risk in cold, hard, monetary terms. This is usually done using the formula for Annualized Loss Expectancy (ALE), in which the expected annual loss from each type of potential breach is simply its frequency (expected number of breaches of that type per year) multiplied by its impact (total expected losses from each breach of that type, in dollars).
ALEx = Frequencyx x Impactx
For a given type of security breach x, the annualized loss expectancy due to x is simply the product of two factors: the expected frequency of x (the expected number of occurrences of x per year), and the potential impact of each occurrence of x (the total expected damages and losses from each occurrence, in dollars).
By computing an ALE for each type of potential breach, the risk assessment team can assign a dollar value to each type of risk. Then, by sorting the risks by their ALE's, the team can assign each risk the proper priority for management.
Alas, a significant problem with quantitative risk analysis is that most threat probabilities and impacts are extremely difficult to quantify. Security breaches occur relatively rarely, and organizations tend not to publicize them; as a result, most sources of incidence information are essentially anecdotal, and cannot be used to support the development of reliable probability or frequency estimates. Likewise, the total expected cost of the potential losses from a given type of breach are hard to estimate, and they may depend on factors such as length of downtime, amount of adverse publicity, and other such factors that are highly variable and inherently difficult to predict without a great deal of uncertainty.
Because of the uncertainty problem, we recommend a qualitative approach to risk assessment. In a qualitative assessment, you determine relative risk rather than absolute risk. At the cost of some (debatable) loss of precision, you simplify your analysis significantly. In a qualitative analysis, you don't attempt to quantify risk precisely. Instead, you try to produce good, but rough, estimates of risk levels. For most assessments, a simple scale with just three levels of risk (Low, Moderate, and High) is good enough to allow your risk assessment team to identify the most significant risks, and to assign mitigation priorities with a reasonable degree of confidence that all significant risks will be addressed.
2.5. Assessing Probability (Frequency)
Recall the two factors that contribute to the level of risk created by a given threat-vulnerability combination:
●the probability that the threat will act upon the vulnerability
●the potential impact of the breach that would result
In risk analysis, we usually express the probability of an event in terms of its expected frequency of occurrence. At MUSC, in keeping with our qualitative approach, we recommend using a simple three-point scale, as in the following example, for rating the estimated probability of a given type of breach:
Rating / Frequency of Occurrence (Expected)High / > 12 times per year
Moderate / 1 - 11 times per year
Low / < 1 time per year
Table 2.5-1: Probability (Frequency) Ratings
Remember, the whole point of a qualitative risk assessment is to assess relative risks, and to determine which risks are the most significant and therefore should be assigned the highest priority for management. If using the frequency ratings suggested above results in all, or nearly all, of your potential breaches' being assigned the same probability, then you should consider adjusting your frequency thresholds, in order to get some useful separation; otherwise, you'll ultimately find it harder to identify the threat-vulnerability pairs that pose the highest risks.
We strongly recommend that you use your Risk Analysis Worksheet to record the assessed Probability (Frequency) rating for each threat-vulnerability pair that your assessment team generated. See Appendix A for more information on how to use our recommended Risk Analysis Worksheet tool.
2.5.1. Assessing Probability (Frequency): Post-Implementation
If you are performing a Post-Implementation risk assessment, then your assessment team should generally rate the probabilities of threat-vulnerability occurrence's with respect to their understanding of the system's current state, as derived from the most recent available evaluation of the effectiveness of the system's existing security controls. For example, if the system already has an effective security control in place to reduce the probability of a potential issue from "High" to "Low" then that should be reflected in your rated Probability (Frequency) for that potential issue.