1. 1 Common Evaluation Methodology for IT Security Part 2: Evaluation Methodology chapter 5-8 Marie Elisabeth Gaup Moe 06/12/04

2. 2 Outline Introduction Security Assurance Requirements Security Assurance Classes Evaluation Assurance Levels EAL 1 - EAL 4 Evaluation Methodology

3. 3 Introduction CEM Part 2, chapters 5 through 8 describes the minimum evaluation effort needed when evaluating according to the Evaluation Assurance Levels EAL1-EAL4 It also provides guidance on ways and means of accomplishing the evaluation in terms of: –Objectivity –Repeatability –Reproducibility

4. 4 Security Assurance Requirements Assurance is grounds for confidence that the claimed security objectives are achieved Assurance is provided based upon an evaluation of the IT product or system that is to be trusted The CC proposes measuring the validity of the documentation and of the resulting IT product or system by expert evaluators with increasing emphasis on scope, depth, and rigour Greater assurance results from the application of greater evaluation effort, the goal is to apply the minimum effort required to provide the necessary level of assurance

5. 5

6. 6 Security Assurance Classes Configuration Management (ACM) Delivery and Operation (ADO) Development (ADV) Guidance Documents (AGD) Life Cycle Support (ALC) Tests (ATE) Vulnerability Assessment (AVA) Assurance Maintenance (AMA) Evaluation Criteria (APE, ASE)

7. 7 Configuration Management (ACM) Configuration management helps to ensure that the integrity of the TOE is preserved, by requiring discipline and control in the processes of refinement and modification of the TOE and other related information It also prevents unauthorised modifications, additions, or deletions to the TOE, thus providing assurance that the TOE and documentation used for evaluation are the ones prepared for distribution

8. 8 Configuration Management Families Configuration Management Automation (ACM_AUT) –Establishes the level of automation used to control the configuration items Configuration Management Capabilities (ACM_CAP) –Define the characteristics of the configuration management system Configuration Management Scope (ACM_SCP) –Indicates the TOE items that need to be controlled by the configuration management system

9. 9 Delivery and Operation (ADO) Assurance class ADO defines requirements for the measures, procedures, and standards concerned with secure delivery, installation, and operational use of the TOE, to ensure that the security protection offered by the TOE is not to be compromised during transfer, installation, start-up and operation

10. 10 Delivery and Operation Families Delivery (ADO_DEL) –Covers the procedures used to maintain security during transfer of the TOE to the user, both on initial delivery and as part of subsequent modification Installation, generation and start-up (ADO_IGS) –Requires that the copy of the TOE is configured and activated by the administrator to exhibit the same protection properties as the master copy

11. 11 Development (ADV) Assurance class ADV defines requirements for the stepwise refinement of the TSF from the TOE summary specification in the ST down to the actual implementation Each of the resulting TSF representations provide information to help the evaluator determine whether the functional requirements of the TOE have been met

12. 12 Development Families Functional specification (ADV_FSP) – Describes the TSF and details the external interface to the TOE High-level design (ADV_HLD) –Identifies the basic structure of the TSF and the major hardware, firmware, and software elements Implementation representation (ADV_IMP) –The least abstract representation of the TSF, captures the detailed internal workings of the TSF in terms of source code, hardware drawings, etc TSF internals (ADV_INT) –Specify the requisite internal structuring of the TSF

13. 13 Development Families Low-level design (ADV_LLD) –Detailed design specification that refines the high-level design into a level of detail that can be used as a basis for programming and/or hardware construction Representation correspondence (ADV_RCR) –Demonstration of mappings between all adjacent pairs of available TSF representations Security policy modeling (ADV_SPM) –Used to provide increased assurance that the functional specification corresponds to the security policies of the TSP, and ultimately to the TOE security functional requirements

14. 14 Guidance Documents (AGD) Assurance class AGD defines requirements directed at the understandability, coverage and completeness of the operational documentation provided by the developer Administrator guidance (AGD_ADM) –Requirements for administrative guidance help ensure that the environmental constraints can be understood by administrators and operators of the TOE User guidance (AGD_USR) –Requirements for user guidance help ensure that users are able to operate the TOE in a secure manner

15. 15 Life Cycle Support (ALC) Assurance class ALC defines requirements for assurance through the adoption of a well defined life-cycle model for all the steps of the TOE development, including flaw remediation procedures and policies, correct use of tools and techniques and the security measures used to protect the development environment

16. 16 Life Cycle Support Families Development security (ALC_DVS) –Covers the physical, procedural, personnel, and other security measures used in the development environment Flaw remediation (ALC_FLR) –Ensures that flaws discovered by the TOE consumers will be tracked and corrected while the TOE is supported by the developer Life cycle definition (ALC_LCD) –Establishes that the engineering practices used by a developer to produce the TOE include the considerations and activities identified in the development process and operational support requirements Tools and techniques (ALC_TAT) –Addresses the need to define the development tools being used to analyse and implement the TOE

17. 17 Tests (ATE) Assurance class ATE states testing requirements that demonstrate that the TSF satisfies the TOE security functional requirements Coverage (ATE_COV) –Addresses the extent to which the TOE security functions are tested Depth (ATE_DPT) –Deals with the level of detail to which the developer tests the TOE Functional tests (ATE_FUN) –Provides assurance that the TSF satisfies at least the requirements of the chosen functional components Independent testing (ATE_IND) –Specifies the degree to which the functional testing of the TOE must be performed by a party other than the developer

18. 18 Vulnerability Assessment (AVA) Assurance class AVA defines requirements directed at the identification of exploitable vulnerabilities which could be introduced in the construction, operation, misuse, or incorrect configuration of the TOE Covert channel analysis (AVA_CCA) –Discovery and analysis of unintended communications channels that can be exploited to violate the intended TSP Misuse (AVA_MSU) –Investigates whether an administrator or user, with an understanding of the guidance documentation, would reasonably be able to determine if the TOE is configured and operating in a manner that is insecure Strength of TOE security functions (AVA_SOF) –Addresses TOE security functions that are realised by a probabilistic or permutational mechanism Vulnerability analysis (AVA_VLA) –Identification of flaws potentially introduced in the different refinement steps of the development

19. 19 Evaluation Assurance Levels (EALs) Assurance levels define a scale for measuring the criteria for the evaluation The EALs are constructed from assurance components taken from the different assurance families The increase in assurance across the levels is done by substituting hierarchically higher assurance components from the same family, and by the addition of assurance components from other families

20. 20

21. 21

22. 22 Evaluation Methodology EAL 1-4 The CEM document gives methodologies for evaluating at EAL 1-EAL 4 These lower four levels provides a basic assurance and can generally be retrofitted to pre-existing products and systems The evaluation activities are derived from the assurance requirements for the corresponding EAL as stated in part 3 of the CC EAL 1: Functionally tested, basic level of assurance EAL 2: Structurally tested, low to moderate level of assurance EAL 3: methodically tested and checked, moderate level of assurance EAL 4: methodically designed, tested and rewieved, moderate to high level of assurance

23. 23 EAL 1 Evaluation Activities Evaluation of the ST Evaluation of the configuration management Evaluation of the delivery and operation documents Evaluation of the development documents Evaluation of the guidance documents Testing

24. 24 EAL 1 Evaluation Subactivities Evaluation of CM capabilities (ACM_CAP.1) –Determine whether the developer has clearly identified the TOE Evaluation of installation, generation and start-up (ADO_IGS.1) –Determine whether the procedures and steps for the secure installation, generation and start-up of the TOE have been documented and result in a secure configuration Evaluation of functional specification (ADV_FSP.1) –Determine whether the developer has provided an adequate description of the security functions of the TOE and whether the security functions provided by the TOE are sufficient to satisfy the security functional requirements of the ST

