Common Criteria and other Security evaluations.

Copyright (c) 2009 Saffire Systems. All Rights Reserved. 1

Saffire SystemsP.O. Box 3054

Champaign, IL 61826217 359-7763

March 12, 2009

Security Certifications


Security Certifications

• Certifications Required to Sell to the Government– Common Criteria– FIPS– Various unique testing for each organization

• Certification & Accreditation– Used by the government to certify systems for

deployment in a specific environment


FIPS 140-2

• July, 1995 National Institute of Standards and Technology (NIST) established the Cryptographic Module Validation Program (CMVP) to validate cryptographic modules to Federal Information Processing Standard (FIPS) 140-1

• CMVP is a joint effort between NIST and the Communications Security Establishment (CSE) of the Government of Canada.

• Any product using cryptography must meet FIPS 140-2 before Federal clients are allowed to buy it.

• NIST and CSE validate products evaluated by a National Voluntary Laboratory Accreditation Program (NVLAP) accredited laboratory.– http://csrc.nist.gov/cryptval


FIPS 140-2

• 4 security levels for cryptographic modules• defined for different degrees of data sensitivity and different

environments of use• Software only modules can only get a Level 1

• Defines a framework & methodology for cryptographic standards.– Specifies security features for 11 requirements areas

• FIPS is officially reexamined and reaffirmed every 5 years.

• http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf


History of Product Evaluations

• TCSEC (US DoD, 1983-1985)

• MSFR (US NIST,1990)

• ITSec (Europe, 1991)

• Federal Criteria (US, 1992)

• TCPEC (Canada, 1993)

• Common Criteria (International,1993-1998)

• ISO 15408 Common Criteria (1999)


Common Criteria Overview

• Protection Profile (PP)

• Security Target (ST)

• Security Functional Requirements (SFRs)

• Security Assurance Requirements (SARs)

• Evaluation Assurance Levels (EAL)– EAL 1 (Functional Testing) to EAL 7 (Formally

verified design and testing)


Common Criteria

• www.commoncriteriaportal.org• Currently 26 Common Criteria Recognition

Agreement (CCRA) members • 12 Authorizing Schemes

– Common Criteria Evaluation and Validation Scheme (CCEVS); US validation body

– Australia & New Zealand (Authorizing)– Austria– Canada (Authorizing)– Czech Republic– Denmark– Finland– France (Authorizing)– Germany (Authorizing)– Greece– Hungary– India– Israel

– Italy– Japan (Authorizing)– Republic of Korea

(Authorizing)– Malaysia– Netherlands (Authorizing)– Norway (Authorizing)– Pakistan– Singapore– Spain (Authorizing)– Sweden (Authorizing)– Turkey– United Kingdom

(Authorizing)

http://www.commoncriteriaportal.org/


Common Criteria

• Common Criteria (CC)– Basis for evaluation of security properties of IT products– Non-IT security measures or procedures excluded– Assessment of cryptographic algorithms excluded

• Common Methodology for Information Technology Security Evaluation (CEM)– Evaluation methodology to which the criteria is applied– Primarily for evaluators reviewing vendor assurance measures

and for validators confirming evaluator activities/ findings.– Evaluation Technical Report (ETR)

• Documents results of performing the work units defined in the CEM

• Certified / Validated Products List (CPL / VPL)


Common Criteria

• CC V2.X / CEM v2.X– CC v2.3 (ISO/IEC 15408:2005 & ISO/IEC

18045:2005)– Used until March 2008– Maintenance until September 2009

• CC V3.X / CEM v3.X– CC V3.1 Release 1 September 2006– CC V3.1 Release 2 September 2007

• CC Parts 2 & 3 and the CEM


CCEVS

• www.niap-ccevs.org/cc-scheme• National Information Assurance Partnership

(NIAP)– Operated by National Security Agency (NSA)– Provides IT security evaluation and validation

services for government and industry– NIST and NSA provide resources to NIAP/CCEVS

• NIST National Voluntary Laboratory Accreditation Program (NVLAP)– Accrediting body for the Common Criteria Test

Laboratories (CCTLs)

http://www.niap-ccevs.org/cc-scheme


CCEVS-specific Requirements

• Scheme Policy Letters– Guidance documents– Requirements for products being validated

• Scheme Publications– Requirements for CCTL approval

• Precedents– Generic version of a Observation Decision (OD)

written to address an issue as requested by the CCTL and documented in an Observation Report (OR)

– Decision posted to resolve the discussion of problems/issues not related to any evaluation as posted on the CC-CMT mailing list



