Which step of risk assessment in the nist sp 800-30 uses history of system attack as an input?

Framing Risk

In the risk management process, risk framing establishes the risk management strategy that provides a common organization-wide strategy for executing the other steps (assessment, response, and monitoring) of the process that are supported by the commitment of the organizations, senior management. As illustrated in Fig. 6.4, input to risk framing can include laws, policies, directives, regulations, contractual relationships, financial limitations, or information that explicitly (Memorandums of Understanding/Agreement (MOUs/MOAs), governance processes) supports key activities in the risk framing step.

Risk framing activities produce guidance that enables the development of a common perspective on how the organization manages risk. This perspective is established through the assumptions and constraints, level of risk tolerance, and priorities and trade-offs that drive the organizations’ decision-making process, and the type/size of the organization. Since risk framing may initially be high level or undefined, a feedback loop should exist to ensure that information from the other steps of the risk management process are used to adjust the original risk factors that contribute to the organization’s risk management policies, procedures, standards, and guidance.

The risk framing step also produces the risk framework and risk methodologies40 that will be used by the organization in tier 2 and tier 3 of the risk management hierarchy and in the execution of the other risk management steps. For example, if the organizational governance structure is centralized,41 only one framework and methodology may be required, whereas if the organization is decentralized,42 multiple frameworks and methodologies may be required. By having a common framework and methodology for organization-wide tailoring, it ensures that at least there is a consistent evaluation standard used by the entire organization for assessing risk and prioritizing risks as they are aggregated (or consolidated) from across the organization. This standard can then be applied in the risk assessment step when assessing risks and in the risk response step when courses of action are prioritized and implemented to achieve the most cost-effective strategy for risk mitigation.43

Risk Management and the RMF

Risk management and the risk management framework seem to be the same thing, but it is important to understand the distinction between the two. The risk management process is specifically detailed by NIST in three different volumes. NIST SP 800-30, Guide for Conducting Risk Assessments, provides an overview of how risk management fits into the system development life cycle (SDLC) and describes how to conduct risk assessments and how to mitigate risks. NIST SP 800-37 discusses the risk management framework that is the subject of this book; the guide is discussed in great detail in coming chapters. Finally, NIST SP 800-39, Managing Information Security Risk, defines the multi-tiered, organization-wide approach to risk management that is discussed in this chapter.

The older certification and accreditation (C&A) process had a number of shortcomings, including looking at risk only from the information systems perspective. This view focused on evaluating risks as they impacted a specific system, in a vacuum and does not address how the systems risks will impact larger business unit or the organization itself. In developing the RMF, members of the Joint Task Force Transformation Initiative, including members from NIST, determined that the best approach to risk management is to view risks at not only the system level, but also at the business unit level and the organizational level. This approach includes determining how the organizational risk picture may be impacted if a specific system is placed into the production environment. This evaluation takes place at three levels: the organizational level, or tier 1; the mission and business process level, or tier 2; and the system level, or tier 3, as illustrated in Figure 3-1. This holistic, multi-tiered, organizational view of risk assists senior leaders in determining how to effectively and efficiently manage risk in the most cost-effective manner across the entire organization.

Risk Assessment (RA)

Risk Management Methodologies

There are a number of popular methodologies and sources of guidance available to support an effective risk management program, including:

OCTAVE (www.cert.org/octave)

ISO 27005 standard for information security risk management http://www.27000.org/iso-27005.htm

National Institute of Standards and Technology (NIST) Computer Security Resource Center: http://csrc.nist.gov/publications/PubsSPs.html

Managing Information Security Risk: Organization, Mission, and Information System View (SP 800-39)

Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach (SP 800-37, Rev.1)

Guide for Conducting Risk Assessments (SP 800-30, Rev 1)

Microsoft’s Security Risk Management Guide http://www.microsoft.com/en-us/download/details.aspx?id=6232

Which methodology is chosen is less important than the decision to choose, implement, and enforce compliance to any methodology. Any effective risk management methodology will include three basic stages:

Risk Identification

Risk Assessment

Risk Control

Risk identification and assessment are discussed earlier in this chapter. Risk control is the determination of risk strategy based on a gap analysis of current protection methods to the level of risk resulting from the risk assessment. If there is a gap between the amount of protection currently provided for a particular information asset, the organization can choose to do one or a combination of the following:

Implement additional controls

Transfer the risk to a third party (such as insurance or a managed security organization)

