Common Criteria Richard Newman

1. Common CriteriaRichard Newman

2. What is the Common Criteria Specify development approaches for products Specify particular forms or formats for product specification Specify evaluation methodology Guarantee fitness for use of an evaluated product Cooperative effort among Canada, France, Germany, the Netherlands, UK, USA (NSA, NIST) Defines sets of security criteria that may be used to define needs claims Does NOT

3. TOE Evaluation Process Evaluation Criteria Develop TOE Security Requirements (PP and ST) Evaluation Scheme Evaluation Methodology Evaluate TOE TOE and Evaluation Evidence Operate TOE Evaluation Results

4. Common Criteria Terms Class: grouping of families with a common focus Component: smallest selectable set of elements for inclusion in PP, ST, or package Element: an indivisible security requirement Evaluation: assessment of PP, ST, or TOE against defined criteria Evaluation Assurance Level (EAL): a package of assurance components from Part 3 representing a point on the CC predefined assurance scale Evaluation Scheme: an administrative and regulatory framework under which the CC is applied Family: a grouping of components that share security objectives but differ in emphasis or rigor Package: a reusable set of either functional or assurance components (e.g., an EAL) that together satisfy a defined set of security objectives

5. Common Criteria Terms Protection Profile (PP): an implementation-independent set of security requirements for a category of TOEs that meets specific customer needs Security Function (SF): a part or parts of the TOE relied upon to enforce a subset of rules of the TSP Security Function Policy (SFP): the security policy enforced by a SF Security Objective: a statement of intent to counter identified threats and/or to satisfy identified organizational security policies or assumptions Security Target (ST): a set of security requirements and specifications to be used to evaluate an identified TOE Strength of Function (SOF): a qualification of a TOE SF expressing the minimum effort assumed to be required to defeat its underlying mechanisms

6. Common Criteria Terms Target of Evaluation (TOE): an IT product of system and its administrative and user guides that is subject to evaluation TOE Security Functions (TSF): the hardware, firmware, and software that enforce the TSP of a TOE TOE Security Policy (TSP): a set of rules that regulate how assets are managed, protected, and distributed in a TOE

7. TOE Evaluation Process Evaluation Criteria Develop TOE Security Requirements (PP and ST) Evaluation Scheme Evaluation Methodology Evaluate TOE TOE and Evaluation Evidence Operate TOE Evaluation Results

8. TOE Representation Requirements At each level of refinement in the TOE specification and development process, representations must be detailed and complete enough to ensure: • Sufficiency – that the refinement is a complete instantiation of the higher levels (i.e., all TSFs, properties, behaviors defined at a higher level must be demonstrably present at the lower level); • Necessity – that the refinement is an accurate instantiation of higher levels (i.e., there are no TSFs, properties, or behaviors at the lower level that are not present at a higher level).

9. TOE Security Environment TSE includes all relevant laws, regulations, organizational security policies, customs, knowledge, expertise, and threats present or assumed = CONTEXT The PP or ST writer must take into account: a) physical environment (protections, personnel); b) assets requiring protection (direct and indirect); c) TOE purpose (product type and intended use). Security statements about the TOE made after threat, risk, and policy investigation: a) assumptions about the environment for the TOE to be considered secure; b) threats to asset security – threat agent, presumed attack method, vulnerabilities exploited, assets attacked; c) applicable organizational policies and rules

10. TOE Security Objectives Statement of goals regarding threats to counter or policies to meet based on the purpose of the TOE and its assumed environment Addresses all security concerns and declares which are to be handled by the TOE and which by its environment, based on engineering judgment, security policy, economic factors, and risk acceptance decisions Security objectives for environment met by non-technical and procedural means Security objectives for TOE and its IT environment refined into IT security requirements

11. TOE IT Security Requirements Refinement of TOE security objectives for TOE and its IT environment, which, if met, would ensure that the TOE meet its security objectives Decomposed into Functional and Assuranced Requirements Functional Requirements (Part 2) include I&A, audit, non-repudiation, etc.; levied on all TSFs: If TOE SFs are realized by probabilistic/permutational mechansisms, then SOF may be specified Assurance Requirements (Part 3) levied on 1) actions of developer, 2) evidence produced, and 3) actions of evaluator; assurance derived from: a) correctness of implementation of SFs b) efficacy of SFs