• Interpretations– NIAP Interpretations Board (NIB)

• Meets periodically• Public review process for proposed Interpretations

– Presented to CCRA Members for inclusion in official CC version

• Common Criteria Interpretations Management Board (CCIMB)



• Prior to October, 2006– Accepted most EAL 2 + evaluations

• Since October, 2006 only accepted higher assurance evaluations.– Caused a flurry of new evaluation requests prior to Oct. 2006– Caused some vendors to go to other schemes, many to Canada

• As of October, 2008,– Only accepting US Government PP or EAL4 compliant

evaluations– Must have a Letter of Intent from a National security customer



• Policy 10 (PL 10)– Defines requirements of the ST to enter In Evaluation

list– Maximum of 2 PL 10 CCEVS reviews

• Policy 13– Defines Acceptable TOEs for Evaluation

• TOE boundary– Entire product as sold– All security functionality provided with a few unwritten

exceptions• PP compliance claimed• Form must be completed before CCEVS will post the

certificate/VPL to the web site.



• Evaluation Acceptance Package– Set of docs required to enter evaluation under

CCEVS• Security Target• Evaluation work package with timelines• Points of Contact• IVOR materials

– Presentation– ASE ETR (results of the ST evaluation)– User and administrator guides



• Validation Oversight Review (VOR)– Process for CCEVS to review the work performed by

the CCTLs– 3 VOR checkpoints per evaluation

• Interactive review of the TOE and the evaluation effort performed by the CCTL between the evaluation team and CCEVS validations (usually 2-3 validators)

• Evaluation Team must be prepared to defend the TOE and evaluation effort by being prepared to discuss technical issues.


VORs

• Evaluation minutes prepared

• Possible results– Pass (rare)– Conditional Pass– Failure

• At most 1 follow-up VOR.

• If follow-up VOR fails, the evaluation is terminated and must be resubmitted


VORs

• IVOR– Ensure compliance to CCEVS Policies 10 & 13– Held prior to acceptance into the CCEVS scheme and posted in

the “In-Evaluation” List• TVOR

– Held prior to evaluation team testing– Guidance, design, testing, and vulnerability assessments must

have passed– Submit assurance measures (evidence) and ETRs– Submit evaluation team test plan

• FVOR– After completion of evaluation, final ETR, and final ST– CCTL submits a draft VR (validation report)– After pass, posted on the Validated Products List


VORs

• Approximately 10-20 VORs per month• Number of requested VORs generally exceeds

validator resources• Prioritization

– FVOR• Medium or High Robustness PP claim• Basic Robustness PP claim• EAL 4

– TVOR– IVOR– Exceptions based on government customer needs


Major CC v2.3 to v3.1 Diffs

• Part 2 : Security Functional Requirements (SFRs)– Draft v3.1 included major changes

• Trial uses proved ineffective and the approach was abandoned– Reverted to v2.X SFRs– Only one major technical change

• Moved FPT_SEP (Domain Separation) and FPT_RVM (Non-bypassability) from Part 2 into Part 3 ADV_ARC (Security Architecture) assurance requirement

• Part 3– Major Changes– Diffs organized by v2.3 assurance classes

• ASE/APE (ST & PP)– Re-written to eliminate repeated, unnecessary work – Focus on purpose of TOE Summary Specification to explain how the

TOE meets the SFRs– No longer an strength of function (SOF) claim


CC v3.1: ADV (Design)

• Requirements increase from EAL1 – EAL4• V3.1 defined the notion of SFR-enforcing, SFR-

supporting and SFR-non-interfering• Architecture (domain separation, non-bypassability, self-

protection)• Functional Specification

– Define external interfaces, level of detail required increases• Design Document

– Describe subsystems and interactions between subsystems (EAL 2 & 3)

– Describe modules, define SFR-enforcing module interfaces, and describe module interactions (EAL4)

• Implementation Representation (subset review)


CC v3.1: AGD (Guidance)

• Same requirements for EAL1 – EAL4• Operational Guidance

– Describe functions and privileges for each role– Describe secure usage of TOE, including warnings– Identify modes of operation– Actions required by the administrator might include actions

associated with the installation and start-up of the TOE.

• Preparative Guidance– Describe steps necessary for secure acceptance of the TOE– Describe steps necessary for secure installation of the TOE

• In v3.1, requirements consolidated in AGD with little to no change


CC v3.1: ALC (Life Cycle)• Requirements increase from EAL1 – EAL4• Identify Configuration Items (EAL 1 – EAL4)• Labeling the TOE (EAL1 – EAL4)• Use a Configuration Management (CM) system (EAL2 –

EAL4)• Define Delivery Procedures (EAL2 – EAL4)• Production support (EAL3 – EAL4)

