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
[email protected].
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 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
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 Federally-owned 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
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
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
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 Domains
20% Domain 1 – NIST Special Publications
10% Domain 2 – NIST Federal Information Processing Standards (FIPS) 10% Domain 3 – NIST Control Families
20% Domain 4 – Governmental Laws and Regulations 30% Domain 5 – NIST Risk Management Framework 10% 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
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.
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 800-53, 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‖.
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.
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)
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
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.
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.
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
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)
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.htmSynopsis
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
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 zero-izes 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
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 pick-resistant 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 pick-resistant 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
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.
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 140-2, 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 800-2]
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
(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.
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 - 1, 224, 256, SHA-384, 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 keyed-hash message authentication codes, or in the generation of random numbers (bits). The five keyed-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.
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
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
