Day 1.pdf

從半導體晶片到IoT產品 您必須取得通行國際的資安認驗證 Common Criteria ISO 15408 2024 Onward Security, a DEKRA Company. 1 All rights reserved  What is Common Criteria The Common Criteria for Information Technology Security Evaluation (CC), and the Compan...

從半導體晶片到IoT產品 您必須取得通行國際的資安認驗證 Common Criteria ISO 15408 2024 Onward Security, a DEKRA Company. 1 All rights reserved  What is Common Criteria The Common Criteria for Information Technology Security Evaluation (CC), and the Companion Common Methodology for Information Technology Security Evaluation (CEM) are the Technical Basis for an International Agreement, the Common Criteria Recognition Arrangement (CCRA), Which Ensures That: Products can be evaluated by competent and independent licensed laboratories so as to The CC is the determine the fulfilment of particular security properties, to a certain extent or assurance driving force for Supporting documents, are used within the Common Criteria certification process to define the widest how the criteria and evaluation methods are applied when certifying specific technologies available mutual recognition of The certification of the security properties of an evaluated product can be issued by a secure IT number of Certificate Authorizing Schemes, with this certification being based on the result products. of their evaluation These certificates are recognized by all the signatories of the CCRA 2024 Onward Security, a DEKRA Company. 2 All rights reserved  What is Common Criteria CCRA Members Authorizing Consuming Australia Austria Canada Czech Republic France Denmark Germany Ethiopia India Finland Italy Greece Japan Hungary Malaysia Indonesia Netherlands Israel New Zealand Pakistan Norway Poland Republic of Korea Qatar Singapore Slovak Republic Spain United Kingdom Sweden Turkey United States 2024 Onward Security, a DEKRA Company. 3 All rights reserved  What Really is Common Criteria A security testing framework in which: ❖ Computer system users specify their security functional and testing requirements. ❖ Vendors then implement this functionality in their products. ❖ Test laboratories evaluate the products to determine if they actually implement the functionality. Common Criteria provides assurance that the process of specification, implementation, and evaluation of a computer security product has been conducted in a rigorous, standard, and repeatable manner at a level commensurate with the target environment. ISO/IEC 15408-2 defines the required structure and content of security functional components for the purpose of security evaluation. It includes a catalogue of functional components that meets the common security functionality requirements of many IT products. 2024 Onward Security, a DEKRA Company. 4 All rights reserved  What Really is Common Criteria CC originated out of three standards: ITSEC (Information Technology Security Evaluation Criteria) CTCPEC (Canadian Trusted Computer Product Evaluation Criteria) TCSEC (Trusted Computer System Evaluation Criteria) Current Revision of Std: CC:2022 and CEM:2022 -evaluation starting no later than the 30th of June 2024. CC v3.1. Release 5 -will be accepted up to the 31st of December 2027. ISO/IEC 15408 Approximately: 2000 products evaluated (that’s a lot) ❖ Common Criteria do NOT specify how secure a product is. ❖ Higher testing levels do NOT mean more secure products. o (it means better-tested products) ❖ Common Criteria will NOT account for zero-day vulnerabilities. 5 2024 Onward Security, a DEKRA Company. o Not designed to stop heart-bleed bug All rights reserved  Related Documentation CC:2022 and CEM:2022 Part 1: Introduction and general model Part 2: Security functional requirements CC v3.1. Release 5 Part 3: Security assurance requirements Part 4: Framework for the specification of evaluation methods and activities Part 5: Pre-defined packages of security requirements CEM:2022 consists of one part The concepts and methodology of the evaluation are defined in the following documents (https://www.commoncriteriaportal.org/cc/ ) Application of the latest published version is mandatory 2024 Onward Security, a DEKRA Company. 6 All rights reserved  Related Documentation ISO/IEC 15408 Mapping description Introduction, and general model is the introduction to the ISO/IEC 15408 series. It defines the general concepts and ISO/IEC 15408-1, principles of IT security evaluation and presents a general model of evaluation; Security functional components establish a set of functional components that serve as standard templates upon which ISO/IEC 15408-2, security functional requirements (SFRs) for TOEs are based. ISO/IEC 15408-2 catalogs the set of security functional components and organizes them into families and classes; Security assurance components establishes a set of assurance components that serve as standard templates upon which security assurance requirements for TOEs are based. ISO/IEC ISO/IEC 15408-3, 15408-3 catalogs the set of security assurance components and organizes them into families and classes. ISO/IEC 15408-3 also defines evaluation criteria for PPs, STs, and TOEs; 7 2024 Onward Security, a DEKRA Company. 7 All rights reserved  Common Criteria Evaluation Assurance Level (EAL 1-7) 2024 Onward Security, a DEKRA Company. 8 All rights reserved  What Really is Common Criteria Common Criteria Key Terms Definitions Target of Evaluation (TOE): set of software, firmware and/or hardware possibly accompanied by guidance Evaluation Assurance Level (EAL): A numerical grade is assigned following the completion of a CC evaluation. The intent of the higher levels is to provide higher confidence in the system. Security Target (ST): implementation-dependent statement of security needs for a specific identified TOE ❖ Main document for certifications ❖ Security functionality is described (Requirements & Summary of behavior) Protection Profile (PP): implementation-independent statement of security needs for a TOE type ❖ Template for products of the same taxonomy ❖ The developer must fulfill the implementation of the Requirements & describe the behavior of the product 2024 Onward Security, a DEKRA Company. 9 All rights reserved  What Really is Common Criteria Common Criteria Key Terms Definitions Security Policy Definition (SPD): Defines the problem that is to be addressed by compliant products. TOE Security Functionality (TSF): Functionality of all HW & SW of a TOE that is relied upon for the correct enforcement of the SFRs. TSF Interface (TSFI): This means by which external entities supply data to, receive data from, and invoke services from the TSF. Security Functional Requirements (SFR): Express security requirements intended to counter threats. The individual security functions to be provided within a TOE. Security Assurance Requirements (SAR): Define the testing performed during a CC evaluation 2024 Onward Security, a DEKRA Company. 10 All rights reserved  What Really is Common Criteria Common Criteria General Methodology Assurance vs. Conformance ❖ Conformance Testing ❖ Assurance Testing ❖ This is changing/has changed! Architecture Review ❖ Review the elements of the product that implement the claimed security. ❖ This is changing/being deemphasized! Interface-based Testing Approach ❖ This is NOT changing! ❖ Where the testing is applied is evolving 2024 Onward Security, a DEKRA Company. 11 All rights reserved  What Really is Common Criteria Common Criteria Involved Parties Common Criteria Test Laboratories (CCTLs) Consultants Schemes Product Vendors End Users Common Criteria Users Forum (CCUF) 2024 Onward Security, a DEKRA Company. 12 All rights reserved  What Really is Common Criteria Common Criteria Test Laboratories (CCTLs) ▪ Worldwide US – 9 Australia- 2 Malaysia -4 Canada – 2 France -5 Singapore- 8 Germany – 6 Japan- 3 Spain - 8 Netherlands – 5 Republic of Korea -7 Turkey -6 ▪ Most are commercial labs ▪ Typical Services Product evaluation Design consultation Documentation services Other Activities Participate in standards update Participation in creation of PPs 2024 Onward Security, a DEKRA Company. 13 All rights reserved  What Really is Common Criteria Common Criteria Consultants No formal accreditation required Quality of service varies widely Why are they important? Perform services labs typically don’t Long-term relationships with product vendors Can control messaging to product vendors Other Activities Participate in standards update Participation in the creation of the PP 2024 Onward Security, a DEKRA Company. 14 All rights reserved  What Really is Common Criteria Common Criteria Schemes Systematic organization of an evaluation and certification functions under the authority of a Certification Body (CB) ❖ High standards of competence and impartiality are maintained. ❖ Consistency is achieved. Establish rules for accredited labs Confirm testing results/issue certificates Serve customers Government End-Users Other Industries that leverage certification Participate in standards development Participate in Protection Profile development The Netherlands Trust CB and US NAIP Common Criteria Scheme is an example of such a scheme. 2024 Onward Security, a DEKRA Company. 15 All rights reserved  What Really is Common Criteria Product Vendors Build Products that meet CC requirements Contract CCTLs to evaluate products Provide subject matter expertise in developing new PPs Provide feedback on standards End Users Create procurement requirements requiring CC. Purchase CC-evaluated products. Configure products in the evaluated configuration. Rely on CC-evaluated product to provide baseline assurance. Provide input into additional technologies to be certified. Provide input into the feature evolution of certified technologies. 2024 Onward Security, a DEKRA Company. 16 All rights reserved  What Really is Common Criteria Common Criteria Users Forum (CCUF) Acts as a community representative to standard Participation is encouraged for all parties CCTLs Product Vendors Consultants Schemes Promote CC Educate CC 2024 Onward Security, a DEKRA Company. 17 All rights reserved  What Really is Common Criteria Participant Relationships Common Criteria User Forum (CCUF) (other schemes) CC Community End Product Schemes CCTLs Users Vendors CC Consultants 2024 Onward Security, a DEKRA Company. 18 All rights reserved  Security Concepts and Relationships 2024 Onward Security, a DEKRA Company. 19 All rights reserved  Security Concepts and Relationships 2024 Onward Security, a DEKRA Company. 20 All rights reserved  Security Concepts and Relationships 2024 Onward Security, a DEKRA Company. 21 All rights reserved  What is Common Criteria Protection Profile: What is it? Identifies detailed security requirements relevant to a particular purpose, e.g., a set of related use cases. Standard security declaration template for a product type that already includes the assets, threats, scenarios, TOE targets, environmental targets, SFRs, and SARs that the manufacturer must satisfy when developing its security declaration in accordance with the PP. If the security PP requires "strict conformance", the security declaration in accordance with the security profile must include all the requirements included in the security profile and may add new ones as long as they do not conflict with those already defined. 2024 Onward Security, a DEKRA Company. 22 All rights reserved  What is Common Criteria Protection Profile: What is it? Protection Profile (PP) “A CC protection profile (PP) is an implementation-independent set of security requirements for a category of products or systems that meet specific consumer needs” Subject to review and certified ▪ Requirements ▪ Functional ▪ Assurance ▪ EAL 2024 Onward Security, a DEKRA Company. 23 All rights reserved  Common Criteria Security Requirement SFR (Security Functional requirements) SFR contains 11 classes of functional requirements Each contains one or more families Elaborate naming and numbering scheme Classes: Security Audit, Communication, Cryptographic Support, User Data Protection, Identification and Authentication, Security Management, Privacy, Protection of Security Functions, Resource Utilization, TOE Access, Trusted Path 2024 Onward Security, a DEKRA Company. 24 All rights reserved  Common Criteria Security Requirement Security Target “A security target (ST) is a set of security requirements and specifications to be used for evaluation of an identified product or system” Can be based on a PP or directly taking components from CC Describes specific security functions and mechanisms 2024 Onward Security, a DEKRA Company. 25 All rights reserved  Common Criteria Assurance Requirements Assurance is the level of confidence that the policies are enforced, and risks are mitigated within the TOE. Assurance requirements must be supported by the TOE Assurance activities are ongoing, often periodic, and typically performed during system operation 2024 Onward Security, a DEKRA Company. 26 All rights reserved  Common Criteria CC Assurance Requirements There are ten security assurance classes as follows: Classes: Protection Profile Evaluation Security Target Evaluation Configuration Management Delivery and Operation Development Guidance Documentation Life Cycle Tests Vulnerabilities Assessment Maintenance of Assurance 2024 Onward Security, a DEKRA Company. 27 All rights reserved  Common Criteria CC Assurance Paradigm Assurance is the grounds for confidence that: ❖ A TOE in it’s operational environment solves a given security problems (meets its security objectives). To ensure the assurance is met, CC divides this matter into 2 sub-domains: ❖ Claiming a set of security functional requirements (SFRs) for a TOE and establishing whether the SFRs, if met, in a defined operational environment will solve the security problems. ❖ Determining whether the TOE meets these SFRs. (TSS) Security Problems TOE SFRs 2024 Onward Security, a DEKRA Company. 28 All rights reserved  Common Criteria How Assurance is Gained in CC Impartiality Evaluators must not have any interests in the outcome. Repeatability Evaluators must be able to repeat their previous effort and arrive at the same results. Reproducibility Another evaluator must be able to repeat the documented effort and arrive at the same results. Objectivity Evaluators must be uninfluenced by emotions or personal prejudices. 2024 Onward Security, a DEKRA Company. 29 All rights reserved  Common Criteria Structure of the SAR Hierarchical structure that consists of : ❖ Classes – a group of families that share a common focus ❖ Families – a group of components that share security objectives but may differ in emphasis or rigour ❖ Components – is the smallest selectable set of elements that may be included in a PP, ST, or a package. ❖ Elements – a security requirement which, if further divided, would not yield a meaningful evaluation result. It is identified as belonging to one of the three sets of assurance elements: ❑ “D” – developer action elements that shall be performed by the developer to ensure that the TOE meet the SFRs of a PP or ST. ❑ “C” – content and presentation of evidence elements. ❑ “E” – evaluator action elements that shall be performed by the evaluator. Assurance level determines scope of classes, families and components for an evaluation 2024 Onward Security, a DEKRA Company. 30 All rights reserved  Common Criteria Structure of the SAR COMPONENT CLASS FAMILY E.g.: Class Name Component Identification ASE_OBJ.2.1D Class ClassName Name Family Name ASE_OBJ.2.2D Introduction Introduction Introduction Objectives Objectives ASE_OBJ.2.1C Family 1. Fami.ly 1 Component. Levelling Application Notes ASE_OBJ.2.2C Family. 1...... Application Notes. Dependencies. ASE_OBJ.2.3C. Component 1 ASE_OBJ.2.4C Element 1 Family n Family Familynn ASE_OBJ.2.5C ASE_OBJ.2.6C Component n Element n ASE_OBJ.2.1E Example: ASE ASE_OBJ ASE_OBJ.2 (Security Target) (Security Objectives) (Security Objectives) 2024 Onward Security, a DEKRA Company. 31 All rights reserved  Common Criteria Naming Convention Class Identifier Element number (1 letter) A = Assurance Element Identifier ASE_SDP.1.1D C – Content D – Developer E - Evaluator Class Identifier (2 Family Name (3 letters) Component letters) SPD = Security Problem number SE Security Target = Definition 2024 Onward Security, a DEKRA Company. 32 All rights reserved  Common Criteria Class Structure Class Name Class Name ❖ Each assurance class is assigned a unique name that indicated the topics covered by the assurance class. Introduction ❖ A unique short name consist of character “A” followed by 2 Family 1 ❖ letters related to the class name. E.g. ADV. Class Introduction ❖ Each assurance class has an introductory section that describes the composition of the class and contains supportive test Family n covering the intent of the class. Family Structure FAMILY Family Name Family Name Every assurance family is assigned a unique name that provides descriptive information about the topics covered by the Objectives assurance family. Component Levelling The short name consist of 7 characters, including the first three... short name of the assurance class. E.g. ADV_ARC. Application Notes. Objectives Component 1 Presents the intent of the assurance family. 2024 Onward Security, a DEKRA Company. Component n 33 All rights reserved  Common Criteria Component Structure Component Identification COMPONENT Provides descriptive information necessary to identify, categorise, Component register, and reference a component. Identification Every assurance component is assigned a unique name such as ADV_FSP.1, ADV_FSP.2 etc. Objectives Objectives Application Notes. Presents the intent of the assurance component.. Dependencies. For those assurance components that have this section, it presents the. specific intent of the component and a more detailed explanation of the Element 1 objective. E.g: ❖ ADV_FSP.1 → Basic functional specification Element n ❖ ADV_FSP.2 → Security-enforcing functional specification Application Notes Contains additional information for the assurance component to facilitate the use if the component. 2024 Onward Security, a DEKRA Company. 34 All rights reserved  Common Criteria Component Structure Assurance Elements A set of assurance elements is provided for each assurance COMPONENT component. Component An assurance element is a security requirement which is further Identification divided would not yield a meaningful evaluation result. It is the smallest security requirement recognised in the CC. Objectives Each assurance element is identified as belonging to one of the 3 sets Application Notes. of assurance elements:. Dependencies.. ❖ Develop action elements (D) Element 1 ❖ Content and presentation of evidence elements (C) ❖ Evaluator action elements (E) Element n Each element represents a requirement to be met these statements of requirements are intended to be clear, concise, and unambiguous. 2024 Onward Security, a DEKRA Company. 35 All rights reserved  Common Criteria The Assurance Classes ASE Security Target Evaluation ADV Development AGD Guidance Documents ALC Life Cycle Support ATE Tests AVA Vulnerability Assessment APE Protection Profile Evaluation ACE Protection Profile Configuration Evaluation ACO Composition 2024 Onward Security, a DEKRA Company. 36 All rights reserved  Common Criteria Differences to Functional Requirements The assurance components are confidence aspects of the TOE and must be verified by evaluator actions. Therefore, for assurance components there are corresponding evaluator activities in the CEM. Components are grouped together in packages to form Evaluation Assurance Levels (EALs). There packages can be used as such or be augmented by selecting other components. The components within a family are strictly hierarchical, representing increasing rigour of the confidence aspect. 2024 Onward Security, a DEKRA Company. 37 All rights reserved  Common Criteria Assurance family structure Assurance component structure 2024 Onward Security, a DEKRA Company. 38 All rights reserved  Common Criteria Assurance Classes ASE Security Target Evaluation ADV Development AGD Guidance Documents ALC Life Cycle Support ATE Tests AVA Vulnerability Assessment APE Protection Profile Evaluation ACE Protection Profile Configuration Evaluation ACO Composition 2024 Onward Security, a DEKRA Company. 39 All rights reserved  Common Criteria Evaluation Assurance Levels Review of functional and interface specifications EAL 1: Functionally Tested Some independent testing Analysis of security functions, incl. high-level design EAL 2: Structurally Tested Independent testing, review of developer testing EAL 3: Methodically Tested and More testing, Some dev. environment controls; Checked EAL 4: Methodically Designed, Requires more design description, improved Tested, Reviewed confidence that TOE will not be tampered 2024 Onward Security, a DEKRA Company. 40 All rights reserved  Common Criteria Evaluation Assurance Levels EAL 5: Semiformally Designed Formal model, modular design and Tested Vulnerability search, covert channel analysis EAL 6: Semiformally Verified Structured development process Design and Tested Formal presentation of functional specification EAL 7: Formally Verified Design Product or system design must be simple and Tested Independent confirmation of developer tests 2024 Onward Security, a DEKRA Company. 41 All rights reserved  Common Criteria Evaluation Assurance Level 1 (EAL1) Basic level of assurance by analysis of an ST and of the claimed functionality by using an FSP and guidance to understand the security behavior. Search for potential vulnerabilities in the public domain & independent testing. Assurance through unique identification of the product & relevant evaluation documents. Meaningful increase in assurance over unevaluated products. 2024 Onward Security, a DEKRA Company. 42 All rights reserved  Common Criteria Evaluation Assurance Level 1 (EAL1) Objectives EAL1 provides a basic level of assurance by a limited ST and an analysis of the SFRs in that ST using a functional and interface specification and guidance documentation, to understand the security behavior. The analysis is supported by a search for potential vulnerabilities in the public domain and independent testing (functional and penetration) of the TOE security functionality (TSF). EAL1 also provides assurance through unique identification of the TOE and of the relevant evaluation documents. EAL1 also provides assurance through unique identification of the TOE and of the relevant evaluation documents. 2024 Onward Security, a DEKRA Company. 43 All rights reserved  Common Criteria Evaluation Assurance Level 1 (EAL1) SARs Assurance class Assurance components ADV: Development ADV_FSP.1 Basic functional specification AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC: Life-cycle support ALC_CMC.1 Labelling of the TOE ALC_CMS.1 TOE CM coverage ASE_CCL.1 Conformance claims ASE: ST evaluation ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.1 Security objectives for the operational environment ASE_REQ.1 Stated security requirements ASE_TSS.1 TOE summary specification ATE: Tests ATE_IND.1 Independent testing – conformance AVA: Vulnerability assessment AVA_VAN.1 Vulnerability survey 2024 Onward Security, a DEKRA Company. 44 All rights reserved  Common Criteria Evaluation Assurance Level 2 (EAL2) Assurance by analysis of an ST & functionality by using an FSP, guidance, and high-level description of product architecture to understand the security behavior. Evidence of developer testing and selective confirmation of results. Vulnerability analysis based on public domain search and design review. Assurance through the use of the CM system and secure delivery procedures. Significant increase in assurance over unevaluated products. 2024 Onward Security, a DEKRA Company. 45 All rights reserved  Common Criteria Evaluation Assurance Level 2 (EAL2) Objectives EAL2 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and interface specification, guidance documentation and a basic description of the architecture of the TOE, to understand the security behavior. The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, selective independent confirmation of the developer test results, and vulnerability analysis (based on the functional specification, TOE design security architecture description, and guidance evidence provided) demonstrating resistance to penetration attackers with a basic attack potential. EAL2 also provides assurance through use of a configuration management system and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL1 by requiring developer testing, a vulnerability analysis (in addition to the search of the public domain), and independent testing based on more detailed TOE specifications. 2024 Onward Security, a DEKRA Company. 46 All rights reserved  Common Criteria Evaluation Assurance Level 2 (EAL2) SARs Assurance class Assurance components ADV: Development ADV_ARC.1 Security architecture description ADV_FSP.2 Security-enforcing functional specification ADV_TDS.1 Basic design AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC: Life-cycle support ALC_CMC.2 Use of a CM system ALC_CMS.2 Parts of the TOE CM coverage ALC_DEL.1 Delivery procedures ASE_CCL.1 Conformance claims ASE: ST evaluation ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE: Tests ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis 2024 Onward Security, a DEKRA Company. 47 All rights reserved  Common Criteria Evaluation Assurance Level 3 (EAL3) Not currently supported by NIAP. Still regularly supported in other countries. Assurance by analysis of an ST & functionality by using an FSP, guidance, and architecture description to understand the security behavior. Evidence of developer testing and selective confirmation of results. Vulnerability analysis based on public domain search and design review. Secure development facilities required 2024 Onward Security, a DEKRA Company. 48 All rights reserved  Common Criteria Evaluation Assurance Level 3 (EAL3) Objectives EAL3 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and interface specification, guidance documentation and an architectural description of the design of the TOE, to understand the security behaviour. The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification and TOE design, selective independent confirmation of the developer test results, and a vulnerability analysis (based on the functional specification, TOE design, security architecture description and guidance evidence provided) demonstrating resistance to penetration attackers with a basic attack potential. EAL3 also provides assurance through the use of development environment controls, TOE configuration management and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL2 by requiring more complete testing coverage of the security functionality and mechanisms and/or procedures that provide some confidence that the TOE will not be tampered with during development. 2024 Onward Security, a DEKRA Company. 49 All rights reserved  Common Criteria Evaluation Assurance Level 3 (EAL3) Assurance class Assurance components ADV_ARC.1 Security architecture description ADV: Development ADV_FSP.3 Functional specification with complete summary ADV_TDS.2 Architectural design AGD_OPE.1 Operational user guidance AGD: Guidance documents AGD_PRE.1 Preparative procedures ALC_CMC.3 Authorization controls ALC_CMS.3 Implementation representation CM coverage ALC: Life-cycle support ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE: ST evaluation ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample 2024 Onward Security, a DEKRA Company. AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis 50 All rights reserved  Common Criteria Evaluation Assurance Level 4 (EAL4) Not currently supported by NIAP. Still regularly supported by other countries. Assurance by analysis of an ST & functionality by using an FSP, guidance, and description of product module design, and subset of product implementation. CM System required automation. Developer must perform FULL interface and security functionality testing. Selective independent confirmation of developer testing results. Vulnerability analysis based on public domain search and design review. 2024 Onward Security, a DEKRA Company. 51 All rights reserved  Common Criteria Evaluation Assurance Level 4 (EAL4) Objectives EAL4 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, a description of the basic modular design of the TOE, and a subset of the implementation, to understand the security behavior. The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification and TOE design, selective independent confirmation of the developer test results, and vulnerability analysis (based on the functional specification, TOE design, implementation representation, security architecture description and guidance evidence provided) demonstrating resistance to penetration attackers with an Enhanced-Basic attack potential. EAL4 also provides assurance through the use of development environment controls and additional TOE configuration management including automation and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL3 by requiring more design description, the implementation representation for the entire TSF and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development. 2024 Onward Security, a DEKRA Company. 52 All rights reserved  Common Criteria Evaluation Assurance Level 4 (EAL4) Assurance class Assurance components ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification ADV: Development ADV_IMP.1 Implementation representation of the TSF ADV_TDS.3 Modular design AGD_OPE.1 Operational user guidance AGD: Guidance documents AGD_PRE.1 Preparative procedures ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMS.4 Problem tracking CM coverage ALC_DEL.1 Delivery procedures ALC: Life-cycle support ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.1 Well defined developer tools ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE: ST evaluation ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample 53 2024 Onward Security, a DEKRA Company. AVA: Vulnerability assessment AVA_VAN.3 Focused vulnerability analysis All rights reserved  Common Criteria Evaluation Assurance Level 5 (EAL5) Not mutually recognized Formal specification of product design Complete rerun of all vendor testing Attacker in vulnerability analysis assumed to be of high-attack potential 2024 Onward Security, a DEKRA Company. 54 All rights reserved  Common Criteria Evaluation Assurance Level 5 (EAL5) Objectives EAL5 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, and a description of the design of the TOE and the implementation, to understand the security behavior. A modular TSF design is also required. The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, TOE design, selective independent confirmation of the developer test results and an independent vulnerability analysis demonstrating resistance to penetration attackers with a moderate attack potential. EAL5 also provides assurance through the use of development environment controls, and comprehensive TOE configuration management including automation and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL4 by requiring semi-formal design descriptions, a more structured (and hence analyzable) architecture, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development. 2024 Onward Security, a DEKRA Company. 55 All rights reserved  Common Criteria Evaluation Assurance Level 5 (EAL5) Assurance class Assurance components ADV_ARC.1 Security architecture description ADV_FSP.5 Complete semi-formal functional specification with additional error information ADV: Development ADV_IMP.1 Implementation representation of the TSF ADV_INT.2 Well-structured internals ADV_TDS.4 Semi-formal modular design AGD_OPE.1 Operational user guidance AGD: Guidance documents AGD_PRE.1 Preparative procedures ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMS.5 Development tools CM coverage ALC: Life-cycle support ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.2 Compliance with implementation standards ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE: ST evaluation ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE_COV.2 Analysis of coverage ATE_DPT.3 Testing: modular design ATE: Tests ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample AVA: Vulnerability assessment AVA_VAN.4 Methodical vulnerability analysis 2024 Onward Security, a DEKRA Company. 56 All rights reserved  Common Criteria Evaluation Assurance Level 6 (EAL6) Objectives EAL6 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, the design of the TOE and the implementation to understand the security behavior. Assurance is additionally gained through a formal model of select TOE security policies and a semi-formal presentation of the functional specification and TOE design. A modular, layered, and simple TSF design is also required. The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, TOE design, selective independent confirmation of the developer test results, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. EAL6 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL5 by requiring more comprehensive analysis, a structured representation of the implementation, more architectural structure (e.g. layering), more comprehensive independent vulnerability analysis, and improved configuration management and development environment controls. 2024 Onward Security, a DEKRA Company. 57 All rights reserved  Common Criteria Evaluation Assurance Level 6 (EAL6) Assurance class Assurance components ADV_ARC.1 Security architecture description ADV_FSP.5 Complete semi-formal functional specification with additional error information ADV_IMP.2 Complete mapping of the implementation representation of the TSF ADV: Development ADV_INT.3 Minimally complex internals ADV_SPM.1 Formal TOE security model policy ADV_TDS.5 Complete semi-formal modular design AGD_OPE.1 Operational user guidance AGD: Guidance documents AGD_PRE.1 Preparative procedures ALC_CMC.5 Advanced support ALC_CMS.5 Development tools CM coverage ALC_DEL.1 Delivery procedures ALC: Life-cycle support ALC_DVS.2 Sufficiency of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.3 Compliance with implementation standards – all parts ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE: ST evaluation ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE_COV.3 Rigorous analysis of coverage ATE_DPT.3 Testing: modular design ATE: Tests ATE_FUN.2 Ordered functional testing ATE_IND.2 Independent testing – sample 2024 Onward Security, a DEKRA Company. AVA: Vulnerability assessment AVA_VAN.5 Advanced methodical vulnerability analysis 58 All rights reserved  Common Criteria Evaluation Assurance Level 7 (EAL7) Objectives EAL7 provides assurance by a full ST and an analysis of the SFRs in that ST, using a functional and complete interface specification, guidance documentation, the design of the TOE, and a structured presentation of the implementation to understand the security behavior. Assurance is additionally gained through a formal model of select TOE security policies and a semi-formal presentation of the functional specification and TOE design. A modular, layered, and simple TSF design is also required. The analysis is supported by independent testing of the TSF, evidence of developer testing based on the functional specification, TOE design, and implementation representation, complete independent confirmation of the developer test results, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. EAL7 also provides assurance through the use of a structured development process, development environment controls, and comprehensive TOE configuration management including complete automation, and evidence of secure delivery procedures. This EAL represents a meaningful increase in assurance from EAL6 by requiring more comprehensive analysis using formal representations and formal correspondence, and comprehensive testing. 2024 Onward Security, a DEKRA Company. 59 All rights reserved  Common Criteria Evaluation Assurance Level 7 (EAL7) Assurance class Assurance components ADV_ARC.1 Security architecture description ADV_FSP.6 Complete semi-formal functional specification with additional formal specification ADV_IMP.2 Complete mapping of the implementation representation of the TSF ADV_INT.3 Minimally complex internals ADV: Development ADV_SPM.1 Formal TOE security model policy ADV_TDS.6 Complete semi-formal modular design with formal high-level design presentation AGD_OPE.1 Operational user guidance AGD: Guidance documents AGD_PRE.1 Preparative procedures ALC_CMC.5 Advanced support ALC_CMS.5 Development tools CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.2 Sufficiency of security measures ALC: Life-cycle support ALC_LCD.2 Measurable life-cycle model ALC_TAT.3 Compliance with implementation standards – all parts ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE: ST evaluation ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification ATE_COV.3 Rigorous analysis of coverage ATE_DPT.4 Testing: implementation representation ATE: Tests ATE_FUN.2 Ordered functional testing ATE_IND.3 Independent testing - complete 60 2024 Onward Security, a DEKRA Company. AVA: Vulnerability assessment AVA_VAN.5 Advanced methodical vulnerability analysis All rights reserved