Author: Fikret OTTEKİN, Software Consultant / Advisor to CEO
This blog entry is for managers and engineers interested in IT security.
1- Brief History of CC
“Common Criteria”, briefly CC, is the title of a document: “Common Criteria for Information Technology Security Evaluation”. Unlike most standards, Common Criteria is free to download in PDF format from the Common Criteria WEB Portal. And like most standards, CC is developed and maintained through an international effort. You can take a look at the organizations from 12 countries who have contributed to its development according to the latest version of CC (released in April 2017).
Figure 1. Contributors of the Common Criteria standard
Until the very end of 20th century, different standards were being used for the security evaluation of IT products in different parts of the World. Then, the Common Criteria was developed, and it superseded most of the older standards such as the “Rainbow Series”, published by the US government with the purpose of Trusted System evaluation in 1980s and 90s. Chapters of Rainbow Series are now decorating the shelves of libraries with their beautiful colors such as “Dark Lavender”, “Burgundy” and “Venice Blue” to name a few, but probably they are not referred to a lot.
In the past, countries’ certification processes dealing with the security verification of IT products were not aligned, either. An IT product exported from a country to another, for example from New Zealand to France, developed and certified in New Zealand, had to be evaluated all over again in France to make sure the security features of the product were functioning exactly as they were declared by the developer. That was not practical. A common standard for evaluation was required as well as an agreement to define the responsibilities of national certification bodies. Both of these seemingly difficult tasks were accomplished around the end of 1990s.
2- The International Arrangement
The strength of Common Criteria and the utmost prestige of the certificates earned at the end of the strenuous CC evaluation process stems from the international agreement behind them: “The Common Criteria Recognition Arrangement”. CCRA was first signed in 1998 by Canada, France, Germany, United Kingdom and USA. Australia and New Zealand has joined in 1999, followed by seven more countries in 2000. CCRA signatories have ever been a growing community; Turkey has joined in September 2003 and 31 countries have signed the arrangement as of November 2020.
First and foremost aim of the arrangement is simple: Mutual recognition of certificates issued by signatory certification bodies. Which means, once an IT product is certified, for instance in New Zealand, it would be “recognized” in all the countries who have signed the arrangement. So, the arrangement is good for business. But it is not easy to obtain the status of New Zealand. Countries eager to attain and sustain the “Certificate Authorizing” status have some obligations. They have got to prove their competence, impartiality, and quality to representatives of CC Management Board once in a couple of years. If you are not willing to walk that winding road, you are merely a “Certificate Consuming” member. Meanwhile, membership status to CCRA may not necessarily indicate the competence of a country in IT security. United Kingdom, who is among the contributors of CC, and Israel, who is quite active in the field of cyber security have preferred to retain certificate consuming member statuses.
In the meantime, Turkey has applied for “certificate authorizing nation” status and has been evaluated by senior CC experts from Netherlands and France in April 2010. As the ash clouds from the erupting Icelandic volcano Eyjafjallajökull covered the skies of Europe and the auditors were stranded in Ankara, Turkey earned the “certificate authorizing nation” status. And that status has been maintained so far.
Common Criteria is exact. The CC Certification Mark, which decorates the certificates issued by Certificate Authorizing nations, is defined in Annex E of the agreement in detail, including hex codes of colors in RGB space (Figure 2). Vendors can use the mark while advertising their products as well. Go ahead and verify if “Warm Red” is really delivered by “0xfa4632” color code in a common picture editor. That could give you a clue whether you would enjoy a career in CC evaluation.
Figure 2. The Common Criteria Certification Mark
3- Most Basic Terms of CC
CCRA has ever been accompanied by the CC Web Portal where the Arrangement, the CC standard and last, but not the least, information about the Certified Products are available.
Three abbreviations would catch the attention of a visitor who isn’t accustomed to CC in the “Products” page of the CC Portal immediately. These are PP (Protection Profile), ST (Security Target) and EAL (Evaluation Assurance Level). Here are their definitions in full color:
A Protection Profile is a cry for help from the customer. It’s a document written by the technology user, and in essence it is something similar to, “I’m living in this kind of world and I’m doing that kind of business and I’m dealing with this and this kind of threats and I can’t cope with them. What I need is a device which has adequate amount of protection against the hyenas and weasels out there. Could you please develop that?” If you write that using regular language, it’s literature. If you write that according to the norms of Common Criteria, it is a Protection Profile. Although they are merely documents describing the users’ expectations from IT products, Protection Profiles are also subject to evaluation and certification.
A Security Target is a richly informative description document including the security features of an IT product and also the developer’s expectations from the environment where the product would be operated, so that the product and its environment may become one. It is written by the developers, saying something similar to “I know the life you’re living. I know your circumstances. There are hyenas and lions out there. I have developed that device right for you, which will keep the vampires from your door. They won’t be able to touch you ever again. Installing it on your door and changing its battery once a month is all you should do to sleep the nights.” If you write that using regular language like I did, it’s advertisement. If you write that according to the norms of Common Criteria, it’s a Security Target document and few would understand it.
In my humble opinion, the biggest benefit of CC is minimizing misunderstandings about the product and its security features among the user, developer and evaluator communities. That feat is accomplished by way of exchanging information in a well-defined format via the Protection Profile and Security Target documents.
Evaluation Assurance Level is the level of protection claimed by the developer, provided by the product, and verified by the Certification Body. The stronger your adversaries, the higher EAL you need. If you will cross the Bosphorus and there are jellyfish in the sea, your swimsuit should be conformant to EAL 2 (analogies are seldom perfect). If there are eels around the reef you want to photograph, your swimsuit should better be EAL 5. If you have been to a beach in Australia and a great white was spotted earlier in the day, better take a walk than swimming in the sea.
All in all, there are seven Evaluation Assurance Levels, whereas EAL 7 is claimed (and achieved) only by a handful of products among the 1589 active certificates as of November 2020. Note that certificates up to and including EAL 4 are granted recognition according to CCRA.
EAL, by itself, may be misleading. Here is how: It gives you an idea about the thickness and protectiveness of the fabric used to produce the swimwear, but not about which parts of the body are covered. When you are dealing with swimwear, the coverage is crystal clear the moment you see the swimsuit. When you are dealing with an IT product, coverage of the product isn’t that obvious immediately. Instead, comprehending the coverage (in other words, the certified security features) provided by the device requires studying the Security Target of that product.
4- Evolution of CCRA
Standards are living documents. Their content, as well as their application methods are subject to change. After a decade of application of CC and certification of hundreds of products, a couple of changes had to be made to the CCRA.
Experience has indicated, and it was whispered inside the CC community that “some evaluation results were not repeatable”. In plain language, a product certified to EAL 4, say, in New Zealand, have failed to pass one or more of assurance requirements in an evaluation laboratory in the importing country, for instance, France. Which means that two of the four objectives of CCRA, stated in the Preamble of the agreement, could not be fulfilled. These are:
- Ensure that evaluation of IT products and PPs are performed to high and consistent standards, contributing significantly to confidence in the security of these products and profiles,
- Eliminate the burden of duplicating evaluations of IT products and PPs.
A vision statement has been released in the annual CC Conference of 2012, declaring that “the CC process should be a little more PP-centric”. In simpler terms, “security features of products should better be based on the requirements of customers, as stated in the protection profiles”. Furthermore, the concept of cPP (Collaborative Protection Profiles) was introduced to improve the PPs as well. A collaborative Protection Profile is a Protection Profile written not only by the users (as described above), but also with the cooperation of product vendors, evaluators and academics working collaboratively as an International Technical Committee.
Article 2-Scope of CCRA was restricted in 2014 and the definition of cPP was appended to the agreement. You can take a look at the comparison of two versions of the Arrangement, signed in May 2000 and July 2, 2014 (which is also the version open to the public in the CC web portal as of November 2020) in figure 3:
Figure 3. Restriction in the Scope of CCRA
To sum it all up, according to the updated arrangement, certificates up to and including EAL 2 are recognized instead of EAL 4 if the product is not based on a cPP.
Modification of CCRA has not reduced interest in CC. Developers have kept on seeking certification above EAL 2 for products not based on cPPs, probably as a sign of quality and prestige that is obtained at the end of the rigorous evaluation process.
5- Collaboration and Openness Improve Security
System requirements are the input of IT product development process, whereas security requirements are a subset of the system requirements after all.
All in all, Collaborative Protection Profiles define validated security requirements more thoroughly thought out than the other protection profiles. Encouraging their development, certification and use by the CC community simply means hardening the security requirement validation process. Alteration of CCRA and encouraging the use of cPPs should be a lesson about the importance of requirement validation for the greater IT research and development community too. System requirements are the base you have got to perfect before moving forward to design and development, especially in turn-key projects with considerable scale. In my humble opinion, time and budget spent for requirement validation would improve the well-being of the overall project significantly.
CC Web Portal offers a wealth of information to developers and technology users alike. PPs, cPPs and ST documents of actively certified as well as archived products (whose certificates are overdue) are open to public access. So how come CC is of assistance to users and developers? The answer is, “Just like Wikipedia”.
Risk analysis is prerequisite to developing security requirements, and it is a challenge even for the most talented and experienced. Take a look at the “World Economic Forum-The Global Risks Report 2020”, if you like, to see how well they fared about predicting the probability of a virus pandemic. Hence, if you need to develop an IT product with security requirements, I suggest that you take a look at the CC web portal first. Your problem may already be solved and documented. First check out the “crème de-la crème” cPPs. If you can’t find a document that would shed light on your path, search the protection profiles. If they are no good either, scan the Security Targets. There are literally hundreds of Protection Profiles and thousands of Security Targets in the CC Web Portal. You don’t need to reinvent the wheel.
We love Wikipedia and we love the CC Web Portal.