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

Page 1 of 16
NIST SP 800-39

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

22

**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.

Page 2 of 16
NIST SP 800-39: Tiers of Risk Management

NIST SP 800-39: Tiers of Risk Management

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
• Multi-tier Organization-Wide Risk Management Tier 1 – Organization
Risk
(Governance)
• Implemented by the Risk Executive Function
• Tightly coupled to Enterprise Architecture and
Tier 2 – Mission
Information Security Architecture (Business Process)

• System Development Lifecycle Focus

Tier 3 – Information
• Disciplined and Structured Process System (Environment
of Operations)
Tactical
• Flexible and Agile Implementation
Risk

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

23

**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.

Page 3 of 16
NIST SP 800-39 : Process Applied

NIST SP 800-39: Process Applied

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

24

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

Page 4 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

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.

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

25

**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,

Page 5 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.

Page 6 of 16
NIST SP 800-39 : Risk Monitoring

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

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

26

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

Page 7 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.

Page 8 of 16
NIST SP 800-39 : Risk Response

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.
Ref: NIST SP 800-39, Managing Information Security Risk

27

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

Page 9 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

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

28

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

Page 10 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,

Page 11 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.

Page 12 of 16
Risk Management Framework

Risk Management Framework

Starting Point
FIPS 199 / SP 800-60

CATEGORIZE
Information System
SP 800-37 / SP 800-53A Define criticality/sensitivity of FIPS 200 / SP 800-53
information system according to
MONITOR potential worst-case, adverse SELECT
Security State impact to mission/business. Security Controls

Continuously track changes to the Select baseline security controls;

information system that may affect apply tailoring guidance and
supplement controls as needed
Security Life Cycle
security controls and reassess
control effectiveness. based on risk assessment.

SP 800-37 SP 800-39 SP 800-70

AUTHORIZE IMPLEMENT
Information System Security Controls
Determine risk to organizational SP 800-53A Implement security controls within
operations and assets, individuals, enterprise architecture using sound
other organizations, and the Nation; if ASSESS systems engineering practices; apply
acceptable, authorize operation. security configuration settings.
Security Controls
Determine security control effectiveness
(i.e., controls implemented correctly,
operating as intended, meeting security
requirements for information system).

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

29

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

Page 13 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."

Page 14 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.

Page 15 of 16
Notices

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
permission@sei.cmu.edu.

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.

Page 16 of 16