How much do you know about Common Criteria (CC)? It is a deep-tech domain not widely taught nor explored in many courses of study in universities and polytechnics in Singapore.
The Div0 Crew (previously known as the Edgis Core Team back in 2011) interviewed Jussipekka Leiwo, a leading expert in CC, to share with us what is it like to be in the CC industry.
Div0: We realised not a lot of people, including the “techies”, are familiar with CC. Can you please share with us what is CC?
Jussipekka: CC is an international standard for assessing the trustworthiness of computer security products. The developer of a product makes a claim of the security functionality that is implemented in the product and documents the implementation of that functionality in accordance with the CC standard. An independent evaluation facility then assesses the product against that claim and documentation to determine whether the security product indeed implements the functionality as claimed, whether the documentation meets the requirements stated in the CC, and whether there are any residual vulnerabilities that can be exploited in the intended operational environment of the product.
There are levels of rigour, called Evaluation Assurance Levels (EAL), to which the product must be documented and evaluated for increasing levels of security assurance. Any security functionality can, in theory, be evaluated to any EAL so the developer has a lot of flexibility in making the security claim. The developer of the product has to choose the EAL and engineer and document their product accordingly. Once the evaluation facility is satisfied that the product is engineered and documented as claimed and that there are no residual exploitable vulnerabilities, the evaluation results are passed to a certifier, usually a government body, who oversees the evaluation and evaluator and once satisfied that the evaluation is properly carried out, issues a security certificate for the product.
The core idea of the framework results from the need for the customers of security products to have a thorough definition of the security claims of the products to fully assess the suitability of the product for their need and yet, most customers do not have the resources to fully assess the product but prefer having accredited laboratories to perform the assessment on their behalf. Further, most vulnerabilities are against the implementation of security functions, not against the theoretical properties of used security techniques. For example, a claim that a product is unbreakable since it uses 256-bit AES for which known attacks exist is false given that while AES is considered secure for most applications, there may be flaws in the implementation of AES in the product which can be exploited without breaking the cipher itself. CC can be used to bring forth a convincing assurance argument that the deployed security techniques are sound and that they are implemented in a secure manner.
Div0: Is it worth being CC certified? If so, who are the targets?
Jussipekka: CC certification may be required for selling security products to government customers. Many nations have policies and regulations that mandate giving preference to certified products in procuring IT Security products. If a company is willing to sell their products to any government customers, they should check the relevant policies in those countries and see whether CC is mandated or recommended.
In Singapore, the Singapore Infocomm Technology Security Authority (SITSA) is working on their heavily CC-inspired National IT Evaluation Scheme (NITES) scheme with the intention that any security product to be deployed in government systems with high security requirements will have to go through NITES certification. We can – as soon as our accreditation as a NITES evaluation laboratory is complete – in fact combine a NITES evaluation with a CC evaluation to produce two separate certificates for the product in question.
Div0: Why do you think it is important to integrate evaluation criteria into the Research and Development (R&D) process of new products?
Jussipekka: Conceptually, security assurance is not fundamentally different from quality assurance. Trustworthy IT Security products result from proper application of rigorous engineering practices in the engineering of the product. The rigour and conformance to international standards of the engineering practices (such as the CC) can be independently verified by an impartial laboratory to produce an assurance claim for the product.
Instead of inventing company-specific practices, companies should follow internationally recognised best practices such as CC to specify and document their security products. Even if formal certifications are not planned, most customers do require a convincing assurance argument and following a recognised process and standard in the engineering of IT Security products is a reasonable assurance argument even if not backed up by a formal security certificate. CC is closely related to various Capability Maturity Models (CMM) and as such, can be easily integrated into the engineering practices.
Div0: How long is the evaluation process from start to the end?
Jussipekka: This is the major weakness of CC. Evaluations do take a long time. The developer’s effort is considerable and even a simple evaluation can easily take up to six calendar months to complete. Most real-world evaluations take between 6 and 12 months but complex evaluations can take up to 18 to 24 months especially when the developer is not fully familiar or experienced with CC. A good evaluation facility will be able to help the developer in managing the time-line of evaluation to ensure that no more time and resources are spent than is absolutely necessary.
Div0: With the rapid pace technologies are moving these days, will CC become a bottleneck for product development in the near future?
Jussipekka: That may happen, and there are claims that given the rapid R&D advances, certified products are already obsolete by the time they obtain the final certificate putting the government agencies and such using the products into a disadvantaged position. The time to market pressures faced by R&D companies to produce new product versions to the market are quite contradictory to the need for certificates – especially as any change in the security functionality of the product invalidates the certificate – and have to be managed carefully by the company seeking for a certification. If a CC evaluation is a one-off effort, the risk of becoming a bottleneck is high, but if the CC evaluations are an integral element in the engineering of high assurance product lines, the time and cost issues can be more effectively managed over the life-time of a product line.
Div0: If one wants to start on the process of getting CC certified, how would you advise him/her?
Jussipekka: The most important thing is to engage a good laboratory or otherwise experienced consultants early on and rely on their experience in avoiding the traps on the way. Consultants are most valuable in the early stages of planning.
Div0: How widely is CC adopted these days?
Jussipekka: By the time of writing this, a mutually recognised CC scheme exists in 15 countries and an additional 11 countries recognise the certificates without having a scheme of their own. There are also other schemes but those are not part of the Common Criteria Recognition Arrangement (CCRA). Certificates issued under countries which have a CCRA recognised Common Criteria scheme are to a defined extent recognised by all other CCRA member states. Therefore, the developers only need to obtain one certificate to get recognition in all member states. Further, certificates issued in any European Union (EU) member state are – because of the various arrangements for free movement of good and services within the Union – recognised in all other member states even if the EAL is beyond what is covered by the CCRA.
The number of certified products on the market is rather large and can be investigated at http://www.commoncriteriaportal.org. The portal also links to the web sites of different schemes where further information is given.
Div0: What do you see CC as in the future?
Jussipekka: In the near future, one can expect that the future versions of the standard will continue the trend of making especially the evaluations at lower EALs quicker and cheaper. Alongside the new nations joining the CCRA, this is likely to make the CC more accessible to developers who have considered it too slow and expensive in the past. At the same time, there is more tailoring of the standard to the local conditions. A good example would be the American scheme putting less emphasis on the EAL structure of the CC and replacing a pre-defined EALs with assurance packages expressed in the CC notation but derived from their domestic security initiatives.
These developments will introduce some complexities to the recognition of the resulting certificates but it is likely that the international recognition will remain a critical success factor of CC. Beyond the international recognition, the high assurance evaluations, especially in the smart card domain, are likely to continue diversifying into a specialised field within the CC community. An interesting topic will remain to see how the high-end security evaluations in the banking and payment domains (banking cards and payment terminals in particular) will relate to the CC in the future.
Div0: What is your next 5–10 years plan?
Jussipekka: My key objective right now is to get the Singaporean operation fully up and running. We are growing quite aggressively and looking into more people to join us in the Asia Pacific operation. CC will be in the core of our service offering but through our HQ in The Netherlands, we get significant exposure to other high assurance security standards, too. We are also working to become an accredited laboratory under the NITES scheme by SITSA. Further, we are looking into transfer of knowledge and expertise from our main office in Delft, The Netherlands, to expand our capabilities in cryptographic and other advanced security testing. Over the long term, the objective is to mature the Singaporean operation to become a leading provider of high assurance security assessment services in the region.
Div0: I understand it isn’t easy to survive as a CC evaluator. As a leading expert in the field for so many years, can you share with us what are the essential skills that an evaluator should possess?
Jussipekka: Basically, there is one essential requirement for an evaluator: the ability and willingness to think creatively. One has to follow a rigorous process (defined in CC and the accompanied Common Evaluation Methodology) and be in full conformance with the testing laboratory processes and policies while carrying out the evaluations, but at the same time, one is required to identify alternative ways of accessing the product to identify and test it for possible vulnerabilities. This sounds quite abstract but as long as the certain type of curious mindset is there, the technical skills can be learned.
An evaluator is also expected to work on a broad range of projects, both as evaluator and consultant, so one has to be prepared to keep constantly learning new things and work on different types of projects and technologies.
Technically, one needs quite a thorough understanding of information security and engineering of software and/or hardware. Depending on the type of products, good electronics and mathematics knowledge is also required. However, it is not realistic to expect any individual to have all the necessary skills so a good team of evaluators can complement the skills of each other and work together to ensure a good outcome.
In particular, when hiring new staff at the junior levels, I don’t expect to see many paper qualifications other than a basic set of IT or related skills. As long as the attitude and mindset are there, the specific technical skills can be acquired at work through training and hands-on engagement in projects under the supervision of experienced evaluators.
Div0: Thank you Jussi for taking your time off your busy schedule to have us.
Jussipekka: My pleasure. I always enjoy talking to you.
Personal Note by Emil Tan:
I met Jussipekka Leiwo when he gave a presentation on “High Assurance Security Product Life-Cycle Considerations” at GovWare 2010. He did not hesitate to share his knowledge with me when I was looking into preloaded malware in software/hardware some time back. He is a great advisor and an amazing friend. Jussipekka Leiwo is currently setting up an assurance test lab, Brightsight Asia Pacific, in Singapore.