Mitigate the effect of a successful attack with effective incident response procedures

Accept the current level of risk, as-is

Remove the asset from exposure, by retiring or discontinuing use of the asset

National Institute of Standards and Technology (NIST) Special Publication (SP) and Guidelines

•

NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook

NIST SP 800-14, Generally Accepted Principles and Practices for Security Information Technology Systems

NIST SP 800-16, Information Technology Security Training Requirements

NIST SP 800-18, Guide for Developing Security Plans for Information Technology Systems

NIST SP 800-26, Security Self-Assessment Guide for Information Technology Systems

NIST SP 800-27, Engineering Principles for Information Technology Security (A Baseline for Achieving Security)

NIST SP 800-30, Guide for Conducting Risk Assessments

NIST SP 800-34, Contingency Planning Guide for IT Systems

NIST SP 800-37, Guide for Security Certification and Accreditation of Federal Information Systems

NIST SP 800-39, Managing Information Security Risk

NIST SP 800-44, Guidelines on Security Public Web Servers

NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems

NIST SP 800-53 Revision 2, Recommended Security Controls for Federal Information Systems

NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations

NIST SP 800-60 Vol. 1 & 2, Guide for Mapping Types of Information and Information Systems to Security Categories

NIST SP 800-63, Electronic Authentication Guideline: Recommendation of the National Institute of Standards and Technology

NIST SP 70, The NIST Security Configuration Checklists Program

NIST SP 800-81, Secure Domain Name System (DNS) Deployment Guide

NIST SP 800-83, Guide to Malware Incident Prevention and Handling

NIST SP 800-86, Guide to Integrating Forensic Techniques Into Incident Response

NIST SP 800-92, Guide for Computer Security Log Management

NIST SP 800-95, Guide for Secure Web Services

NIST SP 800-97, Guide to IEEE 802.111: Establishing Robust Security Networks (this is related to wireless network deployment)

Qualitative threat assessment

Qualitative assessments use words or relative values to express risk, cost, and impact. The first step in using a qualitative system is to define the scale you want to use and then use it consistently. You can use systems like those shown in Table 4.5 or Table 4.6 (Hash, 2002, p. 21), or you can develop a customized scale to fit your needs.

Table 4.5. Qualitative Scale Example

Table 4.6. NIST Likelihood Matrix

One suggestion is that you use a scale with an even number of variables; the one we used has six. This forces a choice between two options, “frequently” or “infrequently” or “high” or “low,” and can prevent someone from selecting the middle value (present when there are an odd number of choices) to be safe. Whatever scale you use or whatever number of variables you opt to use, be sure to define these elements to everyone’s satisfaction. It’s important to have a shared understanding of what these values mean so that when you’re using them for the risk assessment, you’re all using them in the same manner.

When assessing likelihood, you can define a scale that works for your organization. Table 4.6 shown previously is the likelihood matrix developed by the National Institute of Standards and Technology. This matrix is specific to security risk vulnerabilities but provides a good example of how to define these types of qualitative assessments.

Now, let’s look at the same example we looked at previously only this time, let’s use the qualitative method. First, we map out the threat, as shown in Figure 4.6 earlier and repeated here in Figure 4.8 for your convenience.

Now let’s assign values. Let’s say we know that these outages happen once every 4 years. We might determine that outage deserves a rating of “infrequently,” and we can assign it the value of 3. Using the same system, we can say that the vulnerability when the storm hits is 100% (per our quantitative assessment), which would place it on the scale as “extremely high” and give it a rating of 6. So, the left side of our equation = 2, 6.

On the right side, we want to assess the impact cost, but we’re not using exact dollar amounts. We could say well the cost of being down 2 days would be about average because we can catch up later without too much trouble and our fixed costs aren’t through the roof. Therefore, you might assess your impact cost as being “low” or a level 3. If you take the average of these, you have 2 + 6 + 3 = 11/3 = 3.66. This puts it on the scale at “high” if we round up (any number above 3.5 would be 4, any number 3.5 and below would be 3). This is depicted in Figure 4.9.

