nist sp 800-39 and 800-37 - usalearning...nist sp 800-39: tiers of risk management 23 risk...

NIST SP 800-39 and 800-37

Table of Contents

NIST SP 800-39 ................................................................................................................................ 2

NIST SP 800-39: Tiers of Risk Management .................................................................................... 3

NIST SP 800-39 : Process Applied ................................................................................................... 4

NIST SP 800-39 : Risk Framing ......................................................................................................... 5

NIST SP 800-39 : Risk Monitoring.................................................................................................... 7

NIST SP 800-39 : Risk Response ...................................................................................................... 9

NIST SP 800-37 .............................................................................................................................. 10

Risk Management Framework ...................................................................................................... 13

Notices .......................................................................................................................................... 16

of 16

NIST SP 800-39

22

NIST SP 800-39

Managing Risk from Information Systems• Provides guidelines for managing risk to organizational operations

and assets• Provides a structured yet flexible approach for managing risk• A flagship document in the series of FISMA-related publications

**022 So all of that came out of 800-30. It's quite a bit. There's 800- 39, which actually will go through another part of risk management. Some guidelines here. It really is a structured approach. They call it flexible, so you can apply it in different areas or different aspects of your business. If you are subject to FISMA compliance, you want to get friendly with 800-39. Thirty-nine will help you kind of figure out what you need to be FISMA-compliant, how you report it, what you do with it, and that sort of thing, along with a couple documents out there. But 39 will lay that out for you.

of 16

NIST SP 800-39: Tiers of Risk Management

23

Risk management can be viewed as a holistic activity that is fully integrated into every aspect of the organization.

• The organization level• The mission and business process level• The information system level

Strategic Risk

Tactical Risk

• Multi-tier Organization-Wide Risk Management• Implemented by the Risk Executive Function• Tightly coupled to Enterprise Architecture and

Information Security Architecture• System Development Lifecycle Focus• Disciplined and Structured Process• Flexible and Agile Implementation

Ref: NIST SP 800-39, Managing Information Security Risk

Tier 1 – Organization (Governance)

Tier 2 – Mission (Business Process)

Tier 3 – Information System (Environment

of Operations)

NIST SP 800-39: Tiers of Risk Management

**023 You probably recall that there are three tiers of risk management. Where did this come from? Well, it came from 800-39. And again, you've got strategic risk, business risk, and system, or particular application risk. And just keep in mind that with each of these risk management functions, it might be different people looking at these particular functions.

of 16

NIST SP 800-39 : Process Applied

24

NIST SP 800-39: Process Applied


**024 Thirty-nine shows a generic process, and this is a nice little bubble diagram for you. So if you look in the center here, you see each of these triangles is a different tier. So you've got organizational or strategic risk at tier one, you've got mission or business process at tier two, and then actual systems at tier three. What do all of these arrows in these bubbles mean? It means that they all communicate with each other. So by assessing risk, you're able to respond by putting in additional controls. If you can monitor risk and understand what's going on, maybe you can have a better, or more informed, risk

of 16

assessment. If you're monitoring your controls or your risk, maybe you're better able to respond because you can detect when things go wrong.

NIST SP 800-39 : Risk Framing

25

NIST SP 800-39: Risk Framing

Establishes the context and provides a common perspective on how organizations manage risk

Risk framing produces a risk management strategy that addresses how organizations intend to

• Assess risk• Respond to risk, and • Monitor risk.

The risk management strategy makes explicit the specific assumptions, constraints, risk tolerances, and priorities/trade-offs used within organizations for making investment and operational decisions.


**025 So, risk framing, that bubble in the center of the diagram on the previous slide-- this is framing risk. How does it impact your organization? How do you deal with it? What do you do? So the idea is you're looking at a context for the risk management process and establishing some type of common perspective on how to manage that. Again, across the organization,

of 16

