Common Criteria

1. Common Criteria Ravi Sandhu Edited by Duminda Wijesekera

2. Common Criteria: 1998-present • TSEC retired in 2000, CC became de-facto standard • International unification • CC v2.1 is ISO 15408 • Flexibility • Separation of • Functional requirements • Assurance requirements • Marginally successful so far • v1 1996, v2 1998, widespread use ???

3. Common Criteria

4. Class, Family, Component, Package

5. Security Functional Requirements • Identification and authentication • Cryptographic support, • Security management, • Protecting ToE access and security functions • Communication, • Privacy, • Trusted paths, • Channels, • User data protection, • Resource utilization • Audit • Forensic analysis

6. Security Assurance Requirements • Life cycle support, • Pre requirements: Guidance documents • Requirements analysis for consistency and completeness • Vulnerability analysis • Secure design • Development • Testing • Functional, security specifications • vulnerability • Delivery and operations • Maintenance • Assurance maintenance • Configuration management

7. CC Methodology • ToE Security Policy (TSP): set of rules regulating asset management, protection and distributed in system • ToE Security Function (TSF): HW+SW and firmware used for the correct enforcement of TSP • Protection profile (PP): set of (security) requirments • Security target (ST): set of (security) requirements to be used as a evaluation

8. CC Introductory: Section 1 of 8 • ST identification: precisely stated information required to identify ST • ST overview: narrative acceptable as a a standalone description of the ST • CC Conformance: • Claim: a statement of conformance to the CC. • Part 2 conformance: if using only functional requirements

9. CC Product/system description: Section 2 of 8 • Describes the ToE, • Boundaries • Logical • physical • Scope of evaluation

10. CC Product/system family environment: Section 3 of 8 • Assumptions of intended usage • Threat and their agents • Organizational security policy that must be adhered to in providing protection

11. CC Security objective: Section 4 of 8 • Objectives for the product/system: Traceable to identified threats and/or organizational policy • Objectives for the environment: must be traceable to threats • not completely encountered by the system and policies • or assumptions not completely met by the system

12. CC IT Security requirements: Section 5 of 8 • Functional security requirements: from CC • Security assurance requirements: must be augmented by the author as addendums to the EAL

13. CC Product/summary specification: Section 6 of 8 • A statement of security function and how these are met as functional requirements • A statement of assurance requirements and how these are met as

14. CC PP Claims: Section 7 of 8 • Claims of conformance

15. CC Rationale: Section 8 of 8 • Explains various aspects of CC • Security objective rationale • Security requirements rationale • Summary specification rationale • Rationale for not meeting all dependencies • PP claims rationale: explains the differences between objectives, requirements and conformance claims

16. Seven Levels of Evaluation • EAL1: functionally tested • EAL2: structurally tested • EAL3: methodically tested and checked • EAL4: methodically designed, tested and reviewed • EAL5: semi-formally designed and tested • EAL6: semi-formally designed, verified and tested • EAL7: formaly verified, designed and tested

17. The evaluation process • Controlled by C Evaluation Methodology (CEM) and NIST • Many labs are accredited by NIST and charge a fee for evaluation • Vendor selects a lab to evaluate the PP • The vendor and the lab negotiates the process and a schedule and the lab issues a rating

18. Evaluation and testing • Security must be designed in • Security can be retrofitted • Impractical except for simplest systems Evaluation levels • Black box • Gray box • White box

19. EAL, TSEC and ITSEC

20. Future of Testing • Continues to evolve • Quality of Protection (QoP): some research efforts to measure security qualitatively.

21. The SSE-CMM Model 1997-present • System Security Capability Maturity Model • A process oriented model for developing secure systems • Capability models define requirements for processes • CC and its predecessors define requirements for security

22. SSE-CMM Definitions • Process capability: the range of expected results by following the process • Process performance: a measure of the actual results received • Process maturity: the extent to which a process is explicitly defined, managed, measured, controlled and effective

23. Process areas of SSE-CMM • Administrator controls • Assess impact • Asses threat • Asses vulnerability • Build assurance arguments • Coordinate security • Monitor system security posture • Provide security input • Specify security needs • Verify and validate security

24. Example: assessing threats • Identify natural threats • Identify human threats • Identify threat units and measures • Access threat agent capability • Asses threat likelihood • Monitor threats and their characteristics

25. Five capability maturity levels • Represents process maturity • Performed informally: base processes are performed • Planned and tracked: has project-level definition, planning and performance verification • Well-defined: focused on defining, refining a standard practice and coordinating across organization • Continuously improving: organizational capability and process effectiveness improved.