Joint Statement of Support
The Common Criteria Recognition Arrangement Participants listed below, greatly encouraged by the 'agreement in principle' reached by the CC Management Committee in respect of the updated CCRA, and the associated work of the CC Development Board editing group producing the draft process for the creation of collaborative Protection Profiles, have been considering how best to support the demand for progress on cPPs.
We have, as a first step, agreed to provide draft 'endorsement statements' for the following 'new style' national PPs most of which have been developed in a joint manner. We expect to be able to publish broadly similar formal endorsement statements as soon as the corresponding cPPs are produced.
- Software Full Disk Encryption (U.S. Government Approved Protection Profile - Protection Profile for Software Full Disk Encryption Version 1.0)
- Firewall Extended Package (U.S. Government Approved Protection Profile - Network Device Protection Profile (NDPP) Extended Package Stateful Traffic Filter Firewall Version 1.0)
- Network Devices (U.S. Government Approved Protection Profile - Protection Profile for Network Devices Version 1.1)
- Mobile Devices Fundamentals (U.S. Government Approved Protection Profile - Protection Profile for Mobile Devices Version 1.0)
- Mobile Device Management (U.S. Government Approved Protection Profile - Protection Profile for Mobile Device Management Systems Version 1.0)
- Virtual Private Network Client (U.S. Government Approved Protection Profile - Protection Profile for IPsec Virtual Private Network (VPN) Clients Version 1.4)
- Virtual Private Network Gateway - Extended Package (U.S. Government Approved Protection Profile - Network Device Protection Profile (NDPP) Extended Package VPN Gateway Version 1.1)
We will then work, together with any other interested CCRA participants, to take the first three technologies through the iTC/cPP process as it develops. The three were selected after a technical assessment of their level of complexity, priority, and match to available resources.
In parallel we will continue our ongoing support to the USB cPP development.
Our primary aims are to:
- indicate our strong support for detailed, repeatable, achievable, transparent cPPs
- produce a set of four cPPs (and associated supporting documents) as quickly as possible (expecting these to be completed before ICCC 2014)
- help assess and characterise the cPP process using well-understood start points
- create strong international Technical Communities in key areas to continue the development and maintenance of the cPPs etc.
Once these have been successfully produced, and lessons have been learned about the process, we will then apply our resources to other iTCs and cPPs. Of course other participants may, in the interim, be using the developing/completed iTC process for other technologies but resource constraints dictate that we are unlikely to participate beyond providing our position statements for these.
To provide the clarity and transparency sought by industry regarding national cPP requirements there are three technology areas where we are reassessing whether or how to evaluate products using the Common Criteria. These technology areas are General Purpose Operating Systems (GPOS), Database Management Systems (DBMS) and Enterprise Security Management (ESM). More information regarding our use of Common Criteria to evaluate these technologies will be forthcoming.
Additionally, given the complexity of Hardware Security Modules (HSM) and Virtualisation, we are not yet clear on the best way to evaluate these technologies. These technologies require community discussion about the feasibility of evaluations using the Common Criteria.
We also believe it would be useful to publicly state our shared aims for the Common Criteria, and for the changes we are jointly advocating within it. These are:
- To see CC used within our nations to ensure that commercial enterprise security products represent a commercial good practice level of security.
- To see iTCs raise the security bar in the standards they produce towards a goal of secure-by-default products suitable for emerging threats.
- We will not try and differentiate products within Common Criteria – we are simply saying they are ‘good enough’- appropriate to mitigate the likely threats they will face.
- Our standards are minimal, both in scope and content. We will describe what good looks like for enterprise security products in simple and straightforward language.
- We will be clear about those security technologies we see value in, and those which we don’t.
- We will be honest and open about why we are, and aren’t, doing things – which will be repeatable, testable, comparable, and achievable.
- The standards we help write and endorse will describe the totality of what will be assessed, and the totality of the level of assurance that we believe can be achieved.
- We believe that CC must be accessible to all product developers – both large and small. We work to ensure that even the smallest companies around the world are able to participate in this market.
- We need it to be easy for people procuring, deploying and using certified products to understand what was and what was not evaluated, the expected validity period, and how to effectively ensure the enduring security of their systems using them. These people should not need to be CC specialists to accurately understand the value of a particular certificate.
- We aim to clearly explain to users how to use products in the evaluated configuration; as an aspiration, the evaluated configuration should be the out-of-the-box configuration. Evaluated configurations need to match real-world use-cases.
- We will also raise awareness amongst vendors and users that certificates are not absolution from vulnerability – assured products must be used as part of an overall security ecosystem and architecture.
- We will work collaboratively with CCRA participants and industry to achieve these aims as quickly as possible.
Statement Supported by The Following Common Criteria Schemes: