The following are common sets of requirements for FIPS validated modules.
Do you need them? Depends. This is certainly compelling.
PCI DSSv4
Payment
Card Industry Data Security Standard (pcisecuritystandards.org) [Page 70]
These and other non-console access
technologies and methods must be secured with strong cryptography. Further
Information Refer to industry standards and best practices such as NIST SP
800-52 and SP 800-57.
Privacy – PII & the GSA
Rules
and Policies - Protecting PII - Privacy Act | GSA
Rules and Policies - Protecting PII
- Privacy Act. The term “PII,” as defined in OMB Memorandum M-07-1616 refers to
information that can be used to distinguish or trace an individual’s identity,
either alone or when combined with other personal or identifying information
that is linked or linkable to a specific individual.
Protecting PII. PII shall be
protected in accordance with GSA
Information Technology (IT) Security Policy, Chapter 4.
8. NIST SP (800 Series) and GSA guidance documents. All policies shall be implemented using the appropriate special publication from NIST and/or GSA procedural guides to the greatest extent possible. […] Federal Information Processing Standards (FIPS) publication requirements are mandatory for use at GSA. [Page 6]
NIST SP 800-52
Abstract
Transport Layer Security (TLS)
provides mechanisms to protect data during electronic dissemination across the
Internet. This Special Publication provides guidance to the selection and
configuration of TLS protocol implementations while making effective use
of Federal Information Processing Standards (FIPS) and NIST-recommended
cryptographic algorithms. It requires that TLS 1.2 configured
with FIPS-based cipher suites be supported by all government TLS servers and
clients and requires support for TLS 1.3 by January 1, 2024.
NIST SP 800-57
Recommendation
for Key Management: Part 1 - General (nist.gov) [Page 3-4]
1.4 Purpose of FIPS and
NIST Recommendations (NIST Standards) Federal Information Processing
Standards (FIPS) and NIST Recommendations, collectively referred to as “NIST
standards,” are valuable because:
1.
They establish an acceptable minimal level of
security for U.S. government systems. Systems that implement these NIST
standards offer a consistent level of security that is approved for the
protection of sensitive, unclassified government information.
2.
They often establish some level of
interoperability between different systems that implement the NIST standards.
For example, two products that both implement the Advanced Encryption Standard
(AES)10 cryptographic algorithm have the potential to interoperate, provided
that the other functions of the product are compatible.
3.
They often provide for scalability because the
U.S. government requires products and techniques that can be effectively
applied in large numbers.
4.
They are scrutinized by U.S. government experts
and the public to ensure that they provide a high level of security. The NIST
standards process invites broad public participation, not only through the
formal NIST public review process before adoption but also by interaction with
the open cryptographic community through NIST workshops, participation in
voluntary standards development organizations, participation in cryptographic
research conferences, and informal contacts with researchers. NIST encourages
the study and cryptanalysis of NIST standards. Inputs on their security are
welcome at any point, including during the creation of the initial
requirements, during development, and after adoption.
5.
NIST-approved cryptographic techniques are
periodically reassessed for their continued effectiveness. If any technique is
found to be inadequate for the continued protection of government information,
the NIST standard is revised or discontinued.
6.
The algorithms specified in NIST standards
(e.g., AES, SHA-2, and ECDSA) and the cryptographic modules in which they
reside have required conformance tests. Accredited laboratories perform these
tests on vendor implementations that claim conformance to the standards.
Vendors are required to modify nonconforming implementations so that they meet
all applicable requirements. Users of validated implementations can have a high
degree of confidence that validated implementations conform to the standards.
Since 1977, NIST has developed a
cryptographic “toolkit” of NIST standards that form a basis for the
implementation of approved cryptography. This Recommendation references many of
those standards and provides guidance on how they may be properly used to
protect sensitive information.
CUI [NIST SP 800-171]
Protecting
Controlled Unclassified Information in Nonfederal Systems (nist.gov) [Page
14, see 3.1.13]
3.1.13 Employ cryptographic
mechanisms to protect the confidentiality of remote access sessions. DISCUSSION
Cryptographic standards include FIPS-validated cryptography and NSA-approved
cryptography. See [NIST CRYPTO]; [NIST CAVP]; [NIST CMVP]; National Security
Agency Cryptographic Standards.
AC-17(2) Remote Access Protection
of Confidentiality / Integrity Using Encryption
HIPAA [NIST SP 800-66]
NIST
SP 800-66r2 initial public draft, Implementing the Health Insurance Portability
and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide
[Pages 121, 123, and 135]
164.312(e)(1) Transmission
Security: Implement technical security measures to guard against unauthorized
access to electronic protected health information that is being transmitted
over an electronic communications network.
Guidelines for the Selection,
Configuration, and Use of Transport Layer Security 1852 (TLS) Implementations
[SP 800-52] – Provides guidance on the selection and configuration of TLS
protocol implementations while making effective use of Federal Information
Processing Standards (FIPS) and NIST-recommended cryptographic algorithms.
CMMC
CMMC
Assessment Guide - Level 2 (osd.mil) [Page 229]
SC.L2-3.13.11 – CUI ENCRYPTION
FIPS-validated cryptography means
the cryptographic module has to have been tested and validated to meet FIPS
140-1 or-2 requirements. Simply using an approved algorithm is not sufficient –
the module (software and/or hardware) used to implement the algorithm must be
separately validated under FIPS 140. Accordingly, FIPS-validated
cryptography is required to meet CMMC practices that protect CUI when
transmitted or stored outside the protected environment of the covered
contractor information system (including wireless/remote access). Encryption
used for other purposes, such as within applications or devices within the
protected environment of the covered contractor information system, would not
need to be FIPS-validated.
This practice, SC.L2-3.13.11,
complements AC.L2-3.1.19, MP.L2-3.8.6, SC.L2-3.13.8, and SC.L2-3.13.16 by
specifying that FIPS-validated cryptography must be used.