Update from CC Development Board June 2011
Background
At the 2010 ICCC11 held in Antalya Turkey, the report from the CCDB (see CCDB Report to ICCC11) provided an overview of the development work being coordinated by the CCDB, and explained how the schemes in the CCDB aim to build upon the clear success of the smartcard community and develop technical communities for a number of areas of technology.
These technical communities will develop Protection Profiles and associated supporting documents that can be adopted by as many countries as possible thus working towards the third CCRA objective (as stressed by the CCMC chair in his ICCC11 presentation) - 'to eliminate the burden of duplicating evaluations of IT products and protection profiles'. Once appropriate and widely agreed Protection Profiles are in use, these can be considered by several nations as a de-facto standard and could be recommended for use in government procurement.
Draft Vision Statement
At its latest meeting the CCDB discussed how to further the creation of Technical Communities, how best to meet the third CCRA objective of supporting the development of protection profiles and supporting documents that are as widely applicable as possible, and how to efficiently involve other stakeholders in the process. As a first step the CCDB produced this draft vision statement.
The draft statement and the process it outlines, are based upon lessons learned from the existing Smartcard communities. This community defines and requires specific expertise, tools, and information sharing in order to support an effective evaluation and assurance process for that technology. Using the same approach for other technologies will lead to communities being able to create successive generations of requirements, making clear the specific threats mitigated by specific features, the correctness and effectiveness of which are either attested to through specified activities by the developer or evaluated (the appropriate routes in each case being agreed by the community). Most of the value is derived by having the community and creating the successive generation of requirements that are used by developers at the start of the process rather than by performing the evaluations at the end of the development process. The more compelling the threats, the more specific the requirements, the greater the value - This allows schemes to choose to shift from the art of evaluation by a pool of individuals, covering a range of technologies, with varying experience and skills, using a generic methodology, to the science of specifying what is wrong, taking a stance (using acknowledged domain experts) about what can mitigate the problem, and creating a repeatable and objective process using detailed protection profiles and supporting documents, that consistently achieves the same assessment result. Schemes may also choose for any problems that are not addressable this way to be openly acknowledged to risk owners.
There are aspects of the document that need to be defined in more detail before it will be ready to be formally adopted. For example, in order to ensure fair competition and to promote wide acceptance, the CCDB must agree on governance criteria for a community to be approved to create Collaborative Protection Profiles. These criteria should address CCRA expectations for who is allowed to participate, how requirements are created, and for the process used to agree upon the content in the final document.
To help move the process forward quickly however, the CCDB decided to publish this draft and elicit constructive comments from other stakeholders. These comments, combined with lessons resulting from the various initiatives currently developing PPs and supporting documents, will lead to the publication of a formal vision statement and associated procedures etc. The CCDB considers this an important step forward, needing both time and stakeholder input to refine and make ready for implementation. We look forward to receiving constructive comments in writing through the schemes.

About the CCRA