No computing system is free from security vulnerabilities. Such flaws can manifest themselves within software, firmware and hardware implementations. Often the ease in widespread mitigation is based in part on whether a vendor can provide updates to software (relatively easy), firmware (a bit harder), or whether a new version of hardware needs to be deployed (very difficult). The constraints and goals of point-in-time security certification programs such as Common Criteria (CC) and FIPS 140-3 can often conflict with the need to correct such security deficiencies. With the recent disclosure of CVE-2021-44228 (a remote code exploit [RCE] in the widely deployed log4j component in Java-based products), questions often come up as to how such vulnerabilities are handled within certain certification programs.
Common Criteria (ISO 15408) is, ideally, a holistic security review program covering relevant topics such as security design, supply chain, security functional testing, and vulnerability analysis and testing. One of the constraints of Common Criteria certification is that a specific product version and configuration is reviewed. Any deviation from the precise version or configuration means, in a purist’s view of CC, that the product is not running in the “evaluated configuration” and is therefore not certified. This “point-in-time” view of compute products often means that CC is seen as incapable of meeting modern software development challenges such as never-ending security flaw discovery.
North American Common Criteria schemes have tried to approach this problem in a number of ways. Both the Canadian Common Criteria scheme (CCCS) and the US National Information Assurance Partnership (NIAP) generally assume that products will receive timely security updates. To this end, certified products meeting approved Protection Profiles (PPs) are required to show — at the very least — that a product has the capability to receive and/or apply updates to itself. This specific Security Functional Requirement (SFR) class is often denoted as FPT_TUD_EXT. This class of requirements are intended to show that updates are made available by the vendor for the product under test, that they are well-formed, and that the security of the composition of the update package is maintained through reasonably secure methods.
A Common Criteria test lab is required as part of any evaluation to conduct a detailed review of public vulnerability information relevant to a product under evaluation (this is known as the AVA_VAN assurance class). This phase of the evaluation usually comes at the end. Depending on the underlying security claims, the type of product, the type of evaluation being conducted, and the type of access an evaluator has to the product’s internals, an evaluator will attempt to determine whether any existing flaws apply. A full treatment of the nuances of a vulnerability analysis is, unfortunately, beyond the scope of an article like this. However, generally speaking, an evaluator will be most concerned with flaws that present at public interfaces (eg. think a web application, or special-purpose TCP and/or UDP server processes). Flaws in components that are only indirectly available via public interfaces may still be of concern depending on how such interactions are done. For example, if a web interface were to accept (normally sanitized) input from a user (i.e. attacker) and then send that to a flawed component, it may unwittingly permit an attacker to exploit a vulnerability in indirectly accessible code. An evaluator tries to consider the product and the range of available flaws that might be in it and balances that against the “assurance level” of the evaluation.
With that said, both NIAP and CCCS essentially have policies (e.g. NIAP Policy 17) that says products should not contain known vulnerabilities. A product is often considered to be vulnerable if it can be exploited. Usually this means that a product might still be permitted to be certified even if it contains known vulnerabilities as long as there is no way for the vulnerability to be exploited. It is important to realize that most evaluations have unique circumstances and the above cannot be seen to apply universally. Always discuss vulnerability analysis and mitigation plans with your certification lab.
In some cases, egregious security flaws have prompted additional action to be requested by NIAP. Most recently, NIAP issued letters to every product vendor on the Product Compliance List (PCL) requesting a “mitigation plan” from the vendor as to how they would meet an Intel Management Engine flaw (CVE-2019-0169). Other such letters were issued for the original Spectre/Meltdown vulnerabilities [CVE-2017-5753 and CVE-2017-5715], and Heartbleed [CVE-2014-0160]. We have discussed the use of mitigation plans in a previous blog article. While the precise criteria required for NIAP to issue public requests for mitigation plans are not clear, they do appear to be reserved only for the most critical vulnerabilities covering platforms most likely to be used by the largest set of Federal agencies. While CVE-2021-44228 ranks (unofficially as of this writing) as a 10/10 on the Common Vulnerabilities Scoring System (CVSS), it affects systems running Java-based components (which is a lot of systems). It may further be mitigated by other factors and circumstances and therefore may not be a candidate prompting a NIAP mitigation plan requirement. We’ll likely know in the next few weeks for certain.
Let Lightship Security successfully guide your Common Criteria evaluation through the process. Our knowledgeable team can help you identify and remediate possible vulnerabilities including CVE-2021-44228 and ensure your product meets the requirements to get onto the necessary certified products list, including NIAP’s Product Compliance List (PCL).
Greg McLearn is Lightship’s Technical Director. He has been doing Common Criteria and security certifications for 10+ years and enjoys getting his hands on some of the latest technology. He has authored several tools to help facilitate security testing.