looking at the different tiers-- strategic, the operational piece with the business functions, and the individual systems. So what should come out of this framing discussion is: What do we do to assess risk, respond to risk, and monitor risk? Now, if you remember from the bubble chart on the previous slide, that's each of those bubbles that are on the corners. Right? So you're looking at: How do I assess the risk? How do I respond to it? And what do I do about it? And this, the strategy that you come up with, should address all of these things that are here. So, assumptions, constraints, risk tolerance, and priorities when you're going through and doing your risk management.

of 16

NIST SP 800-39 : Risk Monitoring

26

NIST SP 800-39: Risk Monitoring

Provides organizations with the means to• Verify compliance• Determine the ongoing effectiveness of risk response measures • Identify risk-impacting changes to organizational information

systems and environments of operation

Analyzing monitoring results provides organizations the capability to

• Maintain awareness of the risk being incurred• Highlight the need to revisit other steps in the risk management

process• Initiate process improvement activities as needed


**026 Risk monitoring. So this was one of the side bubbles there. Why you do this is because it gives you the ability to say, "I'm compliant with whatever regulations I might be subject to." I can determine the effectiveness of the risk response or the controls that we've got in place, and I can look at risk-impacting changes. So, as things change within our business, the ecosystem that we live in changes-- I get new systems, I get new people-- what are the new risks associated with that? All of that happens here in this section, the risk monitoring section. And what you're trying to do is maintain awareness of the risk you've got. You want to be

of 16

able to go back through other steps in the risk management process and say, "You know what? We need to relook at our controls. We need to redo our vulnerability assessment, because that seems to be out of date." And initiate process improvement activities-- the idea that you're going to do some type of gap analysis here and see: "We have problems. How do we improve that? How do we fix that?" All of that happens here in the risk monitoring.

of 16

NIST SP 800-39 : Risk Response

27

NIST SP 800-39: Risk Response

When organizations experience a breach/compromise to their information systems or environments of operation that require an immediate response to address the incident and reduce additional risk that results from the event

The risk response step can receive inputs from the risk framing step.

• When is the organization required to deploy new safeguards and countermeasures in their information systems based on security requirements in new legislation or OMB policies

• Shapes the resource constraints associated with selecting an appropriate course of action

The risk response step can receive inputs from the risk monitoring step.


**027 With risk response, this is what you do when you actually have an issue, like a security breach. You go into incident response, or whatever your processes might be there. For risk response, generally you're going to be taking inputs from the other aspects, from the assessment, from the monitoring, and even from the framing step within that particular section. And because of that response-- you get inputs from the framing section or the framing process, risk framing process-- you're able to better select the course of

of 16

action that you want to do, pick out, "Here are the steps that we need to take in terms of risk response."

NIST SP 800-37

28

NIST SP 800-37

Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach

Guidelines developed to ensure that • Managing information system security risks is consistent with the

organization’s objectives and overall risk strategy• Information security requirements are integrated into the

organization’s enterprise architecture and SDLC

**028 800-37, another publication. This presents the security lifecycle, or how do we address security within our organization. It does give you some guidance on making sure that your risks are consistent with your risk appetite or your organizational desire for managing risk. So it's kind of balancing risk and what our business actually wants. And it makes sure that your requirements-- so, as your-- or your requirements are integrated into some type of

of 16

lifecycle. Meaning, when you go out and you purchase a new system, or you bring in a new application, when should you start thinking about the security of that application or system? Before you buy it, after you've bought it, or after you've implemented it? Students: Before you buy it. Chris Evans: Before you buy it. Now, when do people usually get to thinking about security? Student: Once they have it in- house. Chris Evans: Once they have it in- house, once the lights are blinking and everybody goes, "Ooh, that's great., We like it." Okay, what about the security of it? So there was an example of an organization who brought in a nice little Polycom system, one of those teleconference systems, and in the documentation for it, the Polycom says, "You have to put this outside your firewall. And oh, by the way-- warning, warning-- it opens you up to attacks," and yada, yada. I mean, it's all documented in there. So, good disclosure from the manufacturer on this device. Right? So somebody said, "Okay"-- somebody within the business unit said, "I want the Polycom. I want it here, because I need to do business, and oh, by the way, I needed it yesterday. So go buy it, put it in,

of 16

