About PPs, CC Technical Communities and ITSEFs

atsec's ITSEFs, like many other IT Security Evaluation Facilities (aka: laboratories), are committed to supporting the CC community, and understands and supports the development of good, and useful Protection Profiles. We support the objectives of the CCRA:

1.  to ensure that evaluations of Information Technology (IT) products and protection profiles are performed to high and consistent standards and are seen to contribute significantly to confidence in the security of those products and profiles;
2. to improve the availability of evaluated, security-enhanced IT products and protection profiles;
3. to eliminate the burden of duplicating evaluations of IT products and protection profiles;
4. to continuously improve the efficiency and cost-effectiveness of the evaluation and certification/validation* process for IT products and protection profiles."

We support the participants of the CCRA to achieve the goals and the purpose of the Arrangement: 

"to advance those objectives by bringing about a situation in which IT products and protection profiles which earn a Common Criteria certificate can be procured or used without the need for further evaluation. The arrangement seeks to provide grounds for confidence in the reliability of the judgements on which the original certificate was based by requiring that a Certification/Validation Body (CB) issuing Common Criteria certificates should meet high and consistent standards."

An ITSEF supports the certificate issuing schemes of which they are a part by:

a) performing evaluations impartially;
b) applying the Common Criteria and Common Methodology correctly and consistently; and
c) adequately protecting the confidentiality of protected information.

The costs of developing a PP that can be mutually recognized under the CCRA

The costs of evaluation (including PPs) are typically presented in three parts:

1. the costs of development, and review of the PP;
2. the costs for the  evaluation of the PP by an accredited ITSEF (Assuming that it needs to be evaluated at all, although evaluation, validation, and certification of a PP is a requirement of the CCRA for mutual recognition of the PP to be considered.);
3. the costs incurred by the national scheme for validation and certification of PPs  make a charge for such an evaluation.

An ITSEF's responsibilities

Those responsible for the formation of technical communities focused on PP development, regardless of whether this is a NIAP technical community,  one formed under the CCDB, or one relating to any other scheme need to understand the nature of the ITSEF as a stakeholder in the business of CC certification.

ITSEF are a class of stakeholder with different objectives, risks, and duties than developers, evaluation sponsors, and national schemes. Here are some of the issues that an ITSEF must consider:

1. Evaluation under CC is a core service of an independent ITSEF
   The smaller laboratories, unlike those that are part of a larger organization, such as a defense integrator, do not produce any products, nor do they offer any services outside of the information security domain.
   As a small company, an ITSEF has overheads. Evaluators typically take a minimum of two years to train and they need to be fully allocated to ensure the health of a small company.
2. Pro-bono work (Performing evaluations free of charge)
   Of course an ITSEF may attach any price to their evaluation services. An ITSEF needs to cover it's overheads including training, accreditation costs, facility maintenance, etc.
   For a small independent ITSEF, the pro-bono work that they undertake represents a very significant investment and unlike the larger ITSEF that are, for example, part of a large defense integrator, cannot be funded through a separate research or business development budget from outside of the lab. Consider the investment that one or two full time people represents to a large company such as a defense integrator with thousands of employees, compared to a small independent ITSEF!
3. Conflict of interest
   If a laboratory has been involved in  technical consulting for a PP, no matter the price attached to such a service, then there is a clear conflict of interest in their performing the subsequent evaluation of the PP.
4. Contract for evaluation of a PP
   Regardless of the price attached to the evaluation of the services, an ITSEF must have a contract. Contracts address many more issues than just the price. They include items such as:

• confidentiality
• protection of IP, 
• termination of the work
• standard of service
• warranty (for example that the ITSEF works under an accredited CC scheme)
• professional insurance
• conditions for the use of trademarks
• conflict of interest considerations
• and a great many other issues...

