NIST Information Security Guide For IT Systems

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 65

Download
Open PDF In Browser	View PDF

Archived NIST Technical Series Publication
The attached publication has been archived (withdrawn), and is provided solely for historical purposes.
It may have been superseded by another publication (indicated below).

Archived Publication
Series/Number:
Title:

NIST Special Publication 800-30

Risk Management Guide for Information Technology Systems

Publication Date(s):

July 2002

Withdrawal Date:

September 2012

Withdrawal Note:

SP 800-30 is superseded in its entirety by the publication of
SP 800-30 Revision 1 (September 2012).

Superseding Publication(s)
The attached publication has been superseded by the following publication(s):
Series/Number:
Title:
Author(s):

NIST Special Publication 800-30 Revision 1

Guide for Conducting Risk Assessments
Joint Task Force Transformation Initiative

Publication Date(s):

September 2012

URL/DOI:

http://dx.doi.org/10.6028/NIST.SP.800-30r1

Additional Information (if applicable)
Contact:
Latest revision of the

Computer Security Division (Information Technology Lab)

SP 800-30 Revision 1 (as of June 19, 2015)

attached publication:
Related information:
Withdrawal
announcement (link):

http://csrc.nist.gov/
N/A

Date updated: June ϭ9, 2015

NATL

INST. OF

STAND & TECH

NISI

PUBUCATSOt^S

National Institute of

Standards and Technology
Technology Administration
U.S.

Department of Commerce

NIST

Risk Management Guide
for Information Technology
Systems
Recommendations of the National Institute
of Standards and Technology

Special Publication

800-30

Gary Stoneburner,

Alice Goguen,

and

Alexis Feringa

COMPUTER

SECURITY

rhe

National Institute of Standards and Teciinology was established in 1988 by Congress to "assist

industry in the development of technology

processes, to ensure product reliability

and

needed

to facilitate rapid

improve product quality,
commercialization

...of

modernize manufacturing

products based on

new

scientific

discoveries."

NIST,

originally

founded as the National Bureau of Standards

in 1901,

works

to strengthen U.S. industry's

competitiveness; advance science and engineering; and improve public health, safety, and the environment.

One

of the

and retain custody of the national standards of measurement, and provide
the means and methods for comparing standards used in science, engineering, manufacturing, commerce, industry, and
education with the standards adopted or recognized by the Federal Government.
As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and
agency's basic functions

to develop, maintain,

applied research in the physical sciences and engineering, and develops measurement techniques, test
Institute does generic and precompetitive work on new and
20899, and at Boulder, CO 80303.
advanced technologies. NIST's research facilities are located at Gaithersburg,
Major technical operating units and their principal activities are listed below. For more information contact the Publications
and Program Inquiries Desk, 301-975-3058.

methods, standards, and related services. The

Office of the Director
•

National Quality Program

•

International and

Academic Affairs

Chemical Science and Technology
Laboratory

•

Biotechnology
Physical and Chemical Properties'
Analytical Chemistry

•

Technology Services
•

Standards Services

•

Process Measurements

•

Surface and Microanalysis Science

•

Technology Partnerships
Measurement Services

•

Information Services

Physics Laboratory

Advanced Technology Program

•

Electron and Optical Physics

•

Atomic Physics
Optical Technology

•

Economic Assessment

•

Information Technology and Applications

•

Ionizing Radiation

•

Chemistry and Life Sciences

•

Materials and Manufacturing Technology

•

Time and Frequency'
Quantum Physics'

•

Electronics and Photonics Technology

Manufacturing Extension Partnership

Program

Manufacturing Engineering
Laboratory
•

Precision Engineering

•

Regional Programs

•

National Programs

•

Program Development

•

Automated Production Technology
Intelligent Systems
Fabrication Technology
Manufacturing Systems Integration

•

Electronics

and

Electrical Engineering

Building and Fire Research Laboratory
• Applied Economics

Laboratory
•

Microelectronics

•

Law Enforcement

•

Structures

Electricity

•

Building Materials

•

Building Environment

•

Fire Safety Engineering

•

Semiconductor Electronics
Radio-Frequency Technology
Electromagnetic Technology'

•

Fire Science

•

Optoelectronics'

•
•
•

Standards

Information Technology Laboratory
Materials Science and Engineering

•

Laboratory

•

Mathematical and Computational Sciences^
Advanced Network Technologies

•

Computer Security

•

Information Access and User Interfaces
High Performance Systems and Services
Distributed Computing and Information Services
Software Diagnostics and Conformance Testing

•

Statistical

•
•

Theoretical and Computational Materials Science

Materials Reliability'
•

•

Ceramics
Polymers

•

Metallurgy

•

NIST Center

•

'At Boulder,
2

Some

•

for

Neutron Research

80303.

elements at Boulder, CO.

Engineering

NisT

Special Publication 800-30

Risk Management Guide
for Information Technology
Systems
Recommendations of the National Institute
of Standards and Technology
Gary Stoneburner, Alice Goguen, and
Alexis Feringa

COMPUTER SECURITY
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Gaithersburg, MD 20899-8930

July

2002

U.S. Department of

Commerce

Donald L. Evans, Secretary

Technology Administration
Phillip

Bond, Under Secretary of Commerce for Technology

National Institute of Standards and Technology

Arden

Bement,

Jr.,

Director

Reports on Information Security Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST)
promotes the U.S. economy and public welfare by providing technical leadership for the Nation's measurement
and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept
implementations, and technical analyses to advance the development and productive use of information
technology.

management

ITL's

responsibilities

include

the

development of technical, physical,

administrative,

and

standards and guidelines for the cost-effective security and privacy of sensitive unclassified

information in Federal computer systems. This Special Publication 800-series reports on ITL's research,

guidance, and outreach efforts in computer security, and

its

collaborative activities with industry, government,

and academic organizations.

Certain commercial

equipment, or materials

entities,

may be

identified in this

experimental procedure or concept adequately. Such identification

endorsement by the National

Institute

document

in order to describe

not intended to imply recommendation or

of Standards and Technology, nor

is it

intended to imply that the entities,

materials, or equipment are necessarily the best available for the purpose.

National Institute of Standards and Technology Special Publication 800-30
Natl. Inst. Stand. Technol. Spec. Publ. 800-30, 54 pages (July 2002)

CODEN: NSPUE2

U.S.

GOVERNMENT PRINTING OFFICE
WASHINGTON:

For

sale

Internet:

the Superintendent of

bookstore.gpo.gov
Mail: Stop

2002

Documents, U.S. Government Printing Office
Fax: (202) 5 1 2-2250
(202) 5 1 2- 1 800

— Phone:

SSOP

Washington,

—

20402-0001

Acknowledgements
The

authors,

Gary Stonebumer from NIST and Ahce Goguen and Alexis Feringa from Booz

Allen Hamilton, wish to express their thanks to their colleagues

both organizations

who

reviewed drafts of this document. In particular, Timothy Grance, Marianne Swanson, and Joan
Hash from NIST and Debra L. Banning, Jeffrey Confer, Randall K. Ewell, and Waseem
Mamlouk from Booz Allen Hamilton, provided valuable insights that contributed substantially to
the technical content of this document. Moreover, we gratefully acknowledge and appreciate the
many comments from the public and private sectors whose thoughtful and constructive
comments improved the quality and utility of this publication.

SP 800-30

Page

iii

TABLE OF CONTENTS
INTRODUCTION

Authority
Purpose

1.1

1.2
1.3

Objective

1.4

Target Audience
Related References
Guide Structure

1.5

1.6

RISK MANAGEMENT OVERVIEW

Importance of Risk Management
Integration of Risk Management into SDLC
Key Roles

2.1

2.2
2.3

RISK ASSESSMENT

Step

3.1

System Characterization

3.1.1

System-Related Information

3.1.2

Information-Gathering Techniques

Step 2: Threat Identification

3.2
3.2.1

3.2.2

Threat-Source Identification
Motivation and Threat Actions

Step

3.3

Vulnerability Identification

3.3.1

Vulnerability Sources

3.3.2

System Security Testing

3.3.3
3.4
3.4.1

Development of Security Requirements Checklist
Step 4: Control Analysis
Control Methods

3.4.2

Control Categories

3.4.3

Control Analysis Technique

Step 5 Likelihood Determination
Step 6: Impact Analysis
Step?: Risk Determination

3.5

3.6
3.7
3.7.1
3.7.2

3.8

3.9

Risk-Level Matrix

Description of Risk Level
Step 8: Control Recommendations
Step 9: Results Documentation

RISK MITIGATION

4.3

Risk Mitigation Options
Risk Mitigation Strategy
Approach for Control Implementation

4.4

Control Categories

4.1

4.2

4.4.1

Technical Security Controls

4.4.2

Management

4.4.3

Security Controls

Operational Security Controls

Cost-Benefit Analysis
Residual Risk

4.5

4.6

EVALUATION AND ASSESSMENT

Ciood Security Practice
Keys for Success

5.1

5.2

Appendix

A—Sample Interview Questions

Appendix B

SP 800-30

—Sample Risk Assessment Report Outline

AB-

Page

—Sample Implementation Safeguard Plan Summary Table
Appendix D — Acronyms
Appendix E—Glossary
Appendix F—References
C

Appendix

C-1

D-1
E-1
F-

LIST OF FIGURES
Figure 3-1 Risk Assessment Methodology Flowchart

Figure 4-1 Risk Mitigation Action Points

Figure 4-2 Risk Mitigation Methodology Flowchart

Figure 4-3 Technical Security Controls

Figure 4-4 Control Implementation and Residual Risk

LIST OF TABLES
Table 2-1 Integration of Risk Management
Table 3-1

Human Threats:

to the

SDLC

Threat-Source, Motivation, and Threat Actions

Table 3-2 Vulnerability/Threat Pairs

Table 3-3 Security Criteria

Table 3-4 Likelihood Definitions

Table 3-5 Magnitude of Impact Definitions

Table 3-6 Risk-Level Matrix

Table 3-7 Risk Scale and Necessary Actions

SP 800-30

Page v

Every organization has a mission. In

INTRODUCTION

this digital era, as organizations

use automated information

technology (IT) systems^ to process their information for better support of their missions, risk

management plays
its

a critical role in protecting an organization's information assets, and therefore

mission, from IT-related risk.

effective risk

management process

an important component of a successful IT security

program. The principal goal of an organization's risk management process should be to protect

and

perform their mission, not just its IT assets. Therefore, the risk
management process should not be treated primarily as a technical function carried out by the IT
experts who operate and manage the IT system, but as an essential management function of the
the organization

its

ability to

organization.

1.1

AUTHORITY

This document has been developed by

NIST

in furtherance of its statutory responsibilities

under

Computer Security Act of 1987 and the Information Technology Management Reform Act of
1996 (specifically 15 United States Code (U.S.C.) 278 g-3 (a)(5)). This is not a guideline within
the meaning of 15 U.S.C 278 g-3 (a)(3).
the

These guidelines are for use by Federal organizations which process sensitive information.
They are consistent with the requirements of 0MB Circular A-130, Appendix HI.
mandatory and binding standards. This document may be used by
non-governmental organizations on a voluntary basis. It is not subject to copyright.

The guidelines herein

are not

Nothing in this document should be taken to contradict standards and guidelines made
mandatory and binding upon Federal agencies by the Secretary of Commerce under his statutory
authority. Nor should these guidelines be interpreted as altering or superseding the existing
authorities of the Secretary of Commerce, the Director of the Office of Management and Budget,
or any other Federal official.

1.2

PURPOSE

Risk

the net negative impact of the exercise of a vulnerability, considering both the probability

and the impact of occurrence. Risk management is the process of identifying risk, assessing risk,
and taking steps to reduce risk to an acceptable level. This guide provides a foundation for the
development of an effective risk management program, containing both the definitions and the
practical guidance necessary for assessing and mitigating risks identified within IT systems. The
ultimate goal

to help organizations to better

The term "IT system"

refers to a general support

manage

system

(e.g.,

IT-related mission risks.

mainframe computer, mid-range computer,

area network, agencywide backbone) or a major application that can run on a general support system and

local

whose

use of information resources satisfies a specific set of user requirements.

SP 800-30

Page

—
In addition, this guide provides information

on the selection of cost-effective security controls.^

These controls can be used to mitigate risk for the better protection of mission-critical
information and the IT systems that process, store, and carry this information.
Organizations

may choose

expand or abbreviate the comprehensive processes and steps
guide and tailor them to their environment in managing IT-related mission

suggested in this

risks.

OBJECTIVE

1.3

The

objective of performing risk

management

is to

enable the organization to accomplish

its

mission(s) (1) by better securing the IT systems that store, process, or transmit organizational
information; (2)

by enabling management

justify the expenditures that are part of an

make well-informed

IT budget; and (3)

management decisions
by assisting management in
risk

authorizing (or accrediting) the IT systems-^ on the basis of the supporting documentation
resulting

1.4

from the performance of risk management.

TARGET AUDIENCE
common foundation for experienced and inexperienced, technical, and
personnel who support or use the risk management process for their IT systems.

This guide provides a
non-technical

These personnel include
•

Senior management, the mission owners,

who make

decisions about the IT security

budget.
•

Federal Chief Information Officers,

management
•

for

who

ensure the implementation of risk

agency IT systems and the security provided for these IT systems

The Designated Approving Authority (DAA), who

responsible for the final

decision on whether to allow operation of an IT system

program manager, who implements the security program

•

The IT

•

Information system security officers (ISSO),

•

IT system owners of system software and/or hardware used to support IT functions.

•

Information owners of data stored, processed, and transmitted by the IT systems

•

Business or functional managers,

•

Technical support personnel

security

(e.g.,

who

are responsible for IT security

are responsible for the IT procurement process

network, system, application, and database

administrators; computer specialists; data security analysts),

who manage and

administer security for the IT systems
•

IT system and application programmers,
affect

maintain code that could

system and data integrity

The terms "safeguards" and
this

who develop and

"controls" refer to risk-reducing measures; these terms are used interchangeably in

guidance document.

Management and Budget's November 2000 Circular A-130, the Computer Security Act of 1987, and the
Government Information Security Reform Act of October 2000 require that an IT system be authorized prior to

Office of

operation and reauthorized at least every 3 years thereafter.

SP 800-30

Page 2

IT quality assurance personnel,

•

who

test

and ensure the integrity of the IT systems

and data

1.5

•

Information system auditors,

•

IT consultants,

who

audit IT systems

support clients in risk management.

RELATED REFERENCES

This guide

based on the general concepts presented

in National Institute of

Standards and

Technology (NIST) Special Publication (SP) 800-27, Engineering Principles for IT Security,
along with the principles and practices in NIST SP 800-14, Generally Accepted Principles and
Practices for Securing Information Technology Systems. In addition, it is consistent with the
policies presented in Office of Management and Budget (0MB) Circular A-130, Appendix III,
"Security of Federal Automated Information Resources"; the Computer Security Act (CSA) of
1987; and the Government Information Security Reform Act of October 2000.
1.6

GUIDE STRUCTURE

The remaining
•

sections of this guide discuss the following:

Section 2 provides an overview of risk management,

development

life

how

it fits

cycle (SDLC), and the roles of individuals

into the system

who

support and use this

process.
•

Section 3 describes the risk assessment methodology and the nine primary steps in

conducting a risk assessment of an IT system.
•

•

Section 4 describes the risk mitigation process, including risk mitigation options and
strategy,

approach for control implementation, control categories, cost-benefit

analysis,

and residual

risk.

Section 5 discusses the good practice and need for an ongoing risk evaluation and

assessment and the factors that will lead to a successful risk management program.

This guide also contains six appendixes. Appendix

Appendix

C contains

SP 800-30

sample interview questions.

provides a sample outline for use in documenting risk assessment results. Appendix

a sample table for the safeguard implementation plan.

acronyms used in this document. Appendix
this guide. Appendix F lists references.
the

A provides

E contains

Appendix

D provides a list of

a glossary of terms used frequently in

Page 3

RISK MANAGEMENT OVERVIEW

This guide describes the risk management methodology,

and how the risk management process

how

tied to the process of

it fits

into each phase of the

SDLC,

system authorization (or

accreditation).

2.1

IMPORTANCE OF RISK MANAGEMENT

Risk management encompasses three processes: risk assessment, risk mitigation, and evaluation
and assessment. Section 3 of this guide describes the risk assessment process, which includes

and evaluation of risks and risk impacts, and recommendation of risk-reducing
measures. Section 4 describes risk mitigation, which refers to prioritizing, implementing, and
maintaining the appropriate risk-reducing measures recommended from the risk assessment
identification

process. Section 5 discusses the continual evaluation process and keys for implementing a

successful risk

management program. The

determining whether the remaining risk

DAA or system authorizing official is responsible for

is at

an acceptable level or whether additional security

implemented to further reduce or eliminate the residual
accrediting) the IT system for operation.

controls should be

authorizing (or

Risk management

the process that allows IT

managers

risk before

to balance the operational

and

economic costs of protective measures and achieve gains in mission capability by protecting the
IT systems and data that support their organizations' missions. This process is not unique to the
IT environment; indeed it pervades decision-making in all areas of our daily lives. Take the case
of home security, for example. Many people decide to have home security systems installed and
pay a monthly fee to a service provider to have these systems monitored for the better protection
of their property. Presumably, the homeowners have weighed the cost of system installation and
monitoring against the value of their household goods and their family's safety, a fundamental
"mission" need.

The head of an
to

accomplish

their

organizational unit must ensure that the organization has the capabilities needed

its

mission. These mission owners must determine the security capabilities that

IT systems must have to provide the desired level of mission support in the face of real-

world

threats.

Most

organizations have tight budgets for IT security; therefore, IT security

spending must be reviewed as thoroughly as other management decisions.

management methodology, when used

effectively, can help

management

A well-structured risk

identify appropriate

controls for providing the mission-essential security capabilities.

2.2

INTEGRATION OF RISK MANAGEMENT INTO SDLC

Minimizing negative impact on an organization and need for sound basis in decision making are
the fundamental reasons organizations implement a risk management process for their IT
systems. Effective risk management must be totally integrated into the SDLC. An IT system's
SDLC has five phases: initiation, development or acquisition, implementation, operation or
maintenance, and disposal. In some cases, an IT system may occupy several of these phases at
the same time. However, the risk management methodology is the same regardless of the SDLC
phase for which the assessment is being conducted. Risk management is an iterative process that
can be performed during each major phase of the SDLC. Table 2-1 describes the characteristics

SP 800-30

Page 4

SDLC phase and indicates how risk management can be performed in

of each

support of each

phase.

Table 2-1 Integration of Risk Management into the

SDLC Phases

Phase Characteristics

SDLC
Support from

Risl(

l\/lanagement Activities

Phase

are used to
support the development of the
system requirements, including
security requirements, and a
security concept of operations

• Identified risks

—

Initiation

The need

system is
expressed and the purpose and
scope of the IT system is
for

documented

(strategy)

— Development or

Phase 2

Acquisition

•

The

system is designed,
purchased, programmed,
IT

The

risks identified during this

phase can be used

support
the security analyses of the IT
system that may lead to
architecture and design tradeoffs during system

developed, or otherwise
constructed

development

— Implementation

Phase 3

•

The system

security features

and

risk

management process

supports the assessment of the
system implementation against
its requirements and within its

should be configured, enabled,
tested,

The

verified

modeled operational
environment. Decisions
regarding risks identified must

be made

prior to

system

operation

Phase 4

—Operation or

Maintenance

•

The system performs

system
being modified on an ongoing

functions. Typically the

may

involve the

disposition of information,

hardware, and software.
Activities may include moving,
archiving, discarding, or

destroying information and
sanitizing the

software

hardware and

are

system

whenever

major changes are made to an
IT system in its operational,
production environment (e.g.,
new system interfaces)

•

This phase

activities

for periodic

reaccreditation) or

hardware and software and by
changes to organizational
processes, policies, and
procedures

—Disposal

management

reauthorization (or

basis through the addition of

Phase 5

Risk

performed

its

Risk

management

activities

are performed for system

components

that will be
disposed of or replaced to
ensure that the hardware and
software are properly disposed
of, that residual data is

appropriately handled, and that
system migration is conducted
in a secure and systematic

manner

SP 800-30

Page 5

2.3

KEY ROLES

Risk management
personnel

•

who

management

responsibility. This section describes the

key

roles of the

should support and participate in the risk management process.

Senior Management. Senior management, under the standard of due care and
ultimate responsibility for mission accomplishment, must ensure that the necessary
resources are effectively applied to develop the capabilities needed to accomplish the
mission. They must also assess and incorporate results of the risk assessment activity
into the decision

making process. An

effective risk

management program

that

assesses and mitigates IT-related mission risks requires the support and involvement

of senior management.
•

Chief Information Officer (CIO). The CIO is responsible for the agency's IT
planning, budgeting, and performance including its information security components.
Decisions made in these areas should be based on an effective risk management
program.

•

System and Information Owners. The system and information owners

are

responsible for ensuring that proper controls are in place to address integrity,
confidentiality,

and

availability of the

IT systems and data they own. Typically the

system and information owners are responsible for changes to their IT systems. Thus,
they usually have to approve and sign off on changes to their IT systems

enhancement, major changes

to the software

(e.g.,

system

and hardware). The system and

information owners must therefore understand their role in the risk management
process and fully support this process.
•

Business and Functional Managers. The managers responsible for business
operations and IT procurement process must take an active role in the risk
management process. These managers are the individuals with the authority and
responsibility for

making

the trade-off decisions essential to mission accomplishment.

Their involvement in the risk management process enables the achievement of proper
security for the IT systems, which, if

managed

properly, will provide mission

effectiveness with a minimal expenditure of resources.
•

ISSO. IT

•

IT Security Practitioners. IT

program managers and computer security officers are responsible
for their organizations' security programs, including risk management. Therefore,
they play a leading role in introducing an appropriate, structured methodology to help
identify, evaluate, and minimize risks to the IT systems that support their
organizations' missions. ISSOs also act as major consultants in support of senior
management to ensure that this activity takes place on an ongoing basis.
security

security practitioners (e.g., network, system,

and database administrators; computer specialists; security analysts;
security consultants) are responsible for proper implementation of security
requirements in their IT systems. As changes occur in the existing IT system
environment (e.g., expansion in network connectivity, changes to the existing
application,

and organizational policies, introduction of new technologies), the IT
security practitioners must support or use the risk management process to identify and
assess new potential risks and implement new security controls as needed to
safeguard their IT systems.

infrastructure

SP 800-30

Page 6

•

Security Awareness Trainers (Security/Subject Matter Professionals). The
organization's personnel are the users of the IT systems.

Use of the IT systems and

data according to an organization's policies, guidelines, and rules of behavior
critical to

risk to the

mitigating risk and protecting the organization's IT resources.

IT systems,

it is

essential that

To minimize

system and application users be provided

with security awareness training. Therefore, the IT security trainers or

must understand the risk management process so
they can develop appropriate training materials and incorporate risk assessment
training programs to educate the end users.

security/subject matter professionals
that

into

SP 800-30

Page 7

RISK ASSESSMENT

Risk assessment is the first process in the risk management methodology. Organizations use
assessment to determine the extent of the potential threat and the risk associated with an IT
system throughout

its

SDLC. The

output of this process helps to identify appropriate controls for

reducing or eliminating risk during the risk mitigation process, as discussed in Section

Risk

risk

a function of the likelihood of a given threat-source's exercising a particular potential

on the organization.

vulnerability,

and the resulting impact of

To determine

the likelihood of a future adverse event, threats to an IT system

that adverse event

in conjunction with the potential vulnerabilities

and the controls

must be analyzed

in place for the

IT system.

Impact refers to the magnitude of harm that could be caused by a threat's exercise of a
vulnerability. The level of impact is governed by the potential mission impacts and in turn
produces a relative value for the IT assets and resources affected (e.g., the criticality and
sensitivity of the

IT system components and

encompasses nine primary

steps,

—System

data).

The

which are described

risk assessment

in Sections 3.1

•

Step

•

Step 2

•

Step 3

^Vulnerability Identification (Section 3.3)

•

Step A

Control Analysis (Section 3.4)

•

Step 5

Likelihood

•

Step

•

Step 7

•

Step 8

•

Step 9

methodology

through 3.9

Characterization (Section 3.1)

—

^Threat Identification (Section 3.2)

—
—
Determination
—
6—Impact
—Risk Determination
Recommendations
—

(Section 3.5)

Analysis (Section 3.6)
(Section 3.7)

Control

—Results Documentation

(Section 3.8)

(Section 3.9).

and 6 can be conducted in parallel after Step 1 has been completed. Figure 3-1
depicts these steps and the inputs to and outputs from each step.
Steps

2, 3, 4,

SP 800-30

Pages

Input
•

Hardware

•

Software

Risk Assessment Activities

Output
•

Step

•

System

•

Data and information

•

People

interfaces

•

System Characterization

•

System Boundary
System Functions
System and Data
Criticality

^»

System mission
,

History of system attack

Data from intelligence

•

System and Data
Sensitivity

Step

Threat Identification

Threat Statement

NIPC, OIG.
FedCIRC, mass media.
agencies,

•

Reports from prior risk
assessments

•

Any

audit

Step

comments

•

Security requirements

•

Security test results

->|

List of Potential

Vulnerability Identification

Vulnerabilities

I
>

Current controls

Planned controls

• Threat-source
•

motivation

Threat capacity

•

Nahire of vulnerability

•

Current controls

Step

List of Current

Control Analysis

and

Planned Controls

—

I
Step

Likelihood Rating
1

Likelihood Determination

I
•

Asset criticality assessment

•

Data

•

Step

Mission impact analysis

•

Data

•

Impact Analysis
Impact Rating

Loss of Integrity

criticality
•

Loss of Availability

•

Loss of Confidentiality

sensitivity

Likelihood of threat
exploitation

Magnitude of impact

Adequacy of plaimed or

Step

Risks and

Risk Determination

Associated Risk
Levels

current controls

Step

Control Recommendations

Step

Results Documentation

—

Recommended
Controls

Risk Assessment
Report

Figure 3-1. Risk Assessment Methodology Flowchart

SP 800-30

Page 9

3.1

STEPl: SYSTEM CHARACTERIZATION

In assessing risks for an IT system, the first step is to define the scope of the effort. In this step,

the boundaries of the IT system are identified, along with the resources

and the information

that

constitute the system. Characterizing an IT system establishes the scope of the risk assessment
effort, delineates the operational authorization (or accreditation)

information

(e.g.,

boundaries, and provides

hardware, software, system connectivity, and responsible division or support

personnel) essential to defining the risk.

Section 3.1.1 describes the system-related information used to characterize an IT system and

its

operational environment. Section 3.1.2 suggests the information-gathering techniques that can

be used to

solicit

information relevant to the IT system processing environment.

The methodology described

in this

document can be applied

interrelated systems. In the latter case,

it is

and dependencies be well defined prior
3.1.1

to assessments of single or multiple,

important that the domain of interest and

to applying the

all

interfaces

methodology.

System-Related Information

Identifying risk for an IT system requires a keen understanding of the system's processing

environment. The person or persons

who conduct

system-related information, which

usually classified as follows:

•

Hardware

•

Software

•

System

•

Data and information

•

Persons

•

System mission

•

System and data

criticality (e.g., the

•

System and data

sensitivity.^

interfaces (e.g., internal

who

the risk assessment

must therefore

and external connectivity)

support and use the IT system
(e.g.,

the processes performed

by the IT system)

system's value or importance to an organization)

Additional information related to the operational environmental of the IT system and
includes, but

not limited

to,

its

data

the following:

•

The

•

Users of the system

functional requirements of the IT system
(e.g.,

system; application users
•

first collect

System security

system users

who

who provide

technical support to the IT

use the IT system to perform business functions)

policies governing the IT system (organizational policies, federal

requirements, laws, industry practices)
•

System security architecture

^ The level of protection required to maintain system and data integrity, confidentiality, and availability.

SP 800-30

Page 10

•

Current network topology

•

Information storage protection that safeguards system and data availability, integrity,

(e.g.,

network diagram)

and confidentiality
•

Flow of information

pertaining to the IT system

(e.g.,

system interfaces, system input

and output flowchart)
•

Technical controls used for the IT system

(e.g., built-in

or add-on security product

and authentication, discretionary or mandatory access
residual information protection, encryption methods)

that supports identification

control, audit,
•

Management

controls used for the IT system (e.g., rules of behavior, security

planning)
•

Operational controls used for the IT system

(e.g.,

personnel security, backup,

contingency, and resumption and recovery operations; system maintenance; off-site
storage; user account establishment

and deletion procedures; controls for segregation

of user functions, such as privileged user access versus standard user access)
•

Physical security environment of the IT system

(e.g., facility security,

data center

policies)
•

Environmental security implemented for the IT system processing environment

(e.g.,

controls for humidity, water, power, pollution, temperature, and chemicals).

system information can be derived from the
design or requirements document. For an IT system under development, it is necessary to define

For a system that

in the initiation or design phase,

key security rules and attributes planned for the future IT system. System design documents and
the system security plan can provide useful information about the security of an IT system that is
in development.

For an operational IT system, data is collected about the IT system in its production
environment, including data on system configuration, connectivity, and documented and
undocumented procedures and practices. Therefore, the system description can be based on the
security provided by the underlying infrastructure or on future security plans for the IT system.
3.1.2

Information-Gathering Techniques

Any, or a combination, of the following techniques can be used
to the IT system within its operational boundary:

•

Questionnaire.

in gathering information relevant

collect relevant information, risk assessment personnel can

develop a questionnaire concerning the management and operational controls planned
or used for the IT system. This questionnaire should be distributed to the applicable
technical and nontechnical

the IT system.

management personnel who

The questionnaire could

are designing or supporting

also be used during on-site visits

and

interviews.
•

On-site Interviews. Interviews with IT system support and management personnel
can enable risk assessment personnel to collect useful information about the IT

system

SP 800-30

(e.g.,

how

the system

operated and managed). On-site visits also allow risk

Page

assessment personnel to observe and gather information about the physical,
environmental, and operational security of the IT system. Appendix

sample interview questions asked during interviews with

site

A contains

personnel to achieve a

better understanding of the operational characteristics of an organization.

systems

still

in the design phase, on-site visit

For

would be face-to-face data gathering

exercises and could provide the opportunity to evaluate the physical environment in

•

which the IT system

will operate.

Document Review.

Policy documents

(e.g., legislative

documentation, directives),

system documentation (e.g., system user guide, system administrative manual,
system design and requirement document, acquisition document), and security-related
documentation

(e.g.,

previous audit report, risk assessment report, system

test results,

system security plan^, security policies) can provide good information about the
security controls used

by and planned

impact analysis or asset

and data

criticality

and

criticality

for the IT system.

organization's mission

assessment provides information regarding system

sensitivity.

Use of Automated Scanning Tool. Proactive

methods can be used to
collect system information efficiently. For example, a network mapping tool can
identify the services that run on a large group of hosts and provide a quick way of

•

technical

building individual profiles of the target IT system(s).

Information gathering can be conducted throughout the risk assessment process, from Step

(System Characterization) through Step 9 (Results Documentation).

Output from Step 1

—Characterization of

the

IT system

assessed, a

good picture of the IT

system environment, and delineation of system boundary
3.2

STEP 2: THREAT IDENTIFICATION

A threat is the potential for a particular threat-source to successfully exercise a particular
vulnerability. A vulnerability is a weakness that can
be accidentally triggered or intentionally exploited. A
threat-source does not present a risk

when

there

Threat: The potential for a threat-

vulnerability that can be exercised. In determining the

source to exercise (accidentally trigger

likelihood of a threat (Section 3.5), one must consider

or intentionally exploit) a specific

threat-sources, potential vulnerabilities (Section 3.3),

vulnerability.

and existing controls (Section
3.2.1

3.4).

Threat-Source Identification

The goal of this

step is to identify the potential

threat-sources and compile a threat statement
listing potential threat-sources that are applicable

to the IT

system being evaluated.

Threat-Source: Either

(1) intent

targeted at the intentional exploitation of a
vulnerability or (2) a situation
that

^ During the

SP 800-30

initial

and method

may

phase, a risk assessment could be used to develop the

and method

accidentally trigger a vulnerability.

initial

system security plan.

Page 12

A threat-source is defined as any
circumstance or event with the

harm

potential to cause

The common

system.

Common Threat-Sources

an IT

threat-

Natural Threats

sources can be natural, human, or

events.
«

important to consider

all

it is

to an

IT system and

Human Threats

—

and other such

^Events that are either enabled

by or

caused by human beings, such as unintentional acts

potential

(inadvertent data entry) or deliberate actions (network

threat-sources that could cause

harm

^Floods, earthquakes, tornadoes,

landslides, avalanches, electrical storms,

environmental.
In assessing threat-sources,

—

based attacks, malicious software upload, unauthorized

its

access to confidential information),

processing environment. For

Environmental Threats

example, although the threat

—Long-term power

failure,

pollution, chemicals, liquid leakage.

statement for an IT system
located in a desert

may not

include "natural flood" because

of the low likelihood of such an event's occurring, environmental threats such as a bursting pipe

can quickly flood a computer room and cause damage to an organization's IT assets and
resources.

Humans can be

threat-sources through intentional acts, such as deliberate attacks

malicious persons or disgruntled employees, or unintentional acts, such as negligence and errors.

A deliberate attack can be either (1) a malicious attempt to gain unauthorized access to an IT
system

(e.g.,

via password guessing) in order to

compromise system and data

integrity,

availability, or confidentiality or (2) a benign, but nonetheless purposeful, attempt to

system security. One example of the

latter

type of deliberate attack

circumvent

a programmer's writing a

Trojan horse program to bypass system security in order to "get the job done."

3.2.2

Motivation and Tlireat Actions

make humans potentially dangerous
an overview of many of today's common human threats, their

Motivation and the resources for carrying out an attack
threat-sources. Table 3-1 presents

possible motivations, and the methods or threat actions by which they might carry out an attack.

This information will be useful to organizations studying their

customizing their

human

threat environments

threat statements. In addition, reviews of the history of

ins; security violation reports; incident reports;

and

system break-

and interviews with the system administrators,

community during information gathering will help identify human
potential to harm an IT system and its data and that may be a concern

help desk personnel, and user
threat-sources that have the

where a vulnerability

SP800-30

exists.

Page 13

Table

Human Threats:

3-1.

Threat-Source

Threat-Source, Motivation, and Threat Actions

Challenge
Hacker, cracker

Threat Actions

Motivation

Ego
Rebellion

•

Hacking

•

Social engineering

•

System

•

Unauthorized system access

•

Computer crime

•

information Hicolociiro

Computer criminal
Monetary gain
Unauthorized data alteration

Blackmail
Destruction

cyber

Fraudulent act (e.g., replay,
impersonation, interception)

•

Information bribery

•

Spoofing

•

System

•

Bomb/Terrorism

•

Information warfare

•

Terrorist

intrusion

System attack

(e.g., distributed

denial of service)

Exploitation
•

System penetration
System tampering

•

Economic

•

Information theft

•

Intrusion

•

Social engineering

•

System penetration
Unauthorized system access

•

Revenge

espionage
(companies, foreign
novprnmpnt^
nthpr
UWUI 1^1 IIO, V/il
Iwl
government interests)

(e.g.,

stalking)

Destruction of information
lllonf)!

intrusion, break-ins

exploitation

on personal privacy

Industrial

Competitive advantage

Economic espionage

•

(access to classified, proprietary,
and/or technology-related
information)
•

Assault on an employee

•

Blackmail

•

Browsing

of proprietary

information

Curiosity

•

Computer abuse
Fraud and theft

Intelligence

•

Information bribery

disgruntled, malicious,

Monetary gain

•

Input of falsified, corrupted data

negligent, dishonest, or
terminated employees)

Revenge

•

Interception

•

Malicious code

•

Sale of personal information

•

System bugs

•

System

•

System sabotage
Unauthorized system access

•

Ego
Insiders (poorly trained,

Unintentional errors

omissions
error,

(e.g.,

and

data entry

programming

bomb, Trojan horse)

error)

•

An estimate of the

(e.g., virus, logic

motivation, resources, and capabilities that

intrusion

may be

required to carry out a

successful attack should be developed after the potential threat-sources have been identified, in

order to determine the likelihood of a threat's exercising a system vulnerability, as described in

Section 3.5.

SP 800-30

Page 14

The

threat statement, or the list of potential threat-sources, should

organization and

processing environment

its

information on natural threats

Known

(e.g., floods,

(e.g.,

be tailored to the individual

end-user computing habits). In general,

earthquakes, storms) should be readily available.

have been identified by many government and private sector organizations.
Intrusion detection tools also are becoming more prevalent, and government and industry
organizations continually collect data on security events, thereby improving the ability to
realistically assess threats. Sources of information include, but are not limited to, the following:
threats

Intelligence agencies (for example, the Federal

•

Bureau of Investigation's National

Infrastructure Protection Center)
•

Federal Computer Incident Response Center (FedCIRC)

•

Mass media,

Web-based resources such as SecurityFocus.com,
SecurityWatch.com, SecurityPortal.com, and SANS.org.

Output from Step 2

particularly

—A threat statement containing a

list

of threat-sources that could exploit

system vulnerabilities

3.3

The

STEP 3: VULNERABILITY IDENTIFICATION
analysis of the threat to an IT system

must include an analysis of the
vulnerabilities associated with the

list

internal controls that

(accidentally triggered or intentionally exploited)

and

(flaws or weaknesses) that could be

exploited by the potential threat-sources.

Terminated employees' system
identifiers (ED) are not

result in a security breach or a violation of the

system's security poUcy.

Table 3-2 presents examples of vulnerability/threat

Vulnerability

pairs.

3-2. Vulnerability/Threat Pairs

telnet,

Threat Action

Threat-Source
Terminated employees

removed

Dialing into the company's

network and accessing

company

from the system

Company

could be exercised

is to

of system vulnerabilities

Table

A flaw or weakness in system

security procedures, design, implementation, or

system

environment. The goal of this step

develop a

Vulnerability:

firewall allows inbound

and guest YD

enabled on

XYZ server

proprietary data

hackers, terminated

Using telnet to XYZ server
and browsing system files

employees, computer

with the guest ID

Unauthorized users

(e.g.,

criminals, terrorists)

The vendor has

identified flaws in

Unauthorized users

(e.g.,

Obtaining unauthorized

the security design of the system;

hackers, disgruntled

access to sensitive system

however, new patches have not
been applied to the system

employees, computer

files

criminals, terrorists)

SP 800-30

based on known
system vulnerabilities

Page 15

Threat Action

Threat-Source

Vulnerability

Data center uses water sprinklers

Fire, negligent persons

Water

sprinklers being

turned on in the data center

to suppress fire; tarpaulins to

protect hardware and equipment

from water damage are not

place

Recommended methods

for identifying system vulnerabilities are the use of vulnerability

sources, the performance of system security testing, and the development of a security

requirements checklist.

and the methodology needed to
usually vary depending on the nature of

should be noted that the types of vulnerabilities that will

determine whether the vulnerabilities are present, will
the IT system and the phase

•

it is

in, in

the

exist,

SDLC:

IT system has not yet been designed, the search for vulnerabilities should focus
on the organization's security policies, planned security procedures, and system
If the

requirement definitions, and the vendors' or developers' security product analyses

•

(e.g.,

white papers).

If the

IT system

expanded

being implemented, the identification of vulnerabilities should be

to include

specific information, such as the planned security features

described in the security design documentation and the results of system certification
test

•

and evaluation.

IT system is operational, the process of identifying vulnerabilities should
include an analysis of the IT system security features and the security controls,
If the

technical and procedural, used to protect the system.

3.3.1

The

Vulnerability Sources

technical and nontechnical vulnerabilities associated with an IT system's processing

environment can be identified via the information-gathering techniques described in Section
3.1.2. A review of other industry sources (e.g., vendor Web pages that identify system bugs and
flaws) will be useful in preparing for the interviews and in developing effective questionnaires to
identify vulnerabilities that

may be

specific operating system).

The

vulnerabilities posted

applicable to specific IT systems (e.g., a specific version of a

by vendors, along with hot

remedial measures that

may be

on known system
service packs, patches, and other

Internet is another source of information
fixes,

applied to eliminate or mitigate vulnerabilities.

Documented

vulnerability sources that should be considered in a thorough vulnerability analysis include, but
are not limited to, the following:

•

Previous risk assessment documentation of the IT system assessed

•

The IT system's
system

•

test

audit reports, system

anomaly

reports, security

review reports, and

and evaluation reports

Vulnerability

lists,

such as the

NIST I-CAT

vulnerability database

(http://icat.nist.gov)

SP 800-30

Page 16

FedCIRC and

Security advisories, such as

•

the

Department of Energy's Computer

Incident Advisory Capability bulletins

3.3.2

•

Vendor advisories

•

Commercial computer incident/emergency response teams and post
SecurityFocus.com forum mailings)

•

Information Assurance Vulnerability Alerts and bulletins for military systems

•

System software security analyses.

lists (e.g.,

System Security Testing

Proactive methods, employing system testing, can be used to identify system vulnerabilities
efficiently,

depending on the

criticality

of the IT system and available resources

(e.g.,

funds, available technology, persons with the expertise to conduct the test). Test

allocated

methods

include

•

Automated

•

Security test and evaluation

•

Penetration

vulnerability scanning tool

(ST&E)

testing.*^

The automated vulnerability scanning tool is used to scan a group of hosts or a network for
known vulnerable services (e.g., system allows anonymous File Transfer Protocol [FTP],
sendmail relaying). However, it should be noted that some of the potential vulnerabilities
identified by the automated scanning tool may not represent real vulnerabilities in the context of
the system environment. For example, some of these scanning tools rate potential vulnerabilities
without considering the

site's

environment and requirements.

may

flagged by the automated scanning software

may be configured that way because
may produce false positives.
but

ST&E is

their

Some

of the "vulnerabilities"

actually not be vulnerable for a particular site

environment requires

it.

Thus,

this test

method

another technique that can be used in identifying IT system vulnerabilities during the

risk assessment process.
script, test

includes the development and execution of a test plan

procedures, and expected test results).

test the effectiveness

The purpose of system

(e.g., test

security testing

is to

of the security controls of an IT system as they have been applied in an

operational environment.

The

objective

is to

ensure that the applied controls meet the approved

security specification for the software and hardware

and implement the organization's security

policy or meet industry standards.

Penetration testing can be used to

complement

the review of security controls

and ensure

that

IT system are secured. Penetration testing, when employed in the risk
assessment process, can be used to assess an IT system's ability to withstand intentional attempts
to circumvent system security. Its objective is to test the IT system from the viewpoint of a
different facets of the

threat-source and to identify potential failures in the IT system protection schemes.

The NIST SP
testing

draft 800-42, Network Security Testing Overview, describes the methodology
and the use of automated tools.

SP 800-30

for

network system

Page 17

The

results of these types of optional security testing will help identify a system's vulnerabilities.

3.3.3

Development of Security Requirements

Cliecklist

assessment personnel determine whether the security requirements
stipulated for the IT system and collected during system characterization are being met by

During

this step, the risk

existing or planned security controls. Typically, the system security requirements can be

presented in table form, with each requirement accompanied by an explanation of

how

the

system's design or implementation does or does not satisfy that security control requirement.

A security requirements checklist contains the basic security standards that can be used to
systematically evaluate and identify the vulnerabilities of the assets (personnel, hardware,
software, information), nonautomated procedures, processes, and information transfers

associated with a given IT system in the following security areas:

•

Management

•

Operational

•

Technical.

Table 3-3

lists

security criteria suggested for use in identifying an IT system's vulnerabilities in

each security area.

Table

3-3. Security Criteria

Security Area

Management Security

Operational Security

Security Criteria

•

Assignment

•

Continuity of support

•

Incident response capability

•

Periodic review of security controls

•

Personnel clearance and background investigations

•

Risk assessment

•

Security and technical training

•

Separation of duties

•

System authorization and reauthorization

•

System

•

Control of air-borne contaminants (smoke, dust, chemicals)

•

Controls to ensure the quality of the electrical power supply

•

Data media access and disposal

•

External data distribution

• Facility

SP 800-30

of responsibilities

or application security plan

protection (e.g.,

and

labeling

computer room, data center,

office)

•

Humidity control

•

Temperature control

•

Workstations, laptops, and stand-alone personal computers

Page 18

Security Area

Security Criteria

Technical Security

•

Communications

•

Cryptography

•

Discretionary access control

(e.g., dial-in,

system interconnection, routers)

and authentication

• Identification
•

Intrusion detection

•

Object reuse

•

System

audit

The outcome of this process is the security requirements checklist. Sources that can be used in
compiUng such a checklist include, but are not limited to, the following government regulatory
and security directives and sources applicable

to the

IT system processing environment:

•

CSA of

•

Federal Information Processing Standards Publications

•

OMB November 2000 Circular A- 130

•

Privacy Act of 1974

•

System security plan of the IT system assessed

•

The

•

Industry practices.

1987

organization's security policies, guidelines, and standards

The NIST SP 800-26,

Security Self-Assessment Guide for Information Technology Systems,

provides an extensive questionnaire containing specific control objectives against which a

system or group of interconnected systems can be tested and measured. The control objectives
are abstracted directly

security

The

from long-standing requirements found

in statute, policy,

and guidance on

and privacy.

results of the checklist (or questionnaire)

can be used as input for an evaluation of

compliance and noncompliance. This process identifies system, process, and procedural

weaknesses

that represent potential vulnerabilities.

Output from Step 3

—A

list

of the system vulnerabilities (observations)"^ that could be exercised

by the potential threat-sources
3.4

STEP 4: CONTROL ANALYSIS

The goal of this

step

is to

analyze the controls that have been implemented, or are planned for

implementation, by the organization to minimize or eliminate the likelihood (or probability) of a
threat's exercising a

Because the

system vulnerability.

risk assessment report is not an audit report,

some

sites

may prefer to

address the identified

vulnerabiUties as observations instead of findings in the risk assessment report.

SP 800-30

Page 19

To derive an overall likelihood rating that indicates the probability that a potential vulnerability
may be exercised within the construct of the associated threat environment (Step 5 below), the
implementation of current or planned controls must be considered. For example, a vulnerability
(e.g., system or procedural weakness) is not likely to be exercised or the likelihood is low if there
is

low

level of threat-source interest or capability or if there are effective security controls that

can eliminate, or reduce the magnitude

of,

harm.

Sections 3.4.1 through 3.4.3, respectively, discuss control methods, control categories, and the
control analysis technique.

3.4.1

Control Methods

Security controls encompass the use of technical and nontechnical methods. Technical controls

computer hardware, software, or firmware (e.g., access
control mechanisms, identification and authentication mechanisms, encryption methods,
intrusion detection software). Nontechnical controls are management and operational controls,
such as security policies; operational procedures; and personnel, physical, and environmental
are safeguards that are incorporated into

security.

3.4.2

The

Control Categories

control categories for both technical and nontechnical control methods can be further

classified as either preventive or detective.
•

These two subcategories are explained as follows:

Preventive controls inhibit attempts to violate security policy and include such
controls as access control enforcement, encryption, and authentication.

•

Detective controls warn of violations or attempted violations of security policy and
include such controls as audit

trails,

intrusion detection methods, and checksums.

Section 4.4 further explains these controls from the implementation standpoint.

implementation of such controls during the risk mitigation process

The

the direct result of the

identification of deficiencies in current or planned controls during the risk assessment process
(e.g.,

3.4.3

controls are not in place or controls are not properly implemented).

Control Analysis Technique

As discussed

development of a security requirements checklist or use of an
available checklist will be helpful in analyzing controls in an efficient and systematic manner.
The security requirements checklist can be used to validate security noncompliance as well as
compliance. Therefore, it is essential to update such checklists to reflect changes in an
organization's control environment (e.g., changes in security policies, methods, and
in Section 3.3.3,

requirements) to ensure the checklist's validity.

—

Output from Step 4 List of current or planned controls used for the IT system to mitigate the
likelihood of a vulnerability's being exercised and reduce the impact of such an adverse event

SP 800-30

Page 20

STEPS: LIKELIHOOD DETERMINATION

3.5

The

•

Threat-source motivation and capability

•

Nature of the vulnerability

•

Existence and effectiveness of current controls.

likelihood that a potential vulnerability could be exercised

a given threat-source can be

described as high, medium, or low. Table 3-4 below describes these three likelihood levels.

Table

3-4. Likelihood Definitions

Likelihood Level

Likelihood Definition

The

High

threat-source

highly motivated

and

sufficiently capable,

and controls

prevent the vulnerability from being exercised are ineffective.

Medium

The

threat-source

motivated and capable, but controls are
of the vulnerability.

place that

may

impede successful exercise

Low

The

place to
prevent, or at least significantly impede, the vulnerability from being exercised.

Output from Step 5
3.6

threat-source lacks motivation or capability, or controls are

—Likelihood rating

(High,

Medium, Low)

STEP 6: IMPACT ANALYSIS

The next major

step in measuring level of risk

is to

determine the adverse impact resulting from

a successful threat exercise of a vulnerability. Before beginning the impact analysis,

it is

necessary to obtain the following necessary information as discussed in Section 3.1.1:
the processes performed

•

System mission

•

System and data

criticality (e.g., the

•

System and data

sensitivity.

(e.g.,

by the IT system)

system's value or importance to an organization)

This information can be obtained from existing organizational documentation, such as the
mission impact analysis report or asset
(also

known

criticality

assessment report.

as business impact analysis [BIA] for

levels associated with the

some

A mission impact analysis

organizations) prioritizes the impact

compromise of an organization's information

qualitative or quantitative assessment of the sensitivity

and

criticality

assets

based on a

of those assets.

asset

assessment identifies and prioritizes the sensitive and critical organization information
assets (e.g., hardware, software, systems, services, and related technology assets) that support the

criticality

organization's critical missions.

SP 800-30

Page 21

documentation does not exist or such assessments for the organization's IT assets have not
been performed, the system and data sensitivity can be determined based on the level of
If this

protection required to maintain the system and data's availability, integrity, and confidentiality.

Regardless of the method used to determine

how

sensitive an IT system

and

its

data are, the

system and information owners are the ones responsible for determining the impact level for
their own system and information. Consequently, in analyzing impact, the appropriate approach
is

to interview the

system and information owner(s).

Therefore, the adverse impact of a security event can be described in terms of loss or degradation

of any, or a combination of any, of the following three security goals: integrity, availability, and
confidentiality.

The following

list

provides a brief description of each security goal and the

consequence (or impact) of its not being met:
•

Loss of Integrity. System and data integrity refers to the requirement that
information be protected from improper modification. Integrity is lost if unauthorized
changes are made to the data or IT system by either intentional or accidental acts. If
the loss of system or data integrity is not corrected, continued use of the contaminated
system or corrupted data could result in inaccuracy, fraud, or erroneous decisions.
Also, violation of integrity may be the first step in a successful attack against system
availability or confidentiality. For all these reasons, loss of integrity reduces the
assurance of an IT system.

•

Loss of Availability.

If a mission-critical

the organization's mission

may be

operational effectiveness, for example,

impeding the end

users'

IT system is unavailable to its end users,
Loss of system functionality and

affected.

may

performance of

result in loss of productive time, thus

their functions in supporting the

organization's mission.
•

Loss of Confidentiality. System and data confidentiality refers to the protection of
information from unauthorized disclosure. The impact of unauthorized disclosure of
confidential information can range from the jeopardizing of national security to the
disclosure of Privacy Act data. Unauthorized, unanticipated, or unintentional
disclosure could result in loss of public confidence, embarrassment, or legal action
against the organization.

Some

tangible impacts can be measured quantitatively in lost revenue, the cost of repairing the

system, or the level of effort required to correct problems caused by a successful threat action.

Other impacts
interest)

(e.g., loss

of public confidence, loss of credibility,

damage

to an organization's

cannot be measured in specific units but can be qualified or described in terms of high,

medium, and low impacts. Because of the generic nature of this discussion, this guide designates
and describes only the qualitative categories high, medium, and low impact (see Table 3.5).

—

SP 800-30

Page 22
\

Table

3-5.

Magnitude of Impact DeHnitions

Magnitude of
Impact

impact Definition
Exercise of tlie vulnerability (1) may result in the highly costly loss of
major tangible assets or resources; (2) may significantly violate, harm, or
impede an organization's mission, reputation, or interest; or (3) may result
in human death or serious injury.

High

Exercise of the vulnerability (1) may result in the costly loss of tangible
assets or resources; (2) may violate, harm, or impede an organization's

Medium

mission, reputation, or interest; or (3)

may

result in

human

injury.

Exercise of the vulnerability (1) may result in the loss of some tangible
assets or resources or (2) may noticeably affect an organization's

Low

mission, reputation, or interest.

Quantitative versus Qualitative Assessment

be given to the advantages and

In conducting the impact analysis, consideration should

disadvantages of quantitative versus qualitative assessments. The main advantage of the
qualitative impact analysis is that

improvement
that

prioritizes the risks

in addressing the vulnerabilities.

and

identifies areas for

The disadvantage of the

immediate

qualitative analysis is

does not provide specific quantifiable measurements of the magnitude of the impacts,

therefore

making a

cost-benefit analysis of any

The major advantage of a

recommended controls

quantitative impact analysis

that

difficult.

provides a measurement of the

impacts' magnitude, which can be used in the cost-benefit analysis of recommended controls.

The disadvantage is that, depending on the numerical ranges used to express the measurement,
the meaning of the quantitative impact analysis may be unclear, requiring the result to be
interpreted in a qualitative manner. Additional factors often must be considered to determine the
magnitude of impact. These
•

An estimation

may

include, but are not limited to

of the frequency of the threat-source's exercise of the vulnerability

over a specified time period
•

(e.g., 1

year)

approximate cost for each occurrence of the threat-source's exercise of the

vulnerability
•

A weighted factor based on a subjective analysis of the relative impact of a specific
threat's exercising a specific vulnerability.

Output from Step 6

SP 800-30

—Magnitude of impact

(High, Medium, or

Low)

Page 23

STEP 7: RISK DETERMINATION

3.7

The purpose of this

step

to assess the level of risk to the

IT system. The determination of risk

for a particular threat/vulnerability pair can be expressed as a function of

The

•
•

likelihood of a given threat-source's attempting to exercise a given vulnerability

The magnitude of the impact should

a threat-source successfully exercise the

vulnerability
•

The adequacy of planned or

existing security controls for reducing or eliminating

risk.

To measure

risk,

a risk scale and a risk-level matrix must be developed. Section 3.7.1 presents a

standard risk-level matrix; Section 3.7.2 describes the resulting risk levels.

3.7.1

The

Risk-Level Matrix

final determination

of mission risk

derived by multiplying the ratings assigned for threat

and threat impact. Table 3.6 below shows how the overall risk
ratings might be determined based on inputs from the threat likelihood and threat impact
categories. The matrix below is a 3 x 3 matrix of threat likelihood (High, Medium, and Low)
and threat impact (High, Medium, and Low). Depending on the site's requirements and the
likelihood

(e.g.,

probability)

granularity of risk assessment desired,

Low /Very High

some

sites

may

use

a4x4ora5x5 matrix.

The

latter

and a Very Low/Very High threat impact
generate a Very LowA^ery High risk level. A "Very High" risk level may require possible
system shutdown or stopping of all IT system integration and testing efforts.
can include a Very

threat likelihood

The sample matrix in Table 3-6 shows how the
derived. The determination of these risk levels
this justification

level

Medium, and Low are
may be subjective. The rationale for

overall risk levels of High,

or ratings

can be explained in terms of the probability assigned for each threat likelihood

and a value assigned for each impact
•

The probability assigned
Medium, 0.1 for Low

•

The value assigned
Low.

SP 800-30

level.

For example,

for each threat likelihood level is 1.0 for High, 0.5 for

for each impact level

100 for High, 50 for Medium, and 10 for

Page 24

Table

Matrix

3-6. Risk-Level

Impact
Threat
Likelihood

High{^.0)

Low

Medium

Higli

(10)

(50)

(100)

Low

Medium

High

50 X

10X1.0 = 10

100 X 1.0 = 100

= 50

Low

Medium

10X0.5 = 5

50 X 0.5 = 25

100X0.5 = 50

Low

50X0.1 = 5

100X0.1 = 10

Medium (0.5)

Low (0.1)

10X0.1 =

Risk Scale: High (>50 to 100); Medium (>10to 50);

3.7.2

Low (1

to 10)^

Description of Risk Level

Table 3-7 describes the risk levels shown in the above matrix. This risk scale, with

its

High, Medium, and Low, represents the degree or level of risk to which an IT system,

procedure might be exposed
actions that senior

a given vulnerability were exercised.

The

management, the mission owners, must take for each

Table

3-7.

ratings of
facility,

risk scale also presents

risk level.

Risk Scale and Necessary Actions
Risk Description and Necessary Actions

Risk Level
If

an observation or finding

evaluated as a

strong need for corrective measures.

High

higli risk,

there

existing systenn

may

continue to operate, but a corrective action plan must be put

place

as soon as possible.
an observation is rated as medium risk, corrective actions are
needed and a plan must be developed to incorporate these actions
within a reasonable period of time.
If

Medium

If an observation is described as low risk, the system's DAA must
determine whether corrective actions are still required or decide to
accept the risk.

Low

—Risk

Output from Step 7

If the level indicated

will

make

sure that they are not overlooked

when conducting

the next periodic risk

These risks may move to a
likelihood and/or impact and that is why it is critical

also establishes a complete record of all risks identified in the analysis.

new risk level on

a reassessment due to a change in threat

that their identification not

SP 800-30

Medium, Low)

on certain items is so low as to be deemed to be "negligible" or non significant (value
100), one may wish to hold these aside in a separate bucket in lieu of forwarding for

on risk scale of 1 to
management action. This
assessment.

level (High,

lost in the exercise.

Page 25

STEPS:

3.8

During

CONTROL RECOMMENDATIONS

this step

of the process, controls that could mitigate or eliminate the identified risks, as

appropriate to the organization's operations, are provided.
controls

is to

reduce the level of risk to the IT system and

The goal of the recommended
its

data to an acceptable level.

The

following factors should be considered in recommending controls and alternative solutions to

minimize or eliminate identified

The

risks:

recommended options

•

Effectiveness of

•

Legislation and regulation

•

Organizational policy

•

Operational impact

•

Safety and reliability.

system compatibility)

control recommendations are the results of the risk assessment process and provide input to

the risk mitigation process, during

controls are evaluated, prioritized,

(e.g.,

should be noted that not

To determine which ones

all

which the recommended procedural and technical security
and implemented.

possible

recommended

controls can be

implemented

to reduce loss.

and appropriate for a specific organization, a cost-benefit
analysis, as discussed in Section 4.6, should be conducted for the proposed recommended
controls, to demonstrate that the costs of implementing the controls can be justified by the
reduction in the level of risk. In addition, the operational impact (e.g., effect on system
performance) and feasibility (e.g., technical requirements, user acceptance) of introducing the
are required

recommended option should be evaluated
Output from Step 8

3.9

Once

carefully during the risk mitigation process.

—Recommendation of control(s) and alternative solutions

to mitigate risk

STEP 9: RESULTS DOCUMENTATION
the risk assessment has been completed (threat-sources and vulnerabilities identified, risks

assessed, and

recommended

controls provided), the results should be

documented

in an official

report or briefing.

A risk assessment report is a management report that helps senior management, the mission
owners,

make

decisions on policy, procedural, budget, and system operational and

management

changes. Unlike an audit or investigation report, which looks for wrongdoing, a risk assessment

manner but as a systematic and analytical
approach to assessing risk so that senior management will understand the risks and allocate
resources to reduce and correct potential losses. For this reason, some people prefer to address
report should not be presented in an accusatory

the threat/vulnerability pairs as observations instead of findings in the risk assessment report.

Appendix

provides a suggested outline for the risk assessment report.

—

Output from Step 9 Risk assessment report that describes the threats and vulnerabilities,
measures the risk, and provides recommendations for control implementation

SP 800-30

Page 26

RISK MITIGATION

Risk mitigation, the second process of risk management, involves prioritizing, evaluating, and
implementing the appropriate risk-reducing controls recommended from the risk assessment
process.

Because the elimination of

all risk is

usually impractical or close to impossible,

it is

the

management and functional and business managers to use the least-cost
approach and implement the most appropriate controls to decrease mission risk to an acceptable
level, with minimal adverse impact on the organization's resources and mission.
responsibility of senior

This section describes risk mitigation options (Section 4.1), the risk mitigation strategy (Section
4.2),

an approach for control implementation (Section 4.3), control categories (Section 4.4), the

cost-benefit analysis used to justify the implementation of the
4.5),

and residual

4.1

RISK MITIGATION OPTIONS

Risk mitigation

recommended

controls (Section

risk (Section 4.6).

a systematic methodology used by senior

management

to reduce mission risk.

Risk mitigation can be achieved through any of the following risk mitigation options:
•

Risk Assumption. To accept the potential risk and continue operating the IT system
or to implement controls to lower the risk to an acceptable level

•

Risk Avoidance. To avoid the
(e.g.,

risk

by eliminating the

forgo certain functions of the system or shut

risk cause and/or

down

the system

consequence

when

risks are

identified)
•

Risk Limitation. To

limit the risk

by implementing controls

adverse impact of a threat's exercising a vulnerability

(e.g.,

that

minimize the

use of supporting,

preventive, detective controls)
•

Risk Planning. To manage risk by developing a
implements, and maintains controls

•

Research and Acknowledgment. To lower the risk of loss by acknowledging the
vulnerability or flaw and researching controls to correct the vulnerability

•

Risk Transference. To
loss,

transfer the risk

risk mitigation plan that prioritizes,

by using other options

compensate for the

such as purchasing insurance.

The goals and mission of an organization should be considered
mitigation options.

may

not be practical to address

all

in selecting

any of these

risk

identified risks, so priority should be

given to the threat and vulnerability pairs that have the potential to cause significant mission

impact or harm. Also, in safeguarding an organization's mission and

its

IT systems, because of

each organization's unique environment and objectives, the option used to mitigate the risk and

implement controls may vary. The "best of breed" approach is to use
appropriate technologies from among the various vendor security products, along with the
appropriate risk mitigation option and nontechnical, administrative measures.

the

methods used

SP 800-30

Page 27

4.2

RISK MITIGATION STRATEGY

Senior management, the mission owners, knowing the potential risks and recommended controls,

may

ask,

"When and under what

circumstances should

take action?

When

shall I

implement

these controls to mitigate the risk and protect our organization?"

The

risk mitigation chart in Figure 4-1 addresses these questions. Appropriate points for

implementation of control actions are indicated in

this figure

the

word YES.

1&
Unacceptable
Risk

Figure 4-1. Risk Mitigation Action Points
This strategy

further articulated in the following rules of thumb,

actions to mitigate risks

•

from

intentional

human

which provide guidance on

threats:

When vulnerability (or flaw, weakness) exists —

implement assurance techniques

to reduce the likelihood of a vulnerability's being exercised.

•

When a vulnerability can be exercised —

apply layered protections, architectural

designs, and administrative controls to minimize the risk of or prevent this

occurrence.
•

When the attacker's cost is less than the potential gain ->

apply protections to

decrease an attacker's motivation by increasing the attacker's cost
controls such as limiting what a system user can access and

do can

(e.g.,

use of system

significantly

reduce an attacker's gain).
•

When loss is too great —

apply design principles, architectural designs, and

technical and nontechnical protections to limit the extent of the attack, thereby

reducing the potential for

The

loss.

strategy outlined above, with the exception of the third

is less

list

item ("When the attacker's cost

than the potential gain"), also applies to the mitigation of risks arising from environmental

SP 800-30

Page 28

or unintentional

human

motivation or gain

4.3

threats (e.g.,

system or user

errors).

(Because there

no "attacker," no

involved.)

APPROACH FOR CONTROL IMPLEMENTATION

When control

actions

must be taken, the following

rule applies:

Address the greatest risks and strive for sufficient risk mitigation at the lowest
minimal impact on other mission capabilities.

The following
•

risk mitigation

Step

methodology describes the approach

to control

cost, with

implementation:

—

Prioritize Actions

Based on the

risk levels presented in the risk assessment report, the implementation

actions are prioritized. In allocating resources, top priority should be given to risk

items with unacceptably high risk rankings

(e.g., risk

assigned a Very High or High

These vulnerability/threat pairs will require immediate corrective action
protect an organization's interest and mission.

risk level).
to

Output from Step
•

—Actions ranking from High to Low

—Evaluate Recommended Control Options

Step 2

The

controls

recommended

in the risk

assessment process

may

not be the most

appropriate and feasible options for a specific organization and IT system. During
this step, the feasibility (e.g., compatibility, user

acceptance) and effectiveness

(e.g.,

degree of protection and level of risk mitigation) of the recommended control options
are analyzed.

minimizing

The

objective

—Conduct

Step 3

aid

select the

most appropriate control option for

risk.

—List offeasible controls

Output from Step 2
•

is to

Cost-Benefit Analysis

management

benefit analysis

in decision

making and

to identify cost-effective controls, a cost-

conducted. Section 4.5 details the objectives and method of

conducting the cost-benefit analysis.

—

Output from Step 3 Cost-benefit analysis describing the cost and benefits of
implementing or not implementing the controls
•

Step 4

—

Select Control

management determines the
most cost-effective control(s) for reducing risk to the organization's mission. The
controls selected should combine technical, operational, and management control
the basis of the results of the cost-benefit analysis,

elements to ensure adequate security for the IT system and the organization.

Output from Step 4

SP 800-30

—Selected

control(s)

Page 29

•

Step 5

—Assign

Responsibility

Appropriate persons (in-house personnel or external contracting

who have

staff)

the

appropriate expertise and skill-sets to implement the selected control are identified,

and responsibility

—List of responsible persons

Output from Step 5
•

—Develop

Step 6

During

a Safeguard Implementation Plan

this step, a

plan should, at a

assigned.

safeguard implementation plan^ (or action plan)

minimum, contain

developed.

The

the following information:

Risks (vulnerability/threat pairs) and associated risk levels (output from risk

assessment report)

Recommended

Prioritized actions (with priority given to items with

controls (output

from

risk assessment report)

Very High and High

risk

levels)

Selected planned controls (determined on the basis of feasibility, effectiveness,
benefits to the organization, and cost)

Required resources for implementing the selected planned controls

Lists of responsible teams

Start date for implementation

Target completion date for implementation

Maintenance requirements.

and

staff

The safeguard implementation plan

prioritizes the

implementation actions and

projects the start and target completion dates. This plan will aid and expedite the risk

mitigation process. Appendix

provides a sample

summary

table for the safeguard

implementation plan.

—Safeguard implementation plan

Output from Step 6
•

—

Step 7

^Implement Selected Control(s)

Depending on individual

situations, the

implemented controls may lower the

risk

level but not eliminate the risk. Residual risk is discussed in Section 4.6.

—Residual

Output from Step 7

risk

Figure 4-2 depicts the recommended methodology for risk mitigation.

NIST

Interagency Report 4749, Sample Statements of Work for Federal Computer Security Services: For Use InOut. December 1991.

House or Contracting

SP 800-30

Page 30

Risk Mitisation Activities

Input

Output

r
•

Step

Risk levels from the
risk assessment

report

High

Low

I
Step

N
•

Actions ranking from

Prioritize Actions

Evaluate Recommended
Control Options

Risk assessment
report

•

Feasibility

•

Effectiveness

Step

List of possible

controls

Conduct Cost-Benefit Analysis
•

Impact of implanaiting

•

Impact of not implementing

•

Associated costs

Cost -benefit
analysis

Selected Controls

Step

List of
5.

responsible persons

Assign Responsibility

I
6. Develop Safeguard
Implementation Plan

Step

•

Risks and Associated Risk Levels

•

Prioritized Actions

•

Recommended Controls

•

Selected Planned Controls

•

Responsible Persons

• Start

Safeguard

implementation plan

Date

•

Target Completion Date

•

Maintenance Requirements

I
Step

Implement Selected

Residual Risks

Controls

Figure 4-2. Risk Mitigation Methodology Flowchart

SP 800-30

Page 31

CONTROL CATEGORIES

4.4

In implementing
technical,

recommended

controls to mitigate risk, an organization should consider

management, and operational security

maximize the effectiveness of controls

when used

controls, or a combination of such controls, to

for their IT systems

and organization. Security controls,

appropriately, can prevent, limit, or deter threat-source

damage

to an organization's

mission.

recommendation process will involve choosing among a combination of technical,
management, and operational controls for improving the organization's security posture. The
trade-offs that an organization will have to consider are illustrated by viewing the decisions
involved in enforcing use of complex user passwords to minimize password guessing and
cracking. In this case, a technical control requiring add-on security software may be more
complex and expensive than a procedural control, but the technical control is likely to be more
effective because the enforcement is automated by the system. On the other hand, a procedural
control might be implemented simply by means of a memorandum to all concerned individuals
and an amendment to the security guidelines for the organization, but ensuring that users
consistently follow the memorandum and guideline will be difficult and will require security
awareness training and user acceptance.

The

control

More detailed
guidance about implementing and planning for IT controls can be found in NIST SP 800-18,
Guide for Developing Security Plans for Information Technology Systems, and NIST SP 800-12,
An Introduction to Computer Security: The NIST Handbook.
This section provides a high-level overview of some of the control categories.

Sections 4.4.1 through 4.4.3 provide an overview of technical, management, and operational
controls, respectively.

4.4.1

Technical Security Controls

Technical security controls for risk mitigation can be configured to protect against given types of

These controls may range from simple to complex measures and usually involve system
architectures; engineering disciplines; and security packages with a mix of hardware, software,
and firmware. All of these measures should work together to secure critical and sensitive data,
information, and IT system functions. Technical controls can be grouped into the following
major categories, according to primary purpose:
threats.

•

Support (Section

4.4.1.1).

security capabilities.

Supporting controls are generic and underlie most IT

These controls must be

in place in order to

implement other

controls.

•

Prevent (Section 4.4.1.2). Preventive controls focus on preventing security breaches
from occurring in the first place.

•

Detect and Recover (Section 4.4.1.3). These controls focus on detecting and
recovering from a security breach.

Figure 4-3 depicts the primary technical controls and the relationships between them.

SP 800-30

Page 32

Identillcation

Cryptographic Key Managonicnl

Seciiritv

Administration

System Protections
(least privilege, ohject reuse, process separalion, etc.)

Figure 4-3. Technical Security Controls
Supporting Technical Controls

4.4.1.1

Supporting controls are, by their very nature, pervasive and interrelated with
controls.

•

The supporting

many other

controls are as follows:

Identification. This control provides the ability to uniquely identify users, processes,

and information resources. To implement other security controls (e.g., discretionary
access control [DAC], mandatory access control [MAC], accountability), it is
essential that both subjects and objects be identifiable.
•

Cryptographic Key Management. Cryptographic keys must be securely managed
when cryptographic functions are implemented in various other controls.
Cryptographic key management includes key generation, distribution, storage, and
maintenance.

•

Security Administration. The security features of an IT system must be configured
(e.g.,

enabled or disabled) to meet the needs of a specific installation and to account

for changes in the operational environment.

operating system security or the application.

System security can be built into
Commercial off-the-shelf add-on

security products are available.

SP 800-30

Page 33

•

System Protections. Underlying
is

a system's various security functional capabilities

a base of confidence in the technical implementation. This represents the quality of

from the perspective both of the design processes used and of the
which the implementation was accomplished. Some examples of system

the implementation

manner

protections are residual information protection (also

known

as object reuse), least

privilege (or "need to know"), process separation, modularity, layering, and

minimization of what needs to be trusted.

Preventive Technical Controls

4.4.1.2

These controls, which can
•

inhibit attempts to violate security policy, include the following:

Authentication. The authentication control provides the means of verifying the
identity of a subject to ensure that a claimed identity is valid. Authentication

mechanisms include passwords, personal identification numbers, or PESfs, and
emerging authentication technology that provides strong authentication (e.g., token,
smart card, digital
•

Authorization. The authorization control enables specification and subsequent
management of the allowed actions for a given system (e.g., the information owner or
the database administrator determines who can update a shared file accessed by a

group of online
•

certificate, Kerberos).

users).

Access Control Enforcement. Data integrity and confidentiality are enforced by
access controls. When the subject requesting access has been authorized to access
particular processes,

it is

necessary to enforce the defined security policy

DAC). These policy-based controls

are enforced via access control

distributed throughout the system (e.g.,
sets,

access control

lists, roles,

(e.g.,

MAC

mechanisms

MAC sensitivity labels; DAC file permission

user profiles).

The

effectiveness and the strength of

access control depend on the correctness of the access control decisions

(e.g.,

how

the

security rules are configured) and the strength of access control enforcement (e.g., the

design of software or hardware security).
•

Nonrepudiation. System accountability depends on the ability to ensure that senders
cannot deny sending information and that receivers cannot deny receiving it.
Nonrepudiation spans both prevention and detection. It has been placed in the
prevention category in this guide because the mechanisms implemented prevent the
successful repudiation of an action

owner's private key

known only

(e.g.,

the digital certificate that contains the

to the owner).

a result, this control

typically

applied at the point of transmission or reception.
•

Protected Communications. In a distributed system, the ability to accomplish
security objectives is highly dependent on trustworthy communications. The
protected communications control ensures the integrity, availability, and
confidentiality of sensitive

and

critical

information while

it is

in transit. Protected

communications use data encryption methods (e.g., virtual private network, Internet
Protocol Security [IPSEC] Protocol), and deployment of cryptographic technologies
(e.g.. Data Encryption Standard [DES], Triple DES, RAS, MD4, MD5, secure hash
standard, and escrowed encryption algorithms such as Clipper) to minimize network
threats such as replay, interception, packet sniffing, wiretapping, or eavesdropping.

]

SP 800-30

Page 34
j

•

Transaction Privacy. Both government and private sector systems are increasingly
required to maintain the privacy of individuals. Transaction privacy controls

Secure Sockets Layer, secure
transactions performed

4.4.1.3 Detection

by an

shell) protect against loss

(e.g.,

of privacy with respect to

individual.

and Recovery Technical Controls

Detection controls warn of violations or attempted violations of security policy and include such

Recovery controls can be
used to restore lost computing resources. They are needed as a complement to the supporting
and preventive technical measures, because none of the measures in these other areas is perfect.
Detection and recovery controls include
controls as audit

•

trails,

intrusion detection methods, and checksums.

Audit. The auditing of security-relevant events and the monitoring and tracking of

system abnormalities are key elements

in the after-the-fact detection of,

and recovery

from, security breaches.
•

Intrusion Detection and Containment.

It is

essential to detect security breaches

network break-ins, suspicious activities) so that a response can occur in a timely
manner. It is also of little use to detect a security breach if no effective response can
(e.g.,

initiated.

The

intrusion detection and containment control provides these

two

capabilities.

•

Proof of Wholeness. The proof-of-wholeness control (e.g., system integrity tool)
analyzes system integrity and irregularities and identifies exposures and potential
threats.

This control does not prevent violations of security policy but detects

violations

4.4.2

and helps determine the type of corrective action needed.

•

Restore Secure State. This service enables a system
known to be secure, after a security breach occurs.

•

Virus Detection and Eradication. Virus detection and eradication software installed
on servers and user workstations detects, identifies, and removes software viruses to
ensure system and data integrity.

Management

to return to a state that is

Security Controls

Management

security controls, in conjunction with technical

implemented

Management

controls focus on the stipulation of information protection policy, guidelines, and

standards,

manage and reduce

the risk of loss

and

and operational controls, are

to protect an organization's mission.

which are carried out through operational procedures

to fulfill the organization's goals

and missions.

Management

security controls

—

preventive, detection, and recovery

—

that are

implemented

reduce risk are described in Sections 4.4.2.1 through 4.4.2.3.

SP 800-30

Page 35

4.4.2.1 Preventive

Management Security

Controls

These controls include the following:
•

Assign security responsibility to ensure that adequate security
mission-critical IT systems

•

Develop and maintain system security plans to document current controls and address
planned controls for IT systems in support of the organization's mission

•

Implement personnel security controls, including separation of
and user computer access registration and termination

•

Conduct security awareness and technical training to ensure that end users and system
users are aware of the rules of behavior and their responsibilities in protecting the

provided for the

duties, least privilege,

organization's mission.

4.4.2.2 Detection

Management Security

Controls

Detection management controls are as follows:

•

Implement personnel security

controls, including personnel clearance,

background

investigations, rotation of duties

4.4.2.3

•

Conduct periodic review of security controls

•

Perform periodic system audits

•

Conduct ongoing

•

Authorize IT systems to address and accept residual

risk

management

to assess

to ensure that the controls are effective

and mitigate

risk

risk.

Recovery Management Security Controls

These controls include the following:
•

Provide continuity of support and develop,

and maintain the continuity of
operations plan to provide for business resumption and ensure continuity of
operations during emergencies or disasters

•

Establish an incident response capability to prepare for, recognize, report, and

respond

4.4.3

to the incident

test,

and return the IT system

to operational status.

Operational Security Controls

organization's security standards should establish a set of controls and guidelines to ensure

governing the use of the organization's IT assets and resources are
properly enforced and implemented in accordance with the organization's goals and mission.
that security procedures

Management

plays a vital role in overseeing policy implementation and in ensuring the

establishment of appropriate operational controls.

SP 800-30

Page 36

Operational controls, implemented in accordance with a base set of requirements

(e.g.,

technical

and good industry practices, are used to correct operational deficiencies that could be
exercised by potential threat-sources. To ensure consistency and uniformity in security
operations, step-by-step procedures and methods for implementing operational controls must be
clearly defined, documented, and maintained. These operational controls include those presented
controls)

in Sections 4.4.3.1

and 4.4.3.2 below.

4.4.3.1 Preventive Operational Controls

Preventive operational controls are as follows:

•

Control data media access and disposal

(e.g.,

physical access control, degaussing

method)
•

Limit external data distribution

•

Control software viruses

•

Safeguard computing

(e.g.,

use of labeling)

facility (e.g., security guards, site

procedures for

visitors,

badge system, biometrics access control, management and distribution of
locks and keys, barriers and fences)
electronic

•

Secure wiring closets that house hubs and cables

•

Provide backup capability
archive logs that save

all

(e.g.,

procedures for regular data and system backups,

database changes to be used in various recovery scenarios)

•

Establish off-site storage procedures and security

•

Protect laptops, personal computers (PC), workstations

•

Protect IT assets from fire

damage

fire extinguishers, tarpaulins,

•

requirements and procedures for the use of

dry sprinkler systems, halon

Provide emergency power source
supplies, on-site

(e.g.,

fire

suppression system)

requirements for uninterruptible power

power generators)

Control the humidity and temperature of the computing facility

(e.g.,

operation of air

conditioners, heat dispersal).

4.4.3.2 Detection Operational Controls

Detection operational controls include the following:

•

Provide physical security

(e.g.,

use of motion detectors, closed-circuit television

monitoring, sensors and alarms)
•

Ensure environmental security

(e.g.,

use of

smoke and

fire detectors,

sensors and

alarms).

4.5

COST-BENEFIT ANALYSIS
allocate resources

and implement cost-effective controls, organizations,

after identifying all

possible controls and evaluating their feasibility and effectiveness, should conduct a cost-benefit

SP 800-30

Page 37

analysis for each proposed control to determine

which controls are required and appropriate for

their circumstances.

The

cost-benefit analysis can be qualitative or quantitative.

costs of implementing the controls can be justified

example, the organization

may not want

Its

purpose

to demonstrate that the

the reduction in the level of risk.

For

spend $1,000 on a control to reduce a $200

risk.

A cost-benefit analysis for proposed new controls or enhanced controls encompasses the
following:
•

Determining the impact of implementing the new or enhanced controls

•

Determining the impact of not implementing the new or enhanced controls

•

Estimating the costs of the implementation. These
to,

may include,

but are not limited

the following:

Hardware and software purchases

Reduced operational

effectiveness

system performance or functionality

reduced for increased security

Cost of implementing additional policies and procedures

Cost of hiring additional personnel to implement proposed policies, procedures, or
services

•

Training costs

Maintenance costs

Assessing the implementation costs and benefits against system and data
determine the importance to the organization of implementing the
their costs

The organization

will

and

new

criticality to

controls, given

relative impact.

need

to assess the benefits of the controls in terms of maintaining an

acceptable mission posture for the organization. Just as there

a cost for implementing a

needed control, there is a cost for not implementing it. By relating the result of not
implementing the control to the mission, organizations can determine whether it is feasible
forgo

its

implementation.

Cost-Benefit Analysis Example: System

X stores and processes mission-critical

and sensitive

employee privacy information; however, auditing has not been enabled for the system. A costbenefit analysis is conducted to determine whether the audit feature should be enabled for
System X.
Items (1) and (2) address the intangible impact (e.g., deterrence factors) for implementing or not
implementing the new control. Item (3) lists the tangibles (e.g., actual cost).

Impact of enabling system audit feature: The system audit feature allows the system security
administrator to monitor users' system activities but will slow down system performance and
(1)

therefore affect user productivity. Also the implementation will require additional resources, as

described in Item

3.
j

SP 800-30

Page 38
I

Impact of not enabling system audit feature: User system activities and violations cannot be
monitored and tracked if the system audit function is disabled, and security cannot be maximized
(2)

to protect the organization's confidential data

(3)

and mission.

Cost estimation for enabling the system audit feature:

—

Cost for enabling system audit feature No cost, built-in feature
Additional staff to perform audit review and archive, per year
Training

Add-on

(e.g.,

xx,xxx
x,xxx
x,xxx
x,xxx

xx,xxx

system audit configuration, report generation)

audit reporting software

Audit data maintenance

(e.g., storage,

archiving), per year

Total Estimated Costs

The organization's managers must determine what constitutes an acceptable level of mission
risk. The impact of a control may then be assessed, and the control either included or excluded,
determines a range of feasible risk levels. This range will vary

after the organization

organizations; however, the following rules apply in determining the use of

•

If control

would reduce

risk

more than needed, then see whether

new

among

controls:

a less expensive

alternative exists

more than

•

If control

would

•

If control

does not reduce risk sufficiently, then look for more controls or a different

cost

the risk reduction provided, then find something else

control
•

If control

provides enough risk reduction and

Frequently the cost of implementing a control
it.

a result, senior

management plays

cost-effective, then use

it.

tangible than the cost of not implementing

a critical role in decisions concerning the

implementation of control measures to protect the organizational mission.
4.6

RESIDUAL RISK

Organizations can analyze the extent of the risk reduction generated by the
controls in terms of the reduced threat likelihood or impact, the

new

two parameters

or enhanced
that define the

mitigated level of risk to the organizational mission.

Implementation of new or enhanced controls can mitigate risk by
•

Eliminating some of the system's vulnerabilities (flaws and weakness), thereby

reducing the number of possible threat-source/vulnerability pairs
•

Adding a targeted control

to reduce the capacity

and motivation of a threat-source

For example, a department determines that the cost for installing and maintaining
add-on security software for the stand-alone PC that stores its sensitive files is not
justifiable, but that administrative and physical controls should be implemented to

SP 800-30

Page 39

make

physical access to that

PC more difficult

(e.g., store

the

in a

locked room,

with the key kept by the manager).

Reducing the magnitude of the adverse impact (for example, limiting the extent of a
vulnerability or modifying the nature of the relationship between the IT system and

•

the organization's mission).

The

relationship

between control implementation and residual

risk is graphically presented in

Figure 4-4.

Figure 4-4. Implemented Controls and Residual Risk

The

risk

remaining after the implementation of new or enhanced controls

Practically

no IT system

risk free,

and not

all

the residual risk.

implemented controls can eliminate the

risk they

are intended to address or reduce the risk level to zero.

As mandated by

0MB Circular A-130, an organization's senior management or the DAA, who

are responsible for protecting the organization's IT asset
accredit) the

IT system

to begin or continue to operate.

and mission, must authorize (or

This authorization or accreditation must

made

IT system. The intent of
this process is to identify risks that are not fully addressed and to determine whether additional
controls are needed to mitigate the risks identified in the IT system. For federal agencies, after
occur

at least

every 3 years or whenever major changes are

to the

the appropriate controls have been put in place for the identified risks, the

DAA will sign a

statement accepting any residual risk and authorizing the operation of the

new IT system

continued processing of the existing IT system.
acceptable level, the risk

If the residual risk

management cycle must be repeated

or the

has not been reduced to an

to identify a

way

of lowering the

residual risk to an acceptable level.

SP 800-30

Page 40

EVALUATION AND ASSESSMENT

most organizations, the network itself will continually be expanded and updated, its
components changed, and its software applications replaced or updated with newer versions. In
addition, personnel changes will occur and security policies are likely to change over time.
These changes mean that new risks will surface and risks previously mitigated may again
become a concern. Thus, the risk management process is ongoing and evolving.
In

This section emphasizes the good practice and need for an ongoing risk evaluation and

assessment and the factors that will lead to a successful risk management program.
5.1

The

GOOD SECURITY PRACTICE
risk assessment process is usually repeated at least every 3 years for federal agencies, as

mandated by

OMB Circular A- 130.

integrated in the

because

it is

SDLC

for

management should be conducted and
IT systems, not because it is required by law or regulation, but
However,

risk

a good practice and supports the organization's business objectives or mission.

There should be a specific schedule for assessing and mitigating mission risks, but the
periodically performed process should also be flexible enough to allow changes where
warranted, such as major changes to the IT system and processing environment due to changes
resulting

5.2

from policies and new technologies.

KEYS FOR SUCCESS

A successful risk management program will rely on

management's commitment; (2)
the full support and participation of the IT team (see Section 2.3); (3) the competence of the risk
assessment team, which must have the expertise to apply the risk assessment methodology to a
specific site and system, identify mission risks, and provide cost-effective safeguards that meet
the needs of the organization; (4) the awareness and cooperation of members of the user
community, who must follow procedures and comply with the implemented controls to
safeguard the mission of their organization; and (5) an ongoing evaluation and assessment of the
(1) senior

IT-related mission risks.

SP 800-30

Page 41

APPENDIX A: Sample Interview

Questions

Interview questions should be tailored based upon where the IT system assessed

Sample questions

be asked during interviews with

the operational characteristics of an organization

site

may

is in

the

SDLC.

personnel to gain an understanding of

include the following:

•

Who

•

What

the mission of the user organization?

•

What

the purpose of the system in relation to the mission?

•

How important is

•

What

•

What

information (both incoming and outgoing)

•

What

information

are valid users?

the system to the user organization's mission?

the system-availability requirement?

retrieved

required by the organization?

generated by, consumed by, processed on, stored

and

by the system?

•

How important is the information to the user organization's mission?

•

What

are the paths of information flow?

•

What

types of information are processed by and stored on the system

personnel, research and development, medical,
•

What

•

What information handled by

in,

command and

(e.g., financial,

control)?

the sensitivity (or classification) level of the information?

or about the system should not be disclosed and to

whom?
•

Where

•

What

are the types of information storage?

•

What

specifically

the information processed and stored?

the potential impact on the organization if the information

disclosed to

unauthorized personnel?
•

What

are the requirements for information availability

•

What

the effect

on the organization's mission

and integrity?

the system or information

not

reliable?
•

How much

system downtime can the organization tolerate?

How does this downtime

compare with the mean repair/recovery time? What other processing or
communications options can the user access?
•

SP 800-30

Could a system or

security malfunction or unavailability result in injury or death?

Page A-1

APPENDIX B: SAMPLE RISK ASSESSMENT REPORT OUTLINE
EXECUTIVE SUMMARY
I.

Introduction
•

Purpose

•

Scope of

this risk

assessment

Describe the system components, elements, users, field
details about the

II.

system

site

locations

(if

any),

and any other

be considered in the assessment.

Risk Assessment Approach

Briefly describe the approach used to conduct the risk assessment, such as

•
•
•

The participants (e.g., risk assessment team members)
The technique used to gather information (e.g., the use of tools, questionnaires)
The development and description of risk scale (e.g., a3x3, 4x4, or 5x5 risk-level
matrix).

in.

System Characterization

Characterize the system, including hardware (server, router, switch), software
operating system, protocol), system interfaces

(e.g.,

communication

(e.g., application,

link), data,

and

users.

Provide connectivity diagram or system input and output flowchart to delineate the scope of this
risk assessment effort.

IV. Threat Statement

Compile and

list

the potential threat-sources

and associated

threat actions applicable to the

system assessed.
V. Risk Assessment Results
List the observations (vulnerability/threat pairs).

•

Each observation must include

Observation number and brief description of observation

(e.g..

Observation

User

system passwords can be guessed or cracked)

VI.

•

A discussion of the threat-source and vulnerability pair

•

Identification of existing mitigating security controls

•

Likelihood discussion and evaluation

•

Impact analysis discussion and evaluation

•

Risk rating based on the risk-level matrix

•

Recommended controls

(e.g..

High, Medium, or

(e.g..
(e.g.,

Low

likelihood)

Low impact)
Medium, or Low risk level)

High, Medium, or
High,

or alternative options for reducing the risk.

Summary

Total the

SP 800-30

number of observations. Summarize

the observations, the associated risk levels, the

PageB-1

recommendations, and any comments in a table format to

recommended

facilitate the

implementation of

controls during the risk mitigation process.

Page B-2

SP 800-30

a o
o

§
.

ON.

•3

- ^
W O
Q.

.S£i

(/}

"O
CO

S 3
3 cr
« CD
0)

Q. is

oo
o
o
CM CM

1- CM
I

N
>
X

E is
o o
en

—io
—
CO

W
C ^
= C
CD "F
CO Q-.t
^ E p E E
CO (C -D O CO
OT

3 .ii' c«
CD E
o c ^
T-

CD
2:

CO
CO

1
C«

PL,

0 0
0 0 =
x:
o
o

V O
o c
CC O
CO ^
b c

5
CO

C 6 c
cj

c
0
CO

O O

CO
0)

§ §

C3)

D
C S
52

^ .2

>-|

(1)

X
0
>

^
~

CO
«0

>*0)

£
QB

^
(0
CO

•—

o
•c

5
o

c
O 0

S 0 w

2^^
^ o9

0
O
O O

c P

c
CC
o

0
0 £
*>
CO
0 ^
^
CO Q) „.|
^ CO 0
CO "3
0
0 !c: 0 =
CO
>^
M ° 5o c"J Q
-Q Q.

E
O
SP 800-30

2M ?c3

z:
CO
05

Page C-1

APPENDIX D: ACRONYMS

AES

Advanced Encryption Standard

CSA

Computer Security Act

DAA

Designated Approving Authority

DAC

Discretionary Access Control

DBS

Data Encryption Standard

FedCIRC

Federal Computer Incident Response Center

FTP

File Transfer Protocol

Identifier

IPSEC

Internet Security Protocol

ISSO

Information system security officer

Information Technology

ITL

Information Technology Laboratory

MAC

Mandatory Access Control

NIPC

National Infrastructure Protection Center

NIST

National Institute of Standards and Technology

OIG

Office of Inspector General

0MB

Office of

Personal Computer

SDLC

System Development Life Cycle

Special Publication

ST&E

Security Test and Evaluation

SP 800-30

Management and Budget

APPENDIX E: GLOSSARY

TERM
Accountability

DEFINITION
The

security goal that generates the requirement for actions of an entity to

be traced uniquely to that

entity.

This supports nonrepudiation, deterrence,

fault isolation, intrusion detection

and
Assurance

and prevention, and after-action recovery

legal action.

Grounds

for confidence that the other four security goals (integrity,

and accountability) have been adequately met
by a specific implementation. "Adequately met" includes (1) functionality
that performs correctly, (2) sufficient protection against unintentional errors
(by users or software), and (3) sufficient resistance to intentional penetration
availability, confidentiality,

or bypass.

Availability

The
•

security goal that generates the requirement for protection against
Intentional or accidental attempts to (1) perform unauthorized deletion

of data or (2) otherwise cause a denial of service or data
•

Confidentiality

The

Unauthorized use of system resources.
security goal that generates the requirement for protection

from

intentional or accidental attempts to perform unauthorized data reads.

Confidentiality covers data in storage, during processing, and in transit.

Denial of Service

The prevention of authorized access

to resources or the delaying of time-

critical operations.

Due Care

Managers and

their organizations

have a duty

to provide for information

and the
deployment of control are appropriate for the system being managed.
security to ensure that the type of control, the cost of control,

Integrity

The

security goal that generates the requirement for protection against either

intentional or accidental attempts to violate data integrity (the property that

data has

when

has not been altered in an unauthorized manner) or system

integrity (the quality that a

system has when

performs

its

intended

function in an unimpaired manner, free from unauthorized manipulation).

SP 800-30

Page E-1

—
IT-Related Risk

The

net mission impact considering (1) the probability that a particular

threat-source will exercise (accidentally trigger or intentionally exploit) a

and (2) the resulting impact if
from legal liability or mission loss

particular information system vulnerability
this

should occur. IT-related risks arise

due

Unauthorized (malicious or accidental) disclosure, modification, or
destruction of information

Unintentional errors and omissions

IT disruptions due to natural or man-made disasters

Failure to exercise due care and diligence in the implementation and

operation of the IT system.

IT Security Goal

See Security Goals

Risk

Within

Risk Assessment

The process of identifying

this

document, synonymous with IT-Related Risk.
the risks to system security and determining the

probability of occurrence, the resulting impact, and additional safeguards
that

would mitigate

this impact.

Part of Risk

Management and synonymous

with Risk Analysis.

Risk Management

The

total

process of identifying, controlling, and mitigating information

system-related risks.

includes risk assessment; cost-benefit analysis; and

and security evaluation of safeguards.
This overall system security review considers both effectiveness and
efficiency, including impact on the mission and constraints due to policy,
regulations, and laws.
the selection, implementation, test,

Security

Information system security

mechanisms
Security Goals

The

that span the

The

a system characteristic and a set of

system both logically and physically.

five security goals are integrity, availability, confidentiality,

accountability,

Threat

and assurance.

potential for a threat-source to exercise (accidentally trigger or

intentionally exploit) a specific vulnerability.

Threat-source

Either (1) intent and method targeted at the intentional exploitation of a
vulnerability or (2) a situation and

method

that

may

accidentally trigger a

vulnerability.

Threat Analysis

The examination of threat-sources

against system vulnerabilities to

determine the threats for a particular system in a particular operational
environment.
Vulnerability

A flaw or weakness in system security procedures, design, implementation,
or internal controls that could be exercised (accidentally triggered or
intentionally exploited)

and

result in a security

breach or a violation of the

system's security policy.

SP 800-30

Page E-2

APPENDIX F: REFERENCES
Computer Systems Laboratory
March 1994.

Bulletin. Threats to

Computer Systems: An Overview.

Interagency Reports 4749. Sample Statements of Work for Federal Computer Security
Services: For Use In-House or Contracting Out. December 1991.

NIST

Special Publication 800-12.

Introduction to

Computer Security: The NIST Handbook.

October 1995.

NIST

Special Publication 800-14. Generally Accepted Principles

and Practices for Securing

Information Technology Systems. September 1996. Co-authored with Barbara Guttman.

NIST

Special Publication 800-18. Guide

NIST

Special Publication 800-26, Security Self-Assessment Guide for Information Technology

For Developing Security Plans for Information
Technology Systems. December 1998. Co-authored with Federal Computer Security Managers'
Forum Working Group.

Systems. August 2001.

NIST

Special Publication 800-27. Engineering Principles for IT Security

0MB Circular A- 130.

June 2001.

Management of Federal Information Resources. Appendix

HI.

November 2000.

SP 800-30

Page F-1

Technical Publications
Periodical

—

Journal of Research of the National Institute of Standards and Technology Reports NIST research
and development in those disciplines of the physical and engineering sciences in which the Institute is
active. These include physics, chemistry, engineering, mathematics, and computer sciences. Papers cover a
broad range of subjects, with major emphasis on measurement methodology and the basic technology
underlying standardization. Also included from time to time are survey articles on topics closely related to
the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

—Major contributions
on various subjects
the
Handbooks—Recommended codes of engineering and
practice (including
codes)
professional organizations, and regulatory bodies.
developed
cooperation with
Special Publications —Include proceedings of conferences sponsored by NIST, NIST annual
and
publications appropriate
grouping such
wall
other
pocket
and bibliographies.
National Standard Reference Data Series—Provides
data on
physical and chemical
Monographs
scientific

to the technical literature

and technical

related to

Institute's

activities.

industrial

safety

interested industries,

reports,

special

charts,

to this

quantitative

cards,

the

properties of materials, compiled from the world's literature and critically evaluated.

Developed under a
worldwide program coordinated by NIST under the authority of the National Standard Data Act (Public
Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD) is published
bimonthly for NIST by the American Institute of Physics (AIP). Subscription orders and renewals are
63150-3284.
available from AIP, P.O. Box 503284, St. Louis,
Building Science Series

—Disseminates

technical information developed at the Institute

on building

and whole structures. The series presents research results, test methods,
and performance criteria related to the structural and environmental functions and the durability and safety
characteristics of building elements and systems.
materials, components, systems,

Technical Notes

—Studies

or reports which are complete in themselves but restrictive in their treatment of
monographs but not so comprehensive in scope or definitive in treatment of the
subject area. Often serve as a vehicle for final reports of work performed at NIST under the sponsorship of
other government agencies.
Voluntary Product Standards Developed under procedures published by the Department of Commerce
in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally recognized
requirements for products, and provide all concerned interests with a basis for common understanding of
the characteristics of the products. NIST administers this program in support of the efforts of private-sector
a subject.

Analogous

—

standardizing organizations.

Order the following NIST publications
Service, Springfield,

—FIPS and NISTIRs—from the National Technical Information

VA 22161.

Federal Information Processing Standards Publications (FIPS

PUB)

—Publications

collectively constitute the Federal Information Processing Standards Register.

in this series

The Register

serves as the

official source of information in the Federal Government regarding standards issued by NIST pursuant to
the Federal Property and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat.
1127), and as implemented by Executive Order 11717 (38 FR 12315, dated May 11, 1973) andPart6of
Title 15 CFR (Code of Federal Regulations).
NIST Interagency or Internal Reports (NISTIR) The series includes interim or final reports on work

