Search CSRC

Understanding user perceptions and behavior is critical to achieving security objectives. People are repeatedly bombarded with messages about the dangers lurking on the Internet and are encouraged (or forced) to take numerous security-related actions, often without a clear understanding of why and to what end. We conduct research to discover people’s security and privacy perceptions, attitudes, and behaviors with a goal of developing cybersecurity guidance that: 1) takes into account user needs, biases, and limitations and 2) helps people make sound security decisions. Recent projects include...

What is a Control Overlay? An overlay offers organizations additional customization options for control baselines and may be a fully specified set of controls, control enhancements, and other supporting information (e.g., parameter values) derived from the application of tailoring guidance to SP 800-53B control baselines, or derived independently of control baselines. Overlays also provide an opportunity to build consensus across communities of interest and develop a starting point of controls that have broad-based support for very specific circumstances, situations, and/or conditions....

Overlay Submission Documents  All documents must be complete and submitted to sec-cert@nist.gov for inclusion in the SCOR.  Download All Files Download all files below as .ZIP or select individual files from list Submission Form Participation Agreement (Public Org) and Participation Agreement (Federal Gov) Overlay Technical Criteria  (Not a download; references section below)   Overview of the SCOR Submission Process Organizations sanitize their security control overlay for public review and ensure overlay is based on NIST SP 800-53 security controls. Organizations...

  NIST welcomes feedback on the NIST Security and Privacy Control Overlay Repository (SCOR). If you have any questions about submitting overlays to the NIST SCOR, participation agreements, or any suggestions, comments, or questions regarding the repository, send an e-mail to sec-cert@nist.gov. Return to Control Overlay Repository Overview    

The following products have been placed on the Removed Products List because they do not conform to the requirements of FIPS 201-2 effective since 9/05/14 or  to the requirements of FIPS 140-2.   All questions regarding the implementation and/or use of any PIV Card Application located on the validation list should first be directed to the vendor. Cert # Product Name Vendor Issue Date/ Update Date FIPS 140-2 validation certificate # and date Product Details Removed Reason 1 PIV End Point Java Card Applet (Version: v1.08[1], v.1.09[2]) for...

Call for Proposals The cover sheet of a submission package shall contain the following information: Name of the proposed cryptosystem. Principal submitter’s name, e-mail address, telephone, organization, and postal address. Name(s) of auxiliary submitter(s). Name of the inventor(s)/ developer(s) of the cryptosystem. Name of the owner, if any, of the cryptosystem (normally expected to be the same as the submitter). Signature of the submitter. (optional) Backup point of contact (with telephone, fax, postal address, and e-mail address).

Call for Proposals Each submission must include: a complete written specification a detailed performance analysis Known Answer Test values a thorough description of the expected security strength an analysis of the algorithm with respect to known attacks a statement of advantages and limitations. Further details are described below. 2.B.1   A complete written specification of the algorithms shall be included, consisting of all necessary mathematical operations, equations, tables, and diagrams that are needed to implement the algorithms. The document shall also include a design...

Call for Proposals All electronic data shall be provided either in a zip file, or on a single CD-ROM, DVD, or USB flash drive labeled with the submitter’s name, as well as the name of the proposed cryptosystem. 2.C.1 Implementations Two implementations are required in the submission package: a reference implementation and an optimized implementation. The goal of the reference implementation is to promote understanding of how the submitted algorithm may be implemented. Since this implementation is intended for reference purposes, clarity in the implementation code is more important than the...

Call for Proposals Each submitted algorithm, together with each submitted reference implementation and optimized implementation, must be made freely available for public review and evaluation purposes worldwide during the period of the post-quantum algorithm search and evaluation. The following signed statements will be required for a submission to be considered complete: 1) statement by the submitter, 2) statement by patent (and patent application) owner(s) (if applicable), and 3) statement by reference/optimized implementations' owner(s). Note that for the last two statements, separate...

Call for Proposals 4.A      Security The security provided by a cryptographic scheme is the most important factor in the evaluation. Schemes will be judged on the following factors: 4.A.1 Applications of Public-Key Cryptography NIST intends to standardize post-quantum alternatives to its existing standards for digital signatures (FIPS 186) and key establishment (SP 800-56A, SP 800-56B). These standards are used in a wide variety of Internet protocols, such as TLS, SSH, IKE, IPsec, and DNSSEC. Schemes will be evaluated by the security they provide in these applications, and in additional...

Call for Proposals 4.B      Cost As the cost of a public-key cryptosystem can be measured on many different dimensions, NIST will continually seek public input regarding which performance metrics and which applications are most important. If there are important applications that require radically different performance tradeoffs, NIST may need to standardize more than one algorithm to meet these diverse needs. 4.B.1 Public Key, Ciphertext, and Signature Size Schemes will be evaluated based on the sizes of the public keys, ciphertexts, and signatures that they produce. All of these may be...

