National Information Assurance Partnership
Download
Report
Transcript National Information Assurance Partnership
The New FISMA Standards and Guidelines
or
Building More Secure Information Systems
A Strategy for Effectively Applying the Provisions of FISMA
Dr. Ron Ross
&
Dr. Stuart Katzke
Computer Security Division
Information Technology Laboratory
IIA Conference February 8, 2005
National Institute of Standards and
Technology
1
Presentation Contents
• Part I: Overview
– Setting the stage/motivation/background
– NIST’s Federal Information Security Management Act
(FISMA) of 2002 Implementation Project: A Risk
Management Framework (RMF)
• Part II: Details
– FIPS 199: Security Categorization
– Special Publication (SP) 800-60: Categories Mapping
Guidelines
– SP 800-53: Security Control Selection
(Minimum/Baseline Controls)
– The Development and Vetting of SP 800-53
– SP 800- 37: Security Certification and Accreditation
National Institute of Standards and
– SP 800- 53A: Security Control Assessment
Technology
IIA Conference February 8, 2005
2
Part I: Overview
IIA Conference February 8, 2005
National Institute of Standards and
Technology
3
The Information Age
Information systems are an integral part of
government and business operations today
Information systems are changing the way we do
business and interact as a society
Information systems are driving a reengineering of
business processes in all sectors including defense,
healthcare, manufacturing, financial services, etc.
Information systems are driving a transition from
a paper-based society to a digital society
IIA Conference February 8, 2005
National Institute of Standards and
Technology
4
The Protection Gap
Information system protection measures have not
kept pace with rapidly advancing technologies
Information security programs have not kept pace
with the aggressive deployment of information
technologies within enterprises
Two-tiered approach to security (i.e., national
security community vs. everyone else) has left
significant parts of the critical infrastructure
vulnerable
IIA Conference February 8, 2005
National Institute of Standards and
Technology
5
The Global Threat
Information security is not just a paperwork
drill…there are dangerous adversaries out
there capable of launching serious attacks
on our information systems that can result
in severe or catastrophic damage to the
nation’s critical information infrastructure
and ultimately threaten our economic and
national security…
IIA Conference February 8, 2005
National Institute of Standards and
Technology
6
U.S. Critical Infrastructures
Definition
“...systems and assets, whether physical or
virtual, so vital to the United States that the
incapacity or destruction of such systems
and assets would have a debilitating impact
on security, national economic security,
national public health and safety, or any
combination of those matters.”
-- USA Patriot Act (P.L. 107-56)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
7
U.S. Critical Infrastructures
Examples
Energy (electrical, nuclear, gas and oil, dams)
Transportation (air, road, rail, port, waterways)
Public Health Systems / Emergency Services
Information and Telecommunications
Defense Industry
Banking and Finance
Postal and Shipping
Agriculture / Food / Water
Chemical
IIA Conference February 8, 2005
National Institute of Standards and
Technology
8
Critical Infrastructure Protection
The U.S. critical infrastructures are over 90%
owned and operated by the private sector
Critical infrastructure protection must be a
partnership between the public and private
sectors
Information security solutions must be broadbased, consensus-driven, and address the
ongoing needs of government and industry
IIA Conference February 8, 2005
National Institute of Standards and
Technology
9
Threats to Security
Connectivity
Complexity
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
Key Security Challenges
Adequately protecting enterprise information
systems within constrained budgets
Changing the current culture of:
“Connect first…ask security questions later”
Bringing standardization to:
Information system security control selection and
specification
Methods and procedures employed to assess the
correctness and effectiveness of those controls
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
Why Standardization?
Security Visibility Among Business/Mission Partners
Organization One
Organization Two
Information
System
Business / Mission
Information Flow
Information
System
?
Security Information
?
Determining the risk to the first
organization’s operations and assets and
the acceptability of such risk
Determining the risk to the second
organization’s operations and assets and
the acceptability of such risk
The objective is to achieve visibility into prospective business/mission partners information
security programs BEFORE critical/sensitive communications begin…establishing levels of
security due diligence.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
NIST’s Federal
Information Security
Management Act (FISMA)
of 2002 Implementation
Project: a Risk
Management Framework
(RMF)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
FISMA Implementation Project
Drivers
Technical
Legislative and Policy
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
Project Drivers:
Technical
NIST’s system security certification and
accreditation (C&A) guidance aging (FIPS 102-1983)
Proliferation of C&A guidance
FIPS 102 (NIST)
DITSCAP (DoD)
NIACAP (NSTISSC/NSS)
Attempt to achieve government-wide C&A
convergence
Attempt to integrate new and existing guidance in
a comprehensive risk management framework
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
Project Drivers:
Legislative and Policy
Public Law 107-347 (Title III)
Federal Information Security Management Act of 2002
Public Law 107-305
Cyber Security Research and Development Act of 2002
Homeland Security Presidential Directive #7
Critical Infrastructure Identification, Prioritization, and
Protection
OMB Circular A-130 (Appendix III)
Security of Federal Automated Information Resources
IIA Conference February 8, 2005
National Institute of Standards and
Technology
16
Security Checklists
CSRDA Requirement
Develop and disseminate security configuration
checklists and option selections that minimize the
security risks associated with commercial information
technology products that are, or are likely to become,
widely used within federal information systems
Publication status:
NIST Special Publication 800-70, “The NIST Security
Configuration Checklists Program”
Initial Public Draft: August 2004
IIA Conference February 8, 2005
National Institute of Standards and
Technology
17
FISMA Legislation
Overview
“Each federal agency shall develop, document,
and implement an agency-wide information
security program to provide information security
for the information and information systems that
support the operations and assets of the agency,
including those provided or managed by another
agency, contractor, or other source…”
-- Federal Information Security Management Act of 2002
IIA Conference February 8, 2005
National Institute of Standards and
Technology
18
FISMA Tasks for NIST
Standards to be used by Federal agencies to categorize
information and information systems based on the
objectives of providing appropriate levels of information
security according to a range of risk levels
Guidelines recommending the types of information and
information systems to be included in each category
Minimum information security requirements (management,
operational, and technical security controls) for information
and information systems in each such category
IIA Conference February 8, 2005
National Institute of Standards and
Technology
19
FISMA Implementation Project
FISMA-related standards and guidelines tightly coupled to
the suite of NIST Management and Technical Guidelines
Described within the context of System Development Life
Cycle (SDLC)
http://csrc.nist.gov/SDLCinfosec
IIA Conference February 8, 2005
National Institute of Standards and
Technology
20
FISMA Implementation Project
Standards and Guidelines (1)
New Standards and Guidelines
FIPS Publication 199 (Security Categorization)
NIST Special Publication 800-37 (Certification & Accreditation)
NIST Special Publication 800-53 (Recommended Security
Controls)
NIST Special Publication 800-53A (Security Control
Assessment)
NIST Special Publication 800-59 (National Security Systems)
NIST Special Publication 800-60 (Security Category Mapping)
FIPS Publication 200 (Minimum Security Controls)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
21
FISMA Implementation Project
Standards and Guidelines (2)
Existing Standards and Guidelines
NIST Special Publication 800-30 (Risk Management )
NIST Special Publication 800-18 (Security Plan
Development)
NIST Special Publication 800-64 (System
Development Life Cycle)
NIST Special Publication 800-70 (Security
Configuration Checklists)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
22
FISMA Implementation Project
Overall Goals
Helping to achieve more secure information
systems within the federal government by:
A better understanding of mission risks resulting from
the operation of information systems
A standard approach for selecting baseline controls
More consistent, comparable and repeatable
assessments of security controls in federal systems
More complete, reliable and trustworthy information to
support authorizing officials—facilitating more
informed accreditation decisions
IIA Conference February 8, 2005
National Institute of Standards and
Technology
23
Managing Enterprise Risk
Key activities in managing organizational-level
risk—risk to the organization resulting from the
operation of an information system:
Categorize the information system
Select set of minimum (baseline) security controls
Refine the security control set based on risk assessment
Document security controls in system security plan
Implement the security controls in the information system
Assess the security controls (C&A)
Determine agency-level risk and risk acceptability (C&A)
Authorize information system operation (C&A)
Monitor security controls on a continuous basis (C&A)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
24
FISMA Implementation Project:
Risk Management Framework (RMF)
FIPS 199 / SP 800-60
SP 800-53 / FIPS 200
Security Control
Selection
Selects minimum security controls (i.e.,
safeguards and countermeasures) planned or
in place to protect the information system
Security
Categorization
Defines category of information
system according to potential
impact of loss
SP 800-37
Security Control
Monitoring
Continuously tracks changes to the information
system that may affect security controls and
assesses control effectiveness
SP 800-53 / FIPS 200 / SP 800-30
SP 800-37
Security Control
Refinement
System
Authorization
Uses risk assessment to adjust minimum control
set based on local conditions, required threat
coverage, and specific agency requirements
Determines risk to agency operations, agency
assets, or individuals and, if acceptable,
authorizes information system processing
SP 800-18
Security Control
Documentation
In system security plan, provides a an
overview of the security requirements for the
information system and documents the
security controls planned or in place
IIA Conference February 8, 2005
SP 800-64/SP 800-70
Security Control
Implementation
Implements security controls in new
or legacy information systems;
implements security configuration
checklists
SP 800-53A / SP 800-37
Security Control
Assessment
Determines extent to which the security
controls are implemented correctly, operating
as intended, and producing desired outcome
with respect to meeting security requirements
National Institute of Standards and
Technology
25
Security Objectives
Confidentiality
“Preserving authorized restrictions on information access and
disclosure, including means for protecting personal privacy
and proprietary information…” [44 U.S.C., Sec. 3542]
Integrity
“Guarding against improper information modification or
destruction, and includes ensuring information non-repudiation
and authenticity…” [44 U.S.C., Sec. 3542]
Availability
“Ensuring timely and reliable access to and use of information…”
[44 U.S.C., Sec. 3542]
IIA Conference February 8, 2005
National Institute of Standards and
Technology
26
FIPS 199 Levels of Impact
The level of impact is low if—
The event could be expected to have a limited adverse effect on agency
operations (including mission, functions, image or reputation), agency assets,
or individuals. The event causes a negative outcome or results in limited
damage to operations or assets, requiring minor corrective actions or repairs.
The level of impact is moderate if—
The event could be expected to have a serious adverse effect on agency
operations (including mission, functions, image or reputation), agency assets,
or individuals. The event causes significant degradation in mission capability,
places the agency at a significant disadvantage, or results in major damage to
assets, requiring extensive corrective actions or repairs.
The level of impact is high if—
The event could be expected to have a severe or catastrophic adverse
effect on agency operations (including mission, functions, image or
reputation), agency assets, or individuals. The event causes a loss of mission
capability for a period that poses a threat to human life, or results in a loss of
major assets.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
27
Security Categorization
Example: An Enterprise Information System
FIPS Publication
199
Guidance for
Mapping Types of
Information and
Information
Systems to FIPS
Publication 199
Security Categories
Low
Moderate
High
Confidentiality
The loss of confidentiality
could be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
Integrity
The loss of integrity could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
The loss of availability could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
SP 800-60
Availability
IIA Conference February 8, 2005
National Institute of Standards and
Technology
28
Security Categorization
Example: An Enterprise Information System
FIPS Publication
199
Guidance for
Mapping Types of
Information and
Information
Systems to FIPS
Publication 199
Security Categories
Low
Moderate
High
Confidentiality
The loss of confidentiality
could be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
Integrity
The loss of integrity could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
The loss of availability could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
SP 800-60
Availability
IIA Conference February 8, 2005
Minimum Security
Controls for High
Impact Systems
National Institute of Standards and
Technology
29
The Desired End State
Security Visibility Among Business/Mission Partners
Organization One
Information
System
Organization Two
Business / Mission
Information Flow
System Security Plan
Security Assessment Report
Information
System
System Security Plan
Security Information
Security Assessment Report
Plan of Action and Milestones
Plan of Action and Milestones
Determining the risk to the first
organization’s operations and assets and
the acceptability of such risk
Determining the risk to the second
organization’s operations and assets and
the acceptability of such risk
The objective is to achieve visibility into prospective business/mission partners information
security programs BEFORE critical/sensitive communications begin…establishing levels of
security due diligence.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
30
System Security Plan
Prepared by the information system owner
Provides an overview of the security requirements
for the information system and describes the
security controls in place or planned for meeting
those requirements
Contains (either as supporting appendices or as
references) other key security-related documents
for the information system (e.g., risk assessment,
contingency plan, incident response plan, system
interconnection agreements)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
31
RMF: Significant Features (1)
Standard categorization method—based on
worst case impact to enterprise if
compromise
Supports scalability and prioritization
Level of effort commensurate with security
categorization
Apply effort to highest impact systems first
Is generic
Applies to all types of systems
Focuses on the process for the selection,
implementation, & assessment of controls
IIA Conference February 8, 2005
National Institute of Standards and
Technology
32
RMF: Significant Features (2)
Master control catalogue derived from many
public and private sector sources:
CC Part 2
ISO/IEC 17799
COBIT
GAO FISCAM
NIST SP 800-26 Self Assessment Questionnaire
CMS (healthcare)
D/CID 6-3 Requirements
DoD Policy 8500
BITS functional packages
IIA Conference February 8, 2005
National Institute of Standards and
Technology
33
RMF: Significant Features (3)
• Minimum/ baseline controls for Low, Moderate, &
High impact systems were selected from master
control catalogue
– Hierarchical
– Increase in functionality
Assurance requirements
Baseline dependent: one for each baseline
Increase control developer/implementer's analysis and
evidence to demonstrate implementation quality,
correctness, and confidence
IIA Conference February 8, 2005
National Institute of Standards and
Technology
34
RMF: Significant Features (4)
Assurance requirements are related to and
support control assessment approach
Common security controls concept
Agency-wide (e.g., training, personal security)
Site-wide (e.g., physical security, contingency
plan)
Common subsystem (e.g., deployed at multiple
sites)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
35
RMF: Significant Features (5)
C&A for low impact systems
Allows self assessment
Scaled level of effort
Controls can be added to the control
catalogue and new baselines developed to
meet requirements of community-specific
applications/systems
SCADA/real-time processing
Healthcare/HIPPA
Financial/Sarbanes-Oxley
IIA Conference February 8, 2005
National Institute of Standards and
Technology
36
RMF: Significant Features (6)
• Possibility of becoming “due diligence” in
commercial and other sectors through:
– Government critical infrastructure liaisons to
private sector counterparts (e.g., energy,
financial, transportation)
– Extension of government security standards and
requirements to systems operated on behalf of
the federal government
• State and local governments
• Contractors and IT service providers
IIA Conference February 8, 2005
National Institute of Standards and
Technology
37
Contact Information
100 Bureau Drive Mailstop 8930
Gaithersburg, MD USA 20899-8930
Project Manager
Administrative Support
Dr. Ron Ross
(301) 975-5390
[email protected]
Peggy Himes
(301) 975-2489
[email protected]
Senior Information Security Researchers and Technical Support
Marianne Swanson
(301) 975-3293
[email protected]
Dr. Stu Katzke
(301) 975-4768
[email protected]
Pat Toth
(301) 975-5140
[email protected]
Arnold Johnson
(301) 975-3247
[email protected]
Curt Barker
(301) 975-4768
[email protected]
Information and Feedback
Web: csrc.nist.gov/sec-cert
Comments: [email protected]
IIA Conference February 8, 2005
National Institute of Standards and
Technology
38
Part II: Details
•
•
•
•
•
•
•
Security Categorization
Categories Mapping Guidelines
Security Control Selection
Security Certification and Accreditation
Security Control Assessment
Desired End State/Conclusion
Security Control Selection Vetting Process
IIA Conference February 8, 2005
National Institute of Standards and
Technology
39
Security Categorization
FIPS 199: Standards for Security
Categorization of Federal
Information and Information Systems
IIA Conference February 8, 2005
National Institute of Standards and
Technology
40
Categorization Standards
FISMA Requirement
Develop standards to be used by federal agencies to
categorize information and information systems based
on the objectives of providing appropriate levels of
information security according to a range of risk levels
Publication status:
Federal Information Processing Standards (FIPS)
Publication 199, “Standards for Security Categorization
of Federal Information and Information Systems”
Final Publication: December 2003*
*
FIPS Publication 199 was signed by the Secretary of Commerce in February 2004.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
41
FIPS Publication 199
FIPS 199 is critically important to enterprises
because the standard—
Requires prioritization of information systems according
to potential impact on mission or business operations
Promotes effective allocation of limited information
security resources according to greatest need
Facilitates effective application of security controls to
achieve adequate information security
Establishes appropriate expectations for information
system protection
IIA Conference February 8, 2005
National Institute of Standards and
Technology
42
FIPS 199 Applications
FIPS 199 should guide the rigor, intensity, and
scope of all information security-related activities
within the enterprise including—
The application and allocation of security controls
within information systems
The assessment of security controls to determine
control effectiveness
Information system authorizations or accreditations
Oversight, reporting requirements, and performance
metrics for security effectiveness and compliance
IIA Conference February 8, 2005
National Institute of Standards and
Technology
43
Security Categorization
Example: An Enterprise Information System
FIPS Publication
199
Guidance for
Mapping Types of
Information and
Information
Systems to FIPS
Publication 199
Security Categories
Low
Moderate
High
Confidentiality
The loss of confidentiality
could be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
Integrity
The loss of integrity could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
The loss of availability could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
SP 800-60
Availability
IIA Conference February 8, 2005
National Institute of Standards and
Technology
44
Categories Mapping Guidelines
SP 800-60: Guide for Mapping Types
of Information and Information
Systems to Security Categories,
IIA Conference February 8, 2005
National Institute of Standards and
Technology
45
Mapping Guidelines
FISMA Requirement
Develop guidelines recommending the types of
information and information systems to be included
in each category
Publication status:
NIST Special Publication 800-60, “Guide for
Mapping Types of Information and Information
Systems to Security Categories”
Final Publication: June 2004
IIA Conference February 8, 2005
National Institute of Standards and
Technology
46
SP 800-60
• Companion to FIPS 199
• Rationale by Identified Lines of Business
• Offers guidance on Special Factors to be
considered in addressing system impact
IIA Conference February 8, 2005
National Institute of Standards and
Technology
47
SP 800-60 Overview
• Types of information
– Agency-common: administrative, management and support
information
– Mission-based: mission information and service delivery
mechanisms
• Service delivery mechanisms provide policy,
programmatic, and managerial foundation in support of
Federal government operations
• Security attributes of information associated with
mission-specific activities will often vary from agency
to agency
National Institute of Standards and
IIA Conference February 8, 2005
Technology
48
SP 800-60 Overview
(concluded)
• Support services and management of
resources functions are included in agencycommon information types
• Services to citizens and modes of delivery
types are included in mission-based
information types
IIA Conference February 8, 2005
National Institute of Standards and
Technology
49
Security Control Selection
(Minimum/Baseline Controls)
NIST Special Publication 800-53:
Recommended Security Controls for
Federal Information Systems
“Building a National Consensus For Due Diligence in the Application
of Minimum Security Controls for Information Systems”
IIA Conference February 8, 2005
National Institute of Standards and
Technology
50
Minimum Security Requirements
FISMA Requirement
Develop minimum information security requirements
(management, operational, and technical security
controls) for information and information systems in
each such category
Publication status:
Federal Information Processing Standards (FIPS)
Publication 200, “Minimum Security Controls for
Federal Information Systems”*
Final Publication: December 2005
*
NIST Special Publication 800-53, “Recommended Security Controls for Federal Information Systems”
(Second public draft September 2004) will provide interim guidance until completion and adoption of
FIPS Publication 200. Current draft out for public comment until November 30, 2004.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
51
Minimum Security Controls
Minimum security controls, or baseline controls,
defined for low-impact, moderate-impact, and highimpact information systems—
Provide a starting point for organizations and
communities of interest in their security control
selection process
Are used in the context of the organization’s ongoing
risk management process
IIA Conference February 8, 2005
National Institute of Standards and
Technology
52
Security Categorization
Example: An Enterprise Information System
FIPS Publication
199
Guidance for
Mapping Types of
Information and
Information
Systems to FIPS
Publication 199
Security Categories
Low
Moderate
High
Confidentiality
The loss of confidentiality
could be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
Integrity
The loss of integrity could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
The loss of availability could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
SP 800-60
Availability
IIA Conference February 8, 2005
National Institute of Standards and
Technology
53
Security Categorization
Example: An Enterprise Information System
FIPS Publication
199
Guidance for
Mapping Types of
Information and
Information
Systems to FIPS
Publication 199
Security Categories
Low
Moderate
High
Confidentiality
The loss of confidentiality
could be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of confidentiality
could be expected to have a
severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
Integrity
The loss of integrity could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of integrity could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
The loss of availability could
be expected to have a
limited adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a
serious adverse effect on
organizational operations,
organizational assets, or
individuals.
The loss of availability could
be expected to have a severe
or catastrophic adverse
effect on organizational
operations, organizational
assets, or individuals.
SP 800-60
Availability
IIA Conference February 8, 2005
Minimum Security
Controls for High
Impact Systems
National Institute of Standards and
Technology
54
Security Control Structure
Functional requirements
Master Security Control Catalogue
17 Control Families
Functional requirements for each control in
each family
Assurance requirements
Dependent on the baseline the control is in
Includes: Low, Moderate, High, and Additional
Assurance Requirements Supplementing the
High Baseline
IIA Conference February 8, 2005
National Institute of Standards and
Technology
55
Security Control Structure
Control Requirements: Functional
Simplified structure consisting of three
sections:
Basic level security control statement
Supplemental guidance
Control enhancements
Example: Contingency Planning (CP)
Family
CP-7 Alternate Processing Site
IIA Conference February 8, 2005
National Institute of Standards and
Technology
56
CP-7 ALTERNATE PROCESSING SITES
The organization identifies an alternate processing site
and initiates necessary agreements to permit the resumption of
information system operations for critical mission/business
functions within [Assignment: organization-defined time period]
when the primary processing capabilities are unavailable.
Supplemental Guidance: Equipment and supplies required to resume
operations within the organization-defined time period are either
available at the alternate site or contracts are in place to support
delivery to the site.
Control:
Control Enhancements:
(1) The alternate processing site is geographically separated from the
primary processing site so as not to be susceptible to the same hazards.
(2) The organization identifies potential accessibility problems to the
alternate processing site in the event of an area-wide disruption or disaster
and outlines explicit mitigation actions.
(3) Alternate processing site agreements contain priority-of-service
provisions in accordance with the organization’s availability requirements.
(4) The alternate processing site is fully configured to support a minimum
required
operational capability and ready to useNational
as theInstitute
operational
site.
IIA Conference February 8, 2005
of Standards
and
Technology
57
Security Control Baselines
Functional
Master Security Control Catalog
Complete Set of Security Controls and Control Enhancements
Minimum Security Controls
Minimum Security Controls
Minimum Security Controls
Low Impact
Information Systems
Moderate Impact
Information Systems
High Impact
Information Systems
Baseline #1
Baseline #2
Baseline #3
Selection of a subset of security
controls from the master catalog—
consisting of basic level controls
Builds on low baseline. Selection
of a subset of controls from the
master catalog—basic level
controls, additional controls, and
control enhancements
Builds on moderate baseline.
Selection of a subset of controls
from the master catalog—basic
level controls, additional controls,
and control enhancements
IIA Conference February 8, 2005
National Institute of Standards and
Technology
58
Contingency Planning Family
Contingency Planning Policy &
Procedures
CP-1
CP-1
CP-1
Contingency Plan
CP-2
CP-2 (1)
CP-2 (1)
Contingency Training
Not
Selected
CP-3
CP-3 (1)
(2)
Contingency Plan Testing
Not
Selected
CP-4 (1)
CP-4 (1)
(2) (3)
Contingency Plan Update
CP-5
CP-5
CP-5
Alternate Storage Sites
Not
Selected
CP-6 (1)
CP-6 (1)
(2) (3)
Alternate Processing Sites
Not
Selected
CP-7 (1)
(2) (3)
Alternate Telecommunications
Services
Not
Selected
CP-8 (1)
(2)
Information System Backup
CP-9
CP-9 (1)
CP-7 (1)
(2) (3)
(4)
CP-8 (1)
(2) (3)
(4)
CP-9 (1)
(2) (3)
Information System Recovery &
Reconstitution
CP-10
IIA Conference February 8, 2005
National Institute
CP-10
CP-10of Standards and
Technology
(1)
59
Security Control Structure
Control Requirements: Assurance
Single assurance requirement for each
baseline
Applies to each control in the baseline
Low impact
Moderate impact
High impact
Additional assurance requirements for
supplementing the high baseline
IIA Conference February 8, 2005
National Institute of Standards and
Technology
60
Assurance Rational/approach
Assurance: Specify developer and implementer
actions during system development process to
ensure controls are implemented correctly,
operating as intended, and producing the desired
outcome with respect to meeting the security
requirements for the system
Assessment: Specify security control assessor’s
actions during the testing and evaluation process
to determine the extent to which the controls are
implemented correctly, operating as intended, and
producing the desired outcome with respect to
meeting the security requirements for the system
IIA Conference February 8, 2005
National Institute of Standards and
Technology
61
Assurance Requirements (1)
Low Baseline
Assurance Requirement: The security control is
in effect and meets explicitly identified
functional requirements in the control
statement.
Supplemental Guidance: For security controls in
the low baseline, the focus is on the control being
in place with the expectation that no obvious
errors exist and that, as flaws are discovered, they
are addressed in a timely manner.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
62
Assurance Requirements (2)
Moderate Baseline
Assurance Requirement: The security control is in effect and meets
explicitly identified functional requirements in the control statement.
The control developer/implementer provides a description of the
functional properties of the control with sufficient detail to permit
analysis and testing of the control. The control
developer/implementer includes as an integral part of the control,
assigned responsibilities and specific actions to ensure that when
the control is implemented, it will meet its required function or
purpose. These actions may include, for example, requiring the
development of records with structure and content suitable to
facilitate making this determination.
Supplemental Guidance: For security controls in the moderate
baseline, the focus is on ensuring correct implementation and operation
of the control. While flaws are still likely to be uncovered (and
addressed expeditiously), the control developer/implementer
incorporates, as part of the control, specific capabilities and produces
specific documentation to ensure the control meets its required
IIA Conference February 8, 2005
National Institute of Standards and
function or purpose
Technology
63
Assurance Requirements (3)
High Baseline
Assurance Requirement: The security control is in effect and meets explicitly
identified functional requirements in the control statement. The control
developer/implementer provides a description of the functional properties and
design/implementation of the control with sufficient detail to permit analysis
and testing of the control (including functional interfaces among control
components). The control developer/implementer includes as an integral part
of the control, assigned responsibilities and specific actions to ensure that
when the control is implemented, it will continuously and consistently (i.e.,
across the information system) meet its required function or purpose and
support improvement in the effectiveness of the control. These actions may
include, for example, requiring the development of records with structure and
content suitable to facilitate making this determination.
Supplemental Guidance: For security controls in the high baseline, the focus is
expanded to require, within the control, the capabilities that are needed to
support ongoing consistent operation of the control and continuous
improvement in the control’s effectiveness. The developer/implementer is
expected to expend significant effort on the design, development,
implementation, and testing of the controls and to produce associated design
and implementation documentation to support these activities. For security
controls in the high baseline, this same documentation is needed by assessors
IIA Conference February 8, 2005
National Institute of Standards and
to analyze and test the internal components of the control
as part of the
overall
Technology
assessment of the control.
64
Assurance Requirements (4)
Additional Requirements Supplementing the High Baseline
Assurance Requirement: The security control is in effect and meets explicitly
identified functional requirements in the control statement. The control
developer/implementer provides a description of the functional properties and
design/implementation of the control with sufficient detail to permit analysis
and testing of the control (including functional interfaces among control
components). The control developer/implementer includes as an integral part
of the control, assigned responsibilities and specific actions to ensure that
when the control is implemented, it will continuously and consistently (i.e.,
across the information system) meet its required function or purpose and
support improvement in the effectiveness of the control. These actions
include, for example, requiring the development of records with structure and
content suitable to facilitate making this determination. The control is
developed in a manner that supports a high degree of confidence that the
control is complete, consistent, and correct.
Supplemental Guidance: The additional high assurance requirements are
intended to supplement the minimum assurance requirements for the high
baseline, when appropriate, in order to protect against threats from highly
skilled, highly motivated, and well-financed threat agents. This level of
protection is required for those information systems where the organization is
not willing to accept the risks associated with the type of threat agents cited
IIA Conference
National Institute of Standards and
above.February 8, 2005
Technology
65
Minimum Baselines
Low
For each family, appropriate controls selected from control
catalogue
Not all controls in family selected
No enhancements
Low Assurance Requirements
Moderate
Includes all controls in Low baseline with (possibly) enhancements
For each family, additional appropriate controls selected from
control catalogue with (possibly) enhancements
Moderate Assurance Requirements
High
Includes all controls in Moderate baseline with (possibly)
additional enhancements
For each family, additional appropriate controls selected from
control catalogue with (possibly) enhancements
IIA Conference February 8, 2005
National Institute of Standards and
High Assurance Requirements
Technology
66
Security Control Selection
Minimum Requirements
• Begin with security categorization triple from
security categorization standard (FIPS 199)
• Reduce triple to a single security category of Low,
Moderate, or High Impact
• Select control baselines for the impact level
• Apply tailoring guidance
• Select minimum assurance requirement for the
impact level
• Final set is input to security control refinement
(i.e., risk analysis process)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
67
Tailoring the initial baselines
• Scoping Guidance Considerations
–
–
–
–
–
–
Technology-related
Infrastructure-related
Public access-related
Scalability-related
Common security control-related
Risk-related /downgrading
• Organization-Defined Security Control
Parameters
• Compensating Security Controls
IIA Conference February 8, 2005
National Institute of Standards and
Technology
68
Requirements Traceability
High Level Security Requirements
Derived from Legislation, Executive Orders, Policies, Directives, Regulations, Standards
Examples: HIPAA, Graham-Leach-Bliley, Sarbanes-Oxley, FISMA, OMB Circular A-130
Security Controls
Security Controls
Security Controls
SP 800-53 / FIPS 200
SP 800-53 / FIPS 200
SP 800-53 / FIPS 200
Enterprise #1
Enterprise #2
Enterprise #3
What set of security controls, if implemented within an information system
and determined to be effective, can show compliance to a particular set of
security requirements?
IIA Conference February 8, 2005
National Institute of Standards and
Technology
69
The Development and Vetting of
SP 800-53
IIA Conference February 8, 2005
National Institute of Standards and
Technology
70
Development Strategy
First, develop mandatory security categorization
standards for federal information and information
systems (FIPS 199)
Next, develop recommended (minimum) security
controls for federal information systems as an 800series guidance document (NIST SP 800-53)
Finally, develop mandatory (minimum) security
control standards for federal information systems
(FIPS 200)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
71
Consensus-Building Process
NIST Special Publication 800-53
Employ extensive vetting process for Special
Publication 800-53
Three full published drafts of document
Three public comment periods to obtain feedback from
the public and private sectors
Carefully assess feedback received during the
public comment periods; incorporate material into
publication, as appropriate
Provide sufficient time for organizations to become
familiar with Special Publication 800-53 before
transitioning to FIPS 200
IIA Conference February 8, 2005
National Institute of Standards and
Technology
72
Special Publication 800-53
Formal and informal comments received from a
wide variety of constituencies in the public and
private sectors including—
Federal, State, and Local Governments
Critical Infrastructure Entities (e.g., power companies,
telecommunications providers)
Fortune 500 Companies
Healthcare Providers
Financial Industry
Consortia (e.g., National Realtors Association)
Private citizens
IIA Conference February 8, 2005
National Institute of Standards and
Technology
73
Significant Comments
Received over 800 comments on the initial public
draft of Special Publication 800-53
Comments indicated that—
Security controls contained too much implementation
detail
Security control baselines (low, moderate, high)
included too many controls for a minimum set
There was insufficient flexibility in the security control
selection process for organizations to effectively apply
the controls in specific operational environments
The “high-water mark” approach required organizations
to employ unnecessary security controls
IIA Conference February 8, 2005
National Institute of Standards and
Technology
74
NIST Response
In response to the initial public comments, NIST
re-engineered Special Publication 800-53
Fundamental changes included—
Streamlining the security control structure and control
content to focus on “token-level” requirements
Redesigning the security control enhancement approach
to facilitate ease-of-use for organizations requiring
additional security controls based on risk assessment
Incorporating scoping guidance to help organizations
effectively apply the NIST guidance in specific
operational environments
Reducing the number of security controls in the control
baselines
IIA Conference February 8, 2005
National Institute of Standards and
Technology
75
Significant
Comments
Received over 400 comments on the second public
draft of Special Publication 800-53
Comments indicated that—
There was overwhelming approval of the reengineered
approach and the simplification of the document
Security control baselines (low, moderate, high) still
contained too many controls for a minimum set
The scoping guidance needed to be strengthened to
added even greater flexibility in the security control
selection and specification process
Organizations wanted the return of the security control
classes (i.e., management, operational, and technical)
which had been previously eliminated
IIA Conference February 8, 2005
National Institute of Standards and
Technology
76
NIST Response
In response to the second round of public
comments, NIST made a few minor modifications—
Changes included—
Modifying the scoping guidance to allow organizations to
eliminate security controls from the control baselines
under strict terms and conditions consistent with FIPS
199 security categorizations
Adjusting the security control baselines again to facilitate
cost-effective, risk-based application of security controls
Adding several new security controls to the control
catalog; eliminating a few controls from the catalog
Expanding the security control mapping table to include
DCID 6/3 and DoD 8500.2
IIA Conference February 8, 2005
National Institute of Standards and
Technology
77
Key Milestones
NIST Special Publication 800-53
Initial Public Draft (October 2003)
Second Public Draft (September 2004)
Final Public Draft (January 2005)
Final Publication (February 2005)
FIPS 200
Initial Public Draft (Projected for May 2005)
Second Public Draft (Projected for August 2005)
Final Publication (Projected for December 2005)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
78
Summary
Public vetting process proved extremely effective
and allowed NIST to build a truly consensus-based
security guideline to serve both public and private
sector needs
Extended development cycle and expanded public
review periods allowed federal agencies to be better
prepare for the transition to FIPS 200, when the
security controls become mandatory
Increasing voluntary acceptance of NIST Special
Publication 800-53 by the private sector will help
provide greater information security for the nation’s
critical infrastructure
IIA Conference February 8, 2005
National Institute of Standards and
Technology
79
Certification and Accreditation
(C&A)
NIST Special Publication 800-37
Guide for the Security Certification and Accreditation
of Federal Information Systems
An Introductory Tutorial
IIA Conference February 8, 2005
National Institute of Standards and
Technology
80
Certification and Accreditation
Supporting FISMA Requirement
Conduct periodic testing and evaluation of the
effectiveness of information security policies,
procedures, and practices (including management,
operational, and technical security controls)
Publication status:
NIST Special Publication 800-37, “Guide for the
Security Certification and Accreditation of Federal
Information Systems”
Final Publication: May 2004
IIA Conference February 8, 2005
National Institute of Standards and
Technology
81
Contents
Introduction
The Fundamentals
The Process
Summary
IIA Conference February 8, 2005
National Institute of Standards and
Technology
82
C&A Part I
Introduction
IIA Conference February 8, 2005
National Institute of Standards and
Technology
83
National Policy
Office of Management and Budget Circular A-130,
Management of Federal Information Resources
requires federal agencies to:
Plan for security
Ensure that appropriate officials are assigned
security responsibility
Authorize system processing prior to operations
and periodically, thereafter
IIA Conference February 8, 2005
National Institute of Standards and
Technology
84
Security Controls
The management, operational, and
technical controls (i.e., safeguards or
countermeasures) prescribed for an
information system to protect the
confidentiality, integrity, and availability
of the system and its information.
-- [FIPS Publication 199]
IIA Conference February 8, 2005
National Institute of Standards and
Technology
85
Key Questions
What security controls are needed to adequately
protect an information system that supports the
operations and assets of the organization?
Have the selected security controls been
implemented or is there a realistic plan for their
implementation?
To what extent are the security controls
implemented correctly, operating as intended, and
producing the desired outcome with respect to
meeting information security requirements?
IIA Conference February 8, 2005
National Institute of Standards and
Technology
86
Certification and Accreditation
FISMA and OMB Requirements
Conduct periodic testing and evaluation of the
effectiveness of information security policies,
procedures, and practices (including management,
operational, and technical security controls)
Publication status:
NIST Special Publication 800-37, “Guide for the
Security Certification and Accreditation of Federal
Information Systems”
Final Publication: May 2004
IIA Conference February 8, 2005
National Institute of Standards and
Technology
87
Purpose and Applicability
Special Publication 800-37
Provides guidelines for certifying and accrediting
information systems supporting the executive
agencies of the federal government
Applies to all federal information systems other
than those systems designated as national security
systems as defined in FISMA
Replaces Federal Information Processing
Standards (FIPS) Publication 102
IIA Conference February 8, 2005
National Institute of Standards and
Technology
88
Significant Benefits
Special Publication 800-37
Helping to achieve more secure information
systems within the federal government by:
Enabling more consistent, comparable, and repeatable
assessments of security controls in federal information
systems
Promoting a better understanding of agency-related
mission risks resulting from the operation of
information systems
Creating more complete, reliable, and trustworthy
information for authorizing officials—facilitating more
informed accreditation decisions
IIA Conference February 8, 2005
National Institute of Standards and
Technology
89
Information Security Programs
Question
How do security certification
and accreditation fit into an agency’s
information security program?
IIA Conference February 8, 2005
National Institute of Standards and
Technology
90
Information Security Programs
Answer
Security certification and accreditation
are important activities that support a
risk management process and are an
integral part of an agency’s overall
information security program.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
91
Risk Management
Links in the Security Chain: Management, Operational, and Technical Controls
Risk assessment
Security planning
Security policies and procedures
Contingency planning
Incident response planning
Physical security
Personnel security
Security assessments
Security accreditation
Access control mechanisms
Identification & authentication mechanisms
(Biometrics, tokens, passwords)
Audit mechanisms
Encryption mechanisms
Firewalls and network security mechanisms
Intrusion detection systems
Anti-viral software
Smart cards
Adversaries attack the weakest link…where is yours?
IIA Conference February 8, 2005
National Institute of Standards and
Technology
92
Managing Agency Risk
Key activities in managing agency-level risk—risk resulting
from the operation of an information system:
Categorize the information system
Select set of minimum (baseline) security controls
Refine the security control set based on risk assessment
Document security controls in system security plan
Implement the security controls in the information system
Assess the security controls (C&A)
Determine agency-level risk and risk acceptability (C&A)
Authorize information system operation (C&A)
Monitor security controls on a continuous basis (C&A)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
93
FISMA Implementation Project:
Risk Management Framework (RMF)
FIPS 199 / SP 800-60
SP 800-53 / FIPS 200
Security Control
Selection
Selects minimum security controls (i.e.,
safeguards and countermeasures) planned or
in place to protect the information system
Security
Categorization
Defines category of information
system according to potential
impact of loss
SP 800-37
Security Control
Monitoring
Continuously tracks changes to the information
system that may affect security controls and
assesses control effectiveness
SP 800-53 / FIPS 200 / SP 800-30
SP 800-37
Security Control
Refinement
System
Authorization
Uses risk assessment to adjust minimum control
set based on local conditions, required threat
coverage, and specific agency requirements
Determines risk to agency operations, agency
assets, or individuals and, if acceptable,
authorizes information system processing
SP 800-18
Security Control
Documentation
In system security plan, provides a an
overview of the security requirements for the
information system and documents the
security controls planned or in place
IIA Conference February 8, 2005
SP 800-64/SP 800-70
Security Control
Implementation
Implements security controls in new
or legacy information systems;
implements security configuration
checklists
SP 800-53A / SP 800-37
Security Control
Assessment
Determines extent to which the security
controls are implemented correctly, operating
as intended, and producing desired outcome
with respect to meeting security requirements
National Institute of Standards and
Technology
94
The Desired End State
Security Visibility Among Business/Mission Partners
Organization One
Information
System
Organization Two
Business / Mission
Information Flow
System Security Plan
Security Assessment Report
Information
System
System Security Plan
Security Information
Security Assessment Report
Plan of Action and Milestones
Plan of Action and Milestones
Determining the risk to the first
organization’s operations and assets and
the acceptability of such risk
Determining the risk to the second
organization’s operations and assets and
the acceptability of such risk
The objective is to achieve visibility into prospective business/mission partners information
security programs BEFORE critical/sensitive communications begin…establishing levels of
security due diligence.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
95
C&A Part II
The Fundamentals
IIA Conference February 8, 2005
National Institute of Standards and
Technology
96
Security Accreditation
Official management decision given by a
senior agency official to authorize operation of
an information system and to explicitly accept
the risk to agency operations (including mission,
functions, image, or reputation), agency assets,
or individuals, based on the implementation of
an agreed upon set of security controls.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
97
Security Certification
Comprehensive assessment of the management,
operational, and technical security controls in an
information system, made in support of security
accreditation, to determine the extent to which the
controls are implemented correctly, operating as
intended, and producing the desired outcome with
respect to meeting the security requirements for
the system.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
98
Key Roles
Authorizing Official
Authorizing Official Designated Representative
Chief Information Officer
Senior Agency Information Security Officer
Information System Owner
Information System Security Officer
Certification Agent
User Representatives
IIA Conference February 8, 2005
National Institute of Standards and
Technology
99
Authorizing Official
Reviews and approves the security categorizations of
information systems
Reviews and approves system security plans
Determines agency-level risk from information generated
during the security certification
Makes accreditation decisions and signs associated
transmittal letters for accreditation packages (authorizing
official only)
Reviews security status reports from continuous
monitoring operations; initiates reaccreditation actions
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
0
Designated Representative
Selected by the authorizing official to coordinate and
carry out the necessary activities required during the
security certification and accreditation process
Empowered to make certain decisions with regard to the:
Planning and resourcing of the security certification and accreditation
activities
Acceptance of the system security plan
Determination of risk to agency operations, assets, and individuals
Prepares accreditation decision letter
Obtains authorizing official’s signature on the
accreditation decision letter and transmits accreditation
package to appropriate agency officials
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
1
Chief Information Officer
Designates a senior agency information security officer
Develops and maintains information security policies,
procedures, and control techniques to address all
applicable requirements
Trains and oversees personnel with significant
responsibilities for information security
Assists senior agency officials concerning their security
responsibilities
Coordinates with other senior agency officials, reporting
annually to the agency head on the effectiveness of the
agency information security program
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
2
Senior Agency Information
Security Officer
Serves in a position with primary responsibilities
and duties related to information security
Carries out the Chief Information Officer
responsibilities under FISMA
Possesses professional qualifications required to
administer information security program functions
Heads an office with the mission and resources to
assist in ensuring agency compliance with FISMA
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
3
Information System Owner
Procures, develops, integrates, modifies, operates or
maintains an information system
Prepares system security plan and conducts risk assessment
Informs agency officials of the need for certification and
accreditation; ensures appropriate resources are available
Provides necessary system-related documentation to the
certification agent
Prepares plan of action and milestones to reduce or
eliminate vulnerabilities in the information system
Assembles final accreditation package and submits to
authorizing official
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
4
Information System Security Officer
Serves as principal staff advisor to the system owner on
all matters involving the security of the information
system
Manages the security aspects of the information system
and, in some cases, oversees the day-to-day security
operations of the system
Assists the system owner in:
Developing and enforcing security policies for the information
system
Assembling the security accreditation package
Managing and controlling changes to the information system
and assessing the security impacts of those changes
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
5
Certification Agent
Provides an independent assessment of the system
security plan
Assesses the security controls in the information system
to determine the extent to which the controls are:
Implemented correctly;
Operating as intended; and
Producing the desired outcome with respect to meeting the
security requirements of the system
Provides recommended corrective actions to reduce or
eliminate vulnerabilities in the information system
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
6
User Representatives
Represent the operational interests and mission needs of
the user community
Identify mission and operational requirements
Serve as liaisons for the user community throughout the
system development life cycle
Assist in the security certification and accreditation
process, when needed
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
7
Other Supporting Roles
Information Owner
Operations Manager
Facilities Manager
System Administrator
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
8
Accreditation Boundaries
Uniquely assigning information resources to an
information system defines the security
accreditation boundary for that system
Agencies have great flexibility in determining
what constitutes an information system and the
resulting accreditation boundary that is
associated with that system
IIA Conference February 8, 2005
National Institute of Standards and
Technology
10
9
Accreditation Boundaries
If a set of information resources is identified as an
information system, the resources should generally
be under the same direct management control
Consider if the information resources being
identified as an information system—
Have the same function or mission objective and
essentially the same operating characteristics and security
needs
Reside in the same general operating environment (or in
the case of a distributed information system, reside in
various locations with similar operating environments)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
0
Large and Complex Systems
Accreditation Boundary
Agency General Support System
Subsystem
Component
Subsystem
Component
Subsystem
Component
System Guard
Local Area Network
Alpha
Local Area Network
Bravo
• System security plan reflects information system decomposition with adequate security
controls assigned to each subsystem component
• Security assessment methods and procedures tailored for the security controls in each
subsystem component and for the combined system-level controls
• Security certification performed on each subsystem component and on system-level controls
not covered by subsystem certifications
• Security accreditation performed on the information system as a whole
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
1
Common Security Controls
Common security controls are those controls that
can be applied to one or more agency information
systems and have the following properties:
The development, implementation, and assessment of
common security controls can be assigned to
responsible officials or organizational elements (other
than the information system owner)
The results from the assessment of the common
security controls can be reused in security certifications
and accreditations of agency information systems
where those controls have been applied
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
2
Common Security Controls
Identification of common security controls is an
agency-level activity in collaboration with Chief
Information Officer, senior agency information
security officer, authorizing officials, information
system owners, and information system security
officers
Potential for significant cost savings for the
agency in security control development,
implementation, and assessment
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
3
Common Security Controls
Common security controls can be applied
agency-wide, site-wide, or to common
subsystems and assessed accordingly—
For example:
*
**
Contingency planning
Incident response planning
Security training and awareness
Physical and personnel security *
Common hardware, software, or firmware **
Related to the concept of site certification in certain communities
Related to the concept of type certification in certain communities
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
4
Common Security Controls
Responsibility of Information System Owners
• Common security controls
developed, implemented, and
assessed one time by designated
agency official(s)
Example: Moderate Impact
Agency Information Systems
• Maximum re-use of assessment
evidence during security certification
and accreditation of information
systems
• Security assessment reports
provided to information system
owners to confirm the security status
of common security controls
• Assessments of common security
controls not repeated; only system
specific aspects when necessary
IIA Conference February 8, 2005
System
Specific
Security
Controls
• Development and implementation
cost amortized across all agency
information systems
Common
Security
Controls
• Results shared among all
information system owners and
authorizing officials where
common security controls are
applied
Responsibility of Designated Agency Official Other
Than Information System Owner (e.g., Chief
Information Officer, Facilities Manager, etc.)
National Institute of Standards and
Technology
11
5
Accreditation Decisions
Authorization To Operate
Interim Authorization To Operate
Denial of Authorization to Operate
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
6
Authorization to Operate
Risk to agency operations, agency assets, or
individuals is deemed acceptable to the
authorizing official
Information system is accredited without any
significant restrictions or limitations on its
operation
Authorizing officials may recommend specific
actions be taken to reduce or eliminate identified
vulnerabilities, where it is cost effective to do so
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
7
Interim Authorization To Operate
Risk to agency operations, agency assets, or
individuals is not deemed acceptable to the
authorizing official, but there is an overarching
mission necessity to place the information system
into operation or continue its operation
Significant deficiencies in the security controls in
the information system but the deficiencies can be
addressed in a timely manner
Acknowledges greater risk to the agency for a
limited period of time
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
8
Interim Authorization To Operate
Limited authorization to operate the information
system under specific terms and conditions
established by the authorizing official
Information system is not accredited during the
period of limited authorization to operate
At the end of the period of limited authorization,
the information system should either meet the
requirements for being authorized or not be
authorized for further operation
IIA Conference February 8, 2005
National Institute of Standards and
Technology
11
9
Denial of Authorization to Operate
The residual risk to the agency’s operations or
assets is deemed unacceptable to the authorizing
official
Information system is not accredited and should
not be placed into operation—or for an
information system currently in operation, all
activity should be halted
Major deficiencies in the security controls in the
information system—corrective actions should be
initiated immediately
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
0
Accreditation Package
System security plan
Security assessment report
Plan of action and milestones
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
1
Accreditation Package
Documents the results of the security certification
Provides the authorizing official with the essential
information needed to make a credible risk-based
decision on whether to authorize operation of the
information system
Uses inputs from the information system security
officer and the certification agent
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
2
System Security Plan
Prepared by the information system owner
Provides an overview of the security requirements
for the information system and describes the
security controls in place or planned for meeting
those requirements
Contains (either as supporting appendices or as
references) other key security-related documents
for the information system (e.g., risk assessment,
contingency plan, incident response plan, system
interconnection agreements)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
3
Security Assessment Report
Prepared by the certification agent
Provides the results of assessing the security
controls in the information system to determine
the extent to which the controls are:
Implemented correctly
Operating as intended
Producing the desired outcome with respect to meeting
the system security requirements
Contains a list of recommended corrective actions
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
4
Plan of Action and Milestones
Prepared by the system owner
Reports progress made on current outstanding
items listed in the plan
Addresses vulnerabilities in the information
system discovered during certification, security
impact analysis, or security control monitoring
Describes how the information system owner
intends to address those vulnerabilities (i.e.,
reduce, eliminate, or accept vulnerabilities)
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
5
Accreditation Decision Letter
Constructed from information provided by the
information system owner in the accreditation
package
Consists of:
Accreditation decision
Supporting rationale for the decision
Specific terms and conditions imposed on the
system owner
The contents of security certification and accreditation-related documentation
(especially information dealing with system vulnerabilities) should be marked and
protected appropriately in accordance with agency policy.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
6
C&A Part III
The Process
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
7
The Process
Initiation Phase
Security Certification Phase
Security Accreditation Phase
Continuous Monitoring Phase
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
8
Initiation Phase
Major Tasks and Subtasks
Task 1: Preparation
Subtask 1.1: Information System Description
Subtask 1.2: Security Categorization
Subtask 1.3: Threat Identification
Subtask 1.4: Vulnerability Identification
Subtask 1.5: Security Control Identification
Subtask 1.6: Initial Risk Determination
Task 2: Notification and Resource Identification
Subtask 2.1: Notification
Subtask 2.2: Planning and Resources
IIA Conference February 8, 2005
National Institute of Standards and
Technology
12
9
Initiation Phase
Major Tasks and Subtasks
Task 3: System Security Plan Analysis, Update,
and Acceptance
Subtask 3.1: Security Categorization Review
Subtask 3.2: System Security Plan Analysis
Subtask 3.3: System Security Plan Update
Subtask 3.4: System Security Plan Acceptance
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
0
Security Certification Phase
Major Tasks and Subtasks
Task 4: Security Control Assessment
Subtask 4.1: Documentation and Supporting Materials
Subtask 4.2: Methods and Procedures
Subtask 4.3: Security Assessment
Subtask 4.4: Security Assessment Report
Task 5: Security Certification Documentation
Subtask 5.1: Findings and Recommendations
Subtask 5.2: System Security Plan Update
Subtask 5.3: Plan of Action and Milestones Preparation
Subtask 5.4: Accreditation Package Assembly
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
1
Security Accreditation Phase
Major Tasks and Subtasks
Task 6: Accreditation Decision
Subtask 6.1: Final Risk Determination
Subtask 6.2: Risk Acceptability
Task 7: Accreditation Documentation
Subtask 7.1: Accreditation Package Transmission
Subtask 7.2: System Security Plan Update
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
2
Continuous Monitoring Phase
Major Tasks and Subtasks
Task 8: Configuration Management and Control
Subtask 8.1: Documentation of System Changes
Subtask 8.2: Security Impact Analysis
Task 9: Security Control Monitoring
Subtask 9.1: Security Control Selection
Subtask 9.2: Selected Security Control Assessment
Task 10: Status Reporting and Documentation
Subtask 10.1: System Security Plan Update
Subtask 10.2: Plan of Action and Milestones Update
Subtask 10.3: Status Reporting
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
3
Certification and Accreditation
For Low Impact Information Systems
Incorporates the use of self-assessment activities
Reduces the associated level of supporting
documentation and paperwork
Decreases the time spent conducting assessmentrelated activities
Significantly reduces costs to the agency without
increasing agency-level risk or sacrificing the
overall security of the information system.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
4
C&A Part IV
Summary
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
5
Special Publication 800-37
Intended to promote and facilitate—
More consistent, comparable, and repeatable
assessments of information systems
More complete and reliable security-related
information for authorizing officials
A better understanding of complex information
systems and associated risks and vulnerabilities
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
6
Security Control Assessments
(Currently in-development)
NIST Special Publication 800-53A: Guide for
Assessing the Security Controls in Federal
Information Systems
A Framework for Developing Assessment Procedures for controls in SP 800-53
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
7
Security Control Assessment
FISMA Requirement
Conduct periodic testing and evaluation of the
effectiveness of information security policies,
procedures, and practices (including management,
operational, and technical security controls)
Publication status:
NIST Special Publication 800-53A, “Guide for
Assessing the Security Controls in Federal Information
Systems”
Initial Public Draft: Winter 2004-05
IIA Conference February 8, 2005
National Institute of Standards and
Technology
13
8
FISMA Implementation Project:
Risk Management Framework (RMF)
FIPS 199 / SP 800-60
SP 800-53 / FIPS 200
Security Control
Selection
Selects minimum security controls (i.e.,
safeguards and countermeasures) planned or
in place to protect the information system
Security
Categorization
Defines category of information
system according to potential
impact of loss
SP 800-37
Security Control
Monitoring
Continuously tracks changes to the information
system that may affect security controls and
assesses control effectiveness
SP 800-53 / FIPS 200 / SP 800-30
SP 800-37
Security Control
Refinement
System
Authorization
Uses risk assessment to adjust minimum control
set based on local conditions, required threat
coverage, and specific agency requirements
Determines risk to agency operations, agency
assets, or individuals and, if acceptable,
authorizes information system processing
SP 800-18
Security Control
Documentation
In system security plan, provides a an
overview of the security requirements for the
information system and documents the
security controls planned or in place
IIA Conference February 8, 2005
SP 800-64/SP 800-70
Security Control
Implementation
Implements security controls in new
or legacy information systems;
implements security configuration
checklists
SP 800-53A / SP 800-37
Security Control
Assessment
Determines extent to which the security
controls are implemented correctly, operating
as intended, and producing desired outcome
with respect to meeting security requirements
National Institute of Standards and
Technology
13
9
Contingency Planning Family
Contingency Planning Policy &
Procedures
CP-1
CP-1
CP-1
Contingency Plan
CP-2
CP-2 (1)
CP-2 (1)
Contingency Training
Not
Selected
CP-3
CP-3 (1)
(2)
Contingency Plan Testing
Not
Selected
CP-4 (1)
CP-4 (1)
(2) (3)
Contingency Plan Update
CP-5
CP-5
CP-5
Alternate Storage Sites
Not
Selected
CP-6 (1)
CP-6 (1)
(2) (3)
Alternate Processing Sites
Not
Selected
CP-7 (1)
(2) (3)
Alternate Telecommunications
Services
Not
Selected
CP-8 (1)
(2)
Information System Backup
CP-9
CP-9 (1)
CP-7 (1)
(2) (3)
(4)
CP-8 (1)
(2) (3)
(4)
CP-9 (1)
(2) (3)
Information System Recovery &
Reconstitution
CP-10
IIA Conference February 8, 2005
National Institute
CP-10
CP-10of Standards and
Technology
(1)
14
0
The Conceptual Model
Framework
Security
Control
Number
Baseline
Assessment
Methods
Interview
Examine
Test
Input
Assessment
Procedure
Output
Process
Example: First security control in Contingency Planning Family
{CP-1, low} {Interview, Examine} Assessment Procedure CP-1
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
1
Assessment Methods
Interview
The process of conducting focused discussions with organizational
personnel to facilitate understanding, achieve clarification, or obtain
evidence
Examine
The process of checking, inspecting, reviewing, observing, studying,
or analyzing an assessment object to generate a verdict or to reach a
conclusion
Test
The process of exercising an assessment object under specified
conditions, observing and recording the results, and comparing the
actual with the expected behavior
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
2
Assessment Objects
• Specifications: primarily a document-type control
– Examples: policies, plans, procedures, system requirements,
designs
• Activities: primarily a people-oriented control but
may be supported by IT mechanisms
– Examples: system operations, system administration, management,
exercises, drills
• Mechanisms: primarily implemented in hardware,
software, firmware but may require human
interaction/support
– Examples: I&A, Audit Trails, Access Control, physical devices,
communications protection/cryptography
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
3
Interview Attributes
Coverage
Addresses the types of individuals to be interviewed (by organizational
roles and associated responsibilities) and the number of individuals to
be interviewed (by type).
Approach
Addresses the formality of the interview process. There are two
potential values for the approach attribute: (i) informal/unstructured;
and (ii) formal/structured.
Depth
Addresses the rigor of and level of detail in the interview process.
There are three possible values for the depth attribute: (i) cursory; (ii)
exploratory; and (iii) comprehensive.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
4
Examine Attributes
Coverage
Addresses the types of assessment objects to be examined and the
number of objects to be examined (by type).
Approach
Addresses the formality of the examination process. There are two
potential values for the approach attribute: (i) informal/unstructured;
and (ii) formal/structured.
Depth
Addresses the rigor of and level of detail in the examination process.
There are three possible values for the depth attribute: (i) cursory; (ii)
exploratory; and (iii) comprehensive.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
5
Test Attributes
Scope
Addresses the types of testing to be conducted. There are three
potential values for the scope attribute: (i) black-box testing; (ii) graybox testing; and (iii) penetration testing.
Coverage
Approach
Depth
Addresses the types of assessment objects to be tested and the number
of objects to be tested (by type).
Addresses the formality of the testing process. There are two potential
values for the approach attribute: (i) informal/unstructured; and (ii)
formal/structured.
Addresses the rigor of and level of detail in the testing process. There
are three possible values for the depth attribute: (i) cursory; (ii)
exploratory; and (iii) comprehensive.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
6
Assurance Attribute
Applicable to all assessment methods
Addresses the expectation of the assessor in
assessing the implementation of the security
control
Values for the assurance attributes are
derived directly from the minimum
assurance requirements described in NIST
Special Publication 800-53
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
7
Assurance Attribute
Low Impact Systems
The focus is on the control being in place with the expectation that no
obvious errors exist and that, as flaws are discovered, they are addressed in a
timely manner.
Moderate Impact Systems
The focus is on ensuring that the control is implemented correctly and
operating as intended. While flaws are still likely to be uncovered (and
addressed expeditiously), the control developer/implementer incorporates, as
part of the control, specific capabilities to ensure the control meets its
function or purpose.
High Impact Systems
The focus is expanded to require, within the control, the capabilities that are
needed to support continuous and consistent operation of the control and to
support continuous improvement in the control’s effectiveness.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
8
Assessment Expectations
Low Impact Systems
Interviews, examinations, and tests are conducted in an informal,
unstructured manner at a cursory level of depth and seek to ensure that there
are no obvious errors in the security control
Moderate Impact Systems
Interviews, examinations, and tests are conducted in a formal, structured
manner at an exploratory level of depth, and seek to ensure that the security
control is implemented correctly and operating as intended
High Impact Systems
Interviews, examinations, and tests are conducted in a formal, structured
manner at a comprehensive level of depth, and seek to ensure that the
security control is implemented correctly and operating as intended on a
continuous and consistent basis with continuous improvement in control
effectiveness
IIA Conference February 8, 2005
National Institute of Standards and
Technology
14
9
Development Methodology
Building an assessment procedure for every
security control in SP 800-53 catalog and for every
control enhancement
Tailoring the assessment procedures according to
impact level (low, moderate, high)
Assessment procedures have a well-defined
numbering system to support potential tool
development efforts
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
0
Publication Options and Schedule
Several options under consideration for SP 800-53A
publication
Option 1: Publish the assessment procedures for security
controls employed in low impact systems first; conduct
public review; finish the remaining procedures for
moderate and high
Option 2: Publish all assessment procedures for security
controls at the same time; conduct public review
Initial Public Draft: March-April 2005
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
1
Methods: Interview, Examine, Test
impact level
attribute
values
low
moderate
high
Defined
objects/
numbers
Defined
objects/
numbers
Defined
objects/
numbers
Coverage
Specified assessment objects to be assessed (i.e.,
specifications, activities, mechanisms, or artifacts)
and number of objects to be assessed
Scope
(Test only)
Black Box
√
√
√
Gray Box
---
√
√
Penetration
---
---
√
Informal, unstructured
√
---
---
Formal, structured
---
√
√
Cursory
√
---
---
Exploratory
---
√
---
Comprehensive
---
---
√
No obvious errors
√
√
√
Correct implementation, operating as intended
---
√
√
Approach
Depth
Assurance
IIA Conference February 8, 2005
Ongoing consistent operation and continuous
improvement
National Institute of Standards and
-----Technology
√
15
2
The Conceptual Model
Framework
Security
Control
Number
Baseline
Assessment
Methods
Interview
Examine
Test
Input
Assessment
Procedure
Output
Process
Example: First security control in Contingency Planning Family
{CP-1, low} {Interview, Examine} Assessment Procedure CP-1
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
3
CP-1
CONTINGENCY PLANNING POLICY AND PROCEDURES
Control: The organization develops, disseminates, and periodically reviews/updates: (i) a formal, documented, contingency planning policy
that addresses purpose, scope, roles, responsibilities, and compliance; and (ii) formal, documented procedures to facilitate the implementation
of the contingency planning policy and associated contingency planning controls.
ASSESSMENT METHODS: Interview, Examine
ASSESSMENT OBJECTS: Specifications (policy, procedures)
Apply
ASSESSMENT PROCEDURES
Low
CP-1.1. Interview the Chief Information Officer, Chief Information Security Officer,
or their designated representatives to determine which elements of the organization
are responsible for developing, disseminating, reviewing, and updating the
contingency planning policy and associated procedures for implementing the policy.
Low
CP-1.2. Interview the Information System Owner (or appropriate/equivalent party) to identify and
arrange access to: (i) the contingency plan for the information system and any associated
contingency-related procedures; (ii) individuals or groups responsible for the development,
implementation, operation, and maintenance of the contingency plan and procedures; (iii) any
materials (including records) associated with the implementation of the continginency plan or
contingency operations; and (iv) guidance on the number/percentage of objects to be assessed by
type.
Low
CP-1.3. Examine the contingency planning policy to determine if the policy
addresses purpose, scope, roles, responsibilities, and compliance for contingency
operations.
Low
FS
PS
CP-1.4. Interview selected organizational personnel with contingency planning
responsibilities to determine if the contingency planning policy is: (i) disseminated to
IIA Conference February 8, 2005
National Institute of Standards and
appropriate elements within the organization; (ii) reviewed by responsible parties
Technology
within the organization; and (iii) updated, if review indicates updates are required.
NS
15
4
Low
CP-1.5. Examine contingency planning policy for evidence (e.g., policy
version notation or record of updates) that the policy is being updated
periodically (if policy review indicates updates are required).
Low
CP-1.6. Examine contingency planning procedures to determine if the
necessary procedures to implement the contingency planning policy are
available.
Low
CP-1.7. Interview selected organizational personnel with contingency
planning responsibilities to determine if the contingency planning
procedures are: (i) disseminated to appropriate elements within the
organization; (ii) reviewed by responsible parties within the organization;
and (iii) updated, if review indicates updates are required.
Low
CP-1.8. Examine contingency planning procedures for evidence (e.g.,
procedure version notation or record of updates) that the procedures are
being updated (if procedure review indicates updates are required).
Low
CP-1.9. Interview selected organizational personnel with responsibility
for implementing contingency planning procedures to determine if the
procedures are in effect.
Control Enhancements:
None.
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
5
Contact Information
100 Bureau Drive Mailstop 8930
Gaithersburg, MD USA 20899-8930
Project Manager
Administrative Support
Dr. Ron Ross
(301) 975-5390
[email protected]
Peggy Himes
(301) 975-2489
[email protected]
Senior Information Security Researchers and Technical Support
Marianne Swanson
(301) 975-3293
[email protected]
Dr. Stu Katzke
(301) 975-4768
[email protected]
Pat Toth
(301) 975-5140
[email protected]
Arnold Johnson
(301) 975-3247
[email protected]
Curt Barker
(301) 975-4768
[email protected]
Information and Feedback
Web: csrc.nist.gov/sec-cert
Comments: [email protected]
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
6