—

performed by NIST for outside sponsors (both goverrunent and nongovernment). In general, initial
distribution is handled by the sponsor; public distribution is handled by sales through the National
Technical Information Service, Springfield, VA 22161, in hard copy, electronic media, or microfiche form.

NISTIR' s may

also report results of

be published subsequently

NIST

projects of transitory or limited interest, including those that will

more comprehensive form.

8
o

C >

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : No
Author                          : Jim Foti
Create Date                     : 2015:10:16 07:57:05-04:00
Modify Date                     : 2015:10:16 07:57:05-04:00
XMP Toolkit                     : Image::ExifTool 8.99
Creator                         : Stoneburner, Gary; Goguen, Alice; Feringa, Alexis
Description                     : Risk Management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level. Organizations use risk assessment, the first step in the risk management methodology, to determine the extent of the potential threat, vulnerabilities, and the risk associated with an information technology (IT) system. The output of this process helps to identify appropriate controls for reducing or eliminating risk during the risk mitigation process, the second step of risk management, which involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the risk assessment process.This guide provides a foundation for the development of an effective risk management program, containing both the definitions and the practical guidance necessary for assessing and mitigating risks identified within IT systems throughout their system development life cycle (SDLC). The ultimate goal is to help organizations to better manage IT-related mission risks.Organizations may choose to expand or abbreviate the comprehensive processes and steps suggested in this guide and tailor them to their site environment in managing IT-related mission risks. In addition, this guide provides information on the selection of cost-effective security controls. These controls can be used to mitigate risk for the better protection of mission-critical information and the IT systems that process, store, and carry this information.The third step in the process is continual evaluation and assessment. In most organizations, IT systems will continually be expanded and updated, their components changed, and their software applications replaced or updated with newer versions. In addition, personnel changes will occur and security policies are likely to change over time. These changes mean that new risks will surface and risks previously mitigated may again become a concern. Thus, the risk management process is ongoing and evolving.
Format                          : application/pdf
Identifier                      : 10.6028/NIST.SP.800-30
Rights                          : Special Publications of the National Institute of Standards and Technology is a publication of the U.S. Government. The papers are in the public domain and are not subject to copyright in the United States. However, please pay special attention to the individual works to make sure there are no copyright restrictions indicated. Individual works may require securing other permissions from the original copyright holder.
Title                           : Risk management guide for information technology systems: recommendations of the National Institute of Standards and Technology
Producer                        : Adobe Acrobat Pro 11.0.12
Creator Tool                    : Adobe Acrobat Pro 11.0.12
Metadata Date                   : 2015:10:16 07:57:05-04:00
Document ID                     : uuid:5fa567db-54f9-4e30-9a62-b6606fad95db
Instance ID                     : uuid:1d6710d6-d3e2-4b3a-9a95-1cd20bc45432
Page Count                      : 65

EXIF Metadata provided by EXIF.tools

NIST Information Security Guide For IT Systems

Navigation menu

Versions of this User Manual:

Views

Navigation