nist sps and risk assessment process - usalearning · nist sps and risk assessment process. ......

NIST SPs and Risk Assessment Process

Table of Contents

Risk Management Frameworks ...................................................................................................... 2

Overview ......................................................................................................................................... 3

National Institute of Standards and Technology Special Publications ........................................... 4

NIST SP 800-30 ................................................................................................................................ 5

NIST SP 800-30: Risk Management ................................................................................................. 6

Risk Assessment .............................................................................................................................. 7

Step 1: System Characterization ..................................................................................................... 9

Step 2: Threat Identification ......................................................................................................... 11

Step 3: Vulnerability Identification ............................................................................................... 12

Step 4: Control Analysis ................................................................................................................ 14

Step 5: Likelihood Determination ................................................................................................. 15

Likelihood Rating ........................................................................................................................... 16

Step 6: Impact Analysis ................................................................................................................. 18

Impact Rating ................................................................................................................................ 19

Step 7: Risk Determination ........................................................................................................... 21

Step 8: Control Recommendations ............................................................................................... 22

Step 9: Results Documentation .................................................................................................... 25

Notices .......................................................................................................................................... 26

of 26

Risk Management Frameworks

© 2012 Carnegie Mellon University

Risk Management Frameworks

**001 Chris Evans: Let's talk about risk management frameworks.

of 26

Overview

2

Overview

National Institute of Standards and Technology (NIST) Special Publications

OCTAVE® and OCTAVE® Allegro

CERT®-RMM

**002 As you're going through and doing your risk management process, there are a lot of different ways that you can go about doing risk management. There are a couple different processes or frameworks that are out there that you can follow, or you can even come up with your own risk management process. It really is up to you. The reason that we'll talk about these is these are the significant ones that are out there. We'll talk about how those are actually employed, where to go for guidance on doing these particular processes. And you might find that, depending on who you are or what organization you work with, that one

of 26

of these processes or one of these frameworks for risk management will work better than another one for you. Or you might find that all of these are very complicated, too overbearing for what you need to do. Really it's up to you. So we present these just as kind of a baseline for what's possible out there.

National Institute of Standards and Technology Special Publications

3

National Institute of Standards and

Technology Special Publications

**003 We'll start with the National Institute of Standards, the Special Publications series that talk about risk management framework.

of 26

NIST SP 800-30

4

NIST SP 800-30

Risk Management Guide for Information Technology Systems• Provides a foundation for the development of an effective risk

management program• Contains the definitions and the practical guidance for assessing

and mitigating risks• Provides information on the selection of cost-effective security

controls

**004 So the first one that you should probably be aware of is Special Publication 800-30, and this is really a foundational document for how to do risk management. It'll talk about definitions, it'll give you some guidance for how to actually build a risk management process, and it talks a little bit about how to select controls, or mitigation strategies for the things that you need to put in place. I would say that 800-30 is just a starting point for you. It kind of lays out a general process for you to follow.

of 26

NIST SP 800-30: Risk Management

5

NIST SP 800-30: Risk Management

Risk management encompasses three processes

Risk Assessment

Risk Mitigation

Evaluation and

Assessment

**005 Within this document, there are the three processes. There's risk assessment, risk mitigation, and evaluation and assessment. And so 800-30 will lay out a process, the overall risk management process, with each of these particular functions defined.

of 26

Risk Assessment

6

Risk Assessment

Step 1: System Characterization

Step 2: Threat Identification

Step 3: Vulnerability Identification

Step 4: Control Analysis

Step 5: Likelihood Determination

Step 6: Impact Analysis

Step 7: Risk Determination

Step 8: Control Recommendations

Step 9: Results Documentation

Risk Assessment

Risk Mitigation

Evaluation and

Assessment

Ref: NIST SP 800-30, Risk Management Guide for Information Technology Systems

**006 As far as the risk assessment piece goes, 800-30 will tell you about these nine steps. And so it kind of guides you through how to do a risk assessment piece. And so it starts with system characterization-- what kind of system do you have-- what are the systems or pieces that are part of this, so kind of scoping the risk assessment process. It talks a little bit about threat identification and vulnerability identification, so what are the bad things that are out there and how are your systems vulnerable to them. It'll talk about control analysis, so what things do you have in place to mitigate currently. It'll talk about likelihood

of 26

determination. So if you have a threat and a vulnerability, 800-30 will help you determine how likely is it that something bad will happen, or how likely is that to occur. It'll lead you through how to do an impact analysis-- so determining if something bad happens, what's the next-level effect on my business; what actually happens there. It talks about risk determination. So, again, I've got this picture of threats, vulnerabilities, controls, likelihood. What is my true risk? So 800-30 will help you with that. And then control recommendations: "I've got this risk. What do I do about it? What are some of the things that I can put in place?" And then results-- again, how do I write up and track my risk assessment, and the end-product of this particular process.

of 26


7


Input• Hardware• Software• System Interfaces• Data and Information• People• System Mission

Output• System Boundary• System Functions• System and Data Criticality• System and Data Sensitivity

tems

**007 Step one: The system characterization. So, what are you looking at here in this particular process, or this particular step of the risk assessment function? Well, really what you're looking at is my critical assets. Actually, not even critical. Let's just say assets. We're looking at systems, software, hardware, people even, and what the system is for-- what is it that we actually are doing here. And your output from this is going to be some notion of what my systems are-- so I'm scoping my assessment by saying, "These are the assets that

of 26

I'm going to focus on"-- and you're also going to have some notion of criticality and sensitivity. Why is criticality and sensitivity important? Again, it goes back to you've got limited resources, you can't fix everything, so prioritize. You prioritize based on what's critical and what's most sensitive to your organization. So out of step one here in the risk assessment process, that's essentially what you're looking at. "Here are the things that I need to do my job, and here they are ordered based on some precedence or prioritization based on what's important to me as a business."

of 26


8


Input• History of system attack• Data from intelligence agencies, mass media, or gov CERT

Output• Threat Statement


**008 Step two: Threat identification. You're looking for problems, what could go wrong with this particular system or these assets that you identified in the previous step. So, you could be looking at historical attacks, like case studies. You could be pulling threat intelligence reports to see that, "Okay, hacktivists have been targeting banks in the recent month. Maybe that's something I need to be concerned about because I'm also a bank." But maybe you pull intelligence reports, maybe you get information from a CERT function or a CSIRT or something like that, or maybe you just read the news and

of 26

see that waves of attacks are coming against banking and financial institutions because somebody's upset, and there's a hacktivist involved, and all sorts of other funny business is going on. So, what's your output from this step? What you're essentially looking at is a threat statement. What could go wrong, or where could I see attacks from on these particular assets from step one?


9


Input• Reports from prior risk assessments• Prior audits• Security requirements• Security test results

Output• List of potential vulnerabilities


**009 So the next step is you're going to look at vulnerabilities. Your inputs here might be prior risk

of 26

assessments where you have a list of all the vulnerabilities. You can go through that and see, "Is this still applicable?" You might do something like a vulnerability test or a vulnerability assessment or a penetration test or something like that. That will tell you where your vulnerabilities are. You might have information from security requirements. So if you track, "Why do we have a firewall in place?" Well, the vulnerability was, "We need to separate systems from the internet." So you've got a-- you can look at the controls you have in place, the current controls you have in place, your current security requirements, and understand vulnerabilities from that as well. And your output in this process, or at this step in the process, is a list of vulnerabilities. So by the end of this step, I have assets, I have treats, and I have vulnerabilities all identified.

of 26


10


Input• Current controls• Planned controls

Output• List of current and planned controls


**010 Step four is control analysis. You're looking at, "What do I currently have in place right now?" If I have a firewall, what is it doing for me? Is it helping me mitigate something? Is it fixing a vulnerability? So I have a list of current controls. Maybe I have a list of controls that are coming. "We've got a six-month plan to implement a wireless intrusion detection system." Okay, document that here in this step. And what you're trying to do is consolidate the controls that you currently have in place or coming soon.

of 26


11


Input• Threat-source motivation• Threat capacity• Nature of vulnerability• Current controls

Output• Likelihood rating


**011 Likelihood determination. Here you're looking at threat sources, their capabilities or their capacity to do attacks. You're looking at the vulnerabilities that you identified in the previous steps. You're looking at the controls you have in place right now. And what you're trying to say is, "What's the likelihood of something bad happening here? Is it highly likely, because we have a very motivated threat source and we don't have a control in place? Or is it low likelihood because nobody's really attacking it-- this particular exploit or this particular vulnerability-- and we have a mitigation strategy. We have a control in place to block it. And so

of 26

your output is going to be, for each threat, what's the likelihood of this actually occurring.

Likelihood Rating

12

Likelihood Rating

HighThe threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective.

MediumThe threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability.

LowThe threat-source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised.


**012 You can generally classify likelihood however you want. You can use a scale of zero to five. You can use a qualitative scale like this, that's high, medium or low. Generally it's up to you. This is an example from 800-30 that says a high likelihood might match this particular statement. So here, if I have a threat source that's highly motivated and capable, and I don't have a control in place, that's high likelihood. What is that saying? So

of 26

you're kind of comparing threats with controls. If my threat is really capable and I have no controls, I have high likelihood. Switch that. I have threat that's not really capable and probably doesn't have the ability to do this, but I have controls in place, what's my likelihood now? Low. Right? And then somewhere in the middle there is medium. So, high, I've got a really motivated threat actor. I don't have any controls in place. It's highly likely that if they do this, something bad is going to happen. Medium says the threat source is capable but I have some controls in place that might do this or might protect me, or might mitigate some of that risk. That's a medium level of likelihood. And then low is the threat actor doesn't really know what he's doing, but I've got a firewall in place. I have an intrusion detection system in place. Now my likelihood is low.

of 26


13


Input• Mission impact analysis• Asset criticality assessment• Data criticality• Data sensitivity

Output• Impact rating


