Division Zero (Div0). Copyright © 2011-2018

All rights reserved.

Common Criteria — An Interview with Jussipekka Leiwo

12 Aug 2011

How much do you know about Common Criteria? It is a deep field not widely taught nor explored in many course of studies in universities and polytechnics in Singapore.

 

The Edgis Core Team interviewed Jussipekka Leiwo, a leading expert in Common Criteria, to share with us what is it like to be in the Common Criteria industry.

 

I met Jussipekka when he gave a presentation on “High Assurance Security Product Life-Cycle Considerations” at Govware last year. 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 is currently setting up an assurance test lab, Brightsight Asia Pacific, in Singapore.

Edgis: We’ve realised not a lot of people, including the “techies”, are familiar with Common Criteria. Can you please share with us what is Common Criteria?

 

Jussipekka: Common Criteria 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 Common Criteria 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 Common Criteria, and whether there are any residual vulnerabilities that can be exploited in the intended operational environment of the product.

 

There are levels of rigor, 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 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. Common Criteria 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.

Edgis: Is it worth being Common Criteria certified? If so, who are the target?

 

Jussipekka: Common Criteria 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 Common Criteria 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.

Edgis: 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 recognized best practices such as Common Criteria 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 recognized 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. Common Criteria is closely related to various Capability Maturity Models and as such, can be easily integrated into the engineering practices.

Edgis: How long is the evaluation process from start to the end?


Jussipekka: This is the major weakness of Common Criteria. 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 Common Criteria. 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.

Edgis: With the rapid pace technologies are moving these day, will Common Criteria 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.

Edgis: If one wants to start on the process on getting Common Criteria certified, how would you advice 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.

Edgis: How widely is Common Criteria adopted these days?


Jussipekka: By the time of writing this, a mutually recognised Common Criteria scheme exists in 15 countries and additional 11 countries recognize 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 recognized Common Criteria scheme are to a defined extent recognized 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 member state are – because of the various arrangements for free movement of good and services within the Union – recognized 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.

Edgis: What do you see Common Criteria 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 Evaluation Assurance Levels 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 Common Criteria and replacing a pre-defined EALs with assurance packages expressed in the CC notation but derived from their domestic security initiatives.

 

These developments whill 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 the Common Criteria. 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 Common Criteria 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.

Edgis: 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. Common Criteria 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.

Edgis: I understand it isn’t easy to survive as a Common Criteria 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 the Common Criteria 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 mind set 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 much paper qualifications other than a basic set of IT or related skills. As long as the attitude and mind set 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.

Edgis: Thank you Jussi for taking your time off your busy schedule to have us.

 

Jussipekka: My pleasure. I always enjoy talking to you.

Share on Facebook
Share on Twitter
Please reload

RECENT POST

September 5, 2017

Please reload

CATEGORIES
Please reload

TAGS
RSS
RSS Feed