Requirements for FIPS Validated Modules

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

Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (nist.gov) [Page ii]

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.

NIST Releases First 3 Finalized Post-Quantum Encryption Standards

 

NIST has finalized three post-quantum encryption standards designed to protect electronic information from future quantum computer attacks. These include ML-KEM for general encryption, ML-DSA for digital signatures, and SLH-DSA as a backup digital signature algorithm. These standards are part of NIST's broader effort to secure data against quantum threats, encouraging immediate adoption by system administrators.

A fourth algorithm, FN-DSA, is scheduled for release in late 2024. This initiative is part of a decade-long project to develop quantum-resistant cryptography.

You can read more about it here: 

NIST Releases First 3 Finalized Post-Quantum Encryption Standards | NIST

Increasing the Work Factor: Enhancing Security to Deter Attackers

In the constantly evolving landscape of cybersecurity, defending your systems against attackers requires more than just strong passwords and firewalls. One of the most effective strategies you can employ is to increase the "work factor"—a term that refers to the amount of effort, time, and resources an attacker must expend to compromise a system. By increasing the work factor, you can make your system less attractive to attackers, ultimately forcing them to abandon their efforts and seek out easier targets.

In this post, we'll explore several methods to increase the work factor and discuss how they can be implemented to strengthen your system's defenses.

1. Implement Timeout Mechanisms

Timeouts are a simple yet powerful way to increase the work factor for attackers. When a user (or attacker) enters incorrect credentials multiple times, the system can implement a timeout, delaying further attempts for a certain period. This prevents attackers from quickly cycling through password attempts (brute force attacks) and forces them to slow down.

Implementation:

•                Login Attempt Timeouts: After a set number of failed login attempts, impose a delay before allowing further attempts. For example, after 5 incorrect attempts, impose a 30-second delay.

•                Session Timeouts: Automatically log out users after a period of inactivity, forcing attackers to restart their efforts if they gain access to an idle session.

2. Enforce Quota and Rate Limits

Quota and rate limits are another effective way to increase the work factor. These limits restrict the number of actions that can be performed in a given time period, making it harder for attackers to execute automated attacks.

Implementation:

•                API Rate Limiting: Set limits on the number of API requests that can be made within a certain timeframe. For example, allow only 100 requests per minute per IP address. This thwarts attackers who use automated scripts to bombard your system with requests.

•                Password Reset Limits: Limit the number of password reset requests that can be made in a specific timeframe. This prevents attackers from abusing the password reset functionality to lock out legitimate users or gain access to accounts.

3. Use CAPTCHA and Other Human Verification Methods

Adding CAPTCHA challenges or other human verification methods is a proven way to increase the work factor by ensuring that only human users (not bots) can interact with your system. This is especially useful for login forms, registration forms, and other areas where automated attacks are common.

Implementation:

•                Login CAPTCHAs: Implement a CAPTCHA challenge after a certain number of failed login attempts or on every login attempt. This makes it significantly harder for automated scripts to continue brute-forcing passwords.

•                Registration CAPTCHAs: Require CAPTCHA completion during user registration to prevent bots from creating fake accounts.

4. Apply Progressive Delays and Exponential Backoff

Progressive delays and exponential backoff increase the time between allowed attempts as the number of failed attempts grows. This strategy greatly increases the work factor by making each successive attempt take longer than the last, discouraging persistent attackers.

Implementation:

•                Login Backoff: After each failed login attempt, increase the delay before the next attempt is allowed. For example, after 3 failed attempts, wait 10 seconds, after 4, wait 30 seconds, and so on.

•                API Call Backoff: For API requests, implement exponential backoff on rate limits, gradually increasing the wait time between requests after each limit breach.

5. Introduce Account Lockout Mechanisms

Account lockouts can be a strong deterrent against brute force attacks by locking an account after a certain number of failed login attempts. While this method needs careful implementation to avoid denial-of-service attacks against legitimate users, it can significantly increase the work factor for attackers.

Implementation:

•                Temporary Lockouts: After a defined number of failed login attempts, temporarily lock the account for a period (e.g., 15 minutes). Notify the user of the lockout and provide instructions for regaining access.

•                Permanent Lockouts with Administrator Intervention: For more critical systems, consider locking accounts permanently after multiple failed attempts, requiring manual intervention by an administrator to unlock them.

6. Implement Multi-Factor Authentication (MFA)

Multi-Factor Authentication (MFA) adds an additional layer of security by requiring users to provide multiple forms of verification (e.g., a password and a one-time code sent to their phone). This drastically increases the work factor for attackers, as they must compromise more than just the user’s password.

Implementation:

•                Mandatory MFA: Make MFA mandatory for all users, especially for accessing sensitive systems or performing critical actions like changing account details or making financial transactions.

