1. National Information Assurance Partnership Paul Mansfield January 2013
An Evolution

2. Common Criteria Recognition Arrangement (CCRA)
Certificate
Consumers
Finland
Greece
Israel
Austria
Turkey
Hungary
Czech
Republic
Singapore
India
Denmark
Pakistan
Malaysia US
Canada UK
Germany
France
Australia
Japan
Netherlands
Norway
South Korea
New Zealand
Spain
Sweden
Italy
Certificate
Producers

3. 2012 International Common Criteria Conference
Common Criteria Recognition Arrangement (CCRA) Management Committee (CCMC) Agreement
Vision Statement
Develop Collaborative Protection Profiles (cPP)
International Technical Communities (iTC)
CC Schemes
Labs
Stakeholders
Vendors
CCMC Chair Directed CC Executive Secretariat and CC Directors Board
Update CCRA
Terms of Reference & CCRA Documents
Transition Plan

4. 2012 ICCC Vision Statement Key Points
Raise General Security Level
Standardization
CCRA Mutual Recognition – cPP
iTCs Define cPPs
cPPs Instead of Individual STs
STs w/o cPP – Limited to EAL2
2 Nations Disagreement
Evaluations above cPP
National Requirements & Special Arrangements
CCRA cPP Only
cPPs Will Address Vulnerability Analysis
Transparent and Repeatable

5. Develop, promulgate and manage foundational security requirements
NIAP Functions:
Prioritize PP Development
Author and promulgate PPs
Conduct risk analysis
Develop profiles with a risk-based mindset
Influence international standards (e.g., ISO)
NIAP leads technical communities to develop, promulgate and manage foundational security requirements that enable the acquisition of validated products to continually improve network defense for America and its Allies.

6. GOTS vs. COTS Government Devices (GOTS) Commercial Devices (COTS)
Traditionally, the US government has used government designed and certified devices to protect its most sensitive data.
Government Devices (GOTS)
Purpose-built for security
Strict design and implementation criteria
Long, exhaustive security evaluation
Commercial Devices (COTS)
Provide a balance of security and features
Quick to market, flexible

7. Committee on National Security Systems Policy (CNSSP) 11
COTS comply with NIAP process
Layered COTS preferred over GOTS
GOTS evaluated by NSA
Evolution
Move away from Evaluation Assurance Level (EAL)
Comply with Protection Profile (PP)
PPs developed by Technical Communities
CCRA Collaborative PPs (cPP)

8. Benefits of New Evaluation Process
One Evaluation Level
Achievable, Repeatable, Testable
One PP per Technology
Internationally accepted
Objective Assurance Requirements
Extended Package (EP) if required
Technical Communities
Industry/Government Partners, shared expertise, contribute to PP development

9. What’s Not Working?
“Cookie cutter approach” to technology type being evaluated
Subjective, inconsistent standards across vendors or countries
Higher EAL doesn’t equal higher security
Process is too lengthy
Not repeatable across labs, schemes/nations
No enforcement of security requirement testing
EALs are not related to the technology type being evaluated, such that a USB and Firewall are evaluated against the same criteria. Evaluations at higher levels of assurance provide a false sense of confidence. Common Evaluation Methodology (CEM) does not recognize technologies as different – rather, the current model utilizes a cookie cutter approach.
Since the EALs are broad, vendors can choose the standards they want the products to be evaluated against an EAL. Each nation creates their own testing regimens. There has not been sufficient cooperation among all stakeholders to reach agreement in requirements. In many nations conforming to CC evaluations is optional.
A higher EAL level meant that the product adhered to a more stringent set of quality assurance requirements during evaluation, but the security features were not tested.
A higher EAL level does not mean that one product is more secure than another, so that in reality, an EAL6 product may be no better than an EAL2 product.
b. The CC became an opportunity to force vendors to disclose sensitive information.
Evaluations for an EAL can take years to complete, which can mean that products may be out-of-date by the time an evaluation is completed.
EAL evaluations are not repeatable across the labs, schemes or nations.
EALs look at documentation of a security requirement being implemented but does not test the security requirement.

