Study Guide for FITSP-Manager
As prepared by
Stacy Myers
John Kressel
Ron Parvin
Disclaimer: The authors of this Study Guide created it as a guide to the FITSI-M exam
and has allowed FITSI to distribute it to exam candidates. Neither FITSI nor the authors
guarantee the completeness or correctness of this guide. The study guide is meant to
give candidates the authors personal impression of what may be required to pass the
FITSI-M exam. Any questions pertaining to the Study Guide should be directed to
Maribeth.Kuzmicki@FITSI.org.
1
Introduction ..................................................................................................................... 7
Purpose ........................................................................................................................... 7
Assumptions.................................................................................................................... 7
Study Guide Structure ..................................................................................................... 7
Exam Structure ............................................................................................................... 7
Domain 1 NIST Special Publications ............................................................................... 8
21 FITSI IT Security Topic Areas Special Publications ................................................... 8
1. Access Control ...................................................................................................................................................8
2. Application Security ..........................................................................................................................................9
3. Audit and Accountability ...................................................................................................................................9
4. Awareness and Training .................................................................................................................................. 10
5. Configuration Management ............................................................................................................................. 10
6. Contingency Planning ...................................................................................................................................... 10
7. Data Security ................................................................................................................................................... 12
8. Identification and Authentication .................................................................................................................... 12
9. Incident Response ............................................................................................................................................ 12
10. Maintenance ................................................................................................................................................... 12
11. Media Protection............................................................................................................................................ 13
12. Personnel Security ......................................................................................................................................... 13
13. Physical and Environmental Protection ......................................................................................................... 13
14. Planning ......................................................................................................................................................... 13
15. Program Management .................................................................................................................................... 13
16. Regulatory and Standards Compliance .......................................................................................................... 14
17. Risk Assessment ............................................................................................................................................ 14
18. Security Assessments and Authorization ....................................................................................................... 14
19. System and Communication Protection ......................................................................................................... 15
20. System and Information Integrity .................................................................................................................. 15
21. System and Services Acquisition ................................................................................................................... 15
Role-based Special Publications (per manager role identified in NIST SP 800-16 Rev1) ........... 16
Additional Special Publications (added by FITSI) .......................................................... 16
Domain 2 NIST Federal Information Processing Standards (FIPS) .............................. 17
FIPS 113 Computer Data Authentication, (1985) .......................................................... 17
FIPS 140-2 Security Requirements for Cryptographic Modules .................................... 18
FIPS 180-3 Secure Hash Standard, (2008)................................................................... 23
FIPS 181 Automated Password Generator (APG), (1993) ............................................ 24
FIPS 185 Escrowed Encryption Standard (EES), (1994) .............................................. 25
FIPS 186-3 Digital Signature Standard (DSS), (2009) .................................................. 27
FIPS 188 Standard Security Label for Information Transfer, (1994) ............................. 30
FIPS 190 Guideline for use of Advanced Authentication Technology Alternatives, (1994)
...................................................................................................................................... 31
FIPS 191 Guideline for the Analysis Local Area Network Security, (1994) ................... 33
FIPS 196 Entity Authentication Using Public Key Cryptography, (1997) ....................... 35
2
FIPS 197 Advanced Encryption Standard (AES) .......................................................... 36
FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC) .......................... 37
FIPS 199 Guideline for use of Advanced Authentication Technology Alternatives,
(1994) ............................................................................................................................ 39
FIPS 200 Minimum Security Requirements for Federal Information and Information
Systems, (2006) ............................................................................................................ 41
FIPS 201-1 Personal Identity Verification (PIV) of Federal Employees and Contractors,
(2006) ............................................................................................................................ 43
Domain 3 – NIST Control Families ................................................................................ 45
Domain 4 Governmental Laws and Regulations ........................................................... 65
1. Acts of Congress ....................................................................................................... 65
The Privacy Act Of 1974 ..................................................................................................................................... 65
Paperwork Reduction Act of 1980....................................................................................................................... 67
Computer Security Act of 1987 ........................................................................................................................... 67
Chief Financial Officers Act (1990) .................................................................................................................... 67
Government Performance and Results Act (1993) .............................................................................................. 68
Government Paperwork Elimination Act ............................................................................................................. 69
Government Information Security Reform Act - (GISRA, 2000) ....................................................................... 69
Federal Information Security Management Act of 2002 ..................................................................................... 70
Health Insurance Portability and Accountability Act (1996) ............................................................................... 73
HITECH Act: Privacy Requirements .................................................................................................................. 79
Clinger–Cohen Act (1996) .................................................................................................................................. 80
National Defense Authorization Act for Fiscal Year 1996 .................................................................................. 81
2. OMB Memoranda ...................................................................................................... 86
M-09-32 Update on the Trusted Internet Connections Initiative ......................................................................... 87
M-09-29 FY 2009 Reporting Instructions for the Federal Information Security Management Act and Agency
Privacy Management ........................................................................................................................................... 88
M-09-02 Information Technology Management Structure and Governance Framework .................................... 89
M-08-27 Guidance for Trusted Internet Connection (TIC) Compliance ............................................................. 91
M-08-23 Securing the Federal Government’s Domain Name System Infrastructure .......................................... 91
M-08-22 Guidance on the Federal Desktop Core Configuration (FDCC) ........................................................... 93
M-08-21 FY 2008 Reporting Instructions for the Federal Information Security Management Act and Agency
Privacy Management ........................................................................................................................................... 97
M-08-16 Guidance for Trusted Internet Connection Statement of Capability Form (SOC) ................................ 99
M-08-09 New FISMA Privacy Reporting Requirements for FY 2008 .............................................................. 100
M-08-05 ―Implementation of Trusted Internet Connections (TIC)‖ ................................................................. 100
M-08-01 HSPD-12 Implementation Status ........................................................................................................ 101
M-07-19 FY 2007 Reporting Instructions for the Federal Information Security Management Act and Agency
Privacy Management ......................................................................................................................................... 102
M-07-18 Ensuring New Acquisitions Include Common Security Configurations ............................................ 102
M-07-16 Safeguarding Against and Responding to the Breach of Personally Identifiable Information ........... 103
M-07-11 Implementation of Commonly Accepted Security Configurations for Windows Operating Systems 104
3
M-07-06 Validating and Monitoring Agency Issuance of Personal Identity Verification Credentials .............. 104
M-06-20 Recommendations for Identity Theft Related Data Breach Notification ............................................ 106
M-06-19 Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for
Security in Agency Information Technology Investments ................................................................................ 107
M-06-18 Acquisition of Products and Services for Implementation of HSPD-12............................................. 108
M-06-16 Protection of Sensitive Agency Information ...................................................................................... 109
M-06-15 Safeguarding Personally Identifiable Information .............................................................................. 112
M-06-06 Sample Privacy Documents for Agency Implementation of Homeland Security Presidential Directive
(HSPD) 12 ......................................................................................................................................................... 112
M-05-24 Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a Common
Identification Standard for Federal Employees and Contractors ....................................................................... 113
M-05-16 Regulation on Maintaining Telecommunication Services During a Crisis or Emergency in Federallyowned Buildings ................................................................................................................................................ 114
M-05-15 FY 2005 Reporting Instructions for the Federal Information Security Management Act and Agency
Privacy Management ......................................................................................................................................... 115
M-05-08 Designation of Senior Agency Officials for Privacy .......................................................................... 116
M-05-05 Electronic Signatures: How to Mitigate the Risk of Commercial Managed Services ........................ 116
M-05-04 Policies for Federal Agency Public Websites ..................................................................................... 117
M-04-26 Personal Use Policies and "File Sharing" Technology ....................................................................... 118
M-04-25 FY 2004 Reporting Instructions for the Federal Information Security Management Act and Updated
Guidance on Quarterly IT Security Reporting ................................................................................................... 119
M-04-16 Software Acquisition ......................................................................................................................... 119
M-04-15 Development of Homeland Security Presidential Directive (HSPD) - 7 Critical Infrastructure
Protection Plans to Protect Federal Critical Infrastructures and Key Resources ............................................... 120
M-04-04 E-Authentication Guidance for Federal Agencies .............................................................................. 121
M-03-22 OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002 .......... 121
M-03-19 FY 2003 Reporting Instructions for the Federal Information Security Management Act and updated
Guidance on Quarterly IT Security Reporting ................................................................................................... 121
M-03-18 Implementation Guidance for the E-Government Act of 2002........................................................... 122
M-02-09 Reporting Instructions for the Government Information Security Reform Act and Updated Guidance
on Security Plans of Action and Milestones ...................................................................................................... 123
M-02-01 Guidance for Preparing and Submitting Security Plans of Action and Milestones ............................ 124
M-01-05 Guidance on Inter-Agency Sharing of Personal Data - Protecting Personal Privacy ......................... 125
M-00-13 Privacy Policies and Data Collection on Federal Web Sites .............................................................. 126
M-00-10 OMB Procedures and Guidance on Implementing the Government Paperwork Elimination Act ...... 127
M-00-07 Incorporating and Funding Security in Information Systems Investments ......................................... 128
M-00-01 Day One Planning and Request for Updated Business Continuity and Contingency Plans ............... 131
M-99-20 Security of Federal Automated Information Resources...................................................................... 132
M-99-18 Privacy Policies on Federal Web Sites ............................................................................................... 133
M-99-16 Business Continuity and Contingency Planning for the Year 2000 .................................................... 134
3. OMB Circulars ......................................................................................................... 136
4
Office of Management and Budget Circular A-130, Appendix III, Security of Federal Information Resources
........................................................................................................................................................................... 136
Executive Office of the President, Office of Management and Budget, Office of Federal Procurement Policy,
Emergency Acquisitions, May 2007 .................................................................................................................. 137
4. Homeland Security President Directives ................................................................. 138
HSPD-3 Homeland Security Advisory System ................................................................................................ 138
HSPD-5 Management of Domestic Incidents ................................................................................................... 141
HSPD-7 Critical Infrastructure Identification, Prioritization, and Protection ................................................... 145
HSPD-8 National Preparedness ........................................................................................................................ 151
HSPD-12 Policy for a Common Identification Standard for Federal Employees and Contractors .................. 156
HSPD-20/NSPD-51 – National Continuity Policy ............................................................................................ 158
Homeland Security Presidential Directive 20, Annex A ................................................................................... 163
HSPD-24 Biometrics for Identification and Screening to Enhance National Security ...................................... 165
5. Executive Orders ..................................................................................................... 169
a) EO 12958 Classified National Security Information .................................................................................... 169
b) 36 Code of Federal Regulation Part 1236, Management of Vital Records, revised as of July 1, 2000 ......... 169
c) 41 Code of Federal Regulations 101.20.103-4, Occupant Emergency Program, revised as of July 1, 2000 171
d) EO 12472 Assignment of National Security and Emergency Preparedness Telecommunications Functions
........................................................................................................................................................................... 171
e) EO 12656 Assignment of Emergency Preparedness Responsibilities .......................................................... 172
f) EO 13231 Critical Infrastructure Protection in the Information Age ............................................................ 172
g) Federal Continuity Directive 1 (FCD 1) – Federal Executive Branch National Continuity Program and
Requirements, Feb 2008 .................................................................................................................................... 174
h) Federal Continuity Directive 2 (FCD 2) – Federal Executive Branch Mission Essential function and Primary
Mission Essential Function Identification and Submission Process, Feb 2008 ................................................. 175
Domain 5 – NIST Risk Management Framework ........................................................ 176
1. 800-18 Rev1 Guide for Developing Security Plans for Federal Information Systems
.................................................................................................................................... 177
2. 800-34 Contingency Planning Guide for Information Technology Systems ............ 179
3. 800-47 Security Guide for Interconnecting Information Technology Systems ........ 186
4. 800-53 Rev3 - Recommended Security Controls for Federal Information Systems 188
5. 800-53A Guide for Assessing the Security Controls in Federal Information Systems
.................................................................................................................................... 189
6. 800-37 Rev1 Guide for the Security Certification and Accreditation of Federal
Information Systems /Guide for Applying the Risk Management Framework to Federal
Information Systems.................................................................................................... 192
7. 800-59 Guideline for Identifying an Information System as a National Security
System ........................................................................................................................ 194
8. 800-60 Rev1 Guide for Mapping Types of Information and Information Systems to
Security Categories: (2 Volumes) ................................................................................ 195
9. 800-66 An Introductory Resource Guide for Implementing the Health Insurance
Portability and Accountability Act (HIPAA) Security Rule ............................................ 197
10. 800-115 Technical Guide to Information Security Testing and Assessment ........ 199
5
11. FIPS 200 Minimum Security Requirements for Federal Information and Information
Systems ...................................................................................................................... 201
12. FIPS 199 Standards for Security Categorization of Federal Information and
Information Systems.................................................................................................... 202
Domain 6 NIST Interagency Reports.......................................................................... 204
1. IR 7581 System and Network Security Acronyms and Abbreviations .................... 204
2. IR 7564 Directions in Security Metrics Research ................................................... 204
3. IR 7536 2008 Computer Security Division Annual Report ...................................... 205
4. IR 7359 Information Security Guide for Government Executives ........................... 205
IR 7359 provides the answers to those questions. ...................................................... 206
5. IR 7358 Program Review for Information Security Management Assistance
(PRISMA) .................................................................................................................... 206
6. IR 7316 Assessment of Access Control Systems................................................... 207
7. IR 7298 Glossary of Key Information Security Terms............................................. 210
8. IR 7206 Smart Cards and Mobile Device Authentication: An Overview and
Implementation ............................................................................................................ 211
APPENDIX A -- FIPS QUIZ ....................................................................................... 212
APPENDIX B -- FIPS 140-2 QUIZ ............................................................................. 214
APPENDIX C -- Public Key Cryptography ................................................................. 215
6
Introduction
Purpose
This guide is intended to help candidates prepare for the FITSP-Manager exam. It provides a synopsis of each
document that comprises the Federal Body of Knowledge (FBK) as outlined in the FITSP-Manager Candidate Exam
Guide and may include document excerpts as deemed relevant.
Assumptions
It is assumed that the candidate who uses this study guide to prepare for the FITSP-Manager exam has a general
working knowledge of information security concepts. No attempt is made herein to educate the reader about the
basic precepts of information security.
Study Guide Structure
The structure of this Study Guide mirrors the structure of the FITSP-M Exam. For each document in the FBK, a
―Synopsis” is presented to give high order understanding of the particular document and it relevance to other
documents within the same Domain. It is intended that future versions of this guide are updated by persons who
have sat for the exam in order to provide increased relevance of the synopses and benefit for future exam candidates.
Appendices are included for topic specific quizzes, diagrams, etc.
Exam Structure
The subject of FITSP-Manager certification exam is organized into six domains and 21 IT security topic areas.
Exam Weight
20%
10%
10%
20%
30%
10%
Domains
Domain 1 – NIST Special Publications
Domain 2 – NIST Federal Information Processing Standards (FIPS)
Domain 3 – NIST Control Families
Domain 4 – Governmental Laws and Regulations
Domain 5 – NIST Risk Management Framework
Domain 6 – NIST Interagency Reports
IT Security Topic Areas
1. Access Control
11. Media Protection
2. Application Security
12. Personnel Security
3. Audit and Accountability
13. Physical and Environmental Protection
4. Awareness and Training
14. Planning
5. Configuration Management
15. Program Management
6. Contingency Planning
16. Regulatory and Standards Compliance
7. Data Security
17. Risk Assessment
8. Identification and Authentication
18. Security Assessment and Authorization
9. Incident Response
19. System and Communications
Protection
10. Maintenance
20. System and Information Integrity
21. System and Services Acquisition
7
Domain 1 – NIST Special Publications
21 FITSI IT Security Topic Areas Special Publications
One or more NIST SPs apply to each of the 21 FITSI IT Security Topic Areas. Relevant content from each of those
SPs may be excerpted as it pertains to the IT Topic area. The synopses address the intersection of FITSI IT Security
Topic Areas and the pertinent NIST SPs selected.
1. Access Control
800-12 – An Introduction to Computer Security: The NIST Handbook
Synopsis: Access Control is a prevalent topic of 800-12, The NIST Handbook

















Access Control is cross-referenced to:
o Policy
o Personnel/User
o Physical and Environmental
o Identification and Authentication
o Audit
o Cryptography
Documenting access controls policy will make it substantially easier to follow and to enforce.
System-specific policy is often implemented through the use of access controls.
Three basic types of access controls should be considered:
o Physical
o operating system, and
o application.
Operating system and application access controls need to be supported by physical access controls.
Access controls often integrated with system operations.
Well-tested access controls mean less effort to identify threats.
Automated tools can be used to help find vulnerabilities, such as improper access controls or access control
configurations.
Personnel issues are closely linked to logical access controls.
Without careful planning, access control can interfere with contingency plans.
Terminating employees often involves access control.
Identification and Authentication are related to Access Controls
Bypassing logical access controls may mean loss of control over system integrity.
Access control often requires that the system be able to identify and differentiate among users.
Audit trails can be used in concert with access controls to identify and provide information about users
suspected of improper modification of data.
Section 15.1 Physical Access Controls
o the objectives of physical access controls may be in conflict with those of life safety.
Chap 17 is about Logical Access Control
o Gateways
o Firewalls
o The use of roles can be a very effective way of providing access control
o Logical access controls are a technical means of implementing policy decisions.
8
2. Application Security
800-12 – An Introduction to Computer Security: The NIST Handbook
Synopsis: Application Security per se is not a topic of 800-12, The NIST Handbook
3. Audit and Accountability
800-92, Guide to Computer Security Log Management
Synopsis: Log management is an important activity that must address and prepare for support of audits.
Accountability is sparsely addressed, except with respect to HIPAA.
The following is a listing of key regulations, standards, and guidelines that help define organizations’ needs for log
management:

Federal Information Security Management Act of 2002 (FISMA). FISMA emphasizes the need for
each Federal agency to develop, document, and implement an organization-wide program to provide
information security for the information systems that support its operations and assets. NIST SP 80053, Recommended Security Controls for Federal Information Systems, was developed in support of
FISMA. NIST SP 800-53 is the primary source of recommended security controls for Federal agencies.
It describes several controls related to log management, including the generation, review, protection,
and retention of audit records, as well as the actions to be taken because of audit failure.

Gramm-Leach-Bliley Act (GLBA). GLBA requires financial institutions to protect their customers’
information against security threats. Log management can be helpful in identifying possible security
violations and resolving them effectively.

Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA includes security
standards for certain health information. NIST SP 800-66, An Introductory Resource Guide for
Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, lists
HIPAA-related log management needs. For example, Section 4.1 of NIST SP 800-66 describes the
need to perform regular reviews of audit logs and access reports. Also, Section 4.22 specifies that
documentation of actions and activities need to be retained for at least six years.

Sarbanes-Oxley Act (SOX) of 2002. Although SOX applies primarily to financial and accounting
practices, it also encompasses the information technology (IT) functions that support these practices.
SOX can be supported by reviewing logs regularly to look for signs of security violations, including
exploitation, as well as retaining logs and records of log reviews for future review by auditors.

Payment Card Industry Data Security Standard (PCI DSS). PCI DSS applies to organizations that
―store, process or transmit cardholder data‖ for credit cards. One of the requirements of PCI DSS is to
―track…all access to network resources and cardholder data‖.
9
4. Awareness and Training
800-16 - Information Technology Security Training Requirements: A Role- and Performance-Based
Model
Synopsis:
800-50 - Building an Information Technology Security Awareness and Training Program
Synopsis: Provides guidance for developing the program, developing the material, and implementing the
program.
5. Configuration Management
800-40, Version 2, Creating a Patch and Vulnerability Management Program
Synopsis: Naturally, configuration management is affected hugely by patch and vulnerability management
programs. Much material in 800-40 is concerned with the testing of patches and non-patch remediation on IT
devices that use standardized hardware and software configurations.
6. Contingency Planning
800-34, Contingency Planning Guide for Information Technology Systems
Synopsis: The primary guide for contingency planning. Outlines a 7-step planning process (shown below)
and stipulates a 3-phase plan (shown below).
Know the difference between „recovery‟ and „reconstitution‟
COOP – mission-essential, within 12 hours and for up to 30 days
BCP - mission/business functions will be sustained during and after a significant disruption.
DR - recovering one or more information systems at an alternate facility
Know the steps for conducting a Business Impact Analysis (BIA)
1. Determine mission/business functions and recovery criticality.
2. Identify resource requirements.
3. Identify recovery priorities for system resources.
Executive Summary
NIST Special Publication 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems, provides
instructions, recommendations, and considerations for federal information system contingency planning.
Contingency planning refers to interim measures to recover information system services after a disruption. Interim
measures may include relocation of information systems and operations to an alternate site, recovery of information
system functions using alternate equipment, or performance of information system functions using manual methods.
This guide addresses specific contingency planning recommendations for three platform types and provides
strategies and techniques common to all systems.

Client/server systems;


Telecommunications systems; and
Mainframe systems.
10
Seven-Step Contingency Planning
This guide defines the following seven-step contingency planning process that an organization may apply to develop
and maintain a viable contingency planning program for their information systems. These seven progressive steps
are designed to be integrated into each stage of the system development life cycle.
1.
Develop the contingency planning policy statement. A formal policy provides the authority and guidance
necessary to develop an effective contingency plan.
2.
Conduct the business impact analysis (BIA). The BIA helps identify and prioritize information systems and
components critical to supporting the organization’s mission/business functions. A template for developing the
BIA is provided to assist the user.
3.
Identify preventive controls. Measures taken to reduce the effects of system disruptions can increase system
availability and reduce contingency life cycle costs.
4.
Create contingency strategies. Thorough recovery strategies ensure that the system may be recovered quickly
and effectively following a disruption.
5.
Develop an information system contingency plan. The contingency plan should contain detailed guidance and
procedures for restoring a damaged system unique to the system’s security impact level and recovery
requirements.
6.
Ensure plan testing, training, and exercises. Testing validates recovery capabilities, whereas training prepares
recovery personnel for plan activation and exercising the plan identifies planning gaps; combined, the activities
improve plan effectiveness and overall organization preparedness.
7.
Ensure plan maintenance. The plan should be a living document that is updated regularly to remain current
with system enhancements and organizational changes.
This guide presents three sample formats for developing an information system contingency plan based on low-,
moderate-, or high-impact level, as defined by Federal Information Processing Standard (FIPS) 199, Standards for
Security Categorization of Federal Information and Information Systems. Each format defines three phases that
govern actions to be taken following a system disruption.
Activation/Notification - describes the process of activating the plan based on outage impacts and
notifying recovery personnel.
Recovery - details a suggested course of action for recovery teams to restore system operations at an
alternate site or using contingency capabilities. The final phase,
Reconstitution - includes activities to test and validate system capability and functionality and outlines
actions that can be taken to return the system to normal operating condition and prepare the system against future
outages.
Be familiar with:
2.2 Types of Plans
2.2.1 Business Continuity Plan (BCP)
2.2.2 Continuity of Operations (COOP) Plan
2.2.3 Crisis Communications Plan
2.2.4 Critical Infrastructure Protection (CIP) Plan
2.2.5 Cyber Incident Response Plan
2.2.6 Disaster Recovery Plan (DRP)
2.2.7 Information System Contingency Plan (ISCP)
2.2.8 Occupant Emergency Plan (OEP)
11
7. Data Security
800-12 – An Introduction to Computer Security: The NIST Handbook
Synopsis: Data Security per se is not a topic of 800-12, The NIST Handbook
800-60 Rev1 - Guide for Mapping Types of Information and Information Systems to Security Categories
Synopsis: Data Security per se is not a topic of 800-60. Data security is addressed by inference when
discussing use of FIPS 199.
8. Identification and Authentication
800-63 - Electronic Authentication Guideline
Synopsis:
9. Incident Response
800-61 - Computer Security Incident Handling Guide
Synopsis: The primary guide for incident response; establishes an Incident Response Life Cycle.
The document discusses the following items:
 Organizing a computer security incident response capability
o Establishing incident response policies and procedures
o Structuring an incident response team, including outsourcing considerations
o Recognizing which additional personnel may be called on to participate in incident response.
 Handling incidents from initial preparation through the post-incident lessons learned phase
 Handling specific types of incidents
Establishing an incident response capability should include the following actions:
 Creating an incident response policy and plan
 Developing procedures for performing incident handling and reporting, based on the incident response
policy
 Setting guidelines for communicating with outside parties regarding incidents
 Selecting a team structure and staffing model
 Establishing relationships between the incident response team and other groups, both internal (e.g., legal
department) and external (e.g., law enforcement agencies)
 Determining what services the incident response team should provide
 Staffing and training the incident response team.
10. Maintenance
800-12 – An Introduction to Computer Security: The NIST Handbook
Synopsis: The topic of maintenance is addressed briefly.

Section 14.7 Maintenance
o Maintenance errors are a source of security problems.
o Maintenance may also be performed remotely
o Many computer systems provide maintenance accounts.
12
11. Media Protection
n.b. 800-88 addresses media sanitization. No NIST SP is cited in FITSP-M EOG for media protection.
800-88 - Guidelines for Media Sanitization
Synopsis: Guidelines and procedures for sanitization
The guide is divided into the following five sections:

Section 1 (this section) explains the authority, purpose and scope, audience, and assumptions
of the document, and outlines its structure.

Section 2 presents an overview of the need for sanitization and the basic types of
information, sanitization, and media.

Section 3 provides general information on procedures and principles that influence
sanitization decisions.

Section 4 provides the user with a process flow to assist with sanitization decision making.

Section 5 provides a summary of several general sanitization techniques.
12. Personnel Security
800-12 – An Introduction to Computer Security: The NIST Handbook
Synopsis: Personnel Security is only mentioned twice in 800-12.
13. Physical and Environmental Protection
800-12 - An Introduction to Computer Security: The NIST Handbook
Synopsis: Topic 13 is sparsely treated in 800-12


Media controls include a variety of measures to provide physical and environmental protection and
accountability for tapes, diskettes, printouts, and other media.
Physical and environmental protection is used to prevent unauthorized individuals from accessing the
media
14. Planning
800-18 - Guide for Developing Security Plans for Federal Information Systems
Synopsis: An apt title.
15. Program Management
800-53 Rev3 - Recommended Security Controls for Federal Information Systems and Organizations (Appendix G)
Synopsis: The information security program management (PM) controls described in Appendix G focus on
the organization-wide information security requirements that are independent of any particular information
system and are essential for managing information security programs. The controls focus on planning and
long-run management of the security program.
13
16. Regulatory and Standards Compliance
800-12 – An Introduction to Computer Security: The NIST Handbook
Synopsis: Topic addressed primarily in section on “Management Controls”; under Program Policy
…a number of laws and regulations mandate that agencies protect their computers, the information they process,
and related technology resources. The most important are listed below.
 The Computer Security Act of 1987 requires agencies to identify sensitive systems, conduct computer
security training, and develop computer security plans.
 The Federal Information Resources Management Regulation (FIRMR) is the primary regulation for
the use, management, and acquisition of computer resources in the federal government.
 OMB Circular A-130 (specifically Appendix III) requires that federal agencies establish security
programs containing specified elements.
Compliance. Program policy typically will address two compliance issues:
1. General compliance to ensure meeting the requirements to establish a program and the responsibilities
assigned therein to various organizational components. Often an oversight office (e.g., the Inspector
General) is assigned responsibility for monitoring compliance, including how well the organization is
implementing management's priorities for the program.
2. The use of specified penalties and disciplinary actions. Since the security policy is a high-level
document, specific penalties for various infractions are normally not detailed here; instead, the policy may
authorize the creation of compliance structures that include violations and specific disciplinary action(s).
Compliance Program. A central computer security program needs to address compliance with national policies and
requirements, as well as organization-specific requirements. National requirements include those prescribed under
the Computer Security Act of 1987, OMB Circular A-130, the FIRMR, and Federal Information Processing
Standards.
17. Risk Assessment
800-30 - Risk Management Guide for Information Technology Systems
Synopsis: An apt title. 800-30 addresses Risk Management, Risk Assessment, and Risk Mitigation. About one
half of the document details a 9-step Risk Assessment process.
18. Security Assessments and Authorization
800-37 Rev1- Guide for Applying the Risk Management Framework to Federal Information Systems
Synopsis: The Topic is treated in Step 4 and Step 5 of the RMF (Risk Management Framework)
• Assess the security controls using appropriate assessment procedures to determine the extent to which the controls
are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the
security requirements for the system.
• Authorize information system operation based on a determination of the risk to organizational operations and
assets, individuals, other organizations, and the Nation resulting from the operation of the information system and
the decision that this risk is acceptable.
14
19. System and Communication Protection
800-13 - Telecommunications Security Guidelines for Telecommunications Management Network
Synopsis: Lays out a framework for managing telecommunications; including a detailed requirements set.
20. System and Information Integrity
800-12 - An Introduction to Computer Security: The NIST Handbook
Synopsis: Know the contrast between system integrity and information/data integrity.
Integrity: In lay usage, information has integrity when it is timely, accurate, complete, and consistent. However,
computers are unable to provide or protect all of these qualities. Therefore, in the computer security field, integrity is
often discussed more narrowly as having two facets: data integrity and system integrity. "Data integrity is a
requirement that information and programs are changed only in a specified and authorized manner." System
integrity is a requirement that a system "performs its intended function in an unimpaired manner, free from
deliberate or inadvertent unauthorized manipulation of the system." The definition of integrity has been, and
continues to be, the subject of much debate among computer security experts.
21. System and Services Acquisition
800-36 - Guide to Selecting Information Security Products
Synopsis: An apt title. The guide provides guidance for selection of security products in 9 areas.
15
Role-based Special Publications
(per manager role identified in NIST SP 800-16 Rev1)
1. 800-14 – Generally Accepted Principles and Practices for Securing Information Technology Systems
2. 800-27 - Engineering Principles for Information Technology Security (A Baseline for Achieving Security)
3. 800-33 - Underlying Technical Models for Information Technology Security
4. 800-35 - Guide to Information Technology Security Services
5. 800-64 - Rev2- Security Considerations in the System Development Life Cycle
6. 800-65 - Integrating IT Security into the Capital Planning and Investment Control Process
7. 800-100 - Information Security Handbook: A Guide for Managers
Additional Special Publications (added by FITSI)
1. 800-41 - Rev 1 - Guidelines on Firewalls and Firewall Policy (focusing on management of technology)
2. 800-45 - Version 2 - Guidelines on Electronic Mail Security (focusing on management of technology)
3. 800-55 - Rev 1 - Performance Measurement Guide for Information Security
4. 800-77 - Guide to IPSec VPNs (focusing on management of technology)
5. 800-84 - Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
6. 800-113 - Guide to SSL VPNs (focusing on management of technology)
16
Domain 2 – NIST Federal Information Processing Standards (FIPS)
These standards can be downloaded at: http://csrc.nist.gov/
1. FIPS 201-1 - Personal Identity Verification (PIV) of Federal Employees and Contractors
2. FIPS 200 - Minimum Security Requirements for Federal Information and Information Systems
3. FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems
4. FIPS 198-1 - The Keyed-Hash Message Authentication Code
5. FIPS 197 - Advanced Encryption Standard
6. FIPS 196 - Entity Authentication Using Public Key Cryptography
7. FIPS 191 - Guideline for the Analysis of Local Area Network Security
8. FIPS 190 - Guideline for the Use of Advanced Authentication Technology Alternatives
9. FIPS 188 - Standard Security Label for Information Transfer
10. FIPS 186-3 - Digital Signature Standard (DSS)
11. FIPS 185 - Escrowed Encryption Standard
12. FIPS 181 - Automated Password Generator
13. FIPS 180-3 - Secure Hash Standard (SHS)
14. FIPS 140-2 - Security Requirements for Cryptographic Modules
15. FIPS 113 - Computer Data Authentication (no electronic version available)
FIPS 113 - Computer Data Authentication, (1985)
See http://www.itl.nist.gov/fipspubs/fip113.htm
Synopsis
Prescribes an algorithm for authenticating data. The algorithm is based on DES.
Explanation: This standard specifies a Data Authentication Algorithm (DAA) which may be used to detect
unauthorized modifications, both intentional and accidental, to data, The standard is based on the algorithm
specified in the Data Encryption Standard (DES) Federal Information Processing Standards Publication (FIPS PUB)
46, and is compatible with both the Department of the Treasury's Electronic Funds and Security Transfer Policy and
the American National Standards Institute (ANSI) Standard for Financial Institution Message Authentication (see
cross index). The Message Authentication Code (MAC) as specified in ANSI X9.9 is computed in the same manner
as the Data Authentication Code (DAC) specified in this standard. Similarly, the Data Identifier (DID) specified in
this standard is sometimes referred to as a Message Identifier (MID) in standards related to message
communications. The example given in Appendix 2 may be used when validating implementations of this standard.
Applicability: This standard shall be used by Federal organizations whenever the person responsible for the security
of any computer system or data determines that cryptographic authentication is needed for the detection of
intentional modifications of data, unless the data is classified according to the National Security Act of 1947, as
amended, or the Atomic' Energy Act of 1954, as amended. Equipments approved for the cryptographic
authentication of classified data may be used in lieu of equipments meeting this standard. In all cases, the authorized
agency official shall determine that any alternative cryptographic authentication system performs at least as well as
those specified in this standard. Use of this standard is also encouraged in private sector applications of
cryptographic authentication for data integrity.
Abstract: This publication specifies a standard to be used by Federal organizations which require that the integrity
of computer data be cryptographically authenticated. In addition, it may be used by any organization whenever
17
cryptographic authentication is desired. Cryptographic authentication of data during transmission between electronic
components or while in storage is necessary to maintain the integrity of the information represented by the data. The
standard specifies a cryptographic authentication algorithm for use in ADP systems and networks. The
authentication algorithm makes use of the Data Encryption Standard (DES) cryptographic algorithm as defined in
Federal Information Processing Standard 46 (FIPS PUB 46).
FIPS 140-2 Security Requirements for Cryptographic Modules
Synopsis:
Supersedes FIPS PUB 140-1 (1994). Specifies the security requirements for cryptographic modules. Provides four
increasing levels of security:




Security Level 1 - No specific physical security mechanisms are required
Security Level 2 - adds requirement for tamper-evidence
Security Level 3 - adds requirement for detecting and responding to attempts at physical access, use or
modification of the cryptographic module. Attempts to prevent the intruder from gaining access to the
critical security parameters (CSPs) held within the cryptographic module. May include circuitry that zeroizes the CSPs within the module.
Security Level 4 - adds requirement for immediate zero-ization of all plaintext CSPs.
In 1995, NIST established the Cryptographic Module Validation Program (CMVP) that validates cryptographic
modules to Federal Information Processing Standards. The CMVP is a joint effort between NIST and the
Communications Security Establishment Canada (CSEC).
FIPS 140-2 precludes the use of unvalidated cryptography within Federal systems. Unvalidated cryptography is
viewed by NIST as providing no protection to the information or data.
OVERVIEW: This standard specifies the security requirements for a cryptographic module utilized within a
security system protecting sensitive information in computer and telecommunication systems (including voice
systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law
104-106.
FIPS 140-1 was developed by a government and industry working group composed of both operators and vendors.
The working group identified requirements for four security levels for cryptographic modules to provide for a wide
spectrum of data sensitivity (e.g., low value administrative data, million dollar funds transfers, and life protecting
data) and a diversity of application environments (e.g., a guarded facility, an office, and a completely unprotected
location). Four security levels are specified for each of 11 requirement areas. Each security level offers an
increase in security over the preceding level. These four increasing levels of security allow cost-effective solutions
that are appropriate for different degrees of data sensitivity and different application environments. FIPS 140-2
incorporates changes in applicable standards and technology since the development of FIPS 140-1 as well as
changes that are based on comments received from the vendor, laboratory, and user communities.
While the security requirements specified in this standard are intended to maintain the security provided by a
cryptographic module, conformance to this standard is not sufficient to ensure that a particular module is secure. The
operator of a cryptographic module is responsible for ensuring that the security provided by the module is sufficient
and acceptable to the owner of the information that is being protected, and that any residual risk is acknowledged
and accepted.
Similarly, the use of a validated cryptographic module in a computer or telecommunications system is not sufficient
to ensure the security of the overall system. The overall security level of a cryptographic module must be chosen to
provide a level of security appropriate for the security requirements of the application and environment in which the
module is to be utilized and for the security services that the module is to provide. The responsible authority in each
18
organization should ensure that their computer and telecommunication systems that utilize cryptographic modules
provide an acceptable level of security for the given application and environment.
The importance of security awareness and of making information security a management priority should be
communicated to all users. Since information security requirements vary for different applications, organizations
should identify their information resources and determine the sensitivity to and the potential impact of losses.
Controls should be based on the potential risks and should be selected from available controls, including
administrative policies and procedures, physical and environmental controls, information and data controls, software
development and acquisition controls, and backup and contingency planning.
The following sections provide an overview of the four security levels. Common examples, given to illustrate
how the requirements might be met, are not intended to be restrictive or exhaustive.
The location of Annexes A, B, C, and D can be found in APPENDIX D: SELECTED BIBLIOGRAPHY.
1.1 Security Level 1
Security Level 1 provides the lowest level of security. Basic security requirements are specified for a cryptographic
module (e.g., at least one Approved algorithm or Approved security function shall be used). No specific physical
security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for
production-grade components. An example of a Security Level 1 cryptographic module is a personal computer (PC)
encryption board. Security Level 1 allows the software and firmware components of a cryptographic module to be
executed on a general purpose computing system using an unevaluated operating system. Such implementations may
be appropriate for some low-level security applications when other controls, such as physical security, network
security, and administrative procedures are limited or nonexistent. The implementation of cryptographic software
may be more cost-effective than corresponding hardware-based mechanisms, enabling organizations to select from
alternative cryptographic solutions to meet lower-level security requirements.
1.2 Security Level 2
Security Level 2 enhances the physical security mechanisms of a Security Level 1 cryptographic module by adding
the requirement for tamper-evidence, which includes the use of tamper-evident coatings or seals or for pickresistant locks on removable covers or doors of the module. Tamper-evident coatings or seals are placed on a
cryptographic module so that the coating or seal must be broken to attain physical access to the plaintext
cryptographic keys and critical security parameters (CSPs) within the module. Tamper-evident seals or pickresistant locks are placed on covers or doors to protect against unauthorized physical access. Security Level 2
requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization
of an operator to assume a specific role and perform a corresponding set of services. Security Level 2 allows the
software and firmware components of a cryptographic module to be executed on a general purpose computing
system using an operating system that • meets the functional requirements specified in the Common Criteria (CC)
Protection Profiles (PPs) listed in Annex B and • is evaluated at the CC evaluation assurance level EAL2 (or
higher). An equivalent evaluated trusted operating system may be used. A trusted operating system provides a level
of trust so that cryptographic modules executing on general purpose computing platforms are comparable to
cryptographic modules implemented using dedicated hardware systems.
1.3 Security Level 3
In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3
attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical
security mechanisms required at Security Level 3 are intended to have a high probability of detecting and
responding to attempts at physical access, use or modification of the cryptographic module. The physical
security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroizes
all plaintext CSPs when the removable covers/doors of the cryptographic module are opened. Security Level 3
requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication
mechanisms specified for Security Level 2. A cryptographic module authenticates the identity of an operator and
19
verifies that the identified operator is authorized to assume a specific role and perform a corresponding set of
services.
Security Level 3 requires the entry or output of plaintext CSPs (including the entry or output of plaintext CSPs using
split knowledge procedures) be performed using ports that are physically separated from other ports, or interfaces
that are logically separated using a trusted path from other interfaces. Plaintext CSPs may be entered into or output
from the cryptographic module in encrypted form (in which case they may travel through enclosing or intervening
systems). Security Level 3 allows the software and firmware components of a cryptographic module to be executed
on a general purpose computing system using an operating system that • meets the functional requirements specified
in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1) and • is
evaluated at the CC evaluation assurance level EAL3 (or higher) with the additional assurance requirement of an
Informal Target of Evaluation (TOE) Security Policy Model (ADV_SPM.1). An equivalent evaluated trusted
operating system may be used. The implementation of a trusted path protects plaintext CSPs and the software and
firmware components of the cryptographic module from other untrusted software or firmware that may be executing
on the system.
1.4 Security Level 4
Security Level 4 provides the highest level of security defined in this standard. At this security level, the physical
security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of
detecting and responding to all unauthorized attempts at physical access. Penetration of the cryptographic module
enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of
all plaintext CSPs. Security Level 4 cryptographic modules are useful for operation in physically unprotected
environments. Security Level 4 also protects a cryptographic module against a security compromise due to
environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and
temperature. Intentional excursions beyond the normal operating ranges may be used by an attacker to thwart a
cryptographic module's defenses. A cryptographic module is required to either include special environmental
protection features designed to detect fluctuations and zeroize CSPs, or to undergo rigorous environmental failure
testing to provide a reasonable assurance that the module will not be affected by fluctuations outside of the normal
operating range in a manner that can compromise the security of the module. Security Level 4 allows the software
and firmware components of a cryptographic module to be executed on a general purpose computing system using
an operating system that • meets the functional requirements specified for Security Level 3 and • is evaluated at the
CC evaluation assurance level EAL4 (or higher). An equivalent evaluated trusted operating system may be used.
Overview: This Implementation Guidance document is issued and maintained by the U.S. Government's National
Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE) of the
Government of Canada, which serve as the validation authorities of the Cryptographic Module Validation Program
(CMVP) for their respective governments. The CMVP is a program under which National Voluntary Laboratory
Accreditation Program (NVLAP) accredited Cryptographic Module Testing (CMT) laboratories test cryptographic
modules for conformance to Federal Information Processing Standard Publication (FIPS) 140-2, Security
Requirements for Cryptographic Modules. In addition, this program covers the testing of FIPS Approved
cryptographic algorithms, including the Advanced Encryption Standard, Data Encryption Algorithm, Digital
Signature Algorithm, Secure Hash Algorithm, and Skipjack Algorithm. This document is intended to provide
clarifications of the CMVP, and in particular, clarifications and guidance pertaining to the Derived Test
Requirements for FIPS PUB 140-2 (DTR), which is used by CMT laboratories to test for a cryptographic module's
conformance to FIPS 140-2. Guidance presented in this document is based on responses issued by NIST and CSE to
questions posed by the CMT labs, vendors, and other interested parties. However, information in this document is
subject to change by NIST and CSE. Each section of this document corresponds with a requirements section of FIPS
140-2, with an additional first section containing general guidance that is not applicable to any particular
requirements section. Within each section, the guidance is listed according to a subject phrase. For those subjects
that may be applicable to multiple requirements areas, they are listed in the area that seems most appropriate. Under
each subject there is a list, including the date of issue for that guidance, along relevant assertions, test requirements,
and vendor requirements from the DTR. (Note: For each subject, there may be additional test and vendor
requirements which apply.) Next, there is section containing a question or statement of a problem, along with a
resolution and any additional comments with related information. This is the implementation guidance for the listed
subject.
20
What is the purpose of the CMVP?
On July 17, 1995, the National Institute of Standards and Technology (NIST) established the Cryptographic Module
Validation Program (CMVP) that validates cryptographic modules to Federal Information Processing Standards
(FIPS)140-1 Security Requirements for Cryptographic Modules, and other FIPS cryptography based standards. The
CMVP is a joint effort between NIST and the Communications Security Establishment Canada (CSEC). FIPS 1402, Security Requirements for Cryptographic Modules, was released on May 25, 2001 and supersedes FIPS 140-1.
Modules validated as conforming to FIPS 140-1 and FIPS 140-2 are accepted by the Federal Agencies of both
countries for the protection of sensitive information. Vendors of cryptographic modules use independent, accredited
Cryptographic and Security Testing (CST) laboratories to test their modules. The CST laboratories use the Derived
Test Requirements (DTR), Implementation Guidance (IG) and applicable CMVP programmatic guidance to test
cryptographic modules against the applicable standards.. NIST's Computer Security Division (CSD) and CSEC
jointly serve as the Validation Authorities for the program, validating the test results and issuing certificates.
What is the applicability of CMVP to the US government?
FIPS 140-1 became a mandatory standard for the protection of sensitive data when the Secretary of Commerce
signed the standard on January 11, 1994. FIPS 140-2 supersedes FIPS 140-1 and the standard was signed on May
25, 2001. The applicability statement from FIPS 140-2 (page iv): 7. Applicability. This standard is applicable to all
Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and
telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology
Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing
cryptographic modules that Federal departments and agencies operate or are operated for them under contract.
Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been
validated against this standard. The adoption and use of this standard is available to private and commercial
organizations.
Use of Unvalidated Cryptographic Modules by Federal Agencies and Departments
FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of
sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as
providing no protection to the information or data - in effect the data would be considered unprotected
plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS
140-2 is applicable. In essence, if cryptography is required, then it must be validated. With the passage of
the Federal Information Security Management Act (FISMA) of 2002, there is no longer a statutory
provision to allow for agencies to waive mandatory Federal Information Processing Standards (FIPS).
The waiver provision had been included in the Computer Security Act of 1987; however, FISMA
supersedes that Act. Therefore, the references to the "waiver process" contained in many of the FIPS
listed below are no longer operative. As background, below is a list of facts found in FIPS 140-2 and
other supporting NIST documents:



Cryptography: The discipline which embodies principles, means and methods for the
transformation of data to hide its information content, prevent its undetected modification,
prevent its unauthorized use or a combination thereof. [ANSI X9.31]
Cryptography deals with the transformation of ordinary text (plaintext) into coded form (cipher
text) by encryption and transformation of cipher text into plaintext by decryption. [NIST SP 8002]
The selective application of technological and related procedural safeguards is an important
responsibility of every Federal organization in providing adequate security in its computer and
telecommunication systems. This standard [FIPS 140-2] provides a standard that will be used by
Federal organizations when these organizations specify that cryptographic-based security systems
are to be used to provide protection for sensitive or valuable data. [FIPS 140-2]
The FIPS 140-2 standard is applicable to all Federal agencies that use cryptographic-based
security systems to protect sensitive information in computer and telecommunication systems
21


(including voice systems) as defined in Section 5131 of the Information Technology Management
Reform Act of 1996, Public Law 104-106. [FIPS 140-2]
FIPS 140-2 shall be used in designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under contract. [FIPS 140-2]
With the passage of the Federal Information Security Management Act of 2002, there is no longer
a statutory provision to allow for agencies to waive mandatory Federal Information Processing
Standards (FIPS). The waiver provision had been included in the Computer Security Act of 1987;
however, FISMA supersedes that Act. Therefore, the references to the "waiver process" contained
in many of the FIPS are no longer operative. For further information, please go to the CMVP
FAQs Section 3.2.
How does Common Criteria (CC) relate to FIPS 140 -2?
If the operational environment is a modifiable operational environment, the operating system
requirements of the Common Criteria are applicable at Security Levels 2 and above.
FIPS 140-1 required evaluated operating systems that referenced the Trusted Computer System
Evaluation Criteria (TCSEC) classes C2, B1 and B2. However, TCSEC is no longer in use and has been
replaced by the Common Criteria. Consequently, FIPS 140-2 now references the Common Criteria for
Information Technology Security Evaluation (CC), ISO/IEC 15408:1999. The Common Criteria (CC)
and FIPS 140-2 are different in the abstractness and focus of tests. FIPS 140-2 testing is against a defined
cryptographic module and provides a suite of conformance tests to four security levels. FIPS 140-2
describes the requirements for cryptographic modules and includes such areas as physical security, key
management, self tests, roles and services, etc. The standard was initially developed in 1994 - prior to the
development of the CC. CC is an evaluation against a created protection profile (PP) or security target
(ST). Typically, a PP covers a broad range of products. A CC evaluation does not supersede or replace a
validation to either FIPS 140-1 or FIPS 140-2. The four security levels in FIPS 140-1 and FIPS 140-2 do
not map directly to specific CC EALs or to CC functional requirements. A CC certificate cannot be a
substitute for a FIPS 140-1 or FIPS 140-2 certificate.
22
FIPS 180-3 Secure Hash Standard, (2008)
Synopsis
Specifies five hash algorithms used to generate message digests.
The algorithms are of the SHA (Secure Hash Algorithm) ilk, namely:





SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
Abstract
This standard specifies five hash algorithms that can be used to generate digests of messages. The digests
are used to detect whether messages have been changed since the digests were generated.
Explanation: This Standard specifies five secure hash algorithms - SHA-1, SHA-224, SHA-256, SHA384, and SHA-512 - for computing a condensed representation of electronic data (message). When a
message of any length less than 264 bits (for SHA-1, SHA-224 and SHA-256) or less than 2128 bits (for
SHA-384 and SHA-512) is input to a hash algorithm, the result is an output called a message digest. The
message digests range in length from 160 to 512 bits, depending on the algorithm. Secure hash algorithms
are typically used with other cryptographic algorithms, such as digital signature algorithms and keyedhash message authentication codes, or in the generation of random numbers (bits). The five hash
algorithms specified in this Standard are called secure because, for a given algorithm, it is
computationally infeasible 1) to find a message that corresponds to a given message digest, or 2) to find
two different messages that produce the same message digest. Any change to a message will, with a very
high probability, result in a different message digests. This will result in a verification failure when the
secure hash algorithm is used with a digital signature algorithm or a keyed-hash message authentication
algorithm. This Standard specifies five secure hash algorithms, SHA-1, SHA-224, SHA-256, SHA-384,
and SHA-512. All five of the algorithms are iterative, one-way hash functions that can process a message
to produce a condensed representation called a message digest. These algorithms enable the determination
of a message’s integrity: any changes to the message will, with a very high probability, result in a
different message digests. This property is useful in the generation and verification of digital signatures
and message authentication codes, and in the generation of random numbers or bits.
Each algorithm can be described in two stages: preprocessing and hash computation. Preprocessing
involves padding a message, parsing the padded message into m-bit blocks, and setting initialization
values to be used in the hash computation. The hash computation generates a message schedule from the
padded message and uses that schedule, along with functions, constants, and word operations to
iteratively generate a series of hash values. The final hash value generated by the hash computation is
used to determine the message digest. The five algorithms differ most significantly in the security
strengths that are provided for the data being hashed. The security strengths of these five hash functions
and the system as a whole when each of them is used with other cryptographic algorithms, such as digital
signature algorithms and keyed-hash message authentication codes, can be found in [SP 800-57] and [SP
800-107]. Additionally, the five algorithms differ in terms of the size of the blocks and words of data that
are used during hashing. Figure 1 presents the basic properties of these hash algorithms.
23
FIPS 181 Automated Password Generator (APG), (1993)
Synopsis
 Specifies an algorithm to generate passwords
 The algorithm uses random numbers to select the characters that form the random pronounceable
passwords.
 It shall be used by all Federal departments and agencies when there is a requirement for computer
generated pronounceable passwords for authenticating users of computer systems or for
authorizing access to resources in those systems.
Explanation - A password is a protected character string used to authenticate the identity of a computer
system user or to authorize access to system resources. When users are allowed to select their own
passwords they often select passwords that are easily compromised. An automated password generator
creates random passwords that have no association with a particular user. This Automated Password
Generator Standard specifies an algorithm to generate passwords for the protection of computer resources.
This standard is for use in conjunction with FIPS PUB 112, Password Usage Standard, which provides
basic security criteria for the design, implementation, and use of passwords. The algorithm uses random
numbers to select the characters that form the random pronounceable passwords. The random numbers
are generated by a random number subroutine based on the Electronic Codebook mode of the Data
Encryption Standard (DES) (FIPS PUB 46-1). The random number subroutine uses a pseudorandom DES
key generated in accordance with the procedure described in Appendix C of ANSI X9.17.
Similar to DES, the FIPS for Automated Password Generator is an interoperability standard.
Interoperability standards specify functions and formats so that data transmitted can be properly acted
upon when received by another computer. This type of standard is independent of physical
implementation. Implementers are required to use the algorithm defined in the FIPS, however, they are
not constrained in how they package it. For discussion purposes a NIST implementation of the Automated
Password Generator is provided. It is expected that commercial implementations will be based on the
latest technologies and differ from NIST's, however the results should be logically equivalent to that of
this FIPS.
Objectives: The objectives of this standard are to: a. improve the administration of password systems
that are used for authenticating the identity of individuals accessing computer resources or files; b.
provide a standard automated method for producing pronounceable passwords that have no association
with a particular user; c. produce passwords that are easily remembered, stored, and entered into computer
24
systems, yet not readily susceptible to automated techniques that have been developed to search for and
disclose passwords.
Applicability: This standard is applicable to the development of procurement or design specifications for
implementing an automatic password generation algorithm within a computer system. It shall be used by
all Federal departments and agencies when there is a requirement for computer generated pronounceable
passwords for authenticating users of computer systems, or for authorizing access to resources in those
systems. This standard does not require the use of passwords in a computer system, but establishes an
automatic password generation algorithm for use in systems where an agency's computer security policy
requires computer generated pronounceable passwords. It should be used in conjunction with FIPS PUB
112, Password Usage Standard, which specifies basic security criteria for the design, implementation, and
use of passwords.
Qualifications: The Automated Password Generator uses the Electronic Codebook (ECB) mode of the
Data Encryption Standard (DES), Federal Information Processing Standard 46-1 (FIPS PUB 46- 1), as the
random number generator. This mode of operation is specified in FIPS 81, DES Modes of Operation.
The protection provided by the DES algorithm against potential threats has been reviewed every 5 years
since its adoption in 1977 and has been reaffirmed during each of those reviews. The DES, and the
possible threats reducing the security provided by the use of DES, will undergo continual review by NIST
and other cognizant Federal organizations. The new technology available at review time will be evaluated
to determine its impact on the DES. In addition, the awareness of any breakthrough in technology or any
mathematical weakness of the algorithm will cause NIST to reevaluate the DES and provide necessary
revisions.
TECHNICAL EXPLANATION: The Automated Password Generator standard is organized as a main
procedure that references three major components: (1) the "unit table"; (2) the "digram table"; and (3) the
"random number subroutine." The random password generator works by forming pronounceable syllables
and concatenating them to form a word. Rules of pronounceability are stored in a table for every unit and
every pair of units (digram). The rules are used to determine whether a given unit is legal or illegal, based
on its position within the syllable and adjacent units. Most rules and checks are syllable oriented and do
not depend on anything outside the current syllable. The main procedure (algorithm) defines the internal
rules used to generate random words.
FIPS 185 Escrowed Encryption Standard (EES), (1994)
Synopsis
 Specifies use of a symmetric-key encryption (and decryption) algorithm (SKIPJACK) and a Law
Enforcement Access Field (LEAF) creation method (one part of a key escrow system) which
provides for decryption of encrypted telecommunications when interception of the
telecommunications is lawfully authorized.
Explanation: This Standard specifies use of a symmetric-key encryption (and decryption) algorithm
(SKIPJACK) and a Law Enforcement Access Field (LEAF) creation method (one part of a key escrow
system) which provides for decryption of encrypted telecommunications when interception of the
telecommunications is lawfully authorized. Both the SKIPJACK algorithm and the LEAF creation
method are to be implemented in electronic devices (e.g., very large scale integration chips). The devices
may be incorporated in security equipment used to encrypt (and decrypt) sensitive unclassified
telecommunications data. Decryption of lawfully intercepted telecommunications may be achieved
25
through the acquisition and use of the LEAF, the decryption algorithm and the two escrowed key
components. One definition of "escrow" means that something (e.g., a document, an encryption key) is
"delivered to a third person to be given to the grantee only upon the fulfillment of a condition" (Webster's
Seventh New Collegiate Dictionary). The term, "escrow", for purposes of this standard, is restricted to
this dictionary definition. A key escrow system, for purposes of this standard, is one that entrusts the two
components comprising a cryptographic key (e.g., a device unique key) to two key component holders
(also called "escrow agents"). In accordance with the above definition of "escrow", the key component
holders provide the components of a key to a "grantee" (e.g., a law enforcement official) only upon
fulfillment of the condition that the grantee has properly demonstrated legal authorization to conduct
electronic surveillance of telecommunications which are encrypted using the specific device whose device
unique key is being requested. The key components obtained through this process are then used by the
grantee to reconstruct the device unique key and obtain the session key which is then used to decrypt the
telecommunications that are encrypted with that session key.
The SKIPJACK encryption/decryption algorithm has been approved for government applications
requiring encryption of sensitive but unclassified data telecommunications as defined herein. The specific
operations of the SKIPJACK algorithm and the LEAF creation method are classified and hence are
referenced, but not specified, in this standard. Data for purposes of this standard includes voice, facsimile
and computer information communicated in a telephone system. A telephone system for purposes of this
standard is limited to a system which is circuit switched and operating at data rates of standard
commercial modems over analog voice circuits or which uses basic-rate ISDN or a similar grade wireless
service. Data that is considered sensitive by a responsible authority should be encrypted if it is
vulnerable to unauthorized disclosure during telecommunications. A risk analysis should be performed
under the direction of a responsible authority to determine potential threats and risks. The costs of
providing encryption using this standard as well as alternative methods and their respective costs should
be projected. A responsible authority should then make a decision, based on the risk and cost analyses,
whether or not to use encryption and then whether or not to use this standard.
Applicability: This standard is applicable to all Federal departments and agencies and their contractors
under the conditions specified below. This standard may be used in designing and implementing security
products and systems, which Federal departments and agencies use or operate or which are operated for
them under contract. These products may be used when replacing Type II and Type III (DES) encryption
devices and products owned by the government and government contractors. This standard may be used
when the following conditions apply: 1. An authorized official or manager responsible for data security or
the security of a computer system decides that encryption is required and cost justified as per OMB
Circular A- 130; and 2. The data is not classified according to Executive Order 12356, entitled "National
Security Information," or to its successor orders, or to the Atomic Energy Act of 1954, as amended.
However, Federal departments or agencies which use encryption devices for protecting data classified
according to either of these acts may use those devices also for protecting unclassified data in lieu of this
standard. In addition, this standard may be adopted and used by non-Federal Government organizations.
Such use is encouraged when it provides the desired security.
Implementations: The encryption/decryption algorithm and the LEAF creation method shall be
implemented in electronic devices (e.g., electronic chip packages) which are protected against
unauthorized entry, modification and reverse engineering. Implementations which are tested and validated
by NIST will be considered as complying with this standard. An electronic device shall be incorporated
into a cryptographic module in accordance with FIPS 140-1. NIST will test for conformance with FIPS
140-1. Conforming cryptographic modules can then be integrated into security equipment for sale and use
in a security application.
26
FIPS 186-3 Digital Signature Standard (DSS), (2009)
Synopsis:
This Standard defines methods for digital signature generation that can be used for the
 protection of binary messages
 verification and validation of those digital signatures.
Three techniques are approved.
1. Digital Signature Algorithm (DSA)
2. RSA digital signature algorithm
3. Elliptic Curve Digital Signature Algorithm (ECDSA)
This Standard includes requirements for obtaining the assurances necessary for valid digital signatures.
FIPS 186, first published in 1994, specified a digital signature algorithm (DSA) to generate and verify digital
signatures. Later revisions (FIPS 186–1 and FIPS 186–2, adopted in 1998 and 1999, respectively) adopted two
additional algorithms specified in American National Standards (ANS) X9.31 (Digital Signatures Using Reversible
Public Key Cryptography for the Financial Services Industry (rDSA)), and X9.62 (The Elliptic Curve Digital
Signature Algorithm (ECDSA)).
The original DSA algorithm, as specified in FIPS 186, 186–1 and 186– 2, allows key sizes of 512 to 1024 bits.
FIPS 186–3 allows the use of 1024, 2048 and 3072-bit keys.
Explanation: This Standard specifies algorithms for applications requiring a digital signature, rather than
a written signature. A digital signature is represented in a computer as a string of bits. A digital signature
is computed using a set of rules and a set of parameters that allow the identity of the signatory and the
integrity of the data to be verified. Digital signatures may be generated on both stored and transmitted
data. Signature generation uses a private key to generate a digital signature; signature verification uses a
public key that corresponds to, but is not the same as, the private key. Each signatory possesses a private
and public key pair. Public keys may be known by the public; private keys are kept secret. Anyone can
verify the signature by employing the signatory’s public key. Only the user that possesses the private key
can perform signature generation. A hash function is used in the signature generation process to obtain a
condensed version of the data to be signed; the condensed version of the data is often called a message
digest. The message digest is input to the digital signature algorithm to generate the digital signature. The
hash functions to be used are specified in the Secure Hash Standard (SHS), FIPS 180-3. FIPS approved
digital signature algorithms shall be used with an appropriate hash function that is specified in the SHS.
The digital signature is provided to the intended verifier along with the signed data. The verifying entity
verifies the signature by using the claimed signatory’s public key and the same hash function that was
used to generate the signature. Similar procedures may be used to generate and verify signatures for both
stored and transmitted data.
Applicability: This Standard is applicable to all Federal departments and agencies for the protection of
sensitive unclassified information that is not subject to section 2315 of Title 10, United States Code, or
section 3502 (2) of Title 44, United States Code. This Standard shall be used in designing and
implementing public key-based signature systems that Federal departments and agencies operate or that
are operated for them under contract. The adoption and use of this Standard is available to private and
commercial organizations.
27
Applications: A digital signature algorithm allows an entity to authenticate the integrity of signed data
and the identity of the signatory. The recipient of a signed message can use a digital signature as evidence
in demonstrating to a third party that the signature was, in fact, generated by the claimed signatory. This
is known as non-repudiation, since the signatory cannot easily repudiate the signature at a later time. A
digital signature algorithm is intended for use in electronic mail, electronic funds transfer, electronic data
interchange, software distribution, data storage, and other applications that require data integrity
assurance and data origin authentication.
Implementations: A digital signature algorithm may be implemented in software, firmware, hardware or
any combination thereof. NIST has developed a validation program to test implementations for
conformance to the algorithms in this Standard. Information about the validation program is available at
http://csrc.nist.gov/cryptval. Examples for each digital signature algorithm are available at
http://csrc.nist.gov/groups/ST/toolkit/examples.html. Agencies are advised that digital signature key pairs
shall not be used for other purposes.
Qualifications: The security of a digital signature system is dependent on maintaining the secrecy of the
signatory’s private keys. Signatories shall, therefore, guard against the disclosure of their private keys.
While it is the intent of this Standard to specify general security requirements for generating digital
signatures, conformance to this Standard does not assure that a particular implementation is secure. It is
the responsibility of an implementer to ensure that any module that implements a digital signature
capability is designed and built in a secure manner. Similarly, the use of a product containing an
implementation that conforms to this Standard does not guarantee the security of the overall system in
which the product is used. The responsible authority in each agency or department shall assure that an
overall implementation provides an acceptable level of security. Since a standard of this nature must be
flexible enough to adapt to advancements and innovations in science and technology, this Standard will
be reviewed every five years in order to assess its adequacy.
General Discussion
A digital signature is an electronic analogue of a written signature; the digital signature can be used to
provide assurance that the claimed signatory signed the information. In addition, a digital signature may
be used to detect whether or not the information was modified after it was signed (i.e., to detect the
integrity of the signed data). These assurances may be obtained whether the data was received in a
transmission or retrieved from storage. A properly implemented digital signature algorithm that meets the
requirements of this Standard can provide these services.
A digital signature algorithm includes a signature generation process and a signature verification process.
A signatory uses the generation process to generate a digital signature on data; a verifier uses the
verification process to verify the authenticity of the signature. Each signatory has a public and private key
and is the owner of that key pair. As shown in Figure 1, the private key is used in the signature generation
process. The key pair owner is the only entity that is authorized
to use the private key to generate digital signatures. In order to prevent other entities from claiming to be
the key pair owner and using the private key to generate fraudulent signatures, the
private key must remain secret. The approved digital signature algorithms are designed to prevent an
adversary who does not know the signatory’s private key from generating the same
signature as the signatory on a different message. In other words, signatures are designed so that
they cannot be forged. A number of alternative terms are used in this Standard to refer to the signatory or
key pair owner. An entity that intends to generate digital signatures in the future may be referred to as the
intended signatory. Prior to the verification of a signed message, the signatory is referred to as the
claimed signatory until such time as adequate assurance can be obtained of the actual identity of the
signatory.
28
The public key is used in the signature verification process (see Figure 1). The public key need not be
kept secret, but its integrity must be maintained. Anyone can verify a correctly signed message using the
public key.
For both the signature generation and verification processes, the message (i.e., the signed data) is converted to a
fixed-length representation of the message by means of an approved hash function. Both the original message and
the digital signature are made available to a verifier.
A verifier requires assurance that the public key to be used to verify a signature belongs to the entity that
claims to have generated a digital signature (i.e., the claimed signatory). That is, a
verifier requires assurance that the signatory is the actual owner of the public/private key pair
used to generate and verify a digital signature. A binding of an owner’s identity and the owner’s
public key shall be effected in order to provide this assurance.
A verifier also requires assurance that the key pair owner actually possesses the private key associated
with the public key, and that the public key is a mathematically correct key.
By obtaining these assurances, the verifier has assurance that if the digital signature can be correctly
verified using the public key, the digital signature is valid (i.e., the key pair owner really signed the
message). Digital signature validation includes both the (mathematical) verification of the digital
signature and obtaining the appropriate assurances. The following are reasons why such assurances are
required.
1. If a verifier does not obtain assurance that a signatory is the actual owner of the key pair whose public
component is used to verify a signature, the problem of forging a signature is reduced to the problem of
falsely claiming an identity. For example, anyone in possession of a mathematically consistent key pair
can sign a message and claim that the signatory was the President of the United States. If a verifier does
not require assurance that the President is actually the owner of the public key that is used to
mathematically verify the message’s signature, then successful signature verification provides assurance
that the message has not been altered since it was signed, but does not provide assurance that the message
came from the President (i.e., the verifier has assurance of the data’s integrity, but source authentication is
lacking).
2. If the public key used to verify a signature is not mathematically valid, the arguments used to establish
the cryptographic strength of the signature algorithm may not apply. The owner may not be the only
party who can generate signatures that can be verified with that public key.
3. If a public key infrastructure cannot provide assurance to a verifier that the owner of a key pair has
demonstrated knowledge of a private key that corresponds to the owner’s public key, then it may be
possible for an unscrupulous entity to have their identity (or an assumed identity) bound to a public key
that is (or has been) used by another party. The unscrupulous entity may then claim to be the source of
certain messages signed by that other party. Or, it may be possible that an unscrupulous entity has
managed to obtain ownership of a public key that was chosen with the sole purpose of allowing for the
verification of a signature on a specific message. Technically, a key pair used by a digital signature
algorithm could also be used for purposes other than digital signatures (e.g., for key establishment).
However, a key pair used for digital signature generation and verification as specified in this Standard
shall not be used for any other purpose. See SP 800-57 on Key Usage for further information. A number
of steps are required to enable a digital signature generation or verification capability in accordance with
this Standard. All parties that generate digital signatures shall perform the initial setup process as
discussed in Section 3.1. Digital signature generation shall be performed as discussed in Section 3.2.
Digital signature verification and validation shall be performed as discussed in Section 3.3.
29
FIPS 188 Standard Security Label for Information Transfer, (1994)
Synopsis:
Security labels convey information used by protocol entities on how to handle data communicated for information
exchanged over data networks.
Information on a security label can be used to
 control access
 specify protective measures
 determine handling restrictions required by the communications security policy.
This standard defines syntax for security labels for use at the Application and Network Layers.
Scope: This standard defines syntactic constructs for conveying security label information when
Government sensitive but unclassified data is exchanged over computer networks. The syntactic
constructs defined in this standard are intended to be used along with semantics provided by the authority
establishing security policy for the protection of the information exchanged. NIST has established a
Computer Security Objects Register (CSOR) that will serve as repository for label semantics. Informative
Appendix A of this standard provides further details on the CSOR. This standard does not discuss the
physical labeling of information or storage media and information displayed on a computer screen or
other peripherals. Labeling of information stored in internal memory and storage media (e.g. hard disks,
compact disks, magnetic tapes, etc.) is also outside of the scope of this standard. The protection of data in
transit and their associated labels along with the binding between the data and the labels is the
responsibility of the communications protocols involved in the transfer and therefore not discussed here.
Compliance with this standard does not provide assurance of the suitability of an implementation for the
protection of data according to specific security policies. That assessment must be made through the
appropriate evaluation and certification processes.
Applicability: This standard applies to U.S. Government communications systems required by agency
security policy to label sensitive but unclassified data when exchanged over data networks. Although this
standard is intended for use on systems handling unclassified information, it could be adopted by the
appropriate authorities for use on systems handling classified information. Complying implementations
shall be capable of transmitting, receiving, and obtaining information from security labels based on the
specifications in this document.
30
FIPS 190 - Guideline for the use of Advanced Authentication Technology
Alternatives, (1994)
Synopsis:
This Guideline describes the primary alternative methods for verifying the identities of computer system users, and
provides recommendations to Federal agencies and departments for the acquisition and use of technology which
supports these methods.
Applicability. This guideline is applicable to all Federal departments and agencies that use
authentication systems to protect unclassified information within computer and telecommunication
systems (including voice systems) that are not subject to Section 2315 of Title 10, U.S. Code, or Section
3502(2) of Title 44, U.S. Code. This guideline may be used by all Federal departments and agencies in
designing, acquiring and implementing authentication systems within computer and telecommunication
systems (including voice systems) that they operate or that are operated for them under contract. NonFederal government organizations are encouraged to use this guideline when it provides the desired
security for protecting valuable or sensitive information.
Applications. Authentication systems may be utilized in various computer and telecommunication
(including voice) applications and in various environments (e.g., centralized computer facilities, office
environments, hostile environments). The strength of an authentication system should be chosen to
provide a degree of assurance appropriate for the security requirements of the application and
environment in which the system is to be utilized and the security services which the system is to provide
Export Control. Many of the authentication systems discussed in this guideline make use of
cryptographic techniques to strengthen the security of the authentication process. Certain cryptographic
devices and technical data regarding them are deemed to be defense articles (i.e., inherently military in
character) and are subject to Federal government export controls as specified in Title 22, Code of Federal
Regulations, Parts 120-128.
Qualifications. The authentication technology described in this guideline is based upon information
provided by many sources within the Federal government and private industry.
Authentication systems are designed to protect against adversaries mounting cost-effective attacks on
unclassified government or commercial data (e.g., hackers, organized crime, economic competitors). The
primary goal in designing an effective security system is to make the cost of any attack greater than the
possible payoff.
Kerberos: Kerberos was developed to provide distributed network authentication services at MIT [48].
In this environment, users access a network of computing resources through workstations which are
assumed to be untrusted. An unscrupulous user might therefore be able to subvert a given workstation
with relatively little difficulty. A primary threat in this type of client-server system is the possibility that
one user will be able to claim the identity of another user, thereby gaining access to system services
without the proper authorization. To protect against this threat, Kerberos provides a trusted third party
accessible to network entities, which supports the services required for authentication between these
entities. This trusted third party is known as the Kerberos key distribution server, which shares secret
cryptographic keys with each client and server within a particular realm.
31
The Kerberos authentication model is based upon the presentation of cryptographic tickets to prove the
identity of clients requesting services from a host system, or server [48]. Since a computer workstation
typically performs the client side of an authentication protocol on behalf of a human user, the term
"client" in the following discussion will refer to a specific system user and the computer workstation
associated with that user. A summary of the Kerberos authentication process follows:
1. The user initiates a login process on a workstation. The workstation login process transmits a ticket
request to the key distribution server. The ticket request contains the client identity, the identity of the
target service, and the current time.
2. The key distribution server retrieves the secret keys for the client and the service. A ticket is prepared,
consisting of: a temporary session key for use by the client and the service, the client identity, the service
identity, a timestamp, the workstation address, and the validity interval of the ticket. The ticket is then
encrypted under the key of the service. The encrypted ticket, temporary session key, identity of the
service, validity interval, and timestamp are encrypted under the client's secret key.
3. The encrypted response packet is sent from the key distribution service to the client.
4. When the client receives the encrypted response packet, the client's secret key is generated by
performing a one-way encryption of the user's password. Using this key, the client decrypts the response
packet and verifies the origin of the message based on the timestamp and client identity. The client then
creates an authenticator consisting of the client identity, client address, and a timestamp. This
authenticator is encrypted under the temporary session key.
5. The client sends the authenticator and the ticket obtained in step 4 to the service.
6. The requested service decrypts the ticket using its secret key and verifies the contents of the ticket,
proving that the ticket originated from the key distribution server. The temporary session key is obtained
from the ticket and used to decrypt the authenticator. The information stored in the authenticator proves
the identity of the client to the requested service, which can then respond to the service request in the
appropriate manner.
7. The service may optionally return an authenticator to prove its identity to the client.
Although a detailed analysis of the Kerberos protocol is beyond the scope of this document, several points
are worth noting. Kerberos eliminates the need for each client to share a unique
authentication key with each service, placing the responsibility for managing keying relationships on the
Kerberos key distribution center. Use of a key distribution/key translation
center as a trusted third party in secret key authentication protocols is a fairly common technique for
reducing the total number of keying relationships which must be managed [49]. However, the key
distribution server requires a very high level of protection, since an attacker could theoretically gain
access to keys for all clients and servers within a given realm by compromising the key distribution server
for that realm.
Since a user's secret key is a one way function of the user's password, these keys are subject to many of
the same attacks used against password based authentication systems which apply a one way function to
user's passwords before storing them. Anyone can request a ticket from the key distribution service, so an
attacker could obtain a ticket for any given user by transmitting the client name, service name, and
timestamp to the key distribution service. The attacker could then attempt to guess the user's password,
and thus the user's secret key, off-line. It would be easy to tell when the correct password had been
guessed, because the resulting secret key would decrypt the encrypted ticket obtained from the key
32
distribution service correctly. Possession of a user's password would then allow the attacker to pose as
that user. Good password management techniques are essential to minimize the risk of such attacks.
FIPS 191 - Guideline for the Analysis Local Area Network Security, (1994)
Synopsis:


Threats, Vulnerabilities, Security Services & Mechanisms - This section describes threats, related
vulnerabilities and the possible security services and mechanisms that could be used to protect the
LAN from these threats.
Risk Management - This section describes the risk management process and how it can be used to
plan and implement appropriate LAN security.
LAN Definition: The Institute of Electrical and Electronic Engineers (IEEE) has defined a LAN as "a
datacomm system allowing a number of independent devices to communicate directly with each other,
within a moderately sized geographic area over a physical communications channel of moderate rates"
[MART89]. Typically, a LAN is owned, operated, and managed locally rather than by a common carrier.
A LAN usually, through a common network operating system, connects servers, workstations, printers,
and mass storage devices, enabling users to share the resources and functionality provided by a LAN.
According to [BARK89] the types of applications provided by a LAN include distributed file storing,
remote computing, and messaging.
Goals of LAN Security: The following goals should be considered to implement effective LAN
security.
• Maintain the confidentiality of data as it is stored, processed or transmitted on a LAN;
• Maintain the integrity of data as it is stored, processed or transmitted on a LAN;
• Maintain the availability of data stored on a LAN, as well as the ability to process and transmit
the data in a timely fashion;
• Ensure the identity of the sender and receiver of a message;
Adequate LAN security requires the proper combination of security policies and procedures,
technical controls, user training and awareness, and contingency planning. While all of these
areas are critical to provide adequate protection, the focus of this document is on the technical
controls that can be utilized. The other areas of control mentioned above are discussed in the
appendices.
THREATS, VULNERABILITIES, SERVICES & MECHANISMS: A threat can be any person,
object, or event that, if realized, could potentially cause damage to the LAN.
Threats can be malicious, such as the intentional modification of sensitive information,
or can be accidental, such as an error in a calculation, or the accidental deletion of a file. Threats
can also be acts of nature, i.e. flooding, wind, lightning, etc. The immediate damage caused by
a threat is referred to as an impact.
Vulnerabilities are weaknesses in a LAN that can be exploited by a threat. For example, unauthorized
access (the threat) to the LAN could occur by an outsider guessing an obvious password. The
33
vulnerability exploited is the poor password choice made by a user. Reducing or eliminating the
vulnerabilities of the LAN can reduce or eliminate the risk of threats to the LAN. For example, a tool that
can help users choose robust passwords may reduce the chance that users will utilize poor passwords, and
thus reduce the threat of unauthorized LAN access.
A security service is the collection of security mechanisms, supporting data files, and procedures
that help protect the LAN from specific threats. For example, the identification and authentication service
helps protect the LAN from unauthorized LAN access by requiring that a user identify himself, as well as
verifying that identity. The security service is only as robust as the mechanisms, procedures, etc. that
make up the service.
Security mechanisms are the controls implemented to provide the security services needed to protect the
LAN. For example, a token based authentication system (which requires that the user be in possession of a
required token) may be the mechanism implemented to provide the identification and authentication
service. Other mechanisms that help maintain the confidentiality of the authentication information can
also be considered as part of the identification and authentication service.
RISK MANAGEMENT: A systematic approach should be used to determine appropriate LAN security
measures. Deciding how to address security, where to implement security on the LAN, and the type and
strength of the security controls requires considerable thought. This section will address the issues
involving risk management of a LAN. The elements that are common to most risk management processes
will be examined in terms of the unique properties of a LAN that may require special considerations
beyond the risk process of a centralized system or application. In presenting this information, a simple
risk management methodology will be introduced that may be considered as a candidate among the
different methodologies and techniques that are currently available. It is the reader’s task to determine
the appropriate level of protection required for their LAN. This is accomplished through risk
management. [KATZ92] defines risk management as the process of:
• estimating potential losses due to the use of or dependence upon automated information
system technology,
• analyzing potential threats and system vulnerabilities that contribute to loss estimates, and
• selecting cost effective safeguards that reduce risk to an acceptable level. There are many risk
management methodologies that an organization may use. However all
should incorporate the process defined above.
34
FIPS 196 Entity Authentication Using Public Key Cryptography, (1997)
Synopsis


Specifies two challenge-response protocols for entity authentication. The two protocols use a public
key cryptographic algorithm for generating and verifying digital signatures.
One entity can prove its identity to another entity by using a private key to generate a digital
signature on a random challenge.
Abstract
This standard specifies two challenge-response protocols by which entities in a computer system may
authenticate their identities to one another. These may be used during session initiation, and at any other
time that entity authentication is necessary. Depending on which protocol is implemented, either one or
both entities involved may be authenticated. The defined protocols are derived from an international
standard for entity authentication based on public key cryptography, which uses digital signatures and
random number challenges.
Authentication based on public key cryptography has an advantage over many other authentication
schemes because no secret information has to be shared by the entities involved in the exchange. A user
(claimant) attempting to authenticate oneself must use a private key to digitally sign a random number
challenge issued by the verifying entity. This random number is a time variant parameter which is unique
to the authentication exchange. If the verifier can successfully verify the signed response using the
claimant's public key, then the claimant has been successfully authenticated.
Applicability. This standard is applicable to all Federal departments and agencies that use public key
based authentication systems to protect unclassified information within computer and digital
telecommunications systems that are not subject to Section 2315 of Title 10, U.S. Code, or Section
3502(2) of Title 44, U.S. Code. This standard shall be used by all Federal Departments and agencies in
designing, acquiring and implementing public key based, challenge response authentication systems at the
application layer within computer and digital telecommunications systems. This includes all systems that
Federal departments and agencies operate or that are operated for them under contract. In addition, this
standard may be used at other layers within computer and digital telecommunications systems. This
standard may be adopted and used by non-Federal Government organizations. Such use is encouraged
when it is either cost effective or provides interoperability for commercial and private organizations.
Applications. Numerous applications can benefit from the incorporation of entity authentication based on
public key cryptography, when the implementation of such technology is considered cost-effective.
Networking applications that require remote login will be able to authenticate clients who have not
previously registered with the host, since secret material (e.g., a password) does not have to be exchanged
beforehand. Also, point-to-point authentication can take place between users who are unknown to one
another. The authentication protocols in this standard may be used in conjunction with other public keybased systems (e.g., a public key infrastructure that uses public key certificates) to enhance the security of
a computer system.)
Export Control. Implementations of this standard are subject to Federal Government export controls as
specified in Title 15, Code of Federal Regulations, Parts 768 through 799. Exporters are advised to
contact the Department of Commerce, Bureau of Export Administration, for more information.
Qualifications. The authentication technology described in this standard is based upon information
provided by sources within the Federal Government and private industry. Authentication systems are
35
designed to protect against adversaries (e.g., hackers, organized crime, economic competitors) mounting
cost-effective attacks on unclassified government or commercial data. The primary goal in designing an
effective security system is to make the cost of any attack greater than the possible payoff. While
specifications in this standard are intended to maintain the security of an authentication protocol,
conformance to this standard does not guarantee that a particular implementation is secure. It is the
responsibility of the manufacturer to build the implementation of an authentication protocol in a secure
manner. This standard will be reviewed every five years in order to assess its adequacy.
FIPS 197 Advanced Encryption Standard (AES)
Synopsis:
AES is a symmetric-key encryption standard adopted by the U.S. government. The standard
comprises three block ciphers, AES-128, AES-192 and AES-256, adopted from a larger
collection originally published as Rijndael. Each of these ciphers has a 128-bit block size, with
key sizes of 128, 192 and 256 bits, respectively. The AES ciphers have been analyzed
extensively and are now used worldwide, as was the case with its predecessor, the Data
Encryption Standard (DES).
AES was announced by National Institute of Standards and Technology (NIST) as U.S. FIPS
PUB 197 (FIPS 197) on November 26, 2001 after a 5-year standardization process in which
fifteen competing designs were presented and evaluated before Rijndael was selected as the most
suitable (see Advanced Encryption Standard process for more details). It became effective as a
Federal government standard on May 26, 2002 after approval by the Secretary of Commerce. It
is available in many different encryption packages. AES is the first publicly accessible and open
cipher approved by the NSA for top secret information
The Rijndael cipher was developed by two Belgian cryptographers, Joan Daemen and Vincent
Rijmen, and submitted by them to the AES selection process. Rijndael (pronounced "Rhine
dall") is a wordplay with the names of the two inventors
Explanation: The Advanced Encryption Standard (AES) specifies a FIPS-approved
cryptographic algorithm that can be used to protect electronic data. The AES algorithm is a symmetric block cipher
that can encrypt (encipher) and decrypt (decipher) information. Encryption converts data to an unintelligible form
called ciphertext; decrypting the ciphertext converts the data back into its original form, called plaintext
The AES algorithm is capable of using cryptographic keys of 128, 192, and 256 bits to encrypt and decrypt data in
blocks of 128 bits.
Applicability: This standard may be used by Federal departments and agencies when an agency determines that
sensitive (unclassified) information (as defined in P. L. 100-235) requires cryptographic protection.
36
Other FIPS-approved cryptographic algorithms may be used in addition to, or in lieu of, this standard. Federal
agencies or departments that use cryptographic devices for protecting classified information can use those devices
for protecting sensitive (unclassified) information in lieu of this standard.
In addition, this standard may be adopted and used by non-Federal Government organizations. Such use is
encouraged when it provides the desired security for commercial and private organizations..
Implementations: A digital signature algorithm may be implemented in software, firmware, hardware or
any combination thereof. NIST has developed a validation program to test implementations for
conformance to the algorithms in this Standard. Information about the validation program is available at
http://csrc.nist.gov/cryptval. Examples for each digital signature algorithm are available at
http://csrc.nist.gov/groups/ST/toolkit/examples.html. Agencies are advised that digital signature key pairs
shall not be used for other purposes.
Waivers: shall be granted only when compliance with this standard would:
a. adversely affect the accomplishment of the mission of an operator of Federal computer system or
b. cause a major adverse financial impact on the operator that is not offset by government wide savings.
FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC)
Synopsis:
This Standard describes a keyed-hash message authentication code (HMAC), a mechanism for
message authentication using cryptographic hash functions. HMAC can be used with any
iterative Approved cryptographic hash function, in combination with a shared secret key.
Mechanisms that provide such integrity checks based on a secret key are usually called
message authentication codes (MACs). Typically, message authentication codes are used
between two parties that share a secret key in order to authenticate information transmitted
between these parties. This Standard defines a MAC that uses a cryptographic hash function in
conjunction with a secret key. This mechanism is called HMAC [HMAC]. HMAC shall use an
Approved cryptographic hash function [FIPS 180-3]. HMAC uses the secret key for the
calculation and verification of the MACs.
Explanation: This Standard specifies an algorithm for applications requiring message authentication.
Message authentication is achieved via the construction of a message authentication code (MAC).
MACs based on cryptographic hash functions are known as HMACs.
The purpose of a MAC is to authenticate both the source of a message and its integrity without the
use of any additional mechanisms. HMACs have two functionally distinct parameters, a message
input and a secret key known only to the message originator and intended receiver(s). Additional
applications of keyed-hash functions include their use in challenge-response identification protocols
for computing responses, which are a function of both a secret key and a challenge message.
An HMAC function is used by the message sender to produce a value (the MAC) that is formed by
condensing the secret key and the message input. The MAC is typically sent to the message receiver
along with the message. The receiver computes the MAC on the received message using the same
37
key and HMAC function as were used by the sender, and compares the result computed with the
received MAC. If the two values match, the message has been correctly received, and the receiver is
assured that the sender is a member of the community of users that share the key. .
Applicability: This Standard is applicable to all Federal departments and agencies for the protection
of sensitive unclassified information that is not subject to Title 10 United States Code Section 2315
(10 USC 2315) and that is not within a national security system as defined in Title 44 United States
Code Section 3502(2) (44 USC 3502(2)). The adoption and use of this Standard is available to
private and commercial organizations.
Implementations. The authentication mechanism described in this Standard may be implemented in
software, firmware, hardware, or any combination thereof. NIST has developed a Cryptographic
Module Validation Program that will test implementations for conformance with this HMAC
Standard. Information on this program is available at http://csrc.nist.gov/groups/STM/index.html.
Agencies are advised that keys used for HMAC applications should not be used for other purposes.
Other Approved Security Functions. HMAC implementations that comply with this Standard shall
employ cryptographic algorithms, cryptographic key generation algorithms and key management
techniques that have been approved for protecting Federal government sensitive information.
Approved cryptographic algorithms and techniques include those that are either:
a. specified in a Federal Information Processing Standard (FIPS),
b. adopted in a FIPS or NIST Recommendation, or
c. specified in the list of Approved security functions for FIPS 140-2.
Export Control. Certain cryptographic devices and technical data regarding them are subject to
Federal export controls.
Qualifications. The security afforded by the HMAC function is dependent on maintaining the
secrecy of the key and the use of an appropriate Approved hash function. Therefore, users must
guard against disclosure of these keys. While it is the intent of this Standard to specify a mechanism
to provide message authentication, conformance to this Standard does not assure that a particular
implementation is secure. It is the responsibility of the implementer to ensure that any module
containing an HMAC implementation is designed and built in a secure manner.
38
FIPS 199 Guideline for the use of Advanced Authentication Technology
Alternatives, (1994)
Synopsis:

FIPS Publication 199 develops the standards for categorizing information and information systems.

Security categorization standards for information and information systems provide a common
framework and understanding for expressing security that, for the federal government, promotes:
 Effective management and oversight of information security programs, including the
coordination of information security efforts throughout the civilian, national security, emergency
preparedness, homeland security, and law enforcement communities; and
 Consistent reporting to the Office of Management and Budget (OMB) and Congress on the
adequacy and effectiveness of information security policies, procedures, and practices.
Applicability
These standards shall apply to: (i) all information within the federal government other than that information
that has been determined pursuant to Executive Order 12958, as amended by Executive Order 13292, or any
predecessor order, or by the Atomic Energy Act of 1954, as amended, to require protection against
unauthorized disclosure and is marked to indicate its classified status; and (ii) all federal information systems
other than those information systems designated as national security systems as defined in 44 United States
Code Section 3542(b)(2). Agency officials shall use the security categorizations described in FIPS Publication
199 whenever there is a federal requirement to provide such a categorization of information or information
systems. Additional security designators may be developed and used at agency discretion. State, local, and
tribal governments as well as private sector organizations comprising the critical infrastructure of the United
States may consider the use of these standards as appropriate. These standards are effective upon approval by
the Secretary of Commerce.
Categorization of Information and Information Systems
The security categories are based on the potential impact on an organization should certain events occur which
jeopardize the information and information systems needed by the organization to accomplish its assigned mission,
protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals. Security
categories (Confidentiality, Integrity, and Availability) are to be used in conjunction with vulnerability and threat
information in assessing the risk to an organization.
Potential Impact
Three levels of potential impact – low, moderate, and high.
Categorization applied to information types
The security category of an information type can be associated with both user information and system information 3
and can be applicable to information in either electronic or non-electronic form. It can also be used as input in
considering the appropriate security category of an information system (see description of security categories for
information systems below). Establishing an appropriate security category of an information type essentially
requires determining the potential impact for each security objective associated with the particular information type.
39
Categorization applied to information types
Determining the security category of an information system requires slightly more analysis and must consider the
security categories of all information types resident on the information system. For an information system, the
potential impact values assigned to the respective security objectives (confidentiality, integrity, availability) shall be
the highest values (i.e., high water mark) from among those security categories that have been determined for each
type of information resident on the information system.
40
FIPS 200 Minimum Security Requirements for Federal Information and
Information Systems, (2006)
Synopsis:
FIPS Publication 200, the second of the mandatory security standards, specifies minimum security
requirements for information and information systems supporting the executive agencies of the federal
government and a risk-based process for selecting the security controls necessary to satisfy the
minimum security requirements.
This standard will promote the development, implementation, and operation of more secure information
systems within the federal government by establishing minimum levels of due diligence for information
security and facilitating a more consistent, comparable, and repeatable approach for selecting and
specifying security controls for information systems that meet minimum security requirements.
organizations must develop and promulgate formal, documented policies and procedures governing the
minimum security requirements set forth in this standard and must ensure their effective
implementation.
Abstract
The E-Government Act (P.L. 107-347), passed in December 2002, recognized the importance of information
security to the economic and national security interests of the United States. Title III of the E-Government Act,
entitled the Federal Information Security Management Act (FISMA), emphasizes the need for each federal
agency to develop, document, and implement an enterprise-wide 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.
FISMA directed the promulgation of federal standards for: (i) the security categorization of federal information
and information systems based on the objectives of providing appropriate levels of information security
according to a range of risk levels; and (ii) minimum security requirements for information and information
systems in each such category. This standard addresses the specification of minimum security requirements for
federal information and information systems.
Applicability
This standard is applicable to: (i) all information within the federal government other than that information that
has been determined pursuant to Executive Order 12958, as amended by Executive Order 13292, or any
predecessor order, or by the Atomic Energy Act of 1954, as amended, to require protection against
unauthorized disclosure and is marked to indicate its classified status; and (ii) all federal information systems
other than those information systems designated as national security systems as defined in 44 United States
Code Section 3542(b)(2). The standard has been broadly developed from a technical perspective to
complement similar standards for national security systems. In addition to the agencies of the federal
government, state, local, and tribal governments, and private sector organizations that compose the critical
infrastructure of the United States are encouraged to consider the use of this standard, as appropriate.
Implementation
This standard specifies minimum security requirements for federal information and information systems in
seventeen security-related areas. Federal agencies must meet the minimum security requirements as defined
herein through the use of the security controls in accordance with NIST Special Publication 800-53,
Recommended Security Controls for Federal Information Systems, as amended.
41
MINIMUM SECURITY REQUIREMENTS
The minimum security requirements cover seventeen security-related areas with regard to protecting the
confidentiality, integrity, and availability of federal information systems and the information processed, stored,
and transmitted by those systems. The security-related areas include: (i) access control; (ii) awareness and
training; (iii) audit and accountability; (iv) certification, accreditation, and security assessments; (v)
configuration management; (vi) contingency planning; (vii) identification and authentication; (viii) incident
response; (ix) maintenance; (x) media protection; (xi) physical and environmental protection; (xii) planning;
(xiii) personnel security; (xiv) risk assessment; (xv) systems and services acquisition; (xvi) system and
communications protection; and (xvii) system and information integrity.
Security Control Selection
Organizations must meet the minimum security requirements in this standard by selecting the appropriate
security controls and assurance requirements as described in NIST Special Publication 800-53, Recommended
Security Controls for Federal Information Systems. The process of selecting the appropriate security controls
and assurance requirements for organizational information systems to achieve adequate security is a
multifaceted, risk-based activity involving management and operational personnel within the organization.
Security categorization of federal information and information systems, as required by FIPS Publication 199, is
the first step in the risk management process. Subsequent to the security categorization process, organizations
must select an appropriate set of security controls for their information systems that satisfy the minimum
security requirements set forth in this standard.
The selected set of security controls must include one of three, appropriately tailored security control baselines
from NIST Special Publication 800-53 that are associated with the designated impact levels of the
organizational information systems as determined during the security categorization process.
- For low-impact information systems, employ appropriately tailored security controls from the low
baseline.
- For moderate-impact information systems, employ appropriately tailored security controls from the
moderate baseline.
- For high-impact information systems, employ appropriately tailored security controls from the high
baseline.
42
FIPS 201-1 Personal Identity Verification (PIV) of Federal Employees and
Contractors, (2006)
Synopsis
In response to HSPD-12, the NIST Computer Security Division initiated a new program for
improving the identification and authentication of Federal employees and contractors for access
to Federal facilities and information systems. FIPS 201 was developed to satisfy the technical
requirements of HSPD 12, approved by the Secretary of Commerce, and issued on February 25,
2005.
PIV-I satisfies the control objectives and meets the security requirements of HSPD 12
PIV-II meets the technical interoperability requirements of HSPD 12.
FIPS 201 together with NIST SP 800-78 (Cryptographic Algorithms and Key Sizes for PIV) are
required for U.S. Federal Agencies but do not apply to US national security systems.
The SmartCard Interagency Advisory Board has indicated that to comply with FIPS 201 PIV II
US government agencies should use smart card technology.
This standard is effective immediately. Federal departments and agencies shall meet the
requirements of PIV-I no later than October 27, 2005, in accordance with the timetable specified
in HSPD 12.
Abstract
This standard specifies the architecture and technical requirements for a common identification standard
for Federal employees and contractors. The overall goal is to achieve appropriate security assurance for
multiple applications by efficiently verifying the claimed identity of individuals seeking physical access
to federally controlled government facilities and electronic access to government information systems.
The standard contains two major sections. Part one describes the minimum requirements for a Federal
personal identity verification system that meets the control and security objectives of Homeland Security
Presidential Directive 12, including personal identity proofing, registration, and issuance. Part two
provides detailed specifications that will support technical interoperability among PIV systems of Federal
departments and agencies. It describes the card elements, system interfaces, and security controls required
to securely store, process, and retrieve identity credentials from the card. The physical card
characteristics, storage media, and data elements that make up identity credentials are specified in this
standard. The interfaces and card architecture for storing and retrieving identity credentials from a smart
card are specified in Special Publication 800-73, Interfaces for Personal Identity Verification. Similarly,
the interfaces and data formats of biometric information are specified in Special Publication 800-76,
Biometric Data Specification for Personal Identity Verification.
This standard does not specify access control policies or requirements for Federal departments and
agencies.
Applicability
This standard is applicable to identification issued by Federal departments and agencies to Federal
employees and contractors (including contractor employees) for gaining physical access to Federally
43
controlled facilities and logical access to Federally controlled information systems except for ―national
security systems‖ as defined by 44 U.S.C. 3542(b)(2). Except as provided in HSPD 12, nothing in this
standard alters the ability of government entities to use the standard for additional applications.
Special-Risk Security Provision—The U.S. Government has personnel, facilities, and other assets
deployed and operating worldwide under a vast range of threats (e.g., terrorist, technical, intelligence),
particularly heightened overseas. For those agencies with particularly sensitive OCONUS threats, the
issuance, holding, and/or use of PIV credentials with full technical capabilities as described herein may
result in unacceptably high risk. In such cases of extant risk (e.g., to facilities, individuals, operations, the
national interest, or the national security), by the presence and/or use of full-capability PIV credentials,
the head of a Department or independent agency may issue a select number of maximum security
credentials that do not contain (or otherwise do not fully support) the wireless and/or biometric
capabilities otherwise required/referenced herein. To the greatest extent practicable, heads of Departments
and independent agencies should minimize the issuance of such special-risk security credentials so as to
support inter-agency interoperability and the President’s policy. Use of other risk-mitigating technical
(e.g., high-assurance on-off switches for the wireless capability) and procedural mechanisms in such
situations is preferable, and as such is also explicitly permitted and encouraged. As protective security
technology advances, this need for this provision will be re-assessed as the standard undergoes the normal
review and update process.
Implementation
The PIV standard consists of two parts—PIV-I and PIV-II. PIV-I satisfies the control objectives and
meets the security requirements of HSPD 12, while PIV-II meets the technical interoperability
requirements of HSPD 12. PIV-II specifies implementation and use of identity credentials on integrated
circuit cards for use in a Federal personal identity verification system.
PIV Cards must be personalized with identity information for the individual to whom the card is issued,
in order to perform identity verification both by humans and automated systems. Humans can use the
physical card for visual comparisons, whereas automated systems can use the electronically stored data on
the card to conduct automated identity verification.
44
Domain 3 – NIST Control Families
NIST SP 800-53 Rev3 identifies 18 control families that must be incorporated into the design of
federal systems. These control families are broken into three categories of controls (management,
technical and operational).
The 18 control families are similar to the 21 IT Security Topic Areas listed in Exam Objectives Guide (EOG)
18 NIST Control Families
Access Control
n.a.
Audit and Accountability
Awareness and Training
Configuration Management
Contingency Planning
n.a.
Identification and Authentication
Incident Response
Maintenance
Media Protection
Personnel Security
Physical and Environmental Protection
Planning
Program Management
n.a.
Risk Assessment
Security Assessment and Authorization
System and Communication Protection
System and Information Integrity
System and Services Acquisition
21 FITSI IT Security Topic Areas
1. Access Control
2. Application Security
3. Audit and Accountability
4. Awareness and Training
5. Configuration Management
6. Contingency Planning
7. Data Security
8. Identification and Authentication
9. Incident Response
10. Maintenance
11. Media Protection
12. Personnel Security
13. Physical and Environmental Protection
14. Planning
15. Program Management
16. Regulatory and Standards Compliance
17. Risk Assessment
18. Security Assessment and Authorization
19. System and Communications Protection
20. System and Information Integrity
21. System and Services Acquisition
The following material is excerpted from FIPS 200 p2, Specifications for Minimum Security
Requirements
Access Control (AC): Organizations must limit information system access to authorized users, processes
acting on behalf of authorized users, or devices (including other information systems) and to the types of
transactions and functions that authorized users are permitted to exercise.
Awareness and Training (AT): Organizations must: (i) ensure that managers and users of organizational
information systems are made aware of the security risks associated with their activities and of the
45
applicable laws, Executive Orders, directives, policies, standards, instructions, regulations, or procedures
related to the security of organizational information systems; and (ii) ensure that organizational personnel
are adequately trained to carry out their assigned information security-related duties and responsibilities.
Audit and Accountability (AU): Organizations must: (i) create, protect, and retain information system
audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of
unlawful, unauthorized, or inappropriate information system activity; and (ii) ensure that the actions of
individual information system users can be uniquely traced to those users so they can be held accountable
for their actions.
Certification, Accreditation, and Security Assessments (CA): Organizations must: (i) periodically
assess the security controls in organizational information systems to determine if the controls are effective
in their application; (ii) develop and implement plans of action designed to correct deficiencies and
reduce or eliminate vulnerabilities in organizational information systems; (iii) authorize the operation of
organizational information systems and any associated information system connections; and (iv) monitor
information system security controls on an ongoing basis to ensure the continued effectiveness of the
controls.
Configuration Management (CM): Organizations must: (i) establish and maintain baseline
configurations and inventories of organizational information systems (including hardware, software,
firmware, and documentation) throughout the respective system development life cycles; and (ii) establish
and enforce security configuration settings for information technology products employed in
organizational information systems.
Contingency Planning (CP): Organizations must establish, maintain, and effectively implement plans
for emergency response, backup operations, and post-disaster recovery for organizational information
systems to ensure the availability of critical information resources and continuity of operations in
emergency situations.
Identification and Authentication (IA): Organizations must identify information system users,
processes acting on behalf of users, or devices and authenticate (or verify) the identities of those users,
processes, or devices, as a prerequisite to allowing access to organizational information systems.
Incident Response (IR): Organizations must: (i) establish an operational incident handling capability for
organizational information systems that includes adequate preparation, detection, analysis, containment,
recovery, and user response activities; and (ii) track, document, and report incidents to appropriate
organizational officials and/or authorities.
Maintenance (MA): Organizations must: (i) perform periodic and timely maintenance on organizational
information systems; and (ii) provide effective controls on the tools, techniques, mechanisms, and
personnel used to conduct information system maintenance.
Media Protection (MP): Organizations must: (i) protect information system media, both paper and
digital; (ii) limit access to information on information system media to authorized users; and (iii) sanitize
or destroy information system media before disposal or release for reuse.
Physical and Environmental Protection (PE): Organizations must: (i) limit physical access to
information systems, equipment, and the respective operating environments to authorized individuals; (ii)
protect the physical plant and support infrastructure for information systems; (iii) provide supporting
utilities for information systems; (iv) protect information systems against environmental hazards; and (v)
provide appropriate environmental controls in facilities containing information systems.
46
Planning (PL): Organizations must develop, document, periodically update, and implement security
plans for organizational information systems that describe the security controls in place or planned for the
information systems and the rules of behavior for individuals accessing the information systems.
Personnel Security (PS): Organizations must: (i) ensure that individuals occupying positions of
responsibility within organizations (including third-party service providers) are trustworthy and meet
established security criteria for those positions; (ii) ensure that organizational information and information
systems are protected during and after personnel actions such as terminations and transfers; and (iii)
employ formal sanctions for personnel failing to comply with organizational security policies and
procedures.
Risk Assessment (RA): Organizations must periodically assess the risk to organizational operations
(including mission, functions, image, or reputation), organizational assets, and individuals, resulting from
the operation of organizational information systems and the associated processing, storage, or
transmission of organizational information.
System and Services Acquisition (SA): Organizations must: (i) allocate sufficient resources to
adequately protect organizational information systems; (ii) employ system development life cycle
processes that incorporate information security considerations; (iii) employ software usage and
installation restrictions; and (iv) ensure that third-party providers employ adequate security measures to
protect information, applications, and/or services outsourced from the organization.
System and Communications Protection (SC): Organizations must: (i) monitor, control, and protect
organizational communications (i.e., information transmitted or received by organizational information
systems) at the external boundaries and key internal boundaries of the information systems; and (ii)
employ architectural designs, software development techniques, and systems engineering principles that
promote effective information security within organizational information systems.
System and Information Integrity (SI): Organizations must: (i) identify, report, and correct information
and information system flaws in a timely manner; (ii) provide protection from malicious code at
appropriate locations within organizational information systems; and (iii) monitor information system
security alerts and advisories and take appropriate actions in response.
FIPS 200 AND SP 800-53
IMPLEMENTING INFORMATION SECURITY STANDARDS AND GUIDELINES
FIPS 200, Minimum Security Requirements for Federal Information and Information Systems, is a
mandatory federal standard developed by NIST in response to FISMA. To comply with the federal
standard, organizations must first determine the security category of their information system in
accordance with FIPS 199, Standards for Security Categorization of Federal Information and
Information Systems, derive the information system impact level from the security category in
accordance with FIPS 200, and then apply the appropriately tailored set of baseline security
controls in NIST Special Publication 800-53, Security Controls for Federal Information Systems
and Organizations. Organizations have flexibility in applying the baseline security controls in
accordance with the guidance provided in Special Publication 800-53. This allows organizations to
tailor the relevant security control baseline so that it more closely aligns with their mission and
business requirements and environments of operation.
FIPS 200 and NIST Special Publication 800-53, in combination, help ensure that appropriate
security requirements and security controls are applied to all federal information and information
systems. An organizational assessment of risk validates the initial security control selection and
determines if any additional controls are needed to protect organizational operations (including
47
mission, functions, image, or reputation), organizational assets, individuals, other organizations, or
the Nation. The resulting set of security controls establishes a level of security due diligence for the
organization.
In FIPS 199, the security category of an information type can be associated with both user information
and system information and can be applicable to information in either electronic or non-electronic form. It
is also used as input in considering the appropriate security category for a system. Establishing an
appropriate security category for an information type simply requires determining the potential impact for
each security objective associated with the particular information type. The generalized format for
expressing the security category, or SC, of an information type is:
The Security Category information type = {(confidentiality, impact), (integrity, impact), (availability,
impact)} where the acceptable values for potential impact are low, moderate, high, or not applicable.
2.1 SECURITY CONTROL ORGANIZATION AND STRUCTURE
Security controls described in this publication have a well-defined organization and structure.
For ease of use in the security control selection and specification process, controls are organized
into eighteen families. Each security control family contains security controls related to the
security functionality of the family. A two-character identifier is assigned to uniquely identify
each security control family. In addition, there are three general classes of security controls:
management, operational, and technical. Table 1-1 of the originating document (see below) summarizes
the classes and families in the security control catalog and the associated security control family
identifiers.
Table 1-1 from SP-800-53-Rev3
IDENTIFIER
AC
AT
AU
CA
CM
CP
IA
IR
MA
MP
PE
PL
PS
RA
SA
SC
SI
PM
FAMILY
Access Control
Awareness and Training
Audit and Accountability
Security Assessment and Authorization
Configuration Management
Contingency Planning
Identification and Authentication
Incident Response
Maintenance
Media Protection
Physical and Environmental Protection
Planning
Personnel Security
Risk Assessment
System and Services Acquisition
System and Communications Protection
System and Information Integrity
Program Management
CLASS
Technical
Operational
Technical
Management
Operational
Operational
Technical
Operational
Operational
Operational
Operational
Management
Operational
Management
Management
Technical
Operational
Management
3.1 MANAGING RISK
The selection and specification of security controls for an information system is accomplished as
part of an organization-wide information security program for the management of risk—that is,
the risk to organizational operations and assets, individuals, other organizations, and the Nation
associated with the operation of an information system. The management of risk is a key element
in the organization’s information security program and provides an effective framework for
selecting the appropriate security controls for an information system—the security controls
48
necessary to protect individuals and the operations and assets of the organization. The risk-based
approach to security control selection and specification considers effectiveness, efficiency, and
constraints due to applicable federal laws, Executive Orders, directives, policies, regulations,
standards, or guidelines. The following activities related to managing risk, included as part of the
Risk Management Framework, are paramount to an effective information security program and
can be applied to both new and legacy information systems within the context of the Federal
Enterprise Architecture and system development life cycle—
• Categorize the information system and the information processed, stored, and transmitted by
that system based on a FIPS 199 impact analysis.
• Select an initial set of baseline security controls for the information system based on the
system impact level and minimum security requirements defined in FIPS 200; apply tailoring
guidance; supplement the tailored baseline security controls based on an organizational
assessment of risk and local conditions including environment of operation, organization specific
security requirements, specific threat information, cost-benefit analyses, or special
circumstances; and specify assurance requirements.
• Implement the security controls and describe how the controls are employed within the
information system and its environment of operation.
• Assess the security controls using appropriate assessment procedures to determine the extent
to which the controls are implemented correctly, operating as intended, and producing the
desired outcome with respect to meeting the security requirements for the system.
• Authorize information system operation based on a determination of the risk to
organizational operations and assets, individuals, other organizations, and the Nation
resulting from the operation of the information system and the decision that this risk is
acceptable.
• Monitor the security controls in the information system on an ongoing basis including assessing control
effectiveness, documenting changes to the system or its environment of operation, conducting security
impact analyses of the associated changes, and reporting the security state of the system to designated
organizational officials. Figure 3-1 illustrates the specific activities in the Risk Management Framework
and the information security standards and guidance documents associated with each activity.51 The
remainder of this chapter focuses on several key activities in the Risk Management Framework associated
with security control selection and specification.
49
FIGURE 3-1: RISK MANAGEMENT FRAMEWORK
3.2 CATEGORIZING THE INFORMATION SYSTEM
FIPS 199, the mandatory security categorization standard, is predicated on a simple and well established
concept—determining appropriate security priorities for organizational information systems and
subsequently applying appropriate measures to adequately protect those systems. The security controls
applied to a particular information system are commensurate with the potential adverse impact on
organizational operations, organizational assets, individuals, other organizations, and the Nation should
there be a loss of confidentiality, integrity, or availability. FIPS 199 requires organizations to categorize
their information systems as low-impact, moderate impact, or high-impact for the security objectives of
confidentiality, integrity, and availability (RMF Step 1). The potential impact values assigned to the
respective security objectives are the highest values (i.e., high water mark) from among the security
categories that have been determined for each type of information processed, stored, or transmitted by
those information systems. The generalized format for expressing the security category (SC) of an
information system is:
SC information system = {(confidentiality, impact), (integrity, impact), (availability, impact)},
where the acceptable values for potential impact are low, moderate, or high.
50
Since the potential impact values for confidentiality, integrity, and availability may not always be
the same for a particular information system, the high water mark concept is introduced in FIPS 200 to
determine the impact level of the information system for the express purpose of selecting an initial set of
security controls from one of the three security control baselines. Thus, a low impact system is defined as
an information system in which all three of the security objectives are low. A moderate-impact system is
an information system in which at least one of the security objectives is moderate and no security
objective is greater than moderate. And finally, a high impact system is an information system in which at
least one security objective is high.
Implementation Tip
To determine the overall impact level of the information system:
• First, determine the different types of information that are processed, stored, or transmitted by the
information system (e.g., financial sector oversight, inspections and auditing, official information
dissemination, etc.). NIST Special Publication 800-60 provides guidance on a variety of information
types commonly used by organizations.
• Second, using the impact levels in FIPS 199 and the recommendations of NIST Special Publication
800-60, categorize the confidentiality, integrity, and availability of each information type.
• Third, determine the information system security categorization, that is, the highest impact level for
each security objective (confidentiality, integrity, availability) from among the categorizations for the
information types associated with the information system.
• Fourth, determine the overall impact level of the information system from the highest impact level
among the three security objectives in the system security categorization.
51
Organizations can use the recommended priority code designation associated with each security control in
the baselines to assist in making sequencing decisions for control implementation (i.e., a Priority Code 1
[P1] control has a higher priority for implementation than a Priority Code 2 [P2] control; a Priority Code
2 (P2) control has a higher priority for implementation than a Priority Code 3 [P3] control). This
recommended sequencing prioritization helps ensure that foundational security controls upon which other
controls depend are implemented first, thus enabling organizations to deploy controls in a more structured
and timely manner in accordance with available resources. The implementation of security controls by
sequence priority code does not imply the achievement of any defined level of risk mitigation until all of
the security controls in the security plan have been implemented. The priority codes are used only for
implementation sequencing, not for making security control selection decisions. Table D-1 summarizes
sequence priority codes for the baseline security controls in Table D-2.
Table 1: Information and Information System Security Objectives
Security Objectives
FISMA Definition [44 U.S.C., Sec.
FIPS 199 Definition
3542]
―Preserving authorized restrictions on
A loss of confidentiality is the
Confidentiality
information access and disclosure,
unauthorized disclosure of
including means for protecting personal
information.
privacy and proprietary information…‖
Integrity
―Guarding against improper information
modification or destruction, and includes
ensuring information non-repudiation
and authenticity…‖
A loss of integrity is the
unauthorized modification or
destruction of information.
Availability
―Ensuring timely and reliable access to
and use of information…‖
A loss of availability is the
disruption of access to or use of
information
52
Table 2: Potential Impact Levels
Potential Impact
Low
Definitions
The potential impact is low if—The loss of confidentiality, integrity,
or availability could be expected to have a limited adverse effect on
organizational operations, organizational assets, or individuals.7
A limited adverse effect means that, for example, the loss of
confidentiality, integrity, or availability might: (i) cause a
degradation in mission capability to an extent and duration that the
organization is able to perform its primary functions, but the
effectiveness of the functions is noticeably reduced; (ii) result in
minor damage to organizational assets; (iii) result in minor financial
loss; or (iv) result in minor harm to individuals.
Moderate
The potential impact is moderate if—The loss of confidentiality,
integrity, or availability could be expected to have a serious adverse
effect on organizational operations, organizational assets, or
individuals.
A serious adverse effect means that, for example, the loss of
confidentiality, integrity, or availability might: (i) cause a significant
degradation in mission capability to an extent and duration that the
organization is able to perform its primary functions, but the
effectiveness of the functions is significantly reduced; (ii) result in
significant damage to organizational assets; (iii) result in significant
financial loss; or (iv) result in significant harm to individuals that
does not involve loss of life or serious life threatening injuries.
High
The potential impact is high if—The loss of confidentiality,
integrity, or availability could be expected to have a severe or
catastrophic adverse effect on organizational operations,
organizational assets, or individuals.
A severe or catastrophic adverse effect means that, for example, the
loss of confidentiality, integrity, or availability might: (i) cause a
severe degradation in or loss of mission capability to an extent and
duration that the organization is not able to perform one or more of
its primary functions; (ii) result in major damage to organizational
assets; (iii) result in major financial loss; or (iv) result in severe or
catastrophic harm to individuals involving loss of life or serious life
threatening injuries.
MINIMUM ASSURANCE REQUIREMENTS
LOW-IMPACT, MODERATE-IMPACT, AND HIGH-IMPACT INFORMATION SYSTEMS
The minimum assurance requirements for security controls described in the security control catalog are
listed below. The assurance requirements are directed at the activities and actions that security control
developers and implementers define and apply to increase the level of confidence that the controls are
implemented correctly, operating as intended, and producing the desired outcome with respect to meeting
the security requirements for the information system. The assurance requirements are applied on a
control-by-control basis. The requirements are grouped by information system impact level (i.e., low,
moderate, and high) since the requirements apply to each control within the respective impact level.
Using a format similar to security controls, assurance requirements are followed by supplemental
53
guidance that provides additional detail and explanation of how the requirements are to be applied.
Bolded text indicates requirements that appear for the first time at a particular impact level.
Low-Impact Information Systems
Assurance Requirement: The security control is in effect and meets explicitly identified functional
requirements in the control statement.
Supplemental Guidance: For security controls in low-impact information systems, the focus is on the
controls 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 Information Systems
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 supporting increased confidence that when the control is implemented, it will meet its
required function or purpose. These actions include, for example, requiring the development of records
with structure and content suitable to facilitate making this determination.
Supplemental Guidance: For security controls in moderate-impact information systems, the focus is on
actions supporting increased confidence in the 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 supporting
increased confidence that the control meets its required function or purpose. This documentation is also
needed by assessors to analyze and test the functional properties of the control as part of the overall
assessment of the control. Note: This level of assurance is not intended to protect a moderate-impact
information system against high end threat agents (i.e., threat agents that are highly skilled, highly
motivated, and well-resourced). When such protection is required, the section below entitled Additional
Assurance Requirements for Moderate- Impact and High-Impact Information Systems applies.
73 In this context, a developer/implementer is an individual or group of individuals responsible for the
development
High-Impact Information Systems
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 supporting increased confidence 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.
Supplemental Guidance: For security controls in high-impact information systems, 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
component/integration testing of the controls and to produce associated design and implementation
documentation to support these activities. This documentation is also needed by assessors to analyze and
test the internal components of the control as part of the overall assessment of the control. Note: This
54
level of assurance is not intended to protect a high-impact information system against high-end threat
agents (i.e., threat agents that are highly skilled, highly motivated, and well-resourced). When such
protection is required, the section below entitled Additional Assurance Requirements for ModerateImpact and High-Impact Information Systems applies.
Additional Assurance Requirements for Moderate-Impact and High-Impact Information Systems
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. The control developer/implementer includes as an integral part of the control,
actions supporting increased confidence 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 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 moderate-impact and high-impact information systems, when
appropriate, in order to protect against threats from highly skilled, highly motivated, and well-resourced
threat agents. This level of protection is necessary for those information systems where the organization is
not willing to accept the risks associated with the type of threat agents cited above.
PR
I
CONTROL BASELINES
LOW
MODERATE
HIGH
AC-1
Access Control - Tech
Access Control Policy and
Procedures
P1
AC-1
AC-2
AC-3
AC-4
AC-5
AC-6
AC-7
AC-8
Account Management
Access Enforcement
Information Flow Enforcement
Separation of Duties
Least Privilege
Unsuccessful Login Attempts
System Use Notification
P1
P1
P1
P1
P1
P2
P1
AC-2
AC-3
Not Selected
Not Selected
Not Selected
AC-7
AC-8
CNT
L
CONTROL NAME
55
AC-1
AC-2 (1) (2) (3)
(4)
AC-3
AC-4
AC-5
AC-6 (1) (2)
AC-7
AC-8
AC-1
AC-2 (1) (2)
(3) (4)
AC-3
AC-4
AC-5
AC-6 (1) (2)
AC-7
AC-8
AC-9
AC10
AC11
AC12
AC13
AC14
AC15
AC16
AC17
AC18
AC19
AC20
AC21
AC22
AT-1
AT-2
AT-3
AT-4
AT-5
AU-1
AU-2
AU-3
AU-4
AU-5
AU-6
AU-7
Previous Logon (Access)
Notification
P0
Not Selected
Not Selected
Concurrent Session Control
P2
Not Selected
Not Selected
Session Lock
P3
Not Selected
AC-11
Session Termination (Withdrawn)
Supervision and Review—Access
Control (Withdrawn)
Permitted Actions without
Identification or Authentication
P1
AC-14
AC-14 (1)
Automated Marking (Withdrawn)
---
---
---
Security Attributes
P0
Not Selected
Not Selected
Remote Access
P1
AC-17
AC-17 (1) (2) (3)
(4) (5) (7) (8)
Wireless Access
P1
AC-18
AC-18 (1)
Access Control for Mobile Devices
Use of External Information
Systems
User-Based Collaboration and
Information Sharing
P1
AC-19
AC-19 (1) (2) (3)
P1
AC-20
AC-20 (1) (2)
P0
Not Selected
Not Selected
Publicly Accessible Content
Awreness and Training - Op
Security Awareness and Training
Policy and Procedures
Security Awareness
Security Training
Security Training Records
Contacts with Security Groups and
Associations
Audit and Accountability - Tech
Audit and Accountability Policy
and Procedures
Auditable Events
P2
AC-22
AC-22
P1
P1
P1
P3
AT-1
AT-2
AT-3
AT-4
AT-1
AT-2
AT-3
AT-4
P0
Not Selected
Not Selected
P1
P1
AU-1
AU-2
AU-1
AU-2 (3) (4)
Content of Audit Records
Audit Storage Capacity
Response to Audit Processing
Failures
Audit Review, Analysis, and
Reporting
Audit Reduction and Report
P1
P1
AU-3
AU-4
AU-3 (1)
AU-4
P1
AU-5
AU-5
P1
P2
AU-6
Not Selected
AU-6
AU-7 (1)
56
Not Selected
AC-10
AC-11
AC-14 (1)
--Not Selected
AC-17 (1)
(2) (3) (4)
(5) (7) (8)
AC-18 (1)
(2) (4) (5)
AC-19 (1)
(2) (3)
AC-20 (1)
(2)
Not Selected
AC-22
AT-1
AT-2
AT-3
AT-4
Not Selected
AU-1
AU-2 (3) (4)
AU-3 (1)
(2)
AU-4
AU-5 (1)
(2)
AU-6 (1)
AU-7 (1)
Generation
Time Stamps
Protection of Audit Information
P1
P1
AU-8
AU-9
AU-8 (1)
AU-9
Non-repudiation
P1
Not Selected
Not Selected
Audit Record Retention
P3
AU-11
AU-11
Audit Generation
Monitoring for Information
Disclosure
P1
AU-12
AU-12
P0
Not Selected
Not Selected
P0
Not Selected
Not Selected
P1
P2
P1
CA-1
CA-2
CA-3
CA-1
CA-2 (1)
CA-3
CA-2 (1) (2)
CA-3
P3
P3
P3
CA-5
CA-6
CA-7
CA-5
CA-6
CA-7
CA-5
CA-6
CA-7
CM-1
Session Audit
Security Assessment and
Authorization - Mgt
Security Assessment and
Authorization Policies and
Procedures
Security Assessments
Information System Connections
Security Certification
(Withdrawn)
Plan of Action and Milestones
Security Authorization
Continuous Monitoring
Configuration Management - Op
Configuration Management Policy
and Procedures
P1
CM-1
CM-1
CM-2
Baseline Configuration
P1
CM-2
CM-2 (1) (3) (4)
CM-3
CM-4
Configuration Change Control
Security Impact Analysis
P1
P2
Not Selected
CM-4
CM-3 (2)
CM-4
CM-5
Access Restrictions for Change
P1
Not Selected
CM-5
CM-6
Configuration Settings
P1
CM-6
CM-6 (3)
CM-7
Least Functionality
Information System Component
Inventory
Configuration Management Plan
Contingency Planning - Op
Contingency Planning Policy and
Procedures
P1
CM-7
CM-7 (1)
P1
P1
CM-8
Not Selected
CM-8 (1) (5)
CM-9
P1
CP-1
CP-1
AU-8
AU-9
AU10
AU11
AU12
AU13
AU14
CA-1
CA-2
CA-3
CA-4
CA-5
CA-6
CA-7
CM-8
CM-9
CP-1
CP-2
CP-3
CP-4
Contingency Plan
Contingency Training
Contingency Plan Testing and
AU-8 (1)
AU-9
AU-10
AU-11
AU-12 (1)
Not
Selected
Not
Selected
CA-1
P1
P2
P2
CP-2
CP-3
CP-4
57
CP-2 (1)
CP-3
CP-4 (1)
CM-1
CM-2 (1)
(2) (3)(5) (6)
CM-3 (1)
(2)
CM-4 (1)
CM-5 (1)
(2) (3)
CM-6 (1)
(2) (3)
CM-7 (1)
(2)
CM-8 (1)
(2) (3)(4) (5)
CM-9
CP-1
CP-2 (1) (2)
(3)
CP-3 (1)
CP-4 (1) (2)
CP-5
Exercises
Contingency Plan Update
(Withdrawn)
CP-6
Alternate Storage Site
P1
Not Selected
CP-7
Alternate Processing Site
P1
Not Selected
CP-6 (1) (3)
CP-7 (1) (2) (3)
(5)
CP-8
Telecommunications Services
P1
Not Selected
CP-8 (1) (2)
CP-9
Information System Backup
Information System Recovery and
Reconstitution
Identification and
Authentication - Tech
Identification and Authentication
Policy and Procedures
P1
CP-9
CP-9 (1)
P1
CP-10
CP-10 (2) (3)
P1
IA-1
IA-1
P1
IA-2 (1)
IA-2 (1) (2) (3)
(8)
P1
P1
Not Selected
IA-4
IA-3
IA-4
P1
P1
IA-5 (1)
IA-6
IA-5 (1) (2) (3)
IA-6
P1
IA-7
IA-7
P1
IA-8
IA-8
P1
P2
IR-1
IR-2
IR-1
IR-2
P2
P1
P1
P1
P3
P1
Not Selected
IR-4
IR-5
IR-6
IR-7
IR-8
IR-3
IR-4 (1)
IR-5
IR-6 (1)
IR-7 (1)
IR-8
MA-1
Authenticator Management
Authenticator Feedback
Cryptographic Module
Authentication
Identification and Authentication
(Non-Organizational Users)
Incident Response - Op
Incident Response Policy and
Procedures
Incident Response Training
Incident Response Testing and
Exercises
Incident Handling
Incident Monitoring
Incident Reporting
Incident Response Assistance
Incident Response Plan
Maintenance - Op
System Maintenance Policy and
Procedures
P1
MA-1
MA-1
MA-2
Controlled Maintenance
P2
MA-2
MA-2 (1)
MA-3
MA-4
Maintenance Tools
Non-Local Maintenance
P2
P1
Not Selected
MA-4
MA-3 (1) (2)
MA-4 (1) (2)
CP-10
IA-1
IA-2
IA-3
IA-4
IA-5
IA-6
IA-7
IA-8
IR-1
IR-2
IR-3
IR-4
IR-5
IR-6
IR-7
IR-8
Identification and Authentication
(Organizational Users)
Device Identification and
Authentication
Identifier Management
(4)
58
CP-6 (1) (2)
(3)
CP-7 (1) (2)
(3)(4) (5)
CP-8 (1) (2)
(3)(4)
CP-9 (1) (2)
(3)
CP-10 (2)
(3) (4)
IA-1
IA-2 (1) (2)
(3) (4) (8)
(9)
IA-3
IA-4
IA-5 (1) (2)
(3)
IA-6
IA-7
IA-8
IR-1
IR-2 (1) (2)
IR-3 (1)
IR-4 (1)
IR-5 (1)
IR-6 (1)
IR-7 (1)
IR-8
MA-1
MA-2 (1)
(2)
MA-3 (1)
(2) (3)
MA-4 (1)
MA-5
MA-6
P1
P1
MA-5
Not Selected
MA-5
MA-6
MP-1
MP-2
MP-3
MP-4
Maintenance Personnel
Timely Maintenance
Media Protection - Op
Media Protection Policy and
Procedures
Media Access
Media Marking
Media Storage
P1
P1
P1
P1
MP-1
MP-2
Not Selected
Not Selected
MP-1
MP-2 (1)
MP-3
MP-4
MP-5
Media Transport
P1
Not Selected
MP-5 (2) (4)
MP-6
Media Sanitization
Physical and Environmental
Protection - Op
Physical and Environmental
Protection Policy and Procedures
Physical Access Authorizations
Physical Access Control
Access Control for Transmission
Medium
Access Control for Output
Devices
Monitoring Physical Access
Visitor Control
Access Records
Power Equipment and Power
Cabling
Emergency Shutoff
Emergency Power
Emergency Lighting
P1
MP-6
MP-6
P1
P1
P1
PE-1
PE-2
PE-3
PE-1
PE-2
PE-3
P1
Not Selected
PE-4
P1
P1
P1
P3
Not Selected
PE-6
PE-7
PE-8
PE-5
PE-6 (1)
PE-7 (1)
PE-8
P1
P1
P1
P1
Not Selected
Not Selected
Not Selected
PE-12
PE-9
PE-10
PE-11
PE-12
Fire Protection
Temperature and Humidity
Controls
Water Damage Protection
Delivery and Removal
Alternate Work Site
Location of Information System
Components
P1
PE-13
PE-13 (1) (2) (3)
P1
P1
P1
P1
PE-14
PE-15
PE-16
Not Selected
PE-14
PE-15
PE-16
PE-17
P2
Not Selected
PE-18
Information Leakage
Planning - Mgt
Security Planning Policy and
Procedures
System Security Plan
System Security Plan Update
(Withdrawn)
Rules of Behavior
P0
Not Selected
Not Selected
P1
PL-1
PL-2
PL-1
PL-2
P1
PL-4
PL-4
PE-1
PE-2
PE-3
PE-4
PE-5
PE-6
PE-7
PE-8
PE-9
PE-10
PE-11
PE-12
PE-13
PE-14
PE-15
PE-16
PE-17
PE-18
PE-19
PL-1
PL-2
PL-3
PL-4
P1
59
(2) (3)
MA-5
MA-6
MP-1
MP-2 (1)
MP-3
MP-4
MP-5 (2)
(3) (4)
MP-6 (1)
(2) (3)
PE-1
PE-2
PE-3 (1)
PE-4
PE-5
PE-6 (1) (2)
PE-7 (1)
PE-8 (1) (2)
PE-9
PE-10
PE-11 (1)
PE-12
PE-13 (1)
(2) (3)
PE-14
PE-15 (1)
PE-16
PE-17
PE-18 (1)
Not
Selected
PL-1
PL-2
PL-4
PL-5
PL-6
PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
RA-1
RA-2
RA-3
RA-4
RA-5
SA-1
SA-2
SA-3
SA-4
SA-5
SA-6
SA-7
SA-8
SA-9
SA-10
SA-11
SA-12
SA-13
SA-14
SC-1
Privacy Impact Assessment
Security-Related Activity
Planning
Personal Security - Op
Personnel Security Policy and
Procedures
Position Categorization
Personnel Screening
Personnel Termination
Personnel Transfer
Access Agreements
Third-Party Personnel Security
Personnel Sanctions
Risk Assessment - Mgt
Risk Assessment Policy and
Procedures
Security Categorization
Risk Assessment
Risk Assessment Update
(Withdrawn)
P1
PL-5
PL-5
Not Selected
PL-6
P1
P1
P1
P2
P2
P3
P1
P3
PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
P1
P1
P1
RA-1
RA-2
RA-3
RA-1
RA-2
RA-3
P3
Vulnerability Scanning
System and Services Acquisition
- Mgt
System and Services Acquisition
Policy and Procedures
Allocation of Resources
Life Cycle Support
P1
RA-5
RA-5 (1)
P1
P1
P1
SA-1
SA-2
SA-3
SA-1
SA-2
SA-3
Acquisitions
Information System
Documentation
Software Usage Restrictions
User-Installed Software
Security Engineering Principles
External Information System
Services
Developer Configuration
Management
Developer Security Testing
Supply Chain Protection
Trustworthiness
Critical Information System
Components
Systems and Communication
Protection - Tech
System and Communications
Protection Policy and Procedures
P1
SA-4
SA-4 (1) (4)
P2
P1
P1
P1
SA-5
SA-6
SA-7
Not Selected
SA-5 (1) (3)
SA-6
SA-7
SA-8
P1
SA-9
SA-9
P1
P2
P1
P1
Not Selected
Not Selected
Not Selected
Not Selected
SA-10
SA-11
Not Selected
Not Selected
P0
Not Selected
Not Selected
P1
SC-1
SC-1
60
PL-5
PL-6
PS-1
PS-2
PS-3
PS-4
PS-5
PS-6
PS-7
PS-8
RA-1
RA-2
RA-3
RA-5 (1)
(2) (3)(4) (5)
(7)
SA-1
SA-2
SA-3
SA-4 (1)
(2) (4)
SA-5 (1)
(2) (3)
SA-6
SA-7
SA-8
SA-9
SA-10
SA-11
SA-12
SA-13
Not
Selected
SC-1
SC-2
SC-3
SC-4
SC-5
Application Partitioning
Security Function Isolation
Information in Shared Resources
Denial of Service Protection
P1
P1
P1
P1
Not Selected
Not Selected
Not Selected
SC-5
SC-2
Not Selected
SC-4
SC-5
SC-6
Resource Priority
P0
Not Selected
Not Selected
SC-7
SC-8
SC-9
SC-10
Boundary Protection
Transmission Integrity
Transmission Confidentiality
Network Disconnect
P1
P1
P1
P2
SC-7
Not Selected
Not Selected
Not Selected
SC-7 (1) (2) (3)
(4) (5) (7)
SC-8 (1)
SC-9 (1)
SC-10
SC-11
P0
Not Selected
Not Selected
P1
P1
P1
P1
SC-12
SC-13
SC-14
SC-15
SC-12
SC-13
SC-14
SC-15
P0
Not Selected
Not Selected
P1
P1
P1
Not Selected
Not Selected
Not Selected
SC-17
SC-18
SC-19
P1
SC-20 (1)
SC-20 (1)
SC-22
SC-23
SC-24
Trusted Path
Cryptographic Key Establishment
and Management
Use of Cryptography
Public Access Protections
Collaborative Computing Devices
Transmission of Security
Attributes
Public Key Infrastructure
Certificates
Mobile Code
Voice Over Internet Protocol
Secure Name /Address Resolution
Service (Authoritative Source)
Secure Name /Address Resolution
Service (Recursive or Caching
Resolver)
Architecture and Provisioning for
Name/Address Resolution Service
Session Authenticity
Fail in Known State
SC-25
SC-26
SC-12
SC-13
SC-14
SC-15
SC-16
SC-17
SC-18
SC-19
SC-20
SC-21
SC-2
SC-3
SC-4
SC-5
Not
Selected
SC-7 (1) (2)
(3)(4) (5) (6)
(7) (8)
SC-8 (1)
SC-9 (1)
SC-10
Not
Selected
SC-12 (1)
SC-13
SC-14
SC-15
Not
Selected
SC-17
SC-18
SC-19
SC-20 (1)
SC-21
P1
Not Selected
Not Selected
P1
P1
P1
Not Selected
Not Selected
Not Selected
SC-22
SC-23
Not Selected
Thin Nodes
P0
Not Selected
Not Selected
P0
Not Selected
Not Selected
SC-27
SC-28
Honeypots
Operating System-Independent
Applications
Protection of Information at Rest
P0
P1
Not Selected
Not Selected
Not Selected
SC-28
SC-29
Heterogeneity
P0
Not Selected
Not Selected
SC-30
Virtualization Techniques
P0
Not Selected
Not Selected
SC-31
SC-32
SC-33
Covert Channel Analysis
Information System Partitioning
Transmission Preparation Integrity
P0
P0
P0
Not Selected
Not Selected
Not Selected
Not Selected
SC-32
Not Selected
61
SC-22
SC-23
SC-24
Not
Selected
Not
Selected
Not
Selected
SC-28
Not
Selected
Not
Selected
Not
Selected
SC-32
Not
SI-1
SI-2
Non-Modifiable Executable
Programs
System and Information
Integrity - Op
System and Information Integrity
Policy and Procedures
Flaw Remediation
SI-3
Malicious Code Protection
P1
SI-3
SI-4
Information System Monitoring
Security Alerts, Advisories, and
Directives
Security Functionality Verification
Software and Information
Integrity
Spam Protection
Information Input Restrictions
Information Input Validation
Error Handling
Information Output Handling and
Retention
P1
Not Selected
SI-3 (1) (2) (3)
SI-4 (2) (4) (5)
(6)
P1
P1
SI-5
Not Selected
SI-5
Not Selected
P1
P1
P2
P1
P2
Not Selected
Not Selected
Not Selected
Not Selected
Not Selected
SI-7 (1)
SI-8
SI-9
SI-10
SI-11
P2
SI-12
SI-12
Predictable Failure Prevention
Program Management - Mgt
P0
Not Selected
Not Selected
SC-34
SI-5
SI-6
SI-7
SI-8
SI-9
SI-10
SI-11
SI-12
SI-13
P0
Not Selected
Not Selected
P1
P1
SI-1
SI-2
SI-1
SI-2 (2)
PM-1
Information Security Program
Plan
P1
PM-2
Senior Information Security
Officer
P1
PM-3
Information Security Resources
P1
PM-4
Plan of Action and Milestones
Process
P1
PM-5
Information System Inventory
P1
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
62
Selected
Not
Selected
SI-1
SI-2 (1) (2)
SI-3 (1) (2)
(3)
SI-4 (2) (4)
(5)(6)
SI-5 (1)
SI-6
SI-7 (1) (2)
SI-8 (1)
SI-9
SI-10
SI-11
SI-12
Not
Selected
PM-6
Information Security Measures of
Performance
P1
PM-7
Enterprise Architecture
P1
PM-8
Critical Infrastructure Plan
P1
PM-9
Risk Management Strategy
P1
PM10
Security Authorization Process
P1
PM11
Mission/Business Process
Definition
P1
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
Deployed
Organizationwide
Supporting all
Baselines
INTERNATIONAL INFORMATION SECURITY STANDARDS
SECURITY CONTROL MAPPINGS FOR ISO/IEC 27001
The mapping tables in this appendix provide organizations with a general indication of
security control coverage with respect to ISO/IEC 27001, Information technology–Security
techniques–Information security management systems–Requirements.76 ISO/IEC 27001 applies to all
types of organizations (e.g., commercial, government) and specifies requirements for establishing,
implementing, operating, monitoring, reviewing, maintaining, and improving a documented information
security management system (ISMS) within the context of the organization’s overall business risks.
While the risk management approach established by NIST originally focused on managing risk from
information systems (as required by FISMA and described in NIST Special Publication 800-39), the
approach is being expanded to include risk management at the organizational level. A forthcoming
version of NIST Special Publication 800- 39 will incorporate ISO/IEC 27001 to manage organizational
information security risk through the establishment of an ISMS. Since NIST’s mission includes the
adoption of international and national standards where appropriate, NIST intends to pursue convergence
to reduce the burden on organizations that must conform to both sets of standards. The convergence
63
initiative will be carried out in three phases. Phase I, the subject of this appendix, provides a two-way
mapping between the security controls in NIST Special Publication 800-53 and the controls in ISO/IEC
27001 (Annex A). Phase II will provide a two-way mapping between the organization-level risk
management concepts in NIST Special Publication 800-39 (forthcoming version) and general
requirements in ISO/IEC 27001. Phase III will use the results from Phase I and II to fully integrate
ISO/IEC 27001 into NIST’s risk management approach such that an organization that complies with
NIST standards and guidelines can also comply with ISO/IEC 27001 (subject to appropriate assessment
requirements for ISO/IEC 27001 certification).
INDUSTRIAL CONTROL SYSTEMS
SECURITY CONTROLS, ENHANCEMENTS, AND SUPPLEMENTAL GUIDANCE
Industrial control systems (ICS) are information systems that differ significantly from traditional
administrative, mission support, and scientific data processing information systems. ICS typically have
many unique characteristics—including a need for real-time response and extremely high availability,
predictability, and reliability. These types of specialized systems are pervasive throughout the critical
infrastructure, often being required to meet several and often conflicting safety, operational, performance,
reliability, and security requirements such as: (i) minimizing risk to the health and safety of the public; (ii)
preventing serious damage to the environment; (iii) preventing serious production stoppages or
slowdowns that result in negative impact to the Nation’s economy and ability to carry out critical
functions; (iv) protecting the critical infrastructure from cyber attacks and common human error; and (v)
safeguarding against the compromise of proprietary information.
Previously, ICS had little resemblance to traditional information systems in that they were isolated
systems running proprietary software and control protocols. However, as these systems have been
increasingly integrated more closely into mainstream organizational information systems to promote
connectivity, efficiency, and remote access capabilities, portions of these ICS have started to resemble the
more traditional information systems. Increasingly, ICS use the same commercially available hardware
and software components as are used in the organization’s traditional information systems. While the
change in ICS architecture supports new information system capabilities, it also provides significantly
less isolation from the outside world for these systems, introducing many of the same vulnerabilities that
exist in current networked information
systems. The result is an even greater need to secure IC
FIPS 200, supported by NIST Special Publication 800-53, requires that federal agencies (and
organizations subordinate to those agencies) implement minimum security controls for their
organizational information systems based on the FIPS 199 security categorization of those systems. This
includes implementing the baseline security controls described in this document in ICS that are operated
by or on behalf of federal agencies. Section 3.3, Tailoring the Initial Baseline, allows organizations80 to
modify or adjust recommended security control baselines when certain conditions exist that require that
flexibility. NIST recommends that ICS owners take advantage of the ability to tailor the initial baselines
applying the ICS-specific guidance in this appendix. This appendix also contains additions to the initial
security control baselines that have been determined to be generally required for ICS.
64
Domain 4 – Governmental Laws and Regulations
Listed below are the Acts of Congress, OMB memos, executive orders and presidential directives
that impact federal IT systems. Acts of Congress, executive orders and presidential directive are
available at a number of Internet locations. OMB memos and bulletins can be obtained from
http://www.whitehouse.gov/omb
1. Acts of Congress
2. OMB Memorandums
3. OMB Circulars
4. Homeland Security President Directives
5. Executive Orders
1. Acts of Congress
a) Privacy Act of 1974
a. as amended 5 U.S.C. § 552a.
b) Paperwork Reduction Act of 1980
 44 USC § 3501, et. seq.
c) Computer Security Act of 1987
 Replaced by FISMA and is no longer in effect
d) Chief Financial Officers Act of 1990
e) Government Performance and Results Act of 1993
f) Paperwork and Elimination Act of 1998
g) Government Information Security Reform Act
 Replaced by FISMA and is no longer in effect
h) Federal Information Security Management Act of 2002
 44 U.S.C. 3541, et. Seq.
i) Health Insurance Portability and Accountability Act
j) Clinger-Cohen Act of 1996
The Privacy Act Of 1974
From Wikipedia, the free encyclopedia
The Privacy Act of 1974, 5 U.S.C. § 552a, Public Law No. 93-579, (Dec. 31, 1974) establishes a Code of
Fair Information Practice that governs the collection, maintenance, use, and dissemination of personally
identifiable information about individuals that is maintained in systems of records by federal agencies. A
system of records is a group of records under the control of an agency from which information is retrieved
by the name of the individual or by some identifier assigned to the individual. The Privacy Act requires
that agencies give the public notice of their systems of records by publication in the Federal Register. The
65
Privacy Act prohibits the disclosure of information from a system of records absent the written consent of
the subject individual, unless the disclosure is pursuant to one of twelve statutory exceptions. The Act
also provides individuals with a means by which to seek access to and amendment of their records, and
sets forth various agency record-keeping requirements.
Conditions of disclosure: The Privacy Act states in part: No agency shall disclose any record which is
contained in a system of records by any means of communication to any person, or to another agency,
except pursuant to a written request by, or with the prior written consent of, the individual to whom the
record pertains..
There are specific exceptions for the record allowing the use of personal records






For statistical purposes by the Census Bureau and the Bureau of Labor Statistics
For routine uses within a U.S. government agency
For archival purposes "as a record which has sufficient historical or other value to warrant its
continued preservation by the United States Government"
For law enforcement purposes
For congressional investigations
Other administrative purposes
The Privacy Act mandates that each United States Government agency have in place an administrative
and physical security system to prevent the unauthorized release of personal records.
Department of Justice: Subsection (u) requires that each agency have a Data Integrity Board. It is
supposed to make an annual report to OMB, available to the public, that includes all complaints that the
Act was violated, such as use of records for unauthorized reasons or the holding of First Amendment
Records and report on —…"(v) any violations of matching agreements that have been alleged or
identified and any corrective action taken‖. Former Attorney General Dick Thornburg appointed a Data
Integrity Board but since then USDOJ has not published any Privacy Act reports.[citation needed]
Computer Matching and Privacy Protection Act: The Computer Matching and Privacy Protection Act
of 1988, P.L. 100–503, amended the Privacy Act of 1974 by adding certain protections for the subjects of
Privacy Act records whose records are used in automated matching programs. These protections have
been mandated to ensure:



procedural uniformity in carrying out matching programs;
due process for subjects in order to protect their rights, and
oversight of matching programs through the establishment of Data Integrity Boards at each
agency engaging in matching to monitor the agency's matching activity.
n.b. The Computer Matching Act is codified as part of the Privacy Act.
Access to records: The Privacy Act also states: Each agency that maintains a system of records shall—
1. upon request by any individual ... permit him ... to review the record and have a copy made of all
or any portion thereof in a form comprehensible to him ...
2. permit the individual to request amendment of a record pertaining to him ...[1]
Issues of scope: The Privacy Act does apply to the records of every "individual,"[4] but the Privacy Act
only applies to records held by an "agency".[5]
66
Therefore the records held by courts, executive components, or non-agency government entities are not
subject to the provisions in the Privacy Act and there is no right to these records.[6]
Paperwork Reduction Act of 1980
The Paperwork Reduction Act of 1980, Pub. L. No. 96-511, 94 Stat. 2812 (Dec. 11, 1980), codified in part at
Subchapter I of Chapter 35 of Title 44 of the United States Code, 44 U.S.C. § 3501 through 44 U.S.C. § 3521, is a
United States federal law enacted in 1980 that gave authority over the collection of certain information to the Office
of Management and Budget (OMB). Within the OMB, the Office of Information and Regulatory Affairs (OIRA)
was established with specific authority to regulate matters regarding federal information and to establish information
policies. These information policies were intended to reduce the total amount of paperwork handled by the United
States government and the general public.
The PRA mandates that all federal government agencies must obtain a Control Number from OMB before
promulgating a form that will impose an information collection burden on the general public. Once obtained,
approval must be renewed every three years. In order to obtain or renew such approval, an agency must fill out
OMB Form 83-I, attach the proposed form, and file it with OIRA. On Form 83-I, the agency must explain the reason
why the form is needed and estimate the burden in terms of time and money that the form will impose upon the
persons required to fill it out.
The process created by the PRA makes OIRA into a centralized clearinghouse for all government forms. Thus, it is
able to assess the overall impact of the government bureaucracy on American citizens and businesses. This is done
in an annual document called the Information Collection Budget of the United States Government.
Computer Security Act of 1987
Synopsis: Is for the protection of sensitive information
It has been superseded by the Federal Information Security Management Act of 2002
The Computer Security Law of 1987, Public Law No. 100-235 (H.R. 145), (Jan. 8, 1988), was passed
by the United States Congress.
It was passed to
 improve the security and privacy of sensitive information in Federal computer systems and to
 establish a minimum acceptable security practices for such systems.
It requires the creation of computer security plans, and the appropriate training of system users or owners
where the systems house sensitive information.
Provisions
 Assigns the National Institute of Standards and Technology (NIST, At the time named National
Bureau of Standards) to develop standards of minimum acceptable practices with the help of the
NSA
 Requires establishment of security policies for Federal computer systems that contain sensitive
information.
 Mandatory security awareness training for federal employees that use those systems.
Chief Financial Officers Act (1990)
Synopsis:



intended to improve the government's financial management,
outlining standards of financial performance and disclosure.
Creates the CFO for each of the 24 federal agencies.
67
The Chief Financial Officer and Federal Financial Reform Act of 1990, or CFO Act, signed into law
by President George H.W. Bush on November 15, 1990, is a United States federal law intended to
improve the government's financial management, outlining standards of financial performance and
disclosure. Among other measures, the Office of Management and Budget (OMB) was given greater
authority over federal financial management. For each of 24 federal departments and agencies, the
position of chief financial officer was created. In accordance with the CFO Act, each agency or
department vests its financial management functions in its chief financial officer.
The Act created a new position in the OMB, the Deputy Director for Management, who is the
government's chief financial management official. It also created a new sub-division of the OMB, the
Office of Federal Financial Management (OFFM), to carry out governmentwide financial management
responsibilities. The OFFM's chief officer was designated as the newly-created Controller position. Both
the Deputy Director for Management and the Controller are appointed by the President with the advice
and consent of the Senate.
The Committee on Government Reform oversees the management and infrastructure of the federal
agencies, including those covered by the CFO Act. The CFO Act also established the CFO Council,
consisting of the CFOs and Deputy CFOs of the largest federal agencies and senior officials of OMB and
Treasury.[1][2] For a discussion of the history and motivation underlying the CFO Act - with particular
emphasis on the difficulties the U.S. Department of Defense has experienced attempting to comply with
the financial-statement reporting requirements of the Act - see "Financial Accountability at the DOD:
Reviewing the Bidding," published in the July 2009 issue of the Defense Acquisition Review Journal and
available at: [1]. The original author of the legislation was Joseph J. DioGuardi, the first certified public
accountant elected to Congress, who served in the House of Representatives representing the 20th
Congressional district of New York from 1985 to 1989.
Government Performance and Results Act (1993)
Synopsis:



First, agencies are required to develop five-year strategic plans that must contain a mission
statement for the agency, and long term results-oriented goals covering each of its major
functions.
Second, agencies are required to prepare annual performance plans that establish the performance
goals for the applicable fiscal year, a brief description of how these goals are to be met, and a
description of how these performance goals can be verified.
And third, agencies must prepare annual performance reports that review the agency’s success or
failure in meeting its targeted performance goals.
The Government Performance and Results Act (GPRA) (P.L. 103-62) is a United States law enacted in
1993. It is one of a series of laws designed to improve government project management. The GPRA
requires agencies to engage in project management tasks such as setting goals, measuring results, and
reporting their progress. In order to comply with GPRA, agencies produce strategic plans, performance
plans, and conduct gap analysis of projects.
The foundation of GPRA is based on the following three elements as follows: First, agencies are required
to develop five-year strategic plans that must contain a mission statement for the agency, and long term
results-oriented goals covering each of its major functions. Second, agencies are required to prepare
68
annual performance plans that establish the performance goals for the applicable fiscal year, a brief
description of how these goals are to be met, and a description of how these performance goals can be
verified. And third, agencies must prepare annual performance reports that review the agency’s success or
failure in meeting its targeted performance goals.
Office of Management and Budget (OMB) is tasked pursuant to GPRA with producing an annual report
on agency performance. This is produced with the President's annual budget request.
Government Paperwork Elimination Act
The Government Paperwork Elimination Act (GPEA, Pub.L. 105-277) requires that, when practicable,
Federal agencies use electronic forms, electronic filing, and electronic signatures to conduct official
business with the public by 2003. In doing this, agencies will create records with business, legal and, in
some cases, historical value. This guidance focuses on records management issues involving records
that have been created using electronic signature technology.[1]
The Act requires agencies, by October 21, 2003, to allow individuals or entities that deal with the
agencies the option to submit information or transact with the agency electronically, when practicable,
and to maintain records electronically, when practicable. The Act specifically states that electronic
records and their related electronic signatures are not to be denied legal effect, validity, or enforceability
merely because they are in electronic form, and encourages Federal government use of a range of
electronic signature alternatives.[2]
The Act seeks to "preclude agencies or courts from systematically treating electronic documents and
signatures less favorably than their paper counterparts", so that citizens can interact with the Federal
government electronically (S. Rep. 105-335). It requires Federal agencies, by October 21, 2003, to
provide individuals or entities that deal with agencies the option to submit information or transact with
the agency electronically, and to maintain records electronically, when practicable. It also addresses the
matter of private employers being able to use electronic means to store, and file with Federal
agencies, information pertaining to their employees. GPEA states that electronic records and their
related electronic signatures are not to be denied legal effect, validity, or enforceability merely because
they are in electronic form. It also encourages Federal government use of a range of electronic signature
alternatives.[2]
The Act is technology-neutral, meaning that the act does not require the government to use one
technology over another. This approach has both advantages and disadvantages. By remaining neutral it
allows each government agency to decide which technology fits its specific needs. It also means that the
government is not restricted to use an older technology as newer and better systems are made available.
As a disadvantage some may argue over which signature capturing method is best and such disagreements
may slow the process of implementation.
Government Information Security Reform Act - (GISRA, 2000)
The Government Information Security Reform Act (GISRA) established information security program,
evaluation, and reporting requirements for federal agencies. GISRA required agencies to perform periodic
threat-based risk assessments for systems and data. GISRA requires agencies to develop and
implement risk-based, cost-effective policies and procedures to provide security protection for
information collected or maintained either by the agency or for it by another agency or contractor. GISRA
required that agencies develop a process for ensuring that remedial action is taken to address significant
deficiencies. GISRA also required agencies to provide training on security awareness for agency
69
personnel and on security responsibilities for information security personnel. GISRA required the
agency head to ensure that the agency‟s information security plan is practiced throughout the life
cycle of each agency system. The agency head was responsible for ensuring that the appropriate agency
officials, evaluated the effectiveness of the information security program, including testing controls.
Federal Information Security Management Act of 2002
The Federal Information Security Management Act of 2002 ("FISMA", 44 U.S.C. § 3541, et seq.) is a United
States federal law enacted in 2002 as Title III of the E-Government Act of 2002 (Pub.L. 107-347, 116 Stat. 2899).
The act recognized the importance of information security to the economic and national security interests of the
United States.[1] The act requires each federal agency to develop, document, and implement an agency-wide
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.[1]
FISMA has brought attention within the federal government to cybersecurity and explicitly emphasized a "riskbased policy for cost-effective security."[1] FISMA requires agency program officials, chief information officers,
and inspectors general (IGs) to conduct annual reviews of the agency’s information security program and report the
results to Office of Management and Budget (OMB). OMB uses this data to assist in its oversight responsibilities
and to prepare this annual report to Congress on agency compliance with the act.[2] In FY 2008, federal agencies
spent $6.2 billion securing the government’s total information technology investment of approximately $68 billion
or about 9.2 percent of the total information technology portfolio. [3]
Purpose of the act
FISMA assigns specific responsibilities to federal agencies, the National Institute of Standards and Technology
(NIST) and the Office of Management and Budget (OMB) in order to strengthen information system security. In
particular, FISMA requires the head of each agency to implement policies and procedures to cost-effectively reduce
information technology security risks to an acceptable level.[2] According to FISMA, the term information security
means protecting information and information systems from unauthorized access, use, disclosure, disruption,
modification, or destruction in order to provide integrity, confidentiality and availability.
Implementation of FISMA
In accordance with FISMA, NIST is responsible for developing standards, guidelines, and associated
methods and techniques for providing adequate information security for all agency operations and assets,
excluding national security systems. NIST works closely with federal agencies to improve their
understanding and implementation of FISMA to protect their information and information systems and
publishes standards and guidelines which provide the foundation for strong information security programs
at agencies. NIST performs its statutory responsibilities through the Computer Security Division of the
Information Technology Laboratory.[4] NIST develops standards, metrics, tests, and validation programs
to promote, measure, and validate the security in information systems and services. NIST hosts the
following:


FISMA implementation project[5]
Information Security Automation Program (ISAP) – * National Vulnerability Database (NVD) –
the U.S. government content repository for ISAP and SCAP. NVD is the U.S. government
repository of standards based vulnerability management data. This data enables automation of
vulnerability management, security measurement, and compliance (e.g., FISMA)[6]
Compliance framework defined by FISMA and supporting standards
70
FISMA defines a framework for managing information security that must be followed for all information
systems used or operated by a U.S. federal government agency or by a contractor or other organization on
behalf of a federal agency. This framework is further defined by the standards and guidelines developed
by NIST[7].
Inventory of information systems
FISMA requires that agencies have in place an information systems inventory. According to FISMA, the
head of each agency shall develop and maintain an inventory of major information systems (including
major national security systems) operated by or under the control of such agency[7] The identification of
information systems in an inventory under this subsection shall include an identification of the interfaces
between each such system and all other systems or networks, including those not operated by or under the
control of the agency.[7] The first step is to determine what constitutes the "information system" in
question. There is not a direct mapping of computers to information system; rather, an information system
may be a collection of individual computers put to a common purpose and managed by the same system
owner. NIST SP 800-18, Revision 1, Guide for Developing Security Plans for Federal Information
Systems[8] provides guidance on determining system boundaries.
Risk assessment
The combination of FIPS 200 and NIST Special Publication 800-53 requires a foundational level of
security for all federal information and information systems. The agency's risk assessment validates the
security control set and determines if any additional controls are needed to protect agency operations
(including mission, functions, image, or reputation), agency assets, individuals, other organizations, or the
Nation. The resulting set of security controls establishes a level of ―security due diligence‖ for the federal
agency and its contractors.[11] A risk assessment starts by identifying potential threats and vulnerabilities
and mapping implemented controls to individual vulnerabilities. One then determines risk by calculating
the likelihood and impact that any given vulnerability could be exploited, taking into account existing
controls. The culmination of the risk assessment shows the calculated risk for all vulnerabilities and
describes whether the risk should be accepted or mitigated. If mitigated by the implementation of a
control, one needs to describe what additional Security Controls will be added to the system.
NIST also initiated the Information Security Automation Program (ISAP) and Security Content
Automation Protocol (SCAP) that support and complement the approach for achieving consistent, costeffective security control assessments.
System security plan
Agencies should develop policy on the system security planning process.[7] NIST SP-800-18 introduces
the concept of a System Security Plan.[8] System security plans are living documents that require periodic
review, modification, and plans of action and milestones for implementing security controls. Procedures
should be in place outlining who reviews the plans, keeps the plan current, and follows up on planned
security controls.[8]
The System security plan is the major input to the security certification and accreditation process for the
system. During the security certification and accreditation process, the system security plan is analyzed,
updated, and accepted. The certification agent confirms that the security controls described in the system
security plan are consistent with the FIPS 199 security category determined for the information system,
and that the threat and vulnerability identification and initial risk determination are identified and
documented in the system security plan, risk assessment, or equivalent document.[8]
71
Certification and accreditation
Once the system documentation and risk assessment has been completed, the system's controls must be
reviewed and certified to be functioning appropriately. Based on the results of the review, the information
system is accredited. The certification and accreditation process is defined in NIST SP 800-37 "Guide for
the Security Certification and Accreditation of Federal Information Systems".[12] Security accreditation is
the 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, agency assets, or individuals
based on the implementation of an agreed-upon set of security controls. Required by OMB Circular A130, Appendix III, security accreditation provides a form of quality control and challenges managers and
technical staffs at all levels to implement the most effective security controls possible in an information
system, given mission requirements, technical constraints, operational constraints, and cost/schedule
constraints. By accrediting an information system, an agency official accepts responsibility for the
security of the system and is fully accountable for any adverse impacts to the agency if a breach of
security occurs. Thus, responsibility and accountability are core principles that characterize security
accreditation. It is essential that agency officials have the most complete, accurate, and trustworthy
information possible on the security status of their information systems in order to make timely, credible,
risk-based decisions on whether to authorize operation of those systems.[12]
The information and supporting evidence needed for security accreditation is developed during a detailed
security review of an information system, typically referred to as security certification. Security
certification is a 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. The results of a security certification are
used to reassess the risks and update the system security plan, thus providing the factual basis for an
authorizing official to render a security accreditation decision.[12]
Continuous monitoring
All accredited systems are required to monitor a selected set of security controls and the system
documentation is updated to reflect changes and modifications to the system. Large changes to the
security profile of the system should trigger an updated risk assessment, and controls that are significantly
modified may need to be re-certified.
Continuous monitoring activities include configuration management and control of information system
components, security impact analyses of changes to the system, ongoing assessment of security controls,
and status reporting. The organization establishes the selection criteria and subsequently selects a subset
of the security controls employed within the information system for assessment. The organization also
establishes the schedule for control monitoring to ensure adequate coverage is achieved.
Status
As of June 2010, multiple bills in Congress are proposing changes to FISMA, including shifting focus
from periodic assessment to real-time assessment and increasing use of automation for reporting. [17]
72
Health Insurance Portability and Accountability Act (1996)
From Wikipedia, the free encyclopedia
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (P.L.104-191) [HIPAA]
was enacted by the U.S. Congress in 1996. It was originally sponsored by Sen. Edward Kennedy (DMass.) and Sen. Nancy Kassebaum (R-Kan.). According to the Centers for Medicare and Medicaid
Services (CMS) website, Title I of HIPAA protects health insurance coverage for workers and their
families when they change or lose their jobs. Title II of HIPAA, known as the Administrative
Simplification (AS) provisions, requires the establishment of national standards for electronic health
care transactions and national identifiers for providers, health insurance plans, and employers.
The Administration Simplification provisions also address the security and privacy of health data. The
standards are meant to improve the efficiency and effectiveness of the nation's health care system by
encouraging the widespread use of electronic data interchange in the U.S. health care system.
Title I: Health Care Access, Portability, and Renewability
Title I of HIPAA regulates the availability and breadth of group health plans and certain individual health
insurance policies. It amended the Employee Retirement Income Security Act, the Public Health Service
Act, and the Internal Revenue Code.
Title I also limits restrictions that a group health plan can place on benefits for preexisting conditions.
Group health plans may refuse to provide benefits relating to preexisting conditions for a period of 12
months after enrollment in the plan or 18 months in the case of late enrollment.[1] However, individuals
may reduce this exclusion period if they had group health plan coverage or health insurance prior to
enrolling in the plan. Title I allows individuals to reduce the exclusion period by the amount of time that
they had "creditable coverage" prior to enrolling in the plan and after any "significant breaks" in
coverage.[2] "Creditable coverage" is defined quite broadly and includes nearly all group and individual
health plans, Medicare, and Medicaid.[3] A "significant break" in coverage is defined as any 63 day period
without any creditable coverage.[4]
Some health care plans are exempted from Title I requirements, such as long-term health plans and
limited-scope plans such as dental or vision plans that are offered separately from the general health plan.
However, if such benefits are part of the general health plan, then HIPAA still applies to such benefits.
For example, if the new plan offers dental benefits, then it must count creditable continuous coverage
under the old health plan towards any of its exclusion periods for dental benefits.
However, an alternate method of calculating creditable continuous coverage is available to the health plan
under Title I. That is, 5 categories of health coverage can be considered separately, including dental and
vision coverage. Anything not under those 5 categories must use the general calculation (e.g., the
beneficiary may be counted with 18 months of general coverage, but only 6 months of dental coverage,
because the beneficiary did not have a general health plan that covered dental until 6 months prior to the
application date). Unfortunately, since limited-coverage plans are exempt from HIPAA requirements, the
odd case exists in which the applicant to a general group health plan cannot obtain certificates of
creditable continuous coverage for independent limited-scope plans such as dental to apply towards
exclusion periods of the new plan that does include those coverages.
Hidden exclusion periods are not valid under Title I (e.g., "The accident, to be covered, must have
occurred while the beneficiary was covered under this exact same health insurance contract"). Such
73
clauses must not be acted upon by the health plan and also must be re-written so that they comply with
HIPAA.
To illustrate, suppose someone enrolls in a group health plan on January 1, 2006. This person had
previously been insured from January 1, 2004 until February 1, 2005 and from August 1, 2005 until
December 31, 2005. To determine how much coverage can be credited against the exclusion period in the
new plan, start at the enrollment date and count backwards until you reach a significant break in coverage.
So, the five months of coverage between August 1, 2005 and December 31, 2005 clearly counts against
the exclusion period. But the period without insurance between February 1, 2005 and August 1, 2005 is
greater than 63 days. Thus, this is a significant break in coverage, and any coverage prior to it cannot be
deducted from the exclusion period. So, this person could deduct five months from his or her exclusion
period, reducing the exclusion period to seven months. Hence, Title I requires that any preexisting
condition begin to be covered on August 1, 2006.
Title II: Preventing Health Care Fraud and Abuse; Administrative Simplification; Medical
Liability Reform
Title II of HIPAA defines numerous offenses relating to health care and sets civil and criminal penalties
for them. It also creates several programs to control fraud and abuse within the health care system.[5][6][7]
However, the most significant provisions of Title II are its Administrative Simplification rules. Title II
requires the Department of Health and Human Services (HHS) to draft rules aimed at increasing the
efficiency of the health care system by creating standards for the use and dissemination of health care
information. These rules apply to "covered entities" as defined by HIPAA and the HHS. Covered entities
include health plans, health care clearinghouses, such as billing services and community health
information systems, and health care providers that transmit health care data in a way that is regulated by
HIPAA.[8][9] Per the requirements of Title II, the HHS has promulgated five rules regarding
Administrative Simplification: the Privacy Rule, the Transactions and Code Sets Rule, the Security Rule,
the Unique Identifiers Rule, and the Enforcement Rule.
Privacy Rule
The Privacy Rule took effect on April 14, 2003, with a one-year extension for certain "small plans". The
HIPAA Privacy Rule regulates the use and disclosure of certain information held by "covered entities"
(generally, health care clearinghouses, employer sponsored health plans, health insurers, and medical
service providers that engage in certain transactions.)[10] It establishes regulations for the use and
disclosure of Protected Health Information (PHI). PHI is any information held by a covered entity
which concerns health status, provision of health care, or payment for health care that can be linked to an
individual.[11] This is interpreted rather broadly and includes any part of an individual's medical record or
payment history. Covered entities must disclose PHI to the individual within 30 days upon request.[12]
They also must disclose PHI when required to do so by law, such as reporting suspected child abuse to
state child welfare agencies.[13]
A covered entity may disclose PHI to facilitate treatment, payment, or health care operations,[14] or if the
covered entity has obtained authorization from the individual.[15] However, when a covered entity
discloses any PHI, it must make a reasonable effort to disclose only the minimum necessary information
required to achieve its purpose.[16] The Privacy Rule gives individuals the right to request that a covered
entity correct any inaccurate PHI.[17] It also requires covered entities to take reasonable steps to ensure the
confidentiality of communications with individuals.[18] For example, an individual can ask to be called at
his or her work number, instead of home or cell phone number.
74
The Privacy Rule requires covered entities to notify individuals of uses of their PHI. Covered entities
must also keep track of disclosures of PHI and document privacy policies and procedures.[19] They must
appoint a Privacy Official and a contact person[20] responsible for receiving complaints and train all
members of their workforce in procedures regarding PHI.[21] An individual who believes that the Privacy
Rule is not being upheld can file a complaint with the Department of Health and Human Services Office
for Civil Rights (OCR).[22][23] However, according to the Wall Street Journal, the OCR has a long backlog
and ignores most complaints. "Complaints of privacy violations have been piling up at the Department of
Health and Human Services. Between April 2003 and Nov. 30, the agency fielded 23,896 complaints
related to medical-privacy rules, but it has not yet taken any enforcement actions against hospitals,
doctors, insurers or anyone else for rule violations. A spokesman for the agency says it has closed threequarters of the complaints, typically because it found no violation or after it provided informal guidance
to the parties involved."[24] Unfortunately many hospitals have broadly interpreted the privacy act and
have not allowed patient information or condition to be released to the families of the hospitalized over
the telephone even if the patient is critically ill and the family member lives out of state. Additionally
strict penalty has been implemented for those (mostly nurses) who unknowingly violate HIPAA in this
manner and many have been terminated from their nursing positions for accidental blunders of the
hospitals interpretation of the law.[citation needed]
Transactions and Code Sets Rule
The HIPAA/EDI provision was scheduled to take effect from October 16, 2003 with a one-year extension
for certain "small plans". However, due to widespread confusion and difficulty in implementing the rule,
CMS granted a one-year extension to all parties. On January 1, 2012 the newest version 5010 becomes
effective, replacing the version 4010.[25] This allows for the larger field size of ICD-10-CM as well as
other improvements.
After July 1, 2005 most medical providers that file electronically did have to file their electronic claims
using the HIPAA standards in order to be paid.
Key EDI(X12) transactions used for HIPAA compliance are:
EDI Health Care Claim Transaction set (837) is used to submit health care claim billing information,
encounter information, or both, except for retail pharmacy claims (see EDI Retail Pharmacy Claim
Transaction). It can be sent from providers of health care services to payers, either directly or via
intermediary billers and claims clearinghouses. It can also be used to transmit health care claims and
billing payment information between payers with different payment responsibilities where coordination of
benefits is required or between payers and regulatory agencies to monitor the rendering, billing, and/or
payment of health care services within a specific health care/insurance industry segment.
For example, a state mental health agency may mandate all healthcare claims, Providers and health plans
who trade professional (medical) health care claims electronically must use the 837 Health Care Claim:
Professional standard to send in claims. As there are many different business applications for the Health
Care claim, there can be slight derivations to cover off claims involving unique claims such as for
Institutions, Professionals, Chiropractors, and Dentists etc.
EDI Retail Pharmacy Claim Transaction (NCPDP Telecommunications Standard version 5.1) is
used to submit retail pharmacy claims to payers by health care professionals who dispense medications,
either directly or via intermediary billers and claims clearinghouses. It can also be used to transmit claims
for retail pharmacy services and billing payment information between payers with different payment
responsibilities where coordination of benefits is required or between payers and regulatory agencies to
75
monitor the rendering, billing, and/or payment of retail pharmacy services within the pharmacy health
care/insurance industry segment.
EDI Health Care Claim Payment/Advice Transaction Set (835) can be used to make a payment, send
an Explanation of Benefits (EOB) remittance advice, or make a payment and send an EOB remittance
advice only from a health insurer to a health care provider either directly or via a financial institution.
EDI Benefit Enrollment and Maintenance Set (834) can be used by employers, unions, government
agencies, associations or insurance agencies to enroll members to a payer. The payer is a healthcare
organization that pays claims, administers insurance or benefit or product. Examples of payers include an
insurance company, health care professional (HMO), preferred provider organization (PPO), government
agency (Medicaid, Medicare etc.) or any organization that may be contracted by one of these former
groups.
EDI Payroll Deducted and other group Premium Payment for Insurance Products (820) is a
transaction set which can be used to make a premium payment for insurance products. It can be used to
order a financial institution to make a payment to a payee.
EDI Health Care Eligibility/Benefit Inquiry (270) is used to inquire about the health care benefits and
eligibility associated with a subscriber or dependent.
EDI Health Care Eligibility/Benefit Response (271) is used to respond to a request inquire about the
health care benefits and eligibility associated with a subscriber or dependent.
EDI Health Care Claim Status Request (276) This transaction set can be used by a provider, recipient
of health care products or services or their authorized agent to request the status of a health care claim.
EDI Health Care Claim Status Notification (277) This transaction set can be used by a health care
payer or authorized agent to notify a provider, recipient or authorized agent regarding the status of a
health care claim or encounter, or to request additional information from the provider regarding a health
care claim or encounter. This transaction set is not intended to replace the Health Care Claim
Payment/Advice Transaction Set (835) and therefore, is not used for account payment posting. The
notification is at a summary or service line detail level. The notification may be solicited or unsolicited.
EDI Health Care Service Review Information (278) This transaction set can be used to transmit health
care service information, such as subscriber, patient, demographic, diagnosis or treatment data for the
purpose of request for review, certification, notification or reporting the outcome of a health care services
review.
EDI Functional Acknowledgement Transaction Set (997) this transaction set can be used to define the
control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the
electronically encoded documents. Although it is not specifically named in the HIPAA Legislation or
Final Rule, it is necessary for X12 transaction set processing . The encoded documents are the transaction
sets, which are grouped in functional groups, used in defining transactions for business data interchange.
This standard does not cover the semantic meaning of the information encoded in the transaction sets.
Security Rule
The Final Rule on Security Standards was issued on February 20, 2003. It took effect on April 21, 2003
with a compliance date of April 21, 2005 for most covered entities and April 21, 2006 for "small plans".
76
The Security Rule complements the Privacy Rule. While the Privacy Rule pertains to all Protected
Health Information (PHI) including paper and electronic, the Security Rule deals specifically with
Electronic Protected Health Information (EPHI). It lays out three types of security safeguards
required for compliance: administrative, physical, and technical. For each of these types, the Rule
identifies various security standards, and for each standard, it names both required and addressable
implementation specifications. Required specifications must be adopted and administered as dictated by
the Rule. Addressable specifications are more flexible. Individual covered entities can evaluate their own
situation and determine the best way to implement addressable specifications. Some privacy advocates
have argued that this "flexibility" may provide too much latitude to covered entities. [26] The standards and
specifications are as follows:

Administrative Safeguards – policies and procedures designed to clearly show how the entity
will comply with the act
o Covered entities (entities that must comply with HIPAA requirements) must adopt a
written set of privacy procedures and designate a privacy officer to be responsible for
developing and implementing all required policies and procedures.
o The policies and procedures must reference management oversight and organizational
buy-in to compliance with the documented security controls.
o Procedures should clearly identify employees or classes of employees who will have
access to electronic protected health information (EPHI). Access to EPHI must be
restricted to only those employees who have a need for it to complete their job function.
o The procedures must address access authorization, establishment, modification, and
termination.
o Entities must show that an appropriate ongoing training program regarding the handling
of PHI is provided to employees performing health plan administrative functions.
o Covered entities that out-source some of their business processes to a third party must
ensure that their vendors also have a framework in place to comply with HIPAA
requirements. Companies typically gain this assurance through clauses in the contracts
stating that the vendor will meet the same data protection requirements that apply to the
covered entity. Care must be taken to determine if the vendor further out-sources any data
handling functions to other vendors and monitor whether appropriate contracts and
controls are in place.
o A contingency plan should be in place for responding to emergencies. Covered entities
are responsible for backing up their data and having disaster recovery procedures in
place. The plan should document data priority and failure analysis, testing activities, and
change control procedures.
o Internal audits play a key role in HIPAA compliance by reviewing operations with the
goal of identifying potential security violations. Policies and procedures should
specifically document the scope, frequency, and procedures of audits. Audits should be
both routine and event-based.
o Procedures should document instructions for addressing and responding to security
breaches that are identified either during the audit or the normal course of operations.

Physical Safeguards – controlling physical access to protect against inappropriate access to
protected data
o Controls must govern the introduction and removal of hardware and software from the
network. (When equipment is retired it must be disposed of properly to ensure that PHI is
not compromised.)
o Access to equipment containing health information should be carefully controlled and
monitored.
o Access to hardware and software must be limited to properly authorized individuals.
77
o
o
o

Required access controls consist of facility security plans, maintenance records, and
visitor sign-in and escorts.
Policies are required to address proper workstation use. Workstations should be removed
from high traffic areas and monitor screens should not be in direct view of the public.
If the covered entities utilize contractors or agents, they too must be fully trained on their
physical access responsibilities.
Technical Safeguards – controlling access to computer systems and enabling covered entities to
protect communications containing PHI transmitted electronically over open networks from being
intercepted by anyone other than the intended recipient.
o Information systems housing PHI must be protected from intrusion. When information
flows over open networks, some form of encryption must be utilized. If closed
systems/networks are utilized, existing access controls are considered sufficient and
encryption is optional.
o Each covered entity is responsible for ensuring that the data within its systems has not
been changed or erased in an unauthorized manner.
o Data corroboration, including the use of check sum, double-keying, message
authentication, and digital signature may be used to ensure data integrity.
o Covered entities must also authenticate entities with which they communicate.
Authentication consists of corroborating that an entity is who it claims to be. Examples of
corroboration include: password systems, two or three-way handshakes, telephone
callback, and token systems.
o Covered entities must make documentation of their HIPAA practices available to the
government to determine compliance.
o In addition to policies and procedures and access records, information technology
documentation should also include a written record of all configuration settings on the
components of the network because these components are complex, configurable, and
always changing.
o Documented risk analysis and risk management programs are required. Covered entities
must carefully consider the risks of their operations as they implement systems to comply
with the act. (The requirement of risk analysis and risk management implies that the act’s
security requirements are a minimum standard and places responsibility on covered
entities to take all reasonable precautions necessary to prevent PHI from being used for
non-health purposes.)
Unique Identifiers Rule (National Provider Identifier)
HIPAA covered entities such as providers completing electronic transactions, healthcare clearinghouses,
and large health plans, must use only the National Provider Identifier (NPI) to identify covered healthcare
providers in standard transactions by May 23, 2007. Small health plans must use only the NPI by May 23,
2008.
Effective from May 2006 (May 2007 for small health plans), all covered entities using electronic
communications (e.g., physicians, hospitals, health insurance companies, and so forth) must use a single
new NPI. The NPI replaces all other identifiers used by health plans, Medicare (i.e., the UPIN), Medicaid,
and other government programs. However, the NPI does not replace a provider's DEA number, state
license number, or tax identification number. The NPI is 10 digits (may be alphanumeric), with the last
digit being a checksum. The NPI cannot contain any embedded intelligence; in other words, the NPI is
simply a number that does not itself have any additional meaning. The NPI is unique and national, never
78
re-used, and except for institutions, a provider usually can have only one. An institution may obtain
multiple NPIs for different "subparts" such as a free-standing cancer center or rehab facility.
Enforcement Rule
On February 16, 2006, HHS issued the Final Rule regarding HIPAA enforcement. It became effective on
March 16, 2006. The Enforcement Rule sets civil money penalties for violating HIPAA rules and
establishes procedures for investigations and hearings for HIPAA violations; however, its deterrent
effects seem to be negligible with few prosecutions for violations.[27]
HITECH Act: Privacy Requirements
Subtitle D of the Health Information Technology for Economic and Clinical Health Act (HITECH Act),
enacted as part of the American Recovery and Reinvestment Act of 2009, and addresses the privacy and
security concerns associated with the electronic transmission of health information.
This subtitle extends the complete Privacy and Security Provisions of HIPAA to business associates
of covered entities. This includes the extension of newly updated civil and criminal penalties to business
associates. These changes are also required to be included in any business associate agreements with
covered entities. On November 30, 2009, the regulations associated with the new enhancements to
HIPAA enforcement took effect[28].
Another significant change brought about in Subtitle D of the HITECH Act, is the new breach
notification requirements. This imposes new notification requirements on covered entities, business
associates, vendors of personal health records (PHR) and related entities if a breach of unsecured
protected health information (PHI) occurs. On April 27, 2009, the Department of Health and Human
Services (HHS) issued guidance on how to secure protected health information appropriately[29]. Both
HHS and the Federal Trade Commission (FTC) were required under the HITECH Act to issue regulations
associated with the new breach notification requirements. The HHS rule was published in the Federal
Register on August 24, 2009[30], and the FTC rule was published on August 25, 2009[31].
The final significant change made in Subtitle D of the HITECH Act, implements new rules for the
accounting of disclosures of a patient's health information. It extends the current accounting for
disclosure requirements to information that is used to carry out treatment, payment and health care
operations when an organization is using an electronic health record (EHR). This new requirement also
limits the timeframe for the accounting to three years instead of six as it currently stands. These changes
won't take effect until January 1, 2011, for organizations implementing EHRs between January 1, 2009
and January 1, 2011, and January 1, 2013, for organizations who had implemented an EHR prior to
January 1, 2009.
Effects on research and clinical care
The enactment of the Privacy and Security Rules has caused major changes in the way physicians and
medical centers operate. The complex legalities and potentially stiff penalties associated with HIPAA, as
well as the increase in paperwork and the cost of its implementation, were causes for concern among
physicians and medical centers. An August 2006 article in the journal Annals of Internal Medicine
detailed some such concerns over the implementation and effects of HIPAA.[32]
79
Effects on research
HIPAA restrictions on researchers have affected their ability to perform retrospective, chart-based
research as well as their ability to prospectively evaluate patients by contacting them for follow-up. A
study from the University of Michigan demonstrated that implementation of the HIPAA Privacy rule
resulted in a drop from 96% to 34% in the proportion of follow-up surveys completed by study patients
being followed after a heart attack.[33] Another study, detailing the effects of HIPAA on recruitment for a
study on cancer prevention, demonstrated that HIPAA-mandated changes led to a 73% decrease in patient
accrual, a tripling of time spent recruiting patients, and a tripling of mean recruitment costs.[34]
In addition, informed consent forms for research studies now are required to include extensive detail on
how the participant's protected health information will be kept private. While such information is
important, the addition of a lengthy, legalistic section on privacy may make these already complex
documents even less user-friendly for patients who are asked to read and sign them.
These data suggest that the HIPAA privacy rule, as currently implemented, may be having negative
impacts on the cost and quality of medical research. Dr. Kim Eagle, professor of internal medicine at the
University of Michigan, was quoted in the Annals article as saying, "Privacy is important, but research is
also important for improving care. We hope that we will figure this out and do it right." [32]
Clinger–Cohen Act (1996)
From Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Clinger%E2%80%93Cohen_Act
The Clinger-Cohen Act (CCA), formerly the Information Technology Management Reform Act of 1996
(ITMRA), is a 1996 United States federal law, designed to improve the way the federal government acquires, uses
and disposes information technology (IT).
The Clinger-Cohen Act supplements the information resources management policies by establishing a
comprehensive approach for executive agencies to improve the acquisition and management of their information
resources, by:[1]



focusing information resource planning to support their strategic missions;
implementing a capital planning and investment control process that links to budget formulation and
execution; and
rethinking and restructuring the way they do their work before investing in information systems.
The Clinger-Cohen Act of 1996 directed the development and maintenance of Information Technology
Architectures (ITAs) by federal agencies to maximize the benefits of information technology (IT) within the
Government. In subsequent guidance on implementing the Clinger-Cohen Act, the Office of Management and
Budget stipulated that agency ITA's "...should be consistent with Federal, agency, and bureau information
architectures.."[2] In keeping with OMB's mandate for consistency between both federal and agency ITA's, in 1999
the Federal CIO Council initiated the Federal Enterprise Architecture, essentially a federal-wide ITA that
would "... develop, maintain, and facilitate the implementation of the top-level enterprise architecture for the Federal
Enterprise." [3]
80
Overview
In February 1996, Congress enacted the Clinger-Cohen Act to reform and improve the way Federal agencies acquire
and manage IT resources.[4] Central to implementing these reforms is the need to establish effective IT leadership
within each agency. The law requires each agency head to establish clear accountability for IT management
activities by appointing an agency Chief Information Officer (CIO) with the visibility and management
responsibilities necessary to carry out the specific provisions of the Act. The CIO plays a critical leadership role
in driving reforms to:[4]



help control system development risks;
better manage technology spending; and
succeed in achieving real, measurable improvements in agency performance.
The Clinger-Cohen Act provides that the government information technology shop be operated exactly as an
efficient and profitable business would be operated. Acquisition, planning and management of technology must
be treated as a "capital investment." While the law is complex, all consumers of hardware and software in the
Department should be aware of the Chief Information Officer's leadership in implementing this statute.[5]
The Clinger-Cohen Act emphasizes an integrated framework of technology aimed at efficiently performing the
business of the Department. Just as few businesses can turn a profit by allowing their employees to purchase
anything they want to do any project they want, the Department also cannot operate efficiently with hardware and
software systems purchased on an "impulse purchase" basis and installed without an overall plan. All facets of
capital planning are taken into consideration just as they would be in private industry. [5]
The Clinger-Cohen Act assigns the Director of the Office of Management and Budget (OMB) responsibility
for improving the acquisition, use, and disposal of information technology by the Federal Government. The
Director should aim to improve the productivity, efficiency, and effectiveness of Federal programs, including
through dissemination of public information and the reduction of information collection burdens on the public. The
Act supplements the information resources management (IRM) policies contained in the Paperwork Reduction Act
(PRA) by establishing a comprehensive approach to improving the acquisition and management of agency
information systems through work process redesign, and by linking planning and investment strategies to the budget
process.[6]
History
To provide agencies with guidance on implementing the Clinger-Cohen Act, the Office of Management and Budget
(OMB) in April 2000 distributed a so called "OMB Circular A-130"[1] about the management of Federal Information
Resources. This circular incorporated some other memoranda:[6]



M–96–20, "Implementation of the Information Technology Management Reform Act of 1996"
M–97–02, "Funding Information Systems Investments"
M–97–16, "Information Technology Architecture",
as well as new material.
Clinger-Cohen Act topics
National Defense Authorization Act for Fiscal Year 1996
This "Information Technology Management Reform Act" was part of the National Defense Authorization Act for
Fiscal Year 1996, which is organized in five divisions:[8]
(1) Division A — Department of Defense Authorizations.
81
(2) Division B — Military Construction Authorizations.
(3) Division C — Department of Energy National Security Authorizations and Other Authorizations.
(4) Division D — Federal Acquisition Reform.
(5) Division E — Information Technology Management
This public law was intent to authorize appropriations for fiscal year 1996 for military activities of the Department
of Defense, for military construction, and for defense activities of the Department of Energy, to prescribe personnel
strengths for such fiscal year for the Armed Forces, to reform acquisition laws and information technology
management of the Federal Government, and for other purposes.
Definitions
In the Clinger-Cohen Act itself some terms have been explicitly defined:[8]
Information technology
The term Information Technology, with respect to an executive agency means any equipment or
interconnected system or subsystem of equipment, that is used in the automatic acquisition,
storage, manipulation, management, movement, control, display, switching, interchange,
transmission, or reception of data or information by the executive agency. For purposes of the
preceding sentence, equipment is used by an executive agency if the equipment is used by the
executive agency directly or is used by a contractor under a contract with the executive agency
which (i) requires the use of such equipment, or (ii) requires the use, to a significant extent, of
such equipment in the performance of a service or the furnishing of a product.
Information technology includes computers, ancillary equipment, software, firmware and similar
procedures, services (including support services), and related resources. It does include any
equipment that is acquired by a Federal contractor incidental to a Federal contract.
Information resources
The term Information Resources means information and related resources, such as personnel,
equipment, funds, and information technology.
Information resources management
The term Information Resources Management means the process of managing information
resources to accomplish agency missions and to improve agency performance, including through
the reduction of information collection burdens on the public.
Information system
The term information system means a discrete set of information resources organized for the
collection, processing, maintenance, use, sharing, dissemination, or disposition of information.
Information technology architecture
The term Information Technology Architecture, with respect to an executive agency, means an
integrated framework for evolving or maintaining existing information technology and acquiring
new information technology to achieve the agency’s strategic goals and information resources
management goals.
Director of the Office of Management and Budget
Clinger-Cohen Act assigns the Director of the Office of Management and Budget (OMB) some ten tasks.
The following list represents a selection:[8]
Use of Information Technology in Federal programs
The OMB Director is held responsibility for improving the acquisition, use, and disposal of
information technology by the Federal Government. The Directory should aim to improve the
82
productivity, efficiency, and effectiveness of Federal programs, including through dissemination
of public information and the reduction of information collection burdens on the public.
Use of budget process
The OMB Director shall develop, as part of the budget process, a process for analyzing, tracking,
and evaluating the risks and results of all major capital investments made by an executive agency
for information systems. The process shall cover the life of each system and shall include explicit
criteria for analyzing the projected and actual costs, benefits, and risks associated with the
investments.
Information Technology Standards
The OMB Director shall oversee the development and implementation of standards and
guidelines pertaining to Federal computer systems by the Secretary of Commerce through the
National Institute of Standards and Technology.
Use of Best Practices in Acquisition
The OMB Director shall encourage the heads of the executive agencies to develop and use the
best practices in the acquisition of information technology.
Assessment of other models for managing Information Technology
The OMB Director shall assess, on a continuing basis, the experiences of executive agencies,
State and local governments, international organizations, and the private sector in managing
information technology.
Other tasks are about the comparisment of agency uses of IT, training, Informing Congress, and
procurement policies.
Performance-based and results-based management
Director of the Office of Management and Budget (OMB) shall encourage the use of performance-based
and results-based management in fulfilling the responsibilities assigned. OMB's Director is tasked with
the following responsibilities:[8]



to evaluate the information resources management practices of the executive agencies with
respect to the performance and results of the investments made by the executive agencies in
information technology.
to issue the head of each executive agency to:
o establish effective and efficient capital planning processes for selecting, managing, and
evaluating the results of all of its major investments in information systems;
o determine, before making an investment in a new information system:
 whether the function to be supported by the system should be performed by the
private sector and, if so, whether any component of the executive agency
performing that function should be converted from a governmental organization
to a private sector organization;
 whether the function should be performed by the executive agency and, if so,
whether the function should be performed by a private sector source under
contract or by executive agency personnel;
o analyze the missions of the executive agency and, based on the analysis, revise the
executive agency’s mission-related processes and administrative processes, as
appropriate, before making significant investments in information technology to be used
in support of those missions;
o ensure that the information security policies, procedures, and practices are adequate.
guidance for undertaking efficiently and effectively interagency and Government-wide
investments in information technology
83


periodic reviews of selected information resources management activities of the executive
agencies
to enforce accountability of the head of an executive agency for information resources
management
Executive Agencies
The head of each US Federal executive agency shall comply with several specific matters. A selection. [8]
Design of Process
Each executive agency shall design and implement in the executive agency a process for
maximizing the value and assessing and managing the risks of the information technology
acquisitions of the executive agency.
Content of Process
The process of an executive agency shall
1. provide for the selection of information technology investments to be made by the
executive agency, the management of such investments, and the evaluation of the results
of such investments;
2. be integrated with the processes for making budget, financial, and program management
decisions within the executive agency;
3. include minimum criteria to be applied in considering whether to undertake a particular
investment in information systems, including criteria related to the quantitatively
expressed projected net, risk-adjusted return on investment and specific quantitative and
qualitative criteria for comparing and prioritizing alternative information systems
investment projects;
4. provide for identifying information systems investments that would result in shared
benefits or costs for other Federal agencies or State or local governments;
5. provide for identifying for a proposed investment quantifiable measurements for
determining the net benefits and risks of the investment; and
6. provide the means for senior management personnel of the executive agency to obtain
timely information regarding the progress of an investment in an information system,
including a system of milestones for measuring progress, on an independently verifiable
basis, in terms of cost, capability of the system to meet specified requirements,
timeliness, and quality.
Performance and Result-based Management
The head of an executive agency shall (1) establish goals for improving the efficiency and
effectiveness of agency operations. (2) prepare an annual report, (3) ensure that performance
measurements (4) comparable with processes and organizations in the public or private sectors
(5) analyze the missions, and (6) ensure that the information security policies, procedures, and
practices of the executive agency are adequate.
Acquisition of Information Technology
The authority of the head of an executive agency to conduct an acquisition of information
technology includes several general and specific authorities.
84
Applications
The CCA generated a number of significant changes in the roles and responsibilities of various Federal
agencies in managing acquisition of IT. It elevated overall responsibility to the Director of the Office of
Management and Budget (White House). OMB set forth guidelines that must be followed by agencies.
At the agency level, IT management must be integrated into procurement, and procurement of
Commercial-off-the-shelf technology was encouraged. CCA required each agency to name a Chief
Information Officer (CIO) with the responsibility of "developing, maintaining, and facilitating the
implementation of a sound and integrated information technology architecture". The CIO is tasked with
advising the agency director and senior staff on all IT issues.
Since these rules went into effect, the agency CIOs also have worked together to form the Federal CIO
Council. Initially an informal group, the council's existence became codified into law by Congress in the
E-Government Act of 2002. Official duties for the council include developing recommendations for
government information technology management policies, procedures, and standards; identifying
opportunities to share information resources; and assessing and addressing the needs of the Federal
Government's IT workforce. [9]
In general, National Security Systems (NSS), as defined in 40 USC 11103, are exempt from the Act.
However, there are specific exceptions to this exemption regarding:
1.
2.
3.
4.
Capital Planning and Investment Control (CPIC);
Performance- And Results-Based Management;
Agency Chief Information Officer (CIO) responsibilities; and
Accountability.
In the Department of Defense, the Assistant Secretary of Defense for Networks & Information Integration
(or ASD(NII)) has been designated as the DoD Chief Information Officer and provides management and
oversight of all DoD information technology, including national security systems.
85
2. OMB Memoranda
Can be found at http://www.whitehouse.gov/omb/memoranda_default/
a) M-09-32 – Update on the Trusted Internet Connections Initiative
b) M-09-29 - FY 2009 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
c) M-09-02 - Information Technology Management Structure and Governance Framework
d) M-08-27 - Guidance for Trusted Internet Connection (TIC) Compliance
e) M-8-23 - Securing the Federal Government’s Domain Name System Infrastructure
f) M-08-22 - Guidance on the Federal Desktop Core Configuration (FDCC)
g) M-08-21 – FY 2008 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
h) M-08-16 – Guidance for Trusted Internet Connection Statement of Capability Form (SOC)
i) M-08-09 – New FISMA Privacy Reporting Requirements for FY 2008
j) M-08-05 - Implementation of Trusted Internet Connections (TIC)
k) M-08-01 - HSPD-12 Implementation Status
l) M-07-19 – FY 2007 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
m) M-07-18 - Ensuring New Acquisitions Include Common Security Configurations
n) M-07-16 - Safeguarding Against and Responding to the Breach of Personally Identifiable Information
o) M-07-11 - Implementation of Commonly Accepted Security Configurations for Windows Operating
Systems
p) M-07-06 - Validating and Monitoring Agency Issuance of Personal Identity Verification Credentials
q) Recommendations for Identity Theft Related Data Breach Notification
r) M-06-20 - FY 2006 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
s) M-06-19 - Reporting Incidents Involving Personally Identifiable Information and Incorporating the
Cost for Security in Agency Information Technology Investments
t) M-06-18 - Acquisition of Products and Services for Implementation of HSPD-12
u) M-06-16 - Protection of Sensitive Agency Information
v) M-06-15 - Safeguarding Personally Identifiable Information
w) M-06-06 - Sample Privacy Documents for Agency Implementation of Homeland Security Presidential
Directive (HSPD) 12
x) M-05-24 - Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a
Common Identification Standard for Federal Employees and Contractors
y) M05-16 - Regulation on Maintaining Telecommunication Services During a Crisis or Emergency in
Federally-owned Buildings
z) M05-15 - FY 2005 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
a) M-05-08 - Designation of Senior Agency Officials for Privacy
b) M-05-05 - Electronic Signatures: How to Mitigate the Risk of Commercial Managed Services
c) M-05-04 - Policies for Federal Agency Public Websites
d) M-04-26 - Personal Use Policies and "File Sharing" Technology
e) M-04-25 – FY 2004 Reporting Instructions for the Federal Information Security Management Act and
Updated Guidance on Quarterly IT Security Reporting
86
f) M-04-16 - Software Acquisition
g) M-04-15 - Development of Homeland Security Presidential Directive (HSPD) - 7 Critical Infrastructure
Protection Plans to Protect Federal Critical Infrastructures and Key Resources
h) M-04-04 - E-Authentication Guidance for Federal Agencies
i) M-03-22 - OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002
j) M-03-19 - FY 2003 Reporting Instructions for the Federal Information Security Management Act and
Updated Guidance on Quarterly IT Security Reporting
k) M-03-18 - Implementation Guidance for the E-Government Act of 2002
l) M-02-09 - Reporting Instructions for the Government Information Security Reform Act and Updated
Guidance on Security Plans of Action and Milestones
a) M-02-01 - Guidance for Preparing and Submitting Security Plans of Action and Milestones
b) M-01-05 - Guidance on Inter-Agency Sharing of Personal Data - Protecting Personal Privacy
c) M-00-13 - Privacy Policies and Data Collection on Federal Web Sites
a) M-00-10 - OMB Procedures and Guidance on Implementing the Government Paperwork Elimination
Act
b) M-00-07 - Incorporating and Funding Security in Information Systems Investments
c) M-00-01 - Day One Planning and Request for Updated Business Continuity and Contingency Plans
d) M-99-20 - Security of Federal Automated Information Resources
e) M-99-18 - Privacy Policies on Federal Web Sites
f) M-99-16 - Business Continuity and Contingency Planning for the Year 2000
M-09-32 Update on the Trusted Internet Connections Initiative
The purpose of this memorandum is to provide an overview of the Trusted Internet Connection (TIC)
initiative and to request updates to agencies’ Plans of Action and Milestones (POA&Ms) for meeting
TIC requirements.
BACKGROUND In November 2007, OMB announced the Trusted Internet Connections (TIC)
Initiative to optimize individual agency network services into a common solution for the Federal
government. Agencies were required to develop and submit comprehensive Plans of Action and
Milestones (POA&Ms) to reduce and consolidate the number of external access points, including
Internet connections; and ensure that all external connections are routed through an OMB-approved
TIC. Based on solicited agency Statements of Capability, OMB also designated twenty agencies as
TIC Access Providers (TICAPS). Each TICAP agency was authorized two locations where they must
reduce and consolidate all external connections. Agencies must present an evidence-based rationale
for acquisition of more than two locations. Please send an email to tic@dhs.gov for the template and
instructions.
SPECIFIC ACTIONS REQUESTED Agencies shall update and report formal Plans of Action and
Milestones (POA&Ms) to the Department of Homeland Security by September 25, 2009, and provide
updated status to DHS every six months thereafter, until completed.
All agencies seeking Trusted Internet Connection Access Provider (TICAP) services shall utilize the
template in enclosure (1) and submit it to tic@dhs.gov. For reference by TICAP agencies only, a
87
blank TICAP agency POA&M is provided in enclosure (2). DHS has separately contacted the 20
TICAP agencies with instructions on how to update their POA&Ms.
In addition to the POA&M, TICAP agencies must schedule by September 25, 2009 their initial TIC
compliance on-site assessments with DHS. All other agencies must also collaborate with DHS to
complete their initial TIC compliance self-assessments by December 31, 2009.
Federal policy requires all agencies to undertake immediate responsibility for executing essential
agreements and updating POA&Ms to facilitate not only TIC preparations, but also due diligence for
integrating the National Cyber Protection System (NCPS, operationally referred to as Einstein)
deployments and synchronizing with US-CERT.
Agencies will work with DHS on studies of Federal network infrastructure, and report data from the
agency’s inventory of network connections to DHS as requested. Each agency is responsible for
maintaining a current inventory of its network connections, including details on the service provider,
cost, capacity and traffic volume for each connection.
M-09-29 FY 2009 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
http://www.whitehouse.gov/sites/default/files/omb/assets/memoranda_fy2009/m09-29.pdf
This memorandum provides instructions for meeting your agency’s FY 2009 reporting requirements
under the Federal Information Security Management Act of 2002 (FISMA) (Title III, Pub. L. No.
107-347). It also includes reporting instructions on your agency’s privacy management program.
The reporting categories and questions are generally the same as last year, and the report will cover
the same areas as in previous years. However, while the content of the report has changed little since
2008, the means of collection have changed substantially. This year, rather than using spreadsheets,
the annual FISMA report data collection will occur via an automated reporting tool. This tool will
allow both manual data entry and automatic upload of data. Therefore, the attachments to this memo
only contain lists of questions and not reporting templates.
The Chief Information Officers (CIO), Inspectors General (IG), and the Senior Agency Officials for
Privacy (SAOP) will all report through the automated collection tool. A test version will be available
in August and further instructions will be issued. Please note that OMB will only accept reports
submitted through the automated tool. Reporting to the Congress will continue as in prior years. Due
to the new collection system, the due date for FISMA reports will be November 18, 2009.
Agencies should also submit the following information related to OMB Memorandum M-07-16, of
May 22, 2007, ―Safeguarding Against and Responding to the Breach of Personally Identifiable
Information.‖1
• Breach notification policy if it has changed significantly since last year’s report;
• Progress update on eliminating unnecessary use of Social Security Numbers (SSN); and
• Progress update on review and reduction of holdings of personally identifiable information (PII).
88
Agency reports must reflect the agency head’s determination of the adequacy and effectiveness of
information security and privacy policies, procedures, and practices. The new automated reporting
tool will allow agencies to submit an electronic copy of the signed official transmittal letter.
M-09-02 Information Technology Management Structure and Governance Framework
this framework includes the requirement for Heads of Departments and Agencies to consult with the
Director of the Office of Management Budget (OMB) prior to appointing an Agency-Appointed CIO,
and to advise the Director on matters regarding the authority, responsibilities and organizational
resources of the CIO, per OMB Circular A-130 (published November 28, 2000), Section 9,
Assignment of Responsibilities. Consultation with OMB on CIO appointments should be factored
into your agency’s selection process, and OMB will ensure its input into such selections is
expeditious.
I. Organizational Structure and Reporting Relationships of IT Executives and Senior
Managers
A. The Department or Agency has a designated executive-level Chief Information Officer (CIO)
reporting to the head of the organization, with formal and full responsibility for all
requirements set forth in promulgating statutes, regulations and guidance of Public Law 104106, ―Clinger-Cohen Act of 1996,‖ Public Law 107-347, ―E-Government Act of 2002,‖ Title
44 U.S. Code Section 3506 ―Federal Agency Responsibilities,‖ Federal Acquisition
Regulation Part 39, ―Acquisition of Information Technology,‖ and Office of Management
and Budget (OMB) Circular A-130, ―Transmittal Memorandum #4, Management of Federal
Information Resources.‖
B. The Agency CIO has ultimate responsibility for the governance, management and delivery of
IT mission and business programs within the Department, and has an effective operative
means of meeting this responsibility.
C. The CIO may review the qualifications of and provides input into the selection process for IT
and IT-related executive and senior management positions within the Agency and
organizational components thereof.
D. IT executives and senior managers in all organizational components of the Agency have clear
responsibilities and accountability for adhering to Agency IT policy and direction established
by the CIO.
E. The CIO may establish and provide evaluations and appraisals in collaboration with the
appropriate supervisors of record for at least one critical performance element within the
performance plans of IT and IT-related executives and senior managers within the Agency
and organizational components thereof.
II. Authorities to Set IT Policy and Implementing Procedures
Except where otherwise authorized by law, regulation, or other policy, the CIO has the authority to
set Agency-wide IT policy, including all areas of IT governance such as enterprise architecture and
standards, IT capital planning and investment management, IT asset management, IT budgeting and
89
acquisition, IT performance management, risk management, IT workforce management, IT security
and operations, and information security.
III. Authorities to Select, Plan, Control and Evaluate Investments in and Acquisition of
Information Systems and Information Technology
Except where otherwise authorized by law, regulation, or other policy, the Agency head is
responsible for the following activities. The Agency CIO shall be the lead agency official in taking
the necessary actions to ensure such activities are completed. Thus, the Agency head:
A. Is responsible for ensuring all Agency business and mission policies, processes, and IT and
IT-related programs comply with the Federal Enterprise Architecture;
B. Ensures the organization’s enterprise architecture data is visible and accessible to other federal
agencies and mission partners to the extent necessary for other organizations to leverage
those resources, and works collaboratively with other agencies and organizations on
enterprise architecture issues and opportunities;
C. Ensures IT and IT-related systems, assets and services acquired and existing within the
organization do not unnecessarily duplicate those available from other federal agencies, and
are planned for and managed throughout their lifecycle;
D. Shall include the Agency CIO in budget formulation, preparation, prioritization and
presentation activities, including determining and evaluating IT resource requirements in
support of mission execution and program administration and support;
E. Shall include the Agency CIO in Agency and component budget execution and resource
allocation and planning activities for IT and systems development, operations, and services as
appropriate to ensure resources are expended in accordance with established IT policy;
F. Shall include the Agency CIO in the selection, planning, review, and oversight of major IT and
IT-related investments and acquisitions, development projects, and contracts or agreements
for goods or services, and in evaluating and providing approval to proceed at the earliest state
possible prior to initiating procurements or advancing to subsequent phases of system
development and/or acquisition;
G. Reviews the status and progress of projects and activities in the Agency IT investment
portfolio to determinate whether to continue, suspend, re-baseline or cancel projects or
components thereof, including any associated current or planned acquisitions; and
A. H. Has established means for ensuring investment management, risk management,
information security, and systems development lifecycle management policy compliance,
including periodic review of artifacts and development products for IT investments and
activities developed within or for component organizations
90
M-08-27 – Guidance for Trusted Internet Connection (TIC) Compliance
In November 2007, OMB announced the implementation of Trusted Internet Connections (TIC) in
Memorandum M-08-05, ―Implementation of Trusted Internet Connections (TIC).‖ The TIC initiative
progress continues to be demonstrated by the agencies’ reduction in external connections, including
internet points of presence.
In the effort to improve the federal government’s incident response capability, I am providing you
with additional guidance and clarification as you coordinate with the Department of Homeland
Security’s (DHS’s) National Cyber Security Division (NCSD).
As you know, the Office of Management and Budget (OMB) and DHS have hosted several technical
meetings regarding the TIC technical architecture. The products from these meetings should be used
by your agency to address questions regarding your consolidation and optimization of your network
and its associated access points.
Moving forward, for those agencies that have been identified as a TIC Access Provider, compliance
with the TIC initiative includes the agency taking the following actions:
1. Complying with critical TIC technical capabilities per the agencies’ Statement of Capability;
2. Continuing reduction and consolidation of external connections to identified TIC access points;
3. Collaborating with NCSD in determining agency technical readiness to coordinate/schedule
installation of Einstein;
4. Executing a Memorandum of Agreement (MOA) between DHS and your agency Chief
Information Officer (CIO); and
5. Executing a Service Level Agreement (SLA) between DHS and your agency CIO.
We are requesting an update for all agencies’ current Plan of Action and Milestones (POA&Ms) to
include the pending modification to the NETWORX contract for TIC services which is scheduled for
award on/or about November 15, 2008. The TIC Access Providers’ updated POA&Ms should
include the above outlined steps. DHS will work with your agency to complete setup/installation
activities for Einstein and other DHS specific TIC tasks based on prioritized needs for each agency.
We will not consider your agency fully compliant until DHS has provided notification to OMB of
completion of the necessary activities for TIC. OMB is requesting your updated POA&Ms be
submitted by October 15, 2008 to tic@dhs.gov.
Policy References:
M-08-05, ―Implementation of Trusted Internet Connections (TIC)‖
http://www.whitehouse.gov/omb/memoranda/fy2008/m08-05.pdf
Planning Guidance for Trusted Internet Connections (TIC)
http://www.whitehouse.gov/omb/egov/documents/TIC_ImplementationPlanningGuidance.pdf
Final Trusted Internet Connections (TIC) Initiative Statement of Capability Evaluation Report, dated
June 4, 2008
http://www.whitehouse.gov/omb/egov/documents/2008_TIC_SOC_EvaluationReport.pdf
M-08-23- Securing the Federal Government’s Domain Name System Infrastructure
91
Almost every instance of network communication begins with a request to the Domain Name System
(DNS) to resolve a human readable name for a network resource (e.g., www.usa.gov) into the
technical information (e.g., Internet Protocol address) necessary to actually access the remote
resource. This memorandum describes existing and new policies for deploying Domain Name
System Security (DNSSEC) to all Federal information systems by December 2009. DNSSEC
provides cryptographic protections to DNS communication exchanges, thereby removing threats of
DNS-based attacks and improving the overall integrity and authenticity of information processed
over the Internet.
Existing Policy
In December 2006, the National Institute of Standards and Technology’s (NIST) Special Publication
800-53r1 ―Recommended Security Controls for Federal Information Systems‖ prescribed initial
DNSSEC deployment steps necessary for FISMA high and moderate impact information systems.
New Policy
This memorandum addresses two important issues in following through with the existing policy and
expanding its scope to address all USG information systems.
The Federal Government will deploy DNSSEC to the top level .gov domain by January 2009.
The top level .gov domain includes the registrar, registry, and DNS server operations. This policy
requires that the top level .gov domain will be DNSSEC signed and processes to enable secure
delegated sub-domains will be developed. Signing the top level .gov domain is a critical procedure
necessary for broad deployment of DNSSEC, increases the utility of DNSSEC, and simplifies lower
level deployment by agencies.
Your agency must now develop a plan of action and milestones for the deployment of
DNSSEC to all applicable information systems. Appropriate DNSSEC capabilities must be deployed
and operational by December 2009. The plan should follow recommendations in NIST Special
Publication 800-81 ―Secure Domain Name System (DNS) Deployment Guide,‖ and address the
particular requirements described in NIST Special Publication 800-53r1 ―Recommended Security
Controls for Federal Information Systems.‖1
The plan should report your agency’s current level of compliance with the current DNSSEC
requirements of NIST Special Publication 800-53r1, and document a plan of action and milestones
that assume the scope of the requirement to operate DNSSEC signed zones (SC-20) will be expanded
to cover all FISMA information systems (including low impact systems2) in revision 3 of NIST
Special Publication 800-53. The plan should ensure that all Agency .gov domains are DNSSEC
signed by December 2009.
Your agency's draft plan of action and milestones should follow the general outline provided below
and be sent to OMB at fisma@omb.eop.gov by September 5, 2008. The draft plans will be reviewed
and feedback will be provided. Mutually-agreed upon final plans will be in place by October 24,
2008. Going forward, agency progress to deploy DNSSEC will be tracked and evaluated through
annual Federal Information Security Management Act (FISMA) reporting.
Additional Resources
The following resources provide additional technical information and guidance to support your
agency’s DNSSEC deployment.
The USG DNSSEC deployment email list: usg-forum@dnssec-deployment.org
The DNSSEC Deployment Initiative: http://www.dnssec-deployment.org/
92
The NIST DNSSEC project: http://www-x.antd.nist.gov/dnssec/
The Secure Naming Infrastructure Pilot (SNIP): http://www.dnsops.gov/
The FISMA Implementation Project: http://csrc.nist.gov/groups/SMA/fisma/index.html
DNSSEC Deployment Plan Outline
Section 1 - Enumerate .gov Domains. Enumerate the second level domains beneath .gov operated by
your agency (or on behalf of your agency). Only the second level sub-domains need to be listed.
Section 2 - Identify Sources of DNS Services. For each domain listed above, describe if your DNS
administration and server operation are provided in house, outsourced to a commercial provider (e.g.,
vendor), or delivered by other means (e.g., provided by another agency).
Section 3 - Describe DNS Server Infrastructure. Document the provider, vendor, or source of DNS
server implementations within your agency (e.g., BIND, NSD, Microsoft Advanced Directory, etc.).
Include in your estimate the number of such servers per source.
Section 4 - Identify and Address Barriers. Document any perceived technical, contractual or
operational barriers impeding deployment of DNSSEC, and milestones for addressing each.
Section 5 – Train and Pilot. Review the activities of the USG Secure Naming Infrastructure Pilot at
www.dnsops.gov and plan for your agency will participate in this pilot test bed, as well as associated
training workshops.
Section 6 – Plan of Action and Milestones. Document your Agency’s plan of action and milestones
to fully implement the policies described in this memo. In particular this plan should detail all key
activities (e.g., acquisition if necessary, training, test, deployment, operations plans with priority
given to citizen services and E-government domains especially those that collect any personally
identifiable information) and milestones necessary to achieve the goal of fully operating DNSSEC
signed .gov sub-domains by December 2009
M-08-22 Guidance on the Federal Desktop Core Configuration (FDCC)
Federal Desktop Core Configuration Major Version 1.0
FDCC Major Version 1.0 is based on Microsoft Windows XP Service Pack (SP) 2 and Microsoft
Windows Vista SP 1. Although Security Content Automation Protocol (SCAP) Content has been
engineered so that it will also operate on Windows XP SP3, near-term Windows XP patch checking
will be oriented toward Windows XP SP2. It is understood that many managed environments
throughout the Federal government implement service packs shortly after their release. While nearterm Windows XP checking is based on Windows XP/SP2, we do not anticipate any significant
measurement issues for Windows XP/SP3. NIST is currently working with IT product vendors to
develop additional SCAP Content based on the FDCC settings for other platforms and applications.
To coincide with the release of FDCC Major Version 1.0, new SCAP Content has also been made
available. This SCAP Content is inclusive of the 40 FDCC settings changes. At this time, the FDCC
is comprised of settings located at http://fdcc.nist.gov that can be checked using the updated SCAP
Content and SCAP-validated tools with FDCC Scanning capability as specified on the NIST website
at http://nvd.nist.gov/scapproducts.cfm. Not all FDCC settings can be checked using automated
scanning tools. NIST is coordinating the refinement of SCAP Content to automate the checking of as
many settings as possible and will release minor versions of SCAP Content as this work progresses.
93
New Microsoft-updated Group Policy Objects (GPO) and Virtual Hard Drive (VHD) files are also
available. These files have been tested by NIST and made available at
http://nvd.nist.gov/fdcc/download_fdcc.cfm.
The SCAP Validation Requirement
Both industry and government information technology providers must use SCAP validated tools with
FDCC Scanner capability to certify their products operate correctly with FDCC configurations and
do not alter FDCC settings. Agencies will use SCAP tools to scan for both FDCC configurations and
configuration deviations approved by department or agency accrediting authority. Agencies must
also use these tools when monitoring use of these configurations as part of FISMA continuous
monitoring1.
The requirement for SCAP validated security software with a validation for FDCC scanning
capability is a required component of the FDCC for several reasons including:

SCAP validated tools enable centralized authorship, quality assurance and publication of a
definitive security configuration in the form of a SCAP Checklist. SCAP Checklists enable
repeatability of low level, technical test procedures for assessment and monitoring of FDCC settings,
as long as a SCAP validated product processes them. Conversion of these test procedures into a wide
variety of non-validated checklists and checklist processing technologies leaves significant room for
translation error.

SCAP validated tools also give IT providers the ability to present evidence that their
product(s) do not alter FDCC settings in a common reporting format, SCAP XCCDF reports. Using
this common standardized reporting format in conjunction with integrity checks of the SCAP
Checklist and the IT product binaries used in the testing process will allow agencies to accept selfassertions with limited Federal testing. This could expedite procurement time.
For additional information on SCAP and a list of validated products go to
http://nvd.nist.gov/scapproducts.cfm.
Compliance, Testing and Use of SCAP validated Tools for Application Providers Supporting
the Federal Government
Federal CIOs shall ensure that government application providers self-assert currently supported
versions of applications:
 Operate correctly on Federal Windows XP and Windows Vista computer systems configured
with FDCC and
 Do not change FDCC settings.
 Consistent with NIST guidance, applications should be installed and configured according to
the ordinary means utilized by the end client within the Federal computing environment. A
typical IT provider testing scenario should include:
 Configure a system with the latest FDCC settings from the NIST website.
 Use a SCAP-validated tool with FDCC Scanner capability to baseline the initial
configuration.
 Install the product and test common use cases (per normal processes).
 Use a SCAP-validated tool with FDCC Scanner capability to ensure the FDCC settings and
patches are intact.
 Uninstall the application, reboot, and run a SCAP-validated tool with FDCC Scanner
capability to ensure proper FDCC settings and patches are still present.
94
NIST recommends IT providers test applicable product versions with all relevant and current updates
and patches installed, especially when the update is considered a ―major version‖ change. It is
assumed this would be accomplished by integrating FDCC-specific tests into pre-existing patch
testing process. Self-assertions should be made for currently supported versions of a product. It is not
necessary for vendors to issue additional self-assertion statements with every minor update or patch.
IT providers’ self-assertion for the currently supported versions of an IT product is valid:

As long as the asserted version of the application is supported or in use by a Federal agency;

Regardless of patches or updates issued for Microsoft Windows XP, Windows Vista,
Windows XP desktop firewall, Windows Vista desktop firewall or Internet Explorer 7.0;

Regardless of how an agency deploys the self-asserted version of the application (on other
systems, across networks, with other applications, etc.) agency integrators must ensure FDCC
compliance throughout the integration process and

Even if the tool used to test the IT product eventually loses its validation because the tool
vendor elected not to re-validate that version of the software.
Changes to FDCC settings will affect self-assertions of IT products. IT providers will self-assert
currently supported versions of IT products against the latest FDCC major version and future major
versions. Future FDCC changes having minimal security impact may be released as minor versions
to FDCC. Self-assertion is not required for minor releases.
Scope of "Desktop" Configuration
Microsoft Windows XP and Windows Vista are desktop operating systems. Accordingly, FDCC is
applicable to all computing system using Windows XP and Windows Vista, including desktops and
laptops but not including servers. It is important for the collective security of the Federal
Government for all the Windows XP and Windows Vista computers to meet or exceed FDCC,
regardless of function.
Regarding Microsoft Windows XP and Vista, IT Providers are not required to self-assert a) operating
systems other than Microsoft Windows XP and Windows Vista or b) applications that run on
operating systems other than Microsoft Windows XP and Windows Vista. This includes server
operating systems and applications.
Additionally, and in support of the deviation analysis process conducted in March 2008, OMB has
provided five environments/system roles which agencies should map any given desktop using
Windows XP and/or Vista. These five environments/system roles are: 1) Centrally Managed General
Purpose Desktop, 2) Centrally Managed General Purpose Laptop, 3) Development System, 4)
Special Use System, and 5) Other. More information on these categories can be found at
http://nvd.nist.gov/fdcc/fdcc_reporting_faq_20080328.cfm. This report marks the first in a line of
ongoing assessments to be conducted to determine compliance to FDCC through the use of SCAP
validated tools.
It is important to note NIST is currently working with a number of IT vendors on standardizing
security settings for a wide variety of IT products and environments. NIST Special Publication 80068, ―Guidance for Securing Microsoft Windows XP Systems for IT Professional: A NIST Security
Configuration Checklist‖ also includes technology neutral configuration settings for a variety of
email, web browser and firewall vendors.
NIST addresses various operating systems and applications through the NIST Security Configuration
Checklists Program for IT Products. The NIST process for creating, vetting and making security
95
checklists available for public use is documented in NIST SP 800-70, ―Security Configuration
Checklists Program for IT Products: Guidance for Checklists Users and Developers.‖
NIST will also continue to host workshops to foster a collaborative environment between Federal
agencies and IT providers. The FDCC technical mailing list, fdcc@nist.gov, and SCAP mailing lists
such as scapdev@ nist.gov and scap-content@nist are also forums to discuss FDCC issues.
Revised Part 39 of the Federal Acquisition Regulation (FAR)
On February 28, 2008, revised Part 39 of the Federal Acquisition Regulation (FAR) was published
which reads:
PART 39-ACQUISITION OF INFORMATION TECHNOLOGY
1. The authority citation for 48 CFR part 39 continues to read as follows: Authority: 40 U.S.C.
121(c); 10U.S.C. chapter 137; and 42 U.S.C. 2473(c).
2. Amend section 39.101 by revising paragraph (d) to read as follows:
39.101 Policy.
*****
(d) In acquiring information technology, agencies shall include the appropriate IT security policies
and requirements, including use of common security configurations available from the NIST's
website at http://checklists.nist.gov. Agency contracting officers should consult with the requiring
official to ensure the appropriate standards are incorporated.
Technology Infrastructure Subcommittee – FDCC Change Control Board
With the release of the FDCC comes the creation of the Technology Infrastructure Subcommittee
(TIS). This subcommittee will convene under the Federal Chief Information Officer (CIO) Council’s
Architecture and Infrastructure Committee (AIC). This subcommittee will convene under the Federal
CIO Council’s Architecture and Infrastructure Committee (AIC). The TIS will be responsible for
coordinating the Federal CIO Council FDCC Change Control Board. The TIS is currently finalizing
its charter which will be available at the end of August.
Although we anticipate relatively few and infrequent changes to FDCC settings, the Change
Control Board will provide a unified process and perspective from the Federal CIO community on
proposed updates, standards and guidance to consider and adjudicate potential changes to the FDCC
in the future. The TIS will work in conjunction with NIST to assist with comprehensive analysis and
public review process. In order to ensure appropriate roles and responsibilities, the TIS is currently
developing a FDCC Concept of Operations that will describe relationships with NIST and other
standards bodies as well as the change control process. This document will be finalized by early fall.
FISMA Guidance
Per OMB Memorandum M-08-21, ―FY 2008 Reporting Instructions for the Federal Information
Security Management Act and Agency Privacy Management,‖ the following configuration
management questions are provided regarding FDCC:
c. Indicate which aspects of Federal Desktop Core Configuration (FDCC) have been implemented as
of this report:
c.1. Agency has adopted and implemented FDCC standard configurations and has documented
deviations. Yes or No.
c.2. New Federal Acquisition Regulation 2007-004 language, which modified "Part 39—Acquisition
of Information Technology,‖ is included in all contracts related to common security settings. Yes or
No.
96
c.3. All Windows XP and VISTA computing systems have implemented the FDCC security settings.
Yes or No.
http://www.whitehouse.gov/omb/memoranda/fy2008/m08-21.pdf
Policy Utilization Effort
OMB in conjunction with the General Services Administration (GSA) has initiated the Policy
Utilization Assessment (PUA) effort. The PUA is intended to provide a service offering to assist
CIOs in conducting independent assessments of IT security policy implementations, with FDCC
being one of the first policy areas.
The program entails the use of statistical sampling (polling of agencies) to determine consistency of
compliance to policy. Sampling activities will seek to collect policy implementation diagnostics and
identify best practices and potential improvements to processes used by agency CIOs to internally
assess policy implementation progress. Through this effort, we will be able to identify gaps in current
agency implementations, determine policy utilization percentages government-wide and increase
agency confidence levels that results are being reached. The pilot assessments were completed in
summer 2008.
Based on the pilot assessments, best practices and assessment methodologies will be shared with
agencies to provide actionable insights and best practices to the CIOs.
M-08-21 FY 2008 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
http://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy2008/m08-21.pdf
Agencies should also submit their most current documentation related to OMB Memorandum M-0716, of May 22, 2007, ―Safeguarding Against and Responding to the Breach of Personally Identifiable
Information,‖1 This information should be provided in an appendix to your annual report and include
the following items for your agency:
Breach notification policy
Implementation plan and progress update on eliminating unnecessary use of Social
Security Numbers (SSN);
Implementation plan and progress update on review and reduction of holdings of
personally identifiable information (PII); and
Policy outlining rules of behavior and identifying consequences and corrective actions
available for failure to follow these rules.
97
FY 2008 Reporting Instructions for the
Federal Information Security Management Act and
Agency Privacy Management
Table of Contents
Page 1
Section A Instructions for Completing the Annual
Federal Information Security
Management Act (FISMA) and Agency
Privacy Management
Report.........................................................
.............................................
This section contains instructions, frequently asked questions, and definitions to aid Chief
Information Officers (CIO), Inspectors General (IG), and Senior Agency Officials for Privacy
(SAOP) in preparing and submitting the annual FISMA and Privacy Management Report.
Page 24
Reporting Template for
CIOs………………………………………
…
This section contains instructions for CIOs to complete the annual FISMA reporting template
(attached).
Page 29
Section C–
Reporting Template for IGs
…………………………………………..
This section contains instructions for IGs to complete the annual FISMA reporting template
(attached).
Page 36
Section D –
Reporting Template for
SAOPs……………………………………
….
This section contains instructions for SAOPs to complete the annual privacy and civil liberties
reporting template (attached). The template in this attachment shall be completed by all agencies.
Section B–
FISMA, OMB policy, and NIST guidance require agency security programs to be risk-based. Who is
responsible for deciding the acceptable level of risk (e.g., the CIO, program officials and system
owners, or the IG)? Are the IGs' independent evaluations also to be risk-based? What if they
disagree?
The agency head ultimately is responsible for deciding the acceptable level of risk for their agency.
System owners, program officials, and CIOs provide input for this decision. Such decisions must
reflect policies from OMB and standards and guidance from NIST (particularly FIPS 199 and FIPS
200). An information system’s Authorizing Official takes responsibility for accepting any residual
risk, thus they are held accountable for managing the security for that system.
IG evaluations are intended to independently assess if the agency is applying a risk-based approach
to their information security programs and the information systems that support the conduct of
agency missions and business functions. When reviewing the Certification and Accreditation (C&A)
of an individual system, for example, the IG would generally assess whether: 1) the C&A was
performed in the manner prescribed in NIST guidance and agency policy; 2) controls are being
implemented as stated in any planning documentation; and 3) continuous monitoring is adequate
given the system impact level of the system and information. Any disagreements among various
program officials, the CIO, and/or the IG would be an internal agency matter; however the view of
98
the agency head will be taken as the authoritative determination, based on the agency head’s decision
after consultation with the IG.
M-08-16 Guidance for Trusted Internet Connection Statement of Capability Form (SOC)
This memorandum provides departments and agencies (D/A) with the opportunity, through their
submission by April 15, 2008, of the attached Trusted Internet Connection Statement of Capability
Form (SOC), to propose their solution and provide their level of capability to become a Trusted
Internet Connection Access Provider (TICAP).
The attached SOC form includes the following five sections:
1. Detailed instructions for how and what sections shall be completed
2. A TIC Enterprise Level Diagram to provide an overview of the "To Be" government-wide
architecture
3. Business Model Capabilities Tab
4. Technical Capabilities Tab
5. Seeking Service Explanation Tab
D/As will select their preferred type of TICAP and fill out the appropriate information as outlined
below:
1) Single Service Provider: Departments and Agencies that propose to provide services to
customers internal to their D/A only, shall complete the following tabs contained within the
Statement of Capability Form
• Technical Capabilities
• Business Model Capabilities
2) Multi Service Provider: Departments and Agencies that propose to provide shared services to
both internal customers as well as customers outside of their own D/A shall complete the following
tabs contained within the Statement of Capability Form
• Technical Capabilities
• Business Model Capabilities
3) Seeking Service: Departments and Agencies that propose to receive services from a TICAP shall
complete the following tabs contained within the Statement of Capability Form
• Technical Capabilities
• Seeking Service Explanation
All D/As must account for each subordinate agency, bureau or component level entity. D/As shall
submit a separate Statement of Capability Form for each type of TICAP desired.
99
Please complete and submit the Statement of Capability Form no later than COB Tuesday April 15,
2008. Please note that the completed document should be treated as Sensitive but Unclassified (SBU)
and should be treated accordingly. The form should be password protected and submitted to
isslob@dhs.gov; additional submission information is provided in the SOC instructions. The ISS
LoB Program Management Office and OMB will review these submissions and follow-up with
agencies as needed.
The April 15, 2008, SOC deadline corresponds with the following Q3FY08 Scorecard Planned
Actions:
• Submission of a revised agency plan of action and milestones (POAM) regarding consolidation of
external connections to isslob@dhs.gov no later than April 15, 2008.
• Submission of D/A justifications of the targeted number of TICs your D/A is requesting to
isslob@dhs.gov for evaluation by OMB no later than May 1, 2008.
M-08-09 New FISMA Privacy Reporting Requirements for FY 2008
This memorandum provides advance notice to agencies about information which will be incorporated
into the annual reporting requirements for fiscal year 2008 under the Federal Information Security
Management Act (FISMA) to be issued next summer.
As part of the FY 2008 FISMA reports, OMB will require agencies to submit the following
information:
By agency, the number of each type of privacy review conducted during the last fiscal year;
Information about the advice – formal written policies, procedures, guidance, or
interpretations of privacy requirements issued by the agency – provided by the Senior Agency
Official for Privacy during the last fiscal year;
The number of written complaints for each type of privacy issue allegation received by the
Senior Agency Official for Privacy during the last fiscal year to include: (1) process and procedural
issues (consent, collection, and appropriate notice); (2) redress issues (non-Privacy Act inquiries
seeking resolution of difficulties or concerns about privacy matters); or (3) operational issues
(inquiries regarding Privacy Act matters not including Privacy Act requests for access and/or
corrections);
For each type of privacy issue received by the Senior Agency Official for Privacy for alleged
privacy violations during the last fiscal year, the number of complaints the agency referred to another
agency with jurisdiction.
M-08-05 - “Implementation of Trusted Internet Connections (TIC)”
I am announcing the Trusted Internet Connections (TIC) initiative to optimize our individual network
services into a common solution for the federal government. This common solution facilitates the
reduction of our external connections, including our Internet points of presence, to a target of fifty.
Additionally, the role of the US-CERT will be enhanced to improve our response capabilities. Each
agency will be required to develop a comprehensive plan of action and milestones (POA&M) with a
target completion date of June 2008. Initial agency POA&Ms must be sent to the Department of
Homeland Security’s (DHS’s) National Cyber Security Division (NCSD) by January 8, 2008, for
review and agreement with OMB, DHS, and the agency.
To discuss this initiative further, we are planning a government-wide meeting on Friday, November
30, 2007. I have asked Karen Evans, Administrator of the Office of Electronic Government and
100
Information Technology and Robert Jamison, Deputy Under Secretary for National Protection &
Programs Directorate, DHS, to ensure adequate collaboration among the various interested parties
such as the Chief Information Officers and Chief Acquisition Officers.
Karen will be sending out the details for the government-wide meeting, including the agenda, to your
Chief Information Officers and I will be inviting the President’s Management Council to attend the
meeting as well.
With the work completed to date in the Lines of Business (LOB) initiatives for Information Systems
Security and IT Infrastructure, the General Services Administration (GSA) award of the NETWORX
contract for telecommunications service, and your current initiative to implement the secure desktop
configurations (i.e. Federal Desktop Core Configuration – FDCC), we are presented with a unique
opportunity to optimize our network delivery capabilities. I ask for you to devote people from your
agency to work on the development and implementation of TIC throughout the federal government.
M-08-01 HSPD-12 Implementation Status
This memorandum serves as a reminder for agencies to complete background investigations and
issue credentials as required for the implementation of Homeland Security Presidential Directive
(HSPD) 12, ―Policy for a Common Identification Standard for Federal Employees and Contractors,‖
which the President issued on August 27, 2004.
In support of the implementation of HSPD-12, the Office of Management and Budget (OMB) has
issued Memorandum-05-24 (M-05-24), ―Implementation of Homeland Security Presidential
Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal Employees and
Contractors,‖ as well as Memorandum-07-06 (M-07-06), ―Validating and Monitoring Agency
Issuance of Personal Identity Verification Credentials.‖ Under HSPD-12 and the OMB memoranda,
agencies are to complete the background investigations on all current employees and contractors and
issue Personal Identity Verification credentials in accordance with the following schedule:
• October 27, 2007 (or by the date specified in the implementation plan mutually agreed-upon by
the agency and OMB): Agencies must complete background checks and issue credentials to
all employees with 15 years or less service and contractors• contractors; and
• October 27, 2008 (or by the date specified in the implementation plan mutually agreed-upon by
the agency and OMB): Agencies must complete background checks and issue credentials to
all employees with more than 15 years of service.
Based on the information that has been publicly posted, as required by M-07-06, a number of
agencies will have difficultly meeting this timetable. I request you instruct the officials in your
agency responsible for this effort either to confirm your agency’s previous plan is still on target or to
update the plan with a revised schedule under which your agency will meet as soon as possible the
requirements of HSPD-12 and the OMB memoranda.
In addition, as part of our ongoing process to monitor implementation progress, OMB will request
additional details be made publicly available. Specifically, this includes additional information on
status of background investigations and major milestones as outlined in agencies’ HSPD-12
implementation plans. OMB has modified the template previously distributed with M-07-06; the
updated template with specific reporting instructions will be distributed to your agency’s Chief
Information Officer.
101
M-07-19 FY 2007 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
This memorandum provides instructions for meeting your agency’s FY 2007 reporting requirements
under the Federal Information Security Management Act of 2002 (FISMA) (Title III, Pub. L. No.
107-347). It also includes reporting instructions on your agency’s privacy management program.
Because the Office of Management and Budget (OMB) and Congress use this report to evaluate
agency-specific and Government-wide security performance, it is especially important your agency’s
report clearly and accurately reflect the overall status of your program and not include conflicting
views of, or unresolved differences among, the various parties contributing to the report including the
Chief Information Officer (CIO), the Inspector General (IG), and the Senior Agency Official for
Privacy (SAOP).
Although the reporting categories and questions are generally the same as last year, there are some
updates based on security and privacy policies issued within the last year. In particular, the plans
required by OMB memorandum (M-07-16) of May 22, 2007, ―Safeguarding Against and Responding
to the Breach of Personally Identifiable Information‖1 should be provided in an appendix to your
annual report and include the following items:
• Breach notification policy (Attachment 3);
• Implementation plan to eliminate unnecessary use of Social Security Numbers (SSN)
(Attachment 1);
• Implementation plan and progress update on review and reduction of holdings of personally
identifiable information (PII) (Attachment 1); and
• Policy outlining rules of behavior and identifying consequences and corrective actions available
for failure to follow these rules (Attachment 4).
Please send one formal copy of your report addressed to the Director of OMB and an electronic copy
to fisma@omb.eop.gov by October 1, 2007. Each report must include a transmittal letter from the
agency head reconciling any differences between the findings of the agency CIO, IG, and SAOP. The
report must reflect the agency head’s determination of the adequacy and effectiveness of information
security and privacy policies, procedures, and practices.
M-07-18 Ensuring New Acquisitions Include Common Security Configurations
This memorandum provides recommended language for your agency to use in solicitations to ensure
new acquisitions include these common security configurations and information technology
providers certify their products operate effectively using these configurations. Your agency may
determine other specifications and/or language is necessary:
―a) The provider of information technology shall certify applications are fully functional
and operate correctly as intended on systems using the Federal Desktop Core
Configuration (FDCC). This includes Internet Explorer 7 configured to operate on
Windows http://csrc.nist.gov/itsec/guidance_WinXP.htmlWindows XP and Vista (in
Protected Mode on Vista). For the Windows XP settings, see:
htmlhttp://csrc.nist.gov/itsec/guidance_vista.html, and for the Windows Vista settings, see: .
102
b) The standard installation, operation, maintenance, update, and/or patching of
software shall not alter the configuration settings from the approved FDCC
configuration. The information technology should also use the Windows Installer
Service for installation to the default ―program files‖ directory and should be able to
silently install and uninstall.
c) Applications designed for normal end users shall run in the standard user context without
elevated system administration privileges."
A number of concurrent activities will further assist your agency’s adoption of common security
configurations. The National Institute of Standards and Technology (NIST) and the Department of
Homeland Security continue to work with Microsoft to establish a virtual machine to provide
agencies and information technology providers’ access to Windows XP and VISTA images. The
images will be pre-configured with the recommended security settings for test and evaluation
purposes to help certify applications operate correctly.
Additionally, Part 39 of the Federal Acquisition Regulation (FAR), which requires agencies to
include appropriate information technology security policies and requirements when acquiring
information technology, will be revised to incorporate requirements for using common security
configurations, as appropriate.
M-07-16 Safeguarding Against and Responding to the Breach of Personally Identifiable Information
As part of the work of the Identity Theft Task Force, this memorandum requires agencies to develop
and implement a breach notification policy within 120 days. The attachments to this memorandum
outline the framework within which agencies must develop this breach notification policy while
ensuring proper safeguards are in place to protect the information.
Agencies should note the privacy and security requirements addressed in this Memorandum apply to
all Federal information and information systems.8 Breaches subject to notification requirements
include both electronic systems as well as paper documents. In short, agencies are required to report
on the security of information systems in any formant (e.g., paper, electronic, etc.). 9
In formulating a breach notification policy, agencies must review their existing requirements with
respect to Privacy and Security (see Attachment 1). The policy must include existing and new
requirements for Incident Reporting and Handling (see Attachment 2) as well as External Breach
Notification (see Attachment 3). Finally, this document requires agencies to develop policies
concerning the responsibilities of individuals authorized to access personally identifiable information
(see Attachment 4).
Within the framework set forth in the attachments, agencies may implement more stringent policies
and procedures reflecting the mission of the agency. While this framework identifies a number of
steps to greatly reduce the risks related to a data breach of personally identifiable information, it is
important to emphasize that a few simple and cost-effective steps may well deliver the greatest
benefit, such as:
o reducing the volume of collected and retained information to the minimum necessary;
103
o limiting access10 to only those individuals who must have such access; and
o using encryption, strong authentication procedures, and other security controls to make
information unusable by unauthorized individuals.
This Memorandum should receive the widest possible distribution within your agency and each
affected organization and individual should understand their specific responsibilities for
implementing the procedures and requirements. Materials created in response to this Memorandum
and attachments should be made available to the public through means determined by the agency,
e.g., posted on the agency web site, by request, etc.
Consistent with longstanding policy requiring agencies to incorporate the costs for securing their
information systems, all costs of implementing this memorandum, including development,
implementation, notification to affected individuals, and any remediation activities, will be addressed
through existing agency resources of the agency experiencing the breach.
http://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy2007/m07-16.pdf
M-07-11 Implementation of Commonly Accepted Security Configurations for Windows Operating
Systems
To improve information security and reduce overall IT operating costs, agencies who have Windows
TM
TM
XP deployed and plan to upgrade to the Vista operating system, are directed to adopt the
security configurations developed by the National Institute of Standards and Technology (NIST), the
Department of Defense (DoD) and the Department of Homeland Security (DHS).
TM
The recent release of the Vista operating system provides a unique opportunity for agencies to
deploy secure configurations for the first time when an operating system is released. Therefore, it is
critical for all Federal agencies to put in place the proper governance structure with appropriate
policies to ensure a very small number of secure configurations are allowed to be used.
DoD has worked with NIST and DHS to reach a consensus agreement on secure configurations of
TM
TM
the Vista operating system, and to deploy standard secure desk tops for Windows XP .
Information is more secure, overall network performance is improved, and overall operating costs are
lower.
Agencies with these operating systems and/or plans to upgrade to these operating systems must adopt
these standard security configurations by February 1, 2008.
M-07-06 Validating and Monitoring Agency Issuance of Personal Identity Verification Credentials
This memorandum discusses validation and monitoring agency issuance of Personal Identity
Verification (PIV) compliant identity credentials. In support of Homeland Security Presidential
Directive 12 (HSPD-12), guidance requires by October 27, 2007, agencies complete background
checks on all current employees and contractors and issue PIV credentials with one exception. For
individuals who have been Federal department or agency employees over 15 years, a new
investigation and PIV credential issuance may be delayed, commensurate with risk, but must be
104
completed no later than October 27, 2008. Identity credentials should be provided as outlined in
Federal Information Processing Standard (FIPS) 201 and associated technical specifications.
By October 27, 2006, agencies were to begin issuing compliant credentials either through the
services of the General Services Administration (GSA) and Department of Interior (Interior) or by
performing this function internally.
Requirements
1. Ensuring agency credentials meet FIPS 201 requirements1. requirements. All agencies must
provide to GSA by January 19, 2007, a credential with their agency’s standard configuration. The
credential will be tested by GSA who will provide test results and report any configuration
problems requiring correction to the agency within three weeks of receipt. Should configuration
problems exist, the agency must resubmit their standard credential for re-testing once required
corrections are made. The resubmission should be within three weeks of receiving the initial test
results from GSA. Otherwise, the agency needs to be able to demonstrate substantial progress is
being made to address any test failures. Agencies should consider not issuing new credentials
until all problems identified in testing are resolved.
The initial testing services are being provided by GSA at no cost to the agency. However, agencies
may be responsible for reimbursing GSA if substantial GSA support is necessary to help agencies
resolve any technical issues.
Agencies not using a shared service program should access the FIPS 201 Evaluation Program
website at http://fips201ep.cio.gov/dce.php for directions on submitting test credentials and necessary
information to GSA for testing.
105
Agencies should contact April Giles at 202-501-1123 or April.Giles@gsa.gov to arrange for
delivering credentials to GSA at 1800 G Street, NW, Washington, D.C. Either Ms. Giles or David
Temoshok (David.Temoshok@gsa.gov or 202-208-7655) can be reached for any questions.
2. Quarterly status reports. Beginning March 1, 2007 and each quarter thereafter, agencies will post
to their federal agency public website a report on the number of PIV credentials issued. Agencies
must use the attached report template to distinguish between credentials issued to employees,
contractors, and others (e.g., visiting scientists). The website address should be provided to OMB at
eauth@omb.eop.gov by the due date.
M-06-20 Recommendations for Identity Theft Related Data Breach Notification
This memorandum provides instructions for meeting your agency’s FY 2006 reporting requirements
under the Federal Information Security Management Act of 2002 (FISMA) (Title III, Pub. L. No.
107-347). It also includes reporting instructions on your agency’s privacy management program.
Because the Office of Management and Budget (OMB) and Congress use your report to evaluate
agency-specific and government-wide security performance, it is especially important your agency’s
report clearly and accurately reflects the overall status of your program and not include conflicting
views of, or unresolved differences among, the various parties contributing to the report such as your
Chief Information Officer and Inspector General.
Although the reporting categories and questions are unchanged from last year, there are several
additional actions you must take, additional information you must provide, and slightly altered
timeframes for doing so.
• First, you should provide with your report, as an appendix or separate attachment, the results of
the review your agency’s senior official for privacy conducted pursuant to my memorandum
(M-06-15) of May 22, 2006, ―Safeguarding Personally Identifiable Information.‖1
• Second, this memorandum requests that Inspectors General provide a list of any systems they
have found missing from the agency’s inventory of major information systems. As you know,
your agency is required, under the E-Government Act of 2002, to provide an inventory of
major information systems (see, Pub. L. No. 107-347, §305(c)(2), codified at 44 U.S.C. §
3505(c)).
• Third, this memorandum requires agency privacy updates be submitted quarterly with your
security updates to support the President’s Management Agenda scorecard. These updates are
now due on the first day of September, December, March, and June.
• Finally, in accordance with OMB memorandum (M-06-19) of July 12, 2006, ―Reporting
Incidents Involving Personally Identifiable Information and Incorporating the Cost for
Security in Agency Information Technology Investments,‖ 2 we want you to identify any
physical or electronic incidents involving the loss of or unauthorized access to personally
identifiable information and report them according to the policies that are outlined in M-0619.
106
M-06-19 Reporting Incidents Involving Personally Identifiable Information and Incorporating the
Cost for Security in Agency Information Technology Investments
http://www.whitehouse.gov/sites/default/files/omb/assets/omb/memoranda/fy2006/m06-19.pdf
This memorandum provides updated guidance on the reporting of security incidents involving
personally identifiable information and to remind you of existing requirements, and explain new
requirements your agency will need to provide addressing security and privacy in your fiscal year
2008 budget submissions for information technology (IT).
Reporting Security Incidents
As you know, the Federal Information Security Management Act of 2002 requires all agencies to
report security incidents to a Federal incident response center. The center (US-CERT) is located
within the Department of Homeland Security. The specific reporting procedures are found in the
concept of operations for US-CERT.
As you know, the reporting procedures require agencies to report according to various timeframes
based on type of incident. This memorandum revises those reporting procedures to now require
agencies to report all incidents involving personally identifiable information to US-CERT within one
hour of discovering the incident. You should report all incidents involving personally identifiable
information in electronic or physical form and should not distinguish between suspected and
confirmed breaches. US-CERT will forward all agency reports to the appropriate Identity Theft Task
Force point-of-contact also within one hour of notification by an agency.
Incorporating Security Funding Into Information Technology Investments
On April 25, 2006, Clay Johnson sent to the heads of departments and agencies planning guidance
for the President’s fiscal year 2008 budget request.4 In that context, I wanted to (1) remind you of the
security and privacy requirements you should include within your IT investments and (2) explain
additional items you will need to provide in your materials.
In particular, I want to remind you of Office of Management and Budget (OMB) Memorandum M00-07, of February 28, 2000, "Incorporating and Funding Security in Information Systems
Investments," instructs agencies on how to include security into the funding for information
technology.5 This guidance is also included in OMB’s budget preparation policy, i.e., Circular A-11
and requires you to do two specific things. Under these existing guidance requirements, first, you
must integrate security into and fund it over the lifecycle of each system undergoing development,
modernization, or enhancement. Second, your steady-state system operations must meet existing
security requirements before new funds are spent on system development, modernization or
enhancement.
In addition, please provide additional detail on how you are allocating your resources between
correcting existing security weaknesses in stead-state investments and proposing funds for system
development, modernization, or enhancement.
Finally, for those agencies having significant isolated or wide-spread weaknesses identified by the
agency Inspector General or the Government Accountability Office, please identify the specific funds
you are requesting for proposed development, modernization, or enhancement efforts to correct these
security weaknesses. This includes correcting weaknesses found during your privacy program
reviews required by OMB Memorandum M-06-15, ―Safeguarding Personally Identifiable
107
Information‖6 and for implementing the specific security controls set forth in OMB Memorandum M06-16, ―Protection of Sensitive Agency Information.
M-06-18 Acquisition of Products and Services for Implementation of HSPD-12
This memorandum provides updated direction for the acquisition of products and services for the
implementation of Homeland Security Presidential Directive-12 (HSPD-12) ―Policy for a Common
Identification Standard for Federal Employees and Contractors‖ and also provides status of
implementation efforts.
Background
HSPD-12 establishes the requirement for a mandatory Government wide standard for secure and reliable
forms of identification for Federal employees and contractors. As directed by HSPD-12, the National
Institute of Standards and Technology (NIST) promulgated Federal Information Processing Standard
(FIPS) 201: Personal Identity Verification of Federal Employees and Contractors on February 25,
2005. FIPS 201 and associated NIST publications establish standards and requirements for the identity
verification of federal employees and contractors and for Personal Identity Verification (PIV) identity
credentials to be issued.
OMB policy memorandum M-05-24: Implementation of Homeland Security Presidential Directive 12
requires federal agencies to deploy products and operational systems to issue identity credentials meeting
the FIPS 201 standard by October 27, 2006. The OMB policy memorandum directs that agencies must
acquire products and services that are approved as compliant with Federal policy, standards and
supporting technical specifications in order to ensure government-wide interoperability. OMB has
designated the General Services Administration (GSA) as the ―executive agency for Government-wide
acquisitions of information technology to implement HSPD-12.‖ In this capacity, GSA will make
approved products and services available through acquisition vehicles that are available to all agencies.
FIPS 201 Product and Service Evaluation and Approval
Both NIST and GSA have established evaluation programs for the testing and evaluation of specific
products and services needed for the implementation of HSPD-12. NIST has established the NIST
Personal Identity Verification Program (NPIVP) to test and validate Personal Identity Verification (PIV)
components and sub-systems required by Federal Information Processing Standard (FIPS) 201. At
present, the NPIVP validation program provides for the testing and validation of PIV card applications
and PIV middleware for conformance to FIPS 201 and the interface specifications of NIST SP 800-73
Interfaces for Personal Identity Verification. NIST has published derived test requirements as NIST SP
800-85A: PIV Card Application and Middleware Test Guidelines. All of the tests under NPIVP are
handled by third-party test laboratories that are now designated as interim NPVIP Test Facilities. NIST
publication FIPS Pub 140-2: Security Requirements for Cryptographic Modules also requires the testing
and validation of cryptographic modules of PIV cards and other products performing cryptographic
functions. This testing is also performed by the accredited third-party facilities designated to perform
NPIVP testing. The status and results of these tests and product validation are posted at the NIST NPVIP
website: http://csrc.nist.gov/npivp/.
GSA also supports the evaluation and approval of products and services required for the implementation
of HSPD-12. GSA has identified 21 categories of products/services for which normative requirements are
expressed in NIST publication FIPS 201 and associated technical specifications. GSA has established the
FIPS 201 Evaluation Program to evaluate and approve such products/services as compliant with specified
FIPS 201 requirements. The Evaluation Program also provides for product interoperability and
performance testing. Specific evaluation and approval requirements for each of the 21 categories of
108
products/services have been established and publicly posted. Each Approval Procedure cites the specific
FIPS 201 requirements that are evaluated for that category of product/service and the type of evaluation
needed for approval. The 21 categories of products/services for the FIPS 201 Evaluation Program and
Approval Procedures for all 21 of those categories are posted at the FIPS 201 Evaluation Program
website: http://fips201ep.cio.gov/.
GSA has designated a third-party laboratory for the evaluation and testing of products and services under
the FIPS 201 Evaluation Program. Vendors must submit completed application packages and, as
appropriate, products if laboratory testing is required.
GSA has established the FIPS 201 Approved Products List for all products and services that have been
approved under the GSA FIPS 201 Evaluation Program. To date 49 vendors have enrolled for the
Evaluation Program and are in the process of submitting application packages for over 100
products/services across the 21 categories. GSA will continue to evaluate and approve products/services
as completed submissions are received; all approved products are posted to the Approved Products List.
The Approved Products List can be accessed at: http://idmanagement.gov.
There are other types of services that may be necessary for HSPD-12 systems and deployments, but have
no normative requirements specified in FIPS 201 and, therefore, are not included in the FIPS 201
Evaluation Program (e.g., integration services, contractor managed services and solutions). Qualification
requirements for these services and a list of qualified vendor services are also posted at:
http://idmanagement.gov.
Acquisition Guidance
GSA has established Special Item Number (SIN) 132-62 on Information Technology (IT) Schedule 70 for
the acquisition of approved HSPD-12 Implementation Products and Services. The following categories of
services and products are established for SIN 132-62:
1. PIV Enrollment and registration services and products;
2. PIV System infrastructure services and products;
3. PIV Card production services and products;
4. PIV Card activation and finalization services and products;
5. PIV Integration services and products;
6. Logical access control and physical access control services and products;
7. Approved FIPS 201 services and products;
8. Other professional services.
FAR Amendments
The following amendments to the Federal Acquisition Regulation (FAR) are being established:
• FAR Case 2005 015: Common Identification Standard for Contractors. FAR Case 2005 015
applies the identity verification requirements of FIPS 201 to federal contractors.
• FAR Case 2005 017: Requirement to Purchase Approved Authentication Products and
Services. FAR Case 2005 017 requires agencies to acquire only approved PIV products
and services.
M-06-16 Protection of Sensitive Agency Information
In an effort to properly safeguard our information assets while using information technology, it is
essential for all departments and agencies to know their baseline of activities.
The National Institute of Standards and Technology (NIST) provided a checklist for protection of
remote information. (See attachment) The intent of implementing the checklist is to compensate for
109
the lack of physical security controls when information is removed from, or accessed from outside
the agency location. In addition to using the NIST checklist, I am recommending all departments and
agencies take the following actions:
1. Encrypt all data on mobile computers/devices which carry agency data unless the data is
determined to be non-sensitive, in writing, by your Deputy Secretary or an individual
he/she may designate in writing;
2. Allow remote access only with two-factor authentication where one of the factors is provided
by a device separate from the computer gaining access;
3. Use a ―time-out‖ function for remote access and mobile devices requiring user reauthentication after 30 minutes inactivity; and
4. Log all computer-readable data extracts from databases holding sensitive information and
verify each extract including sensitive data has been erased within 90 days or its use is
still required.
Most departments and agencies have these measures already in place. We intend to work with the
Inspectors General community to review these items as well as the checklist to ensure we are
properly safeguarding the information the American taxpayer has entrusted to us. Please ensure these
safeguards have been reviewed and are in place within the next 45 days.
Protection of ―Remote‖ Information
This checklist provides specific actions to be taken by federal agencies for the protection of
Personally Identifiable Information (PII) categorized in accordance with FIPS 199 as moderate or
high impact that is either:
• Accessed remotely; or
• Physically transported outside of the agency’s secured, physical perimeter (this includes
information transported on removable media and on portable/mobile devices such as
laptop computers and/or personal digital assistants).
The specific intent is to compensate for the protections offered by the physical security controls when
information is removed from, or accessed from outside of the agency location. Additionally, this
checklist has been developed from existing guidance with the expectation that information security is
a mission requirement essential to achieving the operational benefits of information technology
without exposing the agency, its assets, or individuals to undue risk.
110
SECURITY CHECKLIST FOR PERSONALLY IDENTIFIABLE INFORMATION THAT IS TO BE TRANSPORTED
AND/OR STORED OFFSITE, OR THAT IS TO BE ACCESSED REMOTELY
Procedure
STEP 1: Confirm identification of personally identifiable information protection needs.
Action Item 1.1: Verify information categorization to ensure identification of personally identifiable information
requiring protection when accessed remotely or physically removed.
Action Item 1.2: Verify existing risk assessment.
STEP 2: Verify adequacy of organizational policy.
Action Item 2.1: Identify existing organizational policy that addresses the information protection needs associated
with personally identifiable information that is accessed remotely or physically removed.
Action Item 2.2: Verify that the existing organizational policy adequately addresses the information protection
needs associated with personally identifiable information that is accessed remotely or physically removed.
Action Item 2.3: Revise/develop organizational policy as needed, including steps 3 and 4.
If personally identifiable information is to be transported and/or stored offsite, follow Step 3; for remote
access to personally identifiable information, follow Step 4.
STEP 3: Implement protections for personally identifiable information being transported and/or stored
offsite.
Action Item 3.1: In those instances where personally identifiable information is transported to a remote site,
implement NIST Special Publication 800-53 security controls ensuring that information is transported only in
encrypted form.
Action Item 3.2: In those instances where personally identifiable information is being stored at a remote site,
implement NIST Special Publication 800-53 security controls ensuring that information is stored only in encrypted
form.
Checklist Complete.
STEP 4: Implement protections for remote access to personally identifiable information.
Action Item 4.1: Implement NIST Special Publication 800-53 security controls requiring authenticated, virtual
private network (VPN) connection.
Action Item 4.2: Implement NIST Special Publication 800-53 security controls enforcing allowed downloading of
personally identifiable information.
If remote storage of personally identifiable information is to be permitted follow Action Item 4.3, otherwise
follow Action Item 4.4.
Action Item 4.3: Implement NIST Special Publication 800-53 security controls enforcing encrypted remote storage
of personally identifiable information.
Checklist Complete.
Action Item 4.4: Implement NIST Special Publication 800-53 security controls enforcing no remote storage of
personally identifiable information.
Checklist Complete.
111
M-06-15 Safeguarding Personally Identifiable Information
This memorandum reemphasizes your many responsibilities under law and policy to appropriately
safeguard sensitive personally identifiable information and train your employees on their
responsibilities in this area. In particular, the Privacy Act requires each agency to establish:
―rules of conduct for persons involved in the design, development, operation, or maintenance
of any system of records, or maintaining any record, and instruct each such person with
respect to such rules and the requirements of [the Privacy Act], including any other rules and
procedures adopted pursuant to this [Act] and the penalties for noncompliance‖, and
―appropriate administrative, technical and physical safeguards to insure
the security and confidentiality of records and to protect against any anticipated
threats or hazards to their security or integrity which could result in substantial harm,
embarrassment, inconvenience or unfairness to any individual on whom information is
maintained.‖
Early http://www.whitehouse.gov/omb/egov/documents/SAOPcontactlistfinal.pdfEarly last year, I
directed each agency to designate a Senior Agency Official for Privacy at the Assistant Secretarylevel or equivalent (Memorandum M-05-08), and all agencies have done so, designating a senior
official with overall responsibility and accountability for ensuring the agency’s implementation of
information privacy protections. (See pdf)
Please have your agency’s Senior Official for Privacy conduct a review of your policies and
processes, and take corrective action as appropriate to ensure your agency has adequate safeguards to
prevent the intentional or negligent misuse of, or unauthorized access to, personally identifiable
information. This review shall address all administrative, technical, and physical means used by your
agency to control such information, including but not limited to procedures and restrictions on the
use or removal of personally identifiable information beyond agency premises or control. This
review shall be completed in time for you to include the results in your upcoming reports due this fall
on compliance with the Federal Information Security Management Act (FISMA). Include any
weaknesses you identify in your security plans of action and milestones already required by FISMA.
In addition, please ensure your agency employees are reminded within the next 30 days of their
specific responsibilities for safeguarding personally identifiable information, the rules for acquiring
and using such information as well as the penalties for violating these rules.
Finally, I want to remind you of your responsibilities under FISMA and related policy to promptly
and completely report security incidents to proper authorities, including Inspectors General and other
law enforcement authorities. In certain circumstances, this reporting also includes the Department of
Homeland Security (DHS). Last year, the Office of Management and Budget provided to your Chief
Information Officer the specific requirements including timelines for reporting to DHS. Copies of
these mandatory requirements are available from the DHS National Cyber Security Division.
M-06-06 Sample Privacy Documents for Agency Implementation of Homeland Security Presidential
Directive (HSPD) 12
The Office of Management and Budget (OMB) issued guidance on August 5, 2005 to departments
and agencies regarding their responsibilities under HSPD-12 (―Policy for a Common Identification
112
Standard for Federal Employees and Contractors‖ (the Directive)).1 As you know, HSPD-12 required
the Department of Commerce to develop, and departments and agencies to implement, a governmentwide standard for secure and reliable credentialing of Federal employees and contractors. Section 6
of OMB’s August 5, 2005 guidance itemizes the privacy-related elements of HSPD-12
implementation based on existing requirements that individuals be fully informed about collections
of their personal information.2
As was noted in OMB’s guidance, attached are sample privacy documents to use as models in
implementing HSPD-12 at your agencies. Included are sample Privacy Act systems of records
notices, Privacy Act statements, and a privacy impact assessment developed by a working group of
privacy experts. You may modify the samples to meet your agency-specific requirements, including
those not anticipated by the working group, but overall your documents should comport with the
models provided.
M-05-24 Implementation of Homeland Security Presidential Directive (HSPD) 12 – Policy for a
Common Identification Standard for Federal Employees and Contractors
On August 27, 2004, the President signed HSPD-12 ―Policy for a Common Identification Standard
for Federal Employees and Contractors‖ (the Directive). The Directive requires the development and
agency implementation of a mandatory, government-wide standard for secure and reliable forms of
identification for Federal employees and contractors. As required by the Directive, the Department of
Commerce issued Federal Information Processing Standard 201 (the Standard). This memorandum
provides implementing instructions for the Directive and the Standard.
Inconsistent agency approaches to facility security and computer security are inefficient and costly,
and increase risks to the Federal government. Successful implementation of the Directive and the
Standard will increase the security of your Federal facilities and information systems. As noted in the
attached guidance, this standard identification applies to your employees and contractors who work
at your facilities or have access to your information systems. Following implementation, Federal
departments and agencies will be able to recognize and accept this common identification standard.
Attachments
A) HSPD-12 Implementation Guidance for Federal Departments and Agencies
B) HSPD-12 Policy for a Common Identification Standard for Federal Employees and Contractors
The Standard, required by HSPD-12, contains two parts to guide department and agency
implementation. The requirements of part 2 build upon the requirements of part 1.
They are:
• Part 1: Common Identification, Security and Privacy Requirements – minimum
requirements for a Federal personal identification system that meets the control and security
objectives of the Directive, including the personal identity proofing, registration, and
issuance process for employees and contractors.
A. Adopt and accredit a registration process
B. Initiate the National Agency Check with Written Inquiries (NACI) or other
suitability or national security investigation prior to credential issuance.
C. Include language implementing the Standard in applicable new contracts.
113

• Part 2: Government-wide Uniformity and Interoperability – Detailed specifications to
support technical interoperability among departments and agencies, including card elements,
system interfaces, and security controls required to securely store and retrieve data from the
card.
A. Issue and require the use of identity credentials for all new employees and
contractors
B. Implement the technical requirements of the Standard
C. Risk Based Facility Access
D. Use of Digital Certificates
M-05-16 Regulation on Maintaining Telecommunication Services During a Crisis or Emergency in
Federally-owned Buildings
Effective July 1, 2005, in accordance with the Presidential Memorandum (―Assignment of Certain
Functions Relating to Telecommunications‖) and Section 414, this regulation requires each agency to
initiate a review of its telecommunication capabilities in the context of planning for contingencies
and continuity of operations (COOP) situations. Through the agency’s initiation and conduct of this
review (and the agency’s follow-up implementation of the results of this review), the agency will be
in compliance with the requirements of Section 414 with respect to the provision after July 1, 2005,
of telecommunications services for Federally-owned buildings.
Each agency is responsible for ensuring, in the context of contingencies and COOP situations, the
continued availability of its mission essential and national security/emergency preparedness
telecommunications services. Each agency’s review shall be directed to this objective. First, your
agency’s review shall confirm that the agency, in its planning for contingencies and COOP
situations, has appropriately addressed the agency’s need for viable, risk-based and cost-effective
methods for ensuring the availability of mission essential and national security/emergency
telecommunications services. These methods may include, when determined by the agency to be
appropriate in the context of the agency’s circumstances, the use of redundant and physically
separate telecommunications service entry points into buildings and the use of physically diverse
local network facilities. Second, your agency shall review and confirm that it is complying with
directives issued by the National Communications System and guidance issued in the Federal
Emergency Management Agency’s (FEMA) Federal Preparedness Circular 65 (FPC 65), as
appropriate. Additional information on these directives and FPC 65 guidance is provided in the
attachment.
Section 414 is directed solely at telecommunications services for Federally-owned buildings.
However, an agency’s planning for contingencies and COOP situations must also address those
agency operations that are carried out in leased buildings. Thus, as a matter of Executive Branch
policy regarding the planning for contingencies and COOP situations, your review should also
include the agency’s activities in leased buildings as well as owned buildings. However, as just
noted, Section 414 is limited to telecommunications services for Federally-owned buildings;
therefore your agency’s review of such services for its activities in Federally-owned buildings will
satisfy the requirements of Section 414.
114
Finally, when your agency initiates new telecommunications procurements, the agency shall
determine the appropriate level of availability, performance and restoration that is required, in
accordance with the agency’s contingencies and COOP plans and programs.
This regulation is not intended to, and does not, create any right or benefit, substantive or procedural,
enforceable at law or in equity by a party against the United States, its departments, agencies,
entities, officers, employees, or agents, or any other person.
Attachment
Federal Preparedness Circular 65 (FPC 65)1
FPC 65 provides guidance to Federal Executive Branch departments and agencies for use in
developing contingency plans and programs for continuity of operations (COOP). COOP planning
facilitates the performance of department/agency essential functions following the disruption of
normal operations.
An important part of COOP planning is the selection as appropriate of an alternate operating facility
and the provisioning of interoperable communications with all essential internal and external
organizations, customers and the public. In accordance with FPC 65, agencies should have already
considered locating alternate operating facilities in areas where power, telecommunications, and
internet grids would be distinct from those of the primary site. Agencies should also have taken
advantage of existing agency field infrastructures and give consideration to options such as
telecommuting locations. FEMA recommends telecommunications circuits at alternate facilities be
tested on a regular basis.
National Communication System Directives
National Communications System directives establish policies and procedures for national
security/emergency preparedness (NS/EP) telecommunications. NS/EP telecommunications services
are defined as those services that are used to maintain a state of readiness or to respond to and
manage any event or crisis (local, national, or international) that causes or could cause injury or harm
to the population, damage to or loss of property, or degrade or threaten the national security or
emergency preparedness posture of the United States.
National Communications System directives require participation in programs such as the
Telecommunications Service Priority System which establishes precedence for vendor restoration of
critical government telecommunications circuits.
The National Communications System has recently developed a methodology for assessing a
facility's route diversity and also an accompanying methodology to assess the risk of not having route
diversity. Please contact mailto:routediversity@dhs.gov for additional information.
M-05-15 FY 2005 Reporting Instructions for the Federal Information Security Management Act and
Agency Privacy Management
This memorandum provides instructions for agency reporting under the Federal Information
Security Management Act of 2002 (FISMA).
115
This year, we are asking a number of questions regarding your agency’s privacy program. As
noted in the instructions, the privacy program questions (Section D of the report) shall be
completed by the Senior Agency Official for Privacy, in consultation with other agency privacy
officials as appropriate. These questions relate, in part, to agency implementation of the privacy
provisions of the E-Government Act. Thus, OMB will no longer ask agencies to include privacy
related information in their annual E-Government Act submissions.
As you know, FISMA provides the framework for securing the Federal government’s
information technology including both unclassified and national security systems. All agencies
must implement the requirements of FISMA and report annually to the Office of Management
and Budget (OMB) and Congress on the effectiveness of their security programs.
OMB uses the information to help evaluate agency-specific and government-wide security
performance, develop its annual security report to Congress, assist in improving and maintaining
adequate agency security performance, and inform development of the E-Government Scorecard
under the President’s Management Agenda.
M-05-08 - Designation of Senior Agency Officials for Privacy
OMB is today asking each executive Department and agency (―agency‖) to identify to OMB the
senior official who has the overall agency-wide responsibility for information privacy issues.
Consistent with the Paperwork Reduction Act, the agency’s Chief Information Officer (CIO) may
perform this role. Alternatively, if the CIO, for some reason, is not designated, the agency may have
designated another senior official (at the Assistant Secretary or equivalent level) with agency-wide
responsibility for information privacy issues. In any case, the senior agency official should have
authority within the agency to consider information privacy policy issues at a national and agencywide level.
The senior agency official will have overall responsibility and accountability for ensuring the
agency’s implementation of information privacy protections, including the agency’s full compliance
with federal laws, regulations, and policies relating to information privacy, such as the Privacy Act.
As is required by the Privacy Act, the Federal Information Security Management Act (FISMA), and
other laws and policies, each agency must take appropriate steps necessary to protect personal
information from unauthorized use, access, disclosure or sharing, and to protect associated
information systems from unauthorized access, modification, disruption or destruction. Agencies are
required to maintain appropriate documentation regarding their compliance with information privacy
laws, regulations, and policies. And, agencies have the authority to conduct periodic reviews (e.g., as
part of their annual FISMA reviews) to promptly identify deficiencies, weaknesses, or risks. When
compliance issues are identified, agencies are obligated to take appropriate steps to remedy them.
M-05-05 - Electronic Signatures: How to Mitigate the Risk of Commercial Managed Services
Previous OMB guidance instructed agencies to move to commercial managed services for public key
infrastructure (PKI) and electronic signatures.1 A move to a commercial service from a government
operated one will save time and money. However, lack of strong government controls can create new
116
risks not present in government operated systems. To mitigate these risks, you must use shared
service providers.
Use Shared Service Providers
Strong government oversight and internal controls mitigate the risk of using a commercial
service. For either government operated systems or those commercially provided under a contract,
agencies must ensure their electronic signature systems have an adequate system of oversight and
internal controls.
The General Services Administration (GSA) has created the Shared Service Provider
Program to provide strong government oversight of commercial managed service providers. The list
of providers certified to provide PKI services is located at http://www.cio.gov/ficc/. By contracting
with a certified provider, agencies obtain services consistent with current electronic signature law
and policy. The cost savings and benefits associated with a contractor provided service, with
adequate government oversight and control, outweigh the costs of mitigating potential risks
associated with contractor involvement. Qualified providers must:
• operate their certification authorities under a certificate policy developed, owned and controlled
by the Federal government,
• demonstrate compliance with this policy with an annual third party audit,
• receive approval from a qualified GSA official, and
• comply with existing security law, including certification and accreditation.
GSA will grant the provider authority to operate the service and supporting IT system. You
will receive copies of GSA’s authorization. However, agencies continue to have an on-going
responsibility to meet all legal and OMB policy requirements on their portion of the IT system.
Include these operations in your annual evaluation required by the Federal Information Security
Management Act.
M-05-04 - Policies for Federal Agency Public Websites
Federal agency public websites are information resources funded in whole or in part by the
Federal government and operated by an agency, contractor, or other organization on behalf of the
agency. They present government information or provide services to the public or a specific nonFederal user group and support the proper performance of an agency function. Federal agency public
websites are also information dissemination products as defined in Office of Management and
Budget (OMB) Circular A-130, ―Management of Federal Information Resources.‖ Agencies must
manage Federal agency public websites as part of their information resource management program
following guidance in OMB Circular A-130, OMB ―Guidelines for Ensuring and Maximizing the
Quality, Objectivity, Utility, and Integrity of Information Disseminated by Federal Agencies‖ (67 FR
5365), this memorandum, and other information policy issuances.
117
M-04-26 - Personal Use Policies and "File Sharing" Technology
Background
A type of file sharing known as Peer-to-Peer (P2P) refers to any software or system allowing
individual users of the Internet to connect to each other and trade files. These systems are usually
highly decentralized and are designed to facilitate connections between persons who are looking
for certain types of files. While there are many appropriate uses of this technology, a number of
studies show, the vast majority of files traded on P2P networks are copyrighted music files and
pornography. Data also suggests P2P is a common avenue for the spread of computer viruses
within IT systems.
Federal computer systems or networks (as well as those operated by contractors on the
government's behalf) must not be used for the downloading of illegal and/or unauthorized
copyrighted content. It is important to ensure computer resources of the Federal government are
not compromised and to demonstrate to the American public the importance of adopting ethical
and responsible practices on the Internet.
The CIO Council has issued recommended guidance on "Limited Personal Use of Government
Office Equipment Including Information Technology.1" Examples of inappropriate personal use
include "the creation, download, viewing, storage, copying, or transmission of materials related
to illegal gambling, illegal weapons, terrorist activities, and any other illegal activities or
activities otherwise prohibited" and "the unauthorized acquisition, use, reproduction,
transmission, or distribution of any controlled information including computer software and data,
that includes privacy information, copyrighted, trade marked or material with other intellectual
property rights (beyond fair use), proprietary data, or export controlled software or data."
Direction to Agencies
Effective use and management of file sharing technology requires a clear policy, training of
employees on the policy, and monitoring and enforcement. Specifically, agencies are directed to:
1.
Establish or Update Agency Personal Use Policies to be Consistent with CIO Council Recommended
Guidance.
OMB expects all agencies to establish personal use policies, consistent with the recommended
guidance developed by the CIO Council. Agencies who have not established personal use
guidance should do so without delay, but no later than December 1, 2004.
2.
Train All Employees on Personal Use Policies and Improper Uses of File Sharing
Agencies’ IT security or ethics training must train employees on agency personal use policies
and the prohibited improper uses of file sharing. Training must be consistent with OMB Circular
A-130, appendix III paragraph (3)(a)(b) which states agencies must "ensure that all individuals
are appropriately trained in how to fulfill their security responsibilities […]. Such training shall
118
assure that employees are versed in the rules of the system, be consistent with guidance issued by
NIST and OPM, and apprise them about available assistance and technical security products and
techniques."
On October 6, 2004, as part of the agency annual reports required by Federal Information
Security Management Act of 2002 (FISMA) described in OMB Memorandum 04-25, FY 2004
Reporting Instructions for FISMA2 agencies must report whether they provide training regarding
the appropriate use of P2P file sharing.
3.
Implement Security Controls to Prevent and Detect Improper File Sharing
As required by FISMA, agencies are to use existing NIST standards and guidance to complete
system risk and impact assessments in developing security plans and authorizing systems for
operation. Operational controls detailing procedures for handling and distributing information
and management controls outlining rules of behavior for the user must ensure the proper controls
are in place to prevent and detect improper file sharing.
Again, OMB recognizes there are appropriate uses of file sharing technologies, but as with all
technology it must be appropriately managed.
M-04-25 – FY 2004 Reporting Instructions for the Federal Information Security Management Act and
Updated Guidance on Quarterly IT Security Reporting
Agencies are to transmit their FY04 reports to OMB by October 6, 2004. Guidance for transmitting the reports to
Congress is set out in the attached instructions.
M-04-16 - Software Acquisition
This memorandum reminds agencies of policies and procedures covering acquisition of software to support agency
operations.
The Office of Management and Budget (OMB) Circulars A-11 and A-130 and the Federal Acquisition Regulation
(FAR), guide agency information technology (IT) investment decisions. These policies are intentionally technology
and vendor neutral, and to the maximum extent practicable, agency implementation should be similarly neutral. As
this guidance states, all agency IT investment decisions, including software, must be made consistent with the
agency’s enterprise architecture and the Federal Enterprise Architecture. Additionally, agencies must consider the
total cost of ownership including lifecycle maintenance costs, the costs associated with risk issues, including
security and privacy of data, and the costs of ensuring security of the IT system itself. Furthermore, software
acquisitions must comply with OMB Memorandum M-04-08, Maximizing Use of SmartBuy and Avoiding
Duplication of Agency Activities with the President’s 24 E-Gov Initiatives (February 25, 2004), and where
required, be coordinated with the SmartBuy program.
This reminder applies to acquisitions of all software, whether it is proprietary or Open Source Software. Open
Source Software’s source code is widely available so it may be used, copied, modified, and redistributed. It is
licensed with certain common restrictions, which generally differ from proprietary software. Frequently, the licenses
require users who distribute Open Source Software, whether in its original form or as modified, to make the source
code widely available. Subsequent licenses usually include the terms of the original license, thereby requiring wide
availability. These differences in licensing may affect the use, the security, and the total cost of ownership of the
software and must be considered when an agency is planning a software acquisition.
119
Because software licensing requirements can be legally complex and can directly impact agency operations,
procurement executives and program managers should consult with their General Counsel’s Office to ensure the
requirements are understood before procuring and using the software. In addition, it is essential for procurement
executives and program managers to make sure employees are aware of the licensing restrictions of the software
they are using. This is particularly important when the licensing restrictions require changes to routine employee
operations.
M-04-15 - Development of Homeland Security Presidential Directive (HSPD) - 7 Critical Infrastructure
Protection Plans to Protect Federal Critical Infrastructures and Key Resources
SUBJECT: Development of Homeland Security Presidential Directive (HSPD) - 7 Critical Infrastructure Protection
Plans to Protect Federal
Critical Infrastructures and Key Resources
On December 17th, 2003, the President signed HSPD-7, "Critical Infrastructure Identification, Prioritization and
Protection" (Attachment A). This HSPD supersedes Presidential Decision Directive/NSC-63 of May 22, 1998,
―Critical Infrastructure Protection‖, and establishes a national policy for Federal departments and agencies to
identify and prioritize United States critical infrastructure and key resources and to protect them from terrorist
attacks. 17 th,
HSPD-7 instructed Federal departments and agencies (agencies) to prepare plans for protecting physical and cyber
critical infrastructure and key resources (CI/KR), owned or operated, including leased facilities by July 31, 2004.
OMB has been working with agencies on this requirement and agency Chief Information Officers received official
distribution of draft guidance on April 27, 2004. This memorandum, developed in consultation with the Homeland
Security Council (HSC) and the Department of Homeland Security (DHS), includes the required format for agencies
to use when submitting internal critical infrastructure protection (CIP) plans. Pursuant to the guidance provided
herein, these plans must address identification, prioritization, protection, and contingency planning, including the
recovery and reconstitution of essential capabilities. In particular, planning must include protection priorities, the
agency’s ability to ensure continuity of business operations during a physical or cyber attack, and, where current
capabilities are lacking, plans of action and milestones to achieve the necessary level of performance.
Upon submission, security plans will be subject to an interagency review coordinated by DHS. The goals of these
reviews include ensuring consistent planning and protection of Federal CI/KR across the Federal government. DHS
will prepare a written evaluation of each agency’s physical security plan and provide that evaluation within 120 days
of the agency’s submission of the plan. Agency cyber security plans will be reviewed in a manner consistent with
reviews of cyber security reports submitted under the Federal Information Security Management Act and current
guidance. These efforts will inform DHS’ efforts to develop the National Infrastructure Protection Plan, as it will
provide the data for a more detailed analysis of CI/KR. DHS’ planning effort will outline the methodology for
determining what government facilities are priorities for protection.
Agencies are requested to submit internal CIP plans utilizing the reporting instructions contained in Attachment B.
A consolidated plan must be prepared at the Departmental or ―parent‖ agency level and cover all agency subelements to the extent they own or operate critical infrastructures or key resources. The July 31, 2004 report must be
submitted by the Deputy Secretary or equivalent official.
Agencies will soon receive additional instructions regarding the means for securely transmitting these internal CIP
plans. At a minimum, agency-specific information in the internal CIP plans should be safeguarded as sensitive and
should receive the full measure of protection afforded by Exemption 2 of the Freedom of Information Act, 5 U.S.C.
sec. 552, if an agency ever receives a FOIA request for such information. Further background material on FOIA
Exemption 2 is contained in the Department of Justice’s FOIA Update, Vol. X, No. 3, at 3-4 (Protecting
Vulnerability Assessments Through Application of Exemption Two‖), which is available at
http://www.usdoj.gov/oip/foia_updates/Vol_X_3/page3.html
Agencies should refer to the classification standards contained in Executive Order No. 12958 ―Classified National
Security Information‖ to determine whether information contained in the internal CIP plan is classified. Section 1.5
of the Executive Order contains classification categories that include:
 United States Government programs for safeguarding nuclear materials or facilities; or vulnerabilities
or capabilities of systems, installations, projects or plans relating to the national security.
120
M-04-04 - E-Authentication Guidance for Federal Agencies
The Administration is committed to reducing the paperwork burden on citizens and
businesses, and improving government response time to citizens – from weeks down to minutes. To
achieve these goals, citizens need to be able to access government services quickly and easily by
using the Internet. This guidance document addresses those Federal government services
accomplished using the Internet online, instead of on paper. To make sure that online government
services are secure and protect privacy, some type of identity verification or authentication is needed.
The attached guidance updates guidance issued by OMB under the Government Paperwork
Elimination Act of 1998, 44 U.S.C. § 3504 and implements section 203 of the E-Government Act, 44
U.S.C. ch. 36. This guidance also reflects activities as a result of the E-Authentication E-Government
Initiative and recent standards issued by the National Institute of Standards and Technology (NIST).
In preparing this guidance, we have worked closely with and incorporated comments from agency
Chief Information Officers.
This guidance takes in account current practices in the area of authentication (or eauthentication) for access to certain electronic transactions and a need for government-wide
standards and will assist agencies in determining their authentication needs for electronic
transactions. This guidance directs agencies to conduct ―e-authentication risk assessments‖ on
electronic transactions to ensure that there is a consistent approach across government. (see
Attachment A). It also provides the public with clearly understood criteria for access to Federal
government services online. Attachment B summarizes the public comments received on an earlier
version of this guidance.
M-03-22 - OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002
Background
Section 208 of the E-Government Act of 2002 (Public Law 107-347, 44 U.S.C. Ch 36) requires
that OMB issue guidance to agencies on implementing the privacy provisions of the EGovernment Act (see Attachment A). The text of section 208 is provided as Attachment B to this
Memorandum. Attachment C provides a general outline of regulatory requirements pursuant to
the Children’s Online Privacy Protection Act ("COPPA"). Attachment D summarizes the
modifications to existing guidance resulting from this Memorandum. A complete list of OMB
privacy guidance currently in effect is available at OMB’s website.
As OMB has previously communicated to agencies, for purposes of their FY2005 IT budget
requests, agencies should submit all required Privacy Impact Assessments no later than
October 3, 2003.
M-03-19 - FY 2003 Reporting Instructions for the Federal Information Security Management Act and
updated Guidance on Quarterly IT Security Reporting
This guidance provides direction to agencies on implementing FISMA and consists of the following
four attachments: • Attachment A – The information in this attachment is new and highlights the
more substantive changes introduced by FISMA from previous IT security legislation. • Attachment
B – This attachment contains the FY03 FISMA reporting instructions for agencies and Inspectors
General. • Attachment C – This attachment contains directions for agencies on quarterly reporting on
121
IT security efforts. It includes both the continued quarterly plan of action and milestones updates and
performance measure updates. • Attachment D – This attachment contains definitions in law and
policy referenced in the guidance. I would also like to take this opportunity to inform you of a
number of actions OMB has undertaken to further assist agencies in improving their IT security
status through the President’s Management Agenda and the budget process. On a quarterly basis,
agencies provide updates to OMB on their IT security efforts through quantitative performance
measures and progress in remediating IT security weaknesses. This information is used to inform the
agency’s E-Government Scorecard under the President’s Management Agenda. Additionally, I am
directing my staff to work with your agency to ensure that system remediation plans are implemented
and appropriate resources are identified through the budget process to resolve critical IT security
weaknesses.
Agency reports are due to OMB on September 22nd, 2003. Agency heads should transmit to OMB
the agency report (containing both the agency and IG components) and copies of the IG’s
independent evaluations. This transmission represents a confirmation by the agency head of the
agency’s IT security status as detailed in the agency report. Your CIO and IG received an electronic
copy of this guidance and templates to assist them in reporting. Agency reports will continue to serve
as the primary basis for OMB’s annual summary report to Congress.
M-03-18 - Implementation Guidance for the E-Government Act of 2002
This document provides agencies with guidance following the enactment of the EGovernment Act of 2002 (Public Law 107-347, 44 U.S.C. Ch 36) which was signed by the
President on December 17, 2002 and became effective on April 17, 2003.
The Administration sees this Act as a significant step forward in the way that Federal agencies
should consider using information technology (IT) to transform agency business into a more
citizen oriented and user friendly process. The E-Government Act:






advocates a more citizen focused approach to current governmentwide IT policies and
programs;
establishes an Office of Electronic Government in the Office of Management and Budget
(OMB) to coordinate IT policy;
formalizes the establishment of a Chief Information Officers (CIO) Council;
permanently reauthorizes and amends agency information security requirements through
the Federal Information Security Management Act (FISMA);
protects the confidentiality of certain types of data across the government and allows key
statistical agencies to share business data through the Confidential Information Protection
and Statistical Efficiency Act (CIPSEA); and
supports activities that OMB and the executive branch are already pursuing under the
President’s Management Agenda’s Expanding Electronic Government initiative.
This document provides agencies with guidance on specific actions that are now required under
the E-Government Act. Agencies should apply the requirements of the Act, and this guidance, to
any program that uses IT to improve the program’s effectiveness and efficiency in delivering
services to citizens.
122


Attachment A includes a description of new actions required of agencies, including new
initiatives.
Attachment B contains a table of required activities and products and their due date.
Agencies should use this table to determine how the provisions and requirements of the Act may
impact their programs. The table also provides information on which agencies will be leading the
government-wide implementation of these requirements – some agencies have specific duties under
the Act, other agencies are already pursuing activities to support the particular initiative.
M-02-09 - Reporting Instructions for the Government Information Security Reform Act and Updated
Guidance on Security Plans of Action and Milestones
Background
Last year’s efforts in implementing the Security Act resulted in a detailed understanding of the Federal
government’s information and information technology (IT) security status. As a result of agencies’ work, we now
have a valuable baseline of security performance, ultimately allowing us to track progress in securing the Federal
government’s operations and information assets. Per the requirements of the Security Act, OMB summarized agency
reports in a report sent to Congress in February, www.whitehouse.gov/omb/inforeg/fy01securityactreport.pdf.
Last year OMB issued memorandum 01-24, guidance on reporting the results of agencies’ annual security reviews
and evaluations. OMB also issued memorandum 02-01, guidance for security plans of action and milestones to assist
agencies in closing security performance gaps identified in their reviews. Based on lessons learned from last year’s
reporting, along with input from agency officials, Inspectors General (IGs), and the General Accounting Office, this
memorandum provides updated guidance.
New Reporting Guidance
While the reporting requirements remain largely the same, high-level management performance measures have been
added to the reporting instructions. Additionally, the attachments address specific areas where agencies requested
additional guidance. This new guidance combines and therefore replaces the earlier memoranda.
This guidance has a three part focus on: 1) agency progress in remediating the security weaknesses identified in
FY01; 2) the results of FY02 agency reviews and IG evaluations; and 3) specific performance measures for agency
officials accountable for information and IT security. OMB’s FY02 report to Congress will be based largely on the
information agencies report according to these three areas. It will also measure progress against the performance
baseline established in last year’s security report.
To ensure that agencies’ work is optimized, OMB has taken steps to incorporate their work into the budget process.
Agency corrective action plans link a system with a security weakness to the budget justification for that system.
This link gives the agency and OMB a system’s level of security performance against the funding request for that
system. This information will help to improve and prioritize budget decisions.
Additionally, OMB is evaluating agency information and information security in the President’s Management
Agenda Scorecard under the electronic government score. Agencies’ corrective action plans and quarterly updates
on progress implementing their plans will be the basis for OMB’s assessment of agencies’ information and IT
security for the Scorecard. Agencies will be assessed on the basis of progress at both the Department level and by
major operating divisions or bureaus. This step will further reinforce the roles and responsibilities of agency
program officials (bureau or division heads) for the security of systems that support their programs and the agency
Chief Information Officer (CIO) for the security of their systems and the agency-wide security program. It will also
increase accountability and improve the security of the agency’s operations and assets.
Please find enclosed with this memorandum the following: 1) Attachment A, updated reporting instructions; 2)
Attachment B, updated guidance on developing, submitting, and maintaining security corrective action plans; and 3)
Attachment C, a list of common definitions referenced in the OMB guidance.
123
Instructions for Reporting
th
Agency Security Act reports are due to OMB on September 16 , 2002. Agency heads should transmit to OMB: 1)
the executive summary, developed by the agency CIO, agency program officials, and the IG that is based on the
results of their work; 2) copies of the IG’s independent evaluations; and 3) for national security systems, audits of
the independent evaluations. Your CIO and IG will receive an electronic copy of this guidance and templates to
assist them in reporting. Agency executive summaries will serve as the primary basis for OMB’s summary report to
Congress.
M-02-01 - Guidance for Preparing and Submitting Security Plans of Action and Milestones
On June 22, 2001, I issued a memorandum on "Reporting Instructions for the Government
Information Security Reform Act" (OMB M-01-24). In the memorandum, OMB asked each
agency to submit, with its September budget request, a set of program reviews and evaluations of
both unclassified and classified systems, along with an executive summary. In addition, OMB
asked each agency to submit to OMB by October 31, 2001, (with brief quarterly updates
thereafter) "a plan of action with milestones" to address all weaknesses identified by program
reviews and evaluations.
In response to the June 22nd memorandum, several agencies have asked OMB to issue more
detailed guidance that further describes, and provides a standard format for, the information that
agencies should include in their plans of action and milestones (POA&M). Working with
representatives of agency program offices and Inspector General offices, OMB has developed
the attached POA&M guidance, which provides specific instructions and examples for the
POA&Ms. The first POA&M is due by October 31st, but please notify us if you will need more
time. At a minimum, POA&Ms must address the reporting elements found in the attached
guidance. Agency Chief Information Officers, working with program officials, budget officers,
Inspectors General, and other appropriate agency officials, are responsible for developing a
POA&M for each program and system for which a weakness was identified during the annual
program review and independent evaluations required by the Government Information Security
Reform Act.
Additionally, the POA&Ms should either reflect consolidation with or be accompanied by other
agency plans to correct security weaknesses found during any other review done by, for, or on
behalf of the agency, including GAO audits, financial system audits, and critical infrastructure
vulnerability assessments. Thus, the submission of these POA&Ms includes, but does not
necessarily replace, all security remediation plans that an agency might have. By reflecting the
enterprise security needs of an agency, a consolidated POA&M provides a roadmap for
continuous agency security improvement, assists with prioritizing corrective action and resource
allocation, and is a valuable management and oversight tool for agency officials, Inspectors
General, and OMB.
The attachments provide specific instructions and examples for the POA&Ms.
124
M-01-05 - Guidance on Inter-Agency Sharing of Personal Data - Protecting Personal Privacy
OMB is issuing guidance to remind agencies of several privacy-related legal requirements that
apply to computer matching and to clarify how agencies should conduct computer matching
activities. This guidance applies to data matching activities or programs for purposes of
establishing or verifying eligibility for Federal benefit programs or recouping payments or
delinquent debts under such programs covered by the Computer Matching and Privacy
Protection Act ("Matching Act"),(1) an amendment to the Privacy Act of 1974, 5 U.S.C. Section
552a, whether data are shared between Federal agencies or matched with State agency data.(2)
Although this guidance applies directly only to programs covered by the Matching Act, agencies
should consider applying these principles in other data sharing contexts.
Inter-agency sharing of information about individuals can be an important tool in improving the
efficiency of government programs. By sharing data, agencies can often reduce errors, improve
program efficiency, identify and prevent fraud, find intended beneficiaries, evaluate program
performance, and reduce information collection burden on the public.
As government increasingly moves to electronic collection and dissemination of data, under the
Government Paperwork Elimination Act and other programs, opportunities to share data across
agencies will likely increase. Agencies should work together to determine what data sharing
opportunities are desirable, feasible, and appropriate. In general, data sharing should only be
pursued if the benefits outweigh the costs.
With increased focus on data sharing, agencies must pay close attention to handling responsibly
their own data and the data they share with or receive from other agencies. When information
about individuals is involved, agencies must pay especially close attention to privacy interests
and must incorporate measures to safeguard those interests. Prior to any data sharing, agencies
must review and meet the Privacy Act requirements for computer matching, including
developing a computer matching agreement and publishing notice of the proposed match in the
Federal Register; OMB Guidance on Computer Matching (54 Fed. Reg. 25818, June 19, 1989);
and OMB Circular A-130, Appendix I, "Federal Agency Responsibilities for Maintaining
Records About Individuals." Agencies must also review and meet applicable requirements under
other laws, including the Paperwork Reduction Act of 1995.
The attached memorandum puts forth principles on protecting personal privacy when conducting
inter-agency data sharing. Agencies themselves, as well as inter-agency work groups, such as the
Chief Financial Officers (CFO) Council, the Chief Information Officers (CIO) Council, the
President's Council on Integrity and Efficiency, the Procurement Executives Council (PEC), and
the Human Resources Management Council (HRMC) should ensure that they adhere to the
principles.
125
M-00-13 - Privacy Policies and Data Collection on Federal Web Sites
The purpose of this memorandum is to remind you that each agency is required by law and
policy to establish clear privacy policies for its web activities and to comply with those policies.
Agency contractors should also comply with those policies when operating web sites on behalf
of agencies.
As described in my memorandum of June 2, 1999, on "Privacy Policies on Federal Web Sites,"
agencies are to post clear privacy policies on agency principal web sites, as well as at any other
known, major entry points to sites, and at any web page where substantial amounts of personal
information are posted. Privacy policies must be clearly labeled and easily accessed when
someone visits a web site.
Agencies must take care to ensure full adherence with stated privacy policies. For example, if an
agency web site states that the information provided will not be available to any other entities, it
is the responsibility of the agency to assure that no such sharing takes place. To ensure such
adherence, each agency should immediately review its compliance with its stated web privacy
policies.
Particular privacy concerns may be raised when uses of web technology can track the activities
of users over time and across different web sites. These concerns are especially great where
individuals who have come to government web sites do not have clear and conspicuous notice of
any such tracking activities. "Cookies" -- small bits of software that are placed on a web user's
hard drive -- are a principal example of current web technology that can be used in this way. The
guidance issued on June 2, 1999, provided that agencies could only use "cookies" or other
automatic means of collecting information if they gave clear notice of those activities.
Because of the unique laws and traditions about government access to citizens' personal
information, the presumption should be that "cookies" will not be used at Federal web sites.
Under this new Federal policy, "cookies" should not be used at Federal web sites, or by
contractors when operating web sites on behalf of agencies, unless, in addition to clear and
conspicuous notice, the following conditions are met: a compelling need to gather the data on the
site; appropriate and publicly disclosed privacy safeguards for handling of information derived
from "cookies"; and personal approval by the head of the agency. In addition, it is federal policy
that all Federal web sites and contractors when operating on behalf of agencies shall comply with
the standards set forth in the Children's Online Privacy Protection Act of 1998 with respect to the
collection of personal information online at web sites directed to children.
A description of your privacy practices and the steps taken to ensure compliance with this
memorandum should be included as part of the submission on information technology that is
incorporated into the agency budget submission this fall.
126
M-00-10 - OMB Procedures and Guidance on Implementing the Government Paperwork Elimination
Act
This document provides Executive agencies with the guidance required under Sections 1703 and
1705 the Government Paperwork Elimination Act (GPEA), P. L. 105-277, Title XVII. GPEA
requires agencies, by October 21, 2003, to provide for the (1) option of electronic maintenance,
submission, or disclosure of information, when practicable as a substitute for paper; and (2) use
and acceptance of electronic signatures, when practicable. GPEA specifically states that
electronic records and their related electronic signatures are not to be denied legal effect,
validity, or enforceability merely because they are in electronic form.
GPEA is an important tool in fulfilling the vision of improved customer service and
governmental efficiency through the use of information technology. This vision contemplates
widespread use of the Internet and its World Wide Web, with Federal agencies transacting
business electronically as commercial enterprises are doing. Members of the public who wish to
do business this way may avoid traveling to government offices, waiting in line, or mailing paper
forms. The Federal government can also save time and money transacting business
electronically.
This guidance also implements part of the President's memorandum of December 17, 1999,
"Electronic Government," which calls on Federal agencies to use information technology in
ensuring that governmental services and information are easily accessible to the American
people. Among other things, the President charged the Administrator of General Services, in
coordination with appropriate agencies and organizations, to assist agencies in developing
private, secure, and effective communication across agencies and with the public through the use
of digital signature technology.
Creating more accessible and efficient government requires public confidence in the security of
the government's electronic information communication and information technology systems.
Electronic commerce, electronic mail, and electronic benefits transfer can involve the exchange
of sensitive information within government, between government and private industry or
individuals, and among governments. Electronic systems must be able to protect the
confidentially of citizens' information, authenticate the identity of the transacting parties to the
degree required by the transaction, guarantee that the information is not altered in an
unauthorized way, and provide access when needed.
To reach these goals, agencies must meet objectives outlined by GPEA guidance. First, each
agency must build on their existing efforts to implement electronic government by developing a
plan and schedule that implement, by the end of Fiscal Year 2003, optional electronic
maintenance, submission, or transactions of information, when practicable as a substitute for
paper, including through the use of electronic signatures when practicable. Agencies must submit
a copy of the plan to OMB by October 2000 and coordinate the plan and schedule with their
strategic IT planning activities that support program responsibilities consistent with the budget
process (as required by OMB Circular A-11).
127
M-00-07 - Incorporating and Funding Security in Information Systems Investments
This memorandum reminds agencies of the Office of Management and Budget's (OMB) principles for
incorporating and funding security as part of agency information technology systems and architectures
and of the decision criteria that will be used to evaluate security for information systems investments. The
principles and decision criteria are designed to highlight our existing policy and thereby foster improved
compliance with existing security obligations; this memorandum does not constitute new security policy.
OMB plans to use the principles as part of the FY 2002 budget process to determine whether an agency's
information systems investments include adequate security plans.
Protecting the information and systems that the Federal government depends on is important as agencies
increasingly rely on new technology. Agencies are working to preserve the integrity, reliability,
availability, and confidentiality of important information while maintaining their information systems.
The most effective way to protect information and systems is to incorporate security into the architecture
of each. This approach ensures that security supports agency business operations, thus facilitating those
operations, and that plans to fund and manage security are built into life-cycle budgets for information
systems.
This memorandum is written pursuant to the Information Technology Management Reform Act (the
Clinger-Cohen Act) which directs OMB to develop, as part of the budget process, a mechanism to
analyze, track, and evaluate the risks and results of major capital investments made by an executive
agency for information systems. Additionally, the Clinger-Cohen Act calls for OMB to issue clear and
concise direction to ensure that the information security policies, processes, and practices of the agencies
are adequate. These criteria will be incorporated into future revisions of OMB Circular A-130
("Management of Federal Information Resources") and should be used in conjunction with previous
OMB guidance on sound capital planning and investment control in OMB Memorandum 97-02, "Funding
Information Systems Investments"; OMB Memorandum 97-16, "Information Technology Architectures";
and subsequent updates.
Security programs and controls implemented under this memorandum should be consistent with the
Computer Security Act, the Paperwork Reduction Act, the Clinger-Cohen Act, and OMB Circular A-130.
They should also be consistent with security guidance issued by the National Institute of Standards and
Technology (NIST). Security controls for national security telecommunications and information systems
should be implemented in accordance with appropriate national security directives.
Principles
The principles outlined below will support more effective agency implementation of both agency
computer security and critical information infrastructure protection programs. In terms of Federal
information systems, critical infrastructure protection starts with an effort to prioritize key systems (e.g.,
those that are most critical to agency operations). Once systems are prioritized, agencies apply OMB
128
policies and, for non-national security applications, NIST guidance to achieve adequate security
commensurate with the level of risk and magnitude of likely harm.
Agencies should develop security programs and incorporate security and privacy into information systems
with attention to the following principles:






Effective security is an essential element of all information systems.
Effective privacy protections are essential to all information systems, especially those that contain
substantial amounts of personally identifiable information. The use of new information
technologies should sustain, and not erode, the privacy protections provided in all statutes and
policies relating to the collection, use, and disclosure of personal information.
The increase in efficiency and effectiveness that flows from the use of interconnected computers
and networks has been accompanied by increased risks and potential magnitude of loss. The
protection of Federal computer resources must be commensurate with the risk of harm resulting
from any misuse or unauthorized access to such systems and the information flowing through
them.
Security risks and incidents must be managed in a way that complements and does not
unnecessarily impede agency business operations. By understanding risks and implementing an
appropriate level of cost-effective controls, agencies can reduce risk and potential loss
significantly.
A strategy to manage security is essential. Such a strategy should be based on an ongoing cycle of
risk management and should be developed in coordination with and implemented by agency
program officials. It should identify significant risks, clearly establish responsibility for reducing
them, and ensure that risk management remains effective over time.
Agency program officials must understand the risk to systems under their control and determine
the acceptable level of risk, ensure that adequate security is maintained to support and assist the
programs under their control, and ensure that security controls comport with program needs and
appropriately accommodate operational necessities. In addition, program officials should work in
conjunction with Chief Information Officers and other appropriate agency officials so that
security measures support agency information architectures.
Policy
Security should be built into and funded as part of the system architecture. Agencies should make
security's role explicit in information technology investments and capital programming. These actions are
entirely consistent with and build upon the principles outlined in OMB Memorandum 97-02.
Accordingly, investments in the development of new or the continued operation of existing information
systems, both general support systems and major applications, proposed for funding in the President's
budget must:
1. Be tied to the agency's information architecture. Proposals should demonstrate that the security
controls for components, applications, and systems are consistent with and an integral part of the
information technology architecture of the agency.
2. Be well-planned, by:
129
a) Demonstrating that the costs of security controls are understood and are explicitly incorporated
in the life-cycle planning of the overall system in a manner consistent with OMB guidance for
capital programming.
b) Incorporating a security plan that discusses:







the rules of behavior for the system and the consequences for violating those rules;
personnel and technical controls for the system;
methods for identifying, appropriately limiting, and controlling interconnections with
other systems and specific ways such limits will be monitored and managed;
procedures for the on-going training of individuals that are permitted access to the
system;
procedures for the on-going monitoring of the effectiveness of security controls;
procedures for reporting and sharing with appropriate agency and government authorities
indications of attempted and successful intrusions into agency systems;
provisions for the continuity of support in the event of system disruption or failure.
3. Manage risks, by:
a) Demonstrating specific methods used to ensure that risks and the potential for loss are
understood and continually assessed, that steps are taken to maintain risk at an acceptable level,
and that procedures are in place to ensure that controls are implemented effectively and remain
effective over time.
b) Demonstrating specific methods used to ensure that the security controls are commensurate
with the risk and magnitude of harm that may result from the loss, misuse, or unauthorized access
to or modification of the system itself or the information it manages.
c) Identifying additional security controls that are necessary to minimize risks to and potential
loss from those systems that promote or permit public access, other externally accessible systems,
and those systems that are interconnected with systems over which program officials have little or
no control.
4. Protect privacy and confidentiality, by:
a) Deploying effective security controls and authentication tools consistent with the protection of
privacy, such as public-key based digital signatures, for those systems that promote or permit
public access.
b) Ensuring that the handling of personal information is consistent with relevant governmentwide and agency policies, such as privacy statements on the agency's web sites.
5. Account for departures from NIST Guidance. For non-national security applications, to ensure the
use of risk-based cost-effective security controls, describe each occasion when employing standards and
guidance that are more stringent than those promulgated by the National Institute for Standards and
Technology.
In general, OMB will consider new or continued funding only for those system investments that satisfy
these criteria and will consider funding information technology investments only upon demonstration that
existing agency systems meet these criteria. Agencies should begin now to identify any existing systems
130
that do not meet these decision criteria. They should then work with their OMB representatives to arrive
at a reasonable process and timetable to bring such systems into compliance. Agencies should begin with
externally accessible systems and those interconnected systems that are critical to agency operations.
OMB staff are available to work with you if you or your staff have questions or need further assistance in
meeting these requirements.
M-00-01 - Day One Planning and Request for Updated Business Continuity and Contingency
Plans
It is important that we plan and prepare for the end of December and early January to help
mitigate any problems that may arise. Day One plans, which describe agency planned activities
during the pre-rollover and post-rollover periods, are an essential part of your business continuity
and contingency plans (BCCPs). They should address the full scope of agency activity that will
be underway during that period. That includes efforts to mitigate the impact of possible failures
in internal systems, buildings or other infrastructure. It also includes efforts to assess the impact
of the problem on agency partners in delivering Federal programs and agency constituencies, and
to provide appropriate assistance to them.
Many of you already have well-developed Day One plans, while others are still in the early
stages of planning. To help speed the development of plans, this week the General Accounting
Office issued guidance entitled, "Y2K Computing Challenge: Day One Planning and Operations
Guide." Please consider this guidance carefully. In particular, please assure that your plans
include the following seven elements:
1. Schedule of activity. The schedule should outline the activities that will take place
before, during and after the rollover from December 31 to January 1. It should include,
for example, when various checks to find problems should be made. There should also be
triggers for when contingencies included in your BCCP and Continuity of Operations
Plans (COOP) will be invoked.
2. Personnel on call or on duty. You should decide who must be on-duty or on call to
support the agency’s activities and when they will need to be available. Examples of the
kinds of expertise that may need to be available include building technicians, computer
programmers, telecommunications experts, program staff, contracting officers, legal
counsel, public affairs staff, and senior management.
3. Contractor availability. Assure that your contractors are prepared to provide you with
needed assistance. If your contractor will be serving multiple clients, coordinate with the
contractor and other clients to set priorities for assistance.
4. Communications with your workforce. Assure that you will have the ability to
communicate within your agency, with your agency’s workforce, with contractors, with
partners in program delivery, and with your constituency as appropriate. Also assure that
131
you will be able to communicate externally with the Information Coordination Center
(ICC). Communications is of such importance that communications contingency plans
should be in place.
5. Facilities and services to support your workforce. Assure that buildings,
telecommunications, transportation (including parking), food services, and other
infrastructure needed to support your workforce will be available during the roll-over
period.
6. Security. Assure that special security measures are taken to address vulnerabilities
created by events during the roll-over period. In particular, there is concern about the
vulnerability of systems to malicious intrusion during the roll-over period.
7. Communications with the public. Provide a capability, whether internally or through
the Information Coordination Center (ICC), to communicate with the public about the
impact of the problem on your agency, your agency’s programs, and your agency’s
constituencies. The information being presented should be coordinated with other
involved agencies and the ICC to ensure its accuracy.
M-99-20 - Security of Federal Automated Information Resources
SUBJECT: Security of Federal Automated Information Resources
A number of agencies have recently experienced the intentional disruption of their Internet
website operations. The impact of these disruptions has ranged from minor nuisance to
significant interruption of service.
The purpose of this memorandum is to remind agencies that, consistent with the principles
embodied in OMB Circular A-130, Appendix III, "Security of Federal Automated Information
Resources," they must continually assess the risk to their computer systems and maintain
adequate security commensurate with that risk. Therefore, as soon as practicable, please conduct
a review of your security practices to ensure that you have in place a process that permits
program officials and security managers to understand the risk to agency systems and take
necessary steps to mitigate it. This process should include specific procedures to ensure the
timely implementation of security patches for known vulnerabilities, especially for those systems
that are accessible via the Internet. Installing such patches is a proven way of avoiding
disruptions to systems. Please report back to me within 90 days on your agency's process along
with the name of the official responsible for its implementation.
There are a number of security resources available to assist agencies in meeting their security
responsibilities. Under the Computer Security Act of 1987, the National Institute of Standards
and Technology (NIST) is responsible for issuing specific guidance to agencies regarding
security controls for unclassified systems. A complete collection of that guidance, may be found
at NIST's Computer Security Resources Clearinghouse website (http://csrc.nist.gov). Among
other issuances, NIST's Information Technology Laboratory (ITL) produces a periodic bulletin
132
that provides up-to- date, thoroughly researched information on significant security issues. The
subject of the May 1999 bulletin is especially timely -- computer attacks and prevention
measures.
An important security resource for agencies maintaining externally accessible systems is GSA's
Federal Incident Response Capability (FedCIRC). FedCIRC issues security advisories and offers
free baseline services such as incident response and other, fee-based services such as on-site
recovery and audit trail analysis. Additional information on FedCIRC's activities is available at
their website (http://www.fedcirc.gov).
To assist agencies in complying with Circular A-130, Appendix III, I encourage each agency to
avail themselves of NIST's and GSA's expertise in this important area and ensure that the ITL
Bulletin and GSA's advisories are widely distributed throughout each agency and recommended
actions are pursued as appropriate.
M-99-18 - Privacy Policies on Federal Web Sites
This memorandum directs Departments and Agencies to post clear privacy policies on World
Wide Web sites, and provides guidance for doing so. As a first priority, you must post privacy
policies to your Department or Agency's principal web site by September 1, 1999. By December
1, 1999, add privacy policies to any other known, major entry points to your sites as well as at
any web page where you collect substantial personal information from the public. Each policy
must clearly and concisely inform visitors to the site what information the agency collects about
individuals, why the agency collects it, and how the agency will use it. Privacy policies must be
clearly labeled and easily accessed when someone visits a web site.
Federal agencies must protect an individual's right to privacy when they collect personal
information. This is required by the Privacy Act, 5 U.S.C. 552a, and OMB Circular No. A-130,
"Management of Federal Information Resources," 61 Fed. Reg. 6428 (Feb. 20, 1996), and
supported by the Principles for Providing and Using Personal Information published by the
Information Infrastructure Task Force on June 6, 1995. Posting a privacy policy helps ensure that
individuals have notice and choice about, and thus confidence in, how their personal information
is handled when they use the Internet.
New information technologies offer exciting possibilities for improving the quality and
efficiency of government service to the American people. Web sites are a powerful tool for
conveying information on topics relating to activities, objectives, policies and programs of the
Federal Government. Web pages provide a simple and speedy means of gaining access to
information about the Government, thereby increasing knowledge and understanding of what
Government is doing on the people's behalf. Looking ahead, as contemplated for instance by the
Government Paperwork Elimination Act, people will conduct more and more business and other
activities with the Government electronically. We cannot realize the full potential of the web
until people are confident we protect their privacy when they visit our sites.
133
To assist Departments and Agencies in reviewing their existing privacy policy or in creating such
a policy, I have attached guidance and model privacy language for several different information
practices that may apply to your web sites. You can use the model language verbatim, or as a
starting point in crafting a policy tailored to meet your own requirements and needs.
M-99-16 - Business Continuity and Contingency Planning for the Year 2000
As we complete the work of fixing the Year 2000 computer problem in Federal systems, we
must turn our attention to assuring that our organizations will function smoothly through the
Year 2000 transition. That involves both work we continue to do to prevent Year 2000 problems
from occurring as well making preparations in advance for problems that could affect our
organizations. On March 26, I asked that you work with other Federal agencies, State and Local
governments, and others to assure that high impact programs will operate smoothly through the
Year 2000. I now ask that we work together to prepare and share our business continuity and
contingency plans (BCCPs) for addressing problems that may occur.
Many of you already have such planning well underway. Others may be in the early stages of
planning. If your agency is identified in the attachment, please provide a copy of your high-level
plan to OMB no later than June 15, 1999. The plan should be written from headquarter’s
perspective and should describe the agency’s overall strategy and process for ensuring readiness
of key programs and functions across the agency, rather than provide information on specific
systems. This high level plan, like your agency-wide BCCP, should follow the guidance
contained in the GAO publication, "Year 2000 Computing Crisis: Business Continuity and
Contingency Planning" (August 1998).
I am requesting this information to facilitate the coordination of these activities across agencies,
to help ensure that we are all addressing the many risks presented by the Year 2000 problem and,
where appropriate, using comparable assumptions in developing our plans. While I am asking for
plans as of June 15, I anticipate that development and testing of these plans will be an on-going
process for the remainder of the year as more information is known about what is likely to occur
in January and as we learn from testing the plans.
Consistent with information about the likely impact of Year 2000 released earlier this month by
the President’s Council on Year 2000 Conversion, we identified a number of risk areas for which
agencies should make common assumptions. We expect that agencies will assume for purposes
of preparing their business continuity and contingency plans that electric power, natural gas,
water service, waste treatment, financial services, transportation, public voice and data
communications, the Internet, mail service, and the mass media will be available domestically,
although it is possible that there will be localized disruptions in some areas. Each regional and
field office should work closely with their local providers to assure that these assumptions are
true for their local planning. Internationally, the State Department, in cooperation with other
agencies, is gathering information on a country-specific basis. The State Department has
designated the Head of Mission in each country to be the U.S. lead on Y2K issues there, and
134
agencies with interests overseas should work with the State Department to understand the risks to
their operations and to develop appropriate assumptions.
In addition, a number of other risks to Federal organizations have been identified that should be
addressed in individual agency plans. These risks include possible problems in internal systems,
the potential problems in commercial products, readiness of suppliers, readiness of those with
whom data is exchanged, and the level of awareness of and reaction by an agency’s constituency.
We expect that each agency’s BCCP will address these risks and will follow GAO’s guidance in
managing against them.
135
3. OMB Circulars
Office of Management and Budget Circular A-130, Appendix III, Security of Federal Information
Resources
From Wikipedia, the free encyclopedia
OMB Circular A-130, titled Management of Federal Information Resources, is one of many Government
circulars produced by the United States Federal Government to establish policy for executive branch
departments and agencies.
Circular A-130 was first issued in December of 1985 to meet information resource management
requirements that were included in the Paperwork Reduction Act (PRA) of 1980. Specifically, the PRA
assigned responsibility to the OMB Director to develop and maintain a comprehensive set of information
resources management policies for use across the Federal government, and to promote the application of
information technology to improve the use and dissemination of information in the operation of Federal
programs. [1] The initial release of the Circular provided a policy framework for information resources
management (IRM) across the Federal government.
Since the time of the Circular's first release in 1985, Congress has enacted several additional laws and
OMB issued several guidance documents that related to information technology management in federal
agencies. To account for these new laws and guidance, OMB has revised the Circular three times, in
1994,[2] 1996,[3] and 2000.[4]. A complete rewrite of the Circular to both update and to correct for known
deficiencies has been considered since at least 2005,[5] but as of February 2010, this rewrite has not yet
occurred.
As aptly expressed in the CIO Council's Architecture Alignment and Assessment Guide (2000), Circular
A-130 can be thought of as a "...one-stop shopping document for OMB policy and guidance on
information technology management"
Specific Guidance
A-130 includes specific guidelines that require






all federal information systems to have security plans
systems to have formal emergency response capabilities
a single individual to have responsibility for operational security
Federal Management and Fiscal Integrity Act reports to Congress be made in regards to the
security of the system
security awareness training be available to all government users, administrators of the system
regular review and improvement upon contingency plans for the system to be done
Federal DAA Involvement
The Federal Designated Approving Authority has specific requirements and responsibilities provided by
this circular. It is required that this individual should be a management official, knowledgeable in the
information and processes supported by the system. The individual should also know the management,
personnel, operational, and technical controls used in the protection of this system.
136
The Federal DAA is also responsible for the security of this system as well as the use of the security
products and techniques used therein.
Any information that the information system uses that is classified automatically requires the system to
have National security emergency preparedness guidelines that conform to Executive Order 12472.
Executive Office of the President, Office of Management and Budget, Office of Federal Procurement
Policy, Emergency Acquisitions, May 2007
The guide is designed to help agencies prepare the acquisition workforce for emergencies. The
guide describes strategies for effective response planning and provides a list of acquisition reminders
when contracting during emergencies. The guide also discusses flexibilities that acquisition personnel
deployed to an emergency situation may use to facilitate timely procurements.
The guide includes a number of management and operational best practices that agencies
developed in response to Hurricane Katrina and other emergency situations. These practices should be
considered in planning related to contingency operations, anti-terrorism activities, and national
emergencies.
This guide is intended to supplement, not supplant, agency-specific guidance, and should be read
in conjunction with Part 18 of the Federal Acquisition Regulation on emergency acquisitions. The guide
will be maintained electronically and updated, as needed, on the OFPP Web site,
http://www.whitehouse.gov/omb/procurement/
This document supersedes OFPP’s Emergency Procurement Flexibilities guide, issued in May
2003.
This guide is designed to help ensure the acquisition workforce is prepared for emergencies. Each
emergency evolves differently. Contractors play a critical role in providing supplies and services to our
citizens during an emergency. Viable readiness plans and personnel trained in emergency contracting
procedures will help to optimize the government’s responsiveness during an emergency situation. This
document highlights policies and practices to improve the agility of the acquisition workforce during
these critical situations. It reflects a number of management and operational best practices that agencies
have developed in response to Hurricane Katrina, the Iraqi reconstruction effort, and other emergency
situations. It also reflects a number of lessons documented by the Special Inspector General for Iraq
Reconstruction (SIGIR) and the Government Accountability Office (GAO).1
The guide is presented in three parts.
• Part I discusses organizational and individual response planning efforts agencies should
undertake to improve responsiveness during an emergency.
• Part II provides a list of reminders for agencies to consider when awarding and administering
contracts during emergencies.
• Part III reviews the flexibilities that are available to agencies for use during emergencies.
This guide, developed jointly by the Office of Federal Procurement Policy (OFPP) and the Chief
Acquisition Officers Council’s working group on emergency contracting is not all-inclusive and is
intended to supplement, not supplant, agency-specific guidance. It should be read in conjunction with Part
18 of the Federal Acquisition Regulation (FAR) on emergency acquisitions. This document supersedes
OFPP’s Emergency Procurement Flexibilities guide, issued in May, 2003.
137
4. Homeland Security President Directives
HSPD-3 – Homeland Security Advisory System
Abstract: Homeland Security Presidential Directive 3 creates a Homeland Security Advisory System to
inform all levels of government and local authority, as well as the public, to the current risk of terrorist
acts. The System involves a five-level, color-coded Threat Condition indicator to correspond to the
current situation. Agency-specific Protective Measures associated with each Threat Condition will allow a
flexible, graduated and appropriate response to a change in the nation’s level of risk.
March 11, 2002
SUBJECT: Homeland Security Advisory System
Purpose
The Nation requires a Homeland Security Advisory System to provide a comprehensive and effective
means to disseminate information regarding the risk of terrorist acts to Federal, State, and local authorities
and to the American people. Such a system would provide warnings in the form of a set of graduated
"Threat Conditions" that would increase as the risk of the threat increases. At each Threat Condition,
Federal departments and agencies would implement a corresponding set of "Protective Measures" to
further reduce vulnerability or increase response capability during a period of heightened alert.
This system is intended to create a common vocabulary, context, and structure for an ongoing national
discussion about the nature of the threats that confront the homeland and the appropriate measures that
should be taken in response. It seeks to inform and facilitate decisions appropriate to different levels of
government and to private citizens at home and at work.
Homeland Security Advisory System
The Homeland Security Advisory System shall be binding on the executive branch and suggested,
although voluntary, to other levels of government and the private sector. There are five Threat Conditions,
each identified by a description and corresponding color. From lowest to highest, the levels and colors
are:
Low
=
Guarded =
Elevated =
High
=
Severe =
Green
Blue
Yellow
Orange
Red
The higher the Threat Condition, the greater the risk of a terrorist attack. Risk includes both the
probability of an attack occurring and its potential gravity. Threat Conditions shall be assigned by the
Attorney General in consultation with the Assistant to the President for Homeland Security. Except in
exigent circumstances, the Attorney General shall seek the views of the appropriate Homeland Security
Principals or their subordinates, and other parties as appropriate, on the Threat Condition to be assigned.
Threat Conditions may be assigned for the entire Nation, or they may be set for a particular geographic
area or industrial sector. Assigned Threat Conditions shall be reviewed at regular intervals to determine
whether adjustments are warranted.
138
For facilities, personnel, and operations inside the territorial United States, all Federal departments,
agencies, and offices other than military facilities shall conform their existing threat advisory systems to
this system and henceforth administer their systems consistent with the determination of the Attorney
General with regard to the Threat Condition in effect.
The assignment of a Threat Condition shall prompt the implementation of an appropriate set of Protective
Measures. Protective Measures are the specific steps an organization shall take to reduce its vulnerability
or increase its ability to respond during a period of heightened alert. The authority to craft and implement
Protective Measures rests with the Federal departments and agencies. It is recognized that departments
and agencies may have several preplanned sets of responses to a particular Threat Condition to facilitate a
rapid, appropriate, and tailored response. Department and agency heads are responsible for developing
their own Protective Measures and other antiterrorism or self-protection and continuity plans, and
resourcing, rehearsing, documenting, and maintaining these plans. Likewise, they retain the authority to
respond, as necessary, to risks, threats, incidents, or events at facilities within the specific jurisdiction of
their department or agency, and, as authorized by law, to direct agencies and industries to implement their
own Protective Measures. They shall continue to be responsible for taking all appropriate proactive steps
to reduce the vulnerability of their personnel and facilities to terrorist attack. Federal department and
agency heads shall submit an annual written report to the President, through the Assistant to the President
for Homeland Security, describing the steps they have taken to develop and implement appropriate
Protective Measures for each Threat Condition. Governors, mayors, and the leaders of other organizations
are encouraged to conduct a similar review of their organizations= Protective Measures.
The decision whether to publicly announce Threat Conditions shall be made on a case-by-case basis by
the Attorney General in consultation with the Assistant to the President for Homeland Security. Every
effort shall be made to share as much information regarding the threat as possible, consistent with the
safety of the Nation. The Attorney General shall ensure, consistent with the safety of the Nation, that
State and local government officials and law enforcement authorities are provided the most relevant and
timely information. The Attorney General shall be responsible for identifying any other information
developed in the threat assessment process that would be useful to State and local officials and others and
conveying it to them as permitted consistent with the constraints of classification. The Attorney General
shall establish a process and a system for conveying relevant information to Federal, State, and local
government officials, law enforcement authorities, and the private sector expeditiously.
The Director of Central Intelligence and the Attorney General shall ensure that a continuous and timely
flow of integrated threat assessments and reports is provided to the President, the Vice President,
Assistant to the President and Chief of Staff, the Assistant to the President for Homeland Security, and the
Assistant to the President for National Security Affairs. Whenever possible and practicable, these
integrated threat assessments and reports shall be reviewed and commented upon by the wider
interagency community.
A decision on which Threat Condition to assign shall integrate a variety of considerations. This
integration will rely on qualitative assessment, not quantitative calculation. Higher Threat Conditions
indicate greater risk of a terrorist act, with risk including both probability and gravity. Despite best
efforts, there can be no guarantee that, at any given Threat Condition, a terrorist attack will not occur. An
initial and important factor is the quality of the threat information itself. The evaluation of this threat
information shall include, but not be limited to, the following factors:
1. To what degree is the threat information credible?
2. To what degree is the threat information corroborated?
3. To what degree is the threat specific and/or imminent?
139
4. How grave are the potential consequences of the threat?
Threat Conditions and Associated Protective Measures
The world has changed since September 11, 2001. We remain a Nation at risk to terrorist attacks and will
remain at risk for the foreseeable future. At all Threat Conditions, we must remain vigilant, prepared, and
ready to deter terrorist attacks. The following Threat Conditions each represent an increasing risk of
terrorist attacks. Beneath each Threat Condition are some suggested Protective Measures, recognizing that
the heads of Federal departments and agencies are responsible for developing and implementing
appropriate agency-specific Protective Measures:
1. Low Condition (Green). This condition is declared when there is a low risk of terrorist attacks.
Federal departments and agencies should consider the following general measures in addition to
the agency-specific Protective Measures they develop and implement:
1. Refining and exercising as appropriate preplanned Protective Measures;
2. Ensuring personnel receive proper training on the Homeland Security Advisory System
and specific preplanned department or agency Protective Measures; and
3. Institutionalizing a process to assure that all facilities and regulated sectors are regularly
assessed for vulnerabilities to terrorist attacks, and all reasonable measures are taken to
mitigate these vulnerabilities.
2. Guarded Condition (Blue). This condition is declared when there is a general risk of terrorist
attacks. In addition to the Protective Measures taken in the previous Threat Condition, Federal
departments and agencies should consider the following general measures in addition to the
agency-specific Protective Measures that they will develop and implement:
1. Checking communications with designated emergency response or command locations;
2. Reviewing and updating emergency response procedures; and
3. Providing the public with any information that would strengthen its ability to act
appropriately.
3. Elevated Condition (Yellow). An Elevated Condition is declared when there is a significant risk
of terrorist attacks. In addition to the Protective Measures taken in the previous Threat
Conditions, Federal departments and agencies should consider the following general measures in
addition to the Protective Measures that they will develop and implement:
1. Increasing surveillance of critical locations;
2. Coordinating emergency plans as appropriate with nearby jurisdictions;
3. Assessing whether the precise characteristics of the threat require the further refinement
of preplanned Protective Measures; and
4. Implementing, as appropriate, contingency and emergency response plans.
4. High Condition (Orange). A High Condition is declared when there is a high risk of terrorist
attacks. In addition to the Protective Measures taken in the previous Threat Conditions, Federal
departments and agencies should consider the following general measures in addition to the
agency-specific Protective Measures that they will develop and implement:
1. Coordinating necessary security efforts with Federal, State, and local law enforcement
agencies or any National Guard or other appropriate armed forces organizations;
2. Taking additional precautions at public events and possibly considering alternative
venues or even cancellation;
3. Preparing to execute contingency procedures, such as moving to an alternate site or
dispersing their workforce; and
4. Restricting threatened facility access to essential personnel only.
5. Severe Condition (Red). A Severe Condition reflects a severe risk of terrorist attacks. Under
most circumstances, the Protective Measures for a Severe Condition are not intended to be
140
sustained for substantial periods of time. In addition to the Protective Measures in the previous
Threat Conditions, Federal departments and agencies also should consider the following general
measures in addition to the agency-specific Protective Measures that they will develop and
implement:
1. Increasing or redirecting personnel to address critical emergency needs;
2. Assigning emergency response personnel and pre-positioning and mobilizing specially
trained teams or resources;
3. Monitoring, redirecting, or constraining transportation systems; and
4. Closing public and government facilities.
Comment and Review Periods
The Attorney General, in consultation and coordination with the Assistant to the President for Homeland
Security, shall, for 45 days from the date of this directive, seek the views of government officials at all
levels and of public interest groups and the private sector on the proposed Homeland Security Advisory
System.
One hundred thirty-five days from the date of this directive the Attorney General, after consultation and
coordination with the Assistant to the President for Homeland Security, and having considered the views
received during the comment period, shall recommend to the President in writing proposed refinements to
the Homeland Security Advisory System.
HSPD-5 – Management of Domestic Incidents
Abstract: Homeland Security Presidential Directive 5 serves to enhance the ability of the United States
to manage domestic incidents by establishing a single, comprehensive national incident management
system. This management system is designed to cover the prevention, preparation, response, and recovery
from terrorist attacks, major disasters, and other emergencies. The implementation of such a system
would allow all levels of government throughout the nation to work efficiently and effectively together.
The directive gives further detail on which government officials oversee and have authority for various
parts of the national incident management system, as well making several amendments to various other
HSPDs.
Full Text
March 11, 2002
SUBJECT: Homeland Security Advisory System
Purpose
The Nation requires a Homeland Security Advisory System to provide a comprehensive and effective
means to disseminate information regarding the risk of terrorist acts to Federal, State, and local authorities
and to the American people. Such a system would provide warnings in the form of a set of graduated
"Threat Conditions" that would increase as the risk of the threat increases. At each Threat Condition,
Federal departments and agencies would implement a corresponding set of "Protective Measures" to
further reduce vulnerability or increase response capability during a period of heightened alert.
This system is intended to create a common vocabulary, context, and structure for an ongoing national
discussion about the nature of the threats that confront the homeland and the appropriate measures that
141
should be taken in response. It seeks to inform and facilitate decisions appropriate to different levels of
government and to private citizens at home and at work.
Homeland Security Advisory System
The Homeland Security Advisory System shall be binding on the executive branch and suggested,
although voluntary, to other levels of government and the private sector. There are five Threat Conditions,
each identified by a description and corresponding color. From lowest to highest, the levels and colors
are:
Low
=
Guarded =
Elevated =
High
=
Severe =
Green
Blue
Yellow
Orange
Red
The higher the Threat Condition, the greater the risk of a terrorist attack. Risk includes both the
probability of an attack occurring and its potential gravity. Threat Conditions shall be assigned by the
Attorney General in consultation with the Assistant to the President for Homeland Security. Except in
exigent circumstances, the Attorney General shall seek the views of the appropriate Homeland Security
Principals or their subordinates, and other parties as appropriate, on the Threat Condition to be assigned.
Threat Conditions may be assigned for the entire Nation, or they may be set for a particular geographic
area or industrial sector. Assigned Threat Conditions shall be reviewed at regular intervals to determine
whether adjustments are warranted.
For facilities, personnel, and operations inside the territorial United States, all Federal departments,
agencies, and offices other than military facilities shall conform their existing threat advisory systems to
this system and henceforth administer their systems consistent with the determination of the Attorney
General with regard to the Threat Condition in effect.
The assignment of a Threat Condition shall prompt the implementation of an appropriate set of Protective
Measures. Protective Measures are the specific steps an organization shall take to reduce its vulnerability
or increase its ability to respond during a period of heightened alert. The authority to craft and implement
Protective Measures rests with the Federal departments and agencies. It is recognized that departments
and agencies may have several preplanned sets of responses to a particular Threat Condition to facilitate a
rapid, appropriate, and tailored response. Department and agency heads are respon-sible for developing
their own Protective Measures and other antiterrorism or self-protection and continuity plans, and
resourcing, rehearsing, documenting, and maintaining these plans. Likewise, they retain the authority to
respond, as necessary, to risks, threats, incidents, or events at facilities within the specific jurisdiction of
their department or agency, and, as authorized by law, to direct agencies and industries to implement their
own Protective Measures. They shall continue to be responsible for taking all appropriate proactive steps
to reduce the vulnerability of their personnel and facilities to terrorist attack. Federal department and
agency heads shall submit an annual written report to the President, through the Assistant to the President
for Homeland Security, describing the steps they have taken to develop and implement appropriate
Protective Measures for each Threat Condition. Governors, mayors, and the leaders of other organizations
are encouraged to conduct a similar review of their organizations= Protective Measures.
The decision whether to publicly announce Threat Conditions shall be made on a case-by-case basis by
the Attorney General in consultation with the Assistant to the President for Homeland Security. Every
effort shall be made to share as much information regarding the threat as possible, consistent with the
142
safety of the Nation. The Attorney General shall ensure, consistent with the safety of the Nation, that
State and local government officials and law enforcement authorities are provided the most relevant and
timely information. The Attorney General shall be responsible for identifying any other information
developed in the threat assessment process that would be useful to State and local officials and others and
conveying it to them as permitted consistent with the constraints of classification. The Attorney General
shall establish a process and a system for conveying relevant information to Federal, State, and local
government officials, law enforcement authorities, and the private sector expeditiously.
The Director of Central Intelligence and the Attorney General shall ensure that a continuous and timely
flow of integrated threat assessments and reports is provided to the President, the Vice President,
Assistant to the President and Chief of Staff, the Assistant to the President for Homeland Security, and the
Assistant to the President for National Security Affairs. Whenever possible and practicable, these
integrated threat assessments and reports shall be reviewed and commented upon by the wider
interagency community.
A decision on which Threat Condition to assign shall integrate a variety of considerations. This
integration will rely on qualitative assessment, not quantitative calculation. Higher Threat Conditions
indicate greater risk of a terrorist act, with risk including both probability and gravity. Despite best
efforts, there can be no guarantee that, at any given Threat Condition, a terrorist attack will not occur. An
initial and important factor is the quality of the threat information itself. The evaluation of this threat
information shall include, but not be limited to, the following factors:
1.
2.
3.
4.
To what degree is the threat information credible?
To what degree is the threat information corroborated?
To what degree is the threat specific and/or imminent?
How grave are the potential consequences of the threat?
Threat Conditions and Associated Protective Measures
The world has changed since September 11, 2001. We remain a Nation at risk to terrorist attacks and will
remain at risk for the foreseeable future. At all Threat Conditions, we must remain vigilant, prepared, and
ready to deter terrorist attacks. The following Threat Conditions each represent an increasing risk of
terrorist attacks. Beneath each Threat Condition are some suggested Protective Measures, recognizing that
the heads of Federal departments and agencies are responsible for developing and implementing
appropriate agency-specific Protective Measures:
1. Low Condition (Green). This condition is declared when there is a low risk of terrorist attacks.
Federal departments and agencies should consider the following general measures in addition to
the agency-specific Protective Measures they develop and implement:
1. Refining and exercising as appropriate preplanned Protective Measures;
2. Ensuring personnel receive proper training on the Homeland Security Advisory System
and specific preplanned department or agency Protective Measures; and
3. Institutionalizing a process to assure that all facilities and regulated sectors are regularly
assessed for vulnerabilities to terrorist attacks, and all reasonable measures are taken to
mitigate these vulnerabilities.
2. Guarded Condition (Blue). This condition is declared when there is a general risk of terrorist
attacks. In addition to the Protective Measures taken in the previous Threat Condition, Federal
departments and agencies should consider the following general measures in addition to the
agency-specific Protective Measures that they will develop and implement:
1. Checking communications with designated emergency response or command locations;
143
2. Reviewing and updating emergency response procedures; and
3. Providing the public with any information that would strengthen its ability to act
appropriately.
3. Elevated Condition (Yellow). An Elevated Condition is declared when there is a significant risk
of terrorist attacks. In addition to the Protective Measures taken in the previous Threat
Conditions, Federal departments and agencies should consider the following general measures in
addition to the Protective Measures that they will develop and implement:
1. Increasing surveillance of critical locations;
2. Coordinating emergency plans as appropriate with nearby jurisdictions;
3. Assessing whether the precise characteristics of the threat require the further refinement
of preplanned Protective Measures; and
4. Implementing, as appropriate, contingency and emergency response plans.
4. High Condition (Orange). A High Condition is declared when there is a high risk of terrorist
attacks. In addition to the Protective Measures taken in the previous Threat Conditions, Federal
departments and agencies should consider the following general measures in addition to the
agency-specific Protective Measures that they will develop and implement:
1. Coordinating necessary security efforts with Federal, State, and local law enforcement
agencies or any National Guard or other appropriate armed forces organizations;
2. Taking additional precautions at public events and possibly considering alternative
venues or even cancellation;
3. Preparing to execute contingency procedures, such as moving to an alternate site or
dispersing their workforce; and
4. Restricting threatened facility access to essential personnel only.
5. Severe Condition (Red). A Severe Condition reflects a severe risk of terrorist attacks. Under
most circumstances, the Protective Measures for a Severe Condition are not intended to be
sustained for substantial periods of time. In addition to the Protective Measures in the previous
Threat Conditions, Federal departments and agencies also should consider the following general
measures in addition to the agency-specific Protective Measures that they will develop and
implement:
1. Increasing or redirecting personnel to address critical emergency needs;
2. Assigning emergency response personnel and pre-positioning and mobilizing specially
trained teams or resources;
3. Monitoring, redirecting, or constraining transportation systems; and
4. Closing public and government facilities.
Comment and Review Periods
The Attorney General, in consultation and coordination with the Assistant to the President for Homeland
Security, shall, for 45 days from the date of this directive, seek the views of government officials at all
levels and of public interest groups and the private sector on the proposed Homeland Security Advisory
System.
One hundred thirty-five days from the date of this directive the Attorney General, after consultation and
coordination with the Assistant to the President for Homeland Security, and having considered the views
received during the comment period, shall recommend to the President in writing proposed refinements to
the Homeland Security Advisory System.
144
HSPD-7 – Critical Infrastructure Identification, Prioritization, and Protection
Abstract: Homeland Security Presidential Directive 7 establishes a national policy for Federal
departments and agencies to identify and prioritize critical infrastructure and to protect them from terrorist
attacks. The directive defines relevant terms and delivers 31 policy statements. These policy statements
define what the directive covers and the roles various federal, state, and local agencies will play in
carrying it out.
December 17, 2003
SUBJECT: Critical Infrastructure Identification, Prioritization, and Protection
Purpose
1. This directive establishes a national policy for Federal departments and agencies to identify and
prioritize United States critical infrastructure and key resources and to protect them from terrorist
attacks.
2. Terrorists seek to destroy, incapacitate, or exploit critical infrastructure and key resources across
the United States to threaten national security, cause mass casualties, weaken our economy, and
damage public morale and confidence.
3. America's open and technologically complex society includes a wide array of critical
infrastructure and key resources that are potential terrorist targets. The majority of these are
owned and operated by the private sector and State or local governments. These critical
infrastructures and key resources are both physical and cyber-based and span all sectors of the
economy.
4. Critical infrastructure and key resources provide the essential services that underpin American
society. The Nation possesses numerous key resources, whose exploitation or destruction by
terrorists could cause catastrophic health effects or mass casualties comparable to those from the
use of a weapon of mass destruction, or could profoundly affect our national prestige and morale.
In addition, there is critical infrastructure so vital that its incapacitation, exploitation, or
destruction, through terrorist attack, could have a debilitating effect on security and economic
well-being.
5. While it is not possible to protect or eliminate the vulnerability of all critical infrastructure and
key resources throughout the country, strategic improvements in security can make it more
difficult for attacks to succeed and can lessen the impact of attacks that may occur. In addition to
strategic security enhancements, tactical security improvements can be rapidly implemented to
deter, mitigate, or neutralize potential attacks.
6. In this directive:
a. The term "critical infrastructure" has the meaning given to that term in section 1016(e) of
the USA PATRIOT Act of 2001 (42 U.S.C. 5195c(e)).
b. The term "key resources" has the meaning given that term in section 2(9) of the
Homeland Security Act of 2002 (6 U.S.C. 101(9)).
c. The term "the Department" means the Department of Homeland Security.
d. The term "Federal departments and agencies" means those executive departments
enumerated in 5 U.S.C. 101, and the Department of Homeland Security; independent
establishments as defined by 5 U.S.C. 104(1);Government corporations as defined by 5
U.S.C. 103(1); and the United States Postal Service.
e. The terms "State," and "local government," when used in a geographical sense, have the
same meanings given to those terms in section 2 of the Homeland Security Act of 2002 (6
U.S.C. 101).
145
f. The term "the Secretary" means the Secretary of Homeland Security.
g. The term "Sector-Specific Agency" means a Federal department or agency responsible
for infrastructure protection activities in a designated critical infrastructure sector or key
resources category. Sector-Specific Agencies will conduct their activities under this
directive in accordance with guidance provided by the Secretary.
h. The terms "protect" and "secure" mean reducing the vulnerability of critical infrastructure
or key resources in order to deter, mitigate, or neutralize terrorist attacks.
Policy
7. It is the policy of the United States to enhance the protection of our Nation's critical infrastructure
and key resources against terrorist acts that could:
a. cause catastrophic health effects or mass casualties comparable to those from the use of a
weapon of mass destruction;
b. impair Federal departments and agencies' abilities to perform essential missions, or to
ensure the public's health and safety;
c. undermine State and local government capacities to maintain order and to deliver
minimum essential public services;
d. damage the private sector's capability to ensure the orderly functioning of the economy
and delivery of essential services;
e. have a negative effect on the economy through the cascading disruption of other critical
infrastructure and key resources; or
f. undermine the public's morale and confidence in our national economic and political
institutions.
8. Federal departments and agencies will identify, prioritize, and coordinate the protection of critical
infrastructure and key resources in order to prevent, deter, and mitigate the effects of deliberate
efforts to destroy, incapacitate, or exploit them. Federal departments and agencies will work with
State and local governments and the private sector to accomplish this objective.
9. Federal departments and agencies will ensure that homeland security programs do not diminish
the overall economic security of the United States.
10. Federal departments and agencies will appropriately protect information associated with carrying
out this directive, including handling voluntarily provided information and information that
would facilitate terrorist targeting of critical infrastructure and key resources consistent with the
Homeland Security Act of 2002 and other applicable legal authorities.
11. Federal departments and agencies shall implement this directive in a manner consistent with
applicable provisions of law, including those protecting the rights of United States persons.
Roles and Responsibilities of the Secretary
12. In carrying out the functions assigned in the Homeland Security Act of 2002, the Secretary shall
be responsible for coordinating the overall national effort to enhance the protection of the critical
infrastructure and key resources of the United States. The Secretary shall serve as the principal
Federal official to lead, integrate, and coordinate implementation of efforts among Federal
departments and agencies, State and local governments, and the private sector to protect critical
infrastructure and key resources.
13. Consistent with this directive, the Secretary will identify, prioritize, and coordinate the protection
of critical infrastructure and key resources with an emphasis on critical infrastructure and key
resources that could be exploited to cause catastrophic health effects or mass casualties
comparable to those from the use of a weapon of mass destruction.
146
14. The Secretary will establish uniform policies, approaches, guidelines, and methodologies for
integrating Federal infrastructure protection and risk management activities within and across
sectors along with metrics and criteria for related programs and activities.
15. The Secretary shall coordinate protection activities for each of the following critical infrastructure
sectors: information technology; telecommunications; chemical; transportation systems, including
mass transit, aviation, maritime, ground/surface, and rail and pipeline systems; emergency
services; and postal and shipping. The Department shall coordinate with appropriate departments
and agencies to ensure the protection of other key resources including dams, government
facilities, and commercial facilities. In addition, in its role as overall cross-sector coordinator, the
Department shall also evaluate the need for and coordinate the coverage of additional critical
infrastructure and key resources categories over time, as appropriate.
16. The Secretary will continue to maintain an organization to serve as a focal point for the security
of cyberspace. The organization will facilitate interactions and collaborations between and among
Federal departments and agencies, State and local governments, the private sector, academia and
international organizations. To the extent permitted by law, Federal departments and agencies
with cyber expertise, including but not limited to the Departments of Justice, Commerce, the
Treasury, Defense, Energy, and State, and the Central Intelligence Agency, will collaborate with
and support the organization in accomplishing its mission. The organization's mission includes
analysis, warning, information sharing, vulnerability reduction, mitigation, and aiding national
recovery efforts for critical infrastructure information systems. The organization will support the
Department of Justice and other law enforcement agencies in their continuing missions to
investigate and prosecute threats to and attacks against cyberspace, to the extent permitted by law.
17. The Secretary will work closely with other Federal departments and agencies, State and local
governments, and the private sector in accomplishing the objectives of this directive.
Roles and Responsibilities of Sector-Specific Federal Agencies
18. Recognizing that each infrastructure sector possesses its own unique characteristics and operating
models, there are designated Sector-Specific Agencies, including:
a. Department of Agriculture -- agriculture, food (meat, poultry, egg products);
b. Health and Human Services -- public health, healthcare, and food (other than meat,
poultry, egg products);
c. Environmental Protection Agency -- drinking water and water treatment systems;
d. Department of Energy -- energy, including the production refining, storage, and
distribution of oil and gas, and electric power except for commercial nuclear power
facilities;
e. Department of the Treasury -- banking and finance;
f. Department of the Interior -- national monuments and icons; and
g. Department of Defense -- defense industrial base.
19. In accordance with guidance provided by the Secretary, Sector-Specific Agencies shall:
a. collaborate with all relevant Federal departments and agencies, State and local
governments, and the private sector, including with key persons and entities in their
infrastructure sector;
b. conduct or facilitate vulnerability assessments of the sector; and
c. encourage risk management strategies to protect against and mitigate the effects of
attacks against critical infrastructure and key resources.
20. Nothing in this directive alters, or impedes the ability to carry out, the authorities of the Federal
departments and agencies to perform their responsibilities under law and consistent with
applicable legal authorities and presidential guidance.
147
21. Federal departments and agencies shall cooperate with the Department in implementing this
directive, consistent with the Homeland Security Act of 2002 and other applicable legal
authorities.
Roles and Responsibilities of Other Departments, Agencies, and Offices
22. In addition to the responsibilities given the Department and Sector-Specific Agencies, there are
special functions of various Federal departments and agencies and components of the Executive
Office of the President related to critical infrastructure and key resources protection.
a. The Department of State, in conjunction with the Department, and the Departments of
Justice, Commerce, Defense, the Treasury and other appropriate agencies, will work with
foreign countries and international organizations to strengthen the protection of United
States critical infrastructure and key resources.
b. The Department of Justice, including the Federal Bureau of Investigation, will reduce
domestic terrorist threats, and investigate and prosecute actual or attempted terrorist
attacks on, sabotage of, or disruptions of critical infrastructure and key resources. The
Attorney General and the Secretary shall use applicable statutory authority and attendant
mechanisms for cooperation and coordination, including but not limited to those
established by presidential directive.
c. The Department of Commerce, in coordination with the Department, will work with
private sector, research, academic, and government organizations to improve technology
for cyber systems and promote other critical infrastructure efforts, including using its
authority under the Defense Production Act to assure the timely availability of industrial
products, materials, and services to meet homeland security requirements.
d. A Critical Infrastructure Protection Policy Coordinating Committee will advise the
Homeland Security Council on interagency policy related to physical and cyber
infrastructure protection. This PCC will be chaired by a Federal officer or employee
designated by the Assistant to the President for Homeland Security.
e. The Office of Science and Technology Policy, in coordination with the Department, will
coordinate interagency research and development to enhance the protection of critical
infrastructure and key resources.
f. The Office of Management and Budget (OMB) shall oversee the implementation of
government-wide policies, principles, standards, and guidelines for Federal government
computer security programs. The Director of OMB will ensure the operation of a central
Federal information security incident center consistent with the requirements of the
Federal Information Security Management Act of 2002.
g. Consistent with the E-Government Act of 2002, the Chief Information Officers Council
shall be the principal interagency forum for improving agency practices related to the
design, acquisition, development, modernization, use, operation, sharing, and
performance of information resources of Federal departments and agencies.
h. The Department of Transportation and the Department will collaborate on all matters
relating to transportation security and transportation infrastructure protection. The
Department of Transportation is responsible for operating the national air space system.
The Department of Transportation and the Department will collaborate in regulating the
transportation of hazardous materials by all modes (including pipelines).
i. All Federal departments and agencies shall work with the sectors relevant to their
responsibilities to reduce the consequences of catastrophic failures not caused by
terrorism.
148
23. The heads of all Federal departments and agencies will coordinate and cooperate with the
Secretary as appropriate and consistent with their own responsibilities for protecting critical
infrastructure and key resources.
24. All Federal department and agency heads are responsible for the identification, prioritization,
assessment, remediation, and protection of their respective internal critical infrastructure and key
resources. Consistent with the Federal Information Security Management Act of 2002, agencies
will identify and provide information security protections commensurate with the risk and
magnitude of the harm resulting from the unauthorized access, use, disclosure, disruption,
modification, or destruction of information.
Coordination with the Private Sector
25. In accordance with applicable laws or regulations, the Department and the Sector-Specific
Agencies will collaborate with appropriate private sector entities and continue to encourage the
development of information sharing and analysis mechanisms. Additionally, the Department and
Sector-Specific Agencies shall collaborate with the private sector and continue to support sectorcoordinating mechanisms:
a. to identify, prioritize, and coordinate the protection of critical infrastructure and key
resources; and
b. to facilitate sharing of information about physical and cyber threats, vulnerabilities,
incidents, potential protective measures, and best practices.
National Special Security Events
26. The Secretary, after consultation with the Homeland Security Council, shall be responsible for
designating events as "National Special Security Events" (NSSEs). This directive supersedes
language in previous presidential directives regarding the designation of NSSEs that is
inconsistent herewith.
Implementation
27. Consistent with the Homeland Security Act of 2002, the Secretary shall produce a
comprehensive, integrated National Plan for Critical Infrastructure and Key Resources Protection
to outline national goals, objectives, milestones, and key initiatives within 1 year from the
issuance of this directive. The Plan shall include, in addition to other Homeland Security-related
elements as the Secretary deems appropriate, the following elements:
a. a strategy to identify, prioritize, and coordinate the protection of critical infrastructure
and key resources, including how the Department intends to work with Federal
departments and agencies, State and local governments, the private sector, and foreign
countries and international organizations;
b. a summary of activities to be undertaken in order to: define and prioritize, reduce the
vulnerability of, and coordinate the protection of critical infrastructure and key resources;
c. a summary of initiatives for sharing critical infrastructure and key resources information
and for providing critical infrastructure and key resources threat warning data to State
and local governments and the private sector; and
d. coordination and integration, as appropriate, with other Federal emergency management
and preparedness activities including the National Response Plan and applicable national
preparedness goals.
28. The Secretary, consistent with the Homeland Security Act of 2002 and other applicable legal
authorities and presidential guidance, shall establish appropriate systems, mechanisms, and
149
procedures to share homeland security information relevant to threats and vulnerabilities in
national critical infrastructure and key resources with other Federal departments and agencies,
State and local governments, and the private sector in a timely manner.
29. The Secretary will continue to work with the Nuclear Regulatory Commission and, as
appropriate, the Department of Energy in order to ensure the necessary protection of:
a. commercial nuclear reactors for generating electric power and non-power nuclear
reactors used for research, testing, and training;
b. nuclear materials in medical, industrial, and academic settings and facilities that fabricate
nuclear fuel; and
c. the transportation, storage, and disposal of nuclear materials and waste.
30. In coordination with the Director of the Office of Science and Technology Policy, the Secretary
shall prepare on an annual basis a Federal Research and Development Plan in support of this
directive.
31. The Secretary will collaborate with other appropriate Federal departments and agencies to
develop a program, consistent with applicable law, to geospatially map, image, analyze, and sort
critical infrastructure and key resources by utilizing commercial satellite and airborne systems,
and existing capabilities within other agencies. National technical means should be considered as
an option of last resort. The Secretary, with advice from the Director of Central Intelligence, the
Secretaries of Defense and the Interior, and the heads of other appropriate Federal departments
and agencies, shall develop mechanisms for accomplishing this initiative. The Attorney General
shall provide legal advice as necessary.
32. The Secretary will utilize existing, and develop new, capabilities as needed to model
comprehensively the potential implications of terrorist exploitation of vulnerabilities in critical
infrastructure and key resources, placing specific focus on densely populated areas. Agencies
with relevant modeling capabilities shall cooperate with the Secretary to develop appropriate
mechanisms for accomplishing this initiative.
33. The Secretary will develop a national indications and warnings architecture for infrastructure
protection and capabilities that will facilitate:
a. an understanding of baseline infrastructure operations;
b. the identification of indicators and precursors to an attack; and
c. a surge capacity for detecting and analyzing patterns of potential attacks.
In developing a national indications and warnings architecture, the Department will work with
Federal, State, local, and non-governmental entities to develop an integrated view of physical and
cyber infrastructure and key resources.
34. By July 2004, the heads of all Federal departments and agencies shall develop and submit to the
Director of the OMB for approval plans for protecting the physical and cyber critical
infrastructure and key resources that they own or operate. These plans shall address identification,
prioritization, protection, and contingency planning, including the recovery and reconstitution of
essential capabilities.
35. On an annual basis, the Sector-Specific Agencies shall report to the Secretary on their efforts to
identify, prioritize, and coordinate the protection of critical infrastructure and key resources in
their respective sectors. The report shall be submitted within 1 year from the issuance of this
directive and on an annual basis thereafter.
36. The Assistant to the President for Homeland Security and the Assistant to the President for
National Security Affairs will lead a national security and emergency preparedness
communications policy review, with the heads of the appropriate Federal departments and
agencies, related to convergence and next generation architecture. Within 6 months after the
issuance of this directive, the Assistant to the President for Homeland Security and the Assistant
150
to the President for National Security Affairs shall submit for my consideration any
recommended changes to such policy.
37. This directive supersedes Presidential Decision Directive/NSC-63 of May 22, 1998 ("Critical
Infrastructure Protection"), and any Presidential directives issued prior to this directive to the
extent of any inconsistency. Moreover, the Assistant to the President for Homeland Security and
the Assistant to the President for National Security Affairs shall jointly submit for my
consideration a Presidential directive to make changes in Presidential directives issued prior to
this date that conform such directives to this directive.
38. This directive is intended only to improve the internal management of the executive branch of the
Federal Government, and it is not intended to, and does not, create any right or benefit,
substantive or procedural, enforceable at law or in equity, against the United States, its
departments, agencies, or other entities, its officers or employees, or any other person.
HSPD-8 – National Preparedness
Abstract: Homeland Security Presidential Directive 8 establishes policies to strengthen the U.S.
preparedness in order to prevent and respond to threatened or actual domestic terrorist attacks, major
disasters, and other emergencies. The directive requires a national domestic all-hazards preparedness
goal, with established mechanisms for improved delivery of Federal preparedness assistance to State and
local governments. It also outlines actions to strengthen preparedness capabilities of federal, state, and
local entities. This is a companion directive to HSPD 5.
December 17, 2003
SUBJECT: National Preparedness
Purpose
1. This directive establishes policies to strengthen the preparedness of the United States to prevent
and respond to threatened or actual domestic terrorist attacks, major disasters, and other
emergencies by requiring a national domestic all-hazards preparedness goal, establishing
mechanisms for improved delivery of Federal preparedness assistance to State and local
governments, and outlining actions to strengthen preparedness capabilities of Federal, State, and
local entities.
Definitions
2. For the purposes of this directive:
a. The term "all-hazards preparedness" refers to preparedness for domestic terrorist attacks,
major disasters, and other emergencies.
b. The term "Federal departments and agencies" means those executive depart-ments
enumerated in 5 U.S.C. 101, and the Department of Homeland Security; independent
establishments as defined by 5 U.S.C. 104(1); Government corporations as defined by 5
U.S.C. 103(1); and the United States Postal Service.
151
c. The term "Federal preparedness assistance" means Federal department and agency grants,
cooperative agreements, loans, loan guarantees, training, and/or technical assistance
provided to State and local governments and the private sector to prevent, prepare for,
respond to, and recover from terrorist attacks, major disasters, and other emergencies.
Unless noted otherwise, the term "assistance" will refer to Federal assistance programs.
d. The term "first responder" refers to those individuals who in the early stages of an
incident are responsible for the protection and preservation of life, property, evidence,
and the environment, including emergency response providers as defined in section 2 of
the Homeland Security Act of 2002 (6 U.S.C. 101), as well as emergency management,
public health, clinical care, public works, and other skilled support personnel (such as
equipment operators) that provide immediate support services during prevention,
response, and recovery operations.
e. The terms "major disaster" and "emergency" have the meanings given in section 102 of
the Robert T. Stafford Disaster Relief and Emergency Assistance Act (42 U.S.C. 5122).
f. The term "major events" refers to domestic terrorist attacks, major disasters, and other
emergencies.
g. The term "national homeland security preparedness-related exercises" refers to homeland
security-related exercises that train and test national decision makers and utilize resources
of multiple Federal departments and agencies. Such exercises may involve State and local
first responders when appropriate. Such exercises do not include those exercises
conducted solely within a single Federal department or agency.
h. The term "preparedness" refers to the existence of plans, procedures, policies, training,
and equipment necessary at the Federal, State, and local level to maximize the ability to
prevent, respond to, and recover from major events. The term "readiness" is used
interchangeably with preparedness.
i. The term "prevention" refers to activities undertaken by the first responder community
during the early stages of an incident to reduce the likelihood or consequences of
threatened or actual terrorist attacks. More general and broader efforts to deter, disrupt, or
thwart terrorism are not addressed in this directive.
j. The term "Secretary" means the Secretary of Homeland Security.
k. The terms "State," and "local government," when used in a geographical sense, have the
same meanings given to those terms in section 2 of the Homeland Security Act of 2002 (6
U.S.C. 101).
Relationship to HSPD-5
3. This directive is a companion to HSPD-5, which identifies steps for improved coordination in
response to incidents. This directive describes the way Federal departments and agencies will
prepare for such a response, including prevention activities during the early stages of a terrorism
incident.
Development of a National Preparedness Goal
4. The Secretary is the principal Federal official for coordinating the implementation of all-hazards
preparedness in the United States. In cooperation with other Federal departments and agencies,
the Secretary coordinates the preparedness of Federal response assets, and the support for, and
assessment of, the preparedness of State and local first responders.
5. To help ensure the preparedness of the Nation to prevent, respond to, and recover from threatened
and actual domestic terrorist attacks, major disasters, and other emergencies, the Secretary, in
coordination with the heads of other appropriate Federal departments and agencies and in
152
consultation with State and local governments, shall develop a national domestic all-hazards
preparedness goal. Federal departments and agencies will work to achieve this goal by:
a. providing for effective, efficient, and timely delivery of Federal preparedness assistance
to State and local governments; and
b. supporting efforts to ensure first responders are prepared to respond to major events,
especially prevention of and response to threatened terrorist attacks.
6. The national preparedness goal will establish measurable readiness priorities and targets that
appropriately balance the potential threat and magnitude of terrorist attacks, major disasters, and
other emergencies with the resources required to prevent, respond to, and recover from them. It
will also include readiness metrics and elements that support the national preparedness goal
including standards for preparedness assessments and strategies, and a system for assessing the
Nation's overall preparedness to respond to major events, especially those involving acts of
terrorism.
7. The Secretary will submit the national preparedness goal to me through the Homeland Security
Council (HSC) for review and approval prior to, or concurrently with, the Department of
Homeland Security's Fiscal Year 2006 budget submission to the Office of Management and
Budget.
Federal Preparedness Assistance
8. The Secretary, in coordination with the Attorney General, the Secretary of Health and Human
Services (HHS), and the heads of other Federal departments and agencies that provide assistance
for first responder preparedness, will establish a single point of access to Federal preparedness
assistance program information within 60 days of the issuance of this directive. The Secretary
will submit to me through the HSC recommendations of specific Federal department and agency
programs to be part of the coordinated approach. All Federal departments and agencies will
cooperate with this effort. Agencies will continue to issue financial assistance awards consistent
with applicable laws and regulations and will ensure that program announcements, solicitations,
application instructions, and other guidance documents are consistent with other Federal
preparedness programs to the extent possible. Full implementation of a closely coordinated
interagency grant process will be completed by September 30, 2005.
9. To the extent permitted by law, the primary mechanism for delivery of Federal preparedness
assistance will be awards to the States. Awards will be delivered in a form that allows the
recipients to apply the assistance to the highest priority preparedness requirements at the
appropriate level of government. To the extent permitted by law, Federal preparedness assistance
will be predicated on adoption of Statewide comprehensive all-hazards preparedness strategies.
The strategies should be consistent with the national preparedness goal, should assess the most
effective ways to enhance preparedness, should address areas facing higher risk, especially to
terrorism, and should also address local government concerns and Citizen Corps efforts. The
Secretary, in coordination with the heads of other appropriate Federal departments and agencies,
will review and approve strategies submitted by the States. To the extent permitted by law,
adoption of approved Statewide strategies will be a requirement for receiving Federal
preparedness assistance at all levels of government by September 30, 2005.
10. In making allocations of Federal preparedness assistance to the States, the Secretary, the Attorney
General, the Secretary of HHS, the Secretary of Transportation, the Secretary of Energy, the
Secretary of Veterans Affairs, the Administrator of the Environmental Protection Agency, and the
heads of other Federal departments and agencies that provide assistance for first responder
preparedness will base those allocations on assessments of population concentrations, critical
infrastructures, and other significant risk factors, particularly terrorism threats, to the extent
permitted by law.
153
11. Federal preparedness assistance will support State and local entities' efforts including planning,
training, exercises, interoperability, and equipment acquisition for major events as well as
capacity building for prevention activities such as information gathering, detection, deterrence,
and collaboration related to terrorist attacks. Such assistance is not primarily intended to support
existing capacity to address normal local first responder operations, but to build capacity to
address major events, especially terrorism.
12. The Attorney General, the Secretary of HHS, the Secretary of Transportation, the Secretary of
Energy, the Secretary of Veterans Affairs, the Administrator of the Environmental Protection
Agency, and the heads of other Federal departments and agencies that provide assistance for first
responder preparedness shall coordinate with the Secretary to ensure that such assistance supports
and is consistent with the national preparedness goal.
13. Federal departments and agencies will develop appropriate mechanisms to ensure rapid obligation
and disbursement of funds from their programs to the States, from States to the local community
level, and from local entities to the end users to derive maximum benefit from the assistance
provided. Federal departments and agencies will report annually to the Secretary on the
obligation, expenditure status, and the use of funds associated with Federal preparedness
assistance programs.
Equipment
14. The Secretary, in coordination with State and local officials, first responder organizations, the
private sector and other Federal civilian departments and agencies, shall establish and implement
streamlined procedures for the ongoing development and adoption of appropriate first responder
equipment standards that support nationwide interoperability and other capabilities consistent
with the national preparedness goal, including the safety and health of first responders.
15. To the extent permitted by law, equipment purchased through Federal preparedness assistance for
first responders shall conform to equipment standards in place at time of purchase. Other Federal
departments and agencies that support the purchase of first responder equipment will coordinate
their programs with the Department of Homeland Security and conform to the same standards.
16. The Secretary, in coordination with other appropriate Federal departments and agencies and in
consultation with State and local governments, will develop plans to identify and address national
first responder equipment research and development needs based upon assessments of current and
future threats. Other Federal departments and agencies that support preparedness research and
development activities shall coordinate their efforts with the Department of Homeland Security
and ensure they support the national preparedness goal.
Training and Exercises
17. The Secretary, in coordination with the Secretary of HHS, the Attorney General, and other
appropriate Federal departments and agencies and in consultation with State and local
governments, shall establish and maintain a comprehensive training program to meet the national
preparedness goal. The program will identify standards and maximize the effectiveness of
existing Federal programs and financial assistance and include training for the Nation's first
responders, officials, and others with major event preparedness, prevention, response, and
recovery roles. Federal departments and agencies shall include private organizations in the
accreditation and delivery of preparedness training as appropriate and to the extent permitted by
law.
18. The Secretary, in coordination with other appropriate Federal departments and agencies, shall
establish a national program and a multi-year planning system to conduct homeland security
preparedness-related exercises that reinforces identified training standards, provides for
evaluation of readiness, and supports the national preparedness goal. The establishment and
154
maintenance of the program will be conducted in maximum collaboration with State and local
governments and appropriate private sector entities. All Federal departments and agencies that
conduct national homeland security preparedness-related exercises shall participate in a
collaborative, interagency process to designate such exercises on a consensus basis and create a
master exercise calendar. The Secretary will ensure that exercises included in the calendar
support the national preparedness goal. At the time of designation, Federal departments and
agencies will identify their level of participation in national homeland security preparednessrelated exercises. The Secretary will develop a multi-year national homeland security
preparedness-related exercise plan and submit the plan to me through the HSC for review and
approval.
19. The Secretary shall develop and maintain a system to collect, analyze, and disseminate lessons
learned, best practices, and information from exercises, training events, research, and other
sources, including actual incidents, and establish procedures to improve national preparedness to
prevent, respond to, and recover from major events. The Secretary, in coordination with other
Federal departments and agencies and State and local governments, will identify relevant classes
of homeland-security related information and appropriate means of transmission for the
information to be included in the system. Federal departments and agencies are directed, and
State and local governments are requested, to provide this information to the Secretary to the
extent permitted by law.
Federal Department and Agency Preparedness
20. The head of each Federal department or agency shall undertake actions to support the national
preparedness goal, including adoption of quantifiable performance measurements in the areas of
training, planning, equipment, and exercises for Federal incident management and asset
preparedness, to the extent permitted by law. Specialized Federal assets such as teams, stockpiles,
and caches shall be maintained at levels consistent with the national preparedness goal and be
available for response activities as set forth in the National Response Plan, other appropriate
operational documents, and applicable authorities or guidance. Relevant Federal regulatory
requirements should be consistent with the national preparedness goal. Nothing in this directive
shall limit the authority of the Secretary of Defense with regard to the command and control,
training, planning, equipment, exercises, or employment of Department of Defense forces, or the
allocation of Department of Defense resources.
21. The Secretary, in coordination with other appropriate Federal civilian departments and agencies,
shall develop and maintain a Federal response capability inventory that includes the performance
parameters of the capability, the timeframe within which the capability can be brought to bear on
an incident, and the readiness of such capability to respond to domestic incidents. The
Department of Defense will provide to the Secretary information describing the organizations and
functions within the Department of Defense that may be utilized to provide support to civil
authorities during a domestic crisis.
Citizen Participation
22. The Secretary shall work with other appropriate Federal departments and agencies as well as
State and local governments and the private sector to encourage active citizen participation and
involvement in preparedness efforts. The Secretary shall periodically review and identify the best
community practices for integrating private citizen capabilities into local preparedness efforts.
155
Public Communication
23. The Secretary, in consultation with other Federal departments and agencies, State and local
governments, and non-governmental organizations, shall develop a comprehensive plan to
provide accurate and timely preparedness information to public citizens, first responders, units of
government, the private sector, and other interested parties and mechanisms for coordination at
all levels of government.
Assessment and Evaluation
24. The Secretary shall provide to me through the Assistant to the President for Homeland Security
an annual status report of the Nation's level of preparedness, including State capabilities, the
readiness of Federal civil response assets, the utilization of mutual aid, and an assessment of how
the Federal first responder preparedness assistance programs support the national preparedness
goal. The first report will be provided within 1 year of establishment of the national preparedness
goal.
25. Nothing in this directive alters, or impedes the ability to carry out, the authorities of the Federal
departments and agencies to perform their responsibilities under law and consistent with
applicable legal authorities and presidential guidance.
26. Actions pertaining to the funding and administration of financial assistance and all other
activities, efforts, and policies in this directive shall be executed in accordance with law. To the
extent permitted by law, these policies will be established and carried out in consultation with
State and local governments.
27. This directive is intended only to improve the internal management of the executive branch of the
Federal Government, and it is not intended to, and does not, create any right or benefit,
substantive or procedural, enforceable at law or in equity, against the United States, its
departments, agencies, or other entities, its officers or employees, or any other person.
HSPD-12 – Policy for a Common Identification Standard for Federal Employees and Contractors
Abstract: There are wide variations in the quality and security of identification used to gain access to
secure facilities where there is potential for terrorist attacks. In order to eliminate these variations, U.S.
policy is to enhance security, increase Government efficiency, reduce identity fraud, and protect personal
privacy by establishing a mandatory, Government-wide standard for secure and reliable forms of
identification issued by the Federal Government to its employees and contractors (including contractor
employees). This directive mandates a federal standard for secure and reliable forms of identification.
August 27, 2004
SUBJECT: Policies for a Common Identification Standard for Federal Employees and Contractors
1. Wide variations in the quality and security of forms of identification used to gain access to secure
Federal and other facilities where there is potential for terrorist attacks need to be eliminated.
Therefore, it is the policy of the United States to enhance security, increase Government
efficiency, reduce identity fraud, and protect personal privacy by establishing a mandatory,
156
Government-wide standard for secure and reliable forms of identification issued by the Federal
Government to its employees and contractors (including contractor employees).
2. To implement the policy set forth in paragraph (1), the Secretary of Commerce shall promulgate
in accordance with applicable law a Federal standard for secure and reliable forms of
identification (the "Standard") not later than 6 months after the date of this directive in
consultation with the Secretary of State, the Secretary of Defense, the Attorney General, the
Secretary of Homeland Security, the Director of the Office of Management and Budget (OMB),
and the Director of the Office of Science and Technology Policy. The Secretary of Commerce
shall periodically review the Standard and update the Standard as appropriate in consultation with
the affected agencies.
3. "Secure and reliable forms of identification" for purposes of this directive means identification
that (a) is issued based on sound criteria for verifying an individual employee's identity; (b) is
strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation; (c) can be
rapidly authenticated electronically; and (d) is issued only by providers whose reliability has been
established by an official accreditation process. The Standard will include graduated criteria, from
least secure to most secure, to ensure flexibility in selecting the appropriate level of security for
each application. The Standard shall not apply to identification associated with national security
systems as defined by 44 U.S.C. 3542(b)(2).
4. Not later than 4 months following promulgation of the Standard, the heads of executive
departments and agencies shall have a program in place to ensure that identification issued by
their departments and agencies to Federal employees and contractors meets the Standard. As
promptly as possible, but in no case later than 8 months after the date of promulgation of the
Standard, the heads of executive departments and agencies shall, to the maximum extent
practicable, require the use of identification by Federal employees and contractors that meets the
Standard in gaining physical access to Federally controlled facilities and logical access to
Federally controlled information systems. Departments and agencies shall implement this
directive in a manner consistent with ongoing Government-wide activities, policies and guidance
issued by OMB, which shall ensure compliance.
5. Not later than 6 months following promulgation of the Standard, the heads of executive
departments and agencies shall identify to the Assistant to the President for Homeland Security
and the Director of OMB those Federally controlled facilities, Federally controlled information
systems, and other Federal applications that are important for security and for which use of the
Standard in circumstances not covered by this directive should be considered. Not later than 7
months following the promulgation of the Standard, the Assistant to the President for Homeland
Security and the Director of OMB shall make recommendations to the President concerning
possible use of the Standard for such additional Federal applications.
6. This directive shall be implemented in a manner consistent with the Constitution and applicable
laws, including the Privacy Act (5 U.S.C. 552a) and other statutes protecting the rights of
Americans.
7. Nothing in this directive alters, or impedes the ability to carry out, the authorities of the Federal
departments and agencies to perform their responsibilities under law and consistent with
applicable legal authorities and presidential guidance. This directive is intended only to improve
the internal management of the executive branch of the Federal Government, and it is not
intended to, and does not, create any right or benefit enforceable at law or in equity by any party
157
against the United States, its departments, agencies, entities, officers, employees or agents, or any
other person.
8. The Assistant to the President for Homeland Security shall report to me not later than 7 months
after the promulgation of the Standard on progress made to implement this directive, and shall
thereafter report to me on such progress or any recommended changes from time to time as
appropriate.
HSPD-20/NSPD-51 – National Continuity Policy
Abstract: This directive establishes a comprehensive national policy on the continuity of Federal
Government structures and operations, and also creates the position of a single National Continuity
Coordinator responsible for coordinating the development and implementation of Federal continuity
policies. This policy establishes 'National Essential Functions,' prescribes continuity requirements for all
executive departments and agencies, in order to ensure a comprehensive and integrated national
continuity program that will enhance the credibility of our national security posture and enable a more
rapid and effective response to and recovery from a national emergency.
May 9, 2007
Subject: National Continuity Policy
Purpose
1. This directive establishes a comprehensive national policy on the continuity of Federal
Government structures and operations and a single National Continuity Coordinator responsible
for coordinating the development and implementation of Federal continuity policies. This policy
establishes "National Essential Functions," prescribes continuity requirements for all executive
departments and agencies, and provides guidance for State, local, territorial, and tribal
governments, and private sector organizations in order to ensure a comprehensive and integrated
national continuity program that will enhance the credibility of our national security posture and
enable a more rapid and effective response to and recovery from a national emergency.
Definitions
2. In this directive:
a. "Category" refers to the categories of executive departments and agencies listed in Annex
A to this directive;
b. "Catastrophic Emergency" means any incident, regardless of location, that results in
extraordinary levels of mass casualties, damage, or disruption severely affecting the U.S.
population, infrastructure, environment, economy, or government functions;
c. "Continuity of Government," or "COG," means a coordinated effort within the Federal
Government's executive branch to ensure that National Essential Functions continue to be
performed during a Catastrophic Emergency;
d. "Continuity of Operations," or "COOP," means an effort within individual executive
departments and agencies to ensure that Primary Mission-Essential Functions continue to
158
be performed during a wide range of emergencies, including localized acts of nature,
accidents, and technological or attack-related emergencies;
e. "Enduring Constitutional Government," or "ECG," means a cooperative effort among the
executive, legislative, and judicial branches of the Federal Government, coordinated by
the President, as a matter of comity with respect to the legislative and judicial branches
and with proper respect for the constitutional separation of powers among the branches,
to preserve the constitutional framework under which the Nation is governed and the
capability of all three branches of government to execute constitutional responsibilities
and provide for orderly succession, appropriate transition of leadership, and
interoperability and support of the National Essential Functions during a catastrophic
emergency;
f. "Executive Departments and Agencies" means the executive departments enumerated in
5 U.S.C. 101, independent establishments as defined by 5 U.S.C. 104(1), Government
corporations as defined by 5 U.S.C. 103(1), and the United States Postal Service;
g. "Government Functions" means the collective functions of the heads of executive
departments and agencies as defined by statute, regulation, presidential direction, or other
legal authority, and the functions of the legislative and judicial branches;
h. "National Essential Functions," or "NEFs," means that subset of Government Functions
that are necessary to lead and sustain the Nation during a catastrophic emergency and
that, therefore, must be supported through COOP and COG capabilities; and
i. "Primary Mission Essential Functions," or "PMEFs," means those Government Functions
that must be performed in order to support or implement the performance of NEFs
before, during, and in the aftermath of an emergency.
Policy
3. It is the policy of the United States to maintain a comprehensive and effective continuity
capability composed of Continuity of Operations and Continuity of Government programs in
order to ensure the preservation of our form of government under the Constitution and the
continuing performance of National Essential Functions under all conditions.
Implementation Actions
4. Continuity requirements shall be incorporated into daily operations of all executive departments
and agencies. As a result of the asymmetric threat environment, adequate warning of potential
emergencies that could pose a significant risk to the homeland might not be available, and
therefore all continuity planning shall be based on the assumption that no such warning will be
received. Emphasis will be placed upon geographic dispersion of leadership, staff, and
infrastructure in order to increase survivability and maintain uninterrupted Government
Functions. Risk management principles shall be applied to ensure that appropriate operational
readiness decisions are based on the probability of an attack or other incident and its
consequences.
5. The following NEFs are the foundation for all continuity programs and capabilities and represent
the overarching responsibilities of the Federal Government to lead and sustain the Nation during a
crisis, and therefore sustaining the following NEFs shall be the primary focus of the Federal
Government leadership during and in the aftermath of an emergency that adversely affects the
performance of Government Functions:
a. Ensuring the continued functioning of our form of government under the Constitution,
including the functioning of the three separate branches of government;
159
b. Providing leadership visible to the Nation and the world and maintaining the trust and
confidence of the American people;
c. Defending the Constitution of the United States against all enemies, foreign and
domestic, and preventing or interdicting attacks against the United States or its people,
property, or interests;
d. Maintaining and fostering effective relationships with foreign nations;
e. Protecting against threats to the homeland and bringing to justice perpetrators of crimes
or attacks against the United States or its people, property, or interests;
f. Providing rapid and effective response to and recovery from the domestic consequences
of an attack or other incident;
g. Protecting and stabilizing the Nation's economy and ensuring public confidence in its
financial systems; and
h. Providing for critical Federal Government services that address the national health,
safety, and welfare needs of the United States.
6. The President shall lead the activities of the Federal Government for ensuring constitutional
government. In order to advise and assist the President in that function, the Assistant to the
President for Homeland Security and Counterterrorism (APHS/CT) is hereby designated as the
National Continuity Coordinator. The National Continuity Coordinator, in coordination with the
Assistant to the President for National Security Affairs (APNSA), without exercising directive
authority, shall coordinate the development and implementation of continuity policy for executive
departments and agencies. The Continuity Policy Coordination Committee (CPCC), chaired by a
Senior Director from the Homeland Security Council staff, designated by the National Continuity
Coordinator, shall be the main day-to-day forum for such policy coordination.
7. For continuity purposes, each executive department and agency is assigned to a category in
accordance with the nature and characteristics of its national security roles and responsibilities in
support of the Federal Government's ability to sustain the NEFs. The Secretary of Homeland
Security shall serve as the President's lead agent for coordinating overall continuity operations
and activities of executive departments and agencies, and in such role shall perform the
responsibilities set forth for the Secretary in sections 10 and 16 of this directive.
8. The National Continuity Coordinator, in consultation with the heads of appropriate executive
departments and agencies, will lead the development of a National Continuity Implementation
Plan (Plan), which shall include prioritized goals and objectives, a concept of operations,
performance metrics by which to measure continuity readiness, procedures for continuity and
incident management activities, and clear direction to executive department and agency
continuity coordinators, as well as guidance to promote interoperability of Federal Government
continuity programs and procedures with State, local, territorial, and tribal governments, and
private sector owners and operators of critical infrastructure, as appropriate. The Plan shall be
submitted to the President for approval not later than 90 days after the date of this directive.
9. Recognizing that each branch of the Federal Government is responsible for its own continuity
programs, an official designated by the Chief of Staff to the President shall ensure that the
executive branch's COOP and COG policies in support of ECG efforts are appropriately
coordinated with those of the legislative and judicial branches in order to ensure interoperability
and allocate national assets efficiently to maintain a functioning Federal Government.
10. Federal Government COOP, COG, and ECG plans and operations shall be appropriately
integrated with the emergency plans and capabilities of State, local, territorial, and tribal
governments, and private sector owners and operators of critical infrastructure, as appropriate, in
order to promote interoperability and to prevent redundancies and conflicting lines of authority.
The Secretary of Homeland Security shall coordinate the integration of Federal continuity plans
and operations with State, local, territorial, and tribal governments, and private sector owners and
160
operators of critical infrastructure, as appropriate, in order to provide for the delivery of essential
services during an emergency.
11. Continuity requirements for the Executive Office of the President (EOP) and executive
departments and agencies shall include the following:
a. The continuation of the performance of PMEFs during any emergency must be for a
period up to 30 days or until normal operations can be resumed, and the capability to be
fully operational at alternate sites as soon as possible after the occurrence of an
emergency, but not later than 12 hours after COOP activation;
b. Succession orders and pre-planned devolution of authorities that ensure the emergency
delegation of authority must be planned and documented in advance in accordance with
applicable law;
c. Vital resources, facilities, and records must be safeguarded, and official access to them
must be provided;
d. Provision must be made for the acquisition of the resources necessary for continuity
operations on an emergency basis;
e. Provision must be made for the availability and redundancy of critical communications
capabilities at alternate sites in order to support connectivity between and among key
government leadership, internal elements, other executive departments and agencies,
critical partners, and the public;
f. Provision must be made for reconstitution capabilities that allow for recovery from a
catastrophic emergency and resumption of normal operations; and
g. Provision must be made for the identification, training, and preparedness of personnel
capable of relocating to alternate facilities to support the continuation of the performance
of PMEFs.
12. In order to provide a coordinated response to escalating threat levels or actual emergencies, the
Continuity of Government Readiness Conditions (COGCON) system establishes executive
branch continuity program readiness levels, focusing on possible threats to the National Capital
Region. The President will determine and issue the COGCON Level. Executive departments and
agencies shall comply with the requirements and assigned responsibilities under the COGCON
program. During COOP activation, executive departments and agencies shall report their
readiness status to the Secretary of Homeland Security or the Secretary's designee.
13. The Director of the Office of Management and Budget shall:
a. Conduct an annual assessment of executive department and agency continuity funding
requests and performance data that are submitted by executive departments and agencies
as part of the annual budget request process, in order to monitor progress in the
implementation of the Plan and the execution of continuity budgets;
b. In coordination with the National Continuity Coordinator, issue annual continuity
planning guidance for the development of continuity budget requests; and
c. Ensure that heads of executive departments and agencies prioritize budget resources for
continuity capabilities, consistent with this directive.
14. The Director of the Office of Science and Technology Policy shall:
a. Define and issue minimum requirements for continuity communications for executive
departments and agencies, in consultation with the APHS/CT, the APNSA, the Director
of the Office of Management and Budget, and the Chief of Staff to the President; (b)
Establish requirements for, and monitor the development, implementation, and
maintenance of, a comprehensive communications architecture to integrate continuity
161
components, in consultation with the APHS/CT, the APNSA, the Director of the Office
of Management and Budget, and the Chief of Staff to the President; and (c) Review
quarterly and annual assessments of continuity communications capabilities, as prepared
pursuant to section 16(d) of this directive or otherwise, and report the results and
recommended remedial actions to the National Continuity Coordinator.
15. An official designated by the Chief of Staff to the President shall:
a. Advise the President, the Chief of Staff to the President, the APHS/CT, and the APNSA
on COGCON operational execution options; and
b. Consult with the Secretary of Homeland Security in order to ensure synchronization and
integration of continuity activities among the four categories of executive departments
and agencies.
16. The Secretary of Homeland Security shall:
a. Coordinate the implementation, execution, and assessment of continuity operations and
activities;
b. Develop and promulgate Federal Continuity Directives in order to establish continuity
planning requirements for executive departments and agencies;
c. Conduct biennial assessments of individual department and agency continuity capabilities
as prescribed by the Plan and report the results to the President through the APHS/CT;
d. Conduct quarterly and annual assessments of continuity communications capabilities in
consultation with an official designated by the Chief of Staff to the President;
e. Develop, lead, and conduct a Federal continuity training and exercise program, which
shall be incorporated into the National Exercise Program developed pursuant to
Homeland Security Presidential Directive-8 of December 17, 2003 ("National
Preparedness"), in consultation with an official designated by the Chief of Staff to the
President;
f. Develop and promulgate continuity planning guidance to State, local, territorial, and
tribal governments, and private sector critical infrastructure owners and operators;
g. Make available continuity planning and exercise funding, in the form of grants as
provided by law, to State, local, territorial, and tribal governments, and private sector
critical infrastructure owners and operators; and
h. As Executive Agent of the National Communications System, develop, implement, and
maintain a comprehensive continuity communications architecture.
17. The Director of National Intelligence, in coordination with the Attorney General and the
Secretary of Homeland Security, shall produce a biennial assessment of the foreign and domestic
threats to the Nation's continuity of government.
18. The Secretary of Defense, in coordination with the Secretary of Homeland Security, shall provide
secure, integrated, Continuity of Government communications to the President, the Vice
President, and, at a minimum, Category I executive departments and agencies.
19. Heads of executive departments and agencies shall execute their respective department or agency
COOP plans in response to a localized emergency and shall:
a. Appoint a senior accountable official, at the Assistant Secretary level, as the Continuity
Coordinator for the department or agency;
b. Identify and submit to the National Continuity Coordinator the list of PMEFs for the
department or agency and develop continuity plans in support of the NEFs and the
continuation of essential functions under all conditions;
162
c. Plan, program, and budget for continuity capabilities consistent with this directive;
d. Plan, conduct, and support annual tests and training, in consultation with the Secretary of
Homeland Security, in order to evaluate program readiness and ensure adequacy and
viability of continuity plans and communications systems; and
e. Support other continuity requirements, as assigned by category, in accordance with the
nature and characteristics of its national security roles and responsibilities
General Provisions
20. This directive shall be implemented in a manner that is consistent with, and facilitates effective
implementation of, provisions of the Constitution concerning succession to the Presidency or the
exercise of its powers, and the Presidential Succession Act of 1947 (3 U.S.C. 19), with
consultation of the Vice President and, as appropriate, others involved. Heads of executive
departments and agencies shall ensure that appropriate support is available to the Vice President
and others involved as necessary to be prepared at all times to implement those provisions.
21. This directive:
a. Shall be implemented consistent with applicable law and the authorities of agencies, or
heads of agencies, vested by law, and subject to the availability of appropriations;
b. Shall not be construed to impair or otherwise affect (i) the functions of the Director of the
Office of Management and Budget relating to budget, administrative, and legislative
proposals, or (ii) the authority of the Secretary of Defense over the Department of
Defense, including the chain of command for military forces from the President, to the
Secretary of Defense, to the commander of military forces, or military command and
control procedures; and
c. Is not intended to, and does not, create any rights or benefits, substantive or procedural,
enforceable at law or in equity by a party against the United States, its agencies,
instrumentalities, or entities, its officers, employees, or agents, or any other person.
22. Revocation. Presidential Decision Directive 67 of October 21, 1998 ("Enduring Constitutional
Government and Continuity of Government Operations"), including all Annexes thereto, is
hereby revoked.
23. Annex A and the classified Continuity Annexes, attached hereto, are hereby incorporated into and
made a part of this directive.
24. Security. This directive and the information contained herein shall be protected from
unauthorized disclosure, provided that, except for Annex A, the Annexes attached to this directive
are classified and shall be accorded appropriate handling, consistent with applicable Executive
Orders.
Homeland Security Presidential Directive 20, Annex A
1. In accordance with NSPD-51/HSPD-20, National Continuity Policy, executive departments and
agencies are assigned to one of four categories commensurate with their COOP/COG/ECG
responsibilities during an emergency. These categories shall be used for continuity planning,
communications requirements, emergency operations capabilities, and other related requirements.
2. Category I:
a. Department of State
b. Department of the Treasury
c. Department of Defense, including the U.S. Army Corps of Engineers
163
d.
e.
f.
g.
h.
Department of Justice, including the Federal Bureau of Investigation
Department of Health and Human Services
Department of Transportation
Department of Energy
Department of Homeland Security, including:
a. Federal Emergency Management Agency
b. United States Secret Service
c. National Communications System
i.
j.
Office of the Director of National Intelligence
Central Intelligence Agency
3. Category II:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
o.
p.
Department of the Interior
Department of Agriculture
Department of Commerce
Department of Labor
Department of Housing and Urban Development
Department of Education
Department of Veterans Affairs
Environmental Protection Agency
Federal Communications Commission
Federal Reserve System
General Services Administration
National Archives and Records Administration
Nuclear Regulatory Commission
Office of Personnel Management
Social Security Administration
United States Postal Service
4. Category III:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
Commodity Futures Trading Commission
Export-Import Bank of the United States
Farm Credit Administration
Federal Deposit Insurance Corporation
Federal Mediation and Conciliation Service
National Aeronautics and Space Administration
National Credit Union Administration
National Labor Relations Board
National Science Foundation
Railroad Retirement Board
Securities and Exchange Commission
Small Business Administration
Tennessee Valley Authority
164
5. Category IV:
All executive branch commissions, boards, bureaus, and members of the Small Agency Council
not otherwise identified in Categories I, II, or III.
HSPD-24 – Biometrics for Identification and Screening to Enhance National Security
Abstract: This directive establishes a framework to ensure that Federal executive departments and
agencies use mutually compatible methods and procedures in the collection, storage, use, analysis, and
sharing of biometric and associated biographic and contextual information of individuals in a lawful and
appropriate manner, while respecting their information privacy and other legal rights under United States
law.
June 5, 2008
SUBJECT: Biometrics for Identification and Screening to Enhance National Security
Purpose
This directive establishes a framework to ensure that Federal executive departments and agencies
(agencies) use mutually compatible methods and procedures in the collection, storage, use, analysis, and
sharing of biometric and associated biographic and contextual information of individuals in a lawful and
appropriate manner, while respecting their information privacy and other legal rights under United States
law.
Scope
1. The executive branch has developed an integrated screening capability to protect the Nation
against "known and suspected terrorists" (KSTs). The executive branch shall build upon this
success, in accordance with this directive, by enhancing its capability to collect, store, use,
analyze, and share biometrics to identify and screen KSTs and other persons who may pose a
threat to national security.
2. Existing law determines under what circumstances an individual's biometric and biographic
information can be collected. This directive requires agencies to use, in a more coordinated and
efficient manner, all biometric information associated with persons who may pose a threat to
national security, consistent with applicable law, including those laws relating to privacy and
confidentiality of personal data.
3. This directive provides a Federal framework for applying existing and emerging biometric
technologies to the collection, storage, use, analysis, and sharing of data in identification and
screening processes employed by agencies to enhance national security, consistent with
applicable law, including information privacy and other legal rights under United States law.
4. The executive branch recognizes the need for a layered approach to identification and screening
of individuals, as no single mechanism is sufficient. For example, while existing name-based
screening procedures are beneficial, application of biometric technologies, where appropriate,
improve the executive branch's ability to identify and screen for persons who may pose a national
security threat. To be most effective, national security identification and screening systems will
require timely access to the most accurate and most complete biometric, biographic, and related
data that are, or can be, made available throughout the executive branch.
165
5. This directive does not impose requirements on State, local, or tribal authorities or on the private
sector. It does not provide new authority to agencies for collection, retention, or dissemination of
information or for identification and screening activities.
Definitions
6. In this directive:
a. "Biometrics" refers to the measurable biological (anatomical and physiological) and
behavioral characteristics that can be used for automated recognition; examples include
fingerprint, face, and iris recognition; and
b. "Interoperability" refers to the ability of two or more systems or components to exchange
information and to use the information that has been exchanged.
Background
7. The ability to positively identify those individuals who may do harm to Americans and the Nation
is crucial to protecting the Nation. Since September 11, 2001, agencies have made considerable
progress in securing the Nation through the integration, maintenance, and sharing of information
used to identify persons who may pose a threat to national security.
8. Many agencies already collect biographic and biometric information in their identification and
screening processes. With improvements in biometric technologies, and in light of its
demonstrated value as a tool to protect national security, it is important to ensure agencies use
compatible methods and procedures in the collection, storage, use, analysis, and sharing of
biometric information.
9. Building upon existing investments in fingerprint recognition and other biometric modalities,
agencies are currently strengthening their biometric collection, storage, and matching capabilities
as technologies advance and offer new opportunities to meet evolving threats to further enhance
national security.
10. This directive is designed to (a) help ensure a common recognition of the value of using
biometrics in identification and screening programs and (b) help achieve objectives described in
the following: Executive Order 12881 (Establishment of the National Science and Technology
Council); Homeland Security Presidential Directive-6 (HSPD-6) (Integration and Use of
Screening Information to Protect Against Terrorism); Executive Order 13354 (National
Counterterrorism Center); Homeland Security Presidential Directive-11 (HSPD-11)
(Comprehensive Terrorist Related Screening Procedures); Executive Order 13388 (Further
Strengthening the Sharing of Terrorism Information to Protect Americans); National Security
Presidential Directive-46/Homeland Security Presidential Directive-15 (NSPD-46/HSPD-15)
(U.S. Policy and Strategy in the War on Terror); 2005 Information Sharing Guidelines; 2006
National Strategy for Combating Terrorism; 2006 National Strategy to Combat Terrorist Travel;
2007 National Strategy for Homeland Security; 2007 National Strategy for Information Sharing;
and 2008 United States Intelligence Community Information Sharing Strategy.
Policy
11. Through integrated processes and interoperable systems, agencies shall, to the fullest extent
permitted by law, make available to other agencies all biometric and associated biographic and
contextual information associated with persons for whom there is an articulable and reasonable
basis for suspicion that they pose a threat to national security.
12. All agencies shall execute this directive in a lawful and appropriate manner, respecting the
information privacy and other legal rights of individuals under United States law, maintaining
166
data integrity and security, and protecting intelligence sources, methods, activities, and sensitive
law enforcement information.
Policy Coordination
13. The Assistant to the President for Homeland Security and Counterterrorism, in coordination with
the Assistant to the President for National Security Affairs and the Director of the Office of
Science and Technology Policy, shall be responsible for interagency policy coordination on all
aspects of this directive.
Roles and Responsibilities
14. Agencies shall undertake the roles and responsibilities herein to the fullest extent permitted by
law, consistent with the policy of this directive, including appropriate safeguards for information
privacy and other legal rights, and in consultation with State, local, and tribal authorities, where
appropriate.
15. The Attorney General shall:
a. Provide legal policy guidance, in coordination with the Secretaries of State, Defense, and
Homeland Security and the Director of National Intelligence (DNI), regarding the lawful
collection, use, and sharing of biometric and associated biographic and contextual
information to enhance national security; and
b. In coordination with the DNI, ensure that policies and procedures for the consolidated
terrorist watchlist maximize the use of all biometric identifiers.
16. Each of the Secretaries of State, Defense, and Homeland Security, the Attorney General, the DNI,
and the heads of other appropriate agencies, shall:
a. Develop and implement mutually compatible guidelines for each respective agency for
the collection, storage, use, analysis, and sharing of biometric and associated biographic
and contextual information, to the fullest extent practicable, lawful, and necessary to
protect national security;
b. Maintain and enhance interoperability among agency biometric and associated biographic
systems, by utilizing common information technology and data standards, protocols, and
interfaces;
c. Ensure compliance with laws, policies, and procedures respecting information privacy,
other legal rights, and information security;
d. Establish objectives, priorities, and guidance to ensure timely and effective tasking,
collection, storage, use, analysis, and sharing of biometric and associated biographic and
contextual information among authorized agencies;
e. Program for and budget sufficient resources to support the development, operation,
maintenance, and upgrade of biometric capabilities consistent with this directive and with
such instructions as the Director of the Office of Management and Budget may provide;
and
f. Ensure that biometric and associated biographic and contextual information on KSTs is
provided to the National Counterterrorism Center and, as appropriate, to the Terrorist
Screening Center.
17. The Secretary of State, in coordination with the Secretaries of Defense and Homeland Security,
the Attorney General, and the DNI, shall coordinate the sharing of biometric and associated
167
biographic and contextual information with foreign partners in accordance with applicable law,
including international obligations undertaken by the United States.
18. The Director of the Office of Science and Technology Policy, through the National Science and
Technology Council (NSTC), shall coordinate executive branch biometric science and technology
policy, including biometric standards and necessary research, development, and conformance
testing programs. Recommended executive branch biometric standards are contained in the
Registry of United States Government-Recommended Biometric Standards and shall be updated
via the NSTC Subcommittee on Biometrics and Identity Management.
Implementation
19. Within 90 days of the date of this directive, the Attorney General, in coordination with the
Secretaries of State, Defense, and Homeland Security, the DNI, and the Director of the Office of
Science and Technology Policy, shall, through the Assistant to the President for National Security
Affairs and the Assistant to the President for Homeland Security and Counterterrorism, submit for
the President's approval an action plan to implement this directive. The action plan shall do the
following:
a. Recommend actions and associated timelines for enhancing the existing terrorist-oriented
identification and screening processes by expanding the use of biometrics;
b. Consistent with applicable law, (i) recommend categories of individuals in addition to
KSTs who may pose a threat to national security, and (ii) set forth cost-effective actions
and associated timelines for expanding the collection and use of biometrics to identify
and screen for such individuals; and
c. Identify business processes, technological capabilities, legal authorities, and research and
development efforts needed to implement this directive.
20. Within 1 year of the date of this directive, the Attorney General, in coordination with the
Secretaries of State, Defense, and Homeland Security, the DNI, and the heads of other
appropriate agencies, shall submit to the President, through the Assistant to the President for
National Security Affairs and the Assistant to the President for Homeland Security and
Counterterrorism, a report on the implementation of this directive and the associated action plan,
proposing any necessary additional steps for carrying out the policy of this directive. Agencies
shall provide support for, and promptly respond to, requests made by the Attorney General in
furtherance of this report. The Attorney General will thereafter report to the President on the
implementation of this directive as the Attorney General deems necessary or when directed by the
President.
General Provisions
21. This directive:
a. shall be implemented consistent with applicable law, including international obligations
undertaken by the United States, and the authorities of agencies, or heads of such
agencies, vested by law;
b. shall not be construed to alter, amend, or revoke any other NSPD or HSPD in effect on
the effective date of this directive;
c. is not intended to, and does not, create any rights or benefits, substantive or procedural,
enforceable by law or in equity by a party against the United States, its departments,
agencies, instrumentalities, or entities, its officers, employees, or agents, or any other
person.
168
5. Executive Orders
a) EO 12958 – Classified National Security Information
b) 36 Code of Federal Regulation Part 1236, Management of Vital Records, revised as of July 1, 2000
c) 41 Code of Federal Regulations 101.20.103-4, Occupant Emergency Program, revised as of July 1, 2000
d) EO 12472 – Assignment of National Security and Emergency Preparedness Telecommunications Functions
e) EO 12656 – Assignment of Emergency Preparedness Responsibilities
f) EO 13231 – Critical Infrastructure Protection in the Information Age
g) FCD 1 – Federal Executive Branch National Continuity Program and Requirements, Feb 2008
h) FCD 2 – Federal Executive Branch Mission Essential function and Primary Mission Essential Function
Identification and Submission Process, Feb 2008
a) EO 12958 – Classified National Security Information
created new standards for the process of classifying/declassifying documents
In 1995, United States President William J. Clinton signed Executive Order 12958 which
created new standards for the process of classifying documents and led to an unprecedented
effort to declassify millions of pages from the U.S. diplomatic and national security history. As
of 2002, this policy has resulted in the declassification of what were 800 million pages of
historically valuable records, with the potential of hundreds of millions more being declassified
in the near future. Clinton's White House Chief of Staff, John Podesta, was an important
influence in this process.
One outcome of this change in policy is the government's 1995 admission of its two-decade-plus
involvement in funding highly-classified, special access programs in remote viewing (RV).
Executive Order 12958 was amended and effectively replaced by President George W. Bush on
March 25, 2003, in Executive Order 13292.
Both Executive Order 12958 and Executive Order 13292 were revoked and replaced in full
by President Barack Obama in the issuance of Executive Order 13526. The new guidelines
regulating classified information handling by the U.S. Government will go into full-effect 180
days from December 29th, 2009, except for sections 1.7, 3.3, and 3.7, which are effective
immediately.
b) 36 Code of Federal Regulation Part 1236, Management of Vital Records, revised as of July 1, 2000
169
Archiving Email
Incorporate records management into CPIC
Electronic Records Management:
Agencies Responsibilities:
(a) Incorporate management of electronic records into the records management activities; Integrate
records management and preservation considerations into the design, development, enhancement, and
implementation of electronic information systems in accordance with subpart B of this part; and
(b) Appropriately manage electronic records in accordance with subpart C of this part.
The following types of records management controls are needed to ensure that Federal records in
electronic information systems can provide adequate and proper documentation of agency business for as
long as the information is needed. Agencies must incorporate controls into the electronic information
system or integrate them into a recordkeeping system that is external to the information system itself.
(a) Reliability: Controls to ensure a full and accurate representation of the transactions, activities or facts
to which they attest and can be depended upon in the course of subsequent transactions or activities.
(b) Authenticity: Controls to protect against unauthorized addition, deletion, alteration, use, and
concealment.
(c) Integrity: Controls, such as audit trails, to ensure records are complete and unaltered.
(c) Usability: Mechanisms to ensure records can be located, retrieved, presented, and interpreted.
(d) Content: Mechanisms to preserve the information contained within the record itself that was produced
by the creator of the record;
(e) Context: Mechanisms to implement cross-references to related records that show the organizational,
functional, and operational circumstances about the record, which will vary depending upon the business,
legal, and regulatory requirements of the business activity; and
(f) Structure: controls to ensure the maintenance of the physical and logical format of the records and the
relationships between the data elements.
As part of the capital planning and systems development life cycle processes, agencies must ensure
records management and preservation considerations are incorporated into the design,
development, and implementation of electronic information systems:
(a) That records management controls are planned and implemented in the system;
(b) That all records in the system will be retrievable and usable for as long as needed to conduct agency
business (i.e., for their NARA- approved retention period). Where the records will need to be retained
beyond the planned life of the system, agencies must plan and budget for the migration of records and
170
their associated metadata to new storage media or formats in order to avoid loss due to media decay or
technology obsolescence. (See § 1236.14.)
(c) The transfer of permanent records to NARA in accordance with part 1235 of this subchapter.
(d) Provision of a standard interchange format (e.g., ASCII or XML) when needed to permit the exchange
of electronic documents between offices using different software or operating systems.
c) 41 Code of Federal Regulations 101.20.103-4, Occupant Emergency Program, revised as of July 1,
2000
<<FITSI removed this topic from the FITSP-M exam>>
d) EO 12472 – Assignment of National Security and Emergency Preparedness
Telecommunications Functions
The National Communications System [NCS] was established by Executive Order (EO) 12472 as a
Federal interagency group assigned national security and emergency preparedness (NS/EP)
telecommunications responsibilities throughout the full spectrum of emergencies. Under the policy
objectives stated in EO 12472 and National Security Decision Directive (NSDD) 97, these responsibilities
include planning for, developing, and implementing enhancements to the national telecommunications
infrastructure to achieve measurable improvements in survivability, interoperability, and operational
effectiveness under all conditions and seeking greater effectiveness in managing and using national
telecommunication resources to support the Government during any emergency.
In order to accomplish these responsibilities, the NCS must:












Increase survivability and interoperability of NS/EP telecommunications
Provide connectivity augmentation for the public switched network (PSN)
Develop a NS/EP telecommunications architecture responsive to current and future needs of the
Federal Government
Develop telecommunications technical and procedural standards
Provide technical and analytical expertise to the National Security Telecommunications Advisory
Committee (NSTAC) and subordinate groups
Provide planning assistance and technical analysis to the Committee of Principals (COP) and the
Council of Representatives (COR)
Perform NS/EP telecommunications network performance analysis
Ensure interoperability of Integrated Services Digital Networks (ISDNs)
Develop emergency operations training and exercises
Develop and manage NS/EP automated systems and capabilities
Improve capabilities to predict impacts of natural disasters on telecommunications
Analyze technological advances such as digital cellular, advanced intelligent networks (AIN),
commercial satellite technologies, and wireless technologies to identify potential impacts on
NS/EP telecommunications
171
The National Communications System (NCS) is an office within the United States Department of
Homeland Security charged with enabling national security and emergency preparedness
communications (NS/EP telecommunications) using the national telecommunications system.
On April 3, 1984, President Ronald Reagan signed Executive Order (E.O.) 12472 which broadened the
NCS' national security and emergency preparedness (NS/EP) capabilities and superseded President
Kennedy's original 1963 memorandum. The NCS expanded from its original six members to an
interagency group of 23 Federal departments and agencies, and began coordinating and planning NS/EP
telecommunications to support crises and disasters.
With the addition of the Office of the Director of National Intelligence (ODNI) on September 30, 2007,
the NCS membership currently stands at 24 members.
Each NCS member organization is represented on the NCS through the Committee of Principals (COP) -and its subordinate Council of Representatives (COR). The COP, formed as a result of Executive Order
12472, provides advice and recommendations to the NCS and the National Security Council through the
President's Critical Infrastructure Protection Board on NS/EP telecommunications and its ties to other
critical infrastructures. The NCS also participates in joint industry-Government planning through its work
with the President's National Security Telecommunications Advisory Committee (NSTAC), with the
NCS's National Coordinating Center for Telecommunications (NCC) and the NCC's subordinate
Information Sharing and Analysis Center (ISAC).
After nearly 40 years with the Secretary of Defense serving as its Executive Agent, President George W.
Bush transferred the National Communications System to the Department of Homeland Security (DHS).
The NCS was one of 22 Federal agencies transferred to the Department on March 1, 2003, in accordance
with Executive Order 13286. A revised Executive Order 12472 reflects the changes of E.O. 13286. On
November 15, 2005, the NCS became part of the Department's Directorate for Preparedness after nearly
two years under the Information Analysis and Infrastructure Protection Directorate. In March 2007 the
NCS became an entity of the National Protection and Programs Directorate. Currently, the DHS Under
Secretary for National Protection and Programs Directorate serves as the NCS Manager.
e) EO 12656 – Assignment of Emergency Preparedness Responsibilities
Executive Order 12656 "Assignment of Emergency Preparedness Responsibilities", February 16, 2004
plus Executive Order 13074, Amendment to EO 12656, February 9, 1998.
"Executive Order Number 12656 appointed the National Security Council as the principal body that
should consider emergency powers. This allows the government to increase domestic intelligence and
surveillance of U.S. citizens and would restrict the freedom of movement within the United States
and grant the government the right to isolate large groups of civilians. The National Guard could
be federalized to seal all borders and take control of U.S. air space and all ports of entry."
f) EO 13231 – Critical Infrastructure Protection in the Information Age
Establishes the Committee on National Security Systems (CNSS), a United States intergovernmental
organization that sets policy for the security of the US security systems.
172
The National Security Telecommunications and Information Systems Security Committee (NSTISSC)
was established under National Security Directive 42, "National Policy for the Security of National
Security Telecommunications and Information Systems", dated 5 July 1990. On October 16, 2001,
President George W. Bush signed Executive Order 13231, the Critical Infrastructure Protection in the
Information Age, re-designating the National Security Telecommunications and Information Systems
Security Committee (NSTISSC) as the Committee on National Security Systems. The CNSS holds
discussions of policy issues, sets national policy, directions, operational procedures, and guidance for the
information systems operated by the U.S. Government, its contractors or agents that either contain
classified information, involve intelligence activities, involve cryptographic activities related to national
security, involve command and control of military forces, involve equipment that is an integral part of a
weapon or weapons system(s), or are critical to the direct fulfillment of military or intelligence missions.
The Department of Defense chairs the committee. Membership consists of representatives from 21 U.S.
Government Departments and Agencies with voting privileges, to include the CIA, DIA, DOD, DOJ,
FBI, NSA, and the National Security Council, and all United States Military Services. Members not on
the voting committee include the DISA, NGA, NIST, and the NRO. The operating Agency for CNSS
appears to be the National Security Agency, Which serves as primary contact for public inquiries.
The CNSS awards several certifications to educational institutions and individuals. These certifications
are designed to certify an institution's curriculum as meeting a standard outlined in the National
Information Assurance Certification and Accreditation Process. This process provides a standard set of
activities, general tasks, and a management structure to certify and accredit systems that will maintain the
Information Assurance (IA) and security posture of a system or site. Current certifications include:






NSTISSI-4011 National Training Standard for Information Systems Security (INFOSEC)
Professionals
CNSSI-4012 National Information Assurance Training Standard for Senior Systems Managers
CNSSI-4013 National Information Assurance Training Standard For System Administrators
CNSSI-4014 Information Assurance Training Standard for Information Systems Security Officers
NSTISSI-4015 National Training Standard for Systems Certifiers
CNSSI-4016 National Information Assurance Training Standard For Risk Analysts
Section 1. Policy.
(a) The information technology revolution has changed the way business is transacted, government
operates, and national defense is conducted. Those three functions now depend on an interdependent
network of critical information infrastructures. The protection program authorized by this order shall
consist of continuous efforts to secure information systems for critical infrastructure, including
emergency preparedness communications, and the
physical assets that support such systems. Protection of these systems is essential to the
telecommunications, energy, financial services, manufacturing, water, transportation, health care, and
emergency services sectors.
(b) It is the policy of the United States to protect against disruption of the operation of information
systems for critical infrastructure and thereby help to protect the people, economy, essential human and
government services,
and national security of the United States, and to ensure that any disruptions that occur are infrequent, of
minimal duration, and manageable, and cause the least damage possible. The implementation of this
policy shall include a voluntary public-private partnership, involving corporate and nongovernmental
organizations.
173
Sec. 2. Scope. To achieve this policy, there shall be a senior executive branch board to coordinate and
have cognizance of Federal efforts and programs that relate to protection of information systems and
involve:
(a) cooperation with and protection of private sector critical infrastructure, State and local
governments’ critical infrastructure, and supporting programs in corporate and academic
organizations;
(b) protection of Federal departments’ and agencies’ critical infrastructure; and
(c) related national security programs.
g) Federal Continuity Directive 1 (FCD 1) – Federal Executive Branch National Continuity
Program and Requirements, Feb 2008
The mission of FEMA's National Continuity Programs Directorate (NCP) is to serve the public by
protecting our Nation's constitutional form of government. NCP also published two Federal Continuity
Directives (FCD1 and FCD2) directing executive branch departments and agencies to carry out identified
continuity planning requirements and assessment criteria. FCD 1 provides baseline continuity planning
and program requirements, and FCD 2 provides specific guidance on identification, submission, review
and validation processes for Mission Essential Functions and Primary Mission Essential Functions.
Federal Continuity Directive 1 (FCD 1) Federal Executive Branch National Continuity Program and
Requirements, approved by the Secretary of Homeland Security in February 2008, provides operational
direction for the development of continuity plans and programs for the Federal Executive Branch.
This directive supersedes Federal Preparedness Circular 65 and was developed by NCP’s Continuity of
Operations Division in coordination with its interagency partners.
FCD 1 describes the key elements of a viable continuity capability and the importance of coordinating
with non-Federal organizations to establish and maintain a comprehensive and effective national
continuity capability. Continuity programs and operations are simply good business practices that ensure
government functions and services will be available to our nation’s citizens under all conditions.
The provisions of this directive are applicable at all levels of Federal Executive Branch organizations,
regardless of their location, and are useful for all non-Federal entities.
The enhancements in the new guidance specifically address the following:





Key components of continuity program management, including personnel, communications, and
facilities
Need for scalable, full-spectrum continuity plans that acknowledge the potential for a broad range
of disruptive events and call for more than just a traditional continuity option that requires
relocating staff to an alternate facility
Incorporation of a risk-based framework for continuity plans and programs to identify and assess
potential hazards, determine acceptable levels of risk, and prioritize and allocate resources
Inclusion of budgeting considerations in continuity plans and programs
Readiness and preparedness considerations.
174
h) Federal Continuity Directive 2 (FCD 2) – Federal Executive Branch Mission Essential
function and Primary Mission Essential Function Identification and Submission Process, Feb
2008
Federal Continuity Directive 2 (FCD 2) Federal Executive Branch Mission Essential Function and
Primary Mission Essential Function Identification, approved by the DHS Secretary in February 2008,
provides direction and guidance for Federal organizations to identify their essential functions and
the business process analysis (BPA) and business impact analysis (BIA) that support and identify
the relationships between these essential functions.
FCD 2 provides implementation guidelines for the requirements identified in FCD 1, Annex C. It
provides direction and guidance to Federal entities for identification of their mission essential functions
(MEFs) and potential primary mission essential functions (PMEFs). It also includes checklists to assist in
identifying essential functions through a risk management process and identify potential PMEFs that
support specific national essential functions (NEFs)—the most critical functions necessary for leading and
sustaining our nation during a catastrophic emergency.
FCD 2 provides direction on the formalized process for submission of a Department’s or Agency’s
potential PMEFs that are supportive of the NEFs. It also provides guidance on the processes for
conducting a business process analysis (BPA) and business impact analysis (BIA) for each of the
potential PMEFs that help identify essential function relationships and interdependencies, time
sensitivities, threat and vulnerability analyses, and mitigation strategies affecting and supporting the
PMEFs.
175
Domain 5 – NIST Risk Management Framework
176
These 12 documents are components of the RMF.
1. 800-18 Rev1 - Guide for Developing Security Plans for Federal Information Systems
2. 800-34 - Contingency Planning Guide for Information Technology Systems
3. 800-47 - Security Guide for Interconnecting Information Technology Systems
4. 800-53 Rev3 - Recommended Security Controls for Federal Information Systems
5. 800-53A - Guide for Assessing the Security Controls in Federal Information Systems
6. 800-37 Rev1 - Guide for the Security Certification and Accreditation of Federal Information Systems
7. 800-59 - Guideline for Identifying an Information System as a National Security System
8. 800-60 Rev1- Guide for Mapping Types of Information and Information Systems to Security
Categories: (2 Volumes)
9. 800-66 - An Introductory Resource Guide for Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule
10. 800-115 - Technical Guide to Information Security Testing and Assessment
11. FIPS 200 - Minimum Security Requirements for Federal Information and Information Systems
12. FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems
1. 800-18 Rev1 - Guide for Developing Security Plans for Federal Information Systems
Executive Summary
The objective of system security planning is to improve protection of information system resources.
All federal systems have some level of sensitivity and require protection as part of good management
practice. The protection of a system must be documented in a system security plan. The completion
of system security plans is a requirement of the Office of Management and Budget (OMB) Circular
A-130, ―Management of Federal Information Resources,‖ Appendix III, ―Security of Federal
Automated Information Resources,‖ and‖ Title III of the E-Government Act, entitled the Federal
Information Security Management Act (FISMA).
The purpose of the system security plan is to provide an overview of the security requirements of the
system and describe the controls in place or planned for meeting those requirements. The system
security plan also delineates responsibilities and expected behavior of all individuals who access the
system. The system security plan should be viewed as documentation of the structured process of
planning adequate, cost-effective security protection for a system. It should reflect input from various
managers with responsibilities concerning the system, including information owners, the system
owner, and the senior agency information security officer (SAISO). Additional information may be
included in the basic plan and the structure and format organized according to agency needs, so long
as the major sections described in this document are adequately covered and readily identifiable.
In order for the plans to adequately reflect the protection of the resources, a senior management
official must authorize a system to operate. The authorization of a system to process information,
granted by a management official, provides an important quality control. By authorizing processing
in a system, the manager accepts its associated risk.
Management authorization should be based on an assessment of management, operational, and
technical controls. Since the system security plan establishes and documents the security controls, it
should form the basis for the authorization, supplemented by the assessment report and the plan of
actions and milestones. In addition, a periodic review of controls should also contribute to future
177
authorizations. Re-authorization should occur whenever there is a significant change in processing,
but at least every three years.
Vii
Main references within document:
FIPS 200 - Minimum Security Requirements for Federal Information and Information Systems-
specifies minimum security requirements for fed IT systems.
NIST SP 800-53 – Recommended Security Controls for Federal Information Systems, security
controls prescribed for an information system and documented in a system security plan.
FIPS 199 - the mandatory federal standard used to categorize all information and information
systems in order to provide appropriate levels of information security according to impact.
NIST SP 800-30, Risk Management Guide for Information Technology Systems
NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information
Systems
NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems
OMB Circular A-130, Appendix III, defines major application as an application that requires special attention to
security due to the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or
modification of the information in the application.
OMB Circular A-130, Appendix III, defines general support system as an interconnected set of information
resources under the same direct management control that shares common functionality. It normally includes
hardware, software, information, data, applications, communications, and people.
Organization of Document
This publication introduces a set of activities and concepts to develop an information system security
plan. A brief description of its contents follows:
1 Guide for Developing Security Plans for Federal Information Systems
• Chapter 1 includes background information relevant to the system security planning process, target
audience, information on FIPS 199, Standards for Security Categorization of Federal Information
and Information Systems, a discussion of the various categories of information systems, identification
of related NIST publications, and a description of the roles and responsibilities related to the
development of system security plans.
roles and responsibilities:
 CIO, responsible for developing and maintaining an agency-wide information security
program
 ISO, responsible for the overall procurement, development, integration, modification, or
operation and maintenance of the information system
 Information Owner, official with statutory or operational authority for specified
information and responsibility for establishing the controls
 SAISO, CIO's primary liaison to the agency's ISOs and ISSOs
 ISSO, ensuring that the appropriate operational security posture is maintained
178

AO, official or executive with the authority to formally assume responsibility for
operating an information system at an acceptable level of risk
• Chapter 2 discusses how agencies should analyze their information system inventories in the
process of establishing system boundaries. It also discusses identification of common security
controls and scoping guidance.
• Chapter 3 takes the reader through the steps of system security plan development.
• Appendix A SSP template.
• Appendix B glossary.
• Appendix C references that support this publication.
2. 800-34 - Contingency Planning Guide for Information Technology Systems
Executive Summary
NIST Special Publication 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems,
provides instructions, recommendations, and considerations for federal information system contingency
planning. Contingency planning refers to interim measures to recover information system services after a
disruption. Interim measures may include relocation of information systems and operations to an alternate
site, recovery of information system functions using alternate equipment, or performance of information
system functions using manual methods. This guide addresses specific contingency planning
recommendations for three platform types and provides strategies and techniques common to all systems.
Client/server systems;
Telecommunications systems; and
Mainframe systems.
This guide defines the following seven-step contingency planning process that an organization may apply
to develop and maintain a viable contingency planning program for their information systems. These
seven progressive steps are designed to be integrated into each stage of the system development life cycle.
1. Develop the contingency planning policy statement. A formal policy provides the authority and
guidance necessary to develop an effective contingency plan.
2. Conduct the business impact analysis (BIA). The BIA helps identify and prioritize information
systems and components critical to supporting the organization’s mission/business functions. A
template for developing the BIA is provided to assist the user.
3. Identify preventive controls. Measures taken to reduce the effects of system disruptions can increase
system availability and reduce contingency life cycle costs.
4. Create contingency strategies. Thorough recovery strategies ensure that the system may be
recovered quickly and effectively following a disruption.
5. Develop an information system contingency plan. The contingency plan should contain detailed
guidance and procedures for restoring a damaged system unique to the system’s security impact level
and recovery requirements.
6. Ensure plan testing, training, and exercises. Testing validates recovery capabilities, whereas
training prepares recovery personnel for plan activation and exercising the plan identifies planning
gaps; combined, the activities improve plan effectiveness and overall organization preparedness.
179
7. Ensure plan maintenance. The plan should be a living document that is updated regularly to remain
current with system enhancements and organizational changes.
This guide presents three sample formats for developing an information system contingency plan based
on low-, moderate-, or high-impact level, as defined by Federal Information Processing Standard (FIPS)
199, Standards for Security Categorization of Federal Information and Information Systems. Each format
defines three phases that govern actions to be taken following a system disruption. The
Activation/Notification Phase describes the process of activating the plan based on outage impacts and
notifying recovery personnel. The Recovery Phase details a suggested course of action for recovery
teams to restore system operations at an alternate site or using contingency capabilities. The final phase,
Reconstitution, includes activities to test and validate system capability and functionality and outlines
actions that can be taken to return the system to normal operating condition and prepare the system
against future outages.
Information system contingency planning refers to a coordinated strategy involving plans, procedures,
and technical measures that enable the recovery of information systems, operations, and data after a
disruption. Contingency planning generally includes one or more of the following approaches to restore
disrupted services:

 Restoring information systems using alternate equipment;

Performing some or all of the affected business processes using alternate processing
(manual) means (typically acceptable for only short-term disruptions);

Recovering information systems operations at an alternate location (typically acceptable
for only long–term disruptions or those physically impacting the facility); and

Implementing of appropriate contingency planning controls based on the information
system’s security impact level.

Chapter 1. Introduction
1.1 Purpose.......................................................................................................................1
1.2 Scope..........................................................................................................................2
1.3 Audience.....................................................................................................................3
1.4 Document Structure....................................................................................................4
Chapter 2. Background
2.1 Contingency Planning and Resilience........................................................................6
2.2 Types of Plans............................................................................................................8
2.2.1 Business Continuity Plan (BCP)...................................................................9
2.2.2 Continuity of Operations (COOP) Plan.........................................................9
2.2.3 Crisis Communications Plan........................................................................10
2.2.4 Critical Infrastructure Protection (CIP) Plan.................................................10
2.2.5 Cyber Incident Response Plan.....................................................................11
2.2.6 Disaster Recovery Plan (DRP).....................................................................11
2.2.7 Information System Contingency Plan (ISCP)..............................................11
2.2.8 Occupant Emergency Plan (OEP)................................................................11
Chapter 3. Information System Contingency Planning Process................................14
3.1 Develop the Contingency Planning Policy Statement...............................................15
3.2 Conduct the Business Impact Analysis (BIA)............................................................16
180
3.2.1 Determine Business Processes and Recovery Criticality..............................17
3.2.2 Identify Resource Requirements...................................................................20
3.2.3 Identify System Resource Recovery Priorities..............................................20
3.3 Identify Preventive Controls......................................................................................20
3.4 Create Contingency Strategies.................................................................................21
3.4.1 Backup and Recovery...................................................................................21
3.4.2 Backup Methods and Offsite Storage............................................................22
3.4.3 Alternate Sites...............................................................................................22
3.4.4 Equipment Replacement...............................................................................25
3.4.5 Cost Considerations......................................................................................26
3.4.6 Roles and Responsibilities............................................................................27
3.5 Plan Testing, Training, and Exercises (TT & E)........................................................28
3.5.1 Testing...........................................................................................................28
3.5.2 Training..........................................................................................................29
3.5.3 Exercises.......................................................................................................30
3.5.4 TT&E Program Summary..............................................................................30
3.6 Plan Maintenance.....................................................................................................32
Chapter 4. Information System Contingency Plan Development...............................35
4.1 Supporting Information..............................................................................................36
4.2 Activation and Notification Phase.............................................................................37
4.2.1 Activation Criteria and Procedure..................................................................37
4.2.2 Notification Procedures.................................................................................37
4.2.3 Outage Assessment......................................................................................39
4.3 Recovery Phase........................................................................................................40
181
4.3.1 Sequence of Recovery Activities...................................................................40
4.3.2 Recovery Procedures....................................................................................40
4.3.3 Recovery Escalation and Notification............................................................41
4.4 Reconstitution Phase................................................................................................42
4.5 Plan Appendices.......................................................................................................43
Chapter 5. Technical Contingency Planning Considerations.....................................44
5.1 Common Considerations..........................................................................................44
5.1.1 Use of the BIA...............................................................................................44
5.1.2 Maintenance of Data Security, Integrity, and Backup....................................45
5.1.3 Protection of Resources................................................................................46
5.1.4 Adherence to Security Controls.....................................................................47
5.1.5 Identification of Alternate Storage and Processing Facilities.........................47
5.1.6 Use of High Availability (HA) Processes........................................................49
5.2 Client/Server Systems..............................................................................................49
5.2.1 Client/Server Systems Contingency Considerations.....................................50
5.2.2 Client/Server Systems Contingency Solutions..............................................51
5.3 Telecommunications Systems..................................................................................53
5.3.1 Telecommunications Contingency Considerations........................................54
5.3.2 Telecommunications Contingency Solutions.................................................55
5.4 Mainframe Systems..................................................................................................57
5.4.1 Mainframe Contingency Considerations........................................................57
5.4.2 Mainframe Contingency Solutions.................................................................57
5.5 System Contingency Planning Considerations Summary.........................................58
2.2.1 Business Continuity Plan (BCP)
The BCP focuses on sustaining an organization’s mission/business functions during and after a disruption.
An example of a mission/business function may be an organization’s payroll process or customer service
process. A BCP may be written for mission/business functions within a single business unit or may
address the entire organization’s processes. The BCP may also be scoped to address only the functions
deemed to be priorities. A BCP may be used for long-term recovery in conjunction with the COOP plan,
allowing for additional functions to come online as resources or time allow. Because mission/business
functions use information systems (ISs), the business continuity planner must coordinate with information
system owners to ensure that the BCP expectations and IS capabilities are matched.
2.2.2 Continuity of Operations (COOP) Plan
COOP focuses on restoring an organization’s mission-essential functions (MEF) at an alternate site and
performing those functions for up to 30 days before returning to normal operations. Additional functions,
or those at a field office level, may be addressed by a BCP. Minor threats or disruptions that do not
require relocation to an alternate site are not typically addressed in a COOP plan.
182
COOP vs. ISCP – The Basic Facts
FUNCTIONS

COOP plans address national, primary, or mission-essential functions; ISCPs
address federal information systems.
o COOP functions have specific criteria; not all government mission/business
functions meet COOP criteria.
o COOP functions may be supported by information systems.
o Information systems support government mission/business functions, but not
all government mission/business functions fall within the scope of COOP.
SCOPE

COOP planning applies to mission-essential functions of federal government
departments and agencies.

ISCPs apply to all information systems in federal organizations.
AUTHORITIES

COOP is mandated for federal organizations by HSPD-20/NSPD-51, FCDs 1 and
2, and the National Continuity Policy Implementation Plan (NCPIP); ISCPs are
mandated for federal organizations by FISMA.
2.2.5 Cyber Incident Response Plan
The cyber incident response plan11 establishes procedures to address cyber attacks against an
organization’s information system(s).12 These procedures are designed to enable security personnel to
identify, mitigate, and recover from malicious computer incidents, such as unauthorized access to a
system or data, denial of service, or unauthorized changes to system hardware, software, or data (e.g.,
malicious logic, such as a virus, worm, or Trojan horse). This plan may be included as an appendix of the
BCP.
2.2.6 Disaster Recovery Plan (DRP)
The DRP applies to major, usually physical disruptions to service that deny access to the primary facility
infrastructure for an extended period. A DRP is an information system-focused plan designed to restore
operability of the target system, application, or computer facility infrastructure at an alternate site after an
emergency. The DRP may be supported by multiple information system contingency plans to address
recovery of impacted individual systems once the alternate facility has been established. A DRP may
support a BCP or COOP plan by recovering supporting systems for mission/business functions or mission
essential functions at an alternate location. The DRP only addresses information system disruptions that
require relocation.
183
2.2.7 Information System Contingency Plan (ISCP)
An ISCP provides established procedures for the assessment and recovery of a system following a
system disruption. The ISCP provides key information needed for system recovery, including roles and
responsibilities, inventory information, assessment procedures, detailed recovery procedures, and testing
of a system.
The ISCP differs from a DRP primarily in that the information system contingency plan procedures are
developed for recovery of the system regardless of site or location. An ISCP can be activated at the
system’s current location or at an alternate site. In contrast, a DRP is primarily a site-specific plan
developed with procedures to move operations of one or more information systems from a damaged or
uninhabitable location to a temporary alternate location. Once the DRP has successfully transferred an
information system site to an alternate site, each affected system would then use its respective information
system contingency plan to restore, recover, and test systems, and put them into operation.
2.2.8 Occupant Emergency Plan (OEP)
The OEP outlines first-response procedures for occupants of a facility in the event of a threat or incident
to the health and safety of personnel, the environment, or property. Such events include a fire, bomb
threat, chemical release, domestic violence in the workplace, or a medical emergency. Shelter-in-place
procedures for events requiring personnel to stay inside the building rather than evacuate are also
addressed in an OEP. OEPs are developed at the facility level, specific to the geographic location and
structural design of the building. General Services Administration (GSA)-owned facilities maintain plans
based on the GSA OEP template. The facility OEP may be appended to the COOP or BCP, but is
executed separately and as a first response to the incident. Aspects of planning for personnel safety and
evacuation are discussed in Appendix D.
184
Table 2-2 summarizes the types of plans. The plan types identified are implemented individually or in
coordination with one another as appropriate to respond to a disruptive event.
Plan Types Plan
Business
Continuity Plan
(BCP)
Continuity of
Operations
(COOP) Plan
Crisis Communications Plan
Critical
Infrastructure
Protection (CIP)
Plan
Cyber Incident
Response Plan
Disaster
Recovery Plan
(DRP)
Information
System
Contingency
Plan (ISCP)
Purpose
Provides procedures for
sustaining
mission/business
operations while
recovering from a
significant disruption.
Provides procedures
and guidance to sustain
an organization’s
mission essential
functions at an alternate
site for up to 30 days;
mandated by federal
directives.
Provides procedures for
disseminating internal
and external
communications; means
to provide critical status
information and control
rumors.
Provides policies and
procedures for
protection of national
critical infrastructure
components, as defined
in the National
Infrastructure Protection
Plan.
Provides procedures for
mitigating and correcting
a cyber attack, such as a
virus, worm, or Trojan
horse.
Provides procedures for
relocating information
systems operations to
an alternate location.
Scope
Addresses
mission/business
functions at a lower or
expanded level from
COOP mission-essential
functions.
Addresses missionessential functions at a
facility; information
systems are addressed
based only on their
support of the missionessential functions.
Plan Relationship
Mission/business process
focused plan that may be
activated in coordination
with a COOP plan to
sustain non-missionessential functions.
Mission-essential
functions focused plan
that may also activate
several business unitlevel BCPs, ISCPs, or
DRPs, as appropriate.
Addresses
communications with
personnel and the
public; not information
system- focused.
Incident-based plan often
activated with a COOP or
BCP, but may be used
alone during a public
exposure event.
Addresses critical
infrastructure
components that are
supported or operated
by an agency or
organization.
Risk management plan
that supports COOP
plans for organizations
with critical infrastructure
and key resource assets.
Addresses mitigation
and isolation of affected
systems, cleanup, and
minimizing loss of
information.
Activated after major
system disruptions with
long-term effects.
Provides procedures
and capabilities for
recovering an
information system.
Addresses single
information system
recovery at the current
or, if appropriate
alternate location.
Information systemfocused plan that may
activate an ISCP or DRP,
depending on the extent
of the attack.
Information systemfocused plan that
activates one or more
ISCPs for recovery of
individual systems.
Information systemfocused plan that may be
activated independent
from other plans or as
part of a larger recovery
effort coordinated with a
DRP, COOP, and/or
BCP.
185
Occupant
Emergency Plan
(OEP)
Provides coordinated
procedures for
minimizing loss of life or
injury and protecting
property damage in
response to a physical
threat.
Focuses on personnel
and property particular
to the specific facility;
not mission/business
process or information
system-based.
Incident-based plan that
is initiated immediately
after an event, preceding
a COOP or DRP
activation.
3. 800-47 - Security Guide for Interconnecting Information Technology Systems
Executive Summary
The Security Guide for Interconnecting Information Technology Systems provides guidance for planning,
establishing, maintaining, and terminating interconnections between information technology (IT) systems
that are owned and operated by different organizations. The guidelines are consistent with the
requirements specified in the Office of Management and Budget (OMB) Circular A-130, Appendix III,
for system interconnection and information sharing.
A system interconnection is defined as the direct connection of two or more IT systems for the purpose of
sharing data and other information resources. The document describes various benefits of interconnecting
IT systems, identifies the basic components of an interconnection, identifies methods and levels of
interconnectivity, and discusses potential security risks associated with an interconnection.
The document then presents a ―life-cycle management‖ approach for interconnecting IT systems, with an
emphasis on security. The four phases of the interconnection life cycle are addressed:
+ Planning the interconnection: the participating organizations perform preliminary activities;
examine all relevant technical, security, and administrative issues; and form an agreement
governing the management, operation, and use of the interconnection.
+ Establishing the interconnection: the organizations develop and execute a plan for establishing
the interconnection, including implementing or configuring appropriate security controls.
+ Maintaining the interconnection: the organizations actively maintain the interconnection after it
is established to ensure that it operates properly and securely.
+ Disconnecting the interconnection: one or both organizations may choose to terminate the
interconnection. The termination should be conducted in a planned manner to avoid disrupting the
other party’s system. In response to an emergency, however, one or both organizations may
decide to terminate the interconnection immediately.
The document provides recommended steps for completing each phase, emphasizing security measures
that should be taken to protect the connected systems and shared data.
The document also contains guides and samples for developing an Interconnection Security Agreement
(ISA) and a Memorandum of Understanding/Agreement (MOU/A). The ISA specifies the technical and
security requirements of the interconnection, and the MOU/A defines the responsibilities of the
participating organizations. Finally, the document contains a guide for developing a System
Interconnection Implementation Plan, which defines the process for establishing the interconnection,
including scheduling and costs.
186
INTRODUCTION................................................................................................................1-1
1.1 Authority...................................................................................................................1-1
1.2 Purpose....................................................................................................................1-1
1.3 Scope.......................................................................................................................1-1
1.4 Audience..................................................................................................................1-1
1.5 Other Approaches to System Interconnectivity........................................................1-2
1.6 Document Structure.................................................................................................1-2
2. BACKGROUND.................................................................................................................2-1
3. PLANNING A SYSTEM INTERCONNECTION.................................................................3-1
3.1 Step 1: Establish a Joint Planning Team.................................................................3-1
3.2 Step 2: Define the Business Case...........................................................................3-1
3.3 Step 3: Perform Certification and Accreditation.......................................................3-2
3.4 Step 4: Determine Interconnection Requirements...................................................3-2
3.5 Step 5: Document Interconnection Agreement........................................................3-5
3.6 Step 6: Approve or Reject System Interconnection.................................................3-6
4. ESTABLISHING A SYSTEM INTERCONNECTION.........................................................4-1
4.1 Step 1: Develop an Implementation Plan.................................................................4-1
4.2 Step 2: Execute the Implementation Plan................................................................4-1
4.3 Step 3: Activate the Interconnection........................................................................4-6
5. MAINTAINING A SYSTEM INTERCONNECTION............................................................5-1
5.1 Maintain Clear Lines of Communication..................................................................5-1
5.2 Maintain Equipment.................................................................................................5-2
5.3 Manage User Profiles..............................................................................................5-2
5.4 Conduct Security Reviews.......................................................................................5-2
5.5 Analyze Audit Logs..................................................................................................5-2
5.6 Report and Respond to Security Incidents..............................................................5-3
5.7 Coordinate Contingency Planning Activities............................................................5-3
5.8 Perform Change Management.................................................................................5-3
5.9 Maintain System Security Plans..............................................................................5-4
6. DISCONNECTING A SYSTEM INTERCONNECTION......................................................6-1
6.1 Planned Disconnection............................................................................................6-1
6.2 Emergency Disconnection.......................................................................................6-1
6.3 Restoration of Interconnection.................................................................................6-2
Appendix A—Interconnection Security Agreement...................................................................A-1
Appendix B—Memorandum of Understanding/Agreement.......................................................B-1
Appendix C—System Interconnection Implementation Plan....................................................C-1
Appendix D—Glossary..............................................................................................................D-1
Appendix E—References..........................................................................................................E-1
Appendix F—Index...................................................................................................................F-1
187
4. 800-53 Rev3 - Recommended Security Controls for Federal Information Systems
Purpose & Applicability
The purpose of this publication is to provide guidelines for selecting and specifying security controls for
information systems supporting the executive agencies of the federal government to meet the
requirements of FIPS 200, Minimum Security Requirements for Federal Information and Information
Systems. The guidelines apply to all components11 of an information system that process, store, or transmit
federal information. The guidelines have been developed to help achieve more secure information
systems and effective risk management within the federal government by:
• Facilitating a more consistent, comparable, and repeatable approach for selecting and
specifying security controls for information systems and organizations;
• Providing a recommendation for minimum security controls for information systems
categorized in accordance with FIPS 199, Standards for Security Categorization of Federal
Information and Information Systems;
• Providing a stable, yet flexible catalog of security controls for information systems and
organizations to meet current organizational protection needs and the demands of future
protection needs based on changing requirements and technologies;
• Creating a foundation for the development of assessment methods and procedures for
determining security control effectiveness; and
• Improving communication among organizations by providing a common lexicon that
supports discussion of risk management concepts.
The guidelines in this special publication are applicable to all federal information systems12 other than
those systems designated as national security systems as defined in 44 U.S.C., Section 3542.
Chapter Two describes the fundamental concepts associated with security control selection
and specification including: (i) the structural components of security controls and how the
controls are organized into families; (ii) security control baselines; (iii) the use of common
security controls in support of organization-wide information security programs; (iv) security
controls in external environments; (v) assurance in the effectiveness of security controls; and
(vi) the commitment to maintain currency of the individual security controls and the control
baselines.
• Chapter Three describes the process of selecting and specifying security controls for an
information system including: (i) applying the organization’s overall approach to managing
risk; (ii) categorizing the information system and determining the system impact level in
accordance with FIPS 199 and FIPS 200, respectively; (iii) selecting the initial set of baseline
security controls, tailoring the baseline controls, and supplementing the tailored baseline, as
necessary, in accordance with an organizational assessment of risk; and (iv) assessing the
security controls as part of a comprehensive continuous monitoring process.
• Supporting appendices provide essential security control selection and specification-related
information including: (i) general references; (ii) definitions and terms; (iii) acronyms; (iv)
baseline security controls for low-impact, moderate-impact, and high-impact information
systems; (v) minimum assurance requirements; (vi) a master catalog of security controls; (vii)
information security program management controls; (viii) international information security
standards; and (ix) the application of security controls to industrial control systems.
188
5. 800-53A - Guide for Assessing the Security Controls in Federal Information Systems
Executive Summary
The purpose of this publication is to provide guidelines for building effective security assessment plans
and a comprehensive set of procedures for assessing the effectiveness of security controls employed in
information systems supporting the executive agencies of the federal government. The guidelines apply to
the security controls defined in NIST Special Publication 800-53 (as amended), Recommended Security
Controls for Federal Information Systems, and any additional security controls developed by the
organization. The guidelines have been developed to help achieve more secure information systems
within the federal government by:
Enabling more consistent, comparable, and repeatable assessments of security controls;
Facilitating more cost-effective assessments of security controls contributing to the determination
of overall control effectiveness;
Promoting a better understanding of the risks to organizational operations, organizational assets,
individuals, other organizations, and the Nation resulting from the operation and use of federal
information systems; and
Creating more complete, reliable, and trustworthy information for organizational officials—to
support security accreditation decisions, information sharing, and FISMA compliance.
The guidelines provided in this special publication are applicable to all federal information systems other
than those systems designated as national security systems as defined in 44 U.S.C., Section 3542. The
guidelines have been broadly developed from a technical perspective to complement similar guidelines
for national security systems and may be used for such systems with the approval of the Director of
National Intelligence (DNI), the Secretary of Defense (SECDEF), the Chairman of the Committee on
National Security Systems (CNSS), or their designees. State, local, and tribal governments, as well as
private sector organizations that compose the critical infrastructure of the United States, are also
encouraged to consider the use of these guidelines, as appropriate.
Organizations should use as a minimum, NIST Special Publication 800-53A in conjunction with an
approved security plan in developing a viable security assessment plan for producing and compiling the
information necessary to determine the effectiveness of the security controls employed in the information
system. This publication has been developed with the intention of enabling organizations to tailor and
supplement the basic assessment procedures provided. The assessment procedures should be used as a
starting point for and as input to the security assessment plan. In developing effective security assessment
plans, organizations should take into consideration existing information about the security controls to be
assessed (e.g., results from organizational assessments of risk, platform-specific dependencies in the
hardware, software, or firmware,10 and any assessment procedures needed as a result of organizationspecific controls not included in NIST Special Publication 800-53).
The selection of appropriate assessment procedures for a particular information system depends on three
factors:
The security categorization of the information system in accordance with FIPS 199, Standards for
Security Categorization of Federal Information and Information Systems, and NIST Special Publication
800-60, Guide for Mapping Types of Information and Information Systems to Security Categories;
The security controls identified in the approved security plan, including those from NIST Special
Publication 800-53 (as amended) and any organization-specific controls;11 and
The level of assurance that the organization must have in determining the effectiveness of the
security controls in the information system.
189
The extent of security control assessments should always be risk-driven. Organizations should determine
the most cost-effective implementation of this key element in the organization’s information security
program by applying the results of risk assessments, considering the maturity and quality level of the
organization’s risk management processes, and taking advantage of the flexibility in NIST Special
Publication 800-53A. The use of Special Publication 800-53A as a starting point in the process of
defining procedures for assessing the security controls in information systems, promotes a more
consistent level of security within the organization and offers the needed flexibility to customize the
assessment based on organizational policies and requirements, known threat and vulnerability
information, operational considerations, information view assessment as an information gathering
activity, not a security producing activity. The information produced during security control assessments
can be used by an organization to:

Identify potential problems or shortfalls in the organization’s implementation of the NIST Risk
Management Framework;

Identify information system weaknesses and deficiencies;

Prioritize risk mitigation decisions and associated risk mitigation activities;

Confirm that identified weaknesses and deficiencies in the information system have been
addressed;

Support information system authorization (i.e., security accreditation) decisions; and

Support budgetary decisions and the capital investment process.
Organizations are not expected to employ all of the assessment methods and assessment objects contained
within the assessment procedures identified in this document. Rather, organizations have the flexibility to
determine the security control assessment level of effort and resources expended (e.g., which assessment
methods and objects are employed in the assessment). This determination is made on the basis of what
will most cost-effectively accomplish the assessment objectives defined in this publication with sufficient
confidence to support the subsequent determination of the resulting mission or business risk.
NIST Special Publication 800-53A is a companion publication to NIST Special Publication 800-53, not a
replacement or update. Special Publication 800-53 remains the definitive NIST recommendation for
employing security controls in federal information systems.
CHAPTER TWO THE FUNDAMENTALS...................................................................................6
2.1 ASSESSMENTS WITHIN THE SYSTEM DEVELOPMENT LIFE
CYCLE........................................................................6
2.2 STRATEGY FOR CONDUCTING SECURITY CONTROL
ASSESSMENTS.....................................................................6
2.3 BUILDING AN EFFECTIVE ASSURANCE
CASE....................................................................................................8
2.4 ASSESSMENT
PROCEDURES........................................................................................................................8
2.5 EXTENDED ASSESSMENT
PROCEDURE..........................................................................................................13
CHAPTER THREE THE PROCESS........................................................................................14
190
3.1 PREPARING FOR SECURITY CONTROL
ASSESSMENTS......................................................................................14
3.2 DEVELOPING SECURITY ASSESSMENT
PLANS.................................................................................................16
3.3 CONDUCTING SECURITY CONTROL
ASSESSMENTS..........................................................................................24
3.4 ANALYZING SECURITY ASSESSMENT REPORT
RESULTS...................................................................................25
TABLE 1-1: SECURITY CONTROL CLASSES, FAMILIES, AND IDENTIFIERS
IDENTIFIER FAMILY CLASS
AC Access Control Technical
AT Awareness and Training Operational
AU Audit and Accountability Technical
CA Security Assessment and Authorization Management
CM Configuration Management Operational
CP Contingency Planning Operational
IA Identification and Authentication Technical
IR Incident Response Operational
MA Maintenance Operational
MP Media Protection Operational
PE Physical and Environmental Protection Operational
PL Planning Management
PS Personnel Security Operational
RA Risk Assessment Management
SA System and Services Acquisition Management
SC System and Communications Protection Technical
SI System and Information Integrity Operational
PM Program Management Management
24 Of the eighteen security control families in NIST Special Publication 800-53, seventeen families are
described in the
security control catalog in Appendix F, and are closely aligned with the seventeen minimum security
requirements for
federal information and information systems in FIPS 200. One additional family (Program Management
[PM] family)
in Appendix G provides controls for information security programs. This family, while not referenced in
FIPS 200,
provides security controls at the organizational rather than the information-system level.
191
6. 800-37 Rev1 - Guide for the Security Certification and Accreditation of Federal
Information Systems /Guide for Applying the Risk Management Framework to Federal
Information Systems
Synopsis
The security authorization package contains: the system security plan (SSP); the security
assessment report (SAR); and the plan of action and milestones (POAM).
Background
NIST in partnership with the Department of Defense (DoD), the Office of the Director of
National Intelligence (ODNI), and the Committee on National Security Systems (CNSS), has
developed a common information security framework for the federal government and its
contractors. The intent of this common framework is to improve information security, strengthen
risk management processes, and encourage reciprocity among federal agencies. This publication,
developed by the Joint Task Force Transformation Initiative Working Group, transforms the
traditional Certification and Accreditation (C&A) process into the six-step Risk Management
Framework (RMF). The revised process emphasizes: (i) building information security
capabilities into federal information systems through the application of state-of-the-practice
management, operational, and technical security controls; (ii) maintaining awareness of the security state
of information systems on an ongoing basis though enhanced monitoring processes;
and (iii) providing essential information to senior leaders to facilitate decisions regarding the
acceptance of risk to organizational operations and assets, individuals, other organizations, and
the Nation arising from the operation and use of information systems.
The RMF has the following characteristics:
• Promotes the concept of near real-time risk management and ongoing information system
authorization through the implementation of robust continuous monitoring processes;
• Encourages the use of automation to provide senior leaders the necessary information to
make cost-effective, risk-based decisions with regard to the organizational information
systems supporting their core missions and business functions;
• Integrates information security into the enterprise architecture and system development life
cycle;
• Provides emphasis on the selection, implementation, assessment, and monitoring of security
controls, and the authorization of information systems;
• Links risk management processes at the information system level to risk management
processes at the organization level through a risk executive (function); and
• Establishes responsibility and accountability for security controls deployed within
organizational information systems and inherited by those systems (i.e., common controls).
The risk management process described in this publication changes the traditional focus of C&A
as a static, procedural activity to a more dynamic approach that provides the capability to more
effectively manage information system-related security risks in highly diverse environments of
complex and sophisticated cyber threats, ever-increasing system vulnerabilities, and rapidly
changing missions.
192
PURPOSE AND APPLICABILITY
The purpose of this publication is to provide guidelines for applying the Risk Management
Framework to federal information systems to include conducting the activities of security
categorization,9 security control selection and implementation, security control assessment,
information system authorization,10 and security control monitoring. The guidelines have been
developed:
• To ensure that managing information system-related security risks is consistent with the
organization’s mission/business objectives and overall risk strategy established by the senior
leadership through the risk executive (function);
• To ensure that information security requirements, including necessary security controls, are
integrated into the organization’s enterprise architecture and system development life cycle
processes;
• To support consistent, well-informed, and ongoing security authorization decisions (through
continuous monitoring), transparency of security and risk management-related information,
and reciprocity;11 and
• To achieve more secure information and information systems within the federal government
through the implementation of appropriate risk mitigation strategies.
This publication satisfies the requirements of the Federal Information Security Management Act
(FISMA) and meets or exceeds the information security requirements established for executive
agencies12 by the Office of Management and Budget (OMB) in Circular A-130, Appendix III,
Security of Federal Automated Information Resources. The guidelines in this publication are
applicable to all federal information systems other than those systems designated as national
security systems as defined in 44 U.S.C., Section 3542. The guidelines have been broadly
developed from a technical perspective to complement similar guidelines for national security
systems and may be used for such systems with the approval of appropriate federal officials
exercising policy authority over such systems. State, local, and tribal governments, as well as
private sector organizations are encouraged to consider using these guidelines, as appropriate.
Chapter Two describes the fundamental concepts associated with managing information
system-related security risks including: (i) an organization-wide view of risk management
and the application of the Risk Management Framework; (ii) the integration of information
security requirements into the system development life cycle; (iii) the establishment of
information system boundaries; and (iv) the allocation of security controls to organizational
information systems as system-specific, hybrid, or common controls.
Chapter Three describes the tasks required to apply the Risk Management Framework to
information systems including: (i) the categorization of information and information systems;
(ii) the selection of security controls; (iii) the implementation of security controls; (iv) the
assessment of security control effectiveness; (v) the authorization of the information system;
and (vi) the ongoing monitoring of security controls and the security state of the information
system.
Supporting appendices provide additional information regarding the application of the Risk
Management Framework to information systems including: (i) references; (ii) glossary; (iii)
acronyms; (iv) roles and responsibilities; (v) summary of Risk Management Framework
tasks; (vi) security authorization of information systems; (vii) monitoring the security state of
information systems; (viii) operational scenarios; and (ix) security controls in external
environments.
193
7. 800-59 - Guideline for Identifying an Information System as a National Security System
Executive Summary
Defense, including the National Security Agency, for identifying an information system
as a national security system. The basis for these guidelines is the Federal Information
Security Management Act of 2002 (FISMA, Title III, Public Law 107-347, December 17,
2002), which provides government-wide requirements for information security,
superseding the Government Information Security Reform Act and the Computer
Security Act.
Except for national security systems as defined by FISMA, the Secretary of Commerce is responsible for
prescribing standards and guidelines pertaining to Federal information systems on the basis of standards
and guidelines developed by NIST. The Committee on National Security Systems (CNSS) along with
Federal agencies that operate systems falling within the definition of national security systems provide
security standards and guidance for national security systems. In addition to defining the term national
security system FISMA amended the NIST Act, at 15 U.SC. 278g-3(b)(3), to require NIST to provide
guidelines for identifying an information system as a national security system. As stated in the House
Committee report, ―This guidance is not to govern such systems, but
rather to ensure that agencies receive consistent guidance on the identification of systems
that should be governed by national security system requirements.‖ Report of the Committee on
Government Reform, U. S House of Representatives, Report 107-787, November 14, 2002, p. 85.
The Department of Defense and the Director, Central Intelligence have authority to
develop policies, guidelines, and standards for national security systems. The Director,
Central Intelligence is responsible for policies relating to systems processing intelligence
information. The Committee for National Security Systems, whose executive agent is the
National Security Agency, was established to develop operating policies, procedures,
guidelines, instructions and standards as necessary to implement provisions of the
National Policy for the Security of National Security Telecommunications and Information Systems (see
NSTISSD Number 502). The Director of the Office of
Management and Budget (OMB) retains responsibility for oversight of national security
system information security policies and practices with respect to:
Overseeing agency compliance with the requirements of Subchapter III of
Chapter 35 of Title 44, United States Code, including through any authorized
action under Title 40, United States Code, section 11303, to enforce
accountability for compliance with such requirements; and
Reporting to Congress no later than March 1 of each year on agency compliance
with the requirements of Subchapter III of Chapter 35 of Title 44 United States
Code, including –
o A summary of the findings of evaluations required by 44 U.S.C. 3545;
o An assessment of the development, promulgation, and adoption of, and
compliance with, standards developed under 15 USC 278g-3 and
promulgated under 40 U.S.C. 11331;
o Significant deficiencies in agency information security practices;
o Planned remedial action to address such deficiencies; and
o A summary of, and OMB views on, the report prepared by NIST under 15
USC 278g-3.
Accordingly, the purpose of these guidelines is not to establish requirements for national
security systems, but rather to assist agencies in determining which, if any, of their
systems are national security systems as defined by FISMA and are to be governed by
applicable requirements for such systems, issued in accordance with law and as directed
194
by the President.
1.0 Introduction ........................................................................................1
2.0 Basis for Identification of National Security Systems............................3
3.0 Method for Identifying National Security Systems...............................5
3.1 Determination of Responsibilities............................................................................. 5
3.2 National Security System Identification Checklist ................................................... 6
3.3 Dispute Resolution.................................................................................................... 6
Appendix A: National Security System Identification Checklist..................7
A.1 Minimum Question Set ........................................................................................... 7
A.1.1 Intelligence Activities ....................................................................................... 7
A.1.2 Cryptologic Activities ....................................................................................... 8
A.1.3 Command and Control of Military Forces ........................................................ 8
A.1.4 Weapons and Weapons Systems ....................................................................... 8
A.1.5 Systems Critical to the Direct Fulfillment of Military or Intelligence Missions
.................................................................................................................................... 8
A.1.6 Classified Systems ............................................................................................ 9
A.2 Optional Checklist Material..................................................................................... 9
A.3 Checklist................................................................................................................ 10
Appendix B: References.......................................................................... 11
Appendix C: Glossary of Terms .............................................................. 13
8. 800-60 Rev1- Guide for Mapping Types of Information and Information Systems to Security
Categories: (2 Volumes)
Executive Summary
Title III of the E-Government Act (Public Law 107-347), titled the Federal Information Security
Management Act (FISMA), tasked the National Institute of Standards and Technology (NIST) to
develop:
Standards to be used by all Federal agencies to categorize all information and information
systems collected or maintained by or on behalf of each agency 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 such category; and
Minimum information security requirements (i.e., management, operational, and technical
security controls), for information and information systems in each such category.
In response to the second of these tasks, this guideline has been developed to assist Federal
government agencies to categorize information and information systems. The guideline’s objective is
to facilitate application of appropriate levels of information security according to a range of levels of
impact or consequences that might result from the unauthorized disclosure, modification, or use of
the information or information system. This guideline assumes that the user is familiar with
Standards for Security Categorization of Federal Information and Information Systems (Federal
Information Processing Standard [FIPS] 199). The guideline and its appendices:
Review the security categorization terms and definitions established by FIPS 199;
Recommend a security categorization process;
195
Describe a methodology for identifying types of Federal information and information
systems;
Suggest provisional1 security impact levels for common information types;
Discuss information attributes that may result in variances from the provisional impact level
assignment; and
Describe how to establish a system security categorization based on the system’s use,
connectivity, and aggregate information content.
This document is intended as a reference resource rather than as a tutorial and not all of the material
will be relevant to all agencies. This document includes two volumes, a basic guideline and a volume
of appendices. Users should review the guidelines provided in Volume I, then refer to only that
specific material from the appendices that applies to their own systems and applications. The
provisional impact assignments are provided in Volume II, Appendix C and D. The basis employed
in this guideline for the identification of information types is the Office of Management and Budget’s
Federal Enterprise Architecture (FEA) Program Management Office (PMO) October 2007
publication, The Consolidated Reference Model Document Version 2.3.
Purpose and Applicability
NIST SP 800-60 addresses the FISMA direction to develop guidelines recommending the types of
information and information systems to be included in each category of potential security impact.
This guideline is intended to help agencies consistently map security impact levels to types of: (i)
information (e.g., privacy, medical, proprietary, financial, contractor sensitive, trade secret,
investigation); and (ii) information systems (e.g., mission critical, mission support, administrative).
This guideline applies to all Federal information systems other than national security systems.
National security systems store, process, or communicate national security information.2
FISMA Framework documents:
FIPS 199
FIPS 200
NIST SP 800-30
NIST SP 800-37,
NIST Draft SP 800-39, Managing Risk from Information Systems: An Organization Perspective
NIST SP 800-53,
NIST SP 800-53A
NIST SP 800-59
NIST SP 800-60
NIST Risk Management Framework:
196
9. 800-66 - An Introductory Resource Guide for Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule
Executive Summary
Some federal agencies, in addition to being subject to the Federal Information Security Management
Act of 2002 (FISMA), are also subject to similar requirements of the Health Insurance Portability
and Accountability Act of 1996 (HIPAA) Security Rule (the Security Rule), if the agency is a
covered entity as defined by the rules implementing HIPAA.
The HIPAA Security Rule specifically focuses on the safeguarding of electronic protected health
information (EPHI). Although FISMA applies to all federal agencies and all information types, only
a subset of agencies are subject to the HIPAA Security Rule based on their functions and use of
EPHI. All HIPAA covered entities, which include some federal agencies, must comply with the
Security Rule, which specifically focuses on protecting the confidentiality, integrity, and availability
of EPHI, as defined in the Security Rule. The EPHI that a covered entity creates, receives, maintains,
or transmits must be protected against reasonably anticipated threats, hazards, and impermissible
197
uses and/or disclosures. In general, the requirements, standards, and implementation specifications of
the Security Rule apply to the following covered entities:
Covered Healthcare Providers—Any provider of medical or other health services, or
supplies, who transmits any health information in electronic form in connection with a transaction for
which the Department of Health and Human Services (DHHS) has adopted a standard.
Health Plans—Any individual or group plan that provides, or pays the cost of, medical care,
including certain specifically listed governmental programs (e.g., a health insurance issuer and the
Medicare and Medicaid programs).
Healthcare Clearinghouses—A public or private entity that processes another entity’s
healthcare transactions from a standard format to a nonstandard format, or vice versa.
Medicare Prescription Drug Card Sponsors –A nongovernmental entity that offered an
endorsed discount drug program under the Medicare Modernization Act. This fourth category of
―covered entity‖ remained in effect until the drug card program ended in 2006.
NIST publications, many of which are required for federal agencies, can serve as voluntary
guidelines and best practices for state, local, and tribal governments and the private sector, and may
provide enough depth and breadth to help organizations of many sizes select the type of
implementation that best fits their unique circumstances. NIST security standards and guidelines
(Federal Information Processing Standards [FIPS], Special Publications in the 800 series), which can
be used to support the requirements of both HIPAA and FISMA, may be used by organizations to
help provide a structured, yet flexible framework for selecting, specifying, employing, and evaluating
the security controls in information systems.
This Special Publication (SP), which discusses security considerations and resources that may
provide value when implementing the requirements of the HIPAA Security Rule, was written to:
•
Help to educate readers about information security terms used in the HIPAA Security Rule
and to improve understanding of the meaning of the security standards set out in the Security
Rule;
•
Direct readers to helpful information in other NIST publications on individual topics
addressed by the HIPAA Security Rule; and
•
Aid readers in understanding the security concepts discussed in the HIPAA Security Rule.
This publication does not supplement, replace, or supersede the HIPAA Security Rule itself.
Figure 1 shows all the components of HIPAA and illustrates that the focus of this document is on the
security provisions of the statute and the regulatory rule. Figure 1. HIPAA Components
198
10. 800-115 - Technical Guide to Information Security Testing and Assessment
Executive Summary
An information security assessment is the process of determining how effectively an entity being assessed
(e.g., host, system, network, procedure, person—known as the assessment object) meets specific security
objectives. Three types of assessment methods can be used to accomplish this—testing, examination, and
interviewing. Testing is the process of exercising one or more assessment objects under specified
conditions to compare actual and expected behaviors. Examination is the process of checking, inspecting,
reviewing, observing, studying, or analyzing one or more assessment objects to facilitate understanding,
achieve clarification, or obtain evidence. Interviewing is the process of conducting discussions with
individuals or groups within an organization to facilitate understanding, achieve clarification, or identify
the location of evidence. Assessment results are used to support the determination of security control
effectiveness over time.
This document is a guide to the basic technical aspects of conducting information security assessments. It
presents technical testing and examination methods and techniques that an organization might use as part
of an assessment, and offers insights to assessors on their execution and the potential impact they may
have on systems and networks. For an assessment to be successful and have a positive impact on the
security posture of a system (and ultimately the entire organization), elements beyond the execution of
testing and examination must support the technical process. Suggestions for these activities—including a
robust planning process, root cause analysis, and tailored reporting—are also presented in this guide.
The processes and technical guidance presented in this document enable organizations to:
199

Develop information security assessment policy, methodology, and individual roles and
responsibilities related to the technical aspects of assessment

Accurately plan for a technical information security assessment by providing guidance on
determining which systems to assess and the approach for assessment, addressing logistical
considerations, developing an assessment plan, and ensuring legal and policy considerations
are addressed

Safely and effectively execute a technical information security assessment using the
presented methods and techniques, and respond to any incidents that may occur during the
assessment

Appropriately handle technical data (collection, storage, transmission, and destruction)
throughout the assessment process

Conduct analysis and reporting to translate technical findings into risk mitigation actions that
will improve the organization’s security posture.
The information presented in this publication is intended to be used for a variety of assessment purposes.
For example, some assessments focus on verifying that a particular security control (or controls) meets
requirements, while others are intended to identify, validate, and assess a system’s exploitable security
weaknesses. Assessments are also performed to increase an organization’s ability to maintain a proactive
computer network defense. Assessments are not meant to take the place of implementing security controls
and maintaining system security.
To accomplish technical security assessments and ensure that technical security testing and examinations
provide maximum value, NIST recommends that organizations:

Establish an information security assessment policy. This identifies the organization’s
requirements for executing assessments, and provides accountability for the appropriate
individuals to ensure assessments are conducted in accordance with these requirements. Topics
that an assessment policy should address include the organizational requirements with which
assessments must comply, roles and responsibilities, adherence to an established assessment
methodology, assessment frequency, and documentation requirements.

Implement a repeatable and documented assessment methodology. This provides consistency
and structure to assessments, expedites the transition of new assessment staff, and addresses
resource constraints associated with assessments. Using such a methodology enables
organizations to maximize the value of assessments while minimizing possible risks introduced
by certain technical assessment techniques. These risks can range from not gathering sufficient
information on the organization’s security posture for fear of impacting system functionality to
affecting the system or network availability by executing techniques without the proper
safeguards in place. Processes that minimize risk caused by certain assessment techniques include
using skilled assessors, developing comprehensive assessment plans, logging assessor activities,
performing testing off-hours, and conducting tests on duplicates of production systems (e.g.,
development systems). Organizations need to determine the level of risk they are willing to
accept for each assessment, and tailor their approaches accordingly.

Determine the objectives of each security assessment, and tailor the approach accordingly.
Security assessments have specific objectives, acceptable levels of risk, and available resources.
Because no individual technique provides a comprehensive picture of an organization’s security
200
when executed alone, organizations should use a combination of techniques. This also helps
organizations to limit risk and resource usage.

Analyze findings, and develop risk mitigation techniques to address weaknesses. To ensure
that security assessments provide their ultimate value, organizations should conduct root cause
analysis upon completion of an assessment to enable the translation of findings into actionable
mitigation techniques. These results may indicate that organizations should address not only
technical weaknesses, but weaknesses in organizational processes and procedures as well.
Purpose and Scope
The purpose of this document is to provide guidelines for organizations on planning and conducting
technical information security testing and assessments, analyzing findings, and developing mitigation
strategies. It provides practical recommendations for designing, implementing, and maintaining technical
information relating to security testing and assessment processes and procedures, which can be used for
several purposes—such as finding vulnerabilities in a system or network and verifying compliance with a
policy or other requirements. This guide is not intended to present a comprehensive information security
testing or assessment program, but rather an overview of the key elements of technical security testing
and assessment with emphasis on specific techniques, their benefits and limitations, and recommendations
for their use.
This document replaces NIST Special Publication 800-42, Guideline on Network Security Testing.
11. FIPS 200 - Minimum Security Requirements for Federal Information and Information Systems
Explanation
The E-Government Act (P.L. 107-347), passed by the one hundred and seventh Congress and signed into law
by the President in December 2002, recognized the importance of information security to the economic and
national security interests of the United States. Title III of the E-Government Act, entitled the Federal
Information Security Management Act (FISMA), emphasizes the need for each federal agency to develop,
document, and implement an enterprise-wide 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. FISMA directed the promulgation of federal standards for: (i)
the security categorization of federal information and information systems based on the objectives of providing
appropriate levels of information security according to a range of risk levels; and (ii) minimum security
requirements for information and information systems in each such category. This standard addresses the
specification of minimum security requirements for federal information and information systems.
Purpose and Scope
The purpose of this document is to provide guidelines for organizations on planning and conducting
technical information security testing and assessments, analyzing findings, and developing mitigation
strategies. It provides practical recommendations for designing, implementing, and maintaining technical
information relating to security testing and assessment processes and procedures, which can be used for
several purposes—such as finding vulnerabilities in a system or network and verifying compliance with a
policy or other requirements. This guide is not intended to present a comprehensive information security
testing or assessment program, but rather an overview of the key elements of technical security testing
and assessment with emphasis on specific techniques, their benefits and limitations, and recommendations
for their use.
This document replaces NIST Special Publication 800-42, Guideline on Network Security Testing.
201
12. FIPS 199 - Standards for Security Categorization of Federal Information and Information Systems
Purpose
The E-Government Act of 2002 (Public Law 107-347), passed by the one hundred and seventh Congress and
signed into law by the President in December 2002, recognized the importance of information security to the
economic and national security interests of the United States. Title III of the E-Government Act, entitled the
Federal Information Security Management Act of 2002 (FISMA), tasked NIST with responsibilities for
standards and guidelines, including the development of:
Standards to be used by all federal agencies to categorize all information and information systems
collected or maintained by or on behalf of each agency 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; and
Minimum information security requirements (i.e., management, operational, and technical controls),
for information and information systems in each such category.
FIPS Publication 199 addresses the first task cited—to develop standards for categorizing information and
information systems. Security categorization standards for information and information systems provide a
common framework and understanding for expressing security that, for the federal government, promotes: (i)
effective management and oversight of information security programs, including the coordination of
information security efforts throughout the civilian, national security, emergency preparedness, homeland
security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and
Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures,
and practices. Subsequent NIST standards and guidelines will address the second and third tasks cited.
2 APPLICABILITY
These standards shall apply to: (i) all information within the federal government other than that information
that has been determined pursuant to Executive Order 12958, as amended by Executive Order 13292, or any
predecessor order, or by the Atomic Energy Act of 1954, as amended, to require protection against
unauthorized disclosure and is marked to indicate its classified status; and (ii) all federal information systems
other than those information systems designated as national security systems as defined in 44 United States
Code Section 3542(b)(2). Agency officials shall use the security categorizations described in FIPS Publication
199 whenever there is a federal requirement to provide such a categorization of information or information
systems. Additional security designators may be developed and used at agency discretion. State, local, and
tribal governments as well as private sector organizations comprising the critical infrastructure of the United
States may consider the use of these standards as appropriate. These standards are effective upon approval by
the Secretary of Commerce.
202
Table 1 summarizes the potential impact definitions for each security objective—confidentiality, integrity, and
availability. POTENTIAL IMPACT
Security Objective
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]
LOW
MODERATE
HIGH
The unauthorized
disclosure of information
could be expected to have
a limited adverse effect
on organizational
operations, organizational
assets, or individuals.
The unauthorized
disclosure of information
could be expected to have
a serious adverse effect
on organizational
operations, organizational
assets, or individuals.
The unauthorized
disclosure of information
could be expected to have
a severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
The unauthorized
modification or
destruction of information
could be expected to have
a limited adverse effect
on organizational
operations, organizational
assets, or individuals.
The unauthorized
modification or
destruction of information
could be expected to have
a serious adverse effect
on organizational
operations, organizational
assets, or individuals.
The unauthorized
modification or
destruction of information
could be expected to have
a severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
The disruption of access
to or use of information
or an information system
could be expected to have
a limited adverse effect
on organizational
operations, organizational
assets, or individuals.
The disruption of access
to or use of information
or an information system
could be expected to have
a serious adverse effect
on organizational
operations, organizational
assets, or individuals.
The disruption of access
to or use of information
or an information system
could be expected to have
a severe or catastrophic
adverse effect on
organizational operations,
organizational assets, or
individuals.
203
Domain 6 – NIST Interagency Reports
NIST Interagency or Internal Reports (NISTIRs) describe research of a technical nature of interest to
a specialized audience. These NISTIRs can be downloaded at the following website:
http://csrc.nist.gov/
1. IR 7581 - System and Network Security Acronyms and Abbreviations
2. IR 7564 - Directions in Security Metrics Research
3. IR 7536 - 2008 Computer Security Division Annual Report
4. IR 7359 - Information Security Guide for Government Executives
5. IR 7358 - Program Review for Information Security Management Assistance (PRISMA)
6. IR 7316 - Assessment of Access Control Systems
7. IR 7298 - Glossary of Key Information Security Terms
8. IR 7206 - Smart Cards and Mobile Device Authentication: An Overview and Implementation
1. IR 7581 - System and Network Security Acronyms and Abbreviations
Synopsis: 25 pages of Acronyms and Abbreviations
2. IR 7564 - Directions in Security Metrics Research
Synopsis: The document is all text: no graphics of any kind.
Abstract
More than 100 years ago, Lord Kelvin insightfully observed that measurement is vital to deep knowledge
and understanding in physical science. During the last few decades, researchers have made various
attempts to develop measures and systems of measurement for computer security with varying degrees of
success. This paper provides an overview of the security metrics area and looks at possible avenues of
research that could be pursued to advance the state of the art.
Relevant Table of Contents Excerpt
3. Aspects of Security Measurement
3.1 Correctness and Effectiveness
3.2 Leading Versus Lagging Indicators
3.3 Organizational Security Objectives
3.4 Qualitative and Quantitative Properties
3.5 Measurements of the Large Versus the Small
4. Possible Research Areas
4.1 Formal Models of Security Measurement and Metrics
4.2 Historical Data Collection and Analysis
4.3 Artificial Intelligence Assessment Techniques
4.4 Practicable Concrete Measurement Methods
4.5 Intrinsically Measurable Components
Conclusion
204
The security metrics area poses hard and multi-faceted problems for researchers. Quick resolution is not
expected and the likelihood is that not all aspects of the problem are resolvable. Furthermore, only some
of those aspects that are resolvable may be able to be done satisfactorily, meeting expectations of
repeatability, reproducibility, relevance, timeliness, and cost. Several factors impede progress in security
metrics:
 The lack of good estimators of system security.
 The entrenched reliance on subjective, human, qualitative input.
 The protracted and delusive means commonly used to obtain measurements.
 The dearth of understanding and insight into the composition of security mechanisms.
This paper proposes several lines of research that address these factors and could help to progress the
state of the art in security metrics. The following research areas were identified:
 Formal Models of Security Measurement and Metrics
 Historical Data Collection and Analysis
 Artificial Intelligence Assessment Techniques
 Practicable Concrete Measurement Methods
 Intrinsically Measurable Components.
Each area in itself is quite extensive and requires a commitment to sustain the long-term research and
development needed to be successful
3. IR 7536 - 2008 Computer Security Division Annual Report
Synopsis: What can I say? – It‟s simply an annual report that highlights current accomplishments of NCSD;
organized by the divisions of NCSD.
4. IR 7359 - Information Security Guide for Government Executives
Abstract
Information Security for Government Executives provides a broad overview of information security
program concepts to assist senior leaders in understanding how to oversee and support the development
and implementation of information security programs. Executives are responsible for:

Establishing the organization’s information security program;

Setting program goals and priorities that support the mission of the organization; and

Making sure resources are available to support the program and make it successful.
Senior leadership commitment to security is more important now than ever before. Studies have shown
that senior management’s commitment to information security initiatives is the single most critical
element that impacts an information security program’s success.
Meeting this need necessitates senior leadership to focus on effective information security governance
and support which requires integration of security into the strategic and daily operations of an
organization. When considering this challenge, several key security questions emerge for the executive:

Why do I need to invest in information security?

Where do I need to focus my attention in accomplishing critical information security goals?

What are the key activities to build an effective information security program?
205

What are the information security laws, regulations, standards, and guidance that I need to
understand to build an effective information security program?

Where can I learn more to assist me in evaluating the effectiveness of my information security
program?
IR 7359 provides the answers to those questions.
Other Key Points


Information security program implementations often suffer from inadequate resources—
management commitment, time, money, or expertise.
Executives should ensure a life-cycle approach to compliance by monitoring the status of their
programs

IR 7359 refers to NIST SP 800-100, Information Security Handbook: A Guide for Managers,
and discusses summary guidance on the key elements of an effective security program.

IR 7359 directs executives to other NIST and OMB guidance and refers to public laws governing
Information Security.
5. IR 7358 - Program Review for Information Security Management
Assistance (PRISMA)
Abstract
Several sources of guidance, policies, standards and legislative acts provide many requirements for the federal
agencies when protecting entrusted information. Various assessments, reviews, and evaluations are an outcome of
these information security requirements to monitor federal agency compliance. The manner in which these
monitoring approaches are implemented may be very different, impacting agency resource constraints. The Federal
Information Security Management Act (FISMA) of 2002 charged NIST to provide technical assistance to agencies
regarding compliance with the standards and guidelines developed for securing information systems, as well as
information security policies, procedures, and practices. This Interagency Report provides an overview of the NIST
Program Review for Information Security Management Assistance (PRISMA) methodology. PRISMA is a tool
developed and implemented by NIST for reviewing the complex information security requirements and posture of a
federal information security program. This report is provided as a framework for instructional purposes s to assist
information security personnel, internal reviewers, auditors, and agency Inspector General (IG) staff personnel in
reviewing information security programs.

The PRISMA methodology is a means of employing a standardized approach to review and measure the
information security posture of an information security program.
Primary Objectives of PRISMA:
 Assist agencies in improving security/protection of federal information and Information Technology (IT)
systems and their interrelated components (including contractors and state and local governments acting on
behalf of federal organizations);

Help reduce disruption of critical federal operations and assets;

Improve Federal agency critical infrastructure protection (CIP) planning and implementation efforts;

Support the implementation of more systematic, risk-based, and cost-effective information security
frameworks and strategies.
206
An output of PRISMA is a maturity-based scorecard focusing on nine (9) primary review Topic Areas (TAs) of
information security (see, Table 1-1). This output provides executive management a clear indication of the
information security posture of the agency’s information security program which can be used for executive decisionmaking.
Table 1-1, Nine Topic Areas (TA) with Sample Maturity Level Review Results
TA
1
2
3
4
5
6
7
8
9
Management,
Operational, and
Technical Areas
Information Security
Management & Culture
Information Security
Planning
Security Awareness,
Training, and Education
Budget and Resources
Life Cycle Management
Certification and
Accreditation
Critical Infrastructure
Protection
Incident and
Emergency Response
Security Controls
Policy
Procedures
Implemented
0.63
0.60
0.30
Tested
Integrated
0.10
Noncompliant
Partially
Compliant
0.00
0.20
Compliant
Compliant
.80
Compliant
Compliant
Summary
PRISMA is a methodical and tested approach for information security personnel, internal reviews, auditors, and
inspectors general to provide:

A picture of the information security posture of the information security program for executive decisionmakers and others,

Identification of high level issues,

Corrective actions to resolve identified issues,

A training tool to learn what is required to advance to the next PRISMA maturity level, and

Supporting material for funding and resource approval and priority.
PRISMA results in an improved agency capability to:

Identify and mitigate existing vulnerabilities,

Act knowledgeably and wisely to protect federal information systems, and

Prepare for future security threats.
6. IR 7316 - Assessment of Access Control Systems
Abstract
Adequate security of information and information systems is a fundamental management responsibility. Nearly all
applications that deal with financial, privacy, safety, or defense include some form of access control. Access control
is concerned with determining the allowed activities of legitimate users, mediating every attempt by a user to access
a resource in the system. In some systems, complete access is granted after successful authentication of the user, but
most systems require more sophisticated and complex control. In addition to the authentication mechanism (such as
a password), access control is concerned with how authorizations are structured. In some cases, authorization may
mirror the structure of the organization, while in others it may be based on the sensitivity level of various documents
207
and the clearance level of the user accessing those documents. This publication explains some of the commonly used
access control services available in information technology systems.
Organizations planning to implement an access control system should consider three abstractions: access control
policies, models, and mechanisms. Access control policies are high-level requirements that specify how access is
managed and who may access information under what circumstances. For instance, policies may pertain to resource
usage within or across organizational units or may be based on need-to-know, competence, authority, obligation, or
conflict-of-interest factors. At a high level, access control policies are enforced through a mechanism that translates
a user’s access request, often in terms of a structure that a system provides. An access control list is a familiar
example of an access control mechanism. Access control models bridge the gap in abstraction between policy and
mechanism. Rather than attempting to evaluate and analyze access control systems exclusively at the mechanism
level, security models are usually written to describe the security properties of an access control system. Security
models are formal presentations of the security policy enforced by the system and are useful for proving theoretical
limitations of a system. Discretionary access control, which allows the creator of a file to delegate access to others,
is one of the simplest examples of a model.
As systems grow in size and complexity, access control is a special concern for systems that are distributed across
multiple computers. These distributed systems can be a formidable challenge for developers, because they may use a
variety of access control mechanisms that must be integrated to support the organization’s policy; for example, rolebased access control that can enforce administrator-specified rules is often used. Popular database management
system designs, such as Structured Query Language (SQL), incorporate many aspects of role- and rule-based access.
Services that are particularly useful in implementing distributed access control include the Lightweight Directory
Access Protocol (LDAP), capability-based Kerberos, and the Extensible Markup Language (XML)-based Extensible
Access Control Markup Language (XACML).
A state of access control is said to be safe if no permission can be leaked to an unauthorized or uninvited principal.
To assure the safety of an access control system, it is essential to make certain that the access control configuration
(e.g., access control model) will not result in the leakage of permissions to an unauthorized principal. Even though
the general safety computation is proven undecidable [HRU76], practical mechanisms exist for achieving the safety
requirement, such as safety constraints built into the mechanism.
Access control systems come with a wide variety of features and administrative capabilities, and the operational
impact can be significant. In particular, this impact can pertain to administrative and user productivity, as well as to
the organization’s ability to perform its mission. Therefore, it is reasonable to use a quality metric to verify the
administrative capabilities, administrative cost, policy coverage, extensibility, and performance qualities of access
control systems.
Appendix C summarizes mechanisms and models supported by popular platforms such as Microsoft Windows,
UNIX/Linux, and SQL database management systems.
I thought it useful to include just the TOC. Key Points are embedded in the TOC as deemed useful.
Relevant Table of Contents Excerpt
2 OVERVIEW OF ACCESS CONTROL
2.1 Concepts
2.2 Policies, Models, and Mechanisms
2.2.1 Discretionary Access Control (DAC)
2.2.2 Non-Discretionary Access Control
3 CAPABILITIES AND LIMITATIONS OF ACCESS CONTROL MECHANISMS11
3.1 Access Control List (ACL) and Limitations
3.2 Protection Bits and Limitations
3.3 Capability List and Limitations
3.4 Role-Based Access Control (RBAC) and Limitations
3.4.1 Core
3.4.2 Hierarchical
3.4.3 Statically Constrained
3.4.4 Dynamically Constrained
3.4.5 Limitations of RBAC
208
3.5 Rule-Based Access Control (RuBAC) and Limitations
 It is important to note that there is no commonly understood definition or formally defined standard for rulebased access control as there is for DAC, MAC, and RBAC. ―Rule-based access‖ is a generic term applied to
systems that allow some form of organization-defined rules…
3.6 XML-Based Access Control Languages and Limitations
3.6.1 The Extensible Access Control Markup Language (XACML)
3.6.2 Using XML for Other Access Control Models
3.6.3 Limitations of XML-Based Access Control Languages
4 CAPABILITIES AND LIMITATIONS OF ACCESS CONTROL FOR DISTRIBUTED SYSTEMS
4.1 User Grouping by Roles
4.2 Access Rules
4.3 Centralized Control
4.3.1 Centralized Object Access
4.3.2 Delegation of Administration
4.4 Limitations for Distributed Systems
5 SAFETY LIMITATIONS
209
5.1 Achieving Safety................................................................................................33
5.1.1 Restricted Access Control Model for Safety..............................................33
5.1.2 Constraints for Safety................................................................................33
5.2 Separation of Duty and Safety...........................................................................34
5.2.1 Static Separation of Duty (SSOD)..............................................................34
5.2.2 Dynamic Separation of Duty (DSOD).......................................................35
6 QUALITY METRICS FOR ACCESS CONTROL SYSTEMS...........................36
6.1 Quality Metrics..................................................................................................36
6.1.1 The steps required for assigning and dis-assigning user capabilities into the
system............................................................................................................37
6.1.2 The steps required for assigning and dis-assigning object access control entries into the
system...................................................................................37
6.1.3 The degree to which an access control system supports the concept of least
privilege.............................................................................................................37
6.1.4 Support for separation of duty...................................................................37
6.1.5 Number of relationships required to create an access control policy.......38
6.1.6 The degree to which an access control system is adaptable to the implementation and
evolution of access control policies..........................................38
6.1.7 The horizontal scope (across platforms and applications) of control in which users and
resources are regulated under an access control policy................39
6.1.8 The vertical scope (between application, DBMS, and OS) of control.......39
6.1.9 Support for safety.......................................................................................39
6.1.10 The degree of freedoms for AC management.............................................40
6.1.11 Performance of AC enforcement................................................................40
6.1.12 Policy conflicts that the access control system can resolve or prevent.....40
6.1.13 Flexibilities of configuration into existing systems: microkernel, application, or
client/server.......................................................................................40
6.1.14 Capabilities of policy encapsulation for policy combination, composition, and
constraint.......................................................................................40
6.2 Metric Element Selection...................................................................................41
7 C ONCLUSION
Although only the most commonly used access mechanisms are discussed in this document, many extensions,
combinations, and different mechanisms are possible. Trade-offs and limitations are involved with all mechanisms
and access control designs, so it is the user’s responsibility to determine the best-fit access control mechanisms that
work for their business functions and requirements.
Also included in this document are the most commonly used access control policies. Since access control policies
are targeted to specific access control requirements, unlike access control mechanisms, specific limitations cannot be
inherently associated with them. And like access control mechanisms, it is up to the users to select the best policies
for their needs.
The complex issues of safety and the principles to achieve it are discussed. Although safety has been theoretically
proven hard (non-tractable computation time) [HRU76], there are easy (practical) means to meet the requirement by
providing some invariants that are not limited by the general access control model.
In addition to the limitations and issues, a quality metric depends not only on the consideration of administration
cost, but also on the flexibility of the mechanism helping the user in assessing or selecting among access control
systems.
7. IR 7298 - Glossary of Key Information Security Terms


80-90 pages of Glossary terms AND cites the source document
Published in 2006
210
8. IR 7206 - Smart Cards and Mobile Device Authentication: An Overview
and Implementation
Document Abstract
The use of mobile handheld devices within the workplace is expanding rapidly. These devices are no longer viewed
as coveted gadgets for early technology adopters, but have instead become indispensable tools that offer competitive
business advantages for the mobile workforce. While these devices provide productivity benefits, they also pose new
risks to an organization’s security by the information they contain or can access remotely. Enabling adequate user
authentication is the first line of defense against unauthorized use of an unattended, lost, or stolen handheld device.
Smart cards have long been the choice of authentication mechanism for many organizations; however, few handheld
devices easily support readers for standard-size smart cards.
This report describes two novel types of smart cards that use standard interfaces supported by handheld devices,
avoiding use of the more cumbersome standard-size smart card readers. These solutions are aimed at helping
organization apply smart cards for authentication and other security services. Details of the design and
implementation are provided.
Key points
 Smart cards and mobile handheld devices pose new risks.
 Unauthorized use is the big issue, so authentication is very important here.
o Smart cards are used to authenticate the user before granting access to the device.
 The Multi-mode Authentication Framework (MAF)
o is built on Linux
o includes a policy enforcement engine.
 Bluetooth Smart Card (BSC) authentication
o relies on a smart card chip packaged together with other components in a compact-size form factor
(e.g., a key fob or Bluetooth-enabled cell phone) in lieu of a traditional size smart card.
o a wireless interface is used – so smart card doesn’t need to be in physical contact with the device
o has the following advantages
 No need exists for a specialized smart card reader on the PDA
 The token can be small enough to fit comfortably in a pocket or a purse
 It can work within a few meters of the PDA, even without a direct line of sight
 It does not require much power, nor need to draw power from the PDA
 It can be discrete (i.e., non-discoverable by third parties)
o Has the following vulnerabilities - are the main candidates for exploitation:
 The authentication mechanism can be bypassed
 Weak authentication algorithms and methods are used
 The implementation of a correct and effective authentication mechanism design is flawed
 The confidentiality and integrity of stored authentication information is not preserved
o Communications Concerns - Because BSC uses a wireless communication channel the following
issues are present:
 An attacker can eavesdrop on the communication channel from a distance
 An attacker can send information to the device and PDA via an active Bluetooth interface
to attempt to impersonate one or both parties, or to disrupt communications
 When the PDA selects a token with which to communicate, the PDA cannot be certain it
contacted its user’s token
 When a token is contacted, the token cannot be certain the device that contacted it is the
device of its user
Summary
While mobile handheld devices provide productivity benefits, they also pose new risks associated with the
information and network access capabilities they accumulate over time. User authentication safeguards against the
risk of unauthorized use and access to a device’s contents. This paper demonstrates how novel forms of smart cards
can be implemented as a primary authentication method suitable for mobile devices. The methods used take
advantage of interfaces built into most handheld devices, affording organizations the opportunity to extend smart
card functionality easily to a segment of the computational infrastructure here to fore neglected.
211
APPENDIX A -- FIPS QUIZ
Match FIPS Number to FIPS Title
FIPS Title
FIPS Number
Computer Data Authentication (no electronic version available)
Secure Hash Standard (SHS)
Standard Security Label for Information Transfer
Standards for Security Categorization of Federal Information and
Information Systems
Advanced Encryption Standard
Entity Authentication Using Public Key Cryptography
Guideline for the Analysis of Local Area Network Security
Escrowed Encryption Standard
Personal Identity Verification (PIV) of Federal Employees and
Contractors
Digital Signature Standard (DSS)
Minimum Security Requirements for Federal Information and
Information Systems
The Keyed-Hash Message Authentication Code
Guideline for the Use of Advanced Authentication Technology
Alternatives
212
Security Requirements for Cryptographic Modules
Automated Password Generator
CORRECT ANSWERS
FIPS
Number
FIPS 201-1
FIPS 200
FIPS 199
FIPS 198-1
FIPS 197
FIPS 196
FIPS 191
FIPS 190
FIPS 188
FIPS 186-3
FIPS 185
FIPS 181
FIPS 180-3
FIPS 140-2
FIPS 113
FIPS Title
Personal Identity Verification (PIV) of Federal Employees and Contractors
Minimum Security Requirements for Federal Information and
Information Systems
Standards for Security Categorization of Federal Information and
Information Systems
The Keyed-Hash Message Authentication Code
Advanced Encryption Standard (AES)
Entity Authentication Using Public Key Cryptography
Guideline for the Analysis of Local Area Network Security
Guideline for the Use of Advanced Authentication Technology Alternatives
Standard Security Label for Information Transfer
Digital Signature Standard (DSS)
Escrowed Encryption Standard
Automated Password Generator
Secure Hash Standard (SHS)
Security Requirements for Cryptographic Modules
Computer Data Authentication (no electronic version available)
213
APPENDIX B -- FIPS 140-2 QUIZ
Match Requirements to Security Level
FIPS 140-2 Security Level
(1 through 4)
Requirements
Requirement for tamper-evidence
Requirement for immediate zero-ization of all plaintext CSPs
(Critical Security Parameters).
No specific physical security mechanisms are required
Requirement for detecting and responding to attempts at
physical access
214
APPENDIX C -- Public Key Cryptography
Explain Public Key Cryptography steps
See http://en.wikipedia.org/wiki/Public-key_cryptography
215