The Common Criteria for Information Technology Security Evaluation, or more commonly known as Common Criteria, are a set of guidelines for validating the quality of security of Information Technology (IT) products. As a globally recognized set of “standards,” it helps give buyers assurance of the strict levels of integrity applied in the specification, implementation, and evaluation of an IT product. These products are typically evaluated by a neutral, third-party testing lab through security requirements based on predefined Evaluation Assurance Levels (EALs).
Presently, most businesses rely on computer security products and systems to operate on a day to day basis. So, understanding the Common Criteria can be helpful in determining if security products are providing the assurance they need to protect digital assets from common cyber attacks. This blog post will focus on how the Common Criteria process works and how it applies to Web Application Firewalls (WAFs).
Who Gets Evaluated?
The product that is subject to the evaluation is labeled as the Target of Evaluation, or TOE. Typically, vendors are the ones who submit their product or products to be evaluated for quality assurance. Identifying what security requirements are relevant for that product is necessary, and they are established in what are known as Protection Profiles (PPs).
So who decides which security requirements are relevant and mandatory for the evaluation process? Typically, the decision is made by an individual or a community who is an expert in the field. The security requirements are laid out in a document and shared across a community of specialists. When a product is set to be evaluated, their security features will be tested against these PPs. For a WAF, a PP may include security requirements like data integrity, data confidentiality, and user authentication.
A vendor or developer may attempt to build their systems to meet a certain PP, and thereafter submit a standalone Security Target (ST), which is another document that outlines the security properties of the TOE and describes how the product is able to meet the PP (or PPs). The PPs therefore serve as a guide to creating the ST. This is extremely useful to vendors who want to go through the Common Criteria certification process since the ST allows the evaluations to be tailored specifically to the intended capabilities of the security features of the products.
How the Common Criteria Process Works
When vendors are ready to move forward in the process, they submit the product along with the ST and documentations to an accredited third-party lab. The lab then decides and evaluates if the ST is a sufficient baseline for the evaluation and will decide if the device is able to meet a particular PP through testing.
Because it can get a bit confusing, to round it up, the Common Criteria process first begins with a PP. A vendor then submits the TOE, which is the product, and finally submits an ST which explains the functionality of the device/product and the assurance components.
There are two evaluation tests: Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs). STs establish the Security Functional Requirements to which the product is evaluated against for its security features. This can include web attack protection and prevention, SSL support, client authentication, and protocol configurability for WAFs. SARs on the other hand, ensure that the product meets the compliance associated with the claimed security functionalities.
Common Criteria can be useful in determining a WAF’s ability to secure vital application services from exploitation or attack. Like other IT products, it must satisfy a set of baseline requirements outlined in either a PP or ST to attain certification and be assigned an EAL. A visual representation of the entire process is shown below.
How Are EALs Assigned?
The testing lab is the entity that performs the two security tests, submits a package to an evaluation authority to validate findings, and assigns the EAL. It’s important to keep in mind that higher EALs does not equal better security; it simply shows the extent to which a product was tested as shown below. (If you’re looking for an in-depth analysis of the differences, we recommend reading this guide in the Common Criteria Portal.)
- EAL 1: Functionally tested
- EAL 2: Structurally tested
- EAL 3: Methodically tested and checked
- EAL 4: Methodically designed, tested and reviewed
- EAL 5: Semi-formally designed and tested
- EAL 6: Semi-formally verified design and tested
- EAL 7: Formally verified design and tested
EAL 1, for example, provides a basic level of assurance by a limited security target and an analysis of the SFRs in that ST. EAL 2 through 7 provide assurance by a full security target and an analysis of the SFRs in that ST. Vendors can choose the extent to which their product is evaluated, and if it passes the evaluations tests, any EAL is meaningful. Customers and businesses are ultimately assured that the product, whether it be a WAF or intrusion detection system, is reliable. For WAFs especially, it is important that the security features are working the way they should be: protecting web applications with precise detection.