Email Client & Web Browser Extended Packages Published
The National Information Assurance Partnership/Common Criteria Evaluation and Validation Scheme (NIAP/CCEVS) is pleased to announce the posting of the Application Software Extended Package for Email Clients v2.0 (https://www.niap-ccevs.org/pp/PP_APP_EMAILCLIENT_EP_v2.0/) and the Application Software Extended Package for Web Browsers v2.0 (https://www.niap-ccevs.org/pp/PP_APP_WEBBROWSER_EP_v2.0/). The Security Re...
Updated NIAP Policy #5 FAQ Posted
NIAP has posted an updated Frequently Asked Questions list for Policy #5. The FAQ provides information about CAVP/CMVP/NIAP alignment and what is expected for products evaluated in NIAP that include NIST validated algorithms/modules. NIAP Policy #5 defines Applicability and Relationship of NIST Cryptographic Algorithm Validation Program (CAVP) and Cryptographic Module Validat...
MDPP Equivalency Guidance Posted
The Mobile Device Fundamentals Protection Profile (MDPP) Equivalency Considerations Guidance document has been posted to the NIAP website. Please visit:
Wireless LAN Access System Extended Package Published
The National Information Assurance Partnership/Common Criteria Evaluation and Validation Scheme (NIAP/CCEVS) is pleased to announce the posting of the Wireless LAN Access System Extended Package. The Security Requirements for Network Devices collaborative Protection Profile (NDcPP) defines the baseline Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) for network infrastructure devices in general. This EP serves to extend the NDcPP baseline with additional SFRs and associated &lsquo...
DoD Annex to cPP for Stateful Traffic Filter Firewalls v1.0 Published
The National Information Assurance Partnership/Common Criteria Evaluation and Validation Scheme (NIAP/CCEVS) and DISA Risk Management Executive (RME) Office are pleased to announce the publication of the DoD Annex to the Collaborative Protection Profile (cPP) for Stateful Traffic Filter Firewalls v1.0. This document, created through DISA/NIAP collaboration, addresses the DoD specificity to the NIST SP 800-53 controls identified in the cPP. As a result, the Annex in conj...
4 DoD Annexes to NIAP Protection Profiles Published
The National Information Assurance Partnership/Common Criteria Evaluation and Validation Scheme (NIAP/CCEVS) and DISA Risk Management Executive (RME) Office are pleased to announce the publication of the DoD Annexes to the NIAP Protection Profiles for Application Software v1.1, Mobile Device Fundamentals v2.0, Extended Package for Mobile Device Management Agents v2.0, and Mobile Device Management v2.0. These documents, created through DISA/NIAP collaboration, addresses the DoD specificity to the NIST SP 800-53 contro...
Successful Completion of Acumen Security Lab Accreditation Evaluation
NIAP is pleased to announce the accreditation of Acumen Security as the newest CCTL. In keeping with the new paradigm, Acumen Security completed its trial evaluation against the NDPPv1.1 within the CCEVS goal timeframe, which included the time needed for the extra validation oversight required for trial evaluations.
Joint Statement of Support
As indicated in the Joint Statement of Support below, NIAP, in conjunction with the Common Criteria schemes from Australia, Canada, and the UK, has posted position statements regarding Common Criteria evaluation in three technology areas: General Purpose Operating Systems (GPOS), Database Management Systems (DBMS), and Enterprise Security Management (ESM). The statements may be found here.
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: