1

Common Evaluation Methodology for IT Security

Part 2: Evaluation Methodology chapter 5-8

Marie Elisabeth Gaup Moe06/12/04

2

Outline

• Introduction

• Security Assurance Requirements

• Security Assurance Classes

• Evaluation Assurance Levels

• EAL 1 - EAL 4 Evaluation Methodology

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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