Transcript NIST 800-30 Guide to Conducting Risk Assessments

Reactions to Westlake RMF draft
PERSONAL comment by
Mikey O’Connor
Table of Contents
(based on deliverables in the RFI)
•
•
•
•
•
Description of the components of the risk management framework (e.g. risk
assessment, risk planning, delivery of standards/tools/techniques, risk and activity
monitoring, etc.).
Description of the roles, responsibilities, authority and accountability associated
with each component of the framework – who is responsible for delivering what,
and on what schedule
Description of the scope boundaries of the DNS security risk management function
of ICANN (the organization)
Description of the risk model to be used, assumptions and constraints that will be
applied and information sources that will be developed.
An assessment of the ability of ICANN (the organization and the community) to
deliver the risk- management tasks as described, including the gaps that would
need to be filled and recommendations as to how to fill those gaps. (Such an
assessment may need to be revisited on a periodic basis after the DNS security risk
management framework has been put into operation.)
Deliverable #1: Description of the components
of the risk management framework
!
!
!
!
!
!
!
!
·
C
o
n
t
r
o
lla
b
le
R
is
k
s
!
!
•
!
At!any!point!in!time,!different!parts!of!ICANN!may!be!at!different!levels!of!
maturity.!!
ISO!31000!Risk!management!process!
(Refer!Appendix!1!for!a!detailed!explanation!of!each!step)!
·
)
IC
A
N
N
S
t
r
a
t
e
g
ic
R
is
k
sC
O
M
M
U
N
IT
Y
G
L
O
B
A
L
IN
T
E
R
N
E
T
C
O
M
M
U
N
IT
Y
Kaplan/Mikes
R
is
k
a
s
s
e
s
s
m
e
n
t
R
is
k
id
e
n
tifi
c
a
tio
n
R
is
k
a
n
a
ly
s
is
!
R
is
k
e
v
a
lu
a
tio
n
•
next!two!pages,!the!greatest!benefits!of!risk!management!are!gained!at!the!
integrated!level.!
M
o
n
ito
r
in
g
a
n
d
r
e
v
ie
w
C
o
m
m
u
n
ic
a
tio
n
a
n
d
c
o
n
s
u
lta
tio
n
E
x
t
e
r
n
a
lE
v
e
n
t
s
IC
A
N
N
ICANN!should!assess!its!current!level!of!risk!management!maturity!and!then!
develop!a!plan!to!improve!maturity,!since,!as!described!in!the!matrix!on!the!
E
s
ta
b
lis
h
in
g
th
e
c
o
n
te
x
t
•
!
Risk#Management#Maturity#Model
Maturity
Integrated
Managed
•
Repeatable
Ini*al
R
is
k
tr
e
a
tm
e
n
t
e!institutional!risks!are!inherent!to!all!organisations!…!
!
!!!
Ad#Hoc
1000!defines!risk!as!‘the!effect!of!uncertainty!on!objectives.’!As!commentators!
!
ding!Kaplan!and!Mikes!have!noted,!risk!management!is!not!a!natural!process:!it!
ISO 31000
Time
!
The!table!below!describes!the!purpose!of!each!of!the!documents!and!who!is!
directly!counter!to!the!positive,!‘can!do’!culture!of!achievement!and!success!
responsible!for!endorsing!them.!
many!organisations!foster.!The!essence!of!risk!management!by!contrast!is!about!
!
ifying!and!assessing!what!could!go!wrong,!or!could!deflect!an!organization!from!
SEI Capability Maturity
•
ving!its!goals.!As!a!result,!an!organisation’s!culture,!resulting!from!the!!
tures,!processes,!accepted!behaviours!and!incentives!that!evolve!over!many!
!
!may!actively!discourage!or!hinder!(whether!consciously!or!subconsciously)!
!
ementation!of!effective!risk!management.!
ICANN!DNS!RMF!draft!v1.2.docx!
!2012!report,!“Roads!to!Ruin”,!the!British!Association!for!Risk!and!Insurance!
ICANN!DNS!RMF!draft!v1.2.docx!
21!
©2013!Westlake!Governance!
26!
©2013!Westlake!Governance!
agement!Professionals!(Airmic)!has!analysed!the!origins!and!impact!of!many!
orate!crises!over!the!last!decade.!The!report!identifies!seven!key!risk!areas!that!
!DNS!RMF!draft!v1.2.docx!
3!Westlake!Governance!
•
11!
•
Have these methodologies ever been
successfully combined in this way before? If
so, where?
Where are the points of integration between
the proposed methodologies?
Is the DNS a business? Should we be
presuming that business-oriented command
and control methods will work in the case of
the DNS?
Is Kaplan/Mikes, a business risk management
proposal outlined in the HBR and
underpinned by their “Balanced Scorecard”
business planning methodology, appropriate
to evaluate DNS risk?
Do the advantages of ISO 31000 (also a
business risk mgmt. methodology) offset the
licensing issues that will arise if ICANN wishes
to distribute a tailored version of this
proprietary methodology for use by the
community?
Has the SEI systems maturity model ever been
successfully applied to a technical risk
management function before?
How does ICANN avoid becoming dependent
on external vendors for developing and
maintaining this hybrid (largely proprietary)
methodology?
!
ment%MapDeliverable #2: Description of roles,
responsibilities,
authority and accountability
Process
Controllable Risks
A
s
s
e
s
s
T
r
e
a
t
E
v
a
lu
a
te
Id
e
n
tify
R
is
k
(
b
r
a
in
s
to
r
m
in
g
)
C
o
n
tr
o
l
la
b
le
?
Y
A
n
a
ly
s
e
-L
ik
e
lih
o
o
d
-Im
p
a
c
to
n
A
C
I
N
S
e
le
c
tO
p
tio
n
s
-A
v
o
id
-M
itig
a
te
-A
c
c
e
p
t
-T
r
a
n
s
fe
r
M
o
n
ito
r
Im
p
le
m
e
n
t
-T
e
c
h
n
ic
a
l
m
itig
a
tio
n
s
-R
u
le
s
a
n
d
p
r
o
to
c
o
ls
R
e
v
ie
w
T
o
E
x
te
r
n
a
l
E
v
e
n
ts
O
O
L
I
O
O
O
L
L
L
D
N
S
R
A
G
P
P
P
P
S
S
A
C
/R
S
S
A
C
C
C
C
C
IC
A
N
N
C
o
m
m
u
n
ity
C
C
C
C
C
C
IC
A
N
N
s
ta
ff
C
D
N
S
C
o
m
m
u
n
ity
As req ui red
IC
A
N
N
b
o
a
r
d
O
I
P
Rumsfeld: known knowns
Kaplan/Mikes: preventable risks
Risks that are considered as Class I and are caused by
employees' unauthorized, illegal unethical, or
inappropriate actions. In general, management knows the
actions it wants employees to avoid (the "known knowns")
and has specific management tools and processes to deter
or prevent them from occurring. Ideally, companies want
to drive the probability of Class I risks to zero.
•
•
–
–
–
•
L
e
g
e
n
d
:O
v
e
r
s
e
eL
e
a
dP
a
r
tic
ip
a
teC
o
n
s
u
lt Im
p
le
m
e
n
t
Rumsfeld: unknown unknowns
Kaplan/Mikes: external risks
External Events
A
s
s
e
s
s
T
r
e
a
t
A
n
a
ly
s
e
Id
e
n
tify
R
is
k
(
b
r
a
in
s
to
r
m
in
g
)
C
o
n
tr
o
l
la
b
le
?
a
rg
a
m
in
g
N -W
-S
c
e
n
a
r
io
p
la
n
n
in
g
E
v
a
lu
a
te
-L
ik
e
lih
o
o
d
-Im
p
a
c
to
n
A
C
I
S
e
le
c
tO
p
tio
n
s
-M
itig
a
te
im
p
a
c
t
-A
c
c
e
p
t
Im
p
le
m
e
n
t
-D
e
fe
n
c
e
a
c
tio
n
s
-B
e
h
a
v
io
u
r
c
h
a
n
g
e
R
e
v
ie
w
O
O
O
O
O
IC
A
N
N
s
ta
ff
L
I
L
L
L
D
N
S
R
A
G
P
P
P
P
S
S
A
C
/R
S
S
A
C
C
C
C
C
IC
A
N
N
C
o
m
m
u
n
ity
C
C
C
C
D
N
S
C
o
m
m
u
n
ity
C
C
C
As r eq ui r e d
T
o
C
o
n
tr
o
lla
b
le
R
is
k
s
IC
A
N
N
b
o
a
r
d
O
I
P
L
e
g
e
n
d
:O
v
e
r
s
e
eL
e
a
dP
a
r
tic
ip
a
teC
o
n
s
u
lt Im
p
le
m
e
n
t
•
Strategic Risks
T
r
e
a
t
A
n
a
ly
s
e
-E
x
p
e
r
tp
a
n
e
l
E
v
a
lu
a
te
-L
ik
e
lih
o
o
d
-Im
p
a
c
to
n
A
C
I
O
p
tio
n
s
-A
b
a
n
d
o
n
-M
o
d
ify
-M
itig
a
te
-T
r
a
n
s
fe
r
IC
A
N
N
b
o
a
r
d
O
O
O
L
IC
A
N
N
s
ta
ff
L
L
L
P
D
N
S
R
A
G
P
P
P
P
S
S
A
C
/R
S
S
A
C
C
C
C
C
IC
A
N
N
C
o
m
m
u
n
ity
C
C
C
C
D
N
S
C
o
m
m
u
n
ity
C
C
C
L
e
g
e
n
d
:O
v
e
r
s
e
eL
e
a
dP
a
r
tic
ip
a
teC
o
n
s
u
lt Im
p
le
m
e
n
t
M
o
n
ito
r
Im
p
le
m
e
n
t
-S
to
p
-M
o
d
ify
-P
ilo
t
-C
o
m
m
u
n
ic
a
te
As r eq u i r ed
A
s
s
e
s
s
Id
e
n
tifyR
is
k
(
p
a
r
to
f
Id
e
n
tifyR
is
k
b
u
s
in
e
s
s
(
b
r
a
in
s
to
r
m
in
g
)
c
h
a
n
g
e
p
r
o
p
o
s
a
l)
Class III risks arise from events outside the company and
its strategy and thus are beyond the company's direct
influence or control. Managers cannot estimate their
likelihood and, in many cases, are not even aware of such
events (the "unknown unknowns") or that they could
jeopardize the company's strategy and survival. Managing •
Class III risks requires a process of "risk envisionment" in
which managers rely less on quantitative risk management
and more on their experience, intuition and imagination to
create new mental models about future scenarios and
strategic uncertainties. Once Class III risks have been
envisioned, managers can brainstorm about how to
enhance organizational resilience to withstand the most
consequential of them..
!
Y
M
o
n
ito
r
R
e
s
id
u
a
lr
is
k
s
-C
la
s
s
ify
:
E
x
te
r
n
a
l/
C
o
n
tr
o
lla
b
le
-M
a
n
a
g
e
O
I
P
Rumsfeld: known unknowns
Kaplan/Mikes: strategy risks
Class II risks arise primarily from strategic execution.
Organizations voluntarily take on Class II risks so that they
can generate high returns from their strategies. Managers
can identify Class II risk events (they are "known
unknowns") and can generally influence both their
likelihood and impact. While managers have some ability
to reduce the likelihood and impact of Class II risks, they
cannot eliminate the probability of their occurrence.
Despite management's efforts, some residual risks always
remain.
Definitions are from Kaplan/Mikes HBR piece
Note the assumptions that underpin this
model.
•
There is a single organization,
it can make and execute strategy on its own,
it has control over resources, employees, etc.
Are those assumptions true in the case of
ICANN and the DNS?
The treatment of “strategy risk” seems
malformed. E.g., the biggest strategic change
to ICANN, the “new gTLDs” strategy, came
through the GNSO – and is driven by business
strategies of external entities, not ICANN.
What is the relationship between GNSO
“picket fence” policy and this approach?
Kaplan/Rumsfeld treat “external” risk as the
most difficult to manage. Westlake’s
examples of this are largely technical, but
aren’t the geo-political “split the root” risks in
this category? Are these methods
appropriate to address risks of that type?
The descriptions of risk “treatment” and
“monitoring” also presume a unified entity. In
most cases, treatment and monitoring of DNS
risk will be done by entities outside of ICANN.
How will ICANN support that effort, if at all?
It would be helpful to develop a “base”
version of these processes and then highlight
the very small proportion of the material that
changes between the three cases.
Deliverable #3: Description of the scope boundaries of
the DNS security risk management function of ICANN
(the organization)
•
•
•
•
Source: DSSA
The “scope boundaries” deliverable
listed in the RFI is difficult to find in this
draft – which section covers that
material?
If this is not yet complete, is the
definition of those scope boundaries
planned for a subsequent phase of the
work? If so, what is the approach to
arriving at agreement between the
various participants?
ICANN is part of a collaborative
ecosystem of participants who
collectively manage DNS risk. Which of
those activities is ICANN: responsible
for, a supporter of, a participant in, etc.?
To what extent does this risk
management framework entertain the
idea of empowering the larger
community of participants to help with
facets of DNS risk management, and
what role is envisioned for ICANN in that
effort?
Deliverable #4: Description of the risk model to be
used, assumptions and constraints that will be applied
and information sources that will be developed.
In the context of…
An Adversarial
Threat Source
(with capability,
intent and
targe ng)
Security
Controls
OR
A NonAdversarial
Threat Source
(with a range
of effects)
•
Predisposing
Condi ons
(with varying
pervasiveness)
Could
Ini ate
A Threat
Event
Which
could
result in
Adverse
Impacts
(planned and
implemented)
Vulnerabili es
(ranging in
severity)
(with varying
likelihood of
ini a on)
(with varying
likelihood of
impact)
(with varying
severity and
range)
Crea ng RISK to users and providers of the DNS – a
combina on of the nature of the impact and the likelihood
that its effects will be felt
Source: DSSA
•
•
Although Kaplan/Mikes disparage “checklist
based” methodologies in their HBR article,
ISO 31000 and other comparable
methodologies (COBIT, NIST 800-30, etc.) are
strongly (and similarly) structured in their
analytic frameworks.
One of the critical components of all of those
methodologies is the series of choices that
are made before detailed analysis is begun –
this is called the “risk model” in some
methodologies, and that was what I
expected to see in this section of the report.
The two DSSA documents on this page
summarize roughly 20 tables the group
tailored to address the DNS. Those
customized tables all support a 1-page
instrument that a risk management
practitioner can use to quickly develop DNS
risk scenarios. Are similar models and tools
envisioned in this framework?
Deliverable #5: An assessment of the ability of ICANN (the organization
and the community) to deliver the risk- management tasks as described,
including the gaps that would need to be filled and recommendations as
to how to fill those gaps.
•
Source: Yahoo images
•
•
•
•
•
Was there any underlying analysis that was
excluded from the report (perhaps for
confidentiality reasons) that supports the
conclusion that “the capacity of existing staff
to assume additional risk management
responsibilities or tasks is limited. Any
significant new or expanded function is
likely to require a new staff position.”
Was there a determination of skills
requirements, and staff capabilities in
meeting those requirements (aka a skills
matrix)? If so, could the framework (not the
detailed assessments) be included in the
report?
Similarly, if there was a framework used to
conduct a gap analysis, could it be included?
What is the role of the community in DNS
risk management, and what skills and
capabilities are required and/or missing from
that mix?
The analysis concludes that more staff is
required – is that due to a gap in skills, a gap
in “bandwidth” or a combination of both?
The section concludes with a statement that
“a capability assessment be undertaken.”
How does that differ from what was
requested in the RFI for this project?
Gather comments
and feedback
Beijing
Toronto
Refine and
consolidate
Launch the Risk
Mgmt. function
Align/Integrate
DNSRMF and DSSA
findings/methods/le
adership
Select DNS riskmanagement framework
consultant and launch
DNSRMF project
Complete DNS riskmanagement framework
Establish
communitybased portion of
RM launch
project
Launch the project to
establish the RM
function and complete
one “cycle”
DSSA
Joint
effort
What now?
Obtain community
feedback and
incorporate those
suggestions into the RM
framework
(focus/scope:
ICANN the org)
Public comment
Determine
whether
separate DSSA
risk-assessment
effort is needed
DNSRMF
Revise report and obtain
AC/SO endorsement
(focus/scope:
ICANN the community)
ID roles – gaps &
overlaps
8
Options for the DSSA
• Clarify relationship to DNSRMF
Stop
Wait
GO
– Current: DSSA has broader DNS scope
(all-DNS, vs ICANN-only), narrower
deliverable scope (only assessment,
not full RMF)
– Options: Continue, narrow DNS
scope, or broaden scope to include
community-based RMF
• Determine next step
– Declare victory and wrap up
– Restart and complete next cycle
– Revise charter to include “open
source” RMF for the broader DNS
community
Appendix
NIST 800 – “open source” basis for
community-based RMF
NIST 800 Guide to Applying
the Risk Management Framework
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
Special Publication 800-37
Baseline: Overview
Guide for Applying the Risk Management Framework to Federal Information Systems
A Security Life Cycle Approach
________________________________________________________________________________________________
CHAPTER TWO
THE FUNDAMENTALS
2.1 INTEGRATED
ORGANIZATION-WIDE RISK MANAGEMENT
Managing
his chapter
describes the basicinformation
concepts associated withsystem-related
managing information system- security risks is a complex, multifaceted undertaking that
related security risks. These concepts include: (i) incorporating risk management
requires
the
involvement
the
entirecoreorganization—from senior leaders providing the strategic vision
principles
and best practices
into organizationwide strategic of
planning
considerations,
missions and business processes, and supporting or ganizational information systems; (ii)
and top-level
goals
and
objectives
for (iii)
the organization, to mid-level leaders planning and managing
integrating information
security requirements
into system
development
life cycle processes;
establishing practical and meaningful boundaries for organizational information systems; and (iv)
projects,
to individuals
onas the
fronthybrid,
lines
allocating security
controls to organizational
information systems
system-specific,
or developing, implementing, and operating the systems
common controls.
supporting the organization’s core missions and business processes. Risk management can be viewed
2.1 INTEGRATED ORGANIZATION-WIDE RISK MANAGEMENT
as a holistic activity that is fully integrated into every aspect of the organization. Figure 2-1 illustrates a
Managing information system-related security risk s is a complex, multifaceted undertaking that
requires the involvement of the entire organiza tion—from senior leaders providing the strategic
three-tiered
risk leaders
management
that addresses risk-related concerns at: (i) the organization
vision and top-level
goals and objective sapproach
for the organization,to
to mid-level
planning a nd
managing projects, to individuals on the front lines developing, implementing, and operating the
level;
(ii) thecoremission
and processes.
business
process level; and (iii) the information system level.15
systems supporting
the organization’s
missions and business
Risk m anagement
MANAGING INFORMATION SYSTEM-RELATED SECURITY RISKS
T
•
can be viewed as a holistic activity that i s fully integrated into every aspect of the organization.
Figure 2-1 illustrates a three-tiered approach to risk management that addresses risk-related
concerns at: (i) the organization level; (ii) the mission and business process level; and (iii) the
information system level.15
- Multitier Organization-Wide Risk Management
- Implemented by the Risk Executive (Function)
- Tightly coupled to Enterprise Architecture
TIER 1
and Information Security Architecture
- System Development Life Cycle Focus
ORGANIZATION
(Governance)
- Disciplined and Structured Process
- Flexible and Agile Implementation
TIER 2
MISSION / BUSINESS PROCESS
(Information and Information Flows)
STRATEGIC RISK
STRATEGIC
Cross-community collabora on
Risk Scenario
Topic List
TACTICAL RISK
TIER 3
INFORMATION SYSTEM
(Environment of Operation)
CORE
Gaps in policy, management,
or leadership splits the root
FIGURE 2-1: TIERED RISK MANAGEMENT APPROACH
15
NIST Special Publication 800-39, Integrated Enterprise-Wide Risk Management: Organization, Mission, and
Information System View (projected for publication in 2010), will provide guidance on the holistic approach to risk
management.
GLUE
LONG-TERM
CHAPTER 2
Ecosystem-wide
IMMEDIATE
PAGE 5
“Regional” or “segment” focus
EDGE
Need:
Need:
Provider or organiza on-focused risk
coordina on, fast
models, tools,
response
support, direc on
“Reduc ve” forces (security,
risk-mi ga on, control
through rules, etc.) splits the
root
Widespread natural disaster
brings down the root or a
major TLD
A acks exploi ng technical
vulnerabili es of the DNS
bring down the root or a
major TLD
Inadvertent technical mishap
brings down the root or a
major TLD
•
Use NIST RMF (NIST 800-37) as
the starting point for a RMF
that is aware of and
responsive to the multistakeholder DNS risk
environment
Tailor NIST framework (which
also presumes a single
organization) to reflect needs
of multi-organization DNS
collaboration
TACTICAL
DNS providers are at the forefront
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
Baseline: Process Overview
• Categorize the information system and the
information processed, stored, and transmitted by
that system based on an impact analysis.22
• Select an initial set of baseline security controls for
the information system based on the security
categorization; tailoring and supplementing the
security control baseline as needed based on an
organizational assessment of risk and local
conditions.23
• Implement the security controls and describe how
the controls are employed within the information
system and its environment of operation.
• Assess the security controls using appropriate
assessment procedures to determine the extent to
which the controls are implemented correctly,
operating as intended, and producing the desired
outcome with respect to meeting the security
requirements for the system.
• Authorize information system operation based on a
determination of the risk to organizational operations
and assets, individuals, other organizations, and the
Nation resulting from the operation of the
information system and the decision that this risk is
acceptable.
• Monitor the security controls in the information
system on an ongoing basis including assessing
control effectiveness, documenting changes to the
system or its environment of operation, conducting
security impact analyses of the associated changes,
and reporting the security state of the system to
designated organizational officials.
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
Baseline: Roles and Responsibilities
D.2 RISK EXECUTIVE (FUNCTION)
The risk executive (function) is an individual or group within an organization that helps to ensure
that: (i) risk-related considerations for individual information systems, to include authorization
decisions, are viewed from an organization-wide perspective with regard to the overall strategic
goals and objectives of the organization in carrying out its core missions and business functions;
and (ii) managing information system-related security risks is consistent across the organization,
reflects organizational risk tolerance, and is considered along with other types of risks in order
to ensure mission/business success. The risk executive (function) coordinates with the senior
leadership of an organization to:
•Provide a comprehensive, organization-wide, holistic approach for addressing risk—an
approach that provides a greater understanding of the integrated operations of the
organization;
•Develop a risk management strategy for the organization providing a strategic view of
information security-related risks with regard to the organization
as a whole;50
Special Publication 800-37
Guide for Applying the Risk Management Framework to Federal Information Systems
A Security Life Cycle Approach
________________________________________________________________________________________________
•Facilitate the sharing of risk-related information among
authorizing officials and other senior
leaders within the organization;
APPENDIX E
•Provide oversight for all risk management-related activities across the organization (e.g.,
OFacceptance
RMF TASKS
security categorizations) to help ensure consistent andSUMMARY
effective risk
decisions;
LISTING OF PRIMARY RESPONSIBILITIES AND SUPPORTING ROLES
•Ensure that authorization decisions consider all factors
necessary for mission and business
success;
RMF TASKS
PRIMARY RESPONSIBILITY
SUPPORTING ROLES
•Provide an organization-wide forum to consider all sources of risk (including aggregated risk) to
RMF
Step
1:
Categorize
Information
System
organizational operations and assets, individuals, other organizations, and the Nation;
Information
System Owner
Risk Executive (Function)
TASK 1-1 officials to include
•Promote cooperation and collaboration among authorizing
authorization
Information Owner/Steward
Authorizing Official or Designated
Security Categorization
Representative
actions requiring shared responsibility;
Categorize the information system
Chief Information Officer
and document the results of the
•Ensure that the shared responsibility for supporting organizational
mission/business functions Senior Information Security Officer
security categorization in the
Information System Security Officer
security plan.
using external providers of information and services receives the needed visibility and is
TASK
1-2
Information
System
Owner
Authorizing Official or Designated
elevated to the appropriate decision-making authorities; and
Representative
Information System Description
Senior Information Security Officer
•Identify the organizational risk posture based on the aggregated
risk
to information from the
Describe the information
system
Information Owner/Steward
(including system boundary) and
Information System Security Officer
operation and use of the information systems for which
the the
organization
is responsible.
document
description in the
security plan.
The risk executive (function) presumes neither a specific organizational structure nor formal
TASK 1-3
Information System Owner
Information System Security Officer
responsibility assigned to any one individual or group within
the organization.
The head of the
Information System Registration
agency/organization may choose to retain the risk executive
or to delegate the
Register the (function)
information system with
organizational
function to another official or group (e.g., an executiveappropriate
leadership
council). The risk executive
program/management
offices.
(function) has inherent U.S. Government authority and is assigned to government personnel
RMF Step 2: Select Security Controls
only.
TASK 2-1
Common Control Identification
Identify the security controls that are
provided by the organization as
common controls for organizational
information systems and document
the controls in a security plan (or
equivalent document).
TASK 2-2
Security Control Selection
Select the security controls for the
information system and document
the controls in the security plan.
Chief Information Officer or Senior
Information Security Officer
Information Security Architect
Common Control Provider
Risk Executive (Function)
Authorizing Official or Designated
Representative
Information System Owner
Information System Security Engineer
Information Security Architect
Information System Owner
Authorizing Official or Designated
Representative
Information Owner/Steward
Information System Security Officer
Information System Security Engineer
•
Develop a community wide
understanding and
agreement as to “who does
what” in DNS risk
management
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf
Sample: Risk Monitoring
G.1 MONITORING STRATEGY
Organizations develop a strategy and implement a program for the continuous monitoring of security
control effectiveness including the potential need to change or supplement the control set, taking into
account any proposed/actual changes to the information system or its environment of operation. The
monitoring program is integrated into the organization’s system development life cycle processes. A
robust continuous monitoring program requires the active involvement of information system owners
and common control providers, chief information officers, senior information security officers, and
authorizing officials. The monitoring program allows an organization to: (i) track the security state of
an information system on a continuous basis; and (ii) maintain the security authorization for the
system over time in highly dynamic environments of operation with changing threats, vulnerabilities,
technologies, and missions/business processes.
An effective organization-wide continuous monitoring program includes:
•Configuration management and control processes for organizational information systems;
•Security impact analyses on proposed or actual changes to organizational information systems and
environments of operation;84
•Assessment of selected security controls (including system-specific, hybrid, and common controls)
based on the organization-defined continuous monitoring strategy;85
•Security status reporting to appropriate organizational officials;86 and
•Active involvement by authorizing officials in the ongoing management of information
•system-related security risks.
http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf