D R A F T Common Criteria for Information Technology Security Evaluation CCEB-94/084 Part 3: Security assurance requirements P r e l i m i n a r y D R A F T Version 0.9 94/10/31 D R A F T This document is paginated from i to viii and from 1 to 202 D R A F T CCEB-94/084 Table of contents 94/10/31 Version 0.9 Page i of viii Table of contents Chapter 1 Introduction .................................................... 1 1.1 Scope ................................................................. 1 1.2 Organisation of Part 3 ................................................ 1 Chapter 2 Assurance families and components ............................... 3 2.1 Assurance categorisation ............................................. 3 2.1.1 Development ......................................................... 3 2.1.2 Tests .............................................................. 5 2.1.3 Vulnerability assessment ........................................... 6 2.1.4 Configuration management ............................................ 7 2.1.5 Life-cycle support .................................................. 7 2.1.6 Guidance documents .................................................. 8 2.1.7 Delivery and operation ............................................. 8 2.2 Predefined assurance components ...................................... 9 Class ADV Development ................................................... 11 ADV_FSP Functional specification ........................................ 11 ADV_FSP.1 TOE and security policy ........................................ 12 ADV_FSP.2 Informal security policy model ................................. 13 ADV_FSP.3 Semiformal security policy model .............................. 15 ADV_FSP.4 Formal security policy model ................................... 17 ADV_FSP.5 Property specification by model interpretation ................. 18 ADV_FSP.6 Formal specification of the security functions properties ...... 20 ADV_INT TSF internals .................................................... 23 ADV_INT.1 Modularity .................................................... 24 ADV_INT.2 Minimisation and Complexity ................................... 25 ADV_TIS TSF interface specification ...................................... 27 ADV_TIS.1 Informal TSF interface specification .......................... 27 ADV_TIS.2 Simple semiformal TSF interface specification ................. 28 ADV_TIS.3 Semiformal interface specification ............................. 29 ADV_TIS.4 Formal TSF interface specification ............................. 30 ADV_TIS.5 Formal and semiformal TSF interface specification .............. 31 ADV_TFC TSF interface specification to functional specification correspondence .................................................. 32 ADV_TFC.1 Correspondence argument ....................................... 33 ADV_TFC.2 Correspondence demonstration ................................... 33 ADV_TFC.3 Correspondence proof ........................................... 34 ADV_HLD High-level design ................................................ 37 ADV_HLD.1 Informal high-level design .................................... 37 ADV_HLD.2 Identification of security enforcing structural units ......... 39 ADV_HLD.3 Description of high-level design ............................... 40 ADV_HLD.4 Semiformal high-level design ................................... 42 D R A F T Table of contents CCEB-94/084 Page ii of viii Version 0.9 94/10/31 ADV_HLD.5 Semiformal high-level explanation .............................. 43 ADV_HLD.6 Formal high-level explanation ................................. 45 ADV_HTC High-level design to TSF interface specification correspondence .. 46 ADV_HTC.1 Correspondence argument ....................................... 47 ADV_HTC.2 Correspondence demonstration ................................... 47 ADV_HTC.3 Correspondence proof ........................................... 48 ADV_LLD Low-level design description .................................... 51 ADV_LLD.1 Informal low-level design ...................................... 51 ADV_LLD.2 Descriptive low-level design .................................. 52 ADV_LLD.3 Module-level low-level design .................................. 53 ADV_LLD.4 Semiformal low-level design description ........................ 54 ADV_LLD.5 Semiformal low-level design explanation ....................... 56 ADV_LLD.6 Formal low-level design explanation ........................... 57 ADV_LHC Low-level design to high-level design correspondence ............ 58 ADV_LHC.1 Correspondence argument ....................................... 59 ADV_LHC.2 Correspondence demonstration ................................... 60 ADV_LHC.3 Correspondence proof ........................................... 61 ADV_IMP Delivery of code/hardware drawings .............................. 63 ADV_IMP.1 Delivery of subset ............................................. 63 ADV_IMP.2 Delivery of all security relevant code ......................... 64 ADV_IMP.3 Structured delivery ........................................... 65 ADV_ILC Implementation to low-level design correspondence ................ 65 ADV_ILC.1 Informal implementation to low-level design correspondence ..... 66 ADV_ILC.2 Demonstrated implementation to low-level design correspondence ................................................... 67 Class ATE Tests ......................................................... 69 ATE_FUN Functional tests ................................................. 70 ATE_FUN.1 Minimal testing ................................................ 70 ATE_FUN.2 Conformance testing ............................................ 71 ATE_FUN.3 TSF Interface testing .......................................... 72 ATE_FUN.4 Semi-formal specifications ..................................... 74 ATE_FUN.5 Design correctness ............................................ 75 ATE_FUN.6 Formal specifications ......................................... 78 ATE_COV Coverage ........................................................ 80 ATE_COV.1 Complete coverage .............................................. 81 ATE_COV.2 Test sufficiency ............................................... 82 ATE_COV.3 Ordered testing ............................................... 82 ATE_IND Independent testing .............................................. 83 ATE_IND.1 Third Party Testing ............................................ 84 ATE_IND.2 Evaluator Confirmation ........................................ 85 ATE_IND.3 Formal Specification Testing .................................. 86 ATE_DPT Depth ........................................................... 87 ATE_DPT.1 Interface testing .............................................. 88 ATE_DPT.2 Function testing ............................................... 88 ATE_DPT.3 Module testing ................................................ 89 D R A F T CCEB-94/084 Table of contents 94/10/31 Version 0.9 Page iii of viii Class AVA Vulnerability assessment ...................................... 91 AVA_VLA Vulnerability analysis ........................................... 92 AVA_VLA.1 Obvious flaws .................................................. 92 AVA_VLA.2 Serious flaws .................................................. 93 AVA_VLA.3 Flaw removal .................................................. 94 AVA_VLA.4 Flaw hypothesis ............................................... 96 AVA_VLA.5 Penetration resistance ......................................... 98 AVA_CCA Covert channel analysis ......................................... 101 AVA_CCA.1 Storage channel analysis ....................................... 101 AVA_CCA.2 Timing channel analysis ........................................ 103 AVA_CCA.3 Formal covert channel analysis ................................. 105 AVA_MSU Misuse .......................................................... 107 AVA_MSU.1 Statement of misuse analysis .................................. 108 AVA_MSU.2 Description of misuse analysis ................................. 109 AVA_MSU.3 Explanation of misuse analysis ................................. 110 AVA_SOF Strength of TOE security functions .............................. 111 AVA_SOF.1 No claims for strength of TOE security functions .............. 111 AVA_SOF.2 Strength of TOE security functions claim ...................... 112 Class ACM Configuration management ....................................... 115 ACM_AUT Configuration management automation .............................. 115 ACM_AUT.1 Partial CM automation ......................................... 115 ACM_AUT.2 Complete CM automation ......................................... 116 ACM_SCP Configuration management scope ................................... 117 ACM_SCP.1 Minimal CM coverage ........................................... 118 ACM_SCP.2 Moderate CM coverage .......................................... 119 ACM_SCP.3 Problem tracking CM coverage .................................. 119 ACM_SCP.4 Compiler CM coverage ........................................... 120 ACM_SCP.5 Development tools CM coverage .................................. 121 ACM_CAP Configuration management capabilities ............................ 122 ACM_CAP.1 Minimal support ............................................... 123 ACM_CAP.2 Consistency and authorisation controls ........................ 124 ACM_CAP.3 Regeneration support .......................................... 125 ACM_CAP.4 Acceptance procedures .......................................... 126 ACM_CAP.5 Generation and comparison support .............................. 127 ACM_CAP.6 Advanced support ............................................... 128 ACM_CAP.7 Protection of master copies .................................... 131 Class ALC Life-cycle support ............................................. 135 ALC_LCD Life-cycle definition ........................................... 136 ALC_LCD.1 Developer defined life-cycle process .......................... 137 ALC_LCD.2 Standardised life-cycle process ................................ 138 ALC_LCD.3 Measurable life-cycle process .................................. 138 ALC_FLR Flaw remediation ................................................ 139 D R A F T Table of contents CCEB-94/084 Page iv of viii Version 0.9 94/10/31 ALC_FLR.1 Basic flaw remediation ......................................... 140 ALC_FLR.2 Flaw reporting procedures ..................................... 141 ALC_FLR.3 Systematic flaw remediation .................................... 142 ALC_FLR.4 Timely flaw remediation ........................................ 143 ALC_TAT Tools and techniques ............................................ 145 ALC_TAT.1 Well defined programming languages ............................ 145 ALC_TAT.2 Documentation of implementation options for compilers ......... 146 ALC_TAT.3 Description of implementation options and security measures ... 147 ALC_TAT.4 Runtime libraries .............................................. 148 ALC_DVS Development security ............................................. 150 ALC_DVS.1 Identification of security measures ............................ 150 ALC_DVS.2 Description of security measures .............................. 151 ALC_DVS.3 Sufficiency of security measures .............................. 151 Class AGD Guidance documents ............................................. 153 AGD_USR User guidance ................................................... 153 AGD_USR.1 End-user guidance .............................................. 154 AGD_ADM Administrator guidance ........................................... 155 AGD_ADM.1 Administration guidance ........................................ 156 Class ADO Delivery and operation ......................................... 159 ADO_DEL Delivery ........................................................ 159 ADO_DEL.1 Delivery procedures ........................................... 160 ADO_DEL.2 Detection of modification ...................................... 160 ADO_DEL.3 Prevention of modification ..................................... 162 ADO_IGS Installation, generation, and start-up ........................... 163 ADO_IGS.1 Installation, generation, and start-up procedures ............. 163 ADO_IGS.2 Generation log ................................................. 164 Chapter 3 Assurance levels .............................................. 167 3.1 Description of assurance levels AL0 to AL7 .......................... 167 3.1.1 Level AL0 - Unassured .............................................. 167 3.1.2 Level AL1 - Tested ................................................. 167 3.1.3 Level AL2 - Structurally tested ................................... 167 3.1.4 Level AL3 - Methodically tested and checked ........................ 167 3.1.5 Level AL4 - Methodically tested and reviewed ...................... 167 3.1.6 Level AL5 - Semiformal design ...................................... 168 3.1.7 Level AL6 - Semiformally verified design ........................... 168 3.1.8 Level AL7 - Formally verified design .............................. 168 3.2 Assurance levels, detailed description .............................. 168 D R A F T CCEB-94/084 Table of contents 94/10/31 Version 0.9 Page v of viii Assurance level AL0 Unassured ........................................... 169 Assurance level AL1 Tested ............................................... 171 Assurance level AL2 Structurally tested .................................. 173 Assurance level AL3 Methodically tested and checked ...................... 175 Assurance level AL4 Methodically tested and reviewed ..................... 177 Assurance level AL5 Semiformal design .................................... 183 Assurance level AL6 Semiformally verified design ......................... 185 Assurance level AL7 Formally verified design ............................. 187 Annex A Presentation of assurance ........................................ 191 A.1 Assurance levels ..................................................... 191 A.2 Assurance components ................................................. 191 A.3 Assurance elements ................................................... 192 A.4 Formality of assurance deliverables .................................. 193 A.5 Correspondence between assurance deliverables ........................ 193 Annex B Effectiveness and correctness ................................... 195 B.1 Introduction ......................................................... 195 B.1.1 Background ......................................................... 195 B.1.2 Discussion ......................................................... 195 B.1.3 Evaluation judgment ................................................ 196 B.1.4 Technical approach ................................................. 196 D R A F T Table of contents CCEB-94/084 Page vi of viii Version 0.9 94/10/31 Annex C Augmentation rules for assurance levels ......................... 197 Annex D Cross reference table of Assurance levels and Assurance level components ................................................ 199 Annex E Relationship of Common Criteria assurance levels to previous criteria ................................................ 201 D R A F T CCEB-94/084 List of figures 94/10/31 Version 0.9 Page vii of viii List of figures Figure 2.1 - Development class decomposition ........................... 11 Figure 2.2 - Tests class decomposition .................................. 69 Figure 2.3 - Vulnerability assessment class decomposition ............... 91 Figure 2.4 - Life-cycle support class decomposition .................... 135 Figure 2.5 - Guidance documents class decomposition ..................... 153 Figure 2.6 - Delivery and operation class decomposition ................ 159 D R A F T List of tables CCEB-94/084 Page viii of viii Version 0.9 94/10/31 List of tables Table 2.1 - Assurance components breakdown and mapping .................... 4 Table 3.1 - Components required for assurance level AL1 .................. 172 Table 3.2 - Components required for assurance level AL2 .................. 173 Table 3.3 - Components required for assurance level AL3 .................. 176 Table 3.4 - Components required for assurance level AL4 .................. 181 Table 3.5 - Components required for assurance level AL5 .................. 183 Table 3.6 - Components required for assurance level AL6 .................. 185 Table 3.7 - Components required for assurance level AL7 ................ 189 Table D.1 - Assurance components breakdown and mapping .................. 200 D R A F T 2 CCEB-94/084 94/10/31 Version 0.9 Page 1 of 202 Chapter 1 Introduction 1.1 Scope 1 Part 3 deals with the assurance requirements of the criteria. It presents the assurance levels that define a scale for measuring assurance, and the individual assurance components from which the assurance levels are composed. 1.2 Organisation of Part 3 2 Chapter 1 is the introductory material for Part 3. 3 Chapter 2 provides a high level overview (categorisation) of the assurance families and provides the assurance components for each of the assurance families. 4 Chapter 3 provides a high level overview (categorisation) of the assurance levels and provides the detailed definition of the assurance levels. 5 Annex A discusses the presentation of the assurance elements specified in the assurance components. 6 Annex B discusses the notions of effectiveness and correctness and how those notions are incorporated in the Common Criteria. 7 Annex C provides the rules that govern the operation "augmentation" of an assurance level. 8 Annex D provides a cross reference between the assurance levels and the assurance components. 9 Annex E shows the mappings between CC and ITSEC, FC/TCSEC, and CTCPEC. D R A F T 1 - Introduction CCEB-94/084 Page 2 of 202 Version 0.9 94/10/31 D R A F T 10 CCEB-94/084 94/10/31 Version 0.9 Page 3 of 202 Chapter 2 Assurance families and components 2.1 Assurance categorisation 10 This section presents a description of the assurance classes and the assurance families. The assurance classes, families, and the abbreviation for each family are presented in table 2.1. 2.1.1 Development 11 The assurance families included under the assurance class development deal with the stepwise refinement of the TOE from the security target specifications down to the actual implementation. 2.1.1.1 Functional specification 12 The functional specification describes the security functions provided by the TOE. The functional specification must be a complete and accurate interpretation of the requirements, and must also be shown to enforce the TOE security policy. 2.1.1.2 TSF internals 13 The TSF internals are a set of requirements that detail the internal structuring of the TSF. These requirements apply to all evidences produced for the development assurance class from the functional specification through to the actual implementation. 2.1.1.3 TSF interface specification 14 The TSF interface specification details the external interface to the TSF. Users of the TOE are expected to interact (request that a function be performed) with the TSF through this interface. 2.1.1.4 TSF interface specification to functional specification correspondence 15 The model interpretation and correspondence provides a mapping between the functional specification and the TSF interface specification. 2.1.1.5 High-level design 16 The high level design is a top level design specification that refines the TSF interface specification into the major constituent parts of the TOE. The high level design identifies the basic structure of the TOE and the major hardware, firmware and software elements. D R A F T 2 - Assurance families and components CCEB-94/084 Page 4 of 202 Version 0.9 94/10/31 17 A good design permits the evaluation effort to be concentrated on limited areas of the TOE that contribute to security, and enables the implementation of the TSF to be easily followed, as the design is refined into greater and greater detail. Table 2.1 - Assurance components breakdown and mapping Assurance Class --------------- Assurance Family Abbreviated Name Development ----------- Functional specification ADV_FSP TSF internals ADV_INT TSF interface specification ADV_TIS TSF interface specification to functional specification correspondence ADV_TFC High-level design ADV_HLD High-level design to TSF interface specification correspondence ADV_HTC Low-level design description ADV_LLD Low-level design to high-level design correspondence ADV_LHC Delivery of code/hardware drawings ADV_IMP Implementation to low-level design correspondence ADV_ILC Tests ----- Functional tests ATE_FUN Coverage ATE_COV Independent testing ATE_IND Depth ATE_DPT Vulnerability assessment ------------------------ Vulnerability analysis AVA_VLA Covert channel analysis AVA_CCA Misuse AVA_MSU Strength of TOE security functions AVA_SOF Configuration management ------------------------ Configuration management automation ACM_AUT Configuration management scope ACM_SCP Configuration management capabilities ACM_CAP Life-cycle support ------------------ Life-cycle definition ALC_LCD Flaw remediation ALC_FLR Tools and techniques ALC_TAT Development security ALC_DVS Guidance documents ------------------ User guidance AGD_USR Administrator guidance AGD_ADM Delivery and operation ---------------------- Delivery ADO_DEL Installation, generation, and start-up ADO_IGS D R A F T CCEB-94/084 2 - Assurance families and components 94/10/31 Version 0.9 Page 5 of 202 2.1.1.6 High-level design to TSF interface specification correspondence 18 The high-level design to TSF interface specification correspondence provides a mapping between the high-level design and the TSF interface specification. 2.1.1.7 Low-level design description 19 The detailed design is a low level 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. 20 It is important that as the specifications of the TSF become more detailed and less abstract, the transformation is performed in a way that correctly preserves the intent of the high level design. 2.1.1.8 Low-level design to high-level design correspondence 21 The low-level design to high-level design correspondence provides a mapping between the low-level design and the high-level design. 2.1.1.9 Delivery of code/hardware drawings 22 The implementation is the final representation of the TOE, consisting of software, firmware, and/or hardware. 2.1.1.10 Implementation to low-level design correspondence 23 The design to implementation correspondence provides a mapping between the implementation and the low-level design. 2.1.2 Tests 2.1.2.1 Functional tests 24 Functional tests are a method for establishing that the TSF interface exhibits the properties necessary to satisfy the requirements of its higher level specifications. Functional tests are valuable in providing evidence that the TSF satisfies at least the requirements of the chosen functional components. However, they do not establish that the TSF does no more than expected. Functional tests are to be carried out on a copy of the TOE that is configured and installed as recommended in the TOE's documentation. 25 Other types of tests may also be useful in determining that the implementation of the TSF corresponds to its higher level specifications. For example, module tests are valuable in providing evidence that the modules implement their specifications. 2.1.2.2 Coverage 26 Coverage deals with the sufficiency and completeness of the tests performed on the TOE. D R A F T 2 - Assurance families and components CCEB-94/084 Page 6 of 202 Version 0.9 94/10/31 2.1.2.3 Independent testing 27 Independent testing specifies the degree to which there is independent testing of the TOE. Independent testing could be performed by the TOE evaluators or could be performed by other organisations. 2.1.2.4 Depth 28 Depth is primarily concerned with the type of tests performed. Black box testing concentrates on exercising the external interfaces to the TOE without a detailed understanding of the TSF internals. White box testing takes the TSF internals into account when testing while module testing focuses on the detailed design of each module when testing. 2.1.3 Vulnerability assessment 2.1.3.1 Vulnerability analysis 29 Construction vulnerability assessment is intended to identify potential vulnerabilities being introduced in the TOE because of decisions made during its construction. 30 This analysis of the TSF consists of the identification of flaws potentially introduced in the different refinement steps of the development. It results in the definition of penetration tests through the collection of the necessary information concerning: (1) the completeness of the TSF (do the TSF counter all the postulated threats?), (2) the dependencies between the TSF, and (3) the resistance of the functions. 31 Operational vulnerability assessment is intended to identify vulnerabilities in the operation of the TOE. These known vulnerabilities are assessed through penetration testing to determine whether they could in practice be exploitable to compromise the security of the TOE. 2.1.3.2 Covert channel analysis 32 Covert channel analysis may be required whenever nondiscretionary confidentiality or integrity policies are used to control information flow. 2.1.3.3 Misuse 33 This aspect of effectiveness investigates whether the TOE can be configured or used in a manner which is insecure but which an administrator or end-user of the TOE would reasonably believe to be secure. 2.1.3.4 Strength of TOE security functions 34 Even if a TOE security function cannot be bypassed, deactivated, corrupted, or circumvented, it may still be possible to defeat it. For these functions, it is possible to make a claim for the strength of the security function. D R A F T CCEB-94/084 2 - Assurance families and components 94/10/31 Version 0.9 Page 7 of 202 2.1.4 Configuration management 35 Configuration management ensures that the TOE's TSF configuration remains consistent and complete during its life cycle, and that changes to the TSF do not adversely affect its protection properties. Configuration management ensures that the integrity of the TOE is adequately preserved. Specifically, configuration management provides confidence that the TOE's TSF and documentation used for evaluation are the ones prepared for distribution. 2.1.4.1 Configuration management automation 36 Configuration management automation establishes the level of automation used to control the configuration items. 2.1.4.2 Configuration management scope 37 Configuration management scope defines the TOE items that must be controlled by the configuration item system. 2.1.4.3 Configuration management capabilities 38 Configuration management capabilities defines the characteristics of the configuration management system. 2.1.5 Life-cycle support 2.1.5.1 Life-cycle definition 39 Life cycle definition 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 of the TOE's requirements. Confidence in the correspondence between the requirements and the TOE is greater when security analysis and the production of evidence are done on a regular basis as an integral part of the development process and operational support activities. The intent of this component is not to dictate any specific development process. 2.1.5.2 Flaw remediation 40 An integral part of life cycle definition is flaw remediation. Flaw remediation ensures that flaws discovered by the TOE consumers will be tracked and corrected while the TOE is supported by the developer. While compliance with the flaw remediation requirements cannot be determined when a TOE is evaluated, it is possible to evaluate the procedures and policies that a developer has in place to track and repair flaws and distribute the repairs to affected consumers. 2.1.5.3 Tools and techniques 41 The developer shall define the tools being used to analyse and implement the TOE. It includes requirements concerning the programming languages, the compiling D R A F T 2 - Assurance families and components CCEB-94/084 Page 8 of 202 Version 0.9 94/10/31 tools, the runtime supporting libraries used to develop the TOE, and the techniques used to develop and test the TOE. 2.1.5.4 Development security 42 Development security covers the physical, procedural, technical and personnel measures used in the development environment. It includes the physical security of the development location(s), and controls on the selection and hiring of development staff. 2.1.6 Guidance documents 2.1.6.1 User guidance 43 Requirements for user guidance help ensure that product users are able to operate the product in a secure manner (e.g., the usage constraints assumed by the PP shall be clearly explained and illustrated). The user is defined as a person who operates the TOE, but has no special privileges to affect the configuration of the TOE. 44 User's guidance is the primary means available to the developer for providing the TOE users with the necessary background and specific information on how to correctly use the TOE's protection functions. User guidance shall do two things. First, it shall explain how the functional components of a specific TOE work, so that users are able to consistently and effectively protect their information. Second, it shall explain the user's role in maintaining the TOE's security. 2.1.6.2 Administrator guidance 45 Requirements for administrative guidance help ensure that the environmental constraints are understood by administrators and operators of the TOE. The administrator is defined as a person who has the special privileges needed to affect the TOE configuration and set the user and TOE security parameters. The operator is defined as a person who has the special privileges needed to affect the routine operation of the TOE after it has been configured. 46 Administrative guidance is the primary means available to the developer for providing the TOE administrators with detailed, accurate information of how to: (1) configure and install the TOE, (2) operate the TOE in a secure manner, (3) make effective use of the TOE's privileges and protection functions to control access to administrative functions and databases, and (4) avoid pitfalls and improper use of the administrative functions that would compromise the TSF and user security. 2.1.7 Delivery and operation 2.1.7.1 Delivery 47 Delivery covers the procedures used to maintain security during transfer of the TOE or its component parts to the user, both on initial delivery and as part of subsequent modification. It includes any special procedures or operations required to demonstrate the authenticity of the delivered TOE. Such procedures and measures D R A F T CCEB-94/084 2 - Assurance families and components 94/10/31 Version 0.9 Page 9 of 202 are the basis for ensuring that the security protection offered by the TOE is not compromised during transfer. 48 This component is intended to counter the possibility that the TOE could be intentionally subverted during shipment from the development environment to the user's site. 2.1.7.2 Installation, generation, and start-up 49 Installation, generation, and start-up ensures that the copy of the TOE is configured and activated by the administrator to exhibit the same protection properties as the master copy of the TOE. The installation, generation, and start-up procedures provides confidence that the administrator will be aware of the TOE configuration parameters and how they can affect the functions of the TSF. 2.2 Predefined assurance components 50 This section provides the hierarchically-ordered assurance components for each of the assurance families. D R A F T 2 - Assurance families and components CCEB-94/084 Page 10 of 202 Version 0.9 94/10/31 D R A F T CCEB-94/084 94/10/31 Version 0.9 Page 11 of 202 Class ADV Development 51 Figure 2.1 shows the families within this class, and the hierarchy of components within the families. DEVELOPMENT | | - ADV_FSP - 1 - 2 - 3 - 4 - 5 - 6 | | - ADV_INT - 1 - 2 | | - ADV_TIS - 1 - 2 - 3 - 4 - 5 | | - ADV_TFC - 1 - 2 - 3 - 4 - 5 | | - ADV_HLD - 1 - 2 - 3 - 4 - 5 - 6 | | - ADV_HTC - 1 - 2 - 3 | | - ADV_LLD - 1 - 2 - 3 - 4 - 5 - 6 | | - ADV_LHC - 1 - 2 - 3 | | - ADV_IMP - 1 - 2 - 3 | | - ADV_ILC - 1 - 2 Figure 2.1 - Development class decomposition ADV_FSP Functional specification Editor Note: There is currently an overlap in requirements (i.e., what evidence is produced, what evaluation activities occur) between ADV_FSP and the evaluation of Security Targets defined in Part 1, Annex G. As part of the follow-on activities D R A F T ADV_FSP - Functional specification Development Page 12 of 202 CCEB-94/084 - Version 0.9 94/10/31 there will be a resolution that allocates requirements for evidence and evaluation such that no requirements appears in more than one place in the CC. Objectives 52 The functional specification describes the security functions provided by the TOE in the form of a security policy and/or a security policy model. The security policy describes how the TOE satisfies the requirements of the chosen functional component levels and how the dependencies defined for those functions are satisfied. Threats 53 Functional specification primarily deals with threats of missing requirements and of inconsistencies in the security target. It also deals with the evaluation that there are no security features in the functional specification that conflict with the underlying security policy and/or the security policy model, and with the fact that the refinement through decomposition was not successful. Editor Note: The threats for the family have yet to be expanded to incorporate all the threats derived while developing the family components. Component levelling Application notes ADV_FSP.1 TOE and security policy Objectives and threats 54 This assurance component level requires a TOE including a security policy in order to meet the stated security requirements. The functional specification specifies or references all the claimed security functions. An informal presentation style is used. Threats 55 There are missing requirements and inconsistencies in the functional specification. 56 Security features in the functional specification are in conflict with the underlying security policy. Dependencies: STT_STE D R A F T Development ADV_FSP - Functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 13 of 202 Developer action elements: ADV_FSP.1.1D The developer shall provide a functional specification as part of the security target. Content and presentation of evidence elements: ADV_FSP.1.1C The functional specification shall include or reference the informal security policy enforced by the TOE. ADV_FSP.1.2C The functional specification shall describe the security functions to be provided by the TOE. ADV_FSP.1.3C The security functions shall be specified using an informal style. Evaluator action elements: ADV_FSP.1.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of the evidence. ADV_FSP.1.2E The evaluator shall check that there are no inconsistencies in the security target. ADV_FSP.2 Informal security policy model Objectives and threats 57 An informal model of security policy is required as a theoretical basis for the security policy of the TOE. Thus the security concept for the TOE is founded on scientific results and allows that the evaluator can use informal methods to find out whether the security purposes of the TOE are correctly refined. Threats 58 There are missing requirements and inconsistencies in the functional specification which can only be identified by an intensive evaluation . 59 Security features in the functional specification are in conflict with the underlying security policy. Also non obvious conflicts should be identified by the evaluator because an informal model of security policy is used as a scientific basis for the underlying security policy. Dependencies: STT_STE Developer action elements: ADV_FSP.2.1D The developer shall provide a functional specification as part of the security target. D R A F T ADV_FSP - Functional specification Development Page 14 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_FSP.2.2D The developer shall provide an informal security policy model in terms of the functional specification. ADV_FSP.2.3D At a minimum an informal security policy model of the access control components shall be provided. ADV_FSP.2.4D The developer shall provide an informal interpretation of the underlying informal security policy model in terms of the security target and describe, how security policy is translated to the TOE. ADV_FSP.2.5D The developer shall trace the complete mapping between the security policy model and the security policy. Content and presentation of evidence elements: ADV_FSP.2.1C The functional specification shall include or reference the informal security policy enforced by the TOE. ADV_FSP.2.2C The functional specification shall describe the security functions to be provided by the TOE. ADV_FSP.2.3C The security functions shall be specified using an informal style. ADV_FSP.2.4C The security policy shall identify and describe the security functions provided by the TOE. ADV_FSP.2.5C Each informal security policy model shall include (abstract) data structures and operations defining each functional component or sub-component, and a description of the model properties. ADV_FSP.2.6C The informal interpretation of the security policy model shall state how the security functions satisfy the underlying informal security policy. ADV_FSP.2.7C The trace shall show that the security policy model is sufficient to enforce the security policy. Evaluator action elements: ADV_FSP.2.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of the evidence. ADV_FSP.2.2E The evaluator shall check that there are no inconsistencies in the security target. ADV_FSP.2.3E The evaluator shall check that there are no security features in the security target that conflict with the underlying security policy and that security policy is translated to the TOE. ADV_FSP.2.4E The evaluator shall check, that an informal security policy model in terms of the functional specification has been provided. D R A F T Development ADV_FSP - Functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 15 of 202 ADV_FSP.2.5E The evaluator shall check that each informal security policy model includes (abstract) data structures and operations defining each functional component or sub-component, and a description of the model properties. ADV_FSP.2.6E The evaluator shall check that the interpretation of the underlying informal security policy model describes how the security functions satisfies the underlying informal security policy. ADV_FSP.2.7E The evaluator shall check that the complete mapping between the security policy model and the security policy has been traced and that the security policy model is sufficient to enforce the security policy. ADV_FSP.3 Semiformal security policy model Objectives and threats 60 The security functions shall be specified using a semiformal style where appropriate and thus allowing an evaluation based on structured information. Threats 61 Security features in the functional specification are in conflict with the underlying security policy. Also non obvious conflicts should be identified by the evaluator because a semiformal model of security policy is used as a scientific basis for the underlying security policy. Dependencies: STT_STE Developer action elements: ADV_FSP.3.1D The developer shall provide a functional specification as part of the security target. ADV_FSP.3.2D The developer shall provide a semiformal security policy model in terms of the functional specification. ADV_FSP.3.3D At a minimum a semiformal security policy model of the access control components shall be provided. ADV_FSP.3.4D The developer shall provide an informal interpretation of the underlying semiformal security policy model in terms of the security target and describe , how security policy is translated to the TOE. ADV_FSP.3.5D The developer shall trace the complete mapping between the security policy model and the security policy. D R A F T ADV_FSP - Functional specification Development Page 16 of 202 CCEB-94/084 - Version 0.9 94/10/31 Content and presentation of evidence elements: ADV_FSP.3.1C The functional specification shall include or reference the informal security policy enforced by the TOE. ADV_FSP.3.2C The functional specification shall describe the security functions to be provided by the TOE. ADV_FSP.3.3C The security functions shall be specified using an informal style. ADV_FSP.3.4C The security policy shall identify and describe the security functions provided by the TOE. ADV_FSP.3.5C Each semiformal security policy model shall include (abstract) data structures and operations defining each functional component or sub-component, and a description of the model properties. ADV_FSP.3.6C The informal interpretation of the security policy model shall describe how the security functions satisfy the underlying informal security policy. ADV_FSP.3.7C The demonstration shall show that the security policy model is sufficient to enforce the security policy. Evaluator action elements: ADV_FSP.3.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of the evidence. ADV_FSP.3.2E The evaluator shall review that there are no inconsistencies in the security target. ADV_FSP.3.3E The evaluator shall review that there are no security features in the security target that conflict with the underlying security policy and that security policy is translated to the TOE. ADV_FSP.3.4E The evaluator shall review , that a semiformal security policy model in terms of the functional specification has been provided. ADV_FSP.3.5E The evaluator shall review that the interpretation of the underlying semiformal security policy model describes how the security functions satisfies the underlying informal security policy. ADV_FSP.3.6E The evaluator shall review that the complete mapping between the security policy model and the security policy has been demonstrated and that the security policy model is sufficient to enforce the security policy. D R A F T Development ADV_FSP - Functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 17 of 202 ADV_FSP.4 Formal security policy model Objectives and threats 62 A formal model of security policy is required as a theoretical basis for the security policy of the TOE and thus allowing an extremely rigorous and intensive evaluation based on scientific methods. 63 Thus the security concept for the TOE is founded on scientific results and allows that the evaluator can use formal methods to find out whether the security purposes of the TOE are correctly refined. Threats 64 Security features in the functional specification are in conflict with the underlying security policy. Also hidden conflicts should be identified by the evaluator because a formal model of security policy is used as a scientific basis for the underlying security policy and the evaluation is rigorous and intensive using scientific methods. Dependencies: STT_STE Developer action elements: ADV_FSP.4.1D The developer shall provide a functional specification as part of the security target. ADV_FSP.4.2D The developer shall provide a formal security policy model in terms of the functional specification. ADV_FSP.4.3D At a minimum a formal security policy model of the access control components shall be provided. ADV_FSP.4.4D The developer shall provide an informal interpretation of the underlying formal security policy model in terms of the security target and describe, how security policy is translated to the TOE. ADV_FSP.4.5D The developer shall demonstrate the complete mapping between the security policy model and the security policy. Content and presentation of evidence elements: ADV_FSP.4.1C The functional specification shall include or reference the informal security policy enforced by the TOE. ADV_FSP.4.2C The functional specification shall describe the security functions to be provided by the TOE. D R A F T ADV_FSP - Functional specification Development Page 18 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_FSP.4.3C The security functions shall be specified using both an informal and semiformal style. ADV_FSP.4.4C The security policy shall identify and describe the security functions provided by the TOE. ADV_FSP.4.5C Each formal security policy model shall include (abstract) data structures and operations defining each functional component or sub-component, and a description of the model properties. ADV_FSP.4.6C The informal interpretation of the security policy model shall describe how the security functions satisfy the underlying informal security policy. ADV_FSP.4.7C The demonstration shall show that the security policy model is sufficient to enforce the security policy. Evaluator action elements: ADV_FSP.4.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of the evidence. ADV_FSP.4.2E The evaluator shall review that there are no inconsistencies in the security target. ADV_FSP.4.3E The evaluator shall review that there are no security features in the security target that conflict with the underlying security policy and that security policy is translated to the TOE. ADV_FSP.4.4E The evaluator shall review, that a formal security policy model in terms of the functional specification has been provided. ADV_FSP.4.5E The evaluator shall review that the interpretation of the underlying formal security policy model describes how the security functions satisfies the underlying informal security policy. ADV_FSP.4.6E The evaluator shall review that the complete mapping between the security policy model and the security policy has been demonstrated and that the security policy model is sufficient to enforce the security policy. ADV_FSP.5 Property specification by model interpretation Objectives and threats 65 An interpretation of the models in the descriptive interface specification of the security functions including all security functions elements shall be provided to describe the security functions properties. Threats 66 Security features in the functional specification are in conflict with the underlying security policy. Also hidden conflicts should be identified by the D R A F T Development ADV_FSP - Functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 19 of 202 evaluator because a formal model of security policy is used as a scientific basis for the underlying security policy and the evaluation is extremely rigorous and intensive using scientific methods. Dependencies: STT_STE Developer action elements: ADV_FSP.5.1D The developer shall provide a functional specification as part of the security target. ADV_FSP.5.2D The developer shall provide a formal security policy model in terms of the functional specification. ADV_FSP.5.3D At a minimum a formal security policy model of the access control components shall be provided. ADV_FSP.5.4D The developer shall provide an informal security policy model of reference mediation and security functions protection. ADV_FSP.5.5D The developer shall provide an informal interpretation of the underlying formal security policy model in terms of the security target and describe , how security policy is translated to the TOE. ADV_FSP.5.6D The developer shall demonstrate the complete mapping between the security policy model and the security policy. ADV_FSP.5.7D The developer shall describe how the reference monitor concept is implemented and explain why it is tamper-resistant, cannot be bypassed, and is correctly implemented. It shall be demonstrated that the reference monitor is "small enough" to be subjected to analysis and tests. Content and presentation of evidence elements: ADV_FSP.5.1C The functional specification shall include or reference the informal security policy enforced by the TOE. ADV_FSP.5.2C The functional specification shall describe the security functions to be provided by the TOE. ADV_FSP.5.3C The security functions shall be specified using both an informal and semiformal style. ADV_FSP.5.4C The security policy shall identify and describe the security functions provided by the TOE. ADV_FSP.5.5C The properties of the formal security policy models shall be clearly stated. D R A F T ADV_FSP - Functional specification Development Page 20 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_FSP.5.6C The informal interpretation of the security policy model shall describe how the security functions satisfy the underlying informal security policy. ADV_FSP.5.7C The demonstration shall show that the security policy model is sufficient to enforce the security policy. ADV_FSP.5.8C The evidence shall provide justification ....................TBD. Evaluator action elements: ADV_FSP.5.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of the evidence. ADV_FSP.5.2E The evaluator shall review that there are no inconsistencies in the security target. ADV_FSP.5.3E The evaluator shall review that there are no security features in the security target that conflict with the underlying security policy and that security policy is translated to the TOE. ADV_FSP.5.4E The evaluator shall review , that a formal security policy model in terms of the functional specification has been provided. ADV_FSP.5.5E The evaluator shall review that the properties of the formal security policy models are clearly stated. ADV_FSP.5.6E The evaluator shall review that the interpretation of the underlying formal security policy model describe how the security functions satisfies the underlying informal security policy. ADV_FSP.5.7E The evaluator shall review that the complete mapping between the security policy model and the security policy has been demonstrated and that the security policy model is sufficient to enforce the security policy. ADV_FSP.5.8E The evaluator shall review that the reference monitor concept is implemented and review that it is tamper-resistant, cannot be bypassed, is correctly implemented and that has been demonstrated that the reference monitor is "small enough" to be subjected to analysis and tests. ADV_FSP.5.9E The evaluator shall review the justification. ADV_FSP.6 Formal specification of the security functions properties Objectives and threats 67 The formal interface description of the security functions shall be identified for each model entity and shall be consistent with the model properties. Where appropriate the security functions shall be specified using a formal style. D R A F T Development ADV_FSP - Functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 21 of 202 Threats 68 Security features in the functional specification are in conflict with the underlying security policy. Also intentionally hidden conflicts should be identified by the evaluator because a formal model of security policy is used as a scientific basis for the underlying security policy and the evaluation is extremely rigorous and intensive using scientific methods. Dependencies: STT_STE Developer action elements: ADV_FSP.6.1D The developer shall provide a functional specification. ADV_FSP.6.2D The developer shall provide a formal security policy model. ADV_FSP.6.3D For those aspects of the TSF that can be modelled, a formal security policy model shall be provided. ADV_FSP.6.4D The developer shall provide an informal security policy model of reference mediation and security functions protection. ADV_FSP.6.5D The developer shall provide an informal interpretation of the underlying formal security policy model and describe how security policy is translated to the TOE. ADV_FSP.6.6D The developer shall demonstrate the complete mapping between the security policy model and the security policy. ADV_FSP.6.7D The developer shall describe how the reference monitor concept is implemented and explain why it is tamper-resistant, cannot be bypassed, and is correctly implemented. It shall be demonstrated that the reference monitor is "small enough" to be subjected to analysis and tests. Content and presentation of evidence elements: ADV_FSP.6.1C The functional specification shall include or reference the informal security policy enforced by the TOE. ADV_FSP.6.2C The functional specification shall explain the security functions to be provided by the TOE. ADV_FSP.6.3C The security functions shall be specified using both an informal and formal style. ADV_FSP.6.4C The security policy shall identify and explain the security functions provided by the TOE. ADV_FSP.6.5C The properties of the formal security policy models shall be clearly stated. D R A F T ADV_FSP - Functional specification Development Page 22 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_FSP.6.6C The informal interpretation of the security policy model shall describe how the security functions satisfy the underlying informal security policy. ADV_FSP.6.7C The demonstration shall show that the security policy model is sufficient to enforce the security policy. ADV_FSP.6.8C The evidence shall provide justification ..TBD. Evaluator action elements: ADV_FSP.6.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of the evidence. ADV_FSP.6.2E The evaluator shall review that there are no inconsistencies in the functional specification. ADV_FSP.6.3E The evaluator shall review that the security policy is translated to the TOE. ADV_FSP.6.4E The evaluator shall review, that a formal security policy model in terms of the functional specification has been provided. ADV_FSP.6.5E The evaluator shall review that the properties of the formal security policy models are clearly stated. ADV_FSP.6.6E The evaluator shall review that the interpretation of the underlying formal security policy model describes how the TSF satisfies the underlying informal security policy. ADV_FSP.6.7E The evaluator shall review that the complete mapping between the security policy model and the security policy has been demonstrated and that the security policy model is sufficient to enforce the security policy. ADV_FSP.6.8E The evaluator shall review that the reference monitor concept is implemented and review that it is tamper-resistant, cannot be bypassed, is correctly implemented and that has been demonstrated that the reference monitor is "small enough" to be subjected to analysis and tests. ADV_FSP.6.9E The evaluator shall review the justification. D R A F T Development ADV_INT - TSF internals 94/10/31 CCEB-94/084 - Version 0.9 Page 23 of 202 ADV_INT TSF internals Objectives 69 This family of components deals with the internal structure of the TSF. Requirements are established for modularity, the layering of the software architecture to separate levels of abstraction and eliminate circular dependencies, and the elimination from the TSF of software that is not protection-relevant. 70 Modular design reduces the interdependence between elements of the TSF and thus reduces the risk that a change or error in one module will have effects throughout the TOE. Thus, a modular design provides the basis for determining the scope of interaction with other elements of the TSF and for structuring testing. 71 Design complexity is a measure of how difficult it is to understand the design of the TOE. The simpler the design, the more assurance is gained that there are no hidden vulnerabilities in the design and that the high- level protection requirements are accurately and completely instantiated in the lower level design and the implementation. 72 Design minimisation provides part of the assurance, that the code is understandable; for the less lines of code in a TSF, the greater the likelihood that the design of the TSF is comprehensible. Design minimisation is a key characteristic of a reference validation mechanism. Threats 73 TBD. Component levelling 74 The components in this family are levelled on the basis of the amount of structure and minimisation being required. Application notes 75 The term "relevant representation" is used in these components to cover the need for an evaluator to check for the appropriate issue (e.g., modularity, complexity) at whichever level of representation (e.g., high- level design, implementation) the requirements are being invoked. Similarly for the use of the expression "design documentation." Editor Note: The application of this component is still being worked through as part of the development of the CC. Please comment on the approach so far. D R A F T ADV_INT - TSF internals Development Page 24 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_INT.1 Modularity Objectives and threats Application notes Evaluator notes User notes Dependencies: 76 TBD User notes Developer action elements: ADV_INT.1.1D The developer shall design and structure the TSF in a modular fashion. ADV_INT.1.2D The developer shall design and structure the TSF such that the modules of the TSF have explicit statements of purpose, interfaces, parameters, and side effects. ADV_INT.1.3D The developer shall design and structure the TSF such that the modules of the TSF shall avoid unnecessary dependencies. Content and presentation of evidence elements: ADV_INT.1.1C The design shall identify the modules of the TSF. ADV_INT.1.2C The design shall provide a description of the purpose and the interface of each module. ADV_INT.1.3C The design shall describe how the TSF design provides for largely independent modules. Evaluator action elements: ADV_INT.1.1E The evaluators shall check the relevant representation for compliance with the design modularity requirements. D R A F T Development ADV_INT - TSF internals 94/10/31 CCEB-94/084 - Version 0.9 Page 25 of 202 ADV_INT.2 Minimisation and Complexity Objectives and threats Application notes User notes Dependencies: 77 TBD Developer action elements: ADV_INT.2.1D The developer shall design and structure the TSF in a modular fashion. ADV_INT.2.2D The developer shall design and structure the TSF such that the modules of the TSF have explicit statements of purpose, interfaces, parameters and side effects. ADV_INT.2.3D The developer shall design and structure the TSF such that the modules of the TSF shall avoid unnecessary dependencies. ADV_INT.2.4D The developer shall design and structure the TSF such that functions that are not critical to TSF security mechanisms are excluded from the TSF. ADV_INT.2.5D The developer shall make a significant effort to reduce the complexity of the TSF. Content and presentation of evidence elements: ADV_INT.2.1C The design shall identify the modules of the TSF ADV_INT.2.2C The design shall provide a description of the purpose and the interface of each module ADV_INT.2.3C The design shall describe how the TSF design provides for largely independent modules. ADV_INT.2.4C The design shall provide a description of, and justification for the functions and modules that have been included in the TSF. ADV_INT.2.5C The design shall justify the inclusion of any non-security critical modules in the TSF. This justification provide the arguments and related facts that support the decision to include non-protection functions in the TSF. ADV_INT.2.6C The design shall describe how the TSF has been structured to minimise complexity. D R A F T ADV_INT - TSF internals Development Page 26 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_INT.2.7C The design shall describe the layering of architecture (e.g., into a hierachical set of abstractions). ADV_INT.2.8C The design shall provide show that circular dependencies have been eliminated or minimised. Justification shall be provided for any circular dependencies in the layering Evaluator action elements: ADV_INT.2.1E The evaluators shall check the relevant representation for compliance with the design modularity requirements. ADV_INT.2.2E The evaluators shall check the implementation for compliance with the design modularity requirements. ADV_INT.2.3E The evaluators shall review the design for compliance with the design minimisation requirements. ADV_INT.2.4E The evaluators shall review the implementation for compliance with the design minimisation requirements. ADV_INT.2.5E The evaluators shall verify the design for compliance with the design complexity requirements. ADV_INT.2.6E The evaluators shall verify the implementation for compliance with the design complexity requirements D R A F T Development ADV_TIS - TSF interface specification 94/10/31 CCEB-94/084 - Version 0.9 Page 27 of 202 ADV_TIS TSF interface specification Objectives 78 The TSF interface specification provides a description of the functions available through the external TSF interface. This description may have various degrees of rigor, ranging from an informal natural language statement of the functions available, to natural language statements about syntax and semantics, for formal mathematical specifications of behaviour. Threats 79 TBD Application notes User notes 80 The PP/ST author should also include any specific information called out for inclusion in the TSF interface specification by any functional components included in the PP/ST. ADV_TIS.1 Informal TSF interface specification Objectives and threats Application notes Dependencies: TBD Developer action elements: ADV_TIS.1.1D The developer shall provide a specification for the external interfaces provided by the TSF. ADV_TIS.1.2D The developer shall argue that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Content and presentation of evidence elements: ADV_TIS.1.1C For all of the external TSF interfaces, an informal presentation of syntax and semantics shall be provided. ADV_TIS.1.2C The TSF interface specification shall describe the syntax and semantics of all external interfaces of security enforcing components. D R A F T ADV_TIS - TSF interface specification Development Page 28 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_TIS.1.3C The TSF interface specification shall contain an argument that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Evaluator action elements: ADV_TIS.1.1E The evaluators shall check that the information provided meets all requirements for content and presentation of evidence. ADV_TIS.1.2E The evaluators shall check the TSF interface specification for consistency and completeness. ADV_TIS.1.3E The evaluators shall check that the TSF interface specification completely presents all security enforcing external TSF interfaces. ADV_TIS.1.4E The evaluators shall check the argument that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.2 Simple semiformal TSF interface specification Objectives and threats Application notes Dependencies: TBD Developer action elements: ADV_TIS.2.1D The developer shall provide a specification for the external interfaces provided by the TSF. ADV_TIS.2.2D The developer shall argue that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Content and presentation of evidence elements: ADV_TIS.2.1C For all of the external TSF interfaces, a semiformal presentation of syntax and semantics shall be provided. ADV_TIS.2.2C The TSF interface specification shall describe the syntax and semantics of all external interfaces of security enforcing components. ADV_TIS.2.3C The TSF interface specification shall contain an argument that the external interfaces provided by the TSF are sufficient to implement the security functional specification. D R A F T Development ADV_TIS - TSF interface specification 94/10/31 CCEB-94/084 - Version 0.9 Page 29 of 202 Evaluator action elements: ADV_TIS.2.1E The evaluators shall check that the information provided meets all requirements for content and presentation of evidence. ADV_TIS.2.2E The evaluators shall check the TSF interface specification for consistency and completeness. ADV_TIS.2.3E The evaluators shall check that the TSF interface specification completely presents all security enforcing external TSF interfaces. ADV_TIS.2.4E The evaluators shall check the argument that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.3 Semiformal interface specification Objectives and threats Application notes Dependencies: TBD Developer action elements: ADV_TIS.3.1D The developer shall provide a specification for the external interfaces provided by the TSF. ADV_TIS.3.2D The developer shall argue that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Content and presentation of evidence elements: ADV_TIS.3.1C For all of the external TSF interfaces, a semiformal presentation of syntax, semantics, exceptions, error messages, and effects shall be provided. ADV_TIS.3.2C The TSF interface specification shall describe the syntax, semantics, exceptions, error messages, and effects of all external interfaces of security enforcing components. ADV_TIS.3.3C The TSF interface specification shall contain an argument that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Evaluator action elements: ADV_TIS.3.1E The evaluators shall review that the information provided meets all requirements for content and presentation of evidence. D R A F T ADV_TIS - TSF interface specification Development Page 30 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_TIS.3.2E The evaluators shall review the TSF interface specification for consistency and completeness. ADV_TIS.3.3E The evaluators shall review that the TSF interface specification completely and accurately presents all security enforcing external TSF interfaces. ADV_TIS.3.4E The evaluators shall review the argument that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.4 Formal TSF interface specification Objectives and threats Application notes User notes 81 TBD Dependencies: TBD Developer action elements: ADV_TIS.4.1D The developer shall provide a specification for the external interfaces provided by the TSF. ADV_TIS.4.2D The developer shall demonstrate that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Content and presentation of evidence elements: ADV_TIS.4.1C For those portions of the external TSF interface that can be formally specified, a formal specification of syntax, semantics, exceptions, error messages, and effects shall be provided. ADV_TIS.4.2C For those external TSF interfaces not formally specified , a semiformal presentation of syntax, semantics, exceptions, error messages, and effects shall be provided. ADV_TIS.4.3C The TSF interface specification shall describe the syntax, semantics, exceptions, error messages, and effects of all external interfaces of security enforcing components. ADV_TIS.4.4C The TSF interface specification shall contain a demonstration that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.4.5C The evidences shall provide justification ................ . D R A F T Development ADV_TIS - TSF interface specification 94/10/31 CCEB-94/084 - Version 0.9 Page 31 of 202 Evaluator action elements: ADV_TIS.4.1E The evaluators shall verify that the information provided meets all requirements for content and presentation of evidence. ADV_TIS.4.2E The evaluators shall verify the TSF interface specification for consistency and completeness. ADV_TIS.4.3E The evaluators shall verify that the TSF interface specification completely and accurately presents all security enforcing external TSF interfaces. ADV_TIS.4.4E The evaluators shall review the demonstration that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.4.5E The evaluator shall review the justification. ADV_TIS.5 Formal and semiformal TSF interface specification Objectives and threats Application notes User notes 82 TBD Dependencies: TBD Developer action elements: ADV_TIS.5.1D The developer shall provide a specification for the external interfaces provided by the TSF. ADV_TIS.5.2D The developer shall demonstrate that the external interfaces provided by the TSF are sufficient to implement the security functional specification. Content and presentation of evidence elements: ADV_TIS.5.1C For those portions of the external TSF interface that can be formally specified, a formal specification of syntax, semantics, exceptions, error messages, and effects shall be provided. ADV_TIS.5.2C For all of the external TSF interfaces , a semiformal presentation of syntax, semantics, exceptions, error messages, and effects shall be provided. D R A F T ADV_TFC - TSF interface specification to functional specification correspondence Page 32 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_TIS.5.3C The TSF interface specification shall describe the syntax, semantics, exceptions, error messages, and effects of all external interfaces of security enforcing components. ADV_TIS.5.4C The TSF interface specification shall contain a demonstration that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.5.5C The evidences shall provide justification... TBD. Evaluator action elements: ADV_TIS.5.1E The evaluators shall verify that the information provided meets all requirements for content and presentation of evidence. ADV_TIS.5.2E The evaluators shall verify the TSF interface specification for consistency and completeness. ADV_TIS.5.3E The evaluators shall verify that the TSF interface specification completely and accurately presents all security enforcing external TSF interfaces. ADV_TIS.5.4E The evaluators shall review the demonstration that the external interfaces provided by the TSF are sufficient to implement the security functional specification. ADV_TIS.5.5E The evaluator shall review the justification. ADV_TFC TSF interface specification to functional specification correspondence 83 The correspondence between the specification of behaviour, as represented by the functional specification and the TSF interface specification provides assurance that all of the required behaviours of the functional specification are present in the TSF interface specification. Threats 84 TBD. Component levelling 85 These components are levelled according to the level of formality of the functional specification, and thus reflect the level of rigor that can be obtained in the correspondence between the functional specification and the level of the TSF interface specification. D R A F T Development ADV_TFC - TSF interface specification to functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 33 of 202 Application notes ADV_TFC.1 Correspondence argument Objectives and threats Application notes Dependencies: TBD Developer action elements: ADV_TFC.1.1D The developer shall argue that the TSF interface specification is an accurate instantiation of the functional specification. Content and presentation of evidence elements: ADV_TFC.1.1C The argument of correspondence between the TSF interface specification and the TSF specification may be informal. ADV_TFC.1.2C The correspondence evidence shall demonstrate that all TSF interfaces specified are implemented in the TSF interface specification. ADV_TFC.1.3C The correspondence evidence shall demonstrate that the policy implemented by the functional specification is also implemented by the TSF interface specification. Evaluator action elements: ADV_TFC.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_TFC.1.2E The evaluator shall review the argument of correspondence between the functional specification and the TSF interface specification for accuracy, consistency, and completeness. ADV_TFC.2 Correspondence demonstration Objectives and threats Application notes Dependencies: TBD D R A F T ADV_TFC - TSF interface specification to functional specification correspondence Page 34 of 202 CCEB-94/084 - Version 0.9 94/10/31 Developer action elements: ADV_TFC.2.1D The developer shall demonstrate that the TSF interface specification is an accurate instantiation of the formal functional specification . Content and presentation of evidence elements: ADV_TFC.2.1C The demonstration of correspondence between the TSF interface specification and the TSF interface specification shall be semi-formal . ADV_TFC.2.2C The correspondence evidence shall demonstrate that all security functions in the formal functional specification are implemented in the TSF interface specification . ADV_TFC.2.3C The correspondence evidence shall demonstrate that the policy implemented by the formal functional specification is also implemented by the TSF interface specification. Evaluator action elements: ADV_TFC.2.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_TFC.2.2E The evaluator shall review the demonstration of correspondence between the formal functional specification and the TSF interface specification for accuracy, consistency, and completeness. ADV_TFC.3 Correspondence proof Objectives and threats Application notes Dependencies: ADV_TIS.4 Formal TSF interface specification Developer action elements: ADV_TFC.3.1D For those portions of the functional specification that are formally specified , the developer shall prove that the TSF interface specification is an accurate instantiation of the formal functional specification . ADV_TFC.3.2D For those portions of the functional specification that are not formally specified, the developer shall demonstrate that the TSF interface specification is an accurate instantiation of the formal functional specification. Content and presentation of evidence elements: ADV_TFC.3.1C The proof of correspondence between the TSF interface specification and the functional specification shall be formal . D R A F T Development ADV_TFC - TSF interface specification to functional specification 94/10/31 CCEB-94/084 - Version 0.9 Page 35 of 202 ADV_TFC.3.2C The proof of correspondence evidence shall demonstrate that all interfaces specified in the formal specifications are implemented in the TSF interface specification. ADV_TFC.3.3C The correspondence evidence shall demonstrate that the policy implemented by the formal TSF specification is also implemented by the TSF interface specification. ADV_TFC.3.4C The demonstration of correspondence between the formal functional specification and those portions of the TSF detailed design not formally specified shall be semiformal. Evaluator action elements: ADV_TFC.3.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_TFC.3.2E The evaluator shall review that the proof of correspondence between the formal functional specification and the TSF interface specification for consistency, and completeness . ADV_TFC.3.3E The evaluator shall determine the accuracy of the proof of correspondence by selectively verifying the formal analysis. D R A F T ADV_TFC - TSF interface specification to functional specification correspondence Page 36 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Development ADV_HLD - High-level design 94/10/31 CCEB-94/084 - Version 0.9 Page 37 of 202 ADV_HLD High-level design Editor Note: There is some analysis here which deals with the assessment of whether the TOE addresses the threats enumerated in the Security Target. The overlap with AVA is still to be resolved. Objectives 86 The high-level design of a TOE provides a description of the TOE in terms of major structural units visible from an external point-of-view, and relates these units to the functions that they provide. The high-level design provides assurance that the TOE provides a structure appropriate to implement the claimed functional requirements and the security policy. 87 The high-level design refines the TSF interface specification and the functional specification into major structural units of the TOE design. For each major structural unit of the TOE, the high-level design describes its purpose and function and identifies the security functions enforced by the structural unit. The interrelationships of all structural units are also defined in the high-level design. These interrelationships will be external interfaces for data flow or control flow, etc. as appropriate. The high-level design describes "what" functions each structural unit performs. Threats 88 TBD. Application notes User notes 89 For all components in this family, the PP/ST author should also include any specific information called out for inclusion in the High-level Design documentation by any Functional Components included in the PP/ST. ADV_HLD.1 Informal high-level design Objectives and threats Application notes Evaluator notes 90 TBD Dependencies: TBD D R A F T ADV_HLD - High-level design Development Page 38 of 202 CCEB-94/084 - Version 0.9 94/10/31 Developer action elements: ADV_HLD.1.1D The developer shall provide the high-level design of the TSF. ADV_HLD.1.2D The developer shall argue that the high-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_HLD.1.1C The presentation of the high-level design shall be informal. ADV_HLD.1.2C The high-level design shall describe the general structure of the TSF. ADV_HLD.1.3C The high-level design shall describe the structural units of the TSF in terms of major elements (e.g.., hardware, kernel, servers) visible from a point-of-view external to the TSF. ADV_HLD.1.4C The high-level design shall describe those structural units of the TSF that provide an external interface to the TSF. ADV_HLD.1.5C The high-level design shall identify any underlying hardware, firmware, and/ or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.1.6C For each structural unit in the TSF, the high-level design shall describe the security functions provided by that structural unit. ADV_HLD.1.7C The high-level design shall contain an argument that the TSF mechanisms are an implementation of the security functional specification. Evaluator action elements: ADV_HLD.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.1.2E The evaluator shall check the presentation of the high- level design for consistency and completeness. ADV_HLD.1.3E The evaluator shall check that all structural units of the TSF have been presented. ADV_HLD.1.4E The evaluator shall check that all structural units of the TSF that provide external interfaces have been presented. ADV_HLD.1.5E The evaluator shall check the argument that the high- level design is an implementation of the security functional specification. ADV_HLD.1.6E The evaluator shall check that all the threats are adequately countered by the security enforcing structural units. D R A F T Development ADV_HLD - High-level design 94/10/31 CCEB-94/084 - Version 0.9 Page 39 of 202 ADV_HLD.1.7E The evaluator shall check that the security enforcing structural units combine together in a way which is mutually supportive and provide an integrated and competent whole. ADV_HLD.2 Identification of security enforcing structural units Objectives and threats Application notes Evaluator notes 91 TBD Dependencies: TBD Developer action elements: ADV_HLD.2.1D The developer shall provide the high-level design of the TSF. ADV_HLD.2.2D The developer shall argue that the high-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_HLD.2.1C The presentation of the high-level design shall be informal. ADV_HLD.2.2C The high-level design shall describe the general structure of the TSF. ADV_HLD.2.3C The high-level design shall describe the structural units of the TSF in terms of major elements (e.g.., hardware, kernel, servers) visible from a point-of-view external to the TSF. ADV_HLD.2.4C The high-level design shall divide the structural units of the TOE into security enforcing structural units, and other structural units, and describe how this separation is achieved. ADV_HLD.2.5C The high-level design shall describe those structural units of the TSF that provide an external interface to the TSF. ADV_HLD.2.6C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.2.7C For each structural unit in the TSF, the high-level design shall describe the security functions provided by that structural unit. D R A F T ADV_HLD - High-level design Development Page 40 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_HLD.2.8C The high-level design shall contain an argument that the TSF mechanisms are an implementation of the security functional specification. Evaluator action elements: ADV_HLD.2.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.2.2E The evaluator shall check the presentation of the high-level design for consistency and completeness. ADV_HLD.2.3E The evaluator shall check that all structural units of the TSF have been presented. ADV_HLD.2.4E The evaluator shall check that all structural units of the TSF that provide external interfaces have been presented. ADV_HLD.2.5E The evaluator shall check the argument that the high- level design is an implementation of the security functional specification. ADV_HLD.2.6E The evaluator shall check that all the threats are adequately countered by the security enforcing structural units. ADV_HLD.2.7E The evaluator shall check that the security enforcing structural units combine together in a way which is mutually supportive and provide an integrated and competent whole. ADV_HLD.3 Description of high-level design Objectives and threats Application notes Evaluator notes 92 TBD Dependencies: TBD Developer action elements: ADV_HLD.3.1D The developer shall provide the high-level design of the TSF. ADV_HLD.3.2D The developer shall argue that the high-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_HLD.3.1C The presentation of the high-level design shall be informal. D R A F T Development ADV_HLD - High-level design 94/10/31 CCEB-94/084 - Version 0.9 Page 41 of 202 ADV_HLD.3.2C The high-level design shall describe the general structure of the TSF. ADV_HLD.3.3C The high-level design shall identify and describe the structural units of the TSF in terms of major elements (e.g.., hardware, kernel, servers) visible from a point-of view external to the TSF. ADV_HLD.3.4C The high-level design shall divide the structural units of the TOE into security enforcing structural units, and other structural units, and describe how this separation is achieved. ADV_HLD.3.5C The high-level design shall describe those structural units of the TSF that provide an external interface to the TSF ; and for each structural unit, identify the external interfaces that it provides . ADV_HLD.3.6C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.3.7C For each structural unit in the TSF, the high-level design shall describe the security functions provided by that structural unit. ADV_HLD.3.8C The high-level design shall contain an argument that the TSF mechanisms are an implementation of the security functional specification. Evaluator action elements: ADV_HLD.3.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.3.2E The evaluator shall review the presentation of the high-level design for consistency and completeness. ADV_HLD.3.3E The evaluator shall review that all structural units of the TSF have been presented. ADV_HLD.3.4E The evaluator shall review that all structural units of the TSF that provide external interfaces have been presented , and the external interfaces that each provides identified . ADV_HLD.3.5E The evaluator shall review the argument that the high- level design is an implementation of the security functional specification. ADV_HLD.3.6E The evaluator shall check that all the threats are adequately countered by the security enforcing structural units. ADV_HLD.3.7E The evaluator shall check that the security enforcing structural units combine together in a way which is mutually supportive and provide an integrated and competent whole. D R A F T ADV_HLD - High-level design Development Page 42 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_HLD.4 Semiformal high-level design Objectives and threats Application notes Evaluator notes 93 TBD Dependencies: ADV_FSP.3 Semiformal security policy model Developer action elements: ADV_HLD.4.1D The developer shall provide the high-level design of the TSF. ADV_HLD.4.2D The developer shall demonstrate that the high-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_HLD.4.1C The presentation of the high-level design shall be semiformal . ADV_HLD.4.2C The high-level design shall describe the general structure of the TSF. ADV_HLD.4.3C The high-level design shall identify and describe the structural units of the TSF in terms of major elements (e.g.., hardware, kernel, servers) visible from a point-of view external to the TSF. ADV_HLD.4.4C The high-level design shall divide the structural units of the TOE into security enforcing structural units, and other structural units, and describe how this separation is achieved. ADV_HLD.4.5C The high-level design shall describe those structural units of the TSF that provide an external interface to the TSF; and for each structural unit, identify the external interfaces that it provides. ADV_HLD.4.6C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.4.7C For each structural unit in the TSF, the high-level design shall describe the security functions provided by that structural unit. ADV_HLD.4.8C The high-level design shall contain a demonstration that the TSF mechanisms are an implementation of the security functional specification. D R A F T Development ADV_HLD - High-level design 94/10/31 CCEB-94/084 - Version 0.9 Page 43 of 202 Evaluator action elements: ADV_HLD.4.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.4.2E The evaluator shall review the presentation of the high-level design for consistency and completeness. ADV_HLD.4.3E The evaluator shall review that all structural units of the TSF have been presented. ADV_HLD.4.4E The evaluator shall review that all structural units of the TSF that provide external interfaces have been presented, and the external interfaces that each provides identified. ADV_HLD.4.5E The evaluator shall review the demonstration that the high-level design is an implementation of the security functional specification. ADV_HLD.4.6E The evaluator shall check that all the threats are adequately countered by the security enforcing structural units. ADV_HLD.4.7E The evaluator shall check that the security enforcing structural units combine together in a way which is mutually supportive and provide an integrated and competent whole. ADV_HLD.5 Semiformal high-level explanation Objectives and threats Application notes Evaluator notes 94 TBD Dependencies: TBD ADV_INT.1 Modularity Developer action elements: ADV_HLD.5.1D The developer shall provide the high-level design of the TSF. ADV_HLD.5.2D The developer shall demonstrate that the high-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_HLD.5.1C The presentation of the high-level design shall be semiformal. D R A F T ADV_HLD - High-level design Development Page 44 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_HLD.5.2C The high-level design shall describe the general structure of the TSF. ADV_HLD.5.3C The high-level design shall describe the structural units of the TSF in terms of major elements (e.g.., hardware, kernel, servers) visible from a point-of-view external to the TSF. ADV_HLD.5.4C The high-level design shall divide the structural units of the TOE into security enforcing structural units, and other structural units, and describe how this separation is achieved. ADV_HLD.5.5C The high-level design shall describe those structural units of the TSF that provide an external interface to the TSF; and for each structural unit, identify the external interfaces that it provides. ADV_HLD.5.6C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.5.7C For each structural unit in the TSF, the high-level design shall describe the security functions provided by that structural unit. ADV_HLD.5.8C The high-level design shall contain a demonstration that the TSF mechanisms are an implementation of the security functional specification. ADV_HLD.5.9C The evidences shall provide justification .................. TBD. Evaluator action elements: ADV_HLD.5.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.5.2E The evaluator shall review the presentation of the high-level design for consistency and completeness. ADV_HLD.5.3E The evaluator shall review that all structural units of the TSF have been presented. ADV_HLD.5.4E The evaluator shall review that all structural units of the TSF that provide external interfaces have been presented, and the external interfaces that each provides identified. ADV_HLD.5.5E The evaluator shall review the demonstration that the high-level design is an implementation of the security functional specification. ADV_HLD.5.6E The evaluator shall check that all the threats are adequately countered by the security enforcing structural units. ADV_HLD.5.7E The evaluator shall check that the security enforcing structural units combine together in a way which is mutually supportive and provide an integrated and competent whole. D R A F T Development ADV_HLD - High-level design 94/10/31 CCEB-94/084 - Version 0.9 Page 45 of 202 ADV_HLD.5.8E The evaluator shall review the justification. ADV_HLD.6 Formal high-level explanation Objectives and threats Application notes Evaluator notes 95 TBD Dependencies: TBD Developer action elements: ADV_HLD.6.1D The presentation of the high level design shall be formal . ADV_HLD.6.2D The developer shall provide the high-level design of the TSF. ADV_HLD.6.3D The developer shall demonstrate that the high-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_HLD.6.1C The high-level design shall describe the general structure of the TSF. ADV_HLD.6.2C The high-level design shall describe the structural units of the TSF in terms of major elements (e.g.., hardware, kernel, servers) visible from a point-of-view external to the TSF. ADV_HLD.6.3C The high-level design shall divide the structural units of the TOE into security enforcing structural units, and other structural units, and describe how this separation is achieved. ADV_HLD.6.4C The high-level design shall describe those structural units of the TSF that provide an external interface to the TSF; and for each structural unit, identify the external interfaces that it provides. ADV_HLD.6.5C The high-level design shall identify any underlying hardware, firmware, and/or software required by the TSF with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.6.6C For each structural unit in the TSF, the high-level design shall describe the security functions provided by that structural unit. D R A F T ADV_HTC - High-level design to TSF interface specification correspondence Page 46 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_HLD.6.7C The high-level design shall contain a demonstration that the TSF mechanisms are an implementation of the security functional specification. ADV_HLD.6.8C The evidence shall provide justification ................... TBD. Evaluator action elements: ADV_HLD.6.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.6.2E The evaluator shall review the presentation of the high-level design for consistency and completeness. ADV_HLD.6.3E The evaluator shall review that all structural units of the TSF have been presented. ADV_HLD.6.4E The evaluator shall review that all structural units of the TSF that provide external interfaces have been presented, and the external interfaces that each provides identified. ADV_HLD.6.5E The evaluator shall review the demonstration that the high-level design is an implementation of the security functional specification. ADV_HLD.6.6E The evaluator shall check that all the threats are adequately countered by the security enforcing structural units. ADV_HLD.6.7E The evaluator shall check that the security enforcing structural units combine together in a way which is mutually supportive and provide an integrated and competent whole. ADV_HLD.6.8E The evaluator shall review the justification. ADV_HTC High-level design to TSF interface specification correspondence Objectives 96 The correspondence between the specification of behaviour, as represented by the external interface and the first level of design provides assurance that all of the required behaviours of the external interface are present in the high-level design. Threats 97 TBD. Component levelling 98 These components are levelled according to the level of formality of the interface specifications, and thus reflect the level of rigor that can be obtained in the D R A F T Development ADV_HTC - High-level design to TSF interface specification 94/10/31 CCEB-94/084 - Version 0.9 Page 47 of 202 correspondence between the specification level and the level of the high-level design. Application notes ADV_HTC.1 Correspondence argument Objectives and threats Application notes Dependencies: ADV_TIS.3 Semiformal interface specification Developer action elements: ADV_HTC.1.1D The developer shall argue that the high-level design is an accurate instantiation of the specification. Content and presentation of evidence elements: ADV_HTC.1.1C The argument of correspondence between the high-level design and the TSF specification may be informal. ADV_HTC.1.2C The correspondence evidence shall demonstrate that all interfaces specified are implemented in the high-level design. ADV_HTC.1.3C The correspondence evidence shall demonstrate that the policy implemented by the TSF specification is also implemented by the high-level design. Evaluator action elements: ADV_HTC.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_HTC.1.2E The evaluator shall review the argument of correspondence between the TSF interface specification and the high-level design for accuracy, consistency, and completeness. ADV_HTC.2 Correspondence demonstration Objectives and threats Application notes Dependencies: ADV_TIS.4 Formal TSF interface specification D R A F T ADV_HTC - High-level design to TSF interface specification correspondence Page 48 of 202 CCEB-94/084 - Version 0.9 94/10/31 Developer action elements: ADV_HTC.2.1D The developer shall demonstrate that the high-level design is an accurate instantiation of the formal specification . Content and presentation of evidence elements: ADV_HTC.2.1C The demonstration of correspondence between the high-level design and the TSF specification shall be semi-formal . ADV_HTC.2.2C The correspondence evidence shall demonstrate that all interfaces specified in the formal specifications are implemented in the high-level design . ADV_HTC.2.3C The correspondence evidence shall demonstrate that the policy implemented by the formal TSF specification is also implemented by the high- level design. Evaluator action elements: ADV_HTC.2.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_HTC.2.2E The evaluator shall review the demonstration of correspondence between the formal TSF interface specification and the high-level design for accuracy, consistency, and completeness. ADV_HTC.3 Correspondence proof Objectives and threats Application notes Dependencies: ADV_TIS.4 Formal TSF interface specification Developer action elements: ADV_HTC.3.1D For those portions of the TSF detailed design that are formally specified , the developer shall prove that the high-level design is an accurate instantiation of the formal specification . ADV_HTC.3.2D For those portions of the TSF detailed design that are not formally specified, the developer shall demonstrate that the high-level design is an accurate instantiation of the formal specification. Content and presentation of evidence elements: ADV_HTC.3.1C The proof of correspondence between the high-level design and the TSF specification shall be formal . D R A F T Development ADV_HTC - High-level design to TSF interface specification 94/10/31 CCEB-94/084 - Version 0.9 Page 49 of 202 ADV_HTC.3.2C The proof of correspondence evidence shall demonstrate that all interfaces specified in the formal specifications are implemented in the high-level design. ADV_HTC.3.3C The correspondence evidence shall demonstrate that the policy implemented by the formal TSF specification is also implemented by the high- level design. ADV_HTC.3.4C The demonstration of correspondence between the formal TSF interface specification and those portions of the TSF detailed design not formally specified shall be semiformal. Evaluator action elements: ADV_HTC.3.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_HTC.3.2E The evaluator shall review that the proof of correspondence between the formal TSF interface specification and the high-level design for consistency, and completeness. ADV_HTC.3.3E The evaluator shall determine the accuracy of the proof of correspondence by selectively verifying the formal analysis. D R A F T ADV_HTC - High-level design to TSF interface specification correspondence Page 50 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Development ADV_LLD - Low-level design description 94/10/31 CCEB-94/084 - Version 0.9 Page 51 of 202 ADV_LLD Low-level design description Objectives 99 The description of the low-level design captures the internal workings of the TSF for analysis. In doing so, it identifies internal interrelationships and dependencies, and clarifies exactly the portions of the TOE that must be trusted. Threats 100 TBD Component levelling Application notes User notes 101 The PP/ST low-level design description should also include any additional specific content and presentation requirements as specified by the documentation notes in the included functional components. ADV_LLD.1 Informal low-level design Objectives and threats Application notes Evaluator notes 102 Specifications need not be provided for structural units which are not security enforcing. Dependencies: ADV_FSP.2 Informal security policy model Developer action elements: ADV_LLD.1.1D The developer shall provide the low-level design of the TSF. ADV_LLD.1.2D The developer shall argue that the low-level design of the TSF is an implementation of the security functional specification. Content and presentation of evidence elements: ADV_LLD.1.1C The presentation of the low-level design shall be informal, but sufficiently detailed to allow the analysis of interrelationships between the mechanisms employed. D R A F T ADV_LLD - Low-level design description Development Page 52 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_LLD.1.2C The low-level design shall identify and describe the internal design of the TSF components, structured along major conceptual or actual subsystems. ADV_LLD.1.3C The low-level design shall describe the purpose of each major subsystem. ADV_LLD.1.4C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.1.5C The low-level design shall list all internal interfaces of security enforcing components, including a description of their syntax and semantics. ADV_LLD.1.6C The low-level design shall justify why components for which no design information is provided are not security enforcing. ADV_LLD.1.7C The low-level design shall contain an argument that the TSF mechanisms are an implementation of the security functional specification. Evaluator action elements: ADV_LLD.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.1.2E The evaluator shall check the low-level design for consistency and completeness. ADV_LLD.1.3E The evaluator shall check the argument that the low-level design is an implementation of the security functional specification. ADV_LLD.2 Descriptive low-level design Objectives and threats Application notes Evaluator notes 103 Specifications need not be provided for structural units which are not security enforcing. Dependencies: ADV_HLD.3 Description of high-level design Developer action elements: ADV_LLD.2.1D The developer shall provide the low-level design of the TSF. ADV_LLD.2.2D The developer shall argue that the low-level design of the TSF is an implementation of the high-level design . D R A F T Development ADV_LLD - Low-level design description 94/10/31 CCEB-94/084 - Version 0.9 Page 53 of 202 Content and presentation of evidence elements: ADV_LLD.2.1C The presentation of the low-level design shall be informal, but sufficiently detailed to allow the analysis of interrelationships between the mechanisms employed. ADV_LLD.2.2C The low-level design shall identify and describe the internal design of the TSF components, structured along major conceptual or actual subsystems. ADV_LLD.2.3C The low-level design shall describe the purpose of each major subsystem. ADV_LLD.2.4C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.2.5C The low-level design shall list all internal interfaces of security enforcing components, including a description of their syntax and semantics. ADV_LLD.2.6C The low-level design shall justify why components for which no design information is provided are not security enforcing. ADV_LLD.2.7C The low-level design shall contain an argument that the TSF mechanisms are an implementation of the high-level design . Evaluator action elements: ADV_LLD.2.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.2.2E The evaluator shall check the low-level design for consistency and completeness. ADV_LLD.2.3E The evaluator shall check the argument that the low-level design is an implementation of the high-level design . ADV_LLD.3 Module-level low-level design Objectives and threats Application notes Evaluator notes 104 Specifications need not be provided for structural units which are not security enforcing. Dependencies: ADV_HLD.3 Description of high-level design Developer action elements: ADV_LLD.3.1D The developer shall provide the low-level design of the TSF. D R A F T ADV_LLD - Low-level design description Development Page 54 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_LLD.3.2D The developer shall argue that the low-level design of the TSF is an implementation of the high-level design. Content and presentation of evidence elements: ADV_LLD.3.1C The presentation of the low-level design shall be informal, but sufficiently detailed to allow the analysis of interrelationships between the mechanisms employed. ADV_LLD.3.2C The low-level design shall identify and describe the internal design of the TSF components, structured along major conceptual or actual subsystems. ADV_LLD.3.3C The low-level design shall describe the purpose of each major subsystem and module . ADV_LLD.3.4C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.3.5C The low-level design shall list all (i.e., both internal and external) interfaces of security enforcing modules; including, for internal interfaces, a description of their syntax and semantics. ADV_LLD.3.6C The low-level design shall justify why modules for which no design information is provided are not security enforcing. ADV_LLD.3.7C The low-level design shall contain an argument that the TSF mechanisms are an implementation of the high-level design. Evaluator action elements: ADV_LLD.3.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.3.2E The evaluator shall review the low-level design for consistency and completeness. ADV_LLD.3.3E The evaluator shall review the argument that the low- level design is an implementation of the high-level design. ADV_LLD.4 Semiformal low-level design description Objectives and threats Application notes Evaluator notes 105 Specifications need not be provided for structural units which are not security enforcing. D R A F T Development ADV_LLD - Low-level design description 94/10/31 CCEB-94/084 - Version 0.9 Page 55 of 202 Dependencies: ADV_HLD.4 Semiformal high-level design Developer action elements: ADV_LLD.4.1D The developer shall provide the low-level design of the TSF. ADV_LLD.4.2D The developer shall argue that the low-level design of the TSF is an implementation of the high-level design. Content and presentation of evidence elements: ADV_LLD.4.1C The presentation of the low-level design shall be semiformal . ADV_LLD.4.2C The low-level design shall identify and describe the internal design of the TSF components, structured along major conceptual or actual subsystems. ADV_LLD.4.3C The low-level design shall describe the purpose of each major subsystem and module. ADV_LLD.4.4C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.4.5C The low-level design shall list all (i.e., both internal and external) interfaces of security enforcing modules; including, for internal interfaces, a description of their syntax and semantics. ADV_LLD.4.6C The low-level design shall describe the separation of the TSF into security enforcing modules. ADV_LLD.4.7C The low-level design shall justify why modules for which no design information is provided are not security enforcing. ADV_LLD.4.8C The low-level design shall contain an argument that the TSF mechanisms are an implementation of the high-level design. Evaluator action elements: ADV_LLD.4.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.4.2E The evaluator shall review the low-level design for consistency and completeness. ADV_LLD.4.3E The evaluator shall review the argument that the low- level design is an implementation of the high-level design. D R A F T ADV_LLD - Low-level design description Development Page 56 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_LLD.5 Semiformal low-level design explanation Objectives and threats Application notes Evaluator notes 106 Specifications need not be provided for structural units which are not security enforcing. Dependencies: ADV_HLD.5 Semiformal high-level explanation Developer action elements: ADV_LLD.5.1D The developer shall provide the low-level design of the TSF. ADV_LLD.5.2D The developer shall demonstrate that the low-level design of the TSF is an implementation of the high-level design. Content and presentation of evidence elements: ADV_LLD.5.1C The presentation of the low-level design shall be semiformal. ADV_LLD.5.2C The low-level design shall identify and describe the internal design of the TSF components, structured along major conceptual or actual subsystems. ADV_LLD.5.3C The low-level design shall describe the purpose of each major subsystem and module. ADV_LLD.5.4C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.5.5C The low-level design shall list all (i.e., both internal and external) interfaces of security enforcing modules; including, for internal interfaces, a description of their syntax and semantics. ADV_LLD.5.6C The low-level design shall describe the separation of the TSF into security enforcing modules. ADV_LLD.5.7C The low-level design shall justify why modules for which no design information is provided are not security enforcing. ADV_LLD.5.8C The low-level design shall contain an demonstration that the TSF mechanisms are an implementation of the high-level design. ADV_LLD.5.9C The evidences shall provide justification .................. TBD. D R A F T Development ADV_LLD - Low-level design description 94/10/31 CCEB-94/084 - Version 0.9 Page 57 of 202 Evaluator action elements: ADV_LLD.5.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.5.2E The evaluator shall review the low-level design for consistency and completeness. ADV_LLD.5.3E The evaluator shall review the demonstration that the low-level design is an implementation of the high-level design. ADV_LLD.5.4E The evaluator shall review the justification. ADV_LLD.6 Formal low-level design explanation Objectives and threats Application notes User notes 107 TBD Evaluator notes 108 Specifications need not be provided for structural units which are not security enforcing. 109 Note that a complete semi-formal low-level design is required in addition to the formal specifications. Dependencies: ADV_HLD.5 Semiformal high-level explanation Developer action elements: ADV_LLD.6.1D The developer shall provide the low-level design of the TSF. ADV_LLD.6.2D The developer shall demonstrate that the low-level design of the TSF is an implementation of the high-level design. Content and presentation of evidence elements: ADV_LLD.6.1C The presentation of the low-level design shall be semiformal. ADV_LLD.6.2C For those portions of the low-level design that can be formally specified, a formal specification of syntax, semantics, exceptions, error messages, and effects shall be provided. D R A F T ADV_LHC - Low-level design to high-level design correspondence Development Page 58 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_LLD.6.3C The low-level design shall identify and describe the internal design of the TSF components, structured along major conceptual or actual subsystems. ADV_LLD.6.4C The low-level design shall describe the purpose of each major subsystem and module. ADV_LLD.6.5C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.6.6C The low-level design shall describe the implementation of all security enforcing mechanisms. ADV_LLD.6.7C The low-level design shall list all (i.e., both internal and external) interfaces of security enforcing modules; including, for internal interfaces, a description of their syntax and semantics. ADV_LLD.6.8C The low-level design shall describe the separation of the TSF into security enforcing modules. ADV_LLD.6.9C The low-level design shall justify why modules for which no design information is provided are not security enforcing. ADV_LLD.6.10C The low-level design shall contain an demonstration that the TSF mechanisms are an implementation of the high-level design. ADV_LLD.6.11C The evidences shall provide justification ................. TBD. Evaluator action elements: ADV_LLD.6.1E The evaluator shall verify that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.6.2E The evaluator shall verify the low-level design for consistency and completeness. ADV_LLD.6.3E The evaluator shall verify the demonstration that the low-level design is an implementation of the high-level design. ADV_LLD.6.4E The evaluator shall review the justification. ADV_LHC Low-level design to high-level design correspondence Objectives 110 The correspondence to the specification of behaviour, as represented by the high level design, provides assurance that all of the required behaviours of the high level design are present in the low level design. D R A F T Development ADV_LHC - Low-level design to high-level design correspondence 94/10/31 CCEB-94/084 - Version 0.9 Page 59 of 202 Threats 111 TBD. Component levelling 112 These components are levelled according to the level of formality of the interface specifications, and thus reflect the level of rigor that can be obtained in the correspondence between the high-level design and the low-level design. Application notes ADV_LHC.1 Correspondence argument Objectives and threats Application notes Dependencies: ADV_TIS.3 Semiformal interface specification ADV_HLD.3 Description of high-level design Developer action elements: ADV_LHC.1.1D The developer shall argue that the low level design is an accurate instantiation of the high level design Content and presentation of evidence elements: ADV_LHC.1.1C The correspondence evidence shall demonstrate that all major elements and components specified in the high level design specifications are implemented in the low level design. ADV_LHC.1.2C The demonstration of correspondence between informally specified low level design and the high level design specification shall be informal arguments. Evaluator action elements: ADV_LHC.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_LHC.1.2E The evaluator shall review the informal correspondence between the high level design specification and the low level design for accuracy, consistency, and completeness D R A F T ADV_LHC - Low-level design to high-level design correspondence Development Page 60 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_LHC.2 Correspondence demonstration Objectives and threats Application notes Dependencies: ADV_TIS.4 Formal TSF interface specification ADV_HLD.4 Semiformal high-level design Developer action elements: ADV_LHC.2.1D The developer shall argue that the low level design is an accurate instantiation of the high level design ADV_LHC.2.2D For those portions of the high level design that are semi- formally specified, the developer shall demonstrate that the semi-formally expressed low level design is an accurate instantiation of the formal high level design specification. Content and presentation of evidence elements: ADV_LHC.2.1C The correspondence evidence shall demonstrate that all major elements and components specified in the high level design specifications are implemented in the low level design. ADV_LHC.2.2C The demonstration of correspondence between informally specified low level design and the high level design specification shall be informal arguments. ADV_LHC.2.3C The demonstration of correspondence between the semi-formally specified low level design and the high level design specification shall be semi-formal arguments. Evaluator action elements: ADV_LHC.2.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_LHC.2.2E The evaluator shall review the informal correspondence between the high level design specification and the low level design for accuracy, consistency, and completeness. ADV_LHC.2.3E The evaluator shall review the semi-formal correspondence between the high level design specification and the low level design for accuracy, consistency, and completeness. D R A F T Development ADV_LHC - Low-level design to high-level design correspondence 94/10/31 CCEB-94/084 - Version 0.9 Page 61 of 202 ADV_LHC.3 Correspondence proof Objectives and threats Application notes Dependencies: ADV_TIS.4 Formal TSF interface specification ADV_HLD.6 Formal high-level explanation Developer action elements: ADV_LHC.3.1D The developer shall argue that the low level design is an accurate instantiation of the high level design ADV_LHC.3.2D For those portions of the high level design that are semi-formally specified, the developer shall demonstrate that the semi- formally expressed low level design is an accurate instantiation of the formal high level design specification. ADV_LHC.3.3D For those portions of the high level design that are formally specified, the developer shall prove that the formal expression of the low level design is an accurate instantiation of the formal high level design specification. Content and presentation of evidence elements: ADV_LHC.3.1C The correspondence evidence shall demonstrate that all major elements and components specified in the high level design specifications are implemented in the low level design. ADV_LHC.3.2C The demonstration of correspondence between informally specified low level design and the high level design specification shall be informal arguments. ADV_LHC.3.3C The demonstration of correspondence between the semi- formally specified low level design and the high level design specification shall be semi-formal arguments. ADV_LHC.3.4C The demonstration of correspondence between the formally specified low level design and the high level design specification shall be formal proofs. Evaluator action elements: ADV_LHC.3.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADV_LHC.3.2E The evaluator shall review the informal correspondence between the high level design specification and the low level design for accuracy, consistency, and completeness. D R A F T ADV_LHC - Low-level design to high-level design correspondence Development Page 62 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADV_LHC.3.3E The evaluator shall review the semi-formal correspondence between the high level design specification and the low level design for accuracy, consistency, and completeness . ADV_LHC.3.4E The evaluator shall review that the proof of correspondence between the formal high level design specification and the low level design for accuracy, consistency, and completeness. ADV_LHC.3.5E The evaluator shall determine the accuracy of the proof of correspondence by selectively verifying the formal analysis. D R A F T Development ADV_IMP - Delivery of code/hardware drawings 94/10/31 CCEB-94/084 - Version 0.9 Page 63 of 202 ADV_IMP Delivery of code/hardware drawings Editor Note: The implementation families have to be revised e.g. in line with the current drafting guidance, see Annex A. In addition, the recent introduction of the ADV_INT family will have considerable overlap with these families, an overlap yet to be resolved. Objectives 113 The description of the implementation in the form of source code, object code, firmware and hardware captures the detailed internal workings of the TSF for analysis. 114 The implementation representation allows the evaluator the detailed view of the TOE for analysis purposes. Threats 115 TBD. Component levelling 116 The components in the family shall be levelled on the implementation representations provided. Application notes ADV_IMP.1 Delivery of subset Objectives and threats 117 Often, evaluators need the source code for the extremely critical parts of the system for analysis purposes, whilst not needing other security enforcing code. Application notes User notes 118 The PP/ST author should specify the subset of source code to be delivered. If omitted, the evaluators have the option of requesting a specific subset. Evaluator notes 119 If a specific subset of the source code/hardware drawing to be delivered has not been specified by the PP/ST author, the evaluators have the option of requesting a subset of the source code/hardware drawings for analysis. Dependencies: No dependencies. D R A F T ADV_IMP - Delivery of code/hardware drawings Development Page 64 of 202 CCEB-94/084 - Version 0.9 94/10/31 Developer action elements: ADV_IMP.1.1D The developer shall provide the implementation for a selected subset of the TSF. Content and presentation of evidence elements: ADV_IMP.1.1C The presentation of the software and firmware implementation shall be in the form of source code. ADV_IMP.1.2C The presentation of the hardware implementation shall be in the form of hardware drawings. Evaluator action elements: ADV_IMP.1.1E The evaluators shall check that the information provided meets all requirements for content and presentation of evidence. ADV_IMP.1.2E The evaluators shall use the presentation(s) of the implementation in support of other evaluation activities. ADV_IMP.2 Delivery of all security relevant code Objectives and threats 120 Delivery of the entire implementation of the TSF is necessary to support activities such as modularity studies, penetration testing, and mapping of design to implementation. Application notes 121 TBD Dependencies: ADV_HLD.2 Identification of security enforcing structural units Developer action elements: ADV_IMP.2.1D The developer shall provide the implementation for all security enforcing components . Content and presentation of evidence elements: ADV_IMP.2.1C The presentation of the software and firmware implementation shall be in the form of source code. ADV_IMP.2.2C The presentation of the hardware implementation shall be in the form of hardware drawings. D R A F T Development ADV_ILC - Implementation to low-level design correspondence 94/10/31 CCEB-94/084 - Version 0.9 Page 65 of 202 Evaluator action elements: ADV_IMP.2.1E The evaluators shall check that the information provided meets all requirements for content and presentation of evidence. ADV_IMP.2.2E The evaluators shall use the presentation(s) of the implementation in support of other evaluation activities. ADV_IMP.3 Structured delivery Objectives and threats Application notes Dependencies: ADV_HLD.2 Identification of security enforcing structural units ADV_LLD.3 Module-level low-level design Developer action elements: ADV_IMP.3.1D The developer shall provide the implementation for all security enforcing components. Content and presentation of evidence elements: ADV_IMP.3.1C The presentation of the software and firmware implementation shall be in the form of source code. ADV_IMP.3.2C The presentation of the hardware implementation shall be in the form of hardware drawings. ADV_IMP.3.3C The source code and hardware drawings shall be completely structured into small, comprehensible, separate sections. Evaluator action elements: ADV_IMP.3.1E The evaluators shall check that the information provided meets all requirements for content and presentation of evidence. ADV_IMP.3.2E The evaluators shall use the presentation(s) of the implementation in support of other evaluation activities. ADV_ILC Implementation to low-level design correspondence Objectives 122 The correspondence between the implementation and low-level design deals with the correct and complete instantiation of the low-level design into source code and D R A F T ADV_ILC - Implementation to low-level design correspondence Development Page 66 of 202 CCEB-94/084 - Version 0.9 94/10/31 possibly hardware or firmware. At this point in the successive step- wise refinements of the design a conclusion is reached, on the basis of the cumulative evidence to this point, as to whether or not the implementation is a complete and accurate instantiation of the original specification. Threats 123 TBD Component levelling 124 Levelling for these components is based on the completeness of correspondence evidence. There are only two levels of components in this family. The first requires that some evidence of the correspondence be presented and the second requires that justification be presented that the correspondence is complete. Application notes 125 The level of documentation, especially the level of formality required in the functional specifications, shall be consistent with what is required by the components that require this level of evidence. In particular, the judgment required at this level concerning the consistency between the implementation and the functional specifications will be based upon the level of detail, rigor, and formality required by the components that call for functional specifications to be delivered and argued about. ADV_ILC.1 Informal implementation to low-level design correspondence Objectives and threats Application notes Dependencies: ADV_LLD.3 Module-level low-level design ADV_IMP.1 Delivery of subset Developer action elements: ADV_ILC.1.1D The developer shall provide the evidence and analysis of the correspondence between the source code or hardware drawings and the low-level design. Content and presentation of evidence elements: ADV_ILC.1.1C The evidence shall provide a mapping between the source code or hardware drawings and the functional elements of the low-level design. ADV_ILC.1.2C The evidence shall demonstrate that the low-level design has been accurately implemented; that the source code or hardware provides the functions and behaviour specified by the low-level design. D R A F T Development ADV_ILC - Implementation to low-level design correspondence 94/10/31 CCEB-94/084 - Version 0.9 Page 67 of 202 Evaluator action elements: ADV_ILC.1.1E The evaluators shall review the information provided to determine that it meets all requirements for content and presentation of evidence. ADV_ILC.1.2E The evaluators shall review the correspondence between the implementation and the low-level design for accuracy and consistency. ADV_ILC.2 Demonstrated implementation to low-level design correspondence Objectives and threats Application notes Dependencies: ADV_LLD.5 Semiformal low-level design explanation ADV_IMP.2 Delivery of all security relevant code Developer action elements: ADV_ILC.2.1D The developer shall provide the evidence and analysis of the correspondence between the source code or hardware drawings and the low- level design. Content and presentation of evidence elements: ADV_ILC.2.1C The evidence shall demonstrate a complete mapping between the source code or hardware drawings and the functional elements of the low-level design ; each of the functional elements of the low-level design will be shown to trace to its instantiation in either the source code or the hardware. ADV_ILC.2.2C The evidence shall demonstrate that the low-level design has been accurately implemented; that the source code or hardware provides the functions and behaviour specified by the low-level design. Evaluator action elements: ADV_ILC.2.1E The evaluators shall review the information provided to determine that it meets all requirements for content and presentation of evidence. ADV_ILC.2.2E The evaluators shall review the correspondence between the implementation and the low-level design for accuracy, consistency and completeness . D R A F T ADV_ILC - Implementation to low-level design correspondence Development Page 68 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Tests - 94/10/31 CCEB-94/084 - Version 0.9 Page 69 of 202 Class ATE Tests 126 Figure 2.2 shows the families within this class, and the hierarchy of components within the families.. TESTS | | - ATE_FUN - 1 - 2 - 3 - 4 - 5 - 6 | | - ATE_COV - 1 - 2 - 3 | | - ATE_IND - 1 - 2 - 3 | | - ATE_DPT - 1 - 2 - 3 Figure 2.2 - Tests class decomposition 127 The class "Tests" encompasses four families: functional tests (ATE_FUN), coverage (ATE_COV), independent testing (i.e., testing performed by evaluators) (ATE_IND), and depth (ATE_DPT). This class does not deal with penetration testing, which is directed toward finding design and implementation flaws that D R A F T ATE_FUN - Functional tests Tests Page 70 of 202 CCEB-94/084 - Version 0.9 94/10/31 enable a user to violate the security policy. Penetration testing is dealt with separately as an aspect of vulnerability assessment in the class AVA. Testing establishes that the TSF interface exhibits the properties necessary to satisfy the functional requirements of its protection profile and/or security target. Testing provides assurance that the TSF satisfies at least the security functional requirements, although it cannot establish that the TSF does no more than what was specified. Testing may also be directed toward the internals of the TSF, such as the testing of modules and sub-modules against their design specifications. Additionally, testing can reveal implementation errors as well as design flaws. ATE_FUN Functional tests Objectives 128 Functional testing establishes that the TSF interface exhibits the properties necessary to satisfy the functional requirements of its protection profile and/or security target. Functional testing provides assurance that the TSF satisfies at least the security functional requirements, although it cannot establish that the TSF does no more than what was specified. The family "Functional tests" is largely focused on the responsibilities for testing (i.e., developer or evaluator), the type and amount of documentation or support tools required, and what is to be demonstrated through testing. Threats 129 Functional tests address the threats associated with incorrect implementation of the specifications or the substitution of code that is compliant with the specifications with code that is non-compliant. Component levelling 130 Levelling is based upon the responsibilities for testing (i.e., developer or evaluator), the amount and quality of test documentation and test support, the types of analysis and results required (e.g., elimination or neutralizing of errors), and the level of specification required for developing tests (e.g., narrative design specifications, formal design specifications). Application notes ATE_FUN.1 Minimal testing Objectives and threats 131 At this level the developer may provide test planning and test documentation, but is not required to do so. It is expected that, in general, evaluators will perform any testing not performed by the developer. D R A F T Tests ATE_FUN - Functional tests 94/10/31 CCEB-94/084 - Version 0.9 Page 71 of 202 Application notes Dependencies: TBD. Developer action elements: ATE_FUN.1.1D The developer may test the TSF interfaces to demonstrate that each functions in accordance with the functional specifications. ATE_FUN.1.2D The developer may produce the Test Documentation. Content and presentation of evidence elements: ATE_FUN.1.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_FUN.1.2C The test plan shall identify the functions to be tested and describe the tests to be performed. ATE_FUN.1.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_FUN.1.4C The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target. Evaluator action elements: ATE_FUN.1.1E The evaluator shall check the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_FUN.1.2E The evaluator shall check the test results to determine that the testing shows that the TSF functions as specified in the TOE documentation. ATE_FUN.2 Conformance testing Objectives and threats 132 At this level, the developer is required to perform testing and to provide test documentation and test results. Conformance testing demonstrates that all specified TSF interfaces have tested, and that the TSF performs as expected. Application notes Dependencies: The TSF interface must be specified The TSF security policy must be specified D R A F T ATE_FUN - Functional tests Tests Page 72 of 202 CCEB-94/084 - Version 0.9 94/10/31 Developer action elements: ATE_FUN.2.1D The developer shall test the TSF interfaces to demonstrate that each functions in accordance with the functional specifications. ATE_FUN.2.2D The developer shall produce the Test Documentation. Content and presentation of evidence elements: ATE_FUN.2.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_FUN.2.2C The test plan shall identify the functions to be tested and describe the tests to be performed. ATE_FUN.2.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_FUN.2.4C The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and as defined in the interface description or specification. Evaluator action elements: ATE_FUN.2.1E The evaluator shall check the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_FUN.2.2E The evaluator shall check the test results to determine that the testing shows that the TSF functions as specified in the TOE documentation. ATE_FUN.3 TSF Interface testing Objectives and threats 133 Testing is added to exercise the boundary conditions of the security functions. An example of such testing is to attempt to use out-of-range or undefined parameters. Additionally, the developer is required to provide justification that the testing is complete; that all of the TSF interfaces are being tested. Application notes Dependencies: The TSF interface must be specified The TSF security policy must be specified The test documentation shall be under configuration management D R A F T Tests ATE_FUN - Functional tests 94/10/31 CCEB-94/084 - Version 0.9 Page 73 of 202 Developer action elements: ATE_FUN.3.1D The developer shall test all the TSF interfaces to demonstrate that each functions in accordance with the functional specifications. ATE_FUN.3.2D The developer shall test the boundary conditions of the security functions to demonstrate that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.3.3D The developer shall produce the Test Documentation. The Test Documentation shall include a library of test programs that contains test programs and tools. ATE_FUN.3.4D The developer shall correct all flaws discovered by testing and retest the TSF until the protection functions are shown to work as claimed. Content and presentation of evidence elements: ATE_FUN.3.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_FUN.3.2C The test plan shall identify the functions to be tested and describe the tests to be performed. The tests shall exercise the boundary conditions of the security functions. ATE_FUN.3.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_FUN.3.4C The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and as defined in the interface description or specification, and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.3.5C The test results shall demonstrate that all identified errors have been neutralized or eliminated and that no new errors have been introduced. Evaluator action elements: ATE_FUN.3.1E The evaluator shall review to see that the boundary conditions of the security functions are tested. ATE_FUN.3.2E The evaluator shall review t he test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_FUN.3.3E The evaluator shall review t he test results to determine that the testing shows that the TSF functions as specified in the protection profile or security target and that the TSF can be expected to behave as specified regardless of input values. ATE_FUN.3.4E The evaluators shall use the developer's library of test programs and tools to check the developer testing via sampling. D R A F T ATE_FUN - Functional tests Tests Page 74 of 202 CCEB-94/084 - Version 0.9 94/10/31 ATE_FUN.3.5E The evaluator shall test for obvious flaws (e.g., well-known attacks or errors, known flaws in earlier versions of the TOE.) ATE_FUN.4 Semi-formal specifications Objectives and threats 134 Test plans are generated from formal or semi-formal interface specifications. This provides a much closer linkage to the high-level design and thus, greater assurance that the behavior of the TSF is as required. Testing demonstrates that the TSF implementation is consistent with the semi-formal or formal specification. Requirements are added to assure that previously discovered flaws have been corrected. Application notes Dependencies: The TSF interface must be specified The TSF security policy must be specified The test documentation shall be under configuration management Developer action elements: ATE_FUN.4.1D The developer shall test all the TSF interfaces to demonstrate that each functions in accordance with the semi-formal or formal functional specifications. ATE_FUN.4.2D The developer shall test the boundary conditions of the security functions to demonstrate that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.4.3D The developer shall correct all flaws discovered by testing and retest the TSF until the protection functions are shown to work as claimed. ATE_FUN.4.4D The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. ATE_FUN.4.5D All flaws identified discovered during testing will either be corrected or neutralized. The TOE shall be retested to determine that all discovered flaws have been eliminated and that no new flaws have been introduced. ATE_FUN.4.6D The developer shall produce the Test Documentation. The Test Documentation shall include a library of test programs that contains test programs and tools. Content and presentation of evidence elements: ATE_FUN.4.1C The documentation shall consist of test plans, test procedure description, and the test results. D R A F T Tests ATE_FUN - Functional tests 94/10/31 CCEB-94/084 - Version 0.9 Page 75 of 202 ATE_FUN.4.2C The test plan shall identify the functions to be tested and describe the tests to be performed. The tests shall exercise the boundary conditions of the security functions. Test cases shall be generated from the semi-formal or formal interface specifications (whichever approach has been used for defining the interface). The test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. ATE_FUN.4.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_FUN.4.4C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and as defined in the interface description or specification, and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.4.5C The test results shall demonstrate that all identified errors have been neutralized or eliminated and that no new errors have been introduced. Evaluator action elements: ATE_FUN.4.1E The evaluator shall review that the test cases and test data are consistent with the semi-formal or formal interface specification. ATE_FUN.4.2E The evaluator shall review to see that the boundary conditions of the security functions are tested. ATE_FUN.4.3E The evaluator shall review t he test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_FUN.4.4E The evaluator shall review t he test results to determine that the testing shows that the TSF functions as specified in the protection profile or security target and that the TSF can be expected to behave as specified regardless of input values. ATE_FUN.4.5E The evaluators shall use the developer's library of test programs and tools to check the developer testing via sampling. ATE_FUN.4.6E The evaluator shall test for obvious flaws (e.g., well- known attacks or errors, known flaws in earlier versions of the TOE). ATE_FUN.4.7E The evaluator shall review the test results to determine that previously discovered flaws are no longer present. ATE_FUN.5 Design correctness Objectives and threats 135 Analysis is added to provide a high degree of confidence that the likelihood of undiscovered errors is relatively small. D R A F T ATE_FUN - Functional tests Tests Page 76 of 202 CCEB-94/084 - Version 0.9 94/10/31 Application notes Dependencies: The TSF interface must be specified The TSF security policy must be specified The test documentation shall be under configuration management The Descriptive or Formal Interface specifications shall be under configuration management Test tools shall be under configuration management Process dependencies (e.g., formal proofs, spec-to-code mappings) Developer action elements: ATE_FUN.5.1D The developer shall test all the TSF interfaces to demonstrate that each functions in accordance with the semi-formal or formal functional specifications. ATE_FUN.5.2D The developer shall test the boundary conditions of the security functions to demonstrate that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.5.3D The developer shall correct all flaws discovered by testing and retest the TSF until the protection functions are shown to work as claimed. ATE_FUN.5.4D The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. ATE_FUN.5.5D All flaws identified discovered during testing will either be corrected or neutralized. The TOE shall be retested to determine that all discovered flaws have been eliminated and that no new flaws have been introduced. ATE_FUN.5.6D All flaws discovered during testing shall be analyzed and characterized as either errors of design or implementation. No design flaws and no more than a few correctable implementation flaws may be found during testing. ATE_FUN.5.7D The developer shall produce the Test Documentation. The Test Documentation shall include a library of test programs that contains test programs and tools. Content and presentation of evidence elements: ATE_FUN.5.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_FUN.5.2C The test plan shall identify the functions to be tested and describe the tests to be performed. The tests shall exercise the boundary conditions of the security functions. Test cases shall be generated from the semi-formal or formal interface specifications (whichever approach has been used for defining the interface). The D R A F T Tests ATE_FUN - Functional tests 94/10/31 CCEB-94/084 - Version 0.9 Page 77 of 202 test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. ATE_FUN.5.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_FUN.5.4C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. ATE_FUN.5.5C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and as defined in the interface description or specification, and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.5.6C The test results shall demonstrate that all identified errors have been neutralized or eliminated and that no new errors have been introduced. ATE_FUN.5.7C All flaws discovered during testing shall be analyzed and characterized as either errors of design or implementation. No design flaws and no more than a few correctable implementation flaws may be found during testing. ATE_FUN.5.8C The evidence shall provide justification .....................TBD Evaluator action elements: ATE_FUN.5.1E The evaluator shall review that the test cases and test data are consistent with the semi-formal or formal interface specification. ATE_FUN.5.2E The evaluator shall review to see that the boundary conditions of the security functions are tested. ATE_FUN.5.3E The evaluator shall review the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_FUN.5.4E The evaluator shall review the test results to determine that the testing shows that the TSF functions as specified in the protection profile or security target and that the TSF can be expected to behave as specified regardless of input values. ATE_FUN.5.5E The evaluators shall use the developer's library of test programs and tools to check the developer testing via sampling. ATE_FUN.5.6E The evaluator shall test for obvious flaws (e.g., well- known attacks or errors, known flaws in earlier versions of the TOE). ATE_FUN.5.7E The test results shall be checked to determine that previously- discovered flaws are no longer present. D R A F T ATE_FUN - Functional tests Tests Page 78 of 202 CCEB-94/084 - Version 0.9 94/10/31 ATE_FUN.5.8E The evaluator will perform an independent assessment of the characterization of discovered flaws as either design or implementation flaws. ATE_FUN.5.9E The evaluator shall review the justification. ATE_FUN.6 Formal specifications Objectives and threats 136 Test plans are generated from formal interface specifications. This provides a much closer linkage to the high-level design and thus, greater assurance that the behavior of the TSF is as required. Testing demonstrates that the TSF implementation is consistent with the formal specification. Testing and analysis demonstrates that no design flaws and no more than a few correctable implementation flaws are present, and that there is reasonable confidence that few remain. Application notes Dependencies: The TSF interface must be specified The TSF security policy must be specified The test documentation shall be under configuration management The Formal Interface specifications and formal policy model(s) shall be under configuration management Test tools shall be under configuration management Process dependencies (e.g., formal proofs, spec-to-code mappings) A formal interface specification has been produced and its conformance with the formal policy model has been verified using formal methods. Penetration Testing (EPT-n). Developer action elements: ATE_FUN.6.1D The developer shall test all the TSF interfaces to demonstrate that each functions in accordance with the formal interface specifications. ATE_FUN.6.2D The developer shall show that the test coverage is complete; that each of the TSF interfaces is being tested. ATE_FUN.6.3D The developer shall test the boundary conditions of the security functions to demonstrate that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.6.4D The developer shall correct all flaws discovered by testing and retest the TSF until the protection functions are shown to work as claimed. D R A F T Tests ATE_FUN - Functional tests 94/10/31 CCEB-94/084 - Version 0.9 Page 79 of 202 ATE_FUN.6.5D The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. ATE_FUN.6.6D All flaws identified discovered during testing will either be corrected or neutralized. The TOE shall be retested to determine that all discovered flaws have been eliminated and that no new flaws have been introduced. ATE_FUN.6.7D All flaws discovered during testing shall be analyzed and characterized as either errors of design or implementation. No design flaws and no more than a few correctable implementation flaws may be found during testing. ATE_FUN.6.8D The developer shall produce the Test Documentation. The Test Documentation shall include a library of test programs that contains test programs and tools. Content and presentation of evidence elements: ATE_FUN.6.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_FUN.6.2C The test plan shall identify the functions to be tested and describe the tests to be performed. The tests shall exercise the boundary conditions of the security functions. The developer shall show that the test coverage is complete; that each of the TSF interfaces is being tested. Test cases shall be generated from the formal interface specifications. The test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. ATE_FUN.6.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_FUN.6.4C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. ATE_FUN.6.5C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and as defined in the interface description or specification , and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. ATE_FUN.6.6C The test results shall demonstrate that all identified errors have been neutralized or eliminated and that no new errors have been introduced. ATE_FUN.6.7C All flaws discovered during testing shall be analyzed and characterized as either errors of design or implementation. No design flaws and no more than a few correctable implementation flaws may be found during testing. ATE_FUN.6.8C The evidence shall provide justification .....................TBD D R A F T ATE_COV - Coverage Tests Page 80 of 202 CCEB-94/084 - Version 0.9 94/10/31 Evaluator action elements: ATE_FUN.6.1E The evaluator shall review the test plan for coverage. At least one test must exist for each user-visible TSF function specified in the protection profile or security target. ATE_FUN.6.2E The evaluator shall review that the test cases and test data are consistent with the semi-formal or formal interface specification. ATE_FUN.6.3E The evaluator shall review to see that the boundary conditions of the security functions are tested. ATE_FUN.6.4E The evaluator shall review the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_FUN.6.5E The evaluator shall review the test results to determine that the testing shows that the TSF functions as specified in the protection profile or security target and that the TSF can be expected to behave as specified regardless of input values. ATE_FUN.6.6E The evaluators shall use the developer's library of test programs and tools to check the developer testing via sampling. ATE_FUN.6.7E The test results shall be checked to determine that previously- discovered flaws are no longer present. ATE_FUN.6.8E The evaluator will perform an independent assessment of the characterization of discovered flaws as either design or implementation flaws ATE_COV Coverage Objectives 137 This family addresses those aspects of testing that deal with completeness and sufficiency of testing. That is, it addresses the extent to which all TSFs are tested, whether or not the testing is sufficiently extensive to demonstrate that the TSFs function as specified, and whether or not the order in which testing proceeds correctly accounts for functional dependencies (i.e., "uses" dependencies) between the elements being tested. Threats 138 The threats addressed by this family of components are largely the same as those identified under ATE_FUN, namely those associated with incorrect implementation of the specifications or the substitution of code that is compliant with the specifications with code that is non-compliant. The degree to which these threats are countered is dependent upon the completeness and sufficiency of the testing coverage. D R A F T Tests ATE_COV - Coverage 94/10/31 CCEB-94/084 - Version 0.9 Page 81 of 202 Component levelling 139 The components in this family are levelled on the basis of the coverage of the testing. The first level requires only that each TSF is tested, the second level requires some reasonable evidence that the testing is sufficient to demonstrate that testing fully exercises the entire behavior defined by the design specifications, and the third level requires some proof that testing is structured such as to avoid circular arguments about the correctness of the elements being tested. Application notes 140 The specific documentation required by the coverage components will be determined, in most cases, by those called out in the level of ATE_FUN that is specified. However, the developer of the PP or ST will need to give consideration to the proper set of test evidence and documentation required. ATE_COV.1 Complete coverage Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_COV.1.1D The developer shall, when required 1 , provide an analysis of the test coverage. Content and presentation of evidence elements: ATE_COV.1.1C The analysis of the test coverage shall demonstrate that testing covers all TSFs; that there is at least one test for each TSF. Evaluator action elements: ATE_COV.1.1E The evaluator shall check the test documentation for coverage. At least one test must exist for each user-visible TSF function specified in the protection profile or security target. 1. Note that the first level of Functional Testing (i.e., ATE_FUN.1) does not require the developer to perform testing. Thus, whether or not the developer is required to provide test documentation or evidence of testing is determined by which level of ATE_FUN is part of the assurance requirements. This implies that any evidence required by ATE_COV would be developed by the evaluator. D R A F T ATE_COV - Coverage Tests Page 82 of 202 CCEB-94/084 - Version 0.9 94/10/31 ATE_COV.2 Test sufficiency Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_COV.2.1D The developer shall, when required, provide a convincing argument (i.e., informal) that the test coverage is complete. Content and presentation of evidence elements: ATE_COV.2.1C The analysis of the test coverage shall demonstrate that testing covers all TSFs; that there is at least one test for each TSF. ATE_COV.2.2C The analysis of the test documentation shall show the correspondence between the TSFs and the tests. ATE_COV.2.3C The analysis of the test coverage shall show that the testing is sufficient to demonstrate that each TSF functions as defined in the functional specifications. Evaluator action elements: ATE_COV.2.1E The evaluator shall review the test documentation for coverage. At least one test must exist for each user-visible TSF function specified in the protection profile or security target. ATE_COV.2.2E The evaluator shall review that the test coverage is sufficient to demonstrate that the functional specifications have been completely exercised by the test suite. ATE_COV.3 Ordered testing Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_COV.3.1D The developer shall, when required, provide a justification (i.e., supported by detailed analysis) that the test coverage is complete. D R A F T Tests ATE_IND - Independent testing 94/10/31 CCEB-94/084 - Version 0.9 Page 83 of 202 ATE_COV.3.2D The developer shall, when required, provide a justification that the order of testing is consistent with any functional dependencies that exist between the elements being tested. Content and presentation of evidence elements: ATE_COV.3.1C The analysis of the test coverage shall demonstrate that testing covers all TSFs; that there is at least one test for each TSF ATE_COV.3.2C The analysis of the test documentation shall show the correspondence between the TSFs and the tests. ATE_COV.3.3C The analysis of the test coverage shall show that the testing is sufficient to demonstrate that each TSF functions as defined in the functional specifications. ATE_COV.3.4C The analysis of the testing shall demonstrate that elements that presume the correctness of other elements are not tested until the correctness of the supporting elements have first been established. ATE_COV.3.5C The evidence shall provide justification .....................TBD Evaluator action elements: ATE_COV.3.1E The evaluator shall review the test documentation for coverage. At least one test must exist for each user-visible TSF function specified in the protection profile or security target. ATE_COV.3.2E The evaluator shall determine that the test coverage is sufficient to demonstrate that the functional specifications have been completely exercised by the test suite. ATE_COV.3.3E The evaluator shall determine that the order in which elements have been tested properly accounts for the dependencies between the elements. ATE_COV.3.4E The evaluator shall review the justification. ATE_IND Independent testing Objectives 141 This family deals with the degree to which there is independent, usually evaluator, testing of the TOE. Independent testing may take the form of repeating the developer's tests, in whole or in part. It may also take the form of the augmentation of the developer's tests, either to exercise elements of the TOE not exercised by the developer's testing or to extend the coverage of the developer's testing. D R A F T ATE_IND - Independent testing Tests Page 84 of 202 CCEB-94/084 - Version 0.9 94/10/31 Threats 142 The threats countered by the components of this family are those associated with the risk that incomplete testing or an incorrect assessment of the test outcomes on the part of the developer results in the incorrect implementation of the specifications, or the overlooking of code that is non compliant with the specifications. Component levelling 143 TBD Application notes 144 The specific documentation required by the coverage components will be determined, in most cases, by those called out in the level of ATE_FUN that is specified. However, the developer of the PP or ST will need to give consideration to the proper set of test evidence and documentation required. ATE_IND.1 Third Party Testing Objectives and threats 145 At this level, it is acceptable to have testing performed by a party other than either the developer or the evaluator (e.g., an independent laboratory, an objective consumer advocate). It is required that the testing confirm the results claimed by the developer, with the evaluator being free to replicate any desired tests. Application notes Dependencies: TBD. Developer action elements: ATE_IND.1.1D The developer shall, when required 1 , produce the test documentation. Content and presentation of evidence elements: ATE_IND.1.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_IND.1.2C The test plan shall identify the functions to be tested and describe the tests to be performed. 1. Note that the first level of Functional Testing (i.e., ATE_FUN.1) does not require the developer to perform testing. Thus, whether or not the developer is required to provide test documentation or evidence of testing is determined by which level of ATE_FUN is part of the assurance requirements. This implies that any evidence required by ATE_IND would be developed by the evaluator. D R A F T Tests ATE_IND - Independent testing 94/10/31 CCEB-94/084 - Version 0.9 Page 85 of 202 ATE_IND.1.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_IND.1.4C The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target. Evaluator action elements: ATE_IND.1.1E The evaluator shall check the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_IND.1.2E The evaluator shall check the test results to determine that the testing shows that the TSF functions as specified in the TOE documentation. ATE_IND.1.3E The evaluator shall base his analysis on the testing of an agent who is not the developer if applicable. ATE_IND.1.4E The evaluator shall selectively confirm any test result through his own testing if applicable. ATE_IND.2 Evaluator Confirmation Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_IND.2.1D The developer shall, when required, produce the test documentation. Content and presentation of evidence elements: ATE_IND.2.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_IND.2.2C The test plan shall identify the functions to be tested and describe the tests to be performed. ATE_IND.2.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_IND.2.4C The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target . D R A F T ATE_IND - Independent testing Tests Page 86 of 202 CCEB-94/084 - Version 0.9 94/10/31 Evaluator action elements: ATE_IND.2.1E The evaluator shall review the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_IND.2.2E The evaluator shall review the test results to determine that the testing shows that the TSF functions as specified in the TOE documentation. ATE_IND.2.3E The evaluator shall base his analysis on the testing of an agent who is not the developer if applicable. ATE_IND.2.4E The evaluator shall selectively confirm any test result through his own testing if applicable. ATE_IND.2.5E The evaluator shall perform independent testing. Testing may be selective and shall be based upon all available documentation and interface specifications. ATE_IND.3 Formal Specification Testing Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_IND.3.1D The developer shall, when required, produce the test documentation. Content and presentation of evidence elements: ATE_IND.3.1C The documentation shall consist of test plans, test procedure description, and the test results. ATE_IND.3.2C The test plan shall identify the functions to be tested and describe the tests to be performed. ATE_IND.3.3C The test procedure description shall provide instructions for using test programs and test suites. ATE_IND.3.4C The test results shall show the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target . ATE_IND.3.5C The evidence shall provide justification .....................TBD D R A F T Tests ATE_DPT - Depth 94/10/31 CCEB-94/084 - Version 0.9 Page 87 of 202 Evaluator action elements: ATE_IND.3.1E The evaluator shall review the test procedure description to determine that there is a procedure described for each test identified in the test plan. ATE_IND.3.2E The evaluator shall review the test results to determine that the testing shows that the TSF functions as specified in the TOE documentation. ATE_IND.3.3E The evaluator shall base his analysis on the testing of an agent who is not the developer if applicable. ATE_IND.3.4E The evaluator shall selectively confirm any test result through his own testing if applicable. ATE_IND.3.5E The evaluator shall perform independent testing. Testing may be selective and shall be based upon all available documentation and formal interface specifications. ATE_IND.3.6E The evaluator shall review the justification. ATE_DPT Depth Objectives 146 These components in this family deal with the level of detail to which the TOE is tested. Testing of security functions is seen to take place largely at three levels of detail; the user-visible interface to the security functions, the primary functional elements (e.g., I&A, Audit), and at the level of individual modules. Threats 147 The threats addressed are those that are associated with the risk of missing an error in the development of low-level design detail and final implementation. Additionally, the components of this family, especially as testing is more concerned with the internals of the TOE, are more likely to discover any malicious code that has been inserted. Component levelling 148 The components are levelled essentially in the order of the level of testing detail defined in the previous paragraph. Application notes 149 The specific amount and type of documentation and evidence will, in general, be determined by that required by level of ATE_FUN selected. However, when a PP or an ST is being specified, it will be necessary to pay close attention to these evidence requirements. D R A F T ATE_DPT - Depth Tests Page 88 of 202 CCEB-94/084 - Version 0.9 94/10/31 ATE_DPT.1 Interface testing Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_DPT.1.1E The developer shall, when required 1 , produce the test documentation. Content and presentation of evidence elements: ATE_DPT.1.1C The test documentation shall describe the test plans, test procedures, and test results directed to demonstrating that all protection functions work as claimed in the interface description or specification. ATE_DPT.1.2C The test documentation shall show the correspondence between the interface specifications and the test results; it shall demonstrate that the implementation is consistent with the interface specifications . Evaluator action elements: ATE_DPT.1.1E The evaluator shall check whether the protection properties of the TOE, as described in the interface description or specification work as claimed. ATE_DPT.2 Function testing Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_DPT.2.1E The developer shall, when required, provide test documentation . 1. Note that the first level of Functional Testing (i.e., ATE_FUN.1) does not require the developer to perform testing. Thus, whether or not the developer is required to provide test documentation or evidence of testing is determined by which level of ATE_FUN is part of the assurance requirements. This implies that any evidence required by ATE_DPT would be developed by the evaluator. D R A F T Tests ATE_DPT - Depth 94/10/31 CCEB-94/084 - Version 0.9 Page 89 of 202 Content and presentation of evidence elements: ATE_DPT.2.1C The test documentation shall describe the test plans, test procedures, and test results directed to demonstrating that all protection functions work as claimed in the interface description or specification. ATE_DPT.2.2C The test documentation shall show the correspondence between the interface specifications and the test results; it shall demonstrate that the implementation is consistent with the interface specifications. ATE_DPT.2.3C The test documentation shall provide the test plans, test procedures, and test results for all protection functions (e.g., I&A, Audit) of the TOE. Evaluator action elements: ATE_DPT.2.1E The evaluator shall review whether the protection properties of the TOE, as described in the interface description or specification work as claimed. ATE_DPT.2.2E The evaluator shall review that the protection functions of the TOE work as defined in their individual descriptions or specifications. ATE_DPT.3 Module testing Objectives and threats Application notes Dependencies: TBD. Developer action elements: ATE_DPT.3.1E The developer shall, when required, provide test documentation . Content and presentation of evidence elements: ATE_DPT.3.1C The test documentation shall describe the test plans, test procedures, and test results directed to demonstrating that all protection functions work as claimed in the interface description or specification. ATE_DPT.3.2C The test documentation shall show the correspondence between the interface specifications and the test results; it shall demonstrate that the implementation is consistent with the interface specifications. ATE_DPT.3.3C The test documentation shall provide the test plans, test procedures, and test results for all protection functions (e.g., I&A, Audit) of the TOE. ATE_DPT.3.4C The test documentation shall provide the test plans, test procedures, and test results for all protection-relevant modules of the TOE. D R A F T ATE_DPT - Depth Tests Page 90 of 202 CCEB-94/084 - Version 0.9 94/10/31 ATE_DPT.3.5C The evidence shall provide justification .....................TBD Evaluator action elements: ATE_DPT.3.1E The evaluator shall review whether the protection properties of the TOE, as described in the interface description or specification work as claimed. ATE_DPT.3.2E The evaluator shall review that the protection functions of the TOE work as defined in their individual descriptions or specifications. ATE_DPT.3.3E The evaluator shall review whether the protection-relevant modules are implemented as defined by their descriptions or specifications. ATE_DPT.3.4E The evaluator shall review the justification. D R A F T CCEB-94/084 94/10/31 Version 0.9 Page 91 of 202 Class AVA Vulnerability assessment 150 Figure 2.3 shows the families within this class, and the hierarchy of components within the families.. VULNERABILITY ASSESSMENT | | - AVA_VLA - 1 - 2 - 3 - 4 - 5 | | - AVA_CCA - 1 - 2 - 3 | | - AVA_MSU - 1 - 2 - 3 | | - AVA_SOF - 1 - 2 Figure 2.3 - Vulnerability assessment class decomposition D R A F T AVA_VLA - Vulnerability analysis Vulnerability assessment Page 92 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_VLA Vulnerability analysis Objectives 151 Penetration testing is performed to discover design and implementation errors that will allow users to bypass the intended security policy and perform unauthorised operations. Threats 152 Penetration testing deals with the threats that a malicious user will be able to discover flaws that will allow access to unauthorised resources (e.g., data) or resources, allow the ability to interfere with or alter the TSF, or interfere with the authorised capabilities of other users. Component levelling Application notes AVA_VLA.1 Obvious flaws Objectives and threats 153 Testing is performed to ascertain the presence of "obvious" flaws. Obvious flaws are those that allow common attacks or those that might be suggested by the TOE interface description. They are flaws related attacks that are deemed to require a minimum of skill, technical sophistication, and resources. Application notes Dependencies: No dependencies. Developer action elements: AVA_VLA.1.1D The developer shall perform a test searching for obvious ways in which an unauthorised user can bypass or otherwise defeat the TSF. Content and presentation of evidence elements: AVA_VLA.1.1C The documentation shall consist of test plans, test procedure description, and the test results. AVA_VLA.1.2C The test plan shall describe the tests to be performed. AVA_VLA.1.3C The test results shall show the results of each test. D R A F T Vulnerability assessment AVA_VLA - Vulnerability analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 93 of 202 Evaluator action elements: AVA_VLA.1.1E The evaluator shall check the test plan for reasonableness. AVA_VLA.2 Serious flaws Objectives and threats 154 Testing is extended to search for "serious" flaws that would allow violation of resource isolation, or would permit unauthorised access to the audit or authentication data. These are flaws related attacks that would require a familiarity with the architecture of the TOE and a reasonable level of technical understanding on the part of the attacker. Application notes Dependencies: No dependencies. Developer action elements: AVA_VLA.2.1D The developer shall perform a test searching for obvious ways in which an unauthorised user can bypass or otherwise defeat the TSF. AVA_VLA.2.2D The developer shall perform a test searching for obvious flaws that would allow violation of resource isolation or that would permit unauthorised access to the audit or authentication data. Content and presentation of evidence elements: AVA_VLA.2.1C The documentation shall consist of test plans, test procedure description, and the test results. AVA_VLA.2.2C The test plan shall describe the tests to be performed. AVA_VLA.2.3C The test results shall show the results of each test. AVA_VLA.2.4C The developer shall provide recommendations for corrective action in case of attacks that result in a violation of resource isolation or access to TSF internal data. Evaluator action elements: AVA_VLA.2.1E The evaluator shall check the test plan for reasonableness. AVA_VLA.2.2E The evaluator shall check the developer's test plan and test results. AVA_VLA.2.3E The evaluator shall check any recommendations for corrective action. D R A F T AVA_VLA - Vulnerability analysis Vulnerability assessment Page 94 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_VLA.2.4E The evaluator shall conduct independent testing if applicable. AVA_VLA.3 Flaw removal Objectives and threats 155 Testing based on detailed technical information and the attacker is presumed to be thoroughly familiar with the specific implementation of the TOE. All discovered flaws are to be removed or neutralised, and the TSF retested to demonstrate that new flaws have not been introduced. Objectives and threats Dependencies: No dependencies. Developer action elements: AVA_VLA.3.1D The developer shall perform a test searching for obvious ways in which an unauthorised user can bypass or otherwise defeat the TSF. AVA_VLA.3.2D The developer shall perform a test searching for obvious flaws that would allow violation of resource isolation or that would permit unauthorised access to the audit or authentication data. AVA_VLA.3.3D The developer shall assemble a team of individuals who thoroughly understand the specific implementation of the TSF. AVA_VLA.3.4D The developer shall produce available design documentation, source code, and object code. AVA_VLA.3.5D A test team shall subject the design documentation, source code, and object code to thorough analysis and testing. Their objective shall be to uncover all design and implementation flaws that would permit an untrusted subject to read, change, or delete data normally denied under the security policies, or that would cause the TOE to enter a state such that it is unable to respond to communications initiated by other users. AVA_VLA.3.6D The developer shall identify for each test the goal of the test and the criteria for success. AVA_VLA.3.7D The developer shall define the TSF configuration, interface, and protection functions that are subject to penetration tests. AVA_VLA.3.8D The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. D R A F T Vulnerability assessment AVA_VLA - Vulnerability analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 95 of 202 AVA_VLA.3.9D The developer shall remove or neutralise all flaws discovered, and shall retest the TSF to demonstrate that the flaws have been eliminated and new flaws have not been introduced. Content and presentation of evidence elements: AVA_VLA.3.1C The documentation shall consist of test plans, test procedure description, and the test results. The documentation shall also include design documentation, source code, and object code. AVA_VLA.3.2C The test plan shall describe the tests to be performed. AVA_VLA.3.3C The test results shall show the results of each test. AVA_VLA.3.4C The developer shall provide recommendations for corrective action in case of attacks that result in a violation of resource isolation or access to TSF internal data. AVA_VLA.3.5C The test evidence shall identify all product documentation upon which the search for flaws was based. AVA_VLA.3.6C The penetration evidence shall describe the scenarios for exploiting each potential flaw and the penetration conditions, data (e.g., test setup, function call parameters, and test outcomes), coverage, and conclusions derived from each scenario. AVA_VLA.3.7C The test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. AVA_VLA.3.8C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. AVA_VLA.3.9C The test results shall describe the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. Evaluator action elements: AVA_VLA.3.1E The evaluator shall review the test plan for reasonableness. AVA_VLA.3.2E The evaluator shall review the developer's test plan and test result AVA_VLA.3.3E The evaluator shall review any recommendations for corrective action. AVA_VLA.3.4E The evaluator shall conduct independent testing if applicable . AVA_VLA.3.5E The evaluator shall review the test team's analysis. D R A F T AVA_VLA - Vulnerability analysis Vulnerability assessment Page 96 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_VLA.3.6E The evaluator shall review the test results to determine that previously discovered flaws are no longer present and that any discovered flaws have been corrected. AVA_VLA.4 Flaw hypothesis Objectives and threats 156 Rigorous and thorough analytic techniques are employed to discover even subtle flaws that would require sophisticated attackers with considerable resources. Application notes Dependencies: No dependencies. Developer action elements: AVA_VLA.4.1D The developer shall perform a test searching for obvious ways in which an unauthorised user can bypass or otherwise defeat the TSF. AVA_VLA.4.2D The developer shall perform a test searching for obvious flaws that would allow violation of resource isolation or that would permit unauthorised access to the audit or authentication data. AVA_VLA.4.3D The developer shall assemble a team of individuals who thoroughly understand the specific implementation of the TSF. AVA_VLA.4.4D The developer shall produce available design documentation, source code, and object code. AVA_VLA.4.5D A test team shall subject the design documentation, source code, and object code to thorough analysis and testing. Their objective shall be to uncover all design and implementation flaws that would permit an untrusted subject to read, change, or delete data normally denied under the security policies, or that would cause the TOE to enter a state such that it is unable to respond to communications initiated by other users. AVA_VLA.4.6D The developer shall identify for each test the goal of the test and the criteria for success. AVA_VLA.4.7D The developer shall define the TSF configuration, interface, and protection functions that are subject to penetration tests. AVA_VLA.4.8D The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. D R A F T Vulnerability assessment AVA_VLA - Vulnerability analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 97 of 202 AVA_VLA.4.9D The developer shall remove or neutralise all flaws discovered, and shall retest the TSF to demonstrate that the flaws have been eliminated and new flaws have not been introduced. AVA_VLA.4.10D The developer shall describe how, in addition to system reference manuals and the TSF interface description, the semiformal or formal interface specifications, and the hardware and firmware specifications are used to define penetration test conditions, data, test outcomes, and coverage. AVA_VLA.4.11D The developer shall generate the test conditions from flaw hypotheses. AVA_VLA.4.12D The developer shall confirm flaw hypotheses by checking design and implementation documentation, by defining the test data and running test programs, or by referring to the know classes of penetration flaws. AVA_VLA.4.13D The developer shall describe all flaw hypotheses that have been refuted. AVA_VLA.4.14D The developer shall describe for each discovered flaw scenarios for exploitation, and shall identify all penetration outcomes resulting from the scenarios. AVA_VLA.4.15D The developer shall document the cause of each flaw. Content and presentation of evidence elements: AVA_VLA.4.1C The documentation shall consist of test plans, test procedure description, and the test results. The documentation shall also include design documentation, source code, and object code. AVA_VLA.4.2C The test plan shall describe the tests to be performed. AVA_VLA.4.3C The test results shall show the results of each test. AVA_VLA.4.4C The developer shall provide recommendations for corrective action in case of attacks that result in a violation of resource isolation or access to TSF internal data. AVA_VLA.4.5C The test evidence shall identify all product documentation upon which the search for flaws was based. AVA_VLA.4.6C The penetration evidence shall describe the scenarios for exploiting each potential flaw and the penetration conditions, data (e.g., test setup, function call parameters, and test outcomes), coverage, and conclusions derived from each scenario, and shall summarise both refuted and confirmed flaw hypotheses . AVA_VLA.4.7C The test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. The test results shall demonstrate that the TSF is relatively resistant to penetration. AVA_VLA.4.8C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. D R A F T AVA_VLA - Vulnerability analysis Vulnerability assessment Page 98 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_VLA.4.9C The test results shall describe the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. Evaluator action elements: AVA_VLA.4.1E The evaluator shall review the test plan for reasonableness. AVA_VLA.4.2E The evaluator shall review the developer's test plan and test results. AVA_VLA.4.3E The evaluator shall review any recommendations for corrective action. AVA_VLA.4.4E The evaluator shall conduct independent testing if applicable. AVA_VLA.4.5E The evaluator shall review the test team's analysis. AVA_VLA.4.6E The evaluator shall review the test results to determine that previously-discovered flaws are no longer present and that any discovered flaws have been corrected. AVA_VLA.4.7E The evaluator shall review the developer's flaw hypotheses. AVA_VLA.4.8E The evaluator shall perform additional independent analysis and testing. AVA_VLA.5 Penetration resistance Objectives and threats 157 At this level the TSF must be shown to be resistant to penetration attacks. This means that it is unlikely that a sophisticated attacker with access to considerable technical detail on the TSF will be able to find exploitable flaws. Application notes Dependencies: No dependencies. Developer action elements: AVA_VLA.5.1D The developer shall perform a test searching for obvious ways in which an unauthorised user can bypass or otherwise defeat the TSF. AVA_VLA.5.2D The developer shall perform a test searching for obvious flaws that would allow violation of resource isolation or that would permit unauthorised access to the audit or authentication data. AVA_VLA.5.3D The developer shall assemble a team of individuals who thoroughly understand the specific implementation of the TSF. D R A F T Vulnerability assessment AVA_VLA - Vulnerability analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 99 of 202 AVA_VLA.5.4D The developer shall produce available design documentation, source code, and object code. AVA_VLA.5.5D A test team shall subject the design documentation, source code, and object code to thorough analysis and testing. Their objective shall be to uncover all design and implementation flaws that would permit an untrusted subject to read, change, or delete data normally denied under the security policies, or that would cause the TOE to enter a state such that it is unable to respond to communications initiated by other users. AVA_VLA.5.6D The developer shall identify for each test the goal of the test and the criteria for success. AVA_VLA.5.7D The developer shall define the TSF configuration, interface, and protection functions that are subject to penetration tests. AVA_VLA.5.8D The developer shall demonstrate that previously discovered security flaws in the TSF have been removed. AVA_VLA.5.9D The developer shall remove or neutralise all flaws discovered, and shall retest the TSF to demonstrate that the flaws have been eliminated and new flaws have not been introduced. AVA_VLA.5.10D The developer shall describe how, in addition to system reference manuals and the TSF interface description, the semiformal or formal interface specifications, and the hardware and firmware specifications are used to define penetration test conditions, data, test outcomes, and coverage. AVA_VLA.5.11D The developer shall generate the test conditions from flaw hypotheses. AVA_VLA.5.12D The developer shall confirm flaw hypotheses by checking design and implementation documentation, by defining the test data and running test programs, or by referring to the know classes of penetration flaws. AVA_VLA.5.13D The developer shall describe all flaw hypotheses that have been refuted. AVA_VLA.5.14D The developer shall describe for each discovered flaw scenarios for exploitation, and shall identify all penetration outcomes resulting from the scenarios. AVA_VLA.5.15D The developer shall document the cause of each flaw. AVA_VLA.5.16D The developer shall derive penetration-resistance properties and conditions by interpreting reference mediation and protection requirements of the TSF. AVA_VLA.5.17D The developer shall verify that the penetration- resistance conditions are implemented by the TSF. D R A F T AVA_VLA - Vulnerability analysis Vulnerability assessment Page 100 of 202 CCEB-94/084 - Version 0.9 94/10/31 Content and presentation of evidence elements: AVA_VLA.5.1C The documentation shall consist of test plans, test procedure description, and the test results. The documentation shall also include design documentation, source code, and object code. AVA_VLA.5.2C The test plan shall describe the tests to be performed. AVA_VLA.5.3C The test results shall show the results of each test. AVA_VLA.5.4C The developer shall provide recommendations for corrective action in case of attacks that result in a violation of resource isolation or access to TSF internal data. AVA_VLA.5.5C The test evidence shall identify all product documentation upon which the search for flaws was based. AVA_VLA.5.6C The penetration evidence shall describe the scenarios for exploiting each potential flaw and the penetration conditions, data (e.g., test setup, function call parameters, and test outcomes), coverage, and conclusions derived from each scenario, and shall summarise both refuted and confirmed flaw hypotheses. AVA_VLA.5.7C The test plan shall include tests that attempt to exercise flaws discovered in previous versions of the TSF. The test results shall demonstrate that the TSF is relatively resistant to penetration. AVA_VLA.5.8C The test procedures shall include tests to demonstrate the absence of all flaws discovered in previous versions of the TSF. AVA_VLA.5.9C The test results shall describe the output of each test. These results shall demonstrate that the TSF functions as specified in the protection profile or the security target and that the TSF continues to exhibit the specified security behaviour even when presented with unusual or undefined inputs. AVA_VLA.5.10C The evidences shall provide justification ................. TBD. Evaluator action elements: AVA_VLA.5.1E The evaluator shall review the test plan for reasonableness. AVA_VLA.5.2E The evaluator shall review the developer's test plan and test results. AVA_VLA.5.3E The evaluator shall review any recommendations for corrective action AVA_VLA.5.4E The evaluator shall conduct independent testing if applicable. AVA_VLA.5.5E The evaluator shall review the test team's analysis. AVA_VLA.5.6E The evaluator shall review the test results to determine that previously-discovered flaws are no longer present and that any discovered flaws have been corrected. D R A F T Vulnerability assessment AVA_CCA - Covert channel analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 101 of 202 AVA_VLA.5.7E The evaluator shall review the developer's flaw hypotheses. AVA_VLA.5.8E The evaluator shall perform additional independent analysis and testing. AVA_VLA.5.9E The evaluator shall review the justification. AVA_CCA Covert channel analysis Objectives 158 Covert channel analysis is carried out to determine the existence and potential bandwidth of unintended signalling channels that may be exploited by malicious code (i.e., a "Trojan Horse"). Both storage channels and timing channels are addressed. Threats AVA_CCA.0.1E These requirements address the threat that unintended and exploitable signalling paths exist which may be exercised by a "Trojan Horse" to circumvent the protection policy. Component levelling Application notes AVA_CCA.1 Storage channel analysis Objectives and threats 159 At this level the scope of the analysis is covert storage channels which are identifiable through analysis of informal interface specifications and TOE reference manuals. The bandwidth estimations are based upon informal engineering measurements. 160 The requirements at this level address threats of the exploitation of covert channels that exist as a result of exception conditions (e.g., error returns) that are processed by the TSF. Application notes Dependencies: Information flow policy (e.g., mandatory access control) Developer action elements: AVA_CCA.1.1D The developer shall conduct a search for covert storage channels using at least the informal interface specifications and reference manuals for TOE. D R A F T AVA_CCA - Covert channel analysis Vulnerability assessment Page 102 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_CCA.1.2D The developer shall define the method used for the identification of covert storage channels. AVA_CCA.1.3D The developer shall demonstrate that the chosen method is exhaustive (i.e., that it identifies all covert storage channels) and that it leads to repeatable results. AVA_CCA.1.4D The developer shall define the method for estimating the bandwidth of covert storage channels. AVA_CCA.1.5D The developer shall document the results of the analysis, showing the channels discovered, the maximum bandwidth estimations for each, scenarios for exploitation, and disposition (e.g., reduction, elimination, auditing). AVA_CCA.1.6D The developer shall test all covert storage channel TSFs that have been implemented in the TOE to demonstrate that they work as intended. Content and presentation of evidence elements: AVA_CCA.1.1C All the material used in searching for covert storage channels (i.e., minimally, the informal interface specifications and the reference manuals) shall be made available. AVA_CCA.1.2C The method used for the identification of covert storage channels shall be documented to describe the procedures used for determining the existence of covert storage channels and the information needed to carry out the analysis. The documentation shall also identify all assumptions upon which the analysis or measurement is based, such as processor speed, configuration, memory and cache size AVA_CCA.1.3C All covert storage channels discovered shall be identified and the method(s) of exploitation shall be described. AVA_CCA.1.4C The method used for estimating bandwidth shall describe how the computations are performed. AVA_CCA.1.5C The results of the analysis shall identify each of the discovered channels, describe the possible scenarios of exploitation, justify the bandwidth estimates, and provide justification for the proposed disposition (e.g., retain but audit) of each covert storage channel or class of channels. AVA_CCA.1.6C Test plans, test procedure description, and test results shall be provided for all covert storage channel TSFs. Evaluator action elements: AVA_CCA.1.1E The evaluator shall check the method proposed for the identification of covert storage channels to determine that it is exhaustive and yields repeatable results. D R A F T Vulnerability assessment AVA_CCA - Covert channel analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 103 of 202 AVA_CCA.1.2E The evaluator shall check the test plans and test descriptions determine that there is a procedure shown for each covert channel TSF. AVA_CCA.1.3E The evaluator shall check that testing demonstrates that the covert channel TSFs work as intended. AVA_CCA.1.4E The evaluator shall check the bandwidth estimates to determine that they are reasonable. AVA_CCA.1.5E The evaluator shall check the proposals for the disposition of the channels to determine if they are consistent with the assumptions for the usage and environment of the TOE. AVA_CCA.2 Timing channel analysis Objectives and threats 161 At this level the search for covert timing channels is included. As a consequence the scope of the sources is enlarged to include processor and hardware specifications. Additionally, some subset of the discovered channels must be selected and their bandwidths measured rather than only estimated. These measurements provide a check on the validity of the method of estimation. 162 The requirements at this level address threats of the exploitation of covert channels that exist as a result of exception conditions (e.g., error returns) that are processed by the TSF and those that can be exercised because of the ability for user processes to sense time differences in the response to system calls. Application notes Dependencies: Information flow policy (e.g., mandatory access control) Developer action elements: AVA_CCA.2.1D The developer shall conduct a search for covert storage and timing channels using at least the informal interface specifications and reference manuals for the TOE. Processor specifications shall be used whenever the method of identification includes source code or hardware analysis. AVA_CCA.2.2D The developer shall define the method used for the identification of all covert channels . AVA_CCA.2.3D The developer shall demonstrate that the chosen method is exhaustive (i.e., that it identifies all covert channels ) and that it leads to repeatable results. AVA_CCA.2.4D The developer shall define the method for estimating the bandwidth of all covert channels. D R A F T AVA_CCA - Covert channel analysis Vulnerability assessment Page 104 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_CCA.2.5D The developer shall document the results of the analysis, showing the channels discovered, the maximum bandwidth estimations for each, scenarios for exploitation, and disposition (e.g., reduction, elimination, auditing). AVA_CCA.2.6D The developer shall test all covert channel TSFs that have been implemented in the TOE to demonstrate that they work as intended. AVA_CCA.2.7D The developer shall select TSF primitives to be measured for bandwidth determination. The bandwidths measured through testing shall be compared to the estimates and any significant discrepancies shall be explained. Content and presentation of evidence elements: AVA_CCA.2.1C All the material used in searching for all covert channels (i.e., minimally, the informal interface specifications and the reference manuals) shall be made available. AVA_CCA.2.2C The method used for the identification of all covert channels shall be documented to describe the procedures used for determining the existence of all covert channels and the information needed to carry out the analysis. The documentation shall also identify all assumptions upon which the analysis or measurement is based, such as processor speed, configuration, memory and cache size. The documentation of covert channels includes the variables, timing sources, and the TSF interface functions that can be used to transmit information. AVA_CCA.2.3C All covert channels discovered shall be identified and the method(s) of exploitation shall be described. AVA_CCA.2.4C The method used for estimating bandwidth shall describe how the computations are performed. AVA_CCA.2.5C The results of the analysis shall identify each of the discovered channels, describe the possible scenarios of exploitation, justify the bandwidth estimates, and provide justification for the proposed disposition (e.g., retain but audit) of each covert channel or class of channels. AVA_CCA.2.6C Test plans, test procedure description, and test results shall be provided for all covert channel TSFs. AVA_CCA.2.7C The criteria for selecting the channels to be measured shall be documented. The results of the tests shall describe the test parameters (e.g., processor speed, memory and cache size, relevant configuration parameters, how the channel was exercised) and provide the bandwidths derived from testing. Discrepancies between the estimates of bandwidth and the measured bandwidths shall be described. Evaluator action elements: AVA_CCA.2.1E The evaluator shall review the method proposed for the identification of all covert channels to determine that it is exhaustive and yields repeatable results. D R A F T Vulnerability assessment AVA_CCA - Covert channel analysis 94/10/31 CCEB-94/084 - Version 0.9 Page 105 of 202 AVA_CCA.2.2E The evaluator shall review the test plans and test descriptions determine that there is a procedure shown for each covert channel TSF. AVA_CCA.2.3E The evaluator shall review that testing demonstrates that the covert channel TSFs work as intended. AVA_CCA.2.4E The evaluator shall review the bandwidth estimates to determine that they are reasonable. AVA_CCA.2.5E The evaluator shall review the proposals for the disposition of the channels to determine if they are consistent with the assumptions for the usage and environment of the TOE. AVA_CCA.2.6E The evaluator shall review the criteria proposed for the selection of channels to be measured by testing. AVA_CCA.2.7E The evaluator shall review to see that channels selected are representative and significant. AVA_CCA.2.8E The evaluator shall review that the estimates are reasonable predictors of bandwidths determined through testing. AVA_CCA.3 Formal covert channel analysis Objectives and threats 163 At this level the precision and coverage of analysis is extended by requiring the use of formal interface specifications and "specification- to-code" correspondence tracing. 164 The requirements at this level address threats of the exploitation of covert channels that exist as a result of exception conditions (e.g., error returns) that are processed by the TSF and those that can be exercised because of the ability for user processes to sense time differences in the response to system calls. Application notes Dependencies: ADV_FSP.4 Formal security policy model ADV_TIS.4 Formal TSF interface specification Information flow policy (e.g., mandatory access control) Specification to code correspondence. Developer action elements: AVA_CCA.3.1D The developer shall conduct a search for covert storage and timing channels using at least the formal interface specifications and reference manuals for the TSF. The identification of covert channels shall include the evidence available in the D R A F T AVA_CCA - Covert channel analysis Vulnerability assessment Page 106 of 202 CCEB-94/084 - Version 0.9 94/10/31 specification-to-code correspondence. Processor specifications shall be used whenever the method of identification includes source code or hardware analysis. AVA_CCA.3.2D The developer shall define the method used for the identification of all covert channels. AVA_CCA.3.3D The developer shall demonstrate that the chosen method is exhaustive (i.e., that it identifies all covert channels) and that it leads to repeatable results. AVA_CCA.3.4D The developer shall define the method for estimating the bandwidth of all covert channels. AVA_CCA.3.5D The developer shall document the results of the analysis, showing the channels discovered, the maximum bandwidth estimations for each, scenarios for exploitation, and disposition (e.g., reduction, elimination, auditing). AVA_CCA.3.6D The developer shall test all covert channel TSFs that have been implemented in the TOE to demonstrate that they work as intended. AVA_CCA.3.7D The developer shall select TSF primitives to be measured for bandwidth determination. The bandwidths measured through testing shall be compared to the estimates and any significant discrepancies shall be explained. Content and presentation of evidence elements: AVA_CCA.3.1C All the material used in searching for all covert channels (i.e., minimally, the informal interface specifications and the reference manuals) shall be made available. AVA_CCA.3.2C The method used for the identification of all covert channels shall be documented to describe the procedures used for determining the existence of all covert channels and the information needed to carry out the analysis. The documentation shall also identify all assumptions upon which the analysis or measurement is based, such as processor speed, configuration, memory and cache size. The documentation of covert channels includes the variables, timing sources, and the TSF interface functions that can be used to transmit information. AVA_CCA.3.3C All covert channels discovered shall be identified and the method(s) of exploitation shall be described. AVA_CCA.3.4C The method used for estimating bandwidth shall describe how the computations are performed. AVA_CCA.3.5C The results of the analysis shall identify each of the discovered channels, describe the possible scenarios of exploitation, justify the bandwidth estimates, and provide justification for the proposed disposition (e.g., retain but audit) of each covert channel or class of channels. AVA_CCA.3.6C Test plans, test procedure description, and test results shall be provided for all covert channel TSFs. D R A F T Vulnerability assessment AVA_MSU - Misuse 94/10/31 CCEB-94/084 - Version 0.9 Page 107 of 202 AVA_CCA.3.7C The criteria for selecting the channels to be measured shall be documented. The results of the tests shall describe the test parameters (e.g., processor speed, memory and cache size, relevant configuration parameters, how the channel was exercised) and provide the bandwidths derived from testing. Discrepancies between the estimates of bandwidth and the measured bandwidths shall be explained. AVA_CCA.3.8C The evidence shall provide justification ....................TBD. Evaluator action elements: AVA_CCA.3.1E The evaluator shall review the method proposed for the identification of all covert channels to determine that it is exhaustive and yields repeatable results. AVA_CCA.3.2E The evaluator shall review the test plans and test descriptions determine that there is a procedure shown for each covert channel TSF. AVA_CCA.3.3E The evaluator shall review that testing demonstrates that the covert channel TSFs work as intended. AVA_CCA.3.4E The evaluator shall review the bandwidth estimates to determine that they are reasonable. AVA_CCA.3.5E The evaluator shall review the proposals for the disposition of the channels to determine if they are consistent with the assumptions for the usage and environment of the TOE. AVA_CCA.3.6E The evaluator shall review the criteria proposed for the selection of channels to be measured by testing. AVA_CCA.3.7E The evaluator shall review to see that channels selected are representative and significant. AVA_CCA.3.8E The evaluator shall review that the estimates are reasonable predictors of bandwidths determined through testing. AVA_CCA.3.9E The evaluator shall review the justification. AVA_MSU Misuse Objectives 165 This aspect investigates whether the TOE can be configured or used in a manner which is insecure but which an administrator or end-user of the TOE would reasonably believe to be secure. D R A F T AVA_MSU - Misuse Vulnerability assessment Page 108 of 202 CCEB-94/084 - Version 0.9 94/10/31 Threats 166 Human or other errors in operation may deactivate or disable security functions. It may be possible to configure or install the TOE in a way which is insecure, without the end user or administrator being able to recognise it. Component levelling Application notes AVA_MSU.1 Statement of misuse analysis Objectives and threats 167 A pretended status of security misleads the administrator or end user of the TOE. 168 This component deals with simple activities intended to delude the authorised user of the TOE. Application notes Dependencies: No dependencies. Developer action elements: AVA_MSU.1.1D The developer shall provide a misuse analysis, which identifies possible modes of operation of the TOE, including operation following failure or operational error, their consequences and implications for maintaining secure operation. Content and presentation of evidence elements: AVA_MSU.1.1C The misuse analysis shall describe that any human or other error in operation that deactivates or disables the TSF will be easily detectable. AVA_MSU.1.2C The misuse analysis shall describe if it is possible to configure or cause the TOE to be used in a way which is insecure (i.e. the TSF of the TOE do not satisfy the security target), when an end-user or administrator of the TOE would reasonably believe it to be secure, then this fact will also be detectable. Evaluator action elements: AVA_MSU.1.1E The evaluator shall check that the misuse analysis provided meets all requirements for content and presentation of evidence. AVA_MSU.1.2E The evaluator shall check the analysis for undocumented or unreasonable assumptions about the intended environment. D R A F T Vulnerability assessment AVA_MSU - Misuse 94/10/31 CCEB-94/084 - Version 0.9 Page 109 of 202 AVA_MSU.1.3E The evaluator shall check that all assumptions and requirements for external security measures (such as external procedural, physical and personnel controls) have been appropriately documented. AVA_MSU.1.4E The evaluator shall repeat any configuration and installation procedure to check that the TOE can be configured and used securely, using only the user and administration documentation for guidance. AVA_MSU.1.5E The evaluator shall perform other testing where necessary to confirm or disprove the misuse analysis. AVA_MSU.2 Description of misuse analysis Objectives and threats 169 This component deals with detailed activities intended to delude the authorised user of the TOE. Application notes Dependencies: No dependencies. Developer action elements: AVA_MSU.2.1D The developer shall provide a misuse analysis, which identifies possible modes of operation of the TOE, including operation following failure or operational error, their consequences and implications for maintaining secure operation. Content and presentation of evidence elements: AVA_MSU.2.1C The misuse analysis shall describe that any human or other error in operation that deactivates or disables the TSF will be easily detectable. AVA_MSU.2.2C The misuse analysis shall describe if it is possible to configure or cause the TOE to be used in a way which is insecure (i.e. the TSF of the TOE do not satisfy the security target), when an end-user or administrator of the TOE would reasonably believe it to be secure, then this fact will also be detectable. Evaluator action elements: AVA_MSU.2.1E The evaluator shall review that the misuse analysis provided meets all requirements for content and presentation of evidence. AVA_MSU.2.2E The evaluator shall review the analysis for undocumented or unreasonable assumptions about the intended environment. D R A F T AVA_MSU - Misuse Vulnerability assessment Page 110 of 202 CCEB-94/084 - Version 0.9 94/10/31 AVA_MSU.2.3E The evaluator shall review that all assumptions and requirements for external security measures (such as external procedural, physical and personnel controls) have been appropriately documented. AVA_MSU.2.4E The evaluator shall repeat any configuration and installation procedure to review that the TOE can be configured and used securely, using only the user and administration documentation for guidance. AVA_MSU.2.5E The evaluator shall perform other testing where necessary to confirm or disprove the misuse analysis. AVA_MSU.3 Explanation of misuse analysis Objectives and threats 170 This component deals with elaborate activities intended to delude the authorised user of the TOE. Application notes Dependencies: No dependencies. Developer action elements: AVA_MSU.3.1D The developer shall provide a misuse analysis, which identifies possible modes of operation of the TOE, including operation following failure or operational error, their consequences and implications for maintaining secure operation. Content and presentation of evidence elements: AVA_MSU.3.1C The misuse analysis shall describe that any human or other error in operation that deactivates or disables the TSF will be easily detectable. AVA_MSU.3.2C The misuse analysis shall describe if it is possible to configure or cause the TOE to be used in a way which is insecure (i.e. the TSF of the TOE do not satisfy the security target), when an end-user or administrator of the TOE would reasonably believe it to be secure, then this fact will also be detectable. AVA_MSU.3.3C The evidence shall provide justification ....................TBD. Evaluator action elements: AVA_MSU.3.1E The evaluator shall review that the misuse analysis provided meets all requirements for content and presentation of evidence. AVA_MSU.3.2E The evaluator shall review the analysis for undocumented or unreasonable assumptions about the intended environment. D R A F T Vulnerability assessment AVA_SOF - Strength of TOE security functions 94/10/31 CCEB-94/084 - Version 0.9 Page 111 of 202 AVA_MSU.3.3E The evaluator shall review that all assumptions and requirements for external security measures (such as external procedural, physical and personnel controls) have been appropriately documented. AVA_MSU.3.4E The evaluator shall repeat any configuration and installation procedure to verify that the TOE can be configured and used securely, using only the user and administration documentation for guidance. AVA_MSU.3.5E The evaluator shall perform other testing where necessary to confirm or disprove the misuse analysis. AVA_MSU.3.6E The evaluator shall review the justification. AVA_SOF Strength of TOE security functions Objectives 171 Even if a TOE security function cannot be bypassed, deactivated, corrupted, or circumvented, it may still be possible to defeat it because there is a potential vulnerability in its algorithm, principles or properties. For those functions a quantitative or statistical analysis of the security behaviour is meaningful. For any of these functions a claim of strength of TOE security function can be made. Threats 172 If security functions with a potential vulnerability in their algorithm, principles or properties are not carefully analysed whether they are suitable for the identified threat intensity, the TOE could be attacked successfully. Component levelling 173 The family is levelled by 2 components one of which represents the situation where a claim of strength of TOE security function is not meaningful for any security function. The other component contains requirements for the evaluation of strength of TOE security functions for all functions for which such a claim is being made by the developer. Application notes User notes 174 The evaluation of cryptographic functions is subject to special regulations in some organisations applying these criteria. AVA_SOF.1 No claims for strength of TOE security functions Objectives and threats 175 TBD D R A F T AVA_SOF - Strength of TOE security functions Vulnerability assessment Page 112 of 202 CCEB-94/084 - Version 0.9 94/10/31 Application notes Dependencies: No dependencies. Developer action elements: AVA_SOF.1.1D The developer shall list all TOE security functions. Content and presentation of evidence elements: AVA_SOF.1.1C For all listed functions it shall be shown that they do not possess a potential vulnerability in their algorithm, principles or properties. Evaluator action elements: AVA_SOF.1.1E The evaluator shall check that the analysis of the TOE security functions provided meets all requirements for content and presentation of the evidence. AVA_SOF.1.2E The evaluator shall check this analysis for consistency and completeness. AVA_SOF.2 Strength of TOE security functions claim Objectives and threats 176 TBD Application notes Dependencies: No dependencies. Developer action elements: AVA_SOF.2.1D The developer shall list all security functions with a potential vulnerability in their algorithm, principles or properties for which he has made a strength of TOE security function claim. Content and presentation of evidence elements: AVA_SOF.2.1C For all listed security functions a strength of TOE security function analysis shall be provided. AVA_SOF.2.2C The analysis shall show that the relevant threats for each listed security function match with the claimed category for that function. AVA_SOF.2.3C For each function for which the claim is 'suitable for use in a category C threat environment' the analysis shall show that the function provides protection D R A F T Vulnerability assessment AVA_SOF - Strength of TOE security functions 94/10/31 CCEB-94/084 - Version 0.9 Page 113 of 202 against unintended or casual breach of TOE security by attackers possessing a low level of expertise, opportunities, resources, and motivation. AVA_SOF.2.4C For each function for which the claim is 'suitable for use in a category B threat environment' the analysis shall show that the function provides protection against attackers possessing a moderate level of expertise, opportunities, resources, and motivation. AVA_SOF.2.5C For each function for which the claim is 'suitable for use in a category A threat environment' the analysis shall show that the function provides protection against attackers possessing a high level of expertise, opportunities, resources, and motivation. Evaluator action elements: AVA_SOF.2.1E The evaluator shall check that the strength of function analysis provided meets all requirements for content and presentation of the evidence. AVA_SOF.2.2E The evaluator shall check the analysis for consistency and completeness. D R A F T AVA_SOF - Strength of TOE security functions Vulnerability assessment Page 114 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T CCEB-94/084 94/10/31 Version 0.9 Page 115 of 202 Class ACM Configuration management 177 Configuration management is an aspect of establishing that the functional requirements and specifications are realised in the implementation. It does this through applying some discipline and control to the processes of refinement and modification of the TSF. Even in its minimal form, configuration management provides the consumer a measure of confidence that the TOE that they are operating represents the same product as the one that was evaluated, and thus has the properties asserted by the evaluators. ACM_AUT Configuration management automation Objectives 178 Tool based configuration management systems ensure the consistency and integrity of the configuration items they control. In addition, they ensure that only authorised users are capable of making changes to configuration items. Threats 179 Configuration management automation primarily deals with threats of accidental or deliberate unauthorised modifications of configuration items during the entire life cycle of the TOE. 180 A non tool based source code configuration management system may be bypassed, ignored, or be insufficient to prevent unauthorised modifications or inconsistencies. 181 A non tool based configuration management system may be bypassed, ignored, or be insufficient to prevent unauthorised modifications or inconsistencies. Component levelling Application notes ACM_AUT.1 Partial CM automation Objectives and threats 182 Source code is often difficult to maintain under a non tool based configuration management system because of the number of developers working on the source code and of the quantity of source code present in most TOEs. In addition, source code often undergoes numerous changes during development. A tool based source D R A F T ACM_AUT - Configuration management automation Configuration management Page 116 of 202 CCEB-94/084 - Version 0.9 94/10/31 code configuration management system ensures the consistency and integrity of the source code and that only authorised users are capable of making any changes. 183 No more detail information about threats at this level. Application notes Dependencies: No dependencies. Developer action elements: ACM_AUT.1.1D The developer shall use an automated configuration management system to ensure that only authorised changes are made to the following configuration items: source and object code of the TSF. ACM_AUT.1.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_AUT.1.1C The configuration management documentation shall consist of a configuration management plan. ACM_AUT.1.2C The configuration management plan shall describe the automated configuration management system. ACM_AUT.1.3C The configuration management plan shall describe how the automated configuration management system is used to control changes to these configuration items. Evaluator action elements: ACM_AUT.1.1E The evaluator shall check that the automated configuration management system is capable of controlling changes to these configuration items. ACM_AUT.1.2E The evaluator shall check that the automated configuration management system is being used to control changes to these configuration items. ACM_AUT.2 Complete CM automation Objectives and threats 184 For the same reasons mentioned above, it is often preferable to maintain all configuration items under a tool based configuration management system. 185 No more detail information about threats at this level. D R A F T Configuration management ACM_SCP - Configuration management scope 94/10/31 CCEB-94/084 - Version 0.9 Page 117 of 202 Application notes Dependencies: No dependencies. Developer action elements: ACM_AUT.2.1D The developer shall use an automated configuration management system to ensure that only authorised changes are made to all configuration items. ACM_AUT.2.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_AUT.2.1C The configuration management documentation shall consist of a configuration management plan. ACM_AUT.2.2C The configuration management plan shall describe the automated configuration management system. ACM_AUT.2.3C The configuration management plan shall describe how the automated configuration management system is used to control changes to all configuration items. Evaluator action elements: ACM_AUT.2.1E The evaluator shall check that the automated configuration management system is capable of controlling changes to all configuration items. ACM_AUT.2.2E The evaluator shall check that the automated configuration management system is being used to control changes to all configuration items. ACM_SCP Configuration management scope Objectives 186 The scope of items that are controlled by a configuration management (CM)system directly affects the confidence that those items are consistent, have not been accidentally modified, and have not been deliberately modified by unauthorised users. The state of those items that are not under configuration management is unknown. Threats 187 Configuration management scope primarily deals with threats of inconsistencies, accidental modification, or deliberate unauthorised modifications of items that are not being controlled under configuration management. D R A F T ACM_SCP - Configuration management scope Configuration management Page 118 of 202 CCEB-94/084 - Version 0.9 94/10/31 188 The threat of an accidental or unauthorised modification of a configuration item is countered by this family. 189 The threat of introducing inconsistencies between the multiple levels of abstraction of the TOE is countered by this family. 190 The threat that flaws reported during development or operation will remain in the TOE because the flaw reports were either lost or forgotten is countered by this family. 191 The threat that a wrong version of the compiler is used, the wrong options are provided to the compiler, or a modified compiler is used to generate the object code from the source code is countered by this family. 192 The threat of unauthorised modification of or an inconsistency between the tools supporting the development of the TSF is countered by this family. Component levelling Application Notes ACM_SCP.1 Minimal CM coverage Objectives and threats 193 A configuration management system can only control changes to those items that have been placed under configuration management. At a minimum, the TOE design, code, and tests must be placed under configuration management. 194 No more detail information about threats at this level. Component levelling Dependencies: ACM_CAP.2 Consistency and authorisation controls Developer action elements: ACM_SCP.1.1D The developer shall maintain the following configuration items under a configuration management system: design documentation, source code, object code, and test documentation. ACM_SCP.1.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_SCP.1.1C The configuration management documentation shall show that all of the configuration items are maintained under a configuration management system. D R A F T Configuration management ACM_SCP - Configuration management scope 94/10/31 CCEB-94/084 - Version 0.9 Page 119 of 202 Evaluator action elements: ACM_SCP.1.1E The evaluator shall check that all of the configuration items are maintained under the configuration management system. ACM_SCP.2 Moderate CM coverage Objectives and threats 195 The TOE hardware and firmware should also be placed under configuration management. At this level, changes to the entire TOE are controlled by the configuration management system. 196 No more detail information about threats at this level. Application notes Dependencies: ACM_CAP.2 Consistency and authorisation controls Developer action elements: ACM_SCP.2.1D The developer shall maintain the following configuration items under a configuration management system: design documentation, source code, object code, test documentation , hardware, and firmware . ACM_SCP.2.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_SCP.2.1C The configuration management documentation shall show that all of the configuration items are maintained under a configuration management system. Evaluator action elements: ACM_SCP.2.1E The evaluator shall check that all of the configuration items are maintained under the configuration management system. ACM_SCP.3 Problem tracking CM coverage Objectives and threats 197 The ability to maintain flaws under configuration management ensures that flaw reports are not lost or forgotten and allows a developer to track flaws to their resolutions. 198 No more detail information about threats at this level. D R A F T ACM_SCP - Configuration management scope Configuration management Page 120 of 202 CCEB-94/084 - Version 0.9 94/10/31 Application notes Dependencies: ACM_CAP.2 Consistency and authorisation controls Developer action elements: ACM_SCP.3.1D The developer shall maintain the following configuration items under a configuration management system: design documentation, source code, object code, test documentation, hardware, firmware, and flaws . ACM_SCP.3.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_SCP.3.1C The configuration management documentation shall show that all of the configuration items are maintained under a configuration management system. Evaluator action elements: ACM_SCP.3.1E The evaluator shall check that all of the configuration items are maintained under the configuration management system. ACM_SCP.4 Compiler CM coverage Objectives and threats 199 One completely automated part of TOE development is the translation of source code into machine code (or object code). As such, it is very important that the correct version of the compiler be used, that the correct options be given to the compiler, and that an unmodified version of the compiler be used. 200 No more detail information about threats at this level. 201 The following additional threats are countered by this assurance component: 202 The wrong version of the compiler is used, the wrong options are provided to the compiler, or a modified compiler is used to generate the object code from the source code. Application notes Dependencies: ACM_CAP.2 Consistency and authorisation controls D R A F T Configuration management ACM_SCP - Configuration management scope 94/10/31 CCEB-94/084 - Version 0.9 Page 121 of 202 Developer action elements: ACM_SCP.4.1D The developer shall maintain the following configuration items under a configuration management system: design documentation, source code, object code, test documentation, hardware, firmware, flaws, and compilers . ACM_SCP.4.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_SCP.4.1C The configuration management documentation shall show that all of the configuration items are maintained under a configuration management system. Evaluator action elements: ACM_SCP.4.1E The evaluator shall check that all of the configuration items are maintained under the configuration management system. ACM_SCP.5 Development tools CM coverage Objectives and threats 203 Tools used in the development of the TOE play an important role in ensuring the production of a quality version of the TSF. Therefore, it is equally important to control modifications to these tools and to ensure that the tools used are consistent. 204 No more detail information about threats at this level. Component levelling Dependencies: ACM_CAP.2 Consistency and authorisation controls Developer action elements: ACM_SCP.5.1D The developer shall maintain the following configuration items under a configuration management system: design documentation, source code, object code, test documentation, hardware, firmware, flaws , and development tools (including compilers). ACM_SCP.5.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_SCP.5.1C The configuration management documentation shall show that all of the configuration items are maintained under a configuration management system. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 122 of 202 CCEB-94/084 - Version 0.9 94/10/31 Evaluator action elements: ACM_SCP.5.1E The evaluator shall check that all of the configuration items are maintained under the configuration management system. ACM_CAP Configuration management capabilities Objectives 205 The capabilities of the configuration management system affects the likelihood that accidental or deliberate unauthorised modifications of the configuration items will occur. The configuration management ensure the consistency of configuration items, generate the TSF, audit changes, and protect the master copy of the TSF. As tools to control changes to configuration items are introduced, the more likely that the functional requirements and specification are realised in the implementation. Threats 206 Configuration management capabilities primarily deals with threats of accidental or deliberate unauthorised modifications of configuration items during the entire life cycle of the TOE. 207 The threat that an incorrect or incomplete version of the TOE is delivered to a purchaser is countered by this family. 208 The threat that an item of the TOE is excluded from the evaluation is countered by this family. 209 The threat of unauthorised modification of a TOE configuration item is countered by this family. 210 The threat of introducing inconsistencies between the multiple levels of abstraction of the TOE is countered by this family. 211 The threat that flaws will remain in previous but still supported versions of the TOE due to the inability to regenerate those versions of the TOE is countered by this family. 212 The threat that TSF configuration items which have been modified may contain intentional or unintentional errors and may be included as part of the TOE unless adequately acceptance procedures are in place is countered by this family. 213 The threat that the generation of the new TSF uses older and outdated source code files is countered by this family. 214 The threat that a new version of a TSF contains changes that should not have been made is countered by this family. D R A F T Configuration management ACM_CAP - Configuration management capabilities 94/10/31 CCEB-94/084 - Version 0.9 Page 123 of 202 215 The threat that unauthorised modification or destruction of the material used to generated the TSF is countered by this family. Component levelling Application Notes ACM_CAP.1 Minimal support Objectives and threats 216 This assurance component permits the identification of the configuration items of the TOE. Clear identification of the TOE is required to determine those items under evaluation that are subject to the criteria requirements. In addition, configuration lists can be used to ensure that the TOE delivered is identical to the evaluated TOE. 217 No more detail information about threats at this level. Application notes Dependencies: No dependencies. Developer action elements: ACM_CAP.1.1D The developer shall maintain a configuration list for the TOE. ACM_CAP.1.2D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.1.1C The configuration management documentation shall consist of a configuration list. ACM_CAP.1.2C The configuration list shall state the configuration items that comprise the TOE. ACM_CAP.1.3C The configuration list shall state the method used to uniquely identify the TOE items. Evaluator action elements: ACM_CAP.1.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 124 of 202 CCEB-94/084 - Version 0.9 94/10/31 ACM_CAP.2 Consistency and authorisation controls Objectives and threats 218 Modifications to the TOE are controllable so that only authorised changes are made to the TOE and so that consistency can be maintained between the multiple levels of abstraction of the TOE. 219 No more detail information about threats at this level. Application notes Dependencies: No dependencies. Developer action elements: ACM_CAP.2.1D The developer shall develop a configuration management plan. ACM_CAP.2.2D The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.2.3D The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. ACM_CAP.2.4D The developer shall maintain a configuration list for the TOE. ACM_CAP.2.5D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.2.1C The configuration management documentation shall consist of a configuration list and a configuration management plan. ACM_CAP.2.2C The configuration list shall state the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. ACM_CAP.2.3C The configuration list shall state the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.2.4C The configuration management plan shall state how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. Evaluator action elements: ACM_CAP.2.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence. D R A F T Configuration management ACM_CAP - Configuration management capabilities 94/10/31 CCEB-94/084 - Version 0.9 Page 125 of 202 ACM_CAP.2.2E The evaluator shall check that the procedures outlined in the configuration management plan are being applied. ACM_CAP.3 Regeneration support Objectives and threats 220 The ability to regenerate previous but still supported versions of the TOE is necessary for the resolution of any new flaws discovered during operation. 221 No more detail information about threats at this level. Application notes Dependencies: No dependencies. Developer action elements: ACM_CAP.3.1D The developer shall develop a configuration management plan. ACM_CAP.3.2D The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.3.3D The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. ACM_CAP.3.4D The developer shall use a configuration management system that permits the regeneration of any supported version of the TOE. ACM_CAP.3.5D The developer shall maintain a configuration list for the TOE. ACM_CAP.3.6D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.3.1C The configuration management documentation shall consist of a configuration list and a configuration management plan. ACM_CAP.3.2C The configuration list shall state the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. ACM_CAP.3.3C The configuration list shall state the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.3.4C The configuration management plan shall state how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 126 of 202 CCEB-94/084 - Version 0.9 94/10/31 Evaluator action elements: ACM_CAP.3.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence. ACM_CAP.3.2E The evaluator shall check that the procedures outlined in the configuration management plan are being applied. ACM_CAP.4 Acceptance procedures Objectives and threats 222 Acceptance procedures ensure that changes made to TSF configuration items are adequately and appropriately reviewed such that the changes will not affect the security properties of the TOE. 223 No more detail information about threats at this level. Application notes Dependencies: No dependencies. Developer action elements: ACM_CAP.4.1D The developer shall develop a configuration management plan. ACM_CAP.4.2D The developer shall develop an acceptance plan. ACM_CAP.4.3D The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.4.4D The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. ACM_CAP.4.5D The developer shall use a configuration management system that permits the regeneration of any supported version of the TOE. ACM_CAP.4.6D The developer shall maintain a configuration list for the TOE. ACM_CAP.4.7D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.4.1C The configuration management documentation shall consist of a configuration list, a configuration management plan, and an acceptance plan. ACM_CAP.4.2C The configuration list shall describe the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. D R A F T Configuration management ACM_CAP - Configuration management capabilities 94/10/31 CCEB-94/084 - Version 0.9 Page 127 of 202 ACM_CAP.4.3C The configuration list shall describe the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.4.4C The configuration management plan shall describe how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. ACM_CAP.4.5C The acceptance plan shall describe the procedures used to accept modified or newly created TSF configuration items as part of the TOE. Evaluator action elements: ACM_CAP.4.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of evidence. ACM_CAP.4.2E The evaluator shall review that the procedures outlined in the configuration management plan are being applied. ACM_CAP.4.3E The evaluator shall review that the procedures outlined in the acceptance plan are being applied. ACM_CAP.5 Generation and comparison support Objectives and threats 224 The configuration management system should support the generation of a new TSF from source code to ensure that all of the correct source code files are being used. In addition, it should allow the comparison of newly generated TSF with the previous TSF. This is a method for determining the changes that have been made to the TSF and ensuring that only the desired changes have indeed been made. 225 No more detail information about threats at this level. Application notes Dependencies: ACM_AUT.1 Partial CM automation Developer action elements: ACM_CAP.5.1D The developer shall develop a configuration management plan. ACM_CAP.5.2D The developer shall develop an acceptance plan. ACM_CAP.5.3D The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.5.4D The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 128 of 202 CCEB-94/084 - Version 0.9 94/10/31 ACM_CAP.5.5D The developer shall use a configuration management system that permits the generation of a new version of the TSF from source code. ACM_CAP.5.6D The developer shall use a configuration management system that permits the comparison of a newly generated version with the previous TSF version to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TSF. ACM_CAP.5.7D The developer shall use a configuration management system that permits the regeneration of any supported version of the TOE. ACM_CAP.5.8D The developer shall maintain a configuration list for the TOE. ACM_CAP.5.9D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.5.1C The configuration management documentation shall consist of a configuration list, a configuration management plan, and an acceptance plan. ACM_CAP.5.2C The configuration list shall describe the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. ACM_CAP.5.3C The configuration list shall describe the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.5.4C The configuration management plan shall describe how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. ACM_CAP.5.5C The acceptance plan shall describe the procedures used to accept modified or newly created TSF configuration items as part of the TOE. Evaluator action elements: ACM_CAP.5.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of evidence. ACM_CAP.5.2E The evaluator shall review that the procedures outlined in the configuration management plan are being applied. ACM_CAP.5.3E The evaluator shall review that the procedures outlined in the acceptance plan are being applied. ACM_CAP.6 Advanced support Objectives and threats 226 The additional tool requirements ensures that a rich set of tools is available for performing daily tasks sufficiently and adequately. Integration procedures ensure D R A F T Configuration management ACM_CAP - Configuration management capabilities 94/10/31 CCEB-94/084 - Version 0.9 Page 129 of 202 that the introduction of modifications into the TSF is performed in a controlled, consistent, and complete manner. 227 No more detail information about threats at this level. Application notes Dependencies: ACM_AUT.1 Partial CM automation Developer action elements: ACM_CAP.6.1D The developer shall develop a configuration management plan. ACM_CAP.6.2D The developer shall develop an acceptance plan. ACM_CAP.6.3D The developer shall develop integration procedures. ACM_CAP.6.4D The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.6.5D The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. ACM_CAP.6.6D The developer shall use a configuration management system that permits the generation of a new version of the TSF from source code. ACM_CAP.6.7D The developer shall use a configuration management system that permits the comparison of a newly generated version with the previous TSF version to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TSF. ACM_CAP.6.8D The developer shall use a configuration management system that ensures that the person responsible for acceptance of a configuration item into configuration management is not one of the TOE designers or developers. ACM_CAP.6.9D The developer shall use a configuration management system that permits clear identification of the TSF. ACM_CAP.6.10D The developer shall use a configuration management system capable of identifying all other configuration items that are affected by the modification of a given configuration item. ACM_CAP.6.11D The developer shall use a configuration management system that supports the audit of all modifications to the TSF and that includes the originator, date, and time in the audit trail. ACM_CAP.6.12D The developer shall use a configuration management system that permits the regeneration of any supported version of the TOE. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 130 of 202 CCEB-94/084 - Version 0.9 94/10/31 ACM_CAP.6.13D The developer shall maintain a configuration list for the TOE. ACM_CAP.6.14D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.6.1C The configuration management documentation shall consist of a configuration list, a configuration management plan, an acceptance plan, and integration procedures. ACM_CAP.6.2C The configuration list shall describe the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. ACM_CAP.6.3C The configuration list shall describe the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.6.4C The configuration management plan shall describe how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. ACM_CAP.6.5C The acceptance plan shall describe the procedures used to accept modified or newly created TSF configuration items as part of the TOE. ACM_CAP.6.6C The integration procedures shall describe how they are applied in the manufacturing process in accordance with the quality management procedures. ACM_CAP.6.7C Example audit trail output from the configuration control system shall be provided. ACM_CAP.6.8C The evidence shall provide justification .....................TBD Evaluator action elements: ACM_CAP.6.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of evidence. ACM_CAP.6.2E The evaluator shall review that the procedures outlined in the configuration management plan are being applied. ACM_CAP.6.3E The evaluator shall review that the procedures outlined in the acceptance plan are being applied. ACM_CAP.6.4E The evaluator shall review that the procedures outlined in the integration procedures are being applied. ACM_CAP.6.5E The evaluator shall review the example audit trail output. ACM_CAP.6.6E The evaluator shall review the justification. D R A F T Configuration management ACM_CAP - Configuration management capabilities 94/10/31 CCEB-94/084 - Version 0.9 Page 131 of 202 ACM_CAP.7 Protection of master copies Objectives and threats 228 Although a configuration management system attempts to control the unauthorised modification of configuration items, it may be possible to destroy or modify the material used to generate the TSF in other ways. Technical, physical, and procedural safeguards can help preserve the master copy or copies of the material used to generate the TSF. 229 No more detail information about threats at this level. Application notes Dependencies: ACM_AUT.1 Partial CM automation Developer action elements: ACM_CAP.7.1D The developer shall develop a configuration management plan. ACM_CAP.7.2D The developer shall develop an acceptance plan. ACM_CAP.7.3D The developer shall develop integration procedures. ACM_CAP.7.4D The developer shall use a configuration management system to ensure that only authorised changes are made to the TOE configuration items. ACM_CAP.7.5D The developer shall use a configuration management system to ensure that consistency is maintained between the multiple levels of TOE abstractions. ACM_CAP.7.6D The developer shall use a configuration management system that permits the generation of a new version of the TSF from source code. ACM_CAP.7.7D The developer shall use a configuration management system that permits the comparison of a newly generated version with the previous TSF version to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TSF. ACM_CAP.7.8D The developer shall use a configuration management system that ensures that the person responsible for acceptance of a configuration item into configuration management is not one of the TOE designers or developers. ACM_CAP.7.9D The developer shall use a configuration management system that permits clear identification of the TSF. ACM_CAP.7.10D The developer shall use a configuration management system capable of identifying all other configuration items that are affected by the modification of a given configuration item. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 132 of 202 CCEB-94/084 - Version 0.9 94/10/31 ACM_CAP.7.11D The developer shall use a configuration management system that supports the audit of all modifications to the TSF and that includes the originator, date, and time in the audit trail. ACM_CAP.7.12D The developer shall use a configuration management system that permits the regeneration of any supported version of the TOE. ACM_CAP.7.13D The developer shall use a combination of technical, physical, and procedural safeguards to protect the master copy or copies of all material used to generate the TSF from unauthorised modification or destruction. ACM_CAP.7.14D The developer shall maintain a configuration list for the TOE. ACM_CAP.7.15D The developer shall produce configuration management documentation. Content and presentation of evidence elements: ACM_CAP.7.1C The configuration management documentation shall consist of a configuration list, a configuration management plan, an acceptance plan, and integration procedures. ACM_CAP.7.2C The configuration list shall describe the configuration items that comprise the TOE and those items fundamental to the generation of the TOE. ACM_CAP.7.3C The configuration list shall describe the method used to uniquely identify the TOE items. References to configuration items shall use these unique identifiers. ACM_CAP.7.4C The configuration management plan shall describe how the configuration management system is used in practice and how it is applied in the manufacturing process in accordance with quality management procedures. ACM_CAP.7.5C The acceptance plan shall describe the procedures used to accept modified or newly created TSF configuration items as part of the TOE. ACM_CAP.7.6C The integration procedures shall describe how they are applied in the manufacturing process in accordance with the quality management procedures. ACM_CAP.7.7C Example audit trail output from the configuration control system shall be provided. ACM_CAP.7.8C The evidence shall provide justification ..TBD ACM_CAP.7.9C The technical, physical, and procedural safeguards used to protect the master copy or copies of all material used to generate the TSF shall be described . Evaluator action elements: ACM_CAP.7.1E The evaluator shall review that the information provided meets all requirements for the content and presentation of evidence. ACM_CAP.7.2E The evaluator shall review that the procedures outlined in the configuration management plan are being applied. D R A F T Configuration management ACM_CAP - Configuration management capabilities 94/10/31 CCEB-94/084 - Version 0.9 Page 133 of 202 ACM_CAP.7.3E The evaluator shall review that the procedures outlined in the acceptance plan are being applied. ACM_CAP.7.4E The evaluator shall review that the procedures outlined in the integration procedures are being applied. ACM_CAP.7.5E The evaluator shall review the example audit trail output. ACM_CAP.7.6E The evaluator shall review the justification. D R A F T ACM_CAP - Configuration management capabilities Configuration management Page 134 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T CCEB-94/084 94/10/31 Version 0.9 Page 135 of 202 Class ALC Life-cycle support 230 Figure 2.4 shows the families within this class, and the hierarchy of components within the families. LIFE-CYCLE SUPPORT | | - ALC_LCD - 1 - 2 - 3 | | - ALC_FLR - 1 - 2 - 3 - 4 | | - ALC_TAT - 1 - 2 - 3 - 4 | | - ALC_DVS - 1 - 2 - 3 Figure 2.4 - Life-cycle support class decomposition D R A F T ALC_LCD - Life-cycle definition Life-cycle support Page 136 of 202 CCEB-94/084 - Version 0.9 94/10/31 231 232 Life-cycle support is an aspect of establishing some discipline and control to the processes of refinement and modification of the TSF during development and maintenance. Confidence in the correspondence between the TOE requirements and the TCB is greater when security analysis and the production of evidence are done on a regular basis as an integral part of the development and maintenance activities. ALC_LCD Life-cycle definition Objectives 233 Ad-hoc development and maintenance can result in a flawed implementation of a TOE or a TOE that does not meet all of the security functional requirements. Therefore, it is important that a process for the development and maintenance of a TOE be established as early in the TOE's life-cycle as possible. 234 Using a process for the development and maintenance of a TOE does not necessarily imply that the TOE will not be flawed or that the TOE will meet all of its security functional requirements. It is possible that the process chosen was insufficient or inadequate and therefore no improvement in the quality of the TOE could be observed. Using an engineering process that has achieved acceptance by some group of experts (e.g., academic experts, standards bodies) reduces the chances that the development and maintenance processes will not contribute to the overall quality of the TOE. Threats 235 Life-cycle definition primarily deals with threats of exploiting flaws in a low quality TOE due to ad-hoc development and maintenance of the TOE. It also deals with threats of exploiting flaws in a low quality TOE due to an insufficient or inadequate development and maintenance process. 236 The following threats are countered by this assurance component: 237 Security flaws caused by a lack of quality in the TOE are exploited. 238 Security functional requirements are not met by the TOE which results in security violations. D R A F T Life-cycle support ALC_LCD - Life-cycle definition 94/10/31 CCEB-94/084 - Version 0.9 Page 137 of 202 Component levelling Application notes ALC_LCD.1 Developer defined life-cycle process Objectives and threats 239 Discipline and control may be enforced during refinement and modification of the TSF by requiring that all developers follow a defined set of processes to develop and maintain the TOE. 240 The following threats are countered by this assurance component: 241 Security flaws caused by a lack of quality in the TOE are exploited. 242 Security functional requirements are not met by the TOE which results in security violations. Application notes Dependencies: No dependencies. Developer action elements: ALC_LCD.1.1D The developer shall establish a life-cycle process to be used in the development and maintenance of the TOE. ALC_LCD.1.2D The developer shall produce life-cycle definition documentation. Content and presentation of evidence elements: ALC_LCD.1.1C The life-cycle definition documentation shall describe the process used to develop and maintain the TOE. Evaluator action elements: ALC_LCD.1.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. ALC_LCD.1.2E The evaluator shall check that the processes defined in the life- cycle definition documents are being followed by the developers. D R A F T ALC_LCD - Life-cycle definition Life-cycle support Page 138 of 202 CCEB-94/084 - Version 0.9 94/10/31 ALC_LCD.2 Standardised life-cycle process Objectives and threats 243 By limiting the choice of life-cycle processes to those which have been accepted as standards, the chances that the development and maintenance processes will not contribute to the overall quality of the TOE are reduced. Application notes Dependencies: No dependencies. Developer action elements: ALC_LCD.2.1D The developer shall establish a life-cycle process to be used in the development and maintenance of the TOE. ALC_LCD.2.2D The developer shall use a standardised engineering process to develop and maintain the TOE. ALC_LCD.2.3D The developer shall produce life-cycle definition documentation. Content and presentation of evidence elements: ALC_LCD.2.1C The life-cycle definition documentation shall describe the process used to develop and maintain the TOE. ALC_LCD.2.2C The life-cycle definition documentation shall also explain why the process was chosen and how it is used to develop and maintain the TOE. Evaluator action elements: ALC_LCD.2.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. ALC_LCD.2.2E The evaluator shall check that the standardised engineering processes defined in the life-cycle definition documents are being followed by the developers. ALC_LCD.3 Measurable life-cycle process Objectives and threats 244 The developer is required to use a measurable engineering process. In addition, the developer must comply with those standards such that the quality of the TOE can be monitored throughout the TOE's development and maintenance. D R A F T Life-cycle support ALC_FLR - Flaw remediation 94/10/31 CCEB-94/084 - Version 0.9 Page 139 of 202 Application notes Dependencies: No dependencies. Developer action elements: ALC_LCD.3.1D The developer shall establish a life-cycle process to be used in the development and maintenance of the TOE. ALC_LCD.3.2D The developer shall use a standardised and measurable engineering process to develop and maintain the TOE. ALC_LCD.3.3D The developer shall comply with the engineering process standard. ALC_LCD.3.4D The developer shall produce life-cycle definition documentation. Content and presentation of evidence elements: ALC_LCD.3.1C The life-cycle definition documentation shall describe the process used to develop and maintain the TOE. ALC_LCD.3.2C The life-cycle definition documentation shall also explain why the process was chosen and how it is used to develop and maintain the TOE. Evaluator action elements: ALC_LCD.3.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. ALC_LCD.3.2E The evaluator shall check that the standardised engineering processes defined in the life-cycle definition documents are being followed by the developers. ALC_FLR Flaw remediation Objectives 245 Flaw remediation ensures that flaws discovered will be tracked and corrected while the TOE is supported by the developer. Although compliance to a flaw remediation component cannot be determined at TOE evaluation and only deals with flaws after they are found, it is possible to evaluate the procedures and policies that a developer has in place to track and repair flaws, and to distribute the repairs. Threats 246 Flaw remediation primarily deals with threats concerned with exploiting flaws in a TOE during its operation and before the TOE has been corrected. D R A F T ALC_FLR - Flaw remediation Life-cycle support Page 140 of 202 CCEB-94/084 - Version 0.9 94/10/31 247 The following threats are countered by this assurance component: 248 Security flaws will continue to be exploited even after they have been discovered by the system's users. 249 Security flaws will continue to be exploited even after they have been reported to the developer. 250 Security flaws will continue to be exploited even after corrections to those security flaws have been found by the developer. Component levelling Application notes ALC_FLR.1 Basic flaw remediation Objectives and threats 251 The developer is responsible for establishing procedures to accept reports of flaws, find corrections to those flaws, and disseminate the flaw corrections to users who specifically request the corrections. 252 The following threats are countered by this assurance component: 253 Security flaws will continue to be exploited even after they have been discovered by the system's users. 254 Security flaws will continue to be exploited even after they have been reported to the developer. 255 Security flaws will continue to be exploited even after corrections to those security flaws have been found by the developer. Application notes Dependencies: No dependencies. Developer action elements: ALC_FLR.1.1D The developer shall establish a procedure to track all reported security flaws in each release of the TOE. ALC_FLR.1.2D The developer shall use a tracking system that includes a description of the nature and effect of each flaw and the status of finding a correction to that flaw. D R A F T Life-cycle support ALC_FLR - Flaw remediation 94/10/31 CCEB-94/084 - Version 0.9 Page 141 of 202 ALC_FLR.1.3D The developer shall establish a procedure to identify corrective actions for security flaws. ALC_FLR.1.4D The developer shall establish a procedure to provide flaw information and corrections to registered users. ALC_FLR.1.5D The developer shall produce flaw remediation documentation. Content and presentation of evidence elements: ALC_FLR.1.1C The flaw remediation documentation shall describe the procedures used to track security flaws, identify corrective actions for those flaws, and disseminate the flaw corrections to users. Evaluator action elements: ALC_FLR.1.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. ALC_FLR.2 Flaw reporting procedures Objectives and threats 256 In order to improve the dissemination of flaw information to users, specific points of contact must be identified and publicised by the developer. The point of contact allows users to report security flaws and to direct inquiries about security flaws. 257 The separation of corrections, changes, and updates into security relevant and non security relevant allows users to identify those changes that are critical to maintaining the security of the TOE from those that are not. Application notes Dependencies: No dependencies. Developer action elements: ALC_FLR.2.1D The developer shall establish a procedure to track all reported security flaws in each release of the TOE. ALC_FLR.2.2D The developer shall use a tracking system that includes a description of the nature and effect of each flaw and the status of finding a correction to that flaw. ALC_FLR.2.3D The developer shall establish a procedure to identify corrective actions for security flaws. ALC_FLR.2.4D The developer shall use a procedure that separates security relevant and non security relevant corrections, changes, or updates to the TOE. D R A F T ALC_FLR - Flaw remediation Life-cycle support Page 142 of 202 CCEB-94/084 - Version 0.9 94/10/31 ALC_FLR.2.5D The developer shall establish a procedure to provide flaw information and corrections to registered users. ALC_FLR.2.6D The developer shall establish a procedure for accepting user reports of security problems and requests for corrections to those problems. ALC_FLR.2.7D The developer shall designate one or more specific points of contact for user reports and inquires about security issues involving the TOE. ALC_FLR.2.8D The developer shall produce flaw remediation documentation. Content and presentation of evidence elements: ALC_FLR.2.1C The flaw remediation documentation shall describe the procedures used to track security flaws, identify corrective actions for those flaws, and disseminate the flaw corrections to users. ALC_FLR.2.2C The point of contacts, and the procedures for reporting and inquiring about security issues, shall be provided in user documentation. Evaluator action elements: ALC_FLR.2.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. ALC_FLR.3 Systematic flaw remediation Objectives and threats 258 If in the process of trying to find corrections to a security flaw, the developer violates a user's system security policy, then the consequences of that violation could be more harmful then the security flaw itself. 259 Even though security flaws may have been reported and corrected, the security flaws will continue to exist in other systems as long as those users have not been notified of the problem and corrections. Therefore, it is essential that this type of information be disseminated those registered user. Application notes Dependencies: No dependencies. Developer action elements: ALC_FLR.3.1D The developer shall establish a procedure to track all reported security flaws in each release of the TOE. D R A F T Life-cycle support ALC_FLR - Flaw remediation 94/10/31 CCEB-94/084 - Version 0.9 Page 143 of 202 ALC_FLR.3.2D The developer shall use a tracking system that includes a description of the nature and effect of each flaw and the status of finding a correction to that flaw. ALC_FLR.3.3D The developer shall establish a procedure to identify corrective actions for security flaws. ALC_FLR.3.4D The developer shall use a procedure that separates security relevant and non security relevant corrections, changes, or updates to the TOE. ALC_FLR.3.5D The developer shall have a policy that when a user's system must be used to diagnose and repair any problem, the developer personnel will abide by that user's system security policy. ALC_FLR.3.6D The developer shall establish a procedure for accepting user reports of security problems and requests for corrections to those problems. ALC_FLR.3.7D The developer shall establish a procedure for the automatic distribution of problem reports and the associated corrections to registered users who might be affected by the problem. ALC_FLR.3.8D The developer shall designate one or more specific points of contact for user reports and inquires about security issues involving the TOE. ALC_FLR.3.9D The developer shall produce flaw remediation documentation. Content and presentation of evidence elements: ALC_FLR.3.1C The flaw remediation documentation shall describe the procedures used to track security flaws, identify corrective actions for those flaws, and disseminate the flaw corrections to users. ALC_FLR.3.2C The point of contacts, and the procedures for reporting and inquiring about security issues, shall be provided in user documentation. Evaluator action elements: ALC_FLR.3.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. ALC_FLR.4 Timely flaw remediation Objectives and threats 260 Even though security flaws may have been reported and corrected, the security flaws will continue to exist in other systems as long as those users have not been notified of the problem and corrections. Therefore, it is essential that this type of information be disseminated those registered user within specific time limits. D R A F T ALC_FLR - Flaw remediation Life-cycle support Page 144 of 202 CCEB-94/084 - Version 0.9 94/10/31 Application notes Dependencies: No dependencies. Developer action elements: ALC_FLR.4.1D The developer shall establish a procedure to track all reported security flaws in each release of the TOE. ALC_FLR.4.2D The developer shall use a tracking system that includes a description of the nature and effect of each flaw and the status of finding a correction to that flaw. ALC_FLR.4.3D The developer shall establish a procedure to identify corrective actions for security flaws. ALC_FLR.4.4D The developer shall use a procedure that separates security relevant and non security relevant corrections, changes, or updates to the TOE. ALC_FLR.4.5D The developer shall have a policy that when a user's system must be used to diagnose and repair any problem, the developer personnel will abide by that user's system security policy. ALC_FLR.4.6D The developer shall establish a procedure for accepting user reports of security problems and requests for corrections to those problems. ALC_FLR.4.7D The developer shall establish a procedure which includes strict time intervals for the automatic distribution of problem reports to users that might be affected by the problem and for subsequently distributing the corrections that are found to these same users . ALC_FLR.4.8D The developer shall designate one or more specific points of contact for user reports and inquires about security issues involving the TOE. ALC_FLR.4.9D The developer shall produce flaw remediation documentation. Content and presentation of evidence elements: ALC_FLR.4.1C The flaw remediation documentation shall describe the procedures used to track security flaws, identify corrective actions for those flaws, and disseminate the flaw corrections to users. ALC_FLR.4.2C The point of contacts, and the procedures for reporting and inquiring about security issues, shall be provided in user documentation. Evaluator action elements: ALC_FLR.4.1E The evaluator shall check that the information provided meets all requirements for the identification and description of the evidence. D R A F T Life-cycle support ALC_TAT - Tools and techniques 94/10/31 CCEB-94/084 - Version 0.9 Page 145 of 202 ALC_TAT Tools and techniques Objectives 261 Tools and techniques is an aspect to handle tools being used to analyse and implement the TOE. It includes requirements concerning the programming languages and its documentation, compiling tools, coding standards, and runtime supporting libraries used to develop the TOE. Threats 262 These requirements address the threat of not well-defined, incorrect, or vicious programming languages, compilers, coding standards, and development tools causing the danger of flawed source or object codes. Component levelling Application Notes ALC_TAT.1 Well defined programming languages Objectives and threats 263 At this level options of the programming language shall be described to understand what the source code is doing and to uncover insecure structures and techniques. 264 The following threats are countered by this component: 265 Not well defined or non documented programming languages may cause unexpected and misleading effects during the development of the TOE. Application notes Dependencies: No dependencies. Developer action elements: ALC_TAT.1.1D The developer shall document the implementation dependent options of the programming language. Content and presentation of evidence elements: ALC_TAT.1.1C Any programming languages used for implementation shall be well- defined, e.g. as in an ISO standard. ALC_TAT.1.2C The definition of the programming languages shall define unambiguously the meaning of all statements used in the source code. D R A F T ALC_TAT - Tools and techniques Life-cycle support Page 146 of 202 CCEB-94/084 - Version 0.9 94/10/31 Evaluator action elements: ALC_TAT.1.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ALC_TAT.1.2E The evaluator shall review that the programming languages used for implementation are well-defined. ALC_TAT.1.3E The evaluator shall review that the implementation dependent options of the programming language are well documented. ALC_TAT.1.4E The evaluator shall review that the definition of the programming languages defines unambiguously the meaning of all statements used in the source code. ALC_TAT.2 Documentation of implementation options for compilers Objectives and threats 266 At this level coding standards shall be described to understand what the source code is doing and to uncover insecure structures and techniques. 267 The additional threats countered by this component are: 268 If the coding standards are not described, it is difficult to understanding the behaviour of the source code. Application notes Dependencies: No dependencies. Developer action elements: ALC_TAT.2.1D The developer shall document the implementation dependent options of the programming language. ALC_TAT.2.2D The developer shall describe coding standards to be followed during the implementation of the product. Content and presentation of evidence elements: ALC_TAT.2.1C Any programming languages used for implementation shall be well- defined, e.g. as in an ISO standard. ALC_TAT.2.2C The definition of the programming languages shall define unambiguously the meaning of all statements used in the source code. ALC_TAT.2.3C All source code shall comply with the coding standards. D R A F T Life-cycle support ALC_TAT - Tools and techniques 94/10/31 CCEB-94/084 - Version 0.9 Page 147 of 202 Evaluator action elements: ALC_TAT.2.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ALC_TAT.2.2E The evaluator shall review that the programming languages used for implementation are well-defined. ALC_TAT.2.3E The evaluator shall review that the implementation dependent options of the programming language are well documented. ALC_TAT.2.4E The evaluator shall review that the definition of the programming languages defines unambiguously the meaning of all statements used in the source code. ALC_TAT.2.5E The evaluator shall review that all source code complies with the coding standards. ALC_TAT.2.6E The evaluator shall review the coding standards to be followed during the implementation of the product. ALC_TAT.3 Description of implementation options and security measures Objectives and threats 269 The selected implementation dependent options of all compilers shall be documented to avoid unexpected effects of the object code. 270 The following additional threats are countered by this component: 271 If the selected implementation dependent options of all compilers used are not documented there is the threat of generating flawed object codes. Application notes Dependencies: No dependencies. Developer action elements: ALC_TAT.3.1D The developer shall document the implementation dependent options of the programming language. ALC_TAT.3.2D The developer shall describe coding standards to be followed during the implementation of the product. ALC_TAT.3.3D The developer shall document the selected implementation dependent options of all compilers used. D R A F T ALC_TAT - Tools and techniques Life-cycle support Page 148 of 202 CCEB-94/084 - Version 0.9 94/10/31 Content and presentation of evidence elements: ALC_TAT.3.1C Any programming languages used for implementation shall be well- defined, e.g. as in an ISO standard. ALC_TAT.3.2C The definition of the programming languages shall define unambiguously the meaning of all statements used in the source code. ALC_TAT.3.3C All source code shall comply with the coding standards. Evaluator action elements: ALC_TAT.3.1E The evaluator shall review that the information provided meets all requirements for content and presentation of evidence. ALC_TAT.3.2E The evaluator shall review that the programming languages used for implementation are well-defined. ALC_TAT.3.3E The evaluator shall review that the implementation dependent options of the programming language are well documented. ALC_TAT.3.4E The evaluator shall review that the definition of the programming languages defines unambiguously the meaning of all statements used in the source code. ALC_TAT.3.5E The evaluator shall review that all source code complies with the coding standards. ALC_TAT.3.6E The evaluator shall review the coding standards to be followed during the implementation of the product. ALC_TAT.3.7E The evaluator shall review that the selected implementation dependent options of all compilers used are well documented. ALC_TAT.4 Runtime libraries Objectives and threats 272 The source code of runtime libraries shall be provided to be able to understand and analyse their behaviour. 273 The following additional threats are countered by this component: 274 Within the source code of runtime libraries failures or malicious code may be hidden affecting the security of the TOE. The integrity and consistency of parts of the libraries may not be guaranteed. Application notes Dependencies: No dependencies. D R A F T Life-cycle support ALC_TAT - Tools and techniques 94/10/31 CCEB-94/084 - Version 0.9 Page 149 of 202 Developer action elements: ALC_TAT.4.1D The developer shall document the implementation dependent options of the programming language. ALC_TAT.4.2D The developer shall explain coding standards to be followed during the implementation of the product. ALC_TAT.4.3D The developer shall document the selected implementation dependent options of all compilers used. ALC_TAT.4.4D The developer shall provide the source code of any runtime libraries. Content and presentation of evidence elements: ALC_TAT.4.1C Any programming languages used for implementation shall be well- defined, e.g. as in an ISO standard. ALC_TAT.4.2C The definition of the programming languages shall define unambiguously the meaning of all statements used in the source code. ALC_TAT.4.3C All source code shall comply with the coding standards. ALC_TAT.4.4C Physical, procedural, personnel, and other security measures used by the developer to protect development tools shall be explained. Evaluator action elements: ALC_TAT.4.1E The evaluator shall verify that the information provided meets all requirements for content and presentation of evidence. ALC_TAT.4.2E The evaluator shall verify that the programming languages used for implementation are well-defined. ALC_TAT.4.3E The evaluator shall verify that the implementation dependent options of the programming language are well documented. ALC_TAT.4.4E The evaluator shall verify that the definition of the programming languages defines unambiguously the meaning of all statements used in the source code. ALC_TAT.4.5E The evaluator shall verify that all source code complies with the coding standards. ALC_TAT.4.6E The evaluator shall verify the coding standards to be followed during the implementation of the product. ALC_TAT.4.7E The evaluator shall verify that the selected implementation dependent options of all compilers used are well documented. ALC_TAT.4.8E The evaluator shall verify the source code of any runtime libraries. D R A F T ALC_DVS - Development security Life-cycle support Page 150 of 202 CCEB-94/084 - Version 0.9 94/10/31 ALC_DVS Development security Objectives 275 Development security is concerned with physical, procedural, technical, and personnel measures that may be used in the development environment to protect the TOE. It includes the physical security of the development location and any procedures used to select development staff. Threats 276 TBD. Component levelling Application notes ALC_DVS.1 Identification of security measures Objectives and threats Application notes Dependencies: No dependencies. Developer action elements: ALC_DVS.1.1D The developer shall produce development security documentation. ALC_DVS.1.2D The developer shall ensure that the security measures are followed during development and maintenance of the TOE. Content and presentation of evidence elements: ALC_DVS.1.1C The development security documentation shall identify the physical, procedural, personnel, and other security measures that are used to protect the confidentiality and integrity of the TOE. Evaluator action elements: ALC_DVS.1.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence. ALC_DVS.1.2E The evaluator shall check that the documented procedures are being applied. ALC_DVS.1.3E The evaluator shall search for errors in the security measures used to protect the TOE. D R A F T Life-cycle support ALC_DVS - Development security 94/10/31 CCEB-94/084 - Version 0.9 Page 151 of 202 ALC_DVS.2 Description of security measures Objectives and threats Application notes Dependencies: No dependencies. Developer action elements: ALC_DVS.2.1D The developer shall produce development security documentation. ALC_DVS.2.2D The developer shall ensure that the security measures are followed during development and maintenance of the TOE. Content and presentation of evidence elements: ALC_DVS.2.1C The development security documentation shall describe the physical, procedural, personnel, and other security measures that are used to protect the confidentiality and integrity of the TOE. Evaluator action elements: ALC_DVS.2.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence. ALC_DVS.2.2E The evaluator shall check that the documented procedures are being applied. ALC_DVS.2.3E The evaluator shall search for errors in the security measures used to protect the TOE. ALC_DVS.3 Sufficiency of security measures Objectives and threats Application notes Dependencies: No dependencies. Developer action elements: ALC_DVS.3.1D The developer shall produce development security documentation. ALC_DVS.3.2D The developer shall ensure that the security measures are followed during development and maintenance of the TOE. D R A F T ALC_DVS - Development security Life-cycle support Page 152 of 202 CCEB-94/084 - Version 0.9 94/10/31 Content and presentation of evidence elements: ALC_DVS.3.1C The development security documentation shall describe the physical, procedural, personnel, and other security measures that are used to protect the confidentiality and integrity of the TOE. ALC_DVS.3.2C The development security documentation shall include justifications as to why the security measures are sufficient to protect the confidentiality and integrity of the TOE. Evaluator action elements: ALC_DVS.3.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence. ALC_DVS.3.2E The evaluator shall check that the documented procedures are being applied. ALC_DVS.3.3E The evaluator shall search for errors in the security measures used to protect the TOE. D R A F T CCEB-94/084 94/10/31 Version 0.9 Page 153 of 202 Class AGD Guidance documents 277 Figure 2.5 shows the families within this class, and the hierarchy of components within the families.. GUIDANCE DOCUMENTS | | - AGD_USR - 1 | | - AGD_ADM - 1 Figure 2.5 - Guidance documents class decomposition AGD_USR User guidance Objectives 278 User guidance refers to written material that is intended to be used by non administrative human users of the TOE. User guidance describes the security functions provided by the TSF and provides instructions and guidelines, including warnings, for its secure use. Thus user guidance provides a basis for assumptions about the use of the TOE and a measure of confidence that non-malicious end-users and application developers will understand the secure operation of the TOE and will use it as intended. Threats 279 User guidance deals with threat that user information and resources will be vulnerable to loss or damage if not protected in accordance with the needs and D R A F T AGD_USR - User guidance Guidance documents Page 154 of 202 CCEB-94/084 - Version 0.9 94/10/31 desires of the user who "owns" the information and resources due to the accidental misuse of the security functions provided. Component levelling 280 This family contains only one level. This is because the information required for the user of the TOE to use its capabilities properly does not change with the level of assurance. Furthermore, the user has no need to presented with details of implementation; only with the information about how to use the capabilities presented by the TOE. Application notes User notes 281 The PP/ST author should review the the functional components of the PP/ST for guidance on documentation (i.e., "Component rationale and application notes"). Those application notes that are relevant to user guidance aimed at the understanding and proper use of the security functions should be considered for inclusion in the user guidance requirements. Documentation notes 282 Not applicable AGD_USR.1 End-user guidance Objectives and threats 283 No new objectives for this level. 284 No more detail information about threats at this level. Application notes User notes 285 No new information at this level. Documentation notes 286 Not Applicable. Dependencies: 287 No dependencies D R A F T Guidance documents AGD_ADM - Administrator guidance 94/10/31 CCEB-94/084 - Version 0.9 Page 155 of 202 Developer action elements: AGD_USR.1.1D The developer shall provide a single summary, chapter, or manual in user guidance describing the security functions provided by the TOE and guidelines on their use by non-administrative users. Content and presentation of evidence elements: AGD_USR.1.1C The user guidance shall describe the security enforcing functions and interfaces available to the end-user. AGD_USR.1.2C The user guidance shall describe how an end-user uses the TOE in a secure manner. AGD_USR.1.3C The user guidance shall describe privileges available to end- users, including cautions regarding their use. AGD_USR.1.4C The user guidance shall describe the interaction between user visible security functions. AGD_USR.1.5C The user guidance (e.g., Reference Manuals, User Guides, On-line Help, etc) shall be consistent with all other documentation delivered for evaluation. Evaluator action elements: AGD_USR.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. AGD_USR.1.2E The evaluator shall check that the information provided is consistent with the TSF external interface as described in other evaluation documentation supplied. AGD_ADM Administrator guidance Objectives 288 Administration guidance refers to written material that is intended to be used by those persons responsible for configuring, maintaining, and administering the TOE. Because the secure operation of the TOE is dependent upon the correct performance of these functions, persons responsible for performing these functions are trusted by the TSF. Administration guidance is intended to help administrators understand the security functions provided by the TOE, including both those functions that require the administrator to perform security-critical actions and those functions that provide security-critical information. Thus administration guidance is critical to the secure operation of the TOE. D R A F T AGD_ADM - Administrator guidance Guidance documents Page 156 of 202 CCEB-94/084 - Version 0.9 94/10/31 Threats 289 Administrator guidance deals with threat that user or TSF information and resources will be vulnerable to loss or damage if not protected in accordance with the needs and desires of the organization that "owns" the information and resources and the user to whom it is entrusted. In particular, it this family deals with threats that can be countered with correct installation, configuration, and administration of the TOE. Application notes User notes 290 The PP/ST author should review the the functional components of the PP/ST for guidance on documentation (i.e., "Component rationale and application notes"). Those application notes that are relevant to administrator guidance should be considered for inclusion in the administrator guidance requirements. Documentation notes 291 Privileges or roles that may be assigned to users should be included in the user guidance, and the proper use of such privileges discussed there. AGD_ADM.1 Administration guidance Objectives and threats 292 No new objectives for this level. 293 No more detail information about threats at this level. Application notes User notes 294 No new information at this level. Documentation notes 295 No new information at this level. Dependencies: 296 No dependencies Developer action elements: AGD_ADM.1.1D The developer shall provide administration guidance addressed to system administrative personnel. D R A F T Guidance documents AGD_ADM - Administrator guidance 94/10/31 CCEB-94/084 - Version 0.9 Page 157 of 202 Content and presentation of evidence elements: AGD_ADM.1.1C The administration guidance shall describe how to administer the TOE in a secure manner. AGD_ADM.1.2C The administration guidance shall describe cautions about functions and privileges that should be controlled in a secure processing environment. AGD_ADM.1.3C The administration guidance describe guidelines on the consistent and effective use of the security functions within the TSF. AGD_ADM.1.4C The administration guidance shall describe the difference between two types of functions: those which allow an administrator to control security parameters, and those which allow the administrator only to obtain information. AGD_ADM.1.5C The administrative guidance shall describe all security parameters under the administrator's control. AGD_ADM.1.6C The administrative guidance shall describe each type of security-relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under control of the TSF. AGD_ADM.1.7C The administration guidance shall describe guidelines on how the security functions interact. AGD_ADM.1.8C The administration guidance shall describe instructions regarding how to install, configure the TOE. AGD_ADM.1.9C The administration guidance shall describe all configuration options that may be used during secure installation of the TOE. AGD_ADM.1.10C The administration document shall describe procedures for ensuring that the TOE is started in a secure manner. AGD_ADM.1.11C The administrative guidance shall describe details, sufficient for use, of procedures relevant to the administration of security. AGD_ADM.1.12C The administration guidance, e.g. Reference Manuals, Administrator Guides, shall be consistent with all other documents supplied for evaluation. Evaluator action elements: AGD_ADM.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation and evidence. AGD_ADM.1.2E The evaluator shall check that the installation procedures result in a secure configuration. D R A F T AGD_ADM - Administrator guidance Guidance documents Page 158 of 202 CCEB-94/084 - Version 0.9 94/10/31 AGD_ADM.1.3E The evaluator shall check that the admnistrative documentation is consistent with the external interfaces described in other evaluation guidance. D R A F T CCEB-94/084 94/10/31 Version 0.9 Page 159 of 202 Class ADO Delivery and operation 297 Figure 2.6 shows the families within this class, and the hierarchy of components within the families.. DELIVERY AND OPERATION | | - AGD_USR - 1 - 2 - 3 | | - AGD_ADM - 1 - 2 Figure 2.6 - Delivery and operation class decomposition ADO_DEL Delivery Objectives 298 The requirements for delivery call for system control and distribution facilities and procedures that provide the assurance that the recipient receive what was expected and what the sender intended to deliver, and furthermore that what is received by the recipient correspond to the master copy. These facilities and procedures are applied to both initial delivery of the TOE and to updates and modifications. Threats 299 The delivery requirements deal with the threat of a malicious agent either tampering with the version being sent to a user, attempting to substitute a false version for a valid delivery, or otherwise masquerading as the developer. D R A F T ADO_DEL - Delivery Delivery and operation Page 160 of 202 CCEB-94/084 - Version 0.9 94/10/31 Component levelling Application notes ADO_DEL.1 Delivery procedures Objectives and threats 300 At this level, it is required that the developer provide at least a minimal level of distribution control procedures 301 The threats countered by this component are: 302 This component deals with unsophisticated attacks and errors in distribution. It provides at least the opportunity for checking the correspondence between the version sent by the developer and what was received by the user. Application notes Dependencies: No dependencies. Developer action elements: ADO_DEL.1.1D The developer shall state the procedures for delivery of the TOE, updates to and modifications of the TOE, to the user site. ADO_DEL.1.2D The developer shall document the delivery procedures. Content and presentation of evidence elements: ADO_DEL.1.1C The documented procedures shall show what procedures are employed when distributing versions to a user site. Evaluator action elements: ADO_DEL.1.1E The evaluator shall check the developer's delivery procedures. ADO_DEL.2 Detection of modification Objectives and threats 303 At this level a combination of technical, procedural, and physical safeguards are employed to provide for the detection of any discrepancies between the material which was sent by the developer and the material which was received at the user's site. D R A F T Delivery and operation ADO_DEL - Delivery 94/10/31 CCEB-94/084 - Version 0.9 Page 161 of 202 304 The additional threats countered are: 305 This component provides protection against undetected modifications to either the copy to be delivered (i.e., a change from the master copy) or to the version being delivered. This protection extends to the threat of substitution of a false version for the one originally sent by the developer. Application notes Dependencies: No dependencies. Developer action elements: ADO_DEL.2.1D The developer shall state the procedures for delivery of the TOE, updates to and modifications of the TOE, to the user site. ADO_DEL.2.2D The developer shall establish procedures and use appropriate technical measures to detect modifications of any software, firmware, and/or hardware during transfer from the developer's environment to a user's site. These procedures shall also be capable of detecting when an unauthorised agent has initiated the delivery (i.e., has attempted to masquerade as the developer). ADO_DEL.2.3D The developer shall document the delivery procedures. Content and presentation of evidence elements: ADO_DEL.2.1C The documented procedures shall show what procedures are employed when distributing versions to a user site. ADO_DEL.2.2C The developer's documentation shall state how the procedures are to be employed to obtain the desired detection of modification. ADO_DEL.2.3C The developer's documentation shall describe how the various procedures and technical measures provide for the detection of modifications, or any discrepancy between the developer's master copy and the version received at the user site. ADO_DEL.2.4C The developer's documentation shall describe how the various procedures allow detection of attempted masquerading even in cases in which nothing was sent to the user's site by the developer. Evaluator action elements: ADO_DEL.2.1E The evaluator shall review the developer's delivery procedures. ADO_DEL.2.2E The evaluator shall determine whether the developer's proposed safeguards and procedures are capable of detecting modifications to the delivered version and discrepancies against the developer's master copy. D R A F T ADO_DEL - Delivery Delivery and operation Page 162 of 202 CCEB-94/084 - Version 0.9 94/10/31 ADO_DEL.2.3E The evaluator shall determine whether the developer's proposed safeguards and procedures are capable of detecting an unauthorised agent from masquerading as the developer. ADO_DEL.3 Prevention of modification Objectives and threats 306 At this level the developer is required to establish technical and/or procedural safeguards that prevent modification to versions delivered by the developer. 307 The additional threats countered by this component are: 308 This component provides protection against even sophisticated attempts to modify versions sent by the developer, substitute a false version for a valid one, or to deliver a false version even when nothing was sent by the developer (i.e., masquerade as the authorised developer). Application notes Dependencies: No dependencies. Developer action elements: ADO_DEL.3.1D The developer shall state the procedures for delivery of the TOE, updates to and modifications of the TOE, to the user site. ADO_DEL.3.2D The developer shall establish procedures and use appropriate technical measures to prevent modifications of any software, firmware, and/or hardware during transfer from the developer's environment to a user's site. These procedures shall also be capable of detecting when an unathorised agent has initiated the delivery (i.e., has attempted to masquerade as the developer). ADO_DEL.3.3D The developer shall document the delivery procedures. Content and presentation of evidence elements: ADO_DEL.3.1C The documented procedures shall show what procedures are employed when distributing versions to a user site. ADO_DEL.3.2C The developer's documentation shall state how the procedures are to be employed to prevent modification of the version sent by the developer to the user's site. ADO_DEL.3.3C The developer's documentation shall describe how the various procedures and technical measures provide for the prevention of modifications, or any discrepancy between the developer's master copy and the version received at the user site. D R A F T Delivery and operation ADO_IGS - Installation, generation, and start-up 94/10/31 CCEB-94/084 - Version 0.9 Page 163 of 202 ADO_DEL.3.4C The developer's documentation shall describe how the various procedures allow detection of attempted masquerading even in cases in which nothing was sent to the user's site by the developer. Evaluator action elements: ADO_DEL.3.1E The evaluator shall review the developer's delivery procedures. ADO_DEL.3.2E The evaluator shall determine whether the developer's proposed safeguards and procedures are capable of preventing modifications to the delivered version and discrepancies against the developer's master copy. ADO_DEL.3.3E The evaluator shall determine whether the developer's proposed safeguards and procedures are capable of detecting an unauthorised agent from masquerading as the developer. ADO_IGS Installation, generation, and start-up Objectives 309 Installation, generation, and start-up procedures are useful for ensuring that the operational TSF has been installed, generated, and started in a secure manner as intended by the developer. Threats 310 TBD. Component levelling Application notes 311 The generation requirements are only applicable to TOEs that provide the ability to generate an operational TSF from source or object code. ADO_IGS.1 Installation, generation, and start-up procedures Objectives and threats Application notes Documentation notes 312 The use of the installation, generation, and start-up procedures is documented in the adminstrators manuals. Dependencies: No dependencies. D R A F T ADO_IGS - Installation, generation, and start-up Delivery and operation Page 164 of 202 CCEB-94/084 - Version 0.9 94/10/31 Developer action elements: ADO_IGS.1.1D The developer shall establish procedures for the secure installation, generation, and start-up of the TSF. ADO_IGS.1.2D The developer shall produce installation, generation, and start-up documentation. Content and presentation of evidence elements: ADO_IGS.1.1C The documentation shall describe the procedures established for the secure installation, generation, and start-up of the TSF from the delivered copy of the master TSF. Evaluator action elements: ADO_IGS.1.1E The evaluator shall check that the information provided meets all requirements for content and presentation of evidence. ADO_IGS.2 Generation log Objectives and threats Application notes Documentation notes 313 The use of the installation, generation, and start-up procedures is documented in the adminstrators manuals. Dependencies: No dependencies. Developer action elements: ADO_IGS.2.1D The developer shall establish procedures for the secure installation, generation, and start-up of the TSF. ADO_IGS.2.2D The developer shall produce installation, generation, and start- up documentation. Content and presentation of evidence elements: ADO_IGS.2.1C The documentation shall describe the procedures established for the secure installation, generation, and start-up of the TSF from the delivered copy of the master TSF. ADO_IGS.2.2C The generation procedures shall be capable of creating a log containing the generation options used to generate the TSF in such a way that it is possible to determine exactly how and when the TSF was generated. D R A F T Delivery and operation ADO_IGS - Installation, generation, and start-up 94/10/31 CCEB-94/084 - Version 0.9 Page 165 of 202 Evaluator action elements: ADO_IGS.2.1E The evaluator shall check that the information provided meets all requirements for the content and presentation of evidence . ADO_IGS.2.2E The evaluator shall search for errors in the installation, generation, and start up procedures. 314 D R A F T ADO_IGS - Installation, generation, and start-up Delivery and operation Page 166 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T 168 CCEB-94/084 94/10/31 Version 0.9 Page 167 of 202 Chapter 3 Assurance levels 3.1 Description of assurance levels AL0 to AL7 315 The use of levels provides graduated classes of assurance which differ in an increasing degree of assurance. A further advantage of using levels is given by the aspect of mutual recognition. 316 The following characterisation of assurance levels represents a short overview about the assurance levels AL0 to AL7. A more detailed description is written down in the next section. Seven assurance levels that can be targeted are defined in respect of the confidence in the assurance of a TOE. AL1 designates the lowest level and AL7 the highest. AL0 is provided for those TOEs that have been evaluated but that have failed to meet the requirements for any higher level. 317 The assurance levels are characterised as follows: 3.1.1 Level AL0 - Unassured 318 This level represents those TOEs that have been evaluated but that fail to meet the requirements for any higher level. Therefore, this level may not be the target assurance level for an evaluation of a TOE. 3.1.2 Level AL1 - Tested 319 This level can be characterised as demanding appropriate testing. 3.1.3 Level AL2 - Structurally tested 320 This level provides more confidence than level AL1 by requiring a more rigorous approach to testing. 3.1.4 Level AL3 - Methodically tested and checked 321 This level provides more confidence than level AL2 by requiring the additional evidence of an informal description of the detailed design and more detailed evidence of functional tests. 3.1.5 Level AL4 - Methodically tested and reviewed 322 This level provides more confidence than level AL3 by requiring additional evidence of the implementation and related tests. D R A F T 3 - Assurance levels CCEB-94/084 Page 168 of 202 Version 0.9 94/10/31 3.1.6 Level AL5 - Semiformal design 323 This level provides more confidence than level AL4 by requiring a semiformal presentation style for the design. 3.1.7 Level AL6 - Semiformally verified design 324 This level provides more confidence than level AL5 by requiring additional evidence of a structured approach in the design. 3.1.8 Level AL7 - Formally verified design 325 This level provides more confidence than level AL6 by requiring a formal specifications and the corresponding proofs. 3.2 Assurance levels, detailed description 326 As outlined in the previous section, seven hierarchically ordered assurance levels that can be targeted are defined in this CC for the rating of the TOE's assurance. An additional assurance level that can not be targeted is provided for those TOEs that have been evaluated but that have failed to meet the requirements for any higher level. These assurance levels consist of an appropriate combination of assurance components as described in chapter 2 of this Part. More precisely, for each assurance family one of its assurance components was selected for the respective assurance level or the assurance family is ignored for this assurance level. The latter applies only for the lower assurance levels. Editor Note: Another important aspect of the evaluation as a whole is the evaluation of the ST. The requirements for this step in the evaluation are separated because it was felt to be reasonable to differ between the evaluation of the ST and the TOE. However to understand the overall requirements for an evaluation, the requirements of the assurance levels have to be considered together with the requirements for the evaluation of a ST. D R A F T Unassured Assurance level AL0 94/10/31 CCEB-94/084 - Version 0.9 Page 169 of 202 Assurance level AL0 Unassured Objectives 327 This level represents those TOEs that have been evaluated but that fail to meet the requirements for any higher level. These TOEs are assigned the rating AL0 to distinguish them from those TOEs that have not been evaluated. Threats 328 A TOE that has been evaluated at this level does not meet the requirements that were deemed necessary to counter all of the threats identified in the PP/ST. Application Notes User notes 329 This level cannot be the target assurance level for an evaluation of a TOE. D R A F T Assurance level AL0 Unassured Page 170 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Tested - 94/10/31 CCEB-94/084 - Version 0.9 Page 171 of 202 Assurance level AL1 Tested Objectives 330 The main goals of this assurance level is to reduce the time taken for the evaluation of a TOE. This assurance level has been structured such that the requirements imposed on a developer should not create any additional burden on the TOE development life cycle. In addition, the evaluator actions have been reduced to the minimal set required while offering an increase in assurance over an unevaluated product or system. 331 At a minimum, it must be possible to identify the TOE, to understand the TOE's behaviour (what the TOE does), to actually exercise the TOE to verify its behaviour, and to have documentation that describes how the TOE is used (for both administrators and users). An evaluation that excludes some of the above requirements does not increase the assurance that the TOE counters the identified threats and operates as expected. Threats 332 The following threats are countered by this assurance level: 333 A non-compliant implementation of the specifications; 334 An incorrect or incomplete version of the TOE is delivered to a purchaser or is evaluated; and 335 Users of the TOE do not understand the TOE's security features and as a consequence, the security features are used incorrectly or inappropriately. Application Notes User notes 336 TBD D R A F T Assurance level AL1 - Page 172 of 202 CCEB-94/084 - Version 0.9 94/10/31 Requirements 337 Table 3.1 provides the assurance components which comprise this assurance level. Table 3.1 -Components required for assurance level AL1 Assurance Class --------------- Assurance Family Assurance Component Development ----------- Functional specification ADV_FSP.1 TOE and security policy TSF interface specification ADV_TIS.1 Informal TSF interface specification Tests ----- Functional tests ATE_FUN.1 Minimal testing Coverage ATE_COV.1 Complete coverage Independent testing ATE_IND.1 Third Party Testing Depth ATE_DPT.1 Interface testing Configuration management ------------------------ Configuration management ACM_CAP.1 Minimal support capabilities Guidance documents ------------------ User guidance AGD_USR.1 End-user guidance Administrator guidance AGD_ADM.1 Administration guidance D R A F T Structurally tested Assurance level AL2 94/10/31 CCEB-94/084 - Version 0.9 Page 173 of 202 Assurance level AL2 Structurally tested Objectives 338 Threats 339 Application Notes User notes 340 Requirements 341 Table 3.2 provides the assurance components which comprise this assurance level. Table 3.2 -Components required for assurance level AL2 Assurance Class --------------- Assurance Family Assurance Component [ EMPTY TABLE ] D R A F T Assurance level AL2 Structurally tested Page 174 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Methodically tested and checked Assurance level AL3 94/10/31 CCEB-94/084 - Version 0.9 Page 175 of 202 Assurance level AL3 Methodically tested and checked Objectives 342 This level provides commercial quality assurances that the design objectives, captured in the high-level specifications, are implemented in the TOE. This is achieved by showing how the TLSO and security policy requirements are reflected in the first-level design documents (e.g., TSF interface specifications), and then providing evidence of the correspondence between the high-level design and the implementation. 343 The intent of the assurances at this level is to establish that the external behaviour of the TOE conforms to its user-level and administrative documentation, with minimal analysis of the internal structure of the TSF. 344 Minimal levels of user and administrative guidance and product information are required. That which is required is sufficient for enabling the correct installation of the TOE and correct use of its protection features. 345 There are no requirements at this level for controls on the development environment, and there are no requirements for configuration control. 346 There are no requirements at this level for vulnerability analysis aimed at discovering previously-unknown exploitable flaws. 347 At AL3 much of the evidence is that derived from testing. 348 This level of assurance is intended to provide the equivalent level of assurance as CS1 of the Federal Criteria and, by extension C2 of the TCSEC. Threats 349 The assurances for AL3 are sufficient for relatively benign environments; those in which the threat of malicious attacks aimed at discovering exploitable vulnerabilities is considered minimal. Thus, the primary threats countered by the assurances of AL3 are those of errors or casual attempts to violate the access control policies enforced by the TSF (e.g., "browsing"). Application Notes 350 TBD D R A F T Assurance level AL3 Methodically tested and checked Page 176 of 202 CCEB-94/084 - Version 0.9 94/10/31 Requirements 351 Table 3.3 provides the assurance components which comprise this assurance level. Editor Note: Table 3.3 -Components required for assurance level AL3 Assurance class --------------- Assurance family Assurance component Development ----------- TSF interface specification ADV_TIS.1 Informal TSF interface specification TSF interface specification ADV_TFC.1 Correspondence argument to functional specification correspondence High-level design ADV_HLD.1 Informal high-level design Low-level design description ADV_LLD.1 Informal low-level design Tests ----- Functional tests ATE_FUN.2 Conformance testing Coverage ATE_COV.1 Complete coverage Independent testing ATE_IND.1 Third Party Testing Depth ATE_DPT.1 Interface testing Guidance documents ------------------ User guidance AGD_USR.1 End-user guidance Administrator guidance AGD_ADM.1 Administration guidance D R A F T Methodically tested and reviewed Assurance level AL4 94/10/31 CCEB-94/084 - Version 0.9 Page 177 of 202 Assurance level AL4 Methodically tested and reviewed Objectives 352 This level provides more confidence than lower levels by requiring additional evidence. A semiformal model of security policy is required as a theoretical basis for the security policy of the TOE. The complete mapping between the semiformal security policy model and the informal statement of the architectural design shall be described. This allows the evaluator to find out whether the security objectives of the TOE are correctly refined. The detailed design of the TSF shall be a decomposition of the architectural design and shall be modeled to reduce the interdependence of components and to reduce the risk that a change in one module will result in a cascade of changes throughout the TOE. Functions that are not critical to TSF security mechanisms shall be excluded from the TSF whenever possible to provide appropriate assurance that the code is understandable. No component shall have the ability to exercise privileges other than the minimum necessary to implement its required functions. 353 The implementation for all TSF shall be provided to support activities such as modularity studies, penetration testing, and mapping of design to implementation. The informal mapping between the detailed design and the source code or hardware drawings shall provide assurance that the design described in the detailed design description corresponds to what was implemented. 354 For his functional tests of the TOE the developer shall demonstrate that the previously discovered security flaws in the TOE have been removed. Penetration testing shall discover design and implementation flaws that will allow users to bypass the security functions and to perform unauthorised operations. At this level the TOE shall be retested after removing previously discovered security flaws to determine that all discovered flaws have been eliminated and that no new flaws have been introduced. 355 A misuse analysis shall be provided to investigate whether the TOE can be configured or used in a manner which is insecure but which an administrator or end user would reasonably believe to be secure. 356 Also flaws are a configuration item which must be maintained under a configuration management system to ensure that flaw reports are not lost or forgotten. The configuration management documentation shall additionally consist of an acceptance plan which describes the procedures used to accept modified or newly created TSF configuration items. 357 In order to prevent a flawed implementation of a TOE by an ad-hoc development and maintenance the developer shall follow a defined set of life- cycle processes and D R A F T Assurance level AL4 Methodically tested and reviewed Page 178 of 202 CCEB-94/084 - Version 0.9 94/10/31 shall produce life cycle definition documentation. Procedures shall be established to accept reports of flaws, find corrections of those flaws and disseminate the flaw corrections to users who specifically request the corrections. 358 At this level options of the programming language shall be described to understand what the source code is doing and to uncover insecure structures and techniques. A user guidance shall be provided to permit non- administrative end-users to understand the security functions. An administrator guidance shall be provided to help administrators understand the security functions of the TOE, including both those functions that require the administrator to perform security-critical actions and those functions that provide security-critical information. 359 Developers shall provide a means and procedures of securely generating a TSF from source code. They shall provide tools for generating a new version of the TSF and shall describe compiler dependencies to permit a secure procedure of the TSF from source code. A combination of technical, procedural, and physical safeguards are employed to provide for the detection of any discrepancies between the developer's master copy and the version received at the user's site. Threats 360 Functional specification: 361 There are missing requirements and inconsistencies in the functional specification which can only be identified by an intensive evaluation. 362 Security features in the functional specification are in conflict with the underlying security policy. Also non obvious conflicts should be identified by the evaluator because an semiformal model of security policy is used as a scientific basis for the underlying security policy. 363 Tests: 364 Functional tests address the threats associated with incorrect implementation of the specifications or the substitution of code that is compliant with the specifications with code that is non-compliant. 365 Vulnerability analysis: 366 Penetration testing deals with the threats that a malicious user will be able to discover flaws that will allow access to unauthorised resources (e.g., data) or resources, allow the ability to interfere with or alter the TCB, or interfere with the authorised capabilities of other users. 367 Misuse: 368 Human or other errors in operation may deactivate or disable security functions or mechanisms. It may be possible to configure or install the TOE in a way which is insecure, without the end user or administrator being able to recognise it. D R A F T Methodically tested and reviewed Assurance level AL4 94/10/31 CCEB-94/084 - Version 0.9 Page 179 of 202 369 Configuration management scope: 370 A threat is the accidental or unauthorised modification of a configuration item. 371 The introduction of inconsistencies between the multiple levels of abstraction of the TOE is also a threat. 372 Flaws reported during development or operation will remain in the TOE because the flaw reports were either lost or forgotten. 373 Configuration management capabilities: 374 Configuration management capabilities primarily deals with threats of accidental or deliberate unauthorised modifications of configuration items during the entire life-cycle of the TOE. 375 An incorrect or incomplete version of the TOE is delivered to a purchaser. 376 An item of the TOE is excluded from the evaluation. 377 The unauthorised modification of a TOE configuration item. 378 The introduction of inconsistencies between the multiple levels of abstraction of the TOE. 379 Flaws will remain in previous but still supported versions of the TOE due to the inability to regenerate those versions of the TOE. 380 TSF configuration items which have been modified may contain intentional or unintentional errors and may be included as part of the TOE unless adequately acceptance procedures are in place. 381 Life cycle: 382 Security flaws caused by a lack of quality in the TOE are exploited. 383 Security functional requirements are not met by the TOE which results in security violations. 384 Flaw remediation: 385 Security flaws will continue to be exploited even after they have been discovered by the system's users. 386 Security flaws will continue to be exploited even after they have been reported to the developer. 387 Security flaws will continue to be exploited even after corrections to those security flaws have been found by the developer. D R A F T Assurance level AL4 Methodically tested and reviewed Page 180 of 202 CCEB-94/084 - Version 0.9 94/10/31 388 Tools and techniques: 389 Not well defined or non documented programming languages may cause unexpected and misleading effects during the development of the TOE. 390 User guidance: 391 A non-administrative end-user or application developer will unintentionally misuse the security functions provided by the TOE. 392 A non-administrative end-user or application developer will use the security functions such that the protection is different from that intended. 393 Administrator guidance: 394 An administrator will unintentionally install the TOE such that it is not in a secure state. 395 An administrator will unintentionally misconfigure the TOE such that it is not in a secure state. 396 An administrator will unintentionally misuse the security functions provided by the TOE. 397 An administrator will use the security functions such that the protection is different from that intended or assumed. 398 End-user generation: 399 An administrative end-user will not be able to generate a TSF. 400 An administrative end-user will unintentionally generate a TSF that does not enforce the security policy as advertised.. 401 An administrative end-user will generate a TSF such that the protection is different from that intended. 402 Developer generation: 403 A developer will unintentionally generate a version of the TSF that does not enforce the security policy as documented. 404 A developer will generate a TSF such that the protection is different from that intended. 405 A developer will be unable to generate a TSF or will generate an erroneous TSF due to compiler dependencies. 406 Delivery: D R A F T Methodically tested and reviewed Assurance level AL4 94/10/31 CCEB-94/084 - Version 0.9 Page 181 of 202 407 This component deals with unsophisticated attacks and errors in distribution. It provides at least the opportunity for checking the correspondence between the version sent by the developer and what was received by the user. 408 This component provides protection against undetected modifications to either the copy to be delivered (i.e., a change from the master copy) or to the version being delivered. This protection extends to the threat of substitution of a false version for the one originally sent by the developer. Application Notes User notes 409 TBD Requirements 410 Table 3.4 provides the assurance components which comprise this assurance level. Table 3.4 -Components required for assurance level AL4 Assurance class --------------- Assurance family Assurance component Development ----------- Functional specification ADV_FSP.3 Semiformal security policy model TSF internals ADV_INT.1 Modularity TSF interface specification ADV_TIS.3 Semiformal interface specification TSF interface specification ADV_TFC.2 Correspondence demonstration to functional specification correspondence High-level design ADV_HLD.3 Description of high-level design High-level design to TSF ADV_HLD.2 Identification of security interface specification enforcing structural units correspondence Low-level design description ADV_LLD.2 Descriptive low-level design Low-level design to high-level ADV_LHC.1 Correspondence argument design correspondence Delivery of code/hardware ADV_IMP.1 Delivery of subset drawings Implementation to low-level ADV_ILC.1 Informal implementation to design correspondence low-level design correspondence D R A F T Assurance level AL4 Methodically tested and reviewed Page 182 of 202 CCEB-94/084 - Version 0.9 94/10/31 Table 3.4 -Components required for assurance level AL4 Assurance class --------------- Assurance family Assurance component Tests ----- Functional tests ATE_FUN.3 TSF Interface testing Coverage ATE_COV.2 Test sufficiency Independent testing ATE_IND.2 Evaluator Confirmation Depth ATE_DPT.2 Function testing Vulnerability assessment ------------------------ Vulnerability analysis AVA_VLA.3 Flaw removal Misuse AVA_MSU.2 Description of misuse analysis Configuration management ------------------------ Configuration management scope ACM_SCP.3 Problem tracking CM coverage Configuration management ACM_CAP.4 Acceptance procedures capabilities Life-cycle support ------------------ Life-cycle definition ALC_LCD.1 Developer defined life-cycle process Flaw remediation ALC_FLR.1 Basic flaw remediation Tools and techniques ALC_TAT.1 Well defined programming languages Development security ? Guidance documents ------------------ User guidance AGD_USR.1 End-user guidance Administrator guidance AGD_ADM.1 Administration guidance Delivery and operation ---------------------- Delivery ADO_DEL.2 Detection of modification Installation, generation, ADO_IGS.2 Generation log and start up 411 D R A F T Semiformal design Assurance level AL5 94/10/31 CCEB-94/084 - Version 0.9 Page 183 of 202 Assurance level AL5 Semiformal design Objectives 412 Threats 413 Application Notes User notes 414 Requirements 415 .. Table 3.5 -Components required for assurance level AL5 Assurance Class --------------- Assurance Family Assurance Component [ EMPTY TABLE ] D R A F T Assurance level AL5 Semiformal design Page 184 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Semiformally verified design Assurance level AL6 94/10/31 CCEB-94/084 - Version 0.9 Page 185 of 202 Assurance level AL6 Semiformally verified design Objectives 416 Threats 417 Application Notes User notes 418 Requirements 419 .. Table 3.6 -Components required for assurance level AL6 Assurance Class --------------- Assurance Family Assurance Component [ EMPTY TABLE ] D R A F T Assurance level AL6 Semiformally verified design Page 186 of 202 CCEB-94/084 - Version 0.9 94/10/31 D R A F T Formally verified design Assurance level AL7 94/10/31 CCEB-94/084 - Version 0.9 Page 187 of 202 Assurance level AL7 Formally verified design Objectives 420 The overall objective of this assurance level is to provide more confidence than the previous level by the introduction of the requirement for formal specifications and their corresponding proofs. 421 The security enforcing functions and the architectural design shall be specified in a formal style, consistent with the specified underlying formal model of security policy supporting the security target. The detailed design shall be specified in a semiformal style. 422 The source code and/or hardware drawings corresponding to the security mechanisms shall be evaluated. Evidence of testing of those mechanisms shall be evaluated. Evidence of functional testing shall be evaluated. There shall be a tool based configuration control system and an approved distribution procedure. 423 There shall be a close correspondence between the detailed design and the source code and/or hardware drawings. Threats 424 The following threats are countered by this assurance level: 425 Conflicts, (obvious, obscure and intentional), between the functional and architectural specifications and the underlying security policy; 426 Obvious conflicts between the design and the underlying security policy; 427 Changes in part of the TOE will result in a cascade of changes throughout the TOE and with a complex design chances for errors to occur or be deliberately hidden; 428 A non-compliant implementation of the specifications; 429 The exploitation of known flaws due to lack of corrective action and the dissemination of fixes; 430 Tools and techniques used in the development environment have accidental or malicious functionality; 431 Accidental configuration or misuse of the security features in a non- secure fashion; D R A F T Assurance level AL7 Formally verified design Page 188 of 202 CCEB-94/084 - Version 0.9 94/10/31 432 Errors introduced by dependencies within the development environment; 433 An incorrect or incomplete version of the TOE is delivered to a purchaser or is evaluated; and 434 Sophisticated attempts to modify version sent out by the developer; 435 Users of the TOE do not understand the TOE's security features and as a consequence, the security features are used incorrectly or inappropriately. Application Notes User notes 436 TBD Requirements 437 Table 3.7 provides the assurance components which comprise this assurance level. D R A F T Formally verified design Assurance level AL7 94/10/31 CCEB-94/084 - Version 0.9 Page 189 of 202 Table 3.7 - Components required for assurance level AL7 Assurance Class --------------- Assurance Family Assurance Component Development ----------- Functional specification ADV_FSP.6 Formal specification of the security functions properties TSF internals ADV_INT.2 Minimisation and Complexity TSF interface specification ADV_TIS.5 Formal and semiformal TSF interface specification TSF interface specification ADV_TFC.3 Correspondence proof to functional specification correspondence High-level design ADV_HLD.6 Formal high-level explanation High-level design to TSF ADV_HTC.3 Correspondence proof interface specification correspondence Low-level design description ADV_LLD.6 Formal low-level design explanation Low-level design to high-level ADV_LHC.3 Correspondence proof design correspondence Delivery of code/hardware ADV_IMP.3 Structured delivery drawings Implementation to low-level ADV_ILC.2 Demonstrated implementation design correspondence to low-level design correspondence Tests ----- Functional tests ATE_FUN.6 Formal specifications Coverage ATE_COV.3 Ordered testing Independent testing ATE_IND.3 Formal Specification Testing Depth ATE_DPT.3 Module testing Vulnerability assessment ------------------------ Vulnerability analysis AVA_VLA.5 Penetration resistance Covert channel analysis (a) Misuse AVA_MSU.3 Explanation of misuse analysis Strength of TOE security (b) functions Configuration management ------------------------ Configuration management ACM_AUT.2 Complete CM automation automation Configuration management scope ACM_SCP.5 Development tools CM coverage Configuration management ACM_CAP.7 Protection of master copies capabilities D R A F T Assurance level AL7 Formally verified design Page 190 of 202 CCEB-94/084 - Version 0.9 94/10/31 Table 3.7 - Components required for assurance level AL7 Life-cycle support ------------------ Life-cycle definition ALC_LCD.3 Measurable life-cycle process Flaw remediation ALC_FLR.4 Timely flaw remediation Tools and techniques ALC_TAT.4 Runtime libraries Development security ALC_DVS.3 Sufficiency of security measures Guidance documents ------------------ User guidance AGD_USR.1 End-user guidance Administrator guidance AGD_ADM.1 Administration guidance Delivery and operation ----------------------- Delivery ADO_DEL.3 Prevention of modification Installation, generation, ADO_IGS.2 Generation log and start up Notes on table: (a) If the TOE makes claims about Covert channels (for both storage and timing) then AVA_CCA.3 would be required. (b) If the TOE makes claims about Strength of security functions then AVA_SOF.2 would be required. D R A F T 194 CCEB-94/084 94/10/31 Version 0.9 Page 191 of 202 Annex A Presentation of assurance A.1 Assurance levels 438 The set of assurance levels presented in this Part of the CC represents increasing levels of trust that can be associated with a TOE. 439 Increasing trust results both from replacing one or more assurance components in an Assurance level with higher level components from the same assurance family (i.e. increasing the requirements for evidence and analysis) and from the addition of assurance components from other assurance families (i.e. adding new requirements). 440 Therefore, assurance levels differ not only by additional requirements in the higher assurance levels, but also by demand for additional rigour and precision. A.2 Assurance components 441 Each assurance component is presented as three sets of assurance elements. The sets of assurance elements are: - Developer Actions : the activities that shall be performed by the developer. Requirements for developer actions are identified by appending the letter "D" to the element number. - Content and Presentation of Evidence : the evidence required, what the evidence shall demonstrate, and what information the evidence shall convey. Requirements for content and presentation of evidence are identified by appending the letter "C" to the element number. - Evaluator Actions : the analysis implied by the evidence provided and by the targeted level of assurance. Analysis can include ensuring that the developer has performed all of the actions required, that the evidence provided is complete and correct, and can include actions or analysis which shall be performed in addition to that already performed by the developer. Requirements for evaluator actions are identified by appending the letter "E" to the element number. 442 The developer actions, and content and presentation of evidence define the assurance requirements that are used to define a developer's responsibilities in demonstrating the correctness and effectiveness of the TOE's security functions. By addressing these requirements, the developer can increase consumer and evaluator confidence that the TOE satisfies the functional and assurance requirements of a PP or a ST. D R A F T A - Presentation of assurance CCEB-94/084 Page 192 of 202 Version 0.9 94/10/31 443 The evaluator actions defines the assurance requirements that are used in PPs or STs to define a TOE evaluator's responsibilities in verifying the security claims made in the TOE's ST. By addressing these requirements, the evaluator can increase consumer and evaluator confidence that the TOE satisfies the functional and assurance requirements of a PP or a ST. 444 These requirements identify the evaluator effort that shall be expended in verifying the security claims made in the TOE's ST. 445 Confidence that the security claims have been sufficiently verified depends on two factors: the evaluator's competence and objectivity. Although a very important factor of any evaluation, evaluator competence and objectivity are outside the scope of the CC. Editor Note: The style of the component presentation is at present uneven. Emphasis will be on one of developer actions, evidence, or evaluator actions as appropriate but it is not necessary to emphasis all three i.e., if the evidential requirements are detailed and explicit, a matching evaluator action is not required for each one. The intention is that by adopting the following style the duplication of text will be minimised, please comment : Developer Actions - explicit developer actions should be listed followed by a requirement to furnish the required evidence. Content and Presentation - requirements listed for content, the presentation evidence followed by requirements for the rational (justification) evidence. Evaluator Actions - limited to a check for content and presentation of evidence requirements (single action), validate each justification case (each listed) and other additional evaluator actions. A.3 Assurance elements 446 Each element represents a requirement to be met. These statements of requirements are intended to be clear, concise, and unambiguous statements. Therefore, there are no compound sentences: each separable requirement is stated as an individual element. 447 The elements have been written using the normal dictionary meaning for the terms used, rather than use a number of predefined terms as shorthand which results in implicit requirements. Therefore, elements are written as explicit requirements, with no reserved terms. Editor Note: The ITSEC source document used reserved verbs : state, describe and explain. The intention is that explicit requirements will provide the equivalent. For example, the main difference between "describe" and "explain" is the requirement for justifications; therefore, justifications will be required for higher components. D R A F T CCEB-94/084 A - Presentation of assurance 94/10/31 Version 0.9 Page 193 of 202 Editor Note: The process of implementing the element approach is not yet complete, and will continue during the development of the CC. A.4 Formality of assurance deliverables 448 Additional rigour and precision in assurance deliverables is explicitly required by the formality of presentation of the evidence. 449 TBD Editor Note: The details are to be finalised, but the intent is that there is always an informal representation of the evidence. At the higher levels, the informal is used in support of the semi or formal representations. The step to a semiformal representation is intended to provide demonstrable proof that a systematic and methodical approach is being used within the development environment for the development of the TOE. The step to a formal representation is to demonstrate that a rigorous mathematical approach has been used within the development environment for particular parts of the development of the TOE. A.5 Correspondence between assurance deliverables 450 Additional rigour and precision in correspondence between assurance deliverables is explicitly required by the formality of the presentation of the evidence of correspondence. 451 TBD Editor Note: The details are to be finalised, but the intent is that there is always an informal representation of the evidence of correspondence, providing informal traceability. At the higher levels, the informal evidence of correspondence is used in support of the semi or formal evidence of correspondence The step to semiformal evidence of correspondence between two semiformal representations is intended to provide demonstrable proof that a systematic and methodical approach is being used within the development environment. The step to formal evidence of proof of correspondence between two formal representations is to demonstrate that a rigorous mathematical approach has been used within the development environment for particular parts of the TOE. D R A F T A - Presentation of assurance CCEB-94/084 Page 194 of 202 Version 0.9 94/10/31 D R A F T 196 CCEB-94/084 94/10/31 Version 0.9 Page 195 of 202 Annex B Effectiveness and correctness B.1 Introduction 452 This annex provides information on how the concepts of effectiveness and correctness are incorporated into the Common Criteria (CC). Assurance needs to be addressed from several points of view and the CC distinguishes confidence in the correctness in the implementation of the security functions from confidence in their effectiveness. B.1.1 Background 453 The development model that forms the context for this discussion is one composed of a set of step-wise refinements of requirements into an implementation in hard ware, firmware, and software. This model presumes that there exists a statement of requirements for the system that are expressed in a narrative form. From this statement of requirements is derived an expression of a technical specification: the definition of the features, behaviour, and attributes to be provided by the hardware, firmware, and software. This is the specification level: the highest level of abstraction of the system. This level of abstraction is interpreted into a high-level design. That is, this level of abstraction is refined into a level of specification containing more detail. In a sense, it is an implementation of the high-level design, but remains an abstract machine. This step-wise refinement continues until an implementation is realised: a real (vice abstract) machine is constructed that can be exercised and subjected to testing. B.1.2 Discussion 454 The central focus of assurance is the extent to which the presumed threats to the TOE have been countered. Procedurally, this becomes the determination of whether or not the implementation is a complete and accurate interpretation of the security specifications. Assurance addresses the question of the degree to which one can be certain that the implementation provides the security functions, behaviour and at tributes defined in the high-level abstractions; in particular, the security specifications. B.1.2.1 Effectiveness 455 Effectiveness is, in effect a conditional judgment about the high-level abstractions of the system (primarily at the high-level design). It is a statement that the functions proposed, if implemented correctly (i.e., without error) will have the security behaviour desired; they will be effective in countering the threats postulated. D R A F T B - Effectiveness and correctness CCEB-94/084 Page 196 of 202 Version 0.9 94/10/31 456 Aspects of this determination include: a) The suitability of the selected security functions in countering the identified threats; b) The implications of known security vulnerabilities; c) Whether or not the set of security functions composes into a coherent and cohesive whole (i.e., the dependency issues). B.1.2.2 Correctness 457 Correctness deals with the conditional part of the mapping. It addresses the question of whether or not the implementation is a complete and accurate representation of the specifications. Correctness deals with the issues: a) Are all the specifications implemented; does the implementation contain everything that is stated in the specification; and b) Is there anything in the implementation that is not implied by the specifications; does the specification perform unexpected functions? 458 The first condition means that the details of the specification must be mappable to details of the implementation, whereas the second condition means that the implementation must be shown to be nothing other than an expansion of the specification - that there is no detail in the implementation that cannot be mapped back to a requirement of the original specification. B.1.3 Evaluation judgment 459 One needs to reach a judgment about whether the TOE exhibits the security effects and behaviour desired and counters the threats postulated. Such judgments become the end result of a series of incremental conclusions that allows an argument about the qualities of the implementation with reference to the original specifications. The quality and strength of the conclusions reached may vary (e.g., as a result of the level of evidence available and the granularity of development refinements), but the evaluation process must be complete, in the sense that a judgment is reached about the implementation relative to the specifications. B.1.4 Technical approach 460 A number of assurance levels have been defined, representing ascending levels of confidence in correctness of the implementation and therefore, the effectiveness of the TOE. There are no separate ratings for either effectiveness or correctness. These concepts and the judgments about them appear as integral elements of the judgments to be reached by an evaluator. That is, they appear as aspects of the assurance elements in the form of determinations to be made as the result of the analysis of available evidence. D R A F T 198 CCEB-94/084 94/10/31 Version 0.9 Page 197 of 202 Annex C Augmentation rules for assurance levels 461 The notion of "augmentation" is defined as the addition of one or more pre-defined assurance component levels to an assurance level. Only an assurance level but not an assurance component level may be augmented. 462 Furthermore an assurance level may only be augmented. The notion of an "assurance level minus a constituent assurance component level" is not recognised as a valid claim. 463 The augmentation carries with it the obligation on the part of the claimant to justify the utility and added value of the added assurance component level to the assurance level. D R A F T C - Augmentation rules for assurance levels CCEB-94/084 Page 198 of 202 Version 0.9 94/10/31 D R A F T 200 CCEB-94/084 94/10/31 Version 0.9 Page 199 of 202 Annex D Cross reference table of Assurance levels and Assurance level components 464 The following table (next page) describes the relationship between the assurance levels, and the assurance families and components. D R A F T D - Cross reference table of Assurance levels and Assurance level components Page 200 of 202 Version 0.9 94/10/31 Table D.1 - Assurance components breakdown and mapping AL Assurance Family Abbreviated Name 1 3 4 7 ----------------------------------------------------------------------- Functional specification ADV_FSP 1 - 3 6 TSF internals ADV_INT - - 1 2 TSF interface specification ADV_TIS 1 1 3 5 TSF interface specification to ADV_TFC - 1 2 5 functional specification correspondence High-level design ADV_HLD - 1 3 6 High-level design to TSF interface ADV_HTC - - 2 3 specification correspondence Low-level design description ADV_LLD - 1 2 6 Low-level design to high-level design ADV_LHC - - 1 3 correspondence Delivery of code/hardware drawings ADV_IMP - - 1 3 Implementation to low-level design ADV_ILC - - 1 2 correspondence Functional tests ATE_FUN 1 2 3 6 Coverage ATE_COV 1 1 2 3 Independent testing ATE_IND 1 1 2 3 Depth ATE_DPT 1 1 2 3 Vulnerability analysis AVA_VLA - - 3 5 Covert channel analysis AVA_CCA - - - - (a) Misuse AVA_MSU - - 2 3 Strength of TOE security functions AVA_SOF - - - - (b) Configuration management automation ACM_AUT - - - 2 Configuration management scope ACM_SCP - - 3 5 Configuration management capabilities ACM_CAP 1 - 4 7 Life-cycle definition ALC_LCD - - 1 3 Flaw remediation ALC_FLR - - 1 4 Tools and techniques ALC_TAT - - 1 4 Development security ALC_DVS - - ? 3 User guidance AGD_USR 1 1 1 1 Administrator guidance AGD_ADM 1 1 1 1 Delivery ADO_DEL - - 2 3 Installation, generation, and start-up ADO_IGS - - 2 2 Notes on table: (a) If the TOE makes claims about Covert channels (for both storage and timing) then AVA_CCA.3 would be required. (b) If the TOE makes claims about Strength of security functions then AVA_SOF.2 would be required. D R A F T 202 CCEB-94/084 94/10/31 Version 0.9 Page 201 of 202 Annex E Relationship of Common Criteria assurance levels to previous criteria Editor Note: This annex will be populated with the material currently in the separate Part 3 : Mapping rationale tables document. The presentation of this material is not finalised, please comment on the approach taken in the mapping rationale document. 465 This section relates to the topic of backwards compatibility of the CC to the existing documents (i.e., ITSEC, CTCPEC, TCSEC/FC). It will provide the ability to map from a rating under any of the baseline documents to the CC. D R A F T E - Relationship of Common Criteria assurance levels to previous criteria CCEB Page 202 of 202 Version 0.9 94/10/31