– Automation at EAL4

• Acceptance Procedures (EAL4)• Define development security measures (EAL3 – EAL4)• Define Life-Cycle Module (EAL3 – EAL4)• Use of well-defined development tools (EAL3)• CM should be in place over the life of the product


CC v3.1: ATE (Testing)

• Requirements increase from EAL1 – EAL4• Independent Testing (by Lab; EAL1 – EAL4)• Functional Testing (by developer; EAL2 – EAL4)• Coverage (EAL2 – EAL4)

– Test a subset of the security functions (EAL2)– Test all external security interfaces (EAL3-4)

Developer performs testing• Depth of Testing (EAL3 – EAL4)

– Test at subsystem level (EAL3)– Test at subsystem and SFR-enforcing module level

(EAL4)


CC v3.1 AVA: (Vulnerability Analysis)

• Requirements increase from EAL1 – EAL4 – In v2.3, analysis performed by vendor / developer– In v3.1, analysis performed by evaluation team

• Penetration testing performed by evaluation team (EAL1 – EAL4)

• Analysis for information available in the public domain (EAL 1 – EAL4)

• Analysis using documentation required for evaluation ( EAL2 – EAL4)

• Analysis using the implementation representation (EAL4)


Evaluation Assurance Levels (EAL)

• EAL 1– Not Really Used in Practice– Design– Guidance– Life Cycle / CM– Evaluation team Testing and Vulnerability Analysis (VLA)

• EAL 2– Good starting point for vendors with little documentation and no

well-defined security engineering practices– Design: Security Architecture, Security-enforcing FSP, Basic

Design– Guidance– Life Cycle: CM, Delivery Procedures– Vendor Functional Testing & Coverage – limited testing required– Evaluation team Testing and VLA


Evaluation Assurance Levels (EAL)• EAL 3

– Design: Security Architecture, FSP with complete summary, Architectural Design– Guidance– Life Cycle: CM, Delivery Procedures, Development Security Measures, Life

Cycle Model– Vendor Functional Testing & Coverage, Basic Design testing – complete testing

required– Evaluation team Testing and VLA

• EAL 4– Design: Security Architecture, Complete Functional Specification, Basic Modular

Design, Implementation Representation– Guidance– Life Cycle: CM, Delivery Procedures, Development Security Measures, Life

Cycle Model, Development Tools• Automation

– Vendor Testing• basically same as EAL 3, except increased design test coverage

– Evaluation team Testing and VLA


Protection Profiles

• Customer desired security feature definition• Many PPs are still CC v2.x; PPs are being migrated to CC

v3.1• Firewall

– Updated in 2007 validated against CC V3.1– Basic and Medium Robustness– In practice most commercial firewalls do not meet the PP– Auditing requirements are extensive

• IDS PPs– Updated in 2007 validated against CC V3.1– Basic and Medium Robustness– In practice most commercial firewalls do not meet the PP


Protection Profiles

• OS– Only CC v2.X PPs– Controlled Access PP (CAPP)

• EAL3 PP from 1999• Most conformant validated products

– High Robustness Separation Kernels• 2007 PP• One validated product

– Other PPs have no validated products– Archived PPs with Validated OS Products

• Labeled Security PP (1999)• Role Based Access Control PP (1998)


Realities

• Evidence Development– Provided by most labs and multiple consultants– Reality of Vendor Readiness– Need for Assistance in preparing evidence– Length of Evaluations

• Evaluation Work– Proficiency Exams to become a CC Test Laboratory

• Conflict of Interest• Flaw Remediation (FLR)• Covert Channel Analysis (CCA)


Realities

• Evaluations compliant above EAL 4– Require NSA resources– CCA

• Certification ≠ Perfection

• Factor in Product Procurement Selection

• Possible RFC requirement


Exercise

• Assume a Software Firewall at EAL2– ADV

• Define the subsystems• Define the external interfaces• Describe security architecture

– AVA• Describe the approach to analysis• Describe the approach to penetration testing

• Would it differ for a Firewall Appliance at EAL2


Exercise

• Assume a Firewall Appliance at EAL4– ADV

• Define the subsystems• Define the modules• Define the external interfaces• Assume a Firewall Appliance at EAL4

– AVA• Describe the approach to analysis• Describe the approach to penetration testing

Common Criteria and other Security evaluations.

Documents

Transcript of Common Criteria and other Security evaluations.