25. 25 EAL 1 Evaluation Subactivities Evaluation of representation correspondence (ADV_RCR.1) –Correspondence analysis between the TOE summary specification and the functional specification Evaluation of administrator guidance (AGD_ADM.1) –Determine if the administrator guidance describes how to administer the TOE in a secure manner Evaluation of user guidance (AGD_USR.1) –determine whether the user guidance describes the security functions and interfaces provided by the TSF and whether this guidance provides instructions and guidelines for the secure use of the TOE Evaluation of independent testing (ATE_IND.1) –Determine whether the TSF behaves as specified by independently testing a subset of the TSF

26. 26 EAL 2 Evaluation Activities Evaluation of the ST Evaluation of the configuration management Evaluation of the delivery and operation documents Evaluation of the development documents Evaluation of the guidance documents Evaluation of the tests Testing Evaluation of the vulnerability assessment

27. 27 EAL 2 Evaluation Subactivities Evaluation of CM capabilities (ACM_CAP.2) –Determine if the developer has clearly identified the TOE and its associated configuration items Evaluation of delivery (ADO_DEL.1) –Determine whether the delivery documentation describes all procedures used to maintain integrity when distributing the TOE to the user´s site Evaluation of installation, generation and start-up (ADO_IGS.1) Evaluation of functional specification (ADV_FSP.1) Evaluation of high-level design (ADV_HLD.1) –Determine whether the high-level design provides a description of the TSF in terms of major structural units, and is a correct realisation of the functional specification Evaluation of representation correspondence (ADV_RCR.1)

28. 28 EAL 2 Evaluation Subactivities Evaluation of administrator guidance (AGD_ADM.1) Evaluation of user guidance (AGD_USR.1) Evaluation of coverage (ATE_COV.1) –Determine whether the developer´s test coverage evidence shows correspondence between the tests identified in the test documentation and the functional specification Evaluation of functional tests (ATE_FUN.1) –Determine whether the developer´s functional test documentation is sufficient to demonstrate that security functions perform as specified Evaluation of independent testing (ATE_IND.2) –Determine, by independently testing a subset of the TSF, whether the TOE behaves as specified, and to gain confidence in the developer´s test results by performing a sample of the developer´s tests

29. 29 EAL 2 Evaluation Subactivities Evaluation of strength of TOE security functions (AVA_SOF.1) –Determine whether SOF claims are made in the ST for all probabilistic or permutational mechanisms and whether the developer´s SOF claims are supported by an analysis that is correct Evaluation of vulnerability analysis (AVA_VLA.1) –Determine whether the TOE, in its intended environment, has exploitable obvious vulnerabilities

30. 30 EAL 3 Evaluation Activities Evaluation of the ST Evaluation of the configuration management Evaluation of the delivery and operation documents Evaluation of the development documents Evaluation of the guidance documents Evaluation of life cycle support Evaluation of the tests Testing Evaluation of the vulnerability assessment

31. 31 EAL 3 Evaluation Subactivities Evaluation of CM capabilities (ACM_CAP.3) –Determine whether the developer has clearly identified the TOE and its associated configuration items, and whether the ability to modify these items is properly controlled Evaluation of CM scope (ACM_SCP.1) –Determine whether as a minimum the developer performs configuration management on the TOE implementation representation, design, tests, user and administrator guidance, and the CM documentation Evaluation of delivery (ADO_DEL.1) Evaluation of installation, generation and start-up (ADO_IGS.1) Evaluation of functional specification (ADV_FSP.1) Evaluation of high-level design (ADV_HLD.2) –Determine whether the high-level design provides a description of the TSF in terms of major structural units, provides a description of the interfaces to these structural units, and is a correct implementation of the functional specification

32. 32 EAL 3 Evaluation Subactivities Evaluation of representation correspondence (ADV_RCR.1) Evaluation of administrator guidance (AGD_ADM.1) Evaluation of user guidance (AGD_USR.1) Evaluation of development security (ALC_DVS.1) –Determine whether the developer´s security controls on the development environment are adequate to provide confidentiality of the TOE design and implementation Evaluation of coverage (ATE_COV.2) –Determine whether the testing is sufficient to establish that the TSF has been systematically tested against the functional specification Evaluation of functional tests (ATE_FUN.1)