•                Adaptive MFA: Use adaptive MFA, which requires additional verification only when the system detects unusual behavior, such as login attempts from a new device or location.

Focus on the Strategic Outcome

Increasing the work factor for attackers is a strategic approach to improving your system's security. By implementing timeouts, quota thresholds, human verification methods, and other limits, you can make it significantly more difficult for attackers to successfully compromise your system. These measures, while simple, can have a profound impact on the security of your systems by making them less attractive targets for cybercriminals. By applying these strategies, you’re not only protecting your resources but also sending a clear message: attacking your system is simply not worth the effort.

Remember, the goal is to make the attacker's job so laborious and time-consuming that they abandon their efforts and move on to easier prey.

Threat Model: CREATE

This was an interesting experiment working with two different chat models and focusing on the "often-emphasized" strengths of each threat model method. This isn't an exact science - nor is it intended to be an exact science. But I liked the result. 

CREATE stands for Comprehensive Risk Evaluation and Threat Elimination. This acronym encapsulates the integrated approach of visualizing system architecture, identifying threats, measuring impact, addressing privacy concerns, and determining effective countermeasures.

CREATE Threat Model Steps

• Comprehend the System (Visualize - VAST)
• Develop a high-level architecture diagram of the system, focusing on key components, data flows, and trust boundaries.
• Ensure the diagram is simple, visual, and easy to understand for all stakeholders.
• Identify potential threat actors who may have a vested interest in attacking the system.
• Recognize Assets and Threats (Threats - STRIDE)
• Identify and prioritize critical assets that require protection.
• Break down the application into smaller, manageable components and identify trust boundaries and interactions between the components.
• Identify potential threats for each component and interaction using the STRIDE model:
• Spoofing: Identify threats related to authentication and impersonation.
• Tampering: Identify threats related to unauthorized modification of data or systems.
• Repudiation: Identify threats related to the ability to deny actions or transactions.
• Information Disclosure: Identify threats related to the unauthorized exposure of sensitive data.
• Denial of Service: Identify threats related to the disruption or degradation of system availability.
• Elevation of Privilege: Identify threats related to gaining unauthorized access or permissions.
• Evaluate Risks (Impact - DREAD)
• Assess the likelihood and potential impact of each identified threat using the DREAD model:
• Damage: Assess the potential damage caused by the threat if it were to occur.
• Reproducibility: Determine how easily the threat can be reproduced or exploited.
• Exploitability: Evaluate the level of skill and resources required to exploit the threat.
• Affected Users: Assess the number of users or systems that could be impacted by the threat.
• Discoverability: Determine how easily the vulnerability or weakness can be discovered by potential attackers.
• Address Privacy Concerns (Privacy - LINDDUN)
• Identify potential privacy threats using the LINDDUN model:
• Linkability: Determine if data from different sources can be combined to identify an individual or link their activities.
• Identifiability: Assess if an individual can be singled out or identified within a dataset.
• Non-repudiation: Evaluate if an individual can deny having performed an action or transaction.
• Detectability: Determine if it is possible to detect that an item of interest exists within a system.
• Disclosure of Information: Assess the risk of unauthorized access to or disclosure of sensitive information.
• Unawareness: Evaluate if individuals are unaware of the data collection, processing, or sharing practices.
• Non-compliance: Determine if the system or practices are not compliant with privacy laws, regulations, or policies.
• Terminate Threats (Countermeasures - PASTA)
• Create and review attack models using the PASTA methodology to:
• Define Objectives: Establish the objectives and scope of the attack modeling exercise.
• Define Technical Scope: Identify the key components, data flows, and trust boundaries of the system.
• Application Decomposition: Break down the application into smaller, manageable components.
• Threat Analysis: Identify and analyze potential threats using attack trees, threat intelligence, and vulnerability data.
• Vulnerability & Weaknesses Analysis: Assess the system for vulnerabilities and weaknesses that could be exploited.
• Attack Modeling: Simulate potential attack scenarios to determine the likelihood and impact of each threat.
• Risk & Impact Analysis: Evaluate the risk and potential impact of each identified threat.
• Countermeasure Analysis: Develop and recommend countermeasures to mitigate the identified risks.

CREATE Summary

• Comprehend the System: Visualize the system architecture and identify threat actors.
• Recognize Assets and Threats: Identify and categorize potential threats to the system.
• Evaluate Risks: Measure and prioritize the impact and likelihood of identified threats.
• Address Privacy Concerns: Review privacy-specific concerns within the threat model.
• Terminate Threats: Evaluate data and determine effective countermeasures.

The CREATE model provides an integrated approach to threat modeling by combining the strengths of VAST, STRIDE, DREAD, LINDDUN, and PASTA into a unified framework.