10. What is a Protection Profile?
Tailored set of baseline security functional and security assurance requirements
Focuses on tailored requirements and assurance activities by technology
Tailored set of use cases, threats, and objectives
Allows for the expansion of baseline requirements through extended packages for specialized technologies
i.e. Network Device PP and Firewall EP
PPs are a set of security functional requirements that have international recognition.
A PP is tailored to products of a specific technology type, such as a Network Devise or IPSec for VPN Clients. It focuses on functional requirements and assurance activities by technology.
PPs can have extended packages so that specific functions of a product can also be evaluated.
An example of an extended package would be for a firewall. The firewall would be evaluated against a Network Devise PP and then also to a Firewall Extended Package.
The requirements of PPs will be a set of technology-specific threats and core function requirements necessary to mitigate those threats to create a basic level of security for a particular technology and product.

11. Why Are PP’s Good (Achievable) Reduced time and costs of evaluation
(Repeatable) Produce comparable and meaningful results across labs/schemes
(Testable) Assurance Activities – tailored CEM
Assurance of product compliance
Address specific threats
Created and maintained by Technical Communities (TCs)
PPs are achievable, repeatable, and testable
PPs should be completed within a 4-6 month time frame instead of years, which drastically cuts down time and costs.
PPs include a set of tailored technology-specific threats derived from operational knowledge and technical expertise along with a set of core functional requirements necessary to mitigate those threats.
There is only one evaluation level, PP compliant, so that all products that have been evaluated are to the same standards. Comparable and meaningful results are produced.
They establish a basic level of security for a particular technology and include assurance activities so that the evaluations become repeatable across labs, require less documentation, and become more time effective.
Requires vendors to disclose only information pertinent to evaluation and safeguards their proprietary information.
PPs are have less subjective requirements/test criteria. Vendors and labs can no longer choose only a few requirements to be evaluated against; they must adhere to all assurance activities (e.g., testing requirements), so that a product will be truly PP compliant. Tailored CEM (Common Evaluation Methodology)
PPs are created and maintained by Technical Communities (TCs) so that all requirements can be met by all vendor types, thereby giving a larger role to industry and providing greater incentive to participate.

12. Collaborative environment to create requirements and standards for PPs
What Exactly Are TCs?
Any participating vendor, country, critical infrastructure, evaluator or lab
Collaborative environment to create requirements and standards for PPs
Ultimate creator of PPs with NIAP guidance
TCs consist of any vendor, country, critical infrastructure, evaluator, or lab that wishes to participate.
TCs are a collaborative environment where all involved help in creating the requirements and standards set forth by a PP.
NIAP will continue to be the forefront of the PP, helping to guide and write the PPs, but it will ultimately be the TC that will set the requirements, thus allowing an equal opportunity for all to meet these requirements.

13. ST vs. PP Example (click)
1.) You have some device that you wish to have evaluated. (click)
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity

14. ST vs. PP Example Protection Profile Security Target *SFR 1 *SFR 1
Functional Package
Functional Package
**SAR 01
SAR 02
SAR 03
SAR ....
SAR 24
**SAR 01
SAR 02
TAA 03
TAA ....
TAA 10
(click)
2.) The device will either go against an EAL a Security Target (ST) or a Protection Profile (PP).
A vendor ST can claim any valid “Functional Package”, i.e. any valid combination of security functional requirements.
A vendor ST can claim any valid “Assurance Package”, i.e. any valid combination of security assurance requirement.
Assurance Package
Assurance
Package
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity

15. ST vs. PP Example Protection Profile Security Target *SFR 1 *SFR 1
Functional Package
Functional Package
**SAR 01
SAR 02
SAR 03
SAR ....
SAR 24
**SAR 01
SAR 02
TAA 03
TAA ....
TAA 10
(click)
However, some product vendors only claim minimal security functionality in their ST and continue to claim an assurance package of EAL4 (Evaluation Assurance Level 4).
This approach can be deceiving to the consumer who assume or equate a higher assurance package level as being more secure.
In fact, it is the security functionality present in a product that provides the security AND the assurance package provides an indication of the confidence that has been gained through evaluation that the security functionality works as intended.
4.) As a result, the product can obtain the “assurance package” EAL4 stamp but only test against a subset of “security functional” requirements. (click)
Assurance Package
Assurance
Package
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity

16. ST vs. PP Example Protection Profile Security Target *SFR 1 *SFR 1
Functional Package
Functional Package
**SAR 01
SAR 02
SAR 03
SAR ....
SAR 24
**SAR 01
SAR 02
TAA 03
TAA ....
TAA 10
(click)
3.) However, not all of the security functional requirements may be relevant to a product technology type also not all the assurance requirements in an assurance package, e.g. EAL 4, may be relevant to the product technology type, and therefore not apply. (click)
5.) A product technology type PP can be constructed with an agreed:
- specification of security functional requirements, i.e. “Functional Package”
- specification of security assurance requirements, i.e. “Assurance Package”
and
A product must pass ALL of the PP functional and assurance requirements (click)
6.) So, although a product technology type PP may have fewer security assurance requirements and therefore perhaps assumed to equate to a lower EAL. However, the PP is more considered in the choice of the security assurance requirements appropriate for a product technology type. Together with the added specificity of the security assurance requirements through a process of refinement or “Tailoring” there can be greater confidence that the assurance activities are adequate and appropriate for that product technology type.
“Secure” is a combination of the security functional requirements which provide the security features in a product technology type, and the assurance security requirements are appropriate for a product technology type and that their correct application provide the appropriate confidence that the security functions operate as intended.
Therefore, an agreed product technology type PP claim is less open to security functional or assurance requirements misinterpretation, than an ST for a product that may have only minimal security functional requirements and an inappropriate EAL claim.
Assurance Package
Assurance
Package
*SFR – Security Functional Requirement
**SAR – Security Assurance Requirement
***TAA – Tailored Assurance Activity

17. Technical Community Key to PP Development and Maintenance
Any participating CCRA nation, vendor, critical infrastructure industry, academia, evaluator, or lab
Collaborative environment to create requirements and testing standards for PPs
TCs consist of any vendor, country, critical infrastructure, evaluator, or lab that wishes to participate.
TCs are a collaborative environment where all involved help in creating the requirements and standards set forth by a PP.
NIAP will continue to be the forefront of the PP, helping to guide and write the PPs, but it will ultimately be the TC that will set the requirements, thus allowing an equal opportunity for all to meet these requirements.

18. Published Protection Profiles
Full Disk Encryption
USB Flash Drive
Hardcopy Device (MFP)
Stateful Firewall
Network Devices 1.1
ESM Policy Management
ESM Access Control
ESM Identity & Credential Mgt.
Mobility Endpoint OS
Mobility Endpoint VoIP App
SIP Server
Wireless LAN Access System
Wireless LAN Client
VPN Client
Peripheral Sharing Switch
Located at

19. Protection Profiles Under Development
NDPP V2
VPN Gateway Extended Package
BIOS
MFP v2
USB v2
Hardware Security Module
Virtualization
Storage Area Network
File Encryption
Mobile Device Management

20. Contact Information
NIAP website:
Contact info:
Mark Loepker –
Paul Mansfield –
Telephone:

21. Questions?

22. NIAP Evolution Progress
IA Products Must be CC Evaluated & Validated – U.S. National Policy (NSTISSP-11)
Not the case in most other CC-nations
No longer accepting traditional (EAL4) evaluations
Evaluations must go against NIAP Approved PP
Created Technical Communities
Network, Firewall, ESM
Published 12 Standard PP (December 2012)
Continuing Outreach to Gov’t & International Partners, Industry, Labs, Academia