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
ron.ross@nist.gov
Peggy Himes
(301) 975-2489
peggy.himes@nist.gov
Senior Information Security Researchers and Technical Support
Marianne Swanson
(301) 975-3293
marianne.swanson@nist.gov
Dr. Stu Katzke
(301) 975-4768
skatzke@nist.gov
Pat Toth
(301) 975-5140
patricia.toth@nist.gov
Arnold Johnson
(301) 975-3247
arnold.johnson@nist.gov
Curt Barker
(301) 975-4768
wbarker@nist.gov
Information and Feedback
Web: csrc.nist.gov/sec-cert
Comments: sec-cert@nist.gov
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
ron.ross@nist.gov
Peggy Himes
(301) 975-2489
peggy.himes@nist.gov
Senior Information Security Researchers and Technical Support
Marianne Swanson
(301) 975-3293
marianne.swanson@nist.gov
Dr. Stu Katzke
(301) 975-4768
skatzke@nist.gov
Pat Toth
(301) 975-5140
patricia.toth@nist.gov
Arnold Johnson
(301) 975-3247
arnold.johnson@nist.gov
Curt Barker
(301) 975-4768
wbarker@nist.gov
Information and Feedback
Web: csrc.nist.gov/sec-cert
Comments: sec-cert@nist.gov
IIA Conference February 8, 2005
National Institute of Standards and
Technology
15
6