The Dilemmas of FIPS 140-3 Compliance
FIPS 140-3 is a standard issued by the National Institute of Standards and Technology (NIST) that aims to provide a consistent and secure method for processing sensitive information using a rigorous certification process. Conformity to this standard is mandatory for specific organizations in the US and Canada, but many organizations still choose to adopt it as a best practice, even if it’s not specifically required for them.
However, complying with FIPS 140-3 can be complex and time-consuming. The certification process to get an operating system validated is rigorous and takes quite a long time.
When an organization updates its FIPS-validated operating system to address a vulnerability, that system becomes non-validated and needs to undergo the certification process once again. This conundrum can lead organizations to delay patches, forcing them to decide between staying on either FIPS-certified systems but, at the same time, risking their security or securing these systems from the latest vulnerabilities despite breaking their FIPS certification.
But do organizations need to choose between certification and security? In fact, for the majority of organizations it is not the case. This blog post will delve deeper into these issues and explore alternatives available to organizations, such as Extended Security Updates (ESU), a support service designed specifically for AlmaLinux that provides continuous security and compliance.
What is FIPS 140-3?
FIPS 140-3 specifies the security requirements for cryptographic modules used in hardware and software. Cryptographic modules in the context of an operating system like AlmaLinux are the specific parts of system packages and libraries, including the kernel, OpenSSL, GnuTLS, NSS, and Libgcrypt, containing the implementation of one or more cryptographic algorithms and security measures used to protect sensitive information. A cryptographic module that has been certified to meet the requirements of FIPS 140-3 is considered a secure and reliable solution for protecting such information.
To put it simply, when a software or hardware product has a FIPS 140-3 certificate, it has met the baseline requirements for cryptographic effectiveness and can be trusted.
A Must-Have or Just Nice to Have?
Compliance with the standard is mandatory for Canada’s and the United States’ federal government agencies, government contractors, and companies that provide services to the US federal government. For other organizations, compliance with FIPS 140-3 is a best practice, as it can help them protect sensitive data and assets as well as increase the trust of their customers and other stakeholders in the security of their products and services.
Outsourcing vs. DIY
Organizations requiring FIPS-certified deployments or those operating under compliance regimes with similar requirements (e.g., PCI DSS, HIPAA) can choose whether to certify their applications themselves or build them using already-certified components. The former implies significant investments, cryptographic expertise, and time, since it involves validation by a third-party NIST-accredited laboratory. The more complex the application is, the more effort will be required.
Certified or Secured?
Operating systems that include cryptographic modules and handle sensitive information must be FIPS 140-3 certified. Although cryptographic modules are just small components of certain system packages and libraries, like Kernel Crypto API, these components must be certified as their integral parts. This means that, to maintain FIPS certification, many updates to these packages and libraries require them to be re-certified.
Considering the time and effort required for re-certification, organizations are often forced to stick with their current OS version, essentially choosing to remain FIPS-certified over quickly protecting themselves against the latest vulnerabilities. At the same time, this delay in implementing critical security updates leaves organizations vulnerable to cyberattacks, which is a significant security concern.
Some organizations and agencies address this challenge by carefully evaluating their risk management strategies and weighing the potential risks and costs associated with conforming to the FIPS standard. They may consider implementing alternative security measures, such as network segmentation, to mitigate the impact of vulnerabilities in the operating system. But there is a better way.
Trade-Offs Are Not Necessary
First, the FIPS 140-3 certification is a very lengthy process, and by the time the certificate is received, the packages and libraries containing the certified cryptographic modules will be out of date. They will be missing security patches for vulnerabilities identified since the FIPS 140-3 certification process started. If not updated, the value from the security baseline established by the FIPS certification may be compromised.
Second, most high and critical security updates do not affect validated cryptography (and in NIST terms, “cryptography affecting” is restricted to the FIPS code). If we take the last 4 years of the AlmaLinux 8 lifecycle as an example, then we will see that all important CVEs were in non-cryptographic code (certificate/ASN.1 parsing, security check bypasses, TLS packet handling). Even the most hyped and critical OpenSSL vulnerability – Heartbleed – had nothing to do with cryptography. This means that most vulnerability fixes in the FIPS-certified packages and libraries do not even affect the validated modules, or the cryptography they provide. In other words, updated packages and libraries remain fully FIPS compliant.
Being FIPS-compliant should be sufficient for the majority of organizations. They can run their systems on validated cryptography and, at the same time, benefit from the latest security fixes. There are very specific use cases that will require strict FIPS-certified implementations that are static and never patched, like military or intelligence agencies. However, in case of patching a cryptographic vulnerability, organizations that have chosen to apply security fixes to their FIPS-certified systems will still need to find a way to quickly re-certify their operating system.
If you are looking for an enterprise-grade Linux distribution to comply with the standards of the US and Canadian governments or operate in highly regulated environments, you need to think of a solution that provides you with continuous security and, at the same time, allows you to meet the required data protection standards.
If there is a distribution that delivers FIPS-validated components, security updates for non-cryptographic CVEs, and fast re-certification in case of a cryptographic vulnerability, it would be a perfect fit. Extended Security Updates (ESU), a support service designed specifically for AlmaLinux, does exactly that. It not only provides you with security patches that don’t touch the validated cryptography and provides FIPS 140-3 re-certification when required, but can also be enhanced with live patching – allowing you to patch your FIPS-certified systems while maintaining their 100% uptime.
Extended Security Updates (ESU) for AlmaLinux
If you are familiar with the AlmaLinux lifecycle, a new minor release comes every six months, bringing new features until the fifth year. However, a FIPS-certified version must be stable and introduce as few updates as possible to retain its certification. The AlmaLinux version currently planned for FIPS 140-3 certification is 9.2. With TuxCare’s Extended Security Updates, you can stay on the validated minor version and keep securely running on the validated code for five years of FIPS-compliant security updates.
The service delivers a combination of high and critical security updates in the form of package updates that are tailored to ensure that you run with FIPS-compliant cryptography. They are never bundled with feature updates and deliver fixes for non-cryptographic vulnerabilities to bring stability while still allowing customers to receive the vast majority of security updates. Moreover, if you add live patching to it, your certified AlmaLinux systems can be patched without the need for patch-related reboots or maintenance windows.
At the same time, if there is a cryptographic vulnerability, we fix it by delivering a new packaged kernel. Customers can reboot and install this kernel to update their systems. It is our intention to get every new kernel that modifies cryptography through the re-certification process designed for CVE fixes, which is much faster. This ensures that new kernels that contain a vulnerability fix on their cryptography will be attested to conform to the FIPS 140-3 requirements.
To find out more about all the benefits of Extended Security Updates, check out our product page.