The Evaluation Assurance Levels (EALs) provide an increasing scale that balances the level of assurance obtained with the cost and feasibility of acquiring that degree of assurance. The CC approach identifies the separate concepts of assurance in a TOE at the end of the evaluation, and of maintenance of that assurance during the operational use of the TOE.
It is important to note that not all families and components from Part 3 are included in the EALs. This is not to say that these do not provide meaningful and desirable assurances. Instead, it is expected that these families and components will be considered for augmentation of an EAL in those PPs and STs for which they provide utility.
Table 6.1 represents a summary of the EALs. The columns represent a hierarchically ordered set of EALs, while the rows represent assurance families. Each number in the resulting matrix identifies a specific assurance component where applicable.
As outlined in the next subclause, seven hierarchically ordered evaluation assurance levels are defined in the CC for the rating of a TOE's assurance. They are hierarchically ordered inasmuch as each EAL represents more assurance than all lower EALs. The increase in assurance from EAL to EAL is accomplished by substitution of a hierarchically higher assurance component from the same assurance family (i.e. increasing rigour, scope, and/or depth) and from the addition of assurance components from other assurance families (i.e. adding new requirements).
These EALs consist of an appropriate combination of assurance components as described in chapter 2 of this Part 3. More precisely, each EAL includes no more than one component of each assurance family and all assurance dependencies of every component are addressed.
While the EALs are defined in the CC, it is possible to represent other combinations of assurance. Specifically, the notion of "augmentation" allows the addition of assurance components (from assurance families not already included in the EAL) or the substitution of assurance components (with another hierarchically higher assurance component in the same assurance family) to an EAL. Of the assurance constructs defined in the CC, only EALs may be augmented. The notion of an "EAL minus a constituent assurance component" is not recognised by the standard as a valid claim. Augmentation carries with it the obligation on the part of the claimant to justify the utility and added value of the added assurance component to the EAL. An EAL may also be extended with explicitly stated assurance requirements.
The following sections provide definitions of the EALs, highlighting differences between the specific requirements and the prose characterisations of those requirements using bold type.
Assurance Class | Assurance Family | Assurance Components by Evaluation Assurance Level |
||||||
---|---|---|---|---|---|---|---|---|
EAL1 | EAL2 | EAL3 | EAL4 | EAL5 | EAL6 | EAL7 | ||
Configuration management | ACM_AUT | 1 | 1 | 2 | 2 | |||
ACM_CAP | 1 | 2 | 3 | 4 | 4 | 5 | 5 | |
ACM_SCP | 1 | 2 | 3 | 3 | 3 | |||
Delivery and operation | ADO_DEL | 1 | 1 | 2 | 2 | 2 | 3 | |
ADO_IGS | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
Development | ADV_FSP | 1 | 1 | 1 | 2 | 3 | 3 | 4 |
ADV_HLD | 1 | 2 | 2 | 3 | 4 | 5 | ||
ADV_IMP | 1 | 2 | 3 | 3 | ||||
ADV_INT | 1 | 2 | 3 | |||||
ADV_LLD | 1 | 1 | 2 | 2 | ||||
ADV_RCR | 1 | 1 | 1 | 1 | 2 | 2 | 3 | |
ADV_SPM | 1 | 3 | 3 | 3 | ||||
Guidance documents | AGD_ADM | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
AGD_USR | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
Life cycle support | ALC_DVS | 1 | 1 | 1 | 2 | 2 | ||
ALC_FLR | ||||||||
ALC_LCD | 1 | 2 | 2 | 3 | ||||
ALC_TAT | 1 | 2 | 3 | 3 | ||||
Tests | ATE_COV | 1 | 2 | 2 | 2 | 3 | 3 | |
ATE_DPT | 1 | 1 | 2 | 2 | 3 | |||
ATE_FUN | 1 | 1 | 1 | 1 | 2 | 2 | ||
ATE_IND | 1 | 2 | 2 | 2 | 2 | 2 | 3 | |
Vulnerability assessment | AVA_CCA | 1 | 2 | 2 | ||||
AVA_MSU | 1 | 2 | 2 | 3 | 3 | |||
AVA_SOF | 1 | 1 | 1 | 1 | 1 | 1 | ||
AVA_VLA | 1 | 1 | 2 | 3 | 4 | 4 |
Objectives
EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information.
EAL1 provides an evaluation of the TOE as made available to the customer, including independent testing against a specification, and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimal outlay.
An evaluation at this level should provide evidence that the TOE functions in a manner consistent with its documentation, and that it provides useful protection against identified threats.
Assurance components
EAL1 (see Table 6.2) provides a basic level of assurance by an analysis of the security functions using a functional and interface specification and guidance documentation, to understand the security behaviour.
The analysis is supported by independent testing of the TOE security functions.
This EAL provides a meaningful increase in assurance over an unevaluated IT product or system.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_CAP.1 Version numbers |
Class ADO: Delivery and operation |
ADO_IGS.1 Installation, generation, and start-up procedures |
Class ADV: Development |
ADV_FSP.1 Informal functional specification |
ADV_RCR.1 Informal correspondence demonstration | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ATE: Tests |
ATE_IND.1 Independent testing - conformance |
Objectives
EAL2 requires the co-operation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practice. As such it should not require a substantially increased investment of cost or time.
EAL2 is therefore applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited.
Assurance components
EAL2 (see Table 6.3) provides assurance by an analysis of the security functions, using a functional and interface specification, guidance documentation and the high-level design of the TOE, to understand the security behaviour.
The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, selective independent confirmation of the developer test results, strength of function analysis, and evidence of a developer search for obvious vulnerabilities (e.g. those in the public domain).
EAL2 also provides assurance through a configuration list for the TOE, and evidence of secure delivery procedures.
This EAL represents a meaningful increase in assurance from EAL1 by requiring developer testing, a vulnerability analysis, and independent testing based upon more detailed TOE specifications.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_CAP.2 Configuration items |
Class ADO: Delivery and operation |
ADO_DEL.1 Delivery procedures |
ADO_IGS.1 Installation, generation, and start-up procedures | |
Class ADV: Development |
ADV_FSP.1 Informal functional specification |
ADV_HLD.1 Descriptive high-level design | |
ADV_RCR.1 Informal correspondence demonstration | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ATE: Tests |
ATE_COV.1 Evidence of coverage |
ATE_FUN.1 Functional testing | |
ATE_IND.2 Independent testing - sample | |
Class AVA: Vulnerability assessment |
AVA_SOF.1 Strength of TOE security function evaluation |
AVA_VLA.1 Developer vulnerability analysis |
Objectives
EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound development practices.
EAL3 is applicable in those circumstances where developers or users require a moderate level of independently assured security, and require a thorough investigation of the TOE and its development without substantial re-engineering.
Assurance components
EAL3 (see Table 6.4) provides assurance by an analysis of the security functions, using a functional and interface specification, guidance documentation, and the high-level design of the TOE, to understand the security behaviour.
The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification and high-level design, selective independent confirmation of the developer test results, strength of function analysis, and evidence of a developer search for obvious vulnerabilities (e.g. those in the public domain).
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 functions and mechanisms and/or procedures that provide some confidence that the TOE will not be tampered with during development.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_CAP.3 Authorisation controls |
ACM_SCP.1 TOE CM coverage | |
Class ADO: Delivery and operation |
ADO_DEL.1 Delivery procedures |
ADO_IGS.1 Installation, generation, and start-up procedures | |
Class ADV: Development |
ADV_FSP.1 Informal functional specification |
ADV_HLD.2 Security enforcing high-level design | |
ADV_RCR.1 Informal correspondence demonstration | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ALC: Life cycle support |
ALC_DVS.1 Identification of security measures |
Class ATE: Tests |
ATE_COV.2 Analysis of coverage |
ATE_DPT.1 Testing: high-level design | |
ATE_FUN.1 Functional testing | |
ATE_IND.2 Independent testing - sample | |
Class AVA: Vulnerability assessment |
AVA_MSU.1 Examination of guidance |
AVA_SOF.1 Strength of TOE security function evaluation | |
AVA_VLA.1 Developer vulnerability analysis |
Objectives
EAL4 permits a developer to gain maximum assurance from positive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line.
EAL4 is therefore applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security-specific engineering costs.
Assurance components
EAL4 (see Table 6.5) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and a subset of the implementation, to understand the security behaviour. Assurance is additionally gained through an informal model of the TOE security policy.
The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification and high-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a low 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, a subset of the implementation, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development or delivery.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_AUT.1 Partial CM automation |
ACM_CAP.4 Generation support and acceptance procedures | |
ACM_SCP.2 Problem tracking CM coverage | |
Class ADO: Delivery and operation |
ADO_DEL.2 Detection of modification |
ADO_IGS.1 Installation, generation, and start-up procedures | |
Class ADV: Development |
ADV_FSP.2 Fully defined external interfaces |
ADV_HLD.2 Security enforcing high-level design | |
ADV_IMP.1 Subset of the implementation of the TSF | |
ADV_LLD.1 Descriptive low-level design | |
ADV_RCR.1 Informal correspondence demonstration | |
ADV_SPM.1 Informal TOE security policy model | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ALC: Life cycle support |
ALC_DVS.1 Identification of security measures |
ALC_LCD.1 Developer defined life-cycle model | |
ALC_TAT.1 Well-defined development tools | |
Class ATE: Tests |
ATE_COV.2 Analysis of coverage |
ATE_DPT.1 Testing: high-level design | |
ATE_FUN.1 Functional testing | |
ATE_IND.2 Independent testing - sample | |
Class AVA: Vulnerability assessment |
AVA_MSU.2 Validation of analysis |
AVA_SOF.1 Strength of TOE security function evaluation | |
AVA_VLA.2 Independent vulnerability analysis |
Objectives
EAL5 permits a developer to gain maximum assurance from security engineering based upon rigorous commercial development practices supported by moderate application of specialist security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to the EAL5 requirements, relative to rigorous development without the application of specialised techniques, will not be large.
EAL5 is therefore applicable in those circumstances where developers or users require a high level of independently assured security in a planned development and require a rigorous development approach without incurring unreasonable costs attributable to specialist security engineering techniques.
Assurance components
EAL5 (see Table 6.6) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and all of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy and a semiformal presentation of the functional specification and high-level design and a semiformal demonstration of correspondence between them. A modular TOE design is also required.
The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, high-level design and low-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a moderate attack potential. The analysis also includes validation of the developer's covert channel analysis.
EAL5 also provides assurance through the use of a 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 semiformal design descriptions, the entire implementation, a more structured (and hence analysable) architecture, covert channel analysis, and improved mechanisms and/or procedures that provide confidence that the TOE will not be tampered with during development.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_AUT.1 Partial CM automation |
ACM_CAP.4 Generation support and acceptance procedures | |
ACM_SCP.3 Development tools CM coverage | |
Class ADO: Delivery and operation |
ADO_DEL.2 Detection of modification |
ADO_IGS.1 Installation, generation, and start-up procedures | |
Class ADV: Development |
ADV_FSP.3 Semiformal functional specification |
ADV_HLD.3 Semiformal high-level design | |
ADV_IMP.2 Implementation of the TSF | |
ADV_INT.1 Modularity | |
ADV_LLD.1 Descriptive low-level design | |
ADV_RCR.2 Semiformal correspondence demonstration | |
ADV_SPM.3 Formal TOE security policy model | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ALC: Life cycle support |
ALC_DVS.1 Identification of security measures |
ALC_LCD.2 Standardised life-cycle model | |
ALC_TAT.2 Compliance with implementation standards | |
Class ATE: Tests |
ATE_COV.2 Analysis of coverage |
ATE_DPT.2 Testing: low-level design | |
ATE_FUN.1 Functional testing | |
ATE_IND.2 Independent testing - sample | |
Class AVA: Vulnerability assessment |
AVA_CCA.1 Covert channel analysis |
AVA_MSU.2 Validation of analysis | |
AVA_SOF.1 Strength of TOE security function evaluation | |
AVA_VLA.3 Moderately resistant |
Objectives
EAL6 permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium TOE for protecting high value assets against significant risks.
EAL6 is therefore applicable to the development of security TOEs for application in high risk situations where the value of the protected assets justifies the additional costs.
Assurance components
EAL6 (see Table 6.7) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the of the TOE, and a structured presentation of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy, a semiformal presentation of the functional specification, high-level design, and low-level design and a semiformal demonstration of correspondence between them. A modular and layered TOE design is also required.
The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification, high-level design and low-level design, selective independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. The analysis also includes validation of the developer's systematic covert channel analysis.
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, systematic covert channel identification, and improved configuration management and development environment controls.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_AUT.2 Complete CM automation |
ACM_CAP.5 Advanced support | |
ACM_SCP.3 Development tools CM coverage | |
Class ADO: Delivery and operation |
ADO_DEL.2 Detection of modification |
ADO_IGS.1 Installation, generation, and start-up procedures | |
Class ADV: Development |
ADV_FSP.3 Semiformal functional specification |
ADV_HLD.4 Semiformal high-level explanation | |
ADV_IMP.3 Structured implementation of the TSF | |
ADV_INT.2 Reduction of complexity | |
ADV_LLD.2 Semiformal low-level design | |
ADV_RCR.2 Semiformal correspondence demonstration | |
ADV_SPM.3 Formal TOE security policy model | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ALC: Life cycle support |
ALC_DVS.2 Sufficiency of security measures |
ALC_LCD.2 Standardised life-cycle model | |
ALC_TAT.3 Compliance with implementation standards - all parts | |
Class ATE: Tests |
ATE_COV.3 Rigorous analysis of coverage |
ATE_DPT.2 Testing: low-level design | |
ATE_FUN.2 Ordered functional testing | |
ATE_IND.2 Independent testing - sample | |
Class AVA: Vulnerability assessment |
AVA_CCA.2 Systematic covert channel analysis |
AVA_MSU.3 Analysis and testing for insecure states | |
AVA_SOF.1 Strength of TOE security function evaluation | |
AVA_VLA.4 Highly resistant |
Objectives
EAL7 is applicable to the development of security TOEs for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis.
Assurance components
EAL7 (see Table 6.8) provides assurance by an analysis of the security functions, using a functional and complete interface specification, guidance documentation, the high-level and low-level design of the TOE, and a structured presentation of the implementation, to understand the security behaviour. Assurance is additionally gained through a formal model of the TOE security policy, a formal presentation of the functional specification and high-level design, a semiformal presentation of the low-level design, and formal and semiformal demonstration of correspondence between them, as appropriate. A modular, layered and simple TOE design is also required.
The analysis is supported by independent testing of the TOE security functions, evidence of developer testing based on the functional specification high-level design, low-level design and implementation representation, complete independent confirmation of the developer test results, strength of function analysis, evidence of a developer search for vulnerabilities, and an independent vulnerability analysis demonstrating resistance to penetration attackers with a high attack potential. The analysis also includes validation of the developer's systematic covert channel analysis.
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.
Assurance class | Assurance components |
Class ACM: Configuration management |
ACM_AUT.2 Complete CM automation |
ACM_CAP.5 Advanced support | |
ACM_SCP.3 Development tools CM coverage | |
Class ADO: Delivery and operation |
ADO_DEL.3 Prevention of modification |
ADO_IGS.1 Installation, generation, and start-up procedures | |
Class ADV: Development |
ADV_FSP.4 Formal functional specification |
ADV_HLD.5 Formal high-level design | |
ADV_IMP.3 Structured implementation of the TSF | |
ADV_INT.3 Minimisation of complexity | |
ADV_LLD.2 Semiformal low-level design | |
ADV_RCR.3 Formal correspondence demonstration | |
ADV_SPM.3 Formal TOE security policy model | |
Class AGD: Guidance documents |
AGD_ADM.1 Administrator guidance |
AGD_USR.1 User guidance | |
Class ALC: Life cycle support |
ALC_DVS.2 Sufficiency of security measures |
ALC_LCD.3 Measurable life-cycle model | |
ALC_TAT.3 Compliance with implementation standards - all parts | |
Class ATE: Tests |
ATE_COV.3 Rigorous analysis of coverage |
ATE_DPT.3 Testing: implementation representation | |
ATE_FUN.2 Ordered functional testing | |
ATE_IND.3 Independent testing - complete | |
Class AVA: Vulnerability assessment |
AVA_CCA.2 Systematic covert channel analysis |
AVA_MSU.3 Analysis and testing for insecure states | |
AVA_SOF.1 Strength of TOE security function evaluation | |
AVA_VLA.4 Highly resistant |