I had the pleasure of recently presenting at the International Common Criteria Conference (ICCC) in Kuala Lumpur, Malaysia.  This was the fifth ICCC that I have attended and the fourth consecutive one that I was honored to present a paper.  There are two main themes that I took away from the conference:

• The "Common" in Common Criteria is at risk of disintegrating
• No one agrees on what Supply Chain integrity means and how it applies (or not) to the Common Criteria. 

In today's blog I will discuss the first item; I'll talk about Supply Chain in Part 2.

When I say that the "Common" in Common Criteria is at risk of disintegrating what do I mean?  Common Criteria currently uses Evaluation Assurance Levels (EALs) to provide a structure that has been adopted worldwide as a way of measuring depth of testing and security assurance.   There are seven EALs. The higher the EAL, the greater the depth and breadth of testing and documentation required, adding significant time and cost to the evaluation.  EALs generalize assurance activities without recognizing that different technologies may require different methods of validation.   At the ICCC, we heard that EALs are a fundamental element in the CC and to remove EALs would require a unanimous vote by all 26 countries in the Common Criteria Recognition Arrangement (CCRA).  So the US is pushing to remove Evaluation Assurance Levels (EALs) from the Common Criteria via National policies vs. cracking open the CC and revising it.   The US is driving its agenda to put all of the assurance requirements in the protection profiles being written by its technical communities.  Many of the other countries believe in the science of EALs and utilize them for important technologies like Smart Cards and Multi-function devices. National policies run the risk of fracturing the CC and potentially requiring vendors to evaluate their products more than once.  Without EALs there is no mutual recognition - no "common" in Common Criteria.

I have written previously about the flaws in the CC, including the issues that the CC doesn't really provide assurance that a product is safe or secure.   However this is a case where, "The Devil you know is better than the one you don't know" applies.  Since the CC does require products to go through a rigorous exercise of documentation and testing the results of these evaluations are "recognized" in 26 countries.  The CCRA allows vendors like CA Technologies to evaluate a product once and sell it globally.   This "mutual recognition" treaty is the critical element to what makes the CC so invaluable, but it only works if national policies don't break the fundamentals of the Common Criteria.     

So while this balancing act of mutual recognition risks fracture, the Common Criteria Development Board (CCDB), led by David Martin from The National Technical Authority for Information Assurance in the UK (CESG) is pushing its agenda of Collaborative Protection Profiles (CPP).   The group even wrote to the Common Criteria Vendors Forum and Common Criteria Forum and asked among other things for recommendations on best approaches for "...Collaborating with CCDB members on the production of a 'how to' paper describing the best approaches to the formation and running of a technical community."  Having led a Technical Community for the last 2.5 years with the Enterprise Security Management Protection Profile Project (ESM PP) we certainly plan on contributing to that project but right now it is not even clear that the ESM PP work will be recognized by the CCRA as a legitimate technical community. 

What is clear is that the Common Criteria will not be revised anytime soon, and the "ask" that I mentioned above for the CC community has placed the burden of revising or fixing the CC via technical communities on what David Martin called "coopetition" (a play on cooperate and compete).  The CC has it right that industry can and should help to evolve the standard, but the lack of overall "coopetition" cannot be ignored - let's fix this together!