Asking a laboratory to perform such evaluation work without a valid contract would be asking them to act in a very naive and unprofessional way. Note that in order to gain accreditation under a CCRA certificate producing scheme, an ITSEF must be accredited to ISO/IEC 17025 (NIST's Handbook 150 and 150-20 in the U.S.). This is a requirement of the CCRA.

One of the requirements of ISO/IEC 17025 is that a contract is in place between the ITSEF and their evaluation client (sponsor) covering the topics mentioned above. Many schemes independent of the CCRA also require an ITSEF to have a contract, because there are often requirements of the individual  validation scheme's operations that need to be passed to the ITSEF approved to work with that scheme. Examples include the need for a national scheme to be able to implement policies and requirements for use of their logo and to pursue any cases of certificate misuse.

In short, performing evaluation services that are covered by accreditation as an ITSEF without a contract would mean that the ITSEF is not conforming with the requirements of the ISO/IEC 17025 standard. In turn, that would mean that the evaluation was not performed in accordance with national scheme and CCRA requirements.

What this means for the Terms of Reference for a technical community
These issues need to be considered in the formation of technical communities and the development of their Terms of Reference. An expectation of contract-less evaluation services by an accredited evaluation facility is unrealistic.

It is therefore necessary for a technical community to have the means to negotiate and sign such a contract, and also to negotiate and raise funds for any costs outside the development of the PP that may be necessary.

By Fiona Pattinson 

Technical Communities as posed by the CCDB

The CCDB have posted on the CC portal a draft vision statement about technical communities and the development of Collaborative Protection Profiles (CPPs) and supporting documents.

There was much discussion at the last ICCC conference on this topic and since then I've had several discussions on the topic with a few of my CC community colleagues. I thought it might be useful to bring the discussion to a more public forum so that the thoughts and comments of others in the community can be added and heard. So please add your valuable comments. :)

The draft vision statement requests technical communities (TC) and acknowledges that a “Terms of Reference” needs to be in place without, so far, elucidating in too much detail about what precisely is expected. Such a TC will be responsible for developing and maintaining CPPs and their supporting documents for technology areas (yet to be decided) that can be used in evaluations under the CCRA by many nations. These documents will be approved by the CCDB by some formal mechanism.

To be successful the TCs will need to include representation of all the stakeholders related to the documents at least from the end-user communities, the vendors and integrators, laboratories, schemes, and even, perhaps, the CCDB itself.

As well as bringing together a community of technical experts, there are non-technical issues that need to be considered when developing such documents in such a community including how to deal with anti-trust, patents, copyright, intellectual property, and so on. These are not trivial considerations and especially in a multi-national setting need to be addressed by experts in that field if the risk of (expensive) problems are to be avoided. Although the CCDB/MB propose a governance structure it does not seem to extend to the provision of these services/practices to a TC, these are well established needs in the commercial world.

For this reason so far, none of my colleagues have suggested that a simple “clan gathering of technical experts”, such as the CCF or CCVF in the form that they have so-far existed is likely to be successful. Such a Technical Community must have global reach, provide legal support, and be capable of forming a relationship with the CCDB. Since the CCDB is expecting to provide some authority, or formal acceptance of CPPs from a TC, and proposes a governance structure within the CCDB for formalizing the acceptance of CPPs by the CCMB and even "appointing" a TC then that may need to be a formal relationship with a contractual type relationship between the two organizations.

One important consideration related to operating under an organization that provides these "meta services" to the development effort is that there is a direct cost associated with them. Administration of a global group, providing legal services and processing any issues that arise is expensive, and usually those costs are recovered through the membership in the form of membership fees, or by charging for the standards and documents produced. Also note that community that has stakeholders based internationally is likely to include international travel. Without a formal agreement between the CCDB/MB and the TC there is a risk that a significant investment by members of a TC could be lost.

Costs of participating are a factor for consideration and may end up effecting how smaller organizations can effectively participate. Consider also that for some stakeholders including laboratories, schemes and end-users that it may be necessary to participate in more than one technical community. There may be benefits of simplicity and cost if all Technical Groups are under one umbrella, but that may be a difficult goal to achieve if there are several independent TCs established.

So, we must consider that a TC is in fact developing standards that will be used in an international setting, and we observe that many of the established standards development organizations (SDO) may meet the needs stated above. There are several general SDO groups that might meet the requirements. ACM, IEEE, ISO, ITU, The Open Group, to name a few. Technology specific groups, for example ITU; The WiFi Alliance; and many others too numerous to mention, may also be considered.It might be the case that a combination or organizations meet the needs of the the CC community, but then the CCDB would need to develop relationships with several organizations.

We also need to consider the CCDB's requirements for such a community. Their draft vision statement says that such a community must have:

• Terms-of-Reference (describing rules for membership, voting procedures etc) and regular liaison statements are needed;
• Work in progress/intermediate outputs shall be open for all interested parties and will be referenced on the CC portal.

The success of the smartcard TCC cited by the CCDB is interesting. I'm wondering if someone has the knowledge to describe the characteristics of this group, and the factors that have made it successful. Has this group in fact faced some challenges? If so, what were they?

Below is a discussion of some of the attributes of a couple of groups that I know enough about to present. I'm not specifically promoting these but discussing the merits of each in the context of the TC model proposed by the CCDB may allow some further analysis about the CC communities approach to this problem.

I'm hoping that others may contribute a summary or comment about SDOs or organizations that they have knowledge of. Perhaps with this knowledge we can understand the landscape and opportunities for potential and effective technical communities.

ISO
ISO has a mature governance, structure, and mechanisms for dealing with issues of anti-trust, copyright, patents, IP etc.

• ISO/IEC JTC 1/SC 27 WG 3, who are responsible for editing the ISO/IEC 15408 standard and whose terms of reference includes work such as Community Protection Profile (CPPs), already has a formal relationship with the CCDB.
• An ISO standard (perhaps a CPP) can be formally adopted or not by each nation as a national standard, and carries a status of international recognition.
• Many of the SDOs including national standard's bodies and SDOs such as The Open Group, IEEE etc are already represented and have the right to submit existing standards through the PAS or Fast Track procedures for consideration as International Standards.
• It is an organization of which national standards bodies and liason organizations are the representatives rather than commercial organizations. Commercial organizations, vendors,laboratories etc would be represented at least once removed, and may not be easily represented in some countries where the national standards bodies are not comprised of commercial or stakeholders other than the government.
• Unless a CPP is submitted as a PAS from a formal liaison organization or is agreed to be Fast Tracked might take 3-4 years to produce an approved, published document.

The Open Group

• The Open Group has a mature governance, structure, and mechanisms for dealing with issues of anti-trust, copyright, patents, IP etc.
• The Open Group operates on a consensus approach
• The Open Group is able to flexibly configure a "forum" or various working groups that may meet the need for a Technical Community(ies).
• The Open Group operates internationally
• Many vendors from a variety of technology areas are already members.
• It is an organization of which commercial organizations can be directly represented. It is Open to membership by vendors, government organizations, laboratories, end-users etc.
• It already has a liaison relationship with ISO (and other SDOs), and could form a formal relationship with the CCDB, individual schemes, other MRAs etc.

This post is also mentioned in the Linked In Common Criteria professionals group.

by Fiona Pattinson