You might decide you don’t like converting these assessments to numbers—that’s fine. You might also decide you want a scale with a few more options, say a 10-item scale—that’s fine, too. The point here is that you can make assessments without hard dollar figures and still come up with a meaningful assessment. In the case of the power outage, you might argue that the value of 6 for “very high” under vulnerability skews these data in a way you don’t like because it’s not weighted. However, when you do this assessment using this scale for a number of threat sources, you may find that your data shake out as expected. For instance, you might perform this same assessment on a power outage from an internal failure and decide its total risk value is 3.5. You can then look at these two sources and ask, “Do we really have a slightly greater risk value if we experience a two-day power outage every four years versus our internal power failure that could take us down for a week but only happens once every eight years?” If the answer is no, you may want to go back and better define your scale or reassess the values you used in one or the other assessment. However, in most cases what you’ll find is that after a few of these, you get the feel for the scale and you begin to see that your data track with the reality of the situation. Once you’re confident your scale is working, you can tackle the more difficult or more intangible threat sources.

Another rating scale could range from 1 to 100 to give you a bit more fine-tuned result. An example of this is shown in Figure 4.10. If you really want to keep it simple, you can use a five-element, single-rating system and come up with something similar to that shown in Figure 4.11.

In Figures 4.10 and 4.11, the costs are delineated in terms of the relative impact cost of (1) loss of revenue, (2) damage to servers, (3) damage to the database, and (4) damage to user computers. These two examples assume that the servers were able to shut down without incident but that there was damage to a database as a result of the sudden loss of power. This is just an example to show you how you might assess your IT components. You might also choose to delineate things like firewalls, routers, and cabling in your list, if it’s helpful in making a qualitative assessment.

Whether you choose to use a quantitative system or a qualitative system, be sure everything is clearly defined and that you apply these ratings consistently. What you’ll end up with at the end of your risk assessment phase is a chart, table, or document delineating each threat, the likelihood of that threat, the vulnerability to that threat, and the impact should that threat occur. From there, you’ll develop your risk mitigation strategies because you’ll be able to see the big picture and create optimal solutions for your firm.

Critical Concept

The Security Assessment Report in Context

The security assessment report contains the assessor’s findings for each of the assessment objectives considered during the security control assessment. Perhaps obviously, the security assessment report is dependent on the security control assessment, but the scope and content of the report is also driven by many other factors and RMF activities that precede the security control assessment. The relationship between the RMF activities and outputs influencing the scope of the security control assessment is shown in Figure 11.5.

As described in detail in Chapter 7, the security categorization of an information system performed during step 1 of the RMF process drives the selection of security controls for that system. Specifically, the impact level determined for the system determines the baseline set of security controls from Special Publication 800-53 that must be implemented for the system [43,44]. Starting from the appropriate security control baseline, the information system owner, working with technical experts such as information system architects and in consultation with security officers and engineers [24], tailors the set of security controls to reflect the protective needs of the system, taking into account the organization’s security policies, applicable regulations, and other influences that might lead to exceptions from or additions to the security control baseline. The set of tailored security controls are documented in the system security plan and provide a key input to the development of the security assessment plan. The security assessment plan identifies the controls and relevant enhancements that should be assessed, based on the selections documented in the system security plan and the purpose (and therefore the scope) of the assessment that will be conducted. The security assessment plan also specifies the appropriate procedures to be used to evaluate the controls and enhancements against the assessment objectives in Special Publication 800-53A. The security assessment report typically includes the assessment method or methods employed to assess each control, so to the extent these methods are determined in advance, they can be incorporated in the control assessment guidance, instructions, or templates given to each assessor.

Once the security control assessment is complete and the security assessment report is documented (or generated, in the case where an organization uses an automated assessment system), the system owner, system security officer, security control assessor, and other agency personnel analyze the report findings to determine what corrective actions are required for the system, if any, and to translate other-than-satisfied findings into items included in the plan of action and milestones. When evaluating an initial security assessment report, there may be no expectation that a POA&M item will be created for every other-than-satisfied finding, but when the security assessment report is finalized and delivered to authorizing officials, there should be an explicit response to every other-than-satisfied finding, either in the form of a POA&M item or a documented decision by the system owner to accept the risk corresponding to the weakness or deficiency.

What do these numbers mean? (How to interpret FAIR results)

