As the world’s #1 provider of data diode technology, we field a lot of questions about Common Criteria (CC) and its “Evaluation Assurance Levels” (EAL) of certification, from EAL1 to EAL7, as they relate to data diodes. CC EAL is used around the world as a benchmark of security technology assurance, and while it is generally understood to be an indicator of a product’s security relative to products in the same category, that definition has limits, and in some cases, may not really apply at all. Perhaps nowhere is this more apparent than with data diodes.
To understand the fraught relationship between EAL and data diodes, let’s first take a step back and look at what Common Criteria is and where it came from. We’ll then dig into the EAL process and how EAL certification actually works. Finally, we’ll take a look at the evolution of the EAL process and the resulting fallout as it relates to data diode certification.
What is Common Criteria?
Common Criteria (CC) was created in the mid 90’s, born out of a need to set internationally recognized standards and configurations for various IT technologies and products. It aggregated a number of standards from the USA, Canada, France, Germany, the Netherlands, and the UK into a single technological set of evaluation standards. Along with the standards, the group also established the Common Criteria Recognition Arrangement (CCRA), an enforcement agreement which states that participating members agree to accept the results of CC evaluations performed by other CCRA members.
Figure 1 – CC Source Documents Development[1]
These individual organizations are important to note because while each member organization agrees to recognize the evaluations performed by other members, it does not mean that they have the same evaluation schemes. Indeed, there are now 17 different member countries, each with their own authorizing schemes for evaluation. However, they all agree on a baseline set of product assurance standards as set in the aggregated international common criteria, which establishes the “lowest” levels of assurance certification, EAL1 through EAL2. As for EAL3 through EAL7, the story gets a little more complicated, so first, let’s talk about the EAL process itself.
What is the EAL Certification Process?
The Common Criteria standards were designed to provide a measurable and repeatable baseline framework to evaluate product assurance – thus the “Evaluation Assurance Level” or EAL – such that the product meets the requirements set forth for each level. This framework would then establish a means for developers, customers, and evaluators to institute, test, and verify a level of security assurance, via the evaluation methodology set forth in the Common Criteria. This provides asset owners an established, verifiable, and repeatable means test and become confident that the security measures are sufficient and correct to minimize risk to their assets.
The Common Criteria EAL framework demands a comprehensive set of documentation, from development to user guidance to lifecycle support to security assurance. The security assurance requirements are established in what CC calls the “Security Target” (ST), a document which outlines the assets and threats as well as the conformance claims, specifications of the target operating environment (TOE), security objectives, and security functional requirements (SFR). This document is vitally important as it forms the basis of any security assurance claims established by the certification process.
Figure 2- EAL Certification Documentation
The TOE is defined by Common Criteria as “a set of software, firmware and/or hardware possibly accompanied by guidance.” Basically, whatever technology or product is being evaluated. That guidance may or may not be based on or claim conformance to an established “Protection Profile” (PP).
A PP is a detailed, reusable set of security requirements that exists independent of the EAL process and documentation as a CC certified standard of security needs for a TOE type (typically a product category, such as software firewalls). Used to standardize ST requirements, PPs must detail security mechanisms pertinent to a specific IT product or category that can be certified as complete, consistent, and technically sound in addressing threats that exist in that specified environment. PPs are typically developed by CCRA members in conjunction with vendors, industry experts, and technologists, and once approved are certified for use among the CCRA participants.
Once the EAL documentation is in hand, the TOE (IT device or system) is evaluated against the documentation in a certified laboratory, including physical, operational, procedural, and security conformance claims (according to the ST, with or without a PP). Once the evaluation is complete, the results are then adjudicated by a CCRA-authorized body to certify the results meet the specified EAL requirements according to the CC methodology.
The Problems with EAL
Unfortunately, while the Common Criteria provides a common evaluation methodology, it does not provide a consistent means of certification. Many of the evaluation criteria require the application of expert judgement and background knowledge for which consistency is difficult to achieve, especially across 17 different member organizations.
In addition, unless the ST is based on a certified PP, the security assurance claims are entirely dependent upon the submission itself to define the security requirements for which the TOE is tested. Because of this, issuance of EAL3 and EAL4 (and above) now require a certified PP for mutual recognition across all member organizations. In fact, in the USA, the NIAP now requires an approved PP for any new certification and has done away with the EAL system altogether in favor of the PP system.
“Although EAL4 has become the defacto standard for evaluation, the generic EAL4 requirements are not relevant, achievable and repeatable in all cases. Given this false label of assurance, the creditability of NIAP and the Common Criteria in general has been negatively affected. … To restore the CC brand, it is necessary to restrict evaluations to technology specific Protection Profiles with achievable, repeatable and testable requirements and assurance activities.
The rationale for change is as follows:
- Comparable, consistent evaluation results require an agreed upon threat model and set of security functional requirements that must be captured in a Protection Profile;
- Comparable, consistent evaluation results require documenting tailored assurance activities for each requirement;
- More information must be disclosed across international CCRA Schemes to ensure confidence that evaluations have been consistently performed with the same level of competence and diligence regardless of the CC lab conducting the evaluation; and
- Confidence in a product is limited by its complexity and its separation from other products in the same environment. No amount of documentation and no method of evaluation can overcome these inherent limitations.
For products evaluated by any CC scheme against a NIAP approved Protection Profile, the NIAP PCL will indicate “PP Compliant”; no EAL will be indicated.”[2]
Going beyond EAL4, there tends to be quite a bit of weight put on certifications of EAL7. As the top of the ladder in the EAL system, it would naturally seem to be the “most secure.” To clarify, issuance of levels above EAL4 (EAL5, EAL6, EAL7) require the sponsorship of a CCRA member organization, which provides the additional assurance requirements for evaluation and certification specific to the regulations or compliance requirements of that member’s country. While there are more specific criteria, it doesn’t necessarily mean they are relevant to your use case or the typical application of the technology – it also does not guarantee that a PP was used in evaluation. As such, any certification above EAL4 is only valid within the country in which it is certified, and only mutually recognized across all member organizations at EAL4 (or EAL2 if it does not include a PP).
As you can see, while the CC “levels” may at first appear to be a simple rating of security assurance, there are plenty of nuances and caveats to consider. Although any certification will generally not be investigated by a customer beyond the certificate itself, there are legitimate reasons to question whether a product certified above EAL2 has actually been evaluated against a PP or simply evaluated to whatever vendor requirements were stated in the ST (according to the CC methodology).
Data Diode Certification
Herein lies the rub when it comes to data diodes and EAL. There is no Common Criteria-approved PP for data diodes. This means that until a PP is approved, any CC certification, anywhere, of any data diode technology cannot be mutually recognized above EAL2, no matter what level it was certified for. In fact, in the USA, because the NIAP now requires a PP for any new certification, this means data diodes cannot be EAL certified here at all (although the NIAP still mutually recognizes certification from other countries up to EAL2).
Does that mean EAL certification of data diodes is meaningless or lesser than other technologies? Not necessarily. It merely means that there is no established, approved set of security requirements for data diodes in CC, so evaluation results may vary. We at Owl are working with the NIAP along with industry technology experts to develop a PP for data diodes, but in the meantime, our relationships within the US Defense and Intelligence communities and proximity to the related certification processes for cross domain security technologies has led to another path.
Within those communities, cross domain solutions (CDS) are utilized to transfer data between sensitive networks. The National Cross Domain Strategy and Management Office (NCDSMO) is an office within the NSA directed with developing and refining the policies, guidance, and requirements of CDS technologies. CDSs are certified by the NCDSMO (and leadership from the Defense and Intelligence communities) according to a lengthy, arduous testing process known as a Lab-Based Security Assessment (LBSA), which goes far beyond the CC EAL process – although the CC methodology is a part of the LBSA process. Once CDSs are assessed and approved for use, they are placed on a “baseline” of approved technologies by the NCDSMO.
Similar to CDSs, the NCDSMO has recently developed a baseline of approved data diode technologies. Owl Cyber Defense is one of the first and only data diode solutions providers to pass this testing and make it to the approved baseline list. Going forward, Owl will continue to evaluate our data diodes through the EAL process, but in the absence of any further development on the PP front, for added assurance beyond the limits and inconsistencies of CC EAL, we will also have our solutions evaluated and approved for use through the NCDSMO process.
For more detailed information on how Owl data diodes are rigorously tested, evaluated, and certified, don’t hesitate to contact us today.
[1] https://www.sans.org/reading-room/whitepapers/standards/common-criteria-protection-profiles-evaluate-information-1078
[2] https://www.niap-ccevs.org/NIAP_Evolution/faqs/niap_evolution/FAQs28Mar_v6.pdf