Call for Proposals 4.C      Algorithm and Implementation Characteristics 4.C.1 Flexibility Assuming good overall security and performance, schemes with greater flexibility will meet the needs of more users than less flexible schemes, and therefore, are preferable. Some examples of “flexibility” may include (but are not limited to) the following: The scheme can be modified to provide additional functionalities that extend beyond the minimum requirements of public-key encryption, KEM, or digital signature (e.g., asynchronous or implicitly authenticated key exchange, etc.). It is...

The following sections detail the Schematron rules for SCAP 1.3. SCAP Schematron Rules The SCAP Schematron Rules are ISO Schematron rules written to check many of the requirements documented in NIST SP 800-126 Rev 3. They are for informational purposes only; they do not supercede the requirements in the specification. The rules are subject to change at anytime. Instructions on how to use the resource are provided in the included scap-rules-readme.txt. Version: 1.3.5 Released: 08/06/2020 Download: SCAP Schematron Package SHA-256:...

The following sections detail the Schematron rules for SCAP 1.2. SCAP Schematron Rules The SCAP Schematron Rules are ISO Schematron rules written to check many of the requirements documented in NIST SP 800-126 Rev 2. They are for informational purposes only; they do not supercede the requirements in the specification. The rules are subject to change at anytime. Instructions on how to use the resource are provided in the included readme.txt. Version: 1.2.6 Released: 12/16/2016 Download: SCAP Schematron Package SHA-1: BBFD29657FB9B9F3EB48A3D021817FBB1DB8E21D SHA-256:...

XCCDF Benchmark: XCCDF Sample for Cisco IOS XCCDF Sample for Cisco IOS Status: draft (as of 2004-10-07) Version: 0.12.1 Applies to: Cisco IOS Routers version 11.x Cisco IOS Routers version 12+   Contents 1. Introduction 2. Tailoring Values 2.1. IOS - line exec timeout value 2.2. Logging level for buffered logging 3. Rules 3.1. Management Plane Rules 3.1.1. IOS 11 - no IP finger service 3.1.2. IOS 12 - no IP finger service 3.1.3. Require exec session timeout on admin sessions 3.2. Control Plane Rules 3.2.1. Disable tcp-small-servers 3.2.2. Disable udp-small-servers...

- OCIL Schema - Element Dictionary Schema: OCIL Version: 1.0 Release Date: December 29, 2008 VERSION 1.0 The Open Checklist Interactive Language (OCIL) is a language to express a set of questions to be presented to a user and procedures to interpret responses to these questions for the purpose of developing security checklists. Although its intended domain of use is IT security, its generic nature allows for other applications. For instance, it could be used for authoring research surveys, academic course exams, and instructional walkthroughs. This document was originally developed by...

OCIL - The Open Checklist Interactive Language - Schema Element Dictionary - OCIL Schema - Element Dictionary Schema: OCIL Version: 1.1 Release Date: May 20, 2009 VERSION 1.1 The Open Checklist Interactive Language (OCIL) is a language to express a set of questions to be presented to a user and procedures to interpret responses to these questions for the purpose of developing security checklists. Although its intended domain of use is IT security, its generic nature allows for other applications. For instance, it could be used for authoring research surveys,...

The Applicability Language specification defines a standardized structure for forming complex logical expressions out of Well-formed Names (WFNs). These expressions, also known as applicability statements, are used to tag checklists, policies, guidance, and other documents with information about the product(s) to which the documents apply. For example, a security checklist for Mozilla Firefox 3.6 running on Microsoft Windows Vista could be tagged with a single applicability statement that ensures only systems with both Mozilla Firefox 3.6 and Microsoft Windows Vista will have the security...

The Dictionary specification defines the concept of a CPE dictionary, which is a repository of CPE names and metadata, with each name identifying a single class of IT product. The Dictionary specification defines processes for using the dictionary, such as how to search for a particular CPE name or look for dictionary entries that belong to a broader product class. Also, the Dictionary specification outlines all the rules that dictionary maintainers must follow when creating new dictionary entries and updating existing entries. CPE Dictionary Resources Release 2.3 CPE 2.3 Dictionary...

The Name Matching specification defines the procedures for comparing Well-formed Names (WFNs) to each other so as to determine whether they refer to some or all of the same products. CPE Name Matching Resources Name Matching CPE 2.3 Name Matching Resources (August 2011) Documentation: NISTIR 7696

The Naming specification defines the logical structure of Well-formed Names (WFNs), URI bindings, and formatted string bindings, and the procedures for converting WFNs to and from the bindings. CPE Naming Resources Release 2.3 CPE 2.3 Naming Resources (August 2011) XML Schema Files: [what is a schema?] CPE 2.3 Naming (XSD 1.0) Documentation: NISTIR 7695

The following products have been placed on the Removed Products List because they do not conform to the requirements of FIPS 201-2 effective since 9/05/14.   Note:  Validation of SP 800-73-1, SP 800-73-2 and SP 800-73-3 based PIV Middleware has been superseded by SP 800-73-4 (or higher) based PIV Middleware validation. All questions regarding the implementation and/or use of any PIV Middleware included in the validation list should first be directed to the vendor.    SP 800-73-3 PIV Middleware Validation List Certificate # Product Name Vendor Validation Date...