Our previous article discussed how vulnerabilities are dealt with under the Common Criteria certification program in North America. All commercial product assurance programs deal with flaws and vulnerabilities in different ways, often with overlapping requirements, techniques and outcomes.
In this article, James Ramage of the Lightship Security FIPS team talks about how vulnerabilities are handled for FIPS 140-3 validations.
Similar to the “evaluated configuration” in Common Criteria (see previous post), one of the constraints of FIPS 140-3 validation is that a precise operating environment (OE) must be specified. For example, a cryptographic module’s OE can be specified as an operating system running on general purpose computer (GPC) such as “Windows 10 running on a Dell PowerEdge R740”. Any deviation from the version or configuration means, that the product is not running in the “Tested Configuration” (sometimes referred to as FIPS mode) and is therefore “not validated”.
Given the possibility for a newly discovered vulnerability within a tested operating environment, how does a vendor remediate the situation within the validation process? Thankfully, the CMVP provides a path to remediation by permitting accredited labs and vendors scenarios to fast-track product updates that address severe vulnerabilities. These scenarios allow vendors to address the product vulnerability in conjunction with the lab’s analysis and regression testing with special focus on the product area affected by the issue. For products in validation (within the “review pending”, and “in review” validation phases), a revised test report can be submitted to the CMVP. For validated modules, the “Security Issue (3CVE)” scenario allows for the “Expedited assessment of changes to address CVE related modifications”. After product updates are released and the lab completes required regression testing, a new report can be submitted to the CMVP to initiate the re-validation process.
If a vendor chooses not to remediate certain vulnerabilities or CVE’s, they run the risk of having their validated modules moved to the CMVP’s historical list that impacts their end users ability to procure and use the technology.
As background on the program, the Federal Information Processing Standards (FIPS) are publicly announced standards developed by the National Institute of Standards and Technology (NIST) for use in computer systems by non-military government agencies and contractors. The Cryptographic Module Validation Program (CMVP) is a joint American and Canadian security accreditation program for “cryptographic modules”, which provide “approved” or safe algorithms to protect sensitive data. The program is available to any vendor who seeks to have their products validated for use by the U.S. and Canadian Government, as well as regulated industries (such as financial and health-care institutions) that collect, store, transfer, share and disseminate encrypted “sensitive, but not classified” information.
Cryptographic module testing under the CMVP is handled by third-party laboratories, such as Lightship Security, that are accredited as Cryptographic Module Testing Laboratories by the National Voluntary Laboratory Accreditation Program (NVLAP). Product certifications under the CMVP are performed in accordance with the requirements of FIPS 140-3.
If you are dealing with a validated module suffering from CVE-2021-44228 or any other, let the team at Lightship Security handle your re-validation effort and maintain your module’s validation certificate. Contact us today!
James Ramage
James Ramage is a senior FIPS evaluator at Lightship. He has been doing FIPS evaluations and security certifications for 5+ years and enjoys working with customers, training team members and evaluating new technologies.