We read a lot of security and risk standards. It comes with the territory. If you’ve done the same, you doubtless have read one of those well-intentioned write-ups about the difference between qualitative and quantitative risk analyses. When you get to the end of those write-ups, they usually have some discussion of the pros and cons of each approach. One of our favorite statements is offered by the NIST 800-30 standard Guide for Conducting Risk Assessments (both the older version and the newer one have similar issues). They say this about qualitative analysis: “This type of analysis supports communicating risk results to decision makers.” This statement implies that there are two types of risk analysis methods: qualitative for those that want to communicate with executives, and quantitative for those who want to play math games in their basement (we are being facetious of course). Clearly this creates a bit of a bias because in case you didn’t know, all risk professionals want to communicate with executives. Our experience has been that although qualitative scales can be very useful and are often what the executives are used to seeing, quantitative results tend to be far more informative. That said, it is true that executives are busy people who often need or want to operate off at-a-glance indicators of their world. That way, things that are amiss jump off the page at them, allowing deeper investigation and perhaps corrective actions. Qualitative values – the reds, yellows, and greens of the world – are great at providing that view. Consequently, your risk reports may need to provide that qualitative perspective. Here’s the catch though. Providing a qualitative interpretation of an analysis is not the same thing as doing a qualitative analysis. We can very effectively represent the results of a quantitative analysis in qualitative terms. The reverse isn’t true.

Let’s assume that you want your work to be taken seriously by executives so you follow the sage advice from 800-30 and do a qualitative analysis. You present the results (High, Medium, or Low) to the executives and one of two things happen. Either they ask how you came up with the ratings or they simply accept the information at face value. If there’s not a lot at stake (or if your credibility is already in the toilet) it’s very likely they won’t dig into how the analysis results were arrived at. If, however, you’re asking for a lot money to remediate an issue, or if what’s being proposed is likely to impact business significantly in some manner then it’s much more likely they’ll want an explanation. So if they ask how you came up with the ratings for your analysis, what would your answer be? How much rigor went into your analysis? If it’s like most qualitative analyses you’re left with talking at a high level about some of your reasoning, your experience and training, perhaps what you used to do at another company, or what best practice is. What they hear is that they need to trust you and they need to do what the other companies are doing. If they’re the trusting sort, that may be the end of the conversation. If not, it can be an uncomfortable conversation.

Okay, so now let’s try it another way: with a quantitative analysis. You do your analysis and then present just the numbers. What’s their reaction? Well, first of all you are far more likely to get questions about how you came up with the results, especially the first time or two you put numbers in front of them. This should be viewed as a good thing. It generates dialog and provides the opportunity to convey far more information about the scenario. It also provides an opportunity to demonstrate the rigor underlying your approach, which should increase the credibility of the results. You explain that the estimates were based on this or that data and these assumptions. You can also describe the level of confidence (or lack thereof) in your inputs and why, and answer questions related to the number of Monte Carlo simulations that were performed. All this is great but there can be a downside, depending on the circumstance and the individual inclinations of the executives.

Some executives love numbers and some just want it easy. They have a million things on their plate and they don’t always want to gain a deeper understanding of this scenario at this moment. Sometimes all they want to know is whether this is a situation they need to do something about or worry about. Presumably, you wouldn’t be bringing this analysis before them if the results weren’t important, but setting that aside for the moment, it is important to present analysis results in a form that meets the needs of the decision makers. This introduces a third option – presenting both qualitative and quantitative results. We’ll talk about ways in which to do this shortly. The advantage is that executives can have a simple visual cue regarding how much to care about an issue, and you have the numbers and underlying rigor to explain the analysis if they want an explanation. Everybody wins.

Our experience has been that executives ultimately want to feel they can trust the analysis results. That trust can come from their innate faith in you, the rigor that went into an analysis, or both. We’ve found the combination of the two to be a much stronger formula for trust than just having faith in the person sitting across from them. In fact, very often we appear to gain credibility through the rigor in our analyses. We have yet to encounter an executive who hasn’t appreciated our ability to explain our results, be they presented numerically, in colors, or both. Unfortunately, NIST 800-30 and similar references don’t appear to recognize the distinction between how results are presented versus how they’re arrived at, therefore the people who read those references are misinformed.

Finding the right analysis tools

There are several risk analysis tools available that will help you through the process. And since CMS does not prescribe a specific tool or outline specific instructions on how to conduct the analysis, you have to choose one that best suits your needs, depending on the size of your organization, the sophistication of your record keeping system, and the expertise of your staff.

Several toolkits, guidelines, and risk analysis vendors are worth considering. If you conclude that the risk analysis process is beyond the expertise of your staff, you can hire firms such as Coalfire, Principle Logic, or several other reputable vendors. For detailed guidelines on performing a risk analysis, the first source to review is the National Institute of Standards and Technology (NIST), part of the US Department of Commerce. NIST publishes Guide for Conducting Risk Assessments [8].