**013 Impact analysis, you're looking at impact to the business, impact to your mission, as it were. Your inputs to this are going to be what do you actually do, from a business perspective; what are my critical assets; what are my critical data. You're actually going to look at what the threats and the likelihoods are as well. So you're looking at everything that you've done up to-- in the previous five steps here, and you're going to try to say that, "What actually is going to go wrong here?" Is it bad? Is it not so bad? Or is it no effect? You're trying to come up with an impact.

of 26

Impact Rating

14

Impact RatingHigh

• May result in the highly costly loss of major tangible assets or resources• May significantly violate, harm, or impede an organization’s mission,

reputation, or interest• May result in human death or serious injury

Medium• May result in the costly loss of tangible assets or resources• May violate, harm, or impede an organization’s mission, reputation, or

interest• May result in human injury

Low• May result in the loss of some tangible assets or resources • May noticeably affect an organization’s mission, reputation, or interest.

**014 And so your impact ratings-- again, it could be a quantitative impact zero, or impact five-- that's really bad. Or you could say it's-- qualitatively here-- high, medium or low. And so if you look at a high impact rating, what does a high impact rating mean to you, or mean to your business? It means that your business is going to suffer a significant impact. And so you may say that high impact, it's highly costly loss of major assets, meaning building was destroyed, or I have a 600 thousand dollars server farm that was compromised or something like that. So it may significantly violate, harm or impede your ability to do

of 26

your job, or there's loss of life or significant injury. All of that may be rated as a high impact. Medium impact. You get into kind of a gray area here. Might be some type of physical injury, might have some loss associated with it, though not extreme loss associated with it. That's medium. The low statement here, for low impact, is, "We might lose a little something or other, but nobody's going to get killed; building's not going to fall down around us; and it may-- there may be some noticeable but not significant impact on our business." That would be a low characterization for impact.

of 26


15


Input• Likelihood of threat exploitation• Magnitude of impact• Adequacy of planned or current controls

Output• Risks and risk levels• The final determination of risk is derived by multiplying the ratings

assigned for threat likelihood (e.g., probability) and threat impact.


**015 Once you're done with that, you're actually going to go through and do risk determination. You're going to look at things like likelihood, the impact statements that you did in the previous step and, again, looking at the controls that you have in place, and you're going to determine, "What are my real risks here? What are my risk levels? Do I have high risk, medium risk, low risk? Do I have no risk, because of likelihood and impact and controls in place?" So what you're trying to do is come up with an assessment or evaluation of how big is this risk for this particular threat or asset or something like that.

of 26


16


To minimize/eliminate identified risks, consider the following factors when recommending controls/alternative solutions

• Effectiveness of options• Legal/regulatory• Organizational policy• Impact to operations• Safety/reliability

**016 Control recommendations. So here you're looking at the risk that you came up with in step seven, and you're saying, "Okay, what am I going to do about it? How do I minimize the risk? How do I eliminate the risk? How do I reduce the impact from this particular risk?" And so with this, you also want to consider that the controls you have in place, how effective are they? If they're pretty effective, maybe I don't need as significant as a control as I would if they weren't effective. The controls that I'm thinking about putting in place, how effective are they going to be? If I spent 10 million dollars on this and I only get

of 26

this much capability out of it, a small level of capability, do I really want to spend that money on it? Legal and regulatory concerns. Before you actually put a firewall in, does that break your own organizational policy? Is there some legal reason or regulatory reason why you can't do that? Or, the flip side of that is, are there regulations that say I have to have it? In which case, okay, my decision's made for me. I don't get to select my own controls because the regulatory body is telling me which one I have to use. Organizational policy. Again, you want to make sure that what you put in from a control standpoint fits your organization and doesn't kind of go against the grain, because if it does, nobody's going to use it. They'll find ways to get around it. Impact to operations. What this is getting at is if you put a control in place that precludes you from doing business or keeps people from doing business, that's not an effective control. There's always this tradeoff between security and convenience. Right? If you're very secure, you probably can't do business. And so you want to make sure that the controls you put in place don't have a negative impact on your ability to do your job. And then safety and reliability. You want to make sure that you don't introduce any other risks or concerns or problems with the controls that

of 26

you put in place. For an example here, look at a Halon fire system, or fire suppression system. Right? When you put these into the buildings, they're really good at putting out fires, and they're also really good at killing people. Right? Because they take all the oxygen out of the environment. So if you're going to put something like that in your facility-- data centers you see this quite a bit-- you want to consider the safety implications of that and maybe put in oxygen masks or make sure that there's an all-clear before the Halon system goes out.

of 26


17


Risk Assessment Report includes• Threat-sources• Vulnerabilities identified• Risks assessed• Recommended controls provided

**017 And then the last step here: Results documentation. You're looking at everything that you've done in the previous steps. You're looking at the assets that you identified, the threats, the vulnerabilities, the impacts, the controls. You're documenting all of that into some type of an assessment report or risk document.

of 26

Notices

2

Notices© 2014 Carnegie Mellon University

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study.

Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

of 26

nist sps and risk assessment process - usalearning · nist sps and risk assessment process. ......

Documents