common criteria evaluation and validation scheme syed naqvi [email protected] xtreemos training day
TRANSCRIPT
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
TCSEC1985
UK CLs1989
German Criteria
French Criteria
ITSEC1991
Federal CriteriaDraft 1993
Canadian Criteria
1993
v1.0 1996 v2.0 1998v3.0 2005
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
Evaluated Configuration
Security Environment
Security Objectives
Security Objectives
Security Requirements
• Security Functional RequirementsClass 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 RequirementsClass ACM: Configuration & Management Class AVA: Vulnerability Assessment Class ADO: Delivery & OperationClass ADV: DevelopmentClass ALC: Life Cycle SupportClass ATE: TestsClass AGD: Guidance Documents
Functional Requirements
Functional Requirements
> --------------------------------------------------------------------------------------------------------- <
> --------------------------------------------------------------------------------------------------------- <
Functional Requirements
Assurance Requirements
Assurance Requirements
Assurance Requirements
Security Rationale
Security Objectives Rationale
Security Objectives Rationale
Security Requirements Rationale
Security Requirements Rationale
Dependencies
Thank youSyed Naqvi
CoreGRID Research Fellow
E-Science Systems Research DepartmentCCLRC Rutherford Appleton Laboratory, UK