Herzig, Walsh, and Gallagher also describe a detailed risk analysis process in their guide to healthcare security [9]. Their approach includes (1) creating an inventory of applications and systems, (2) identifying threats, (3) determining what safeguards are currently in place to deal with those threats, (4) identifying vulnerabilities, and (5) estimating the likelihood that each threat will materialize. The remaining steps include an impact analysis, a risk determination that includes a numerical score, advice on how to mitigate the risks you spot, and a final documentation phase.

Their risk score plots the potential impact of a risk against the likelihood of it occurring to generate a number from 1 to 9—referred to as the OCTAVE approach—which can then be used to help you determine how much time and resources you want to devote to fixing the problem.

As I have mentioned previously, HHS and the Office of Civil Rights place a great deal of emphasis on documenting the results of your risk analysis. Herzig et al’s recommendations on the final documentation are worth a closer look. They suggest creating three types of documents: Risk profiles, a risk analysis report, and a risk remediation report. One especially valuable feature of their risk analysis report is its mitigate/transfer/accept option. This lets the organization make a list of potential safeguards or “controls,” designate the amount of resources needed to put them in place, and decide whether to install the control (ie, mitigate the risk), pass on the responsibility to someone else (eg, transfer the risk to a cybersecurity insurance firm for example), or just accept the risk without doing anything.

The purpose of these documents, as well as those generated by several other risk analysis tools, is to prove to government auditors that you have taken your responsibility to protect patient information seriously and have made a reasonable effort to adhere to the HIPAA privacy and security rules. The authorities do not expect you to create an impenetrable fortress, but neither do they want a simple checklist completed.

HIMSS also provides resources to help providers perform a risk analysis [10]. Its risk assessment toolkit includes white papers, best practices, and a variety of other resources to help providers manage the process. I have featured one of its tools below, which uses the example of a small medical practice to keep things simple. Also keep in mind that the description given subsequently only covers a portion of the assessment process. Since the primary audience for this book is executives and other decision makers and not security specialists or compliance officers, my purpose is not to provide a detailed how-to guide but a general overview that will allow you to provide direction to those who are responsible for actually doing the analysis.

HIMSS provides the tool/sample analysis as an Excel file and assumes the practice has five employees, including a physician, biller, nurse—who doubles as practice manager—and two administrative assistants. It also assumes you have an in-house server with an EHR system and practice management software, as well as a cloud-based email system and a laptop to run EKGs.

The sample analysis contains cells that allow the practice to plug in its threats and vulnerabilities, and the nature of the risk each vulnerability presents. It also asks you to estimate the risk level for each vulnerability as low, medium, or high, and requires you to list the likely impact of each threat and what existing safeguards are in place to prevent a mishap. So, for example, one of the vulnerabilities listed is a missing policy and procedures manual that outlines the practice’s security plan. Without a manual, the practice has no clear cut direction from the physician owner defining best practices. That is a serious deficiency in the mind of any competent auditor.

One of the threats described in this Excel file is from an employee who wants to steal sensitive data or simply does not know enough about basic security to take reasonable precautions. Without specific policies that tell staffers not to write system passwords on Post-its that are pasted next to their workstations, for instance, the physician owner will be held responsible when a CMS auditor shows up and spots this obvious mistake.

Similarly, without a written policy that instructs staffers not to click on hyperlinks in suspicious emails, it is that much easier for an outsider to trick them into logging into a malicious web site that can track their keystrokes or plant some other type of malware on your server.

Another vulnerability in the HIMSS sample risk analysis is described as: “Unauthorized access of data transmitted over the Internet (eg, remote access use by employees/contractors or transmitting data to business associates)”. In this sample analysis, the likelihood of a data breach resulting from this specific vulnerability is listed as low because the practice was smart enough to only allow remote access to its server through an encrypted virtual private network or VPN. It also explains that transmissions from their business associate use a secure socket layer or SSL encrypted web browser.

Speaking of business associates, in 2013, HHS updated the privacy and security protections originally incorporated in HIPAA, which was introduced in 1996. Back then, the primary focus had been on medical practices, hospitals, health plans, and a variety of health professionals. The more recent Omnibus Rule, which is based on statutory changes under the HITECH Act, put a great deal more emphasis on the responsibilities of vendors, contractors, and subcontractors working with these organizations and clinicians. These business associates (BAs) are now required to do a risk analysis as well, and healthcare organizations have to take into account their relationships with their BAs when they do their own risk analysis, as you will learn subsequently.