Common Criteria Evaluation and Validation Scheme Syed Naqvi XtreemOS Training Day

Formal Security Evaluations Independent (third party) attestation of a developer’s security claims against a defined security evaluation criteria. Evaluations result in independent measure of assurance, therefore build confidence in security. Secures development process and yields better product. Comprehensive security solutions cannot be evaluated by simple examination!

Evolution of Evaluations Criteria TCSEC 1985 UK CLs 1989 German Criteria French Criteria ITSEC 1991 Federal Criteria Draft 1993 Canadian Criteria 1993 v v v Dutch Criteria ISO/IEC 15408

Common Criteria Purpose From the User perspective: –A way to define Information Technology (IT) security requirements for some IT products: Hardware Software Combinations of above From the Developer/Vendor perspective: –A way to describe security capabilities of their specific product From the Evaluator/Scheme perspective: –A tool to measure the belief we may attain about the security characteristics of a product.

Common Criteria Terminologies PP : Protection Profile contains a set of Functional and Assurance requirements for a product or system written to be implementation independent ST : Security Target contains the requirements that the specific product or system under evaluation conforms to, written to be implementation dependent TOE : Target of Evaluation product or system that is to be evaluated against the criteria detailed in the Security Target EAL : Evaluation Assurance Level contains specific and building assurance requirements in each level. CC defines EAL 1 through 7, with EAL7 being the highest. SOF : Strength of Function a qualification of a TOE Security Function expressing the minimal efforts assumed to defeat its security mechanisms.

Common Criteria Model Helmut Kurth, How Useful are Product Security Certifications for Users of the Product, June 2005

Evaluation Assurance Levels 1.Functionally tested 2.Structurally tested 3.Methodically tested and checked 4.Methodically designed, tested, and reviewed 5.Semi-formally designed and tested 6.Semi-formally verified design and tested 7.Formally verified design and tested

CC Evaluation Example

Target of Evaluation (TOE)

Evaluated Configuration

Security Environment

Security Objectives

Security Requirements Security Functional Requirements Class FAU: Security Audit Class FPR: Privacy Class FCO: Communication Class FPT: Protection of the TSF Class FCS: Cryptographic SupportClass FRU: Resource Utilization Class FDP: User Data ProtectionClass FTA: TOE Access Class FMT: Security ManagementClass FTP: Trusted Path/Channels Class FIA: Identification & Authentication Security Assurance Requirements Class ACM: Configuration & Management Class AVA: Vulnerability Assessment Class ADO: Delivery & Operation Class ADV: Development Class ALC: Life Cycle Support Class ATE: Tests Class AGD: Guidance Documents

Functional Requirements

> <

Functional Requirements

Assurance Requirements

Security Rationale

Security Objectives Rationale

Security Requirements Rationale

Dependencies

Thank you Syed Naqvi CoreGRID Research Fellow E-Science Systems Research Department CCLRC Rutherford Appleton Laboratory, UK