1. Common Criteria Evaluation and Validation Scheme Syed Naqvi S.Naqvi@rl.ac.uk XtreemOS Training Day

2. 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!

3. Evolution of Evaluations Criteria TCSEC 1985 UK CLs 1989 German Criteria French Criteria ITSEC 1991 Federal Criteria Draft 1993 Canadian Criteria 1993 v1.0 1996 v2.0 1998 v3.0 2005 Dutch Criteria ISO/IEC 15408

4. 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.

5. 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.

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

8. 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

11. CC Evaluation Example

12. Target of Evaluation (TOE)

13. Evaluated Configuration

15. Security Environment

16. Security Objectives

18. 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

19. Functional Requirements

20. > --------------------------------------------------------------------------------------------------------- <

21. Functional Requirements

22. Assurance Requirements

25. Security Rationale

26. Security Objectives Rationale

28. Security Requirements Rationale

30. Dependencies

31. Thank you Syed Naqvi CoreGRID Research Fellow E-Science Systems Research Department CCLRC Rutherford Appleton Laboratory, UK S.Naqvi@rl.ac.uk