and we'll be all right." Three hundred thousand dollars later, the Polycom comes in, is sitting on the table, and the people go, "Oh yeah, we need to talk to security about this." So it's already up and running, it's already connected in, and the security guys come over and go, "Oh. Well, this is going to introduce all sorts of problems." Now you have security versus convenience. Right? "Well, I have to have the Polycom to do business, but the security guys are telling me this is a terrible thing to have because it opens up our network to attack." Well, now what do we do? What do you think is going to happen? The organization already spent 300 grand on the Polycom device. Student: Risk assessment. Chris Evans: That's what hopefully happens, but usually what happens is the Polycom stays there and the security guys are left to figure out how to deal with it and how to mitigate that.

of 16

Risk Management Framework

29

Risk Management Framework

Security Life CycleSP 800-39

Determine security control effectiveness (i.e., controls implemented correctly,

operating as intended, meeting security requirements for information system).

SP 800-53A

ASSESSSecurity Controls

Define criticality/sensitivity of information system according to potential worst-case, adverse impact to mission/business.

FIPS 199 / SP 800-60

CATEGORIZE Information System

Starting Point

Continuously track changes to the information system that may affect

security controls and reassess control effectiveness.

SP 800-37 / SP 800-53A

MONITORSecurity State

SP 800-37

AUTHORIZE Information System

Determine risk to organizational operations and assets, individuals,

other organizations, and the Nation; if acceptable, authorize operation.

Implement security controls within enterprise architecture using sound

systems engineering practices; apply security configuration settings.

IMPLEMENT Security Controls

SP 800-70

FIPS 200 / SP 800-53

SELECT Security Controls

Select baseline security controls; apply tailoring guidance and

supplement controls as needed based on risk assessment.

Ref: NIST SP 800-37, Guide for Applying the Risk, Management Framework to Federal Information Systems

**029 So, you look at the security lifecycle that's presented here. Kind of in the-- this is the lifecycle that comes out of 800-37. Right in the middle of this thing you have the overall guidance. That comes out of 800-39. You're going to start your process up at the top of this chart. So, up at the top there, we have categorizing information systems. So, we've talked a lot about risk management. What's the first thing you do? Identify your critical assets. Right? Systems, people, that sort of thing. So you're categorizing your information systems. You can get guidance on that out of FIPS 199 or

of 16

800-30. Both of those-- or, sorry, 800-60. Both of those documents will help you categorize your information system. Once you do that, you're coming over here, and you're going to look at the security controls that you want to put in place to address the risks. You can look at FIPS 200 or Special Pub 800-53. 800-53 is a thick document and it lists hundreds of controls that you can put in place, separated by different functional areas. So, when you're selecting security controls, take a look at 800-53. There's a bunch of information in there for you. When you're implementing security controls, take a look at 800-70. This has checklist guidance in it, and will help you determine how to implement security controls within your organization. Once you've got it implemented, you're going to start looking at assessing it. How do the controls work? Do they work as intended? Are they really what we need? So, take a look at 800-53A. There's a reason it's 53A, because I said a few minutes ago that 800-53 lists all the controls that you could implement. Well, a significant majority of them, right? 53A is the companion document to that, and 53A tells you how do you assess each of those controls. So 53A will list-- or, sorry, 53 will list what the controls are; 53A will say, "For each of those controls, here's how you assess the effectiveness of that."

of 16

Once you've assessed it and you've said, "Okay, we're ready to put this system into practice," you can authorize it. So, the certification and authorization process is governed by 800-37. And then monitoring. You do continuous monitoring on this to make sure that things-- if things changed, your controls are still effective and still work. And so you monitor that. You can take a look at 53A-- again, that's the assessment piece that we talked about down here at the bottom of the diagram-- and 800-37. Both of those documents will kind of give you guidance on how to do this. So this kind of eye candy chart right here tells you the documents and the guidance that's available to you, at least from NIST and the U.S. federal government on risk management.

of 16

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 16

nist sp 800-39 and 800-37 - usalearning...nist sp 800-39: tiers of risk management 23 risk...

Documents