12. TOE Summary Specification Part of Security Target (ST) Defines instantiation of security requirements for TOE: High-level definition of Security Functions (SFs) claimed to meet the functional requirements; and Assurance measures taken to meet assurance requirements

13. Dependencies May exist between functional components May exist between assurance components May exist between functional and assurance components Arise when a component is not sufficient by itself and relies on the presence of another component Dependency descriptions are part of CC component definitions Must be satisfied when incorporating components into PPs and STs for completeness

14. Operations on Components Iteration: may be used more than once with varying operations Assignment: specification of a parameter to be filled in when component is used Selection: specification of items from a list given in the component Refinement: addition of extra detail when component is used

15. Packages Intermediate combination of components Permits expression of a set of functional or assurance requirements that meet an identifiable subset of security objectives Intended for reuse May be used in larger packages, PPs, STs EALs (Evaluation Assurance Levels) are predefined assurance packages in Part 3 Each EAL is a baseline set of consistent assurance requirements for evaluation

16. Protection Profiles Consistent set of functional and assurance requirements from the CC, or stated explicitly, along with an EAL (perhaps augments) Permit expression of security requirements for a set of TOEs that will comply fully with a set of security objectives Intended for reuse Contains rationale for objectives and requirements

17. Security Targets Consistent set of security requirements made by reference to a PP by reference to CC functional and assurance components, or by explicit statement Contains the TOE Summary Specification, along with security requirements and objectives, and rationales for each Basis for agreement among all parties as to what security the TOE offers

18. Protection Profile Specification PP Identification PP Overview Assumptions Threats Organizational security policies For the TOE For the environment TOE security requirements (F and A) IT environment security requirements For Security Objectives, Requirements PP Introduction TOE Description TOE Security Environment Security Objectives IT Security Requirements PP Application Notes Rationale

19. Security Target Specification (1) ST Identification ST Overview CC conformance Assumptions Threats Organizational security policies For the TOE For the environment TOE security requirements (F and A) IT environment security requirements ST Introduction TOE Description TOE Security Environment Security Objectives IT Security Reqts

20. Security Target Specification (2) TOE Security Functions Assurance measures PP reference, PP tailoring, PP additions For Security Objectives, Security Requirements, TOE Summary Specifications PP Claims TOE Summary Specification PP Claims Rationale

21. Current State of CC 8 September 2014 – 26 countries have agreed to recognize CC certificates for IT security (Cert./Validation body stds) Australia Austria Canada Czech Republic Denmark Finland France Germany Greece Hungary India Israel Italy Japan Malaysia The Netherlands New Zealand Norway Pakistan Rep. of Korea Singapore Spain Sweden Turkey UK USA

22. Certified PPs Protection Profiles: https://www.commoncriteriaportal.org/pps/ Access Control Devices and Systems – 2 Biometric Systems and Devices – 2 Boundary Protection Devices and Systems – 11 Data Protection – 7 Databases – 1 ICs, Smart Cards and Smart Card-Related Devices and Systems – 50 Key Management Systems – 4 Multi-Function Devices – 3 Network and Network-Related Devices and Systems – 13 Operating Systems – 1 Other Devices and Systems – 27 Products for Digital Signatures – 17 Trusted Computing – 2

23. Certified Products Products: https://www.commoncriteriaportal.org/products/ Access Control Devices and Systems – 87 Biometric Systems and Devices – 3 Boundary Protection Devices and Systems – 125 Data Protection – 79 Databases – 45 ICs, Smart Cards and Smart Card-Related Devices and Systems – 43 Key Management Systems – 36 Multi-Function Devices – 223 Network and Network-Related Devices and Systems – 221 Operating Systems – 106 Other Devices and Systems – 230 Products for Digital Signatures – 81 Trusted Computing – 4