33. 33 EAL 3 Evaluation Subactivities Evaluation of independent testing (ATE_IND.2) Evaluation of depth (ATE_DPT.1) –Determine whether the developer has tested the TSF against its high-level design Evaluation of strength of TOE security functions (AVA_SOF.1) Evaluation of vulnerability analysis (AVA_VLA.1) Evaluation of misuse (AVA_MSU.1) –Determine whether the guidance is misleading, unreasonable or conflicting, whether secure procedures for all modes of operation have been addressed, and whether use of guidance will facilitate prevention and detection of insecure TOE items

34. 34 EAL 4 Evaluation Activities Evaluation of the ST Evaluation of the configuration management Evaluation of the delivery and operation documents Evaluation of the development documents Evaluation of the guidance documents Evaluation of life cycle support Evaluation of the tests Testing Evaluation of the vulnerability assessment

35. 35 EAL 4 Evaluation Subactivities Evaluation of CM capabilities (ACM_CAP.4) –Determine whether the developer has clearly identified the TOE and its associated configuration items, and whether the ability to modify these items is properly controlled Evaluation of CM scope (ACM_SCP.2) –Determine whether as a minimum the developer performs configuration management on the TOE implementation representation, design, tests, user and administrator guidance, the CM documentation and security flaws Evaluation of CM automation (ACM_AUT.1) –Determine whether changes to the implemntation representation are controlled with the support of automated tools, thus making the CM system less susceptible to human error or negligence Evaluation of delivery (ADO_DEL.2) –Determine whether the delivery documentation describes all procedures used to maintain integrity and the detection of modification or substitution of the TOE when distributing the TOE to the user´s site

36. 36 EAL 4 Evaluation Subactivities Evaluation of installation, generation and start-up (ADO_IGS.1) Evaluation of functional specification (ADV_FSP.2) –Determine whether the developer has provided an adequate description of the security functions of the TOE and whether the security functions provided by the TOE are sufficient to satisfy the security functional requirements of the ST Evaluation of high-level design (ADV_HLD.2) Evaluation of representation correspondence (ADV_RCR.1) Evaluation of implementation representation (ADV_IMP.1) –Determine whether the implementation representation is sufficient to satisfy the functional requirements of the ST and is a correct realisation of the low-level design Evaluation of low-level design (ADV_LLD.1) –Determine whether the low-level design is sufficient to satisfy the functional requirements of the ST, and is a correct and effective refinement of the high-level design

37. 37 EAL 4 Evaluation Subactivities Evaluation of security policy modeling (ADV_SPM.1) –Determine whether the security policy model clearly and consistently describes the rules and characteristics of the security policies and whether this description corresponds with the description of security functions in the functional specification Evaluation of administrator guidance (AGD_ADM.1) Evaluation of user guidance (AGD_USR.1) Evaluation of development security (ALC_DVS.1) Evaluation of life-cycle definition (ALC_LCD.1) –Determine whether the developer has used a documented model of the TOE life-cycle Evaluation of tools and techniques (ALC_TAT.1) –Determine whether the developer has used well-defined development tools that yield consistent and predictable results Evaluation of coverage (ATE_COV.2) Evaluation of functional tests (ATE_FUN.1)

38. 38 EAL 4 Evaluation Subactivities Evaluation of independent testing (ATE_IND.2) Evaluation of depth (ATE_DPT.1) Evaluation of strength of TOE security functions (AVA_SOF.1) Evaluation of vulnerability analysis (AVA_VLA.2) –Determine whether the TOE, in its intended environment, has vulnerabilities exploitable by attackers possessing low attack potential Evaluation of misuse (AVA_MSU.2) –Determine whether the guidance is misleading, unreasonable or conflicting, whether secure procedures for all modes of operation have been addressed, and whether use of the guidance will facilitate prevention and detection of insecure TOE states