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

1. Common CriteriaEvaluation 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 Canadian Criteria 1985 1993 UK CLs 1989 German Criteria Federal Criteria Draft 1993 ITSEC French Criteria 1991 v1.0 1996 v2.0 1998v3.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 • Functionally tested • Structurally tested • Methodically tested and checked • Methodically designed, tested, and reviewed • Semi-formally designed and tested • Semi-formally verified design and tested • Formally verified design and tested

11. CC Evaluation Example

12. Target of Evaluation (TOE)

13. Evaluated Configuration

14. Evaluated Configuration

15. Security Environment

16. Security Objectives

17. 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 Support Class FRU: Resource Utilization Class FDP: User Data Protection Class FTA: TOE Access Class FMT: Security Management Class FTP: Trusted Path/ChannelsClass 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. Functional Requirements > --------------------------------------------------------------------------------------------------------- < > --------------------------------------------------------------------------------------------------------- <

21. Functional Requirements

22. Assurance Requirements

23. Assurance Requirements

24. Assurance Requirements

25. Security Rationale

26. Security Objectives Rationale

27. Security Objectives Rationale

28. Security Requirements Rationale

29. Security Requirements Rationale

30. Dependencies

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