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  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, 1.Pre requirements: Guidance documents 2.Requirements analysis for consistency and completeness 3.Vulnerability analysis 4.Secure design 5.Development 6.Testing  Functional, security specifications  vulnerability 7.Delivery and operations 8.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 1.Performed informally: base processes are performed 2.Planned and tracked: has project-level definition, planning and performance verification 3.Well-defined: focused on defining, refining a standard practice and coordinating across organization 4.Continuously improving: organizational capability and process effectiveness improved.