National Information Assurance Partnership Paul Mansfield January 2013 An Evolution

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

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

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 MR @ cPP Only cPPs Will Address Vulnerability Analysis Transparent and Repeatable https://www.commoncriteriaportal.org/

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.

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

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)

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

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.

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.

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.

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.

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

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

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

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

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.

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 www.niap-ccevs.org/pp/

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

Contact Information NIAP website: http://www.niap-ccevs.org/ Contact info: Mark Loepker – msloepk@nsa.gov Paul Mansfield – pbmansf@nsa.gov Email: scheme-comments@niap-ccevs.org Telephone: 410.854.4458

Questions?

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