D R A F T Common Criteria for Information Technology Security Evaluation -------------------------- CCEB-94/082 Part 1: Introduction and general model 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 108 D R A F T CCEB-94/082 Table of contents 94/10/31 Version 0.9 Page i of viii Table of contents Chapter 1 Overview ....................................................... 1 1.1 Introduction .......................................................... 1 1.2 Common Criteria approach .............................................. 2 1.2.1 Development ......................................................... 2 1.2.2 Evaluation .......................................................... 3 1.2.3 Operation .......................................................... 4 Chapter 2 Introduction .................................................... 5 2.1 Background of the Common Criteria .................................... 5 2.2 Scope of Part 1 ...................................................... 6 2.3 Organisation of Part 1 ................................................ 6 2.4 Abbreviations ........................................................ 6 Chapter 3 Target audience of the CC ....................................... 7 3.1 Consumers or procurers ............................................... 7 3.2 Developers or producers ............................................... 7 3.3 Evaluators ............................................................ 8 3.4 Others ............................................................... 8 3.5 Usage of Common Criteria by target audience ........................... 8 Chapter 4 Key concepts ................................................... 9 4.1 Target of evaluation ................................................. 9 4.2 Security functional requirements ..................................... 9 4.3 Security assurance requirements ....................................... 9 4.4 CC as evaluation criteria ............................................. 9 4.5 Derivation of TOE security objectives ................................ 10 4.6 Organisation of security requirements ............................... 11 4.7 Synthesis of TOE security requirements .............................. 13 4.8 Expression of TOE security specifications ............................ 13 Chapter 5 Organisation of Common Criteria ............................... 15 5.1 Part 1: Introduction and general model ............................... 15 5.2 Part 2: Security functional requirements ............................ 15 5.3 Part 3: Security assurance requirements .............................. 15 5.4 Part 4: Predefined Protection Profiles ............................... 16 5.5 Part 5: Registration procedures ...................................... 16 5.6 Relationship of target audience to the Common Criteria ............... 16 D R A F T Table of contents CCEB-94/082 Page ii of viii Version 0.9 94/10/31 Chapter 6 Scope and applicability ........................................ 17 Chapter 7 Common Criteria evaluation results ............................. 19 7.1 Introduction ......................................................... 19 7.2 Limitations on expression of security functions and assurance ....... 19 7.2.1 Security functions and assurance in Protection Profiles ............ 19 7.2.2 Security functions in Security Targets ............................ 20 7.2.3 Assurance in Security Targets ..................................... 20 7.3 Definition of the CC evaluation results ............................. 20 Chapter 8 Common Criteria levels of abstraction .......................... 23 8.1 Introduction ......................................................... 23 8.2 Top Level Security Objectives ........................................ 24 8.3 Security requirements ................................................ 25 8.3.1 Source of requirements ............................................. 25 8.3.2 Construction of requirements ...................................... 26 8.3.3 Re-use of security requirements .................................... 26 8.4 Security specifications ............................................. 27 8.5 Strength of TOE functions ........................................... 27 8.5.1 Strength of TOE function rating .................................... 27 8.5.2 Strength of TOE function claim .................................... 27 8.5.3 Strength evaluation ................................................ 28 Chapter 9 Evaluation of requirements and specifications ................. 29 9.1 Evaluation of requirements ........................................... 29 9.2 Evaluation of specifications ........................................ 29 Annex A Glossary of terms related to information technology security evaluation (normative) ................................. 31 Annex B Specification of functional requirements (normative) ............ 37 B.1 Overview ............................................................. 37 B.2 Class structure ...................................................... 37 B.2.1 Family structure .................................................. 38 B.2.2 Family name ........................................................ 38 B.2.3 Family behaviour .................................................. 39 B.2.4 Threats ........................................................... 39 B.2.5 Application notes ................................................. 39 D R A F T CCEB-94/082 Table of contents 94/10/31 Version 0.9 Page iii of viii B.2.6 Other relevant families ........................................... 40 B.2.7 Component levelling ................................................ 40 B.2.8 Components ........................................................ 41 B.2.9 Component structure ................................................ 41 B.2.10 Component identification .......................................... 41 B.2.11 Component rationale and application notes ........................ 42 B.2.12 Permitted operations .............................................. 42 B.2.13 Dependencies ..................................................... 42 B.2.14 Functional elements .............................................. 43 B.3 Construction rules for classes ....................................... 43 B.4 Construction rules for families ...................................... 43 B.4.1 Method used in levelling components ............................... 43 B.4.2 Other rules ........................................................ 44 B.5 Construction rules for components .................................... 44 B.5.1 Measurable ........................................................ 45 B.5.2 Evaluatable ....................................................... 45 B.5.3 Technically feasible .............................................. 46 B.5.4 Unique ............................................................. 46 B.5.5 Unambiguous ....................................................... 46 B.5.6 Permitted operations ............................................... 47 B.5.7 Dependency analysis ................................................ 48 B.5.8 Hierarchical relationship analysis ................................. 48 B.6 Functional component evaluation criteria ............................. 48 Annex C Specification of assurance requirements (normative) ............. 49 C.1 Overview ............................................................. 49 C.2 Assurance class structure ........................................... 49 C.2.1 Name ............................................................... 49 C.2.2 Families ........................................................... 50 C.3 Assurance family structure ........................................... 50 C.3.1 Name ............................................................... 51 C.3.2 Objectives ......................................................... 51 C.3.3 Threats ........................................................... 51 C.3.4 Component levelling ................................................ 51 C.3.5 Application notes ................................................. 52 C.3.6 Components ........................................................ 52 C.4 Assurance component structure ....................................... 52 C.4.1 Objectives and threats ............................................. 52 C.4.2 Application notes ................................................. 53 C.4.3 Dependencies ...................................................... 54 C.4.4 Elements .......................................................... 54 C.5 Construction rules for classes ....................................... 54 C.6 Construction rules for families ...................................... 54 C.7 Construction rules for components .................................... 54 C.8 Assurance component evaluation criteria .............................. 54 D R A F T Table of contents CCEB-94/082 Page iv of viii Version 0.9 94/10/31 Annex D Specification of functional packages (normative) ................ 55 D.1 Overview ............................................................. 55 D.2 Functional package structure and content ............................. 55 D.2.1 Package Identification ............................................. 55 D.2.2 Package behaviour ................................................. 56 D.2.3 Application notes ................................................. 57 D.2.4 Permitted operations ............................................... 57 D.2.5 Dependencies ...................................................... 57 D.2.6 Functional Components ............................................. 58 D.3 Composition Rules for Packages ...................................... 58 D.3.1 Functional package behaviour composition ........................... 58 D.3.2 Functional package application note composition ................... 59 D.3.3 Functional package permitted operation composition ................ 59 D.3.4 Functional package dependency composition ......................... 59 D.3.5 Functional package requirements composition ........................ 60 D.4 Evaluation criteria for functional packages ......................... 60 Annex E Specification of assurance levels (normative) ................... 61 E.1 Overview ............................................................. 61 E.2 Assurance level structure ........................................... 61 E.2.1 Name ............................................................... 61 E.2.2 Objectives ......................................................... 61 E.2.3 Threats ........................................................... 61 E.2.4 Application notes ................................................. 62 E.2.5 Assurance components ............................................... 63 E.3 Composition rules .................................................... 63 Annex F Specification of Protection Profiles (normative) ................ 65 F.1 Overview ............................................................. 65 F.2 Content of Protection Profile ....................................... 65 F.2.1 Descriptive elements ............................................... 65 F.2.2 TLSO .............................................................. 65 F.2.3 Requirements ...................................................... 67 F.2.4 Application notes ................................................. 68 F.3 Protection Profile construction rules ................................ 68 F.4 Source of Protection Profiles ....................................... 68 F.5 Evaluation criteria for Protection Profiles ......................... 68 F.5.1 PPE Protection Profile Evaluation ................................. 68 D R A F T CCEB-94/082 Table of contents 94/10/31 Version 0.9 Page v of viii Annex G Specification of security targets (normative) ................... 71 G.1 Overview ............................................................. 71 G.2 Content of security target .......................................... 71 G.2.1 Descriptive elements ............................................... 71 G.2.2 TLSO .............................................................. 73 G.2.3 Requirements ...................................................... 74 G.2.4 TOE description ................................................... 76 G.2.5 Application notes ................................................. 77 G.3 Security Target construction rules .................................. 77 G.4 Source of security target ............................................ 77 G.5 Relationships between protection profile and security target ......... 77 G.5.1 Introduction ....................................................... 77 G.5.2 Common sections of a PP and a ST .................................. 78 G.5.3 Three cases of relationship between a PP and a ST ................. 79 G.6 Evaluation criteria for Security Targets ............................ 80 G.6.1 STE - ST Evaluation ................................................ 80 Annex H Security concepts and principles (informative) .................. 85 H.1 Introduction ......................................................... 85 H.2 General security context ............................................. 85 H.3 Information technology security context ............................. 87 Annex I Security development and evaluation model (informative) ......... 89 I.1 Introduction ......................................................... 89 I.2 Development of Security Requirements and Specifications .............. 89 I.3 Development of TOE .................................................. 91 I.4 Evaluation context .................................................. 92 I.5 Use of evaluation results ............................................ 93 Annex J Evaluation of systems and products (informative) ................ 95 J.1 Introduction ......................................................... 95 J.2 Boundaries of CC applicability ....................................... 95 Annex K Preservation of philosophy of source criteria (informative) ..... 97 K.1 Effectiveness and correctness ........................................ 97 D R A F T Table of contents CCEB-94/082 Page vi of viii Version 0.9 94/10/31 K.2 Strength of mechanism ................................................ 97 K.3 Reference monitor .................................................... 97 K.4 Trusted computing base .............................................. 97 K.5 Development and evaluation assurance ................................ 97 K.6 Extensibility of requirements ....................................... 97 Annex L Additional background material (informative) .................... 99 L.1 Introduction ......................................................... 99 L.2 History of international evaluation criteria ......................... 99 L.2.1 Recent progress .................................................... 99 L.2.2 The Common Criteria project ........................................ 100 L.3 Common Criteria project terms of reference .......................... 100 L.3.1 Scope of Common Criteria project ................................... 100 L.3.2 Objectives of Common Criteria project ............................. 100 L.4 ISO Subcommittee 27 Working Group 3 terms of reference ............... 100 Annex M Bibliography (informative) ...................................... 103 M.1 Referenced standards ................................................ 103 M.2 Applicable standards ................................................. 103 M.3 Related standards ................................................... 104 Annex N Index (informative) ............................................ 105 D R A F T CCEB-94/082 List of figures 94/10/31 Version 0.9 Page vii of viii List of figures Figure 1.1 - Influence of evaluation ...................................... 3 Figure 4.1 - Organisation and synthesis of concepts for requirements expression ...................................................... 14 Figure B.1 - Functional class structure .................................. 37 Figure B.2 - Functional family structure ................................. 38 Figure B.3 - Functional component structure ............................. 41 Figure C.1 - Assurance class structure .................................. 49 Figure C.2 - Assurance family structure .................................. 50 Figure C.3 - Assurance component structure .............................. 53 Figure D.1 - Functional package structure ................................ 56 Figure E.1 - Assurance level structure .................................. 62 Figure F.1 - Protection Profile structure ................................ 66 Figure G.1 - Security target structure .................................. 72 Figure H.1 - Security concepts and relationships ........................ 85 Figure H.2 - Evaluation concepts and relationships ...................... 86 Figure I.1 - Derivation of requirements and specifications ............... 90 Figure I.2 - TOE Development Model ....................................... 91 Figure I.3 - Evaluation context ......................................... 93 Figure I.4 - Use of evaluation results ................................... 94 D R A F T List of tables CCEB-94/082 Page viii of viii Version 0.9 94/10/31 List of tables Table 4.1 - Organisation of security requirements ....................... 12 Table 5.1 - Roadmap of Common Criteria .................................. 16 Table G.1 - Content comparison of Protection Profile and Security Target .......................................................... 78 D R A F T CCEB-94/082 1 - Overview 94/10/31 Version 0.9 Page 1 of 108 Chapter 1 Overview 1.1 Introduction 1 Information Technology (IT) is becoming increasingly important to the proper functioning of many parts of society. Much of industry, the health sector, telecommunications, and government relies on IT to handle the volumes of information necessary for them to perform their functions. 2 The information held by IT systems is a critical resource which enables organisations to succeed in their mission. Users expect their information systems to perform their functions efficiently whilst exercising proper control of the information to ensure it is protected against hazards such as unintentional, unwanted, or unwarranted dissemination or alteration. The term IT security is used to cover determination and mitigation of the effect of these and similar hazards. 3 The focus of IT security is the reduction of risks associated with threats to the information arising directly or indirectly from human error or deliberate subversion. This may be contrasted with safety where the primary focus is the threat to human well being arising out of functional or mechanical failure, and the more general quality issue where the primary focus is the ability of the IT to satisfy the overall objectives of its users. 4 A threat analysis for an IT system can show what threats are conceivable, and completion of a risk analysis can determine what countermeasures should be implemented to reduce risk to an acceptable level. These countermeasures can be provided as part of the IT system or can be implemented as external measures. 5 Users, who rely on IT security, need to be confident that their chosen countermeasures are fit for their intended purpose and contain no implementation defects which would undermine security. 6 Many users of IT lack the knowledge and expertise necessary to judge whether their confidence in the security of their IT installations might be misplaced and they may not wish to rely solely on the assertions of suppliers as to the qualities of their offerings. Users may therefore choose to increase their confidence in their security measures by ordering a security review. 7 This Common Criteria (CC) document establishes a set of criteria for use as the basis of an IT security evaluation. By establishing a common criteria base, the results of an evaluation will be more meaningful to a wider audience and will permit a degree of comparability between the results of otherwise independent security evaluations. The evaluation result is then available to users for determining whether an evaluated IT product or system is secure enough for their intended application and whether the security risks implicit in its use are tolerable. D R A F T 1 - Overview CCEB-94/082 Page 2 of 108 Version 0.9 94/10/31 8 In order to achieve greater comparability between evaluation results, evaluations are performed within the framework of an evaluation scheme which sets the evaluation standards and monitors the quality of the evaluations. Several such schemes currently exist at a national level each based on a different (though broadly comparable) set of evaluation criteria. 9 The CC is the outcome of a project to align the existing and emerging evaluation criteria (FC/USA including TCSEC, CTCPEC/Canada, ITSEC/Europe, ISO) in order to define a common set of criteria with the potential to ease the mutual recognition of evaluation results between nations. This is intended to facilitate the supply of security-evaluated products by eliminating the costs of multiple evaluations. 10 The CC is compatible with existing evaluation criteria, and thus preserves current investment in security evaluations. Moreover it also improves on the existing material by introducing new concepts and clarifying current ones 11 The CC is the evaluation criteria with contextual material that is provided for support and guidance only and to increase the accessibility of the material to a wider audience. 1.2 Common Criteria approach 12 Confidence in IT security can be gained through action and influence on the processes of development, evaluation, and operation. Overall security can be improved through the exercise of proper IT security controls. Figure 1.1 illustrates the relationships between evaluation and the IT product which are briefly described below and amplified in annex J. 1.2.1 Development 13 To achieve proper IT security, it is essential that the security requirements imposed on the IT development be effective in contributing towards the security objectives of users. Unless suitable requirements are established at the start of the development process the resulting end product, however well engineered, will not meet the objectives of its (anticipated) users. 14 The CC defines a set of IT security requirements of known utility which can be used in establishing security requirements for prospective products. The CC also defines the Protection Profile (PP) construct which allows prospective users or suppliers to describe reusable sets of security requirements of proven utility which will meet their organisational objectives. 15 Developers should use PPs when specifying products to be developed. The product security definition, requirements, and objectives together form the Security Target (ST) which is used by the evaluators as the basis for the evaluation. D R A F T CCEB-94/082 1 - Overview 94/10/31 Version 0.9 Page 3 of 108 16 . < . . . . . . . . . . . . . . . . . . . . . . . . < . . V . . Security requirements (PP & ST) - - - - - - -\ . . | \ . . | /-IT evaluation requirements (CC) -\ | . . | V V V . . \ > Development - - > IT product & - - > Evaluation <.. . /\ . > evaluation evidence | . . . . . . . . . . . | V . | Evaluation .>. | Report . | | . \ V . \ - - - - - > Operation | . V . Influence . . . . Operation .>. Information - - - - Report Figure 1.1 - Influence of evaluation 17 The CC defines requirements for the quality and rigour of the development process and the evidence which must be presented for evaluation in order to show that the requirements have been met. The statements of evidence are the formal subject of evaluation. 1.2.2 Evaluation 18 The evaluation process may be carried out in parallel with development, or it may follow it. The principal inputs to evaluation are: a) A Security Target describing the security to be evaluated and containing the security requirements which may be by reference to claimed Protection Profile(s); b) The set of evidence prescribed by the CC; D R A F T 1 - Overview CCEB-94/082 Page 4 of 108 Version 0.9 94/10/31 c) The IT product for which the security evaluation is required; d) The criteria to be used by the evaluator in forming judgments about the IT security. 19 Additional input comes from the body of knowledge about IT security in general and the IT security expertise of the evaluator in particular. 20 The expected result of the evaluation process is a report documenting the evaluator findings about the product as determined by the evaluation criteria. The report will be useful to actual and potential consumers of the product as well as to the developer of the product. 21 Evaluation reduces the probability of errors or vulnerabilities in the Target of Evaluation (TOE) and may therefore influence the initial requirements, the development process, or the end product. 1.2.3 Operation 22 Users may elect to use evaluated products in their particular environment. Once a product or system is in operation, previously unknown errors or vulnerabilities may surface or environmental assumptions may be revised. As a result, reports would be raised to give the developer an opportunity to correct the product or modify the requirements. Such changes may require the product to be re-evaluated. D R A F T CCEB-94/082 2 - Introduction 94/10/31 Version 0.9 Page 5 of 108 Chapter 2 Introduction 2.1 Background of the Common Criteria 23 This document represents the most recent effort at developing criteria for evaluation of IT security that are broadly useful within the international community. The history of evaluation criteria began in the early 1980's in the United States with the development of the Trusted Computer System Evaluation Criteria (TCSEC), commonly called the "Orange Book". In the later 1980's, a series of initiatives began in several countries to develop evaluation criteria which built upon the concepts of the TCSEC but were more flexible and adaptable to the evolving nature of IT in general. 24 The work in individual nations began to converge at the end of the 1980's with the growing realisation that the problem of IT security evaluation was global in nature, as was the market for IT products with security features. The needs for coordination and international standardisation were becoming very clear. Purely national standards for evaluation would preclude mutual recognition of evaluation results between countries. The lack of mutual recognition agreements would in turn create trade barriers between countries or groups of countries, and this would again lead to significantly higher costs for security evaluated systems. The first effort at international evaluation criteria was the draft Information Technology Security Evaluation Criteria (ITSEC) version 1.0, published jointly by the nations of France, Germany, the Netherlands, and the United Kingdom. The revised ITSEC was published in 1991 as version 1.2 by the European Commission for trial use in the European Union. 25 At approximately the same time, work began in the International Organisation for Standardisation (ISO) to develop evaluation criteria for general international use. This task was assigned to Working Group 3 (WG3), which was created in Stockholm in 1990, coincident with the creation of its parent subcommittee 27 (SC27). In ISO, a series of working drafts of an international standard criteria were developed and discussed since 1991 without much substantive progress in resolving the fundamental differences in approach and content among the various criteria. Further work was needed to synthesise the criteria initiatives being taken in Europe with the historical approach used in the US. In Canada, the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) was developed during the early 1990's as one approach to this synthesis. In the US, the draft Federal Criteria for Information Technology Security (FC) was published in January 1993, as a second approach to the synthesis, this time with the participation of Canada and using elements of the ITSEC work. 26 When the new FC was presented to the European IT security community in February 1993, it was agreed that intensive work should go forward by the authors of the CTCPEC, FC, and ITSEC to align the criteria approaches taken in the D R A F T 2 - Introduction CCEB-94/082 Page 6 of 108 Version 0.9 94/10/31 European Union and North America. Thereby, the interests of the world IT security community could be served, because the resultant criteria could be offered to ISO as a sound basis for proceeding with a truly international set of IT security evaluation criteria. The European Commission and the governments of Canada and the US began a project to develop a single draft Common Criteria (CC). The stated intent of the project is to resolve the philosophical and technical differences now found in the three main published criteria, and then to deliver the still-draft results after testing to ISO as a contribution to its work in progressing the international standard. This document is the first public result of that project. 2.2 Scope of Part 1 27 This part of the CC provides the general model of IT security evaluation. It defines the fundamental conceptual structures and ideas used in all parts of the CC in relation to each other. In addition, the target audience is described, with pointers to the various parts of the CC where their individual interests with respect to security criteria and evaluation are covered. 2.3 Organisation of Part 1 28 Part 1 consists of a body and a set of annexes. The body provides an introduction and scoping of the CC, along with a presentation of the general model of IT security evaluation and its important elements. The annexes provide normative specifications plus extensive informative contextual and supporting material for IT security evaluation. The document also contains a detailed glossary (normative) to help avoid ambiguities of terms. 2.4 Abbreviations 29 For the purpose of all parts of the CC, the following abbreviations are used: CC: Common Criteria for Information Technology Security Evaluation IT: Information Technology PP: Protection Profile SF: Security Function ST: Security Target TOE: Target of Evaluation TLSO: Top-Level Security Objectives TSF: TOE Security Functions TSP: TOE Security Policy TSC: TOE Security Functions Scope of Control D R A F T CCEB-94/082 3 - Target audience of the CC 94/10/31 Version 0.9 Page 7 of 108 Chapter 3 Target audience of the CC 30 IT security evaluations are formal investigations of the security properties of products and systems. Three groups of people with a general interest in these evaluations can be identified: a) Consumers or procurers of IT products or systems; b) Developers or producers of IT products or systems; c) Evaluators of IT products or systems. 31 The evaluation criteria presented in this document have been structured to support the needs of all three groups. They are all considered to be users of this CC. The three groups can benefit from the criteria as explained in the following paragraphs. 3.1 Consumers or procurers 32 The consumers or procurers can use the evaluation results to help decide whether an evaluated product or system fulfills their security needs. These security needs are typically identified as a result of a risk analysis. The CC plays an important role in supporting techniques for the selection of IT security measures. The CC is written especially to ensure that the evaluation results fulfill the needs of the consumers or procurers, taking the position that this is the fundamental purpose and justification for the evaluation process. 33 The CC provides a structure for presenting the security properties of a product or a system that permits a consumer to make the decision to operate the TOE. The consumers can use the evaluation results to compare between different products or systems. The concept of presenting requirements in hierarchical order in the CC supports this need. 34 The CC also gives consumers - especially in consumer groups and societies - a structure in which to express their special requirements for IT security measures in a product or system which can then be built to meet those requirements. This requirements structure is called a Protection Profile (PP), a term which is explained in detail in annex F of this Part 1. 3.2 Developers or producers 35 The intent of the CC is also to support the developers or producers in preparing for and assisting in the evaluation of their products or systems appropriately. The clear and precise structure provided by the CC for stating security requirements aids the D R A F T 3 - Target audience of the CC CCEB-94/082 Page 8 of 108 Version 0.9 94/10/31 developers or producers in identifying those requirements to be satisfied by their own product or system to be evaluated. Moreover, the developers can use the CC to determine their responsibilities and actions in supporting the evaluation. The CC describes the actions a developer is to carry out and defines all the deliverables a developer is to provide for an evaluation. 3.3 Evaluators 36 The evaluators can find evaluation requirements in the CC. The CC describes the specific actions the evaluator is to carry out. 3.4 Others 37 The CC is also useful as reference material to all parties with an interest in or responsibility for IT security when determining how to express their security requirements or when considering whether CC based IT security evaluation is relevant to their needs. Accordingly, the following additional groups can benefit from information contained in the CC in various ways: a) System custodians responsible for determining organisational IT security requirements; b) Security requirements architects responsible for the specification of the security content of IT systems and products; c) Accreditors responsible for accepting an IT system for use within a particular environment; d) Sponsors of evaluation, persons or organisations requesting and supporting an evaluation; e) Evaluation authorities responsible for the management and oversight of IT security evaluation programmes. 3.5 Usage of Common Criteria by target audience 38 Chapter 5 of this Part 1 contains a description of each of the parts of the CC and provides a table which relates these to the three principal categories of users. D R A F T CCEB-94/082 4 - Key concepts 94/10/31 Version 0.9 Page 9 of 108 Chapter 4 Key concepts 4.1 Target of evaluation 39 The TOE is the IT security product or system which is subject to evaluation. The CC is applicable to both IT security products and systems. In most cases there is no need to distinguish between a general purpose IT product and a specific operational IT system installation. The term TOE is therefore used where no distinction is required. 40 The CC presents requirements for the IT security of a TOE under the distinct categories of security functional requirements and assurance requirements. 4.2 Security functional requirements 41 The CC security functional requirements are levied on those functions of the TOE that are specifically in support of IT security and set the desired security behaviour. Part 2 defines the set of security functional requirements for which the CC is known to be applicable. 42 Examples of security functional requirements are: identification, authentication, security audit, or non-repudiation of origin. 4.3 Security assurance requirements 43 Assurance is a property of a TOE which gives a user confidence that the TOE is secure. Assurance is derived from knowledge about the definition, construction, and intended use of the TOE. Part 3 presents the requirements for assurance which allow an evaluator studying the TOE to present evaluation findings in the form of an assurance rating for the TOE. Such an assurance rating may then be meaningful to the user. 44 Examples of assurance requirements include: constraints on the rigour of the implementation process and requirements to search for and analyse the impact of potential security vulnerabilities. 4.4 CC as evaluation criteria 45 The CC is the evaluation criteria which permit an evaluator to state whether the TOE satisfies its definition of `secure'. By using the CC in evaluation of the TOE, the evaluator will be able to make statements about: D R A F T 4 - Key concepts CCEB-94/082 Page 10 of 108 Version 0.9 94/10/31 a) Whether the specified security functions of the TOE meet security functional requirements expressed in the ST; b) Whether the specified security functions of the TOE are correctly implemented; c) Whether the specified security functions of the TOE are effective in countering the assumed threats to the TOE. 46 The security requirements expressed in the CC define the known safe working domain of applicability of IT security evaluation criteria. A TOE for which the security requirements are expressed only in terms of the functional and assurance requirements drawn from the CC will be evaluatable against the CC. However there may be a need, in some circumstances, for a TOE to meet security requirements not directly expressed in the CC. The CC recognises the necessity to evaluate such a TOE but, as the additional requirements lie outside the known domain of applicability of the CC, the results of such an evaluation must be qualified accordingly and may place at risk universal acceptance of the evaluation results. 47 The results of an evaluation will be stated in terms of conformance to the CC, as defined in chapter 7 of this Part 1. Describing the security of a TOE in CC terms permits comparison of the security characteristics of TOEs in general. 4.5 Derivation of TOE security objectives 48 A TOE will be constructed in the expectation that it will meet security needs of prospective users. Users are responsible for determining their own security needs using an approach such as risk analysis. The details of risk analysis are outside the scope of the CC. The CC assumes that any risk analysis will include definition of the threats to the information and IT environment and definition of responsibilities for IT security. 49 Risk analysis may be carried out by an organisation in the general context of the IT needs of that organisation. Such an organisational risk analysis will be used to derive an IT security policy for the organisation which lays down security objectives and general requirements for IT environments within the organisation. As such IT security policies are likely to be organisation specific, the CC cannot lay down detailed requirements for content and presentation for the security policies. 50 Where no applicable organisational IT security policy exists, a similar risk analysis must be carried out for the TOE based on an assumed environment of use and intended manner of use. This risk analysis will develop a presumed threat scenario for the postulated use and environment for the TOE and will be used to set IT security objectives. 51 The CC uses the term top level security objectives (TLSO) to encompass the results of the risk analysis work. The CC requires that the TLSO be provided for the TOE. The TLSO contain assumptions about the environment, intended use, statements of threat to the TOE and may refer to any applicable IT security policies. D R A F T CCEB-94/082 4 - Key concepts 94/10/31 Version 0.9 Page 11 of 108 4.6 Organisation of security requirements 52 The CC presents requirements for TOE functions and assurance in the same general style and uses the same hierarchical organisation and terminology. 53 The term class is used for the most general grouping of security requirements. The concept of class is introduced primarily for organisational convenience and does not define a hard taxonomic boundary. All the security requirements within a class share a common intent or approach. 54 The members of a class are termed families. A family is a grouping of sets of security requirements which share a single purpose but may differ in emphasis or rigour of the requirements. 55 The members of a family are termed components. A component describes a specific set of security requirements and is the organisational unit of security requirements which may be called up by a TOE. In most cases, the set of components within a family will be ordered to represent a range of stringency of security requirements which share a common purpose. 56 The components are constructed from individual requirement elements. The element is the lowest level expression of security requirements and is the single evaluatable security requirement. 57 The organisation of the security requirements into the hierarchy of class - family - component - element permits the different aspects of security requirements to be addressed separately. This hierarchy is provided to help users choose the right components once they have identified the threats to the information in their IT environment. Table 4.1 provides some illustrative examples of this hierarchy. 58 The CC supports the concept of dependencies between components. A dependency identifies the reliance of one component on other components. D R A F T 4 - Key concepts CCEB-94/082 Page 12 of 108 Version 0.9 94/10/31 59 Table 4.1 - Organisation of security requirements Example functional requirements Example assurance requirements Class TOE Entry - class of functional Development Environment - class security requirements of requirement concerned with associated with initiation of control and management of the access to the TOE resources. development of the TOE User Data Protection - class Development Process - class of of functional security requirement concerned with the requirements associated with development methods and control of access to the user technical characteristics of object within the TOE. the TOE Family TOE Entry__Session Locking - Development Environment__ family of functional components Configuration Management - expressing requirements to help family of assurance components control unauthorised use of a concerned with control of the user's terminal. This reduces TOE representations and the vulnerabilities associated ensuring that the with unattended sessions. representations are reflected in the actual TOE. TOE Entry__Method of Entry - Development Environment__ family of functional components Developer Security - family of expressing requirements to assurance components limit user security attributes expressing requirements to a user may select and the control physical access to the subject a user may bond to development facilities. based on how the session is initiated (e.g. ftp, rpc, dial-in, local terminal). Component TOE Entry__Session Locking__ Development Environment__ Basic Session Locking - A Configuration Management__ functional component Basic Configuration expressing requirements to Management - An assurance reduce the threat of component expressing unauthorised use of terminals requirements for significant that have accidentally been attention to configuration management. left unattended and active. TOE Entry__Session Locking__ Development Environment__ User Session Locking - A Configuration Management__ functional component expressing Configuration List - An requirements to reduce the assurance component expressing threat of unauthorised use of requirements for minimal terminals that have configuration management. intentionally been left unattended and active. Element TOE Entry__Session Locking__ Development Environment__ Basic Session Locking__ Configuration Management__ Element1 - Security functions Configuration List__Element1 - shall enable authorised The developer shall maintain a administrators to display and configuration list for the modify the policy attributes TOE. used in session locking control TOE Entry__Session Locking__ Development Environment__ Basic Session Locking__ Configuration Management__ Element2 - The conditions under Configuration List__Element2 - which an unprivileged user may The developer shall provide a display and modify the session configuration list for the locking attributes shall be TOE. specified in user documentation. D R A F T CCEB-94/082 4 - Key concepts 94/10/31 Version 0.9 Page 13 of 108 4.7 Synthesis of TOE security requirements 60 A TOE is constructed to meet the TOE TLSO. In order to meet the conditions for evaluation against the CC, the TOE security requirements should be synthesised from the component security requirements defined in the CC. The CC defines a set of structures which combine CC component security requirements into meaningful assemblies. The relationships among the various concepts for requirements expression are described below and illustrated in figure 4.1. 61 The intermediate level of component combination is termed a package. The pack age permits the expression of a set of requirements which comply with an identifiable subset of security objectives. A package is intended to be reusable and to define requirements which are known to be useful and effective in meeting the identified objectives both for functions and assurance. 62 The high level of component combination is termed a protection profile (PP). The PP permits the expression of security requirements for a set of TOEs which will comply fully with an expressed TLSO. A PP is intended to be reusable and to define TOE requirements which are known to be useful and effective in meeting the identified TLSO. A PP is not specific to a single TOE. 63 A package may be used in the construction of PPs and of higher level packages subject to the dependencies between the underlying components being resolved. All dependencies should be identified. Not all dependencies have to be resolved within a package. Within a PP, all of the dependencies must be resolved. Dependencies within a package may only be partially resolved with the intent of resolving those dependencies on use of the package. All the component dependencies within a PP must be resolved for the PP to be considered as valid. 64 The CC assurance levels are packages contained in the CC which are the primary focus of CC assurance requirements. The CC assurance levels each define a balanced and complete set of assurance requirements and together form an ordered set which defines the assurance scale used by the CC for stating the assurance of a TOE. 4.8 Expression of TOE security specifications 65 Any particular TOE which is constructed to meet a set of security requirements must possess a set of security specifications for the TOE functions and assurance. The functional specification will specify the interface to and behaviour of the TOE security functions. The assurance specification will specify how the assurance requirements will be met for the TOE. A definition of the TOE security together with the security requirements and the justification for each are collectively termed the security target (ST). The ST is the basis for the agreement between the TOE developers, users, evaluators, and evaluation authorities as to what security the TOE offers. The ST is used as the basis for the evaluation of the TOE during which the evaluator will determine whether the requirements expressed are an effective response to the threat, whether the specifications meet the requirements, and whether the specifications are implemented correctly. D R A F T 4 - Key concepts CCEB-94/082 Page 14 of 108 Version 0.9 94/10/31 / Component 1 (Element 1, ...) /- Family <- Component 2 (Element 1, ...) / \ Component 3 (Element 1, ...) / Assurance / / Component 1 (Element 1, ...) or Class <----- Family < Functional \ \ Component 2 (Element 1, ...) \ \ / Component 1 (Element 1, ...) \- Family <- Component 2 (Element 1, ...) \\ Component 3 (Element 1, ...) \ Component 4 (Element 1, ...) Functional Component A \ > Functional Package Functional Component B / Assurance Component X \ Assurance Component Y -> Assurance Level Assurance Component Z / Functional Package \ \ Functional Component\ \ \ \ Functional Component \ \\ \ > Protection Profile / Security Target Assurance Level / / / Assurance Component / Figure 4.1 - Organisation and synthesis of concepts for requirements expression D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 15 of 108 Chapter 5 Organisation of Common Criteria 66 The CC is presented as a set of distinct but related parts as identified below. 5.1 Part 1: Introduction and general model 67 This Part 1 is the introduction to the CC. Part 1 defines general concepts and principles of IT security evaluation and presents a general model of evaluation. Part 1 also presents a common structure for expressing IT security requirements and specifications for products and systems based on their top-level security objectives (TLSO). Part 1 defines the structure, content and construction rules for functional and assurance requirement components and packages, PPs, and STs. Part 1 also defines evaluation criteria for requirements and specifications for use in evaluation of components, packages, PPs, and STs. 5.2 Part 2: Security functional requirements 68 Part 2 establishes a set of functional components as a standard way of expressing the security functional requirements for TOEs. Functional requirements state the TOE behavioural properties needed to counter identified threats. Each functional component addresses a specific set of threats. Complementary sets of functional components, that possess associated behaviour and may be implemented in a TOE, may be combined into functional packages. Part 2 catalogues the set of functional components, families, classes, and some useful functional packages. 5.3 Part 3: Security assurance requirements 69 Part 3 presents assurance levels that define the CC scale for rating assurance. It establishes a set of assurance components as a standard way of expressing the assurance requirements. These components are the smallest selectable set of assurance elements that can be added to a PP or ST. Each assurance component is expressed as a set of requirements on both the developer and evaluator. Assurance components are grouped into the set of assurance levels. The assurance levels and assurance components are used to evaluate the assurance claims of a TOE. Evaluation against these assurance levels provides confidence in the IT security functions of a TOE. D R A F T 5 - Organisation of Common Criteria CCEB-94/082 Page 16 of 108 Version 0.9 94/10/31 5.4 Part 4: Predefined Protection Profiles 70 Part 4 contains the set of PPs that state existing combinations of functional and assurance requirements which have been identified in source criteria including ITSEC, CTCPEC and FC/TCSEC. Editor Note: In early review drafts, worked examples of PPs will be provided in lieu of Part 4 for feasibility demonstration purposes. 5.5 Part 5: Registration procedures 71 Part 5 will define the procedures necessary to register additional PPs and to maintain them in an international registry. This part also could include procedures to perform the same operations on functional packages and functional components. Editor Note: Part 5 will not be included in early review drafts. 5.6 Relationship of target audience to the Common Criteria 72 The following table presents, for the three key target audience groupings, the parts of the CC that will be of greatest interest to them. Table 5.1 - Roadmap of Common Criteria Part 1: Introduction and general model -------------------------------------- Consumers/Procurers - Use for background information and reference purposes. Developers - Use for background information and reference for the development of requirements and specification material. Evaluators - Use for background information and mandatory statement of evaluation criteria for requirements & specifications. Part 2: Security functional requirements -------------------------------------- Consumers/Procurers - Use for guidance and reference on formulating statements of requirements for security function. Developers - Use for reference when interpreting statements of requirement and formulating security specifications. Evaluators - Mandatory statement of evaluation criteria when determining presence or absence of claimed security functions. Part 3: Security assurance requirements -------------------------------------- Consumers/Procurers - Use for guidance when determining required levels of assurance. Developers - Use for reference when interpreting statements of requirement and determining assurance approaches of TOE. Evaluators - Mandatory statement of evaluation criteria when determining the assurance of the TOE. Part 4: Predefined Protection Profiles -------------------------------------- Consumers/Procurers - Use for guidance and reference when formulating requirements. Developers - Use for reference when interpreting statements of requirement and formulation of security specifications. Evaluators - Mandatory reference base when determining claimed conformance to PPs. Part 5: Registration procedures -------------------------------------- Consumers/Procurers - Use for guidance when offering PPs for registration. Developers - Use for guidance when offering PPs for registration. Evaluators - Use for guidance when determining whether PPs are eligible for registration. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 17 of 108 Chapter 6 Scope and applicability 73 The CC has been developed primarily to support evaluation of the security properties of TOEs. The CC is also useful as a guide for development of products or systems with IT security features and for procurement of commercial products and systems. The CC defines a basis for evaluation of a TOE in order to establish the level of confidence that may be held in its IT security attributes. Such TOEs include IT products and systems which also encompass computer networks, distributed systems, and application services. 74 The aspects of IT security addressed by the CC include, but are not limited to, the protection of information from unauthorised disclosure, modification, or loss of use by countering threats to that information arising from human activities whether malicious or otherwise. Resistance to these three types of damage is generally called confidentiality, integrity, and availability, respectively. The CC is designed to be applicable to the aspects of IT security outside the domain of these three -for example non-repudiation. The CC may be appropriately used in other areas of IT, but makes no claim of competence outside the strict domain of IT security. 75 The CC is equally applicable to IT security measures implemented in hardware or software. Where particular aspects of evaluation are intended only to apply to certain methods of implementation, this will be indicated within the relevant criteria statements. Certain topics, because they involve specialised techniques, or because they are somewhat peripheral to IT security, are considered to be outside the scope of the CC. Some of these are identified below. 76 The CC is primarily concerned with the selection and evaluation of technical IT security measures. A significant part of the security of a TOE can often be achieved through non-technical administrative measures such as organisational, personnel, physical and procedural controls. The CC does not cover evaluation of such administrative IT security measures. Administrative IT security measures are considered only where these have impact on the technical IT security measures. 77 The evaluation of physical aspects of IT security such as electromagnetic emanation control is not discussed. 78 The organisation-specific evaluation methodology, and any scheme established to use the results generated by evaluation, are matters left up to individual jurisdictions. The CC provides technical evaluation criteria only and does not address the evaluation methodology or the administrative and legal framework under which the criteria may be applied. 79 The procedures for use of evaluation results in operational system accreditation are outside the scope. System accreditation is the administrative process whereby authority is granted for the operation of an IT system in its full operational context. D R A F T 6 - Scope and applicability CCEB-94/082 Page 18 of 108 Version 0.9 94/10/31 The CC focuses on the IT security parts of the system and those parts of the operating context which bear directly upon the IT elements. Accreditors should make their own provision for assessments of non-IT related system security properties and their relationship to the IT security parts. 80 The subject of criteria for the assessment of the inherent qualities of cryptographic algorithms and related techniques is not covered in the CC. Should independent assessment of mathematical properties of cryptography embedded in a TOE be required, the scheme under which the CC is applied must make provision for such assessments. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 19 of 108 Chapter 7 Common Criteria evaluation results 7.1 Introduction 81 There is no absolute scale for interpreting the results of an IT security evaluation. Binary results like "yes/no" or "good/bad", which are appropriate in other evaluation areas, are not reasonable in this domain. The results of a security evaluation derive from the application of criteria which contain both subjective and objective elements. Therefore precise and universal statements of IT security are not possible. 82 A rating made relative to these criteria represents an evaluation of the security properties of the TOE. It is insufficient, by itself, to imply the adequacy of the TOE for use in any particular environment. The decision of the fitness of the TOE for a particular usage and environment is a decision that requires the consideration of a variety of factors, the evaluation results being one of these. 7.2 Limitations on expression of security functions and assurance 83 The CC defines a single IT security criteria that can address the needs of many communities and thus serve as a major expert input to the production of an international standard for IT security. The CC has been developed around the central notion that use only of the security functional components and packages defined in Part 2 and the assurance levels and components defined in Part 3 represents the safest course of action for expression of TOE requirements, as they represent a well-known and understood domain. 84 The following limitations and caveats apply to the expression of security functions and assurance in PPs and STs. 7.2.1 Security functions and assurance in Protection Profiles 85 A PP is a successfully evaluated set of functional and assurance requirements. A PP is defined as a set of requirements that consist only of functional requirement components contained in Part 2 and an assurance level (possibly augmented by additional assurance components) contained in Part 3. D R A F T 7 - Common Criteria evaluation results CCEB-94/082 Page 20 of 108 Version 0.9 94/10/31 7.2.2 Security functions in Security Targets 86 The CC cannot prevent the articulation in STs of functional requirements not contained in Part 2. However, the following caveats apply to the inclusion of these novel functional components in STs: a) Any functional requirements presented in a ST shall comply in structure and content, as well as follow the construction rules, for functional components and packages in annexes B and D respectively. b) There is a limitation on evaluation results (compliance) when using functional components in STs not contained in Part 2 because evaluation of such components is risky. Including novel functional components in STs is more than conforming to the structure and rules and does not guarantee acceptance of the results of the evaluation by any scheme. 7.2.3 Assurance in Security Targets 87 ST assurance requirements shall consist of at least an assurance level (possibly augmented by additional assurance components) contained in Part 3. Assurance components other than those contained in Part 3 may be included in STs. However, the following caveats apply to the inclusion of these novel assurance components in STs: a) Any assurance requirements presented in a ST shall comply in structure and content, as well as follow the construction rules, laid out in annexes C and E. b) There is a limitation on evaluation results (compliance) for STs which contain assurance requirements not taken from Part 3. Addition of assurance requirements to an assurance level is not necessarily supportable and acceptable to other evaluation schemes, whether or not the additional assurance requirements are taken from the components contained in Part 3. However, additional assurances can not undermine existing ones, although the value of the additional assurance requirements may be indeterminate. 7.3 Definition of the CC evaluation results 88 The result of the evaluation shall be a statement which describes the extent to which the TOE can be trusted to conform to the requirements. The results shall be stated with respect to both Part 2 (security functional requirements) and Part 3 (security assurance requirements) and to the whole CC, as listed below. a) Conformant to Part 2: A TOE is conformant to Part 2 if and only if it is based upon functional components contained in Part 2. b) Part 2 Extended: A TOE is Part 2 extended if it is based upon functional components contained in Part 2 plus additional functional requirements not contained in Part 2. D R A F T CCEB-94/082 7 - Common Criteria evaluation results 94/10/31 Version 0.9 Page 21 of 108 c) Conformant to Part 3: A TOE is conformant to Part 3 if and only if it is based upon an assurance level contained in Part 3. d) Part 3 Augmented: A TOE is Part 3 augmented if and only if it is based upon an assurance level and other assurance components contained in Part 3. e) Part 3 Extended: A TOE is Part 3 extended if it is based upon an assurance level and optionally other assurance components contained in Part 3 plus additional assurance requirements not contained in Part 3. f) Conformant to CC: A TOE is conformant to the CC if and only if it is conformant to Part 2 and Part 3. 89 Although the evaluation results Part 2 extended and Part 3 extended are defined, it is recommended that these options only be used after very careful consideration of the preferred alternative of being conformant with the requirements presented in the CC. D R A F T 7 - Common Criteria evaluation results CCEB-94/082 Page 22 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 23 of 108 Chapter 8 Common Criteria levels of abstraction 8.1 Introduction 90 The CC uses a set of levels of abstraction for IT security. These concepts are: global security environment, TOE top level security objectives, TOE security requirements, TOE security specifications, and TOE. The TOE is the product or system. The environment defines the context in which the TOE operates. The objectives define the purpose of the TOE in terms of the threats the TOE must withstand. The requirements define the functions and assurance that are needed to meet the objectives. The specifications define how the requirements are met. These abstractions are introduced briefly below and explained in more detail in the following sections. For background information, also see annex I and figure I.3. a) Global security environment The global security environment includes all the laws, customs, expertise, and knowledge of the IT security field and defines the context within which the CC must operate. This environment does not relate to any specific requirement for IT security and is not further characterised in the CC. TOE representations must be consistent with the global security environment for which concepts such as reasonable, useful, and feasible are relevant. Criteria for determination of TOE consistency with this environment are partially addressed by the CC and relate to justification of the business case for the TOE. b) TOE Top Level Security Objectives (TLSO) The TLSO identify the threats which the TOE is required to counter, the local environment in which it is to operate, and any assumptions about the intended use of the TOE. TOE representations must be consistent with their TLSO. Criteria for determination of TOE consistency with the TLSO are within the scope of the CC and relate to justification of the case for effectiveness of the TOE. c) TOE security requirements The TOE security requirements are derived from the TLSO and additional requirements analysis. The requirements analysis will determine the proper balance between IT and non-IT security measures leading to a precise statement of the IT security requirements for a TOE in terms of functions and assurances. TOE representations must be consistent with the security requirements. Criteria for determination of TOE consistency with security requirements D R A F T 8 - Common Criteria levels of abstraction CCEB-94/082 Page 24 of 108 Version 0.9 94/10/31 are within the scope of the CC and relate to justification of the case for correctness of the TOE. d) TOE security specification The TOE security specifications are derived from the security requirements through a process of design refinement and are the precise statements of functions and assurance that are provided by the TOE in order to meet the security requirements. Implementation of the TOE must be consistent with its security specifications. Criteria for determination of TOE consistency with security specifications are within the scope of the CC and relate to justification of the case for correctness of the TOE. e) TOE The TOE is the complete IT system or product that implements the security specifications. The TOE includes representations of all implementation refinements and evidence that the security requirements have been addressed. The CC provide criteria for the evaluation of correctness of representations of the TOE and criteria for evaluation of the correct use of the TOE. 91 Example: As an example of these levels of abstraction, the exemplary PP Commercial Security Requirements Level 1 PP (CS1) is used. CS1 defines the TLSO for operating systems in general commercial usage. One top level security objective for CS1 is that the TOE protects its assets from unauthorised access. An example CS1 threat is that an authorised user of a TOE may attempt to gain access to resources for which the user is not authorised. An example CS1 environmental assumption is that a TOE is protected against unauthorised physical access. An example CS1 usage assumption is that the user authorisations are set up correctly. This is input for the requirements analysis which leads to a precise statement of technical security requirements for a TOE. The detailed specification of a CS1- compliant product would be the TOE security specification. The CS1-compliant product itself is the TOE. 92 The descriptions and definitions of TOE security are contained in documents which characterise the TOE security at all levels of abstraction. Other than the explicit requirements levied on the PP and ST, the CC does not constrain the TOE documentation set to adopt a particular structure or naming convention. 8.2 Top Level Security Objectives 93 The statement of TLSO is the most abstract characterisation of the TOE security. The TLSO state the problem the TOE is required to address and are the basis for determining the effectiveness of the TOE. The TLSO are amplified or restated as necessary within the ST. D R A F T CCEB-94/082 8 - Common Criteria levels of abstraction 94/10/31 Version 0.9 Page 25 of 108 94 The qualitative and quantitative statements about the usage, environment and threats should be of sufficient depth to permit justification of the TOE security requirements and to assess the impact of any residual vulnerabilities of the TOE. 95 The CC does not set presentational requirements for the TLSO material. Much of the TLSO material may be determined by pre-existing legislation and relevant organisational security policies. Where necessary, reference may be made to the policy supported by any interpretations necessary for proper characterisation of the TOE. 96 The requirements for TLSO definition are contained in annexes F and G. 8.3 Security requirements 97 Technical security requirements for a TOE are developed in response to the TLSO. The development of the security requirements is essentially one of engineering refinement and risk analysis and draws on the existing knowledge about security requirements where applicable. 98 The PP is the CC instrument for the expression of security requirements for a set of TOEs. Annex F defines the presentational and content requirements for PPs. Security requirements for a single TOE shall be expressed in an ST in accordance with annex G. 8.3.1 Source of requirements 99 TOE security requirements are constructed from the component security requirements. Part 2 of the CC contains the functional security components which should be used to express functional security requirements for a TOE. Part 3 of the CC contains the assurance components used to form the assurance levels which are the mandatory CC scale for assurance requirements. The following are the possible inputs to the development of the TOE security requirements: a) Existing PPs The TOE security requirements may be adequately expressed by, or are intended to comply with, a pre-existing statement of requirements contained in an existing PP. b) Existing packages Part of the TOE security requirement may have already been expressed in a package. c) CC assurance levels The TOE assurance requirement shall include a CC assurance level. d) CC requirements components The TOE requirements may be expressed directly, using the components of the CC. D R A F T 8 - Common Criteria levels of abstraction CCEB-94/082 Page 26 of 108 Version 0.9 94/10/31 e) Additional requirements Additional security requirements, if needed, shall be stated explicitly following the rules in annexes B and C and are subject to the caveats in chapter 7. 100 Existing requirements material should be used where available. The use of an existing PP will ensure that the TOE will meet a well known set of needs of known utility and thus be more widely applicable. 8.3.2 Construction of requirements 101 Unless the TOE is to be built to satisfy only the requirements of an existing PP, some requirements construction and validation will be necessary. The PPs, packages, and components contain statements of objectives and explanations which should be used as guidance when selecting the requirements components. 102 The TOE assurance requirements shall, as a minimum, incorporate a CC assurance level. The assurance requirements may be supplemented by additional CC assurance components subject to their dependencies being satisfied. 103 The complete TOE security requirements must be subjected to a dependency analysis to demonstrate that all of the dependencies of the components incorporated have been satisfied. The dependency analysis must also cover all components of any incorporated profiles and packages. 104 The security requirements shall be supported by a rationale showing how the stated requirements meet the security objectives of the TOE. 8.3.3 Re-use of security requirements 105 Packages are specific groupings of components, either functional or assurance. These combinations provide a homogeneous set of requirements intended to counter a list of identified threats. A package basically addresses common users' needs, e.g.'identification and authentication for smartcards'. 106 Useful combinations of components may be submitted for consideration as reusable packages. Functional packages shall be expressed and evaluated in accordance with annex D. 107 Complete and justified statements of requirements including only CC functional requirements and a CC assurance level, possibly augmented by additional CC assurance components, may be submitted for consideration as reusable PPs. PPs shall be expressed and evaluated in accordance with annex F. PPs which have been shown to be compliant with the CC may be submitted for admittance to a register of protection profiles which are then available for wider use. Editor Note: No such registry is currently under development. D R A F T CCEB-94/082 8 - Common Criteria levels of abstraction 94/10/31 Version 0.9 Page 27 of 108 8.4 Security specifications 108 Security requirements are envisioned by the CC to be generic thus allowing a variety of specific implementations. When applying these requirements to a TOE, the developer must demonstrate how they are met. 109 The TOE specification is derived by applying security and IT engineering skills and knowledge to the security requirements. The high level descriptive subset of the TOE specification states how the security requirements will be met and is described in the ST. The ST is therefore the basis for the evaluation. 110 The TOE specification refines the security requirements and TOE description. 8.5 Strength of TOE functions 8.5.1 Strength of TOE function rating 111 Certain security functions possess a potential vulnerability for which a quantitative analysis of the exploitability of that vulnerability is meaningful. Part 3 defines three levels of threat intensity to describe ascending levels for strength of TOE functions. These levels are used in the interests of achieving a common understanding and simple rating of the strength of the TOE functions. The use of such a claimed strength of TOE function rating does not replace the explicit statement of threats in the TLSO. The threat intensity levels corresponding to strength of TOE function are summarised below: a) For a TOE function to be rated as `suitable for use in a category C threat environment', it shall be shown that the TOE function provides protection against unintended or casual breach of TOE security by attackers possessing a low level of expertise, opportunities, resources and motivation. However, such a TOE function may be capable of being defeated by a knowledgeable attacker. b) For a TOE function to be rated as `suitable for use in a category B threat environment', it shall be shown that the TOE function provides protection against attackers possessing a moderate level of expertise, opportunities, resources and motivation. c) For a TOE function to be rated as `suitable for use in a category A threat environment' it shall be shown that the TOE function provides protection against attackers possessing a high level of expertise, opportunity, resources and motivation. A successful attack is judged as being beyond normal practicality. 8.5.2 Strength of TOE function claim 112 The claimed strength of TOE function rating, when used in the ST TOE functions statement, shall be made by specifying one of the strength of function components D R A F T 8 - Common Criteria levels of abstraction CCEB-94/082 Page 28 of 108 Version 0.9 94/10/31 in Part 3 for each TOE function that requires such a claim. This rating shall be supported by an analysis contained in the rationale which justifies that claim. 8.5.3 Strength evaluation 113 Representations of the TOE presented for evaluation shall be supported by a vulnerability analysis. Part of the vulnerability analysis shall present a reasoned argument demonstrating that the security functions defined in the representations are sufficient to counter the threats defined in the TLSO. This part of the vulnerability analysis will focus on those functions and implementations of functions which possess a vulnerability and for which a quantitative analysis of the exploitability of that vulnerability is meaningful. The vulnerabilities shall be analysed in the context of the entire TOE. This analysis shall disregard functions which are a correct implementation of a required security policy for which the policy admits to vulnerabilities. Editor Note: More work is needed here on reconciling the analysis of strength at the mechanism level with the rating of strength at the function level and the general support for the ITSEC strength of mechanism concept. The terms `category A/B etc.' are placeholders pending agreement on the actual terms to be used. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 29 of 108 Chapter 9 Evaluation of requirements and specifications 9.1 Evaluation of requirements 114 Security requirements, in the form either of a PP or the TLSO and requirements statements of a ST, shall be subjected to a technical evaluation and shown to meet the criteria in annex F (for PP) or annex G (for ST). 115 For security requirements to be useful to producers, consumers, procurers, developers, and evaluators, they shall have certain evaluatable technical properties. The primary goal of the requirements evaluation is to determine whether the profile is fit for purpose. Further, the evaluation of the requirements shall show that it is appropriate to use them as the basis for evaluation of TOEs. 9.2 Evaluation of specifications 116 The security specifications shall be evaluated as part of the overall TOE evaluation process. Detailed requirements for evaluation of the TOE description in the ST are contained in annex G. A brief discussion of the approach is given here. 117 The evaluation of a ST considers effectiveness and correctness. The TLSO in a ST shall be shown to describe a valid set of security problems. The TOE description shall be shown to specify an effective solution to these problems. The assurance specifications shall be shown to be appropriate in meeting the security objectives identified in its TLSO. Finally, the statement of assurance shall be shown to ensure that the residual level of risk is acceptable and that the TOE is suitable for its intended environment of use. Editor Note: This chapter should be reworked into a discussion of the nature and need for evaluation of PPs and STs. Particular issues of concern are: - The need for evaluation of requirements in general; - needs for evaluation of STs to scope the viability and cost of evaluation and as a vehicle for documenting the supplier claims; -Where the ITSEC suitability and binding concepts are covered. D R A F T 9 - Evaluation of requirements and specifications CCEB-94/082 Page 30 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 31 of 108 Annex A Glossary of terms related to information technology security evaluation (normative) A.1 Access type 118 A specific type of interaction which can be carried out on an Object. A.2 Access right 119 A granted permission for a User or Subject to carry out an Access Type. A.3 Accountability 120 The property that responsibility for events can be determined. A.4 Accreditation 121 The administrative process of granting authority. A.5 Assurance 122 Property of a TOE giving grounds for confidence that the TOE is secure. A.6 Assurance level 123 A predefined set of assurance components that assigns a measure to the inherent security quality of the TOE. An indication of the totality of assurance measures applied to a TOE. A.7 Augmentation 124 The addition of one or more assurance component(s) to an assurance level. A.8 Authorised user 125 A user who has a specific right or permission to do something described in the TSP. A.9 Availability 126 The property that information and/or services are not being withheld in an unauthorised manner - and thus are accessible when needed without undue delay. D R A F T A - Glossary of terms related to information technology security evaluation Page 32 of 108 Version 0.9 94/10/31 A.10 Behaviour 127 A description of a response to postulated interactions. A.11 Class 128 A group of related Families which reflects a specific set of security objectives. A.12 Component 129 The smallest selectable set of requirements that may be included in a Protection Profile, a Security Target, or a Package. A.13 Confidentiality 130 The property that information is not disclosed in an unauthorised manner. A.14 Constrained 131 A qualifier implying: within the TSF Scope of Control (TSC). A.15 Correctness 132 The preservation of relevant properties between levels of representations. A.16 Dependency 133 A.17 Effectiveness 134 A judgment that the TOE has the security behaviour desired and counters the threats postulated. A.18 Element 135 An indivisible security requirement which is to be satisfied during an evaluation. A.19 Encapsulation 136 Enveloping a user or resource in a defined set of attributes and permissible access types. A.20 Family 137 Grouping of related components that all address the same type of threats. A.21 Formal 138 Based upon precise and unambiguous syntax and semantics. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 33 of 108 A.22 Human user 139 A person who interacts with the TOE. A.23 Informal 140 Expressed in natural language. A.24 Integrity a) The property that information or resources are not improperly affected. b) The property that assumptions about the known or expected state of information or resources remain true. A.25 Machine user 141 A machine, group of machines or other logical entity outside of the TOE with interacts with the TOE. A.26 Object 142 An encapsulated resource visible at the TSF interface and upon which a defined set of operations can be performed. A.27 Package 143 A set of components combined together to satisfy a set of identified objectives. A.28 Protection Profile (PP) 144 A combination of security requirements including assurance and functional requirements with associated rationale and target environment A.29 Resource 145 Anything usable or consumable in the TOE not directly visible at the TSF interface. A.30 Role 146 A defined set of functionally related operations, and the authorisations necessary to perform those operations, which may be assigned to users. A.31 Security administrator 147 A user or user role about which assumptions of correct behaviour need to be made to ensure the continuing correct operation of the TOE. D R A F T A - Glossary of terms related to information technology security evaluation Page 34 of 108 Version 0.9 94/10/31 A.32 Security attribute 148 Information, controlled by the TSF and used in TSP enforcement, about a user, subject, resource or object. A.33 Security domain 149 Scope of potential interaction as enforced by the TSF. A.34 Security Function (SF) 150 A part or parts of the TOE which enforce a closely related subset of the rules and objectives from the TOE Security Policy (TSP). A.35 Security Function Policy (SFP) 151 A closely related subset of the rules and objectives of the TSP. The security policy enforced by a security function (SF). A.36 Security mechanism 152 The logic or algorithm that implements all or part of a security function (SF). A.37 Security policy 153 Set of rules designed to meet a set of security objectives. A.38 Security Target 154 The statement of security requirements and functional specification to be used as the baseline for an evaluation. A.39 Semiformal 155 Expressed in a restricted syntax language with defined semantics. A.40 Subject 156 An entity within the TSF Scope of Control (TSC) and constrained by the TSF to a single security domain. A.41 Target of Evaluation (TOE) 157 The part of an IT system or product that is subjected to security evaluation. A.42 TOE Security Functions (TSF) 158 All parts of the TOE which have to be relied upon for enforcement of the TOE Security Policy (TSP). D R A F T CCEB-94/082 A - Glossary of terms related to information technology security 94/10/31 Version 0.9 Page 35 of 108 A.43 TOE Security Policy (TSP) 159 The totality of the rules and objectives defining the security behaviour of the TOE. A.44 Top Level Security Objectives (TLSO) 160 A high level statement of intended security goals. A.45 Trusted channel 161 The means by which two TSFs can communicate directly with necessary confidence to support the TSPs of each TSF. A.46 Trusted Computing Base (TCB) 162 The TOE Security Functions (TSF) which implement the reference monitor concept as follows: a) The TSF are tamperproof; b) The TSF are always invoked to enforce access checks; and c) The TSF are simple enough to be analysed to the requirements of the target assurance level. A.47 Trusted path 163 A means by which a User and a TSF can communicate directly with necessary confidence to support the TSP of the TSF. A.48 TOE Security Functions Scope of Control (TSC) 164 The environment over which the TSF maintains enforcement of the TSP and beyond which the TSF does not or cannot maintain enforcement. A.49 Untrusted 165 A qualifier implying that no assumptions about correct behaviour need to be made in order to ensure the correct enforcement of the TSP. A.50 User 166 Something or someone outside the Target of Evaluation (TOE) that interacts with the Target of Evaluation. D R A F T A - Glossary of terms related to information technology security evaluation Page 36 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 37 of 108 Annex B Specification of functional requirements (normative) B.1 Overview 167 This annex defines the requirements for content and presentation and the construction rules of the functional requirements of the CC. The set of functional requirements presented in Part 2 complies with these rules. These rules are mandatory for the specification of functional requirements which may be considered as candidates for incorporation in future issues of the CC. 168 These requirements form the basis for criteria against which such requirements are evaluated. These rules are mandatory for functional requirements not provided in Part 2 of the CC. B.2 Class structure 169 Figure B.1 below illustrates the required functional class structure in diagrammatic form. Functional Security Class | | - Class Name | | - Class Introduction | | - Security Functional Families Figure B.1 - Functional class structure. D R A F T B - Specification of functional requirements (normative) CCEB-94/082 Page 38 of 108 Version 0.9 94/10/31 170 The grouping of families in a class is based on the common intent or approach of those families to satisfy security objectives, described in an introduction section. The definition of functional classes does not reflect any formal taxonomy in the specification of the requirements. The proposed approach in Part 2 annex A of the CC reflects the common understanding issued from the existing criteria. Each class is identified by a short name. This is the principal reference name for the class and it is used in the specification of the short names of the families of this class. B.2.1 Family structure Functional Security Family | | - Family Name | | - Family Behaviour | | - Threats | | - Application Notes | | - User Notes | | - Evaluator Notes | | - Audit Notes | | - Documentation Notes | | - Other Relevant Families | | - Component Levelling | | - Components Figure B.2 - Functional family structure 171 Figure B.2 illustrates the required functional family structure in diagrammatic form. B.2.2 Family name 172 The functional family name section provides categorical and descriptive information necessary to identify and categorise a component family. Every functional family shall have a unique name. 173 All new functional families should be assigned to one of the relevant classes as defined in the taxonomy contained in Part 2. 174 A unique short form of the family name shall be provided. This is the principal reference name for the component family. D R A F T CCEB-94/082 B - Specification of functional requirements (normative) 94/10/31 Version 0.9 Page 39 of 108 B.2.3 Family behaviour 175 The component family behaviour is the narrative description of the component family stating its security objective, a general description of the functional requirements, and the rationale justifying the claim that the functional requirements counter the threats. These are described in greater detail below: a) The security objectives of the component family shall be a clear and concise statement of the security problem for which a TOE incorporating a component belonging to the family contributes to the solution. b) The description of the functional requirements shall summarise what requirements are included in the component(s). It shall be sufficiently general to apply to all the components. It is aimed at potential users who wish to assess whether the component family is relevant to their specific requirements. c) The rationale for the component shall explain, at a high level, why the functions expressed are suitable to counter the stated threats in the indicated threat environment. It is aimed at authors of PPs and STs incorporating a component of the family. B.2.4 Threats 176 The statement of threats or threat environment for the component family shall state the categories of threat which the component family is intended to counter. The description should be kept at a general level, specific details of threats should be incorporated in the component belonging to the family where the threat intensity can be related to the actual functional elements included. 177 The threat statements are the specific threat statements against which the Security Target of the TOE is evaluated and shall be specific instances of the generic threat descriptions for the component family. 178 The identified threats do not necessarily represent a complete list of uses for the component. They do not guarantee the suitability of a specific mechanism or collection of mechanisms against the stated threats. B.2.5 Application notes 179 Application notes contain additional narrative qualifications of the components as listed below: a) The user notes contain additional information which is of interest to potential users of the component, that is PP and ST writers and designers of TOEs incorporating the component. The presentation is informal and would cover, for example, warnings about limitations of use and areas where specific attention might be required when using the component. D R A F T B - Specification of functional requirements (normative) CCEB-94/082 Page 40 of 108 Version 0.9 94/10/31 b) The evaluator notes contain any information which is of interest to evaluators of TOE's claiming compliance to the component. The presentation is informal and can cover a variety of areas where specific attention might be needed when evaluating the TOE. This can include what needs to be documented to support the required functional behaviour, as well as caveats and warnings of specific interest to evaluators. c) The audit notes contain guidance information which may be of interest to PP/ST writers in the selecting of auditable events if FAU Security Audit is included in the PP/ST. The presentation is informal and is in the form of suggestions to the PP/ST writers. These suggestions should include security relevant events in terms of the various levels of detail supported by the components of the FAU_GEN Security Audit Event Generation family. For example, an audit note might include actions that are in terms of: Minimal - successful use of the security mechanism; Basic - any use of the security mechanism as well as relevant information regarding the security attributes involved; Detailed - Any configuration changes made to the mechanism including the actual configuration values before and after the change. d) The documentation notes contain information which may be of interest to PP/ST writers in performing assignment operations on documentation components. The presentation is informal and is in the form of suggestions which are not considered as mandatory on the part of PP/ST writers. 180 These note sections are not mandatory and should only appear if appropriate. B.2.6 Other relevant families 181 Any other family offering partial coverage of any threat shall be cross referenced for completeness. This information helps a PP or ST author to find all the components related to a threat. B.2.7 Component levelling 182 Functional component families contain one or more components, any one of which can be selected for inclusion in security functional packages, PPs, and STs. The goal of this section is to provide information to users in selecting an appropriate functional component once the family has been identified as being a necessary or useful part of their security requirements. 183 This section of the functional family description shall describe the components available, their rationale, and the relationships between components. The exact details of the components are contained within each component. For a component family with only one component, this part of the functional family should contain a statement to the effect that the component family currently only contains one component. 184 Functional families containing more than one component shall be levelled and shall provide rationale as to how these components are levelled. This rationale shall be in terms of coverage, scope, and granularity as defined in section B.4.1 of this D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 41 of 108 annex. The relationships between components within a functional family may or may not be hierarchical. Families containing more then one component shall be numbered sequentially according to level, starting from 1. Each component beyond the first component shall describe any additional elements or changes to elements of the component of the previous level, as well as a description of the threats countered by the additional or modified elements. B.2.8 Components 185 The relationship between components within a family shall be highlighted using a bolding convention. This bolding convention includes the bolding of all new requirements. For hierarchical components, requirements shall be bolded that are enhanced or modified beyond the requirements of the previous component. In addition, any new or enhanced threats, application notes, permitted operations, and/ or dependencies beyond the previous component shall also be highlighted using bold type. B.2.9 Component structure Component | | - Component Identification | | - Component Rationale and Application Notes | | - Permitted Operations | | - Dependencies | | - Functional Elements Figure B.3 - Functional component structure 186 Figure B.3 illustrates the required functional component structure in diagrammatic form. B.2.10 Component identification 187 The component identification section provides descriptive information necessary to identify, categorise, register, and cross-reference a component. The following must be provided in every functional component: D R A F T B - Specification of functional requirements (normative) CCEB-94/082 Page 42 of 108 Version 0.9 94/10/31 188 A unique name. The name should reflect the purpose of the component. 189 A short name. A unique short form of the functional component name shall also be provided. This short name will serve as the principal reference name for the categorisation, registering and cross-referencing of the component. 190 A hierarchical-to list. A list of other components which this component is hierarchical to and for which this component can be used to satisfy dependencies to the listed components. B.2.11 Component rationale and application notes 191 Any specific information, related to the component should be provided in this section to emphasis the description of the threats, the rationale, and the application notes defined in the family. - The rationale contains the specifics of the rationale which amplifies the general statements on rationale for the specific level and should only be used if level specific amplification is required. - The application notes are optional on a per needed basis. If appropriate, this section would contain additional amplification in terms of narrative qualification as it pertains to a specific component. This amplification can pertain to user notes, audit notes and/or documentation notes as described in section B.2.5 of this annex. B.2.12 Permitted operations 192 Components may be tailored through use of prescribed operations before being incorporation into a PP, an ST, or a functional package, based on the particular environment of use and security policies being addressed. The possible operations are defined in section B.5.6. Not all operations are permitted on all functional components. Each component shall contain a description of those operations, the nature under which the operation can be applied to the component, and the results of the application of this operation. "No permitted operation" is an acceptable description. B.2.13 Dependencies 193 For each functional component there shall exist a complete list of dependencies among functional components, and between functional and assurance components. "No dependencies" is an acceptable list. 194 Dependencies among functional components arise when a component is not self sufficient and relies upon the functionality of, or interaction with, another component. In addition, functional dependencies can exist because different components implement the same policies (properties) or requirement(s), individually or together. The type of each dependency should be specified. Types of dependencies are defined in section B.5.7. D R A F T CCEB-94/082 B - Specification of functional requirements (normative) 94/10/31 Version 0.9 Page 43 of 108 195 If there exists a dependency to a component within a family where the components are levelled in a hierarchical manner, then dependencies can be specified to this family in an abbreviated nature. If the condition exists where component n is identify as a dependency then components hierarchically greater then component n also satisfy the dependency. B.2.14 Functional elements 196 A set of elements shall be provided for each component. Each element shall be individually defined and shall be self-contained. 197 A functional element is a security functional requirement which if further divided would not yield a meaningful evaluation result. It is the smallest security functional requirement recognised in the CC. B.3 Construction rules for classes 198 B.4 Construction rules for families 199 B.4.1 Method used in levelling components 200 The method used in levelling components shall be included with each functional family. Levelling information could provide insight that could be used in selecting an appropriate level within a component. 201 The levelling of each functional component is based on one or more of the following three parameters: a) The coverage of a requirement's features; b) The scope of the requirement application; c) The granularity of the requirement. 202 The coverage of a component determines the behavioural policy subset under which requirements are included in a component level. As new requirements are added, the coverage increases. Coverage is illustrated using the following examples: - TCB self-checking may be on a periodic or continuous basis; - Recovery may be manual or automatic; D R A F T B - Specification of functional requirements (normative) CCEB-94/082 Page 44 of 108 Version 0.9 94/10/31 - Protection requirements may include isolation features, but not consistency features; - Physical TSF protection may include attack detection and deterrence requirements, but not attack countermeasures. 203 The scope of a component determines the entity subset to which the component applies. Scope is illustrated using the following examples: - To all the users, subjects and objects, or only a defined subset thereof; - To all the TSF functions and application programming interfaces, or only a defined subset thereof; - To all the TSF elements (i.e., hardware, firmware, software, data structures and code), or only a defined subset thereof; - To all TSF configurations, or only a defined subset thereof. 204 The granularity of a component determines the entity- attribute subset to which the component applies (e.g., whether the requirement applies to all attributes of users, subjects or objects, or only to a defined subset of attributes). Granularity is illustrated using the following examples: - Some components may refer to access rights for objects and subjects, but not to object and subject status variables; - Privileges may be associated with roles, but not with individual functions or actions; - Authentication may be based on group or role identities, but not on individual user identity. B.4.2 Other rules 205 B.5 Construction rules for components 206 The requirements shall be stated at a level of abstraction that is largely implementation independent, and yet sufficiently detailed in that they are unambiguous and measurable. Each element of the component should be specified as a single and complete requirement statement. Each component and element should be written at a level of detail that allows for the mapped back to the individual threats described in the family section. In addition, each component element should be written at a sufficient level of abstraction to provide a designer of a TOE with a clear description of the required functionality. Upon implementation of the required functionality, it shall be possible for the user and D R A F T CCEB-94/082 B - Specification of functional requirements (normative) 94/10/31 Version 0.9 Page 45 of 108 evaluator to determine that the requirements stated in the functional component has been satisfied. 207 Functional components shall not contain requirements designed to meet any specific national or sector security need. Each component shall be generally applicable to a large variety of enterprise security policies. B.5.1 Measurable 208 Each element of the component shall present objective criteria and be separately evaluatable by objective means. Each element shall state objective evaluation requirements in that compliance or non-compliance of a TOE can be systematically demonstrated. That is, evaluation techniques exist that can be effectively applied with predictable results. Each element shall be separately and independently evaluatable by independent laboratories yielding similar evaluation results. This assumes that each element can be evaluated using techniques that are universally available and known to be technologically achievable by all approved evaluation laboratories. In addition, each element should generally apply to some subset of the types of TOEs that are described to be within the scope of the CC. B.5.2 Evaluatable 209 In order for the component, to be considered to be evaluatable, it shall satisfy the following requirements: - The strengths and weaknesses inherent in the security requirements shall be well understood by the evaluation community; - The existing assurance criteria as defined in Part 3 shall be relevant and applicable with the existing evaluation technology; - Any TOE that is intended to satisfy the requirements shall be capable of being evaluated through use of internationally recognised and repeatable techniques; - There shall exist the capability to develop clear and explicit guidelines that specify the evaluator actions to be performed and what constitutes success. 210 Questions that should be readily answered in regard to a component include the following: - What evidence must be examined, and/or tests performed, in judging each requirement element? - Is the phrasing of each requirement clear and concise? - Is it self-evident when the requirements have been met? - If this is not possible, what factors are to be considered in determining whether the requirement has been met? D R A F T B - Specification of functional requirements (normative) CCEB-94/082 Page 46 of 108 Version 0.9 94/10/31 211 If the component does not satisfy these conditions, the information necessary to bring the component into compliance shall be provided with the component itself. B.5.3 Technically feasible 212 For each element of the component it should be practical to implement a TOE meeting the requirements. As such, the development and implementation of required functions should be possible through the use existing technology. Each element shall either be obviously developable given today's technology or provide some references to the evidence that it is developable. 213 Questions that should be readily answered in regard to a component include the following: - Are there examples of the function in common use? - Are there examples being developed? - Is there proof-of-concept evidence? - What types of resources (including expertise) are required for its development? B.5.4 Unique 214 No other component shall be viewed as implementing the same set of requirements. There may be an overlap between different components such as a superset, subset, or jointly shared requirements. 215 Relevant questions to be answered to determine uniqueness are the following: - Do the threats described in this component very closely resemble those of any other existing component? - If yes, is there a significant difference between the two components? - Does the proposed required functionality closely resemble those of any other existing component? - If yes, is there a significant difference between a resulting evaluator action between the two components? B.5.5 Unambiguous 216 Each element of the component shall be expressed as a clear and concise statement of requirements to minimise the need for interpretation. From a developer's perspective each component element should clearly present requirements as to what design and implementation steps need to be taken. From an evaluator's perspective each component element should be complete and sufficient in describing the required behaviour of the TOE. D R A F T CCEB-94/082 B - Specification of functional requirements (normative) 94/10/31 Version 0.9 Page 47 of 108 B.5.6 Permitted operations 217 The functional components used in the definition of the requirements in a PP, an ST, or a functional package may be exactly as specified in the annexes of this part, or they may be tailored to meet a specific need, security policy, or environment of use (i.e., security objective). However, selecting and tailoring these functional components is complicated by the fact that dependencies must be considered. Thus, this tailoring must be restricted to an approved set of operations. 218 A list of permitted operations shall be included with each functional component. Not all operations are permitted on all functional components. 219 The permitted operations shall be selected from the following set: - Assignment: allows the specification of an identified parameter; - ; Refinement: allows the addition of details. B.5.6.1 Assignment 220 Some functional component elements contain parameters or variables which enable the PP/ST writer to specify a policy or a set of values for incorporation into the PP or ST to meets a specific security objective. These elements will clearly identify each parameter and the complete set of acceptable values that may be assigned to that parameter. 221 Any aspect of an element whose acceptable values can be unambiguously described or enumerated can be represented by a parameter. The description or enumeration must limit the permissible values in such a way that all possible choices will have the same dependencies (i.e., no choice will cause the listed dependencies to change). 222 The parameter may be an attribute or rule which narrows the requirement to a specific value or range of values. For instance, based on a specified security objective, the functional component element may state that a given operation must be performed a number of times. In this case, the assignment would provide the number, or range of numbers, to be used in the parameter. B.5.6.2 Refinement 223 Some functional component elements permit the PP/ST writer to limit the set of acceptable implementations by specifying additional detail in order to meet a security objective. These elements will be clearly identified. Refinement of an element consists of adding these technical details. 224 The refinement does not levy any new requirements (i.e., all pre-existing requirements in the element are still present and enforced) but applies an elaboration, interpretation, or meaning to a requirement, rule, constant, or condition based on security objectives. The refinement shall only further restrict the set of possible acceptable functions or mechanisms to implement the requirements but never increase it. Because refinement does not allow new requirements to be D R A F T B - Specification of functional requirements (normative) CCEB-94/082 Page 48 of 108 Version 0.9 94/10/31 created or existing requirements to be deleted, refinement should not have any impact on the list of dependencies associated with a component. B.5.7 Dependency analysis 225 The analysis of the dependencies between components must be performed during component construction. Such analysis helps avoid inadequate or incorrect profile specification and determines the effect of profile changes (e.g., addition of or removal of requirements. These dependencies exist among functional components, among assurance components, and among functional and assurance components. Dependencies among functional components arise because the functions that implement a functional component depend on functions implementing other functional components, or because different functions implementing different component elements must implement the same policies (properties), individually or together. 226 Thus, a distinction is made between the uses and policy types of functional dependencies: - There exists a uses dependency between two functional components A and B if the correct operation of functions implementing A assumes the correct operation of functions implementing B; - There exists a policy dependency between two functional components A and B if functions implementing both A and B must implement, either individually or together, a property or conditions required by the policy. 227 A functional component has a uses dependency on an assurance component if the assurance component becomes necessary when ever the functional component is used. The analysis of the dependencies between functional components and assurance components helps to determine whether a functional component can be correctly designed, analysed, implemented, and evaluated given the selected assurance level. B.5.8 Hierarchical relationship analysis 228 The analysis of the hierarchical relationship between components must be performed during component construction. This is necessary to ensure that hierarchical components are correctly and consistently levelled. The practical implication of this analysis has direct impact on dependency analysis. B.6 Functional component evaluation criteria 229 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 49 of 108 Annex C Specification of assurance requirements (normative) C.1 Overview 230 This annex defines the requirements for content and presentation and the construction rules of the assurance requirements of the CC. The set of assurance requirements presented in chapter 2 of Part 3 complies with these rules. C.2 Assurance class structure 231 Figure C.1 illustrates the required assurance class structure in diagrammatic form. C.2.1 Name 232 Every assurance class is assigned a unique name. The name provides descriptive information about the topics covered by the assurance class. 233 A unique short form of the assurance class name is also provided. This is the primary means for referencing the assurance class. Assurance class | | - Name | | - Families Figure C.1 - Assurance class structure D R A F T C - Specification of assurance requirements (normative) CCEB-94/082 Page 50 of 108 Version 0.9 94/10/31 C.2.2 Families 234 All assurance classes contain at least one assurance family. The structure of the assurance families are described in the following section. C.3 Assurance family structure 235 Figure C.2 illustrates the required assurance family structure in diagrammatic form. Functional Family | | - Name | | - Objectives | | - Threats | | - Component Levelling | | - Application Notes | | - User Notes | | - Documentation Notes | | - Components Figure C.2 - Assurance family structure D R A F T CCEB-94/082 C - Specification of assurance requirements (normative) 94/10/31 Version 0.9 Page 51 of 108 C.3.1 Name 236 Every assurance family is assigned a unique name. The name provides descriptive information about the topics covered by the assurance family. Each assurance family is placed within one assurance class. 237 A unique short form of the assurance family name is also provided. This is the primary means used to reference the assurance family. C.3.2 Objectives 238 The objectives section of the assurance family provides the overall purpose and goals of the assurance family (i.e., it is used to justify the existence of the assurance family). C.3.3 Threats 239 The threats section of the assurance family provides the categories of threats which the family is intended to counter. The description for the assurance family is kept at a general level. Any specific details required for threats are incorporated in the particular assurance component. C.3.4 Component levelling 240 An assurance family may contain one or more assurance components. This section of the assurance family describes the components available and explains the distinctions between them. Its main purpose is to provide information for selecting the appropriate assurance component once that it has been determined that the assurance family is a necessary or useful part of the security requirements. 241 This part of the assurance family shall describe the components available and explain the relationship between them and the rationale for creating them. The exact details of the components are contained within each component. For a component family with only one component, this part of the assurance family should contain a statement to the effect that the component family currently only contains one component. 242 Assurance families containing more than one component shall be levelled and shall provide rationale as to how these components are levelled. This rationale shall be in terms of coverage, scope and granularity as defined in section C.6 of this annex. Families containing more than one component shall be numbered sequentially according to level, starting from 1. Each component beyond the first component shall describe any additional elements or changes to elements of the component of the previous level, as well as a description of any threats countered by the additional or modified elements. D R A F T C - Specification of assurance requirements (normative) CCEB-94/082 Page 52 of 108 Version 0.9 94/10/31 C.3.5 Application notes 243 The application notes section of the assurance family contains additional narrative qualification of the assurance family. The application notes section is divided into two subsections: user notes and documentation notes. C.3.5.1 User notes 244 The user notes subsection contains additional information which is of particular interest to users of the assurance family e.g., PP and ST writers and designers of TOEs incorporating a component from this assurance family. The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required. C.3.5.2 Documentation notes 245 The documentation notes subsection contains requirements describing the items that must be described in assurance documentation. C.3.6 Components 246 All assurance families have at least one assurance component. The structure of the assurance components is provided in the following section. C.4 Assurance component structure 247 Figure C.3 (next page) illustrates the required assurance component structure in diagrammatic form. C.4.1 Objectives and threats 248 The objectives and threats section of the assurance component contains specific objectives and threats for the particular assurance component if required. Not all assurance components have an objectives and threats section. 249 For those assurance components that have this section, it contains the specific purpose and goal of the component and a more detailed explanation of the threats countered. 250 The objectives and threats section of the assurance component is consistent with the objectives and threats identified for the assurance family. 251 The modification of objectives and threat from one component to the next are highlighted using bold text. D R A F T CCEB-94/082 C - Specification of assurance requirements (normative) 94/10/31 Version 0.9 Page 53 of 108 252 C.4.2 Application notes 253 The application notes section of the assurance component contains additional narrative qualification of the assurance component. The application notes section is divided into two subsections: user notes and documentation notes. C.4.2.1 User notes 254 The user notes subsection contains additional information which is of particular interest to users of the assurance component e.g., PP and ST writers and designers of TOEs incorporating the component. The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required. C.4.2.2 Documentation notes 255 The documentation notes subsection contains requirements describing the items that must be described in assurance documentation. Assurance Component | | - Objectives and Threats | | - Application Notes | | - User Notes | | - Documentation Notes | | - Dependencies | | - Elements Figure C.3 - Assurance component structure D R A F T C - Specification of assurance requirements (normative) CCEB-94/082 Page 54 of 108 Version 0.9 94/10/31 C.4.3 Dependencies 256 For each assurance component, there exists a complete list of the first order dependencies among assurance components, and between functional and assurance components. "No dependencies" is used to describe the situation where no dependencies have been identified. 257 The modification of dependencies from one component to the next are highlighted using bold text. C.4.4 Elements 258 A set of assurance elements is provided for each assurance component. The elements are individually defined and are self-contained. 259 All assurance elements are identified as belonging to one of the three sets of assurance elements: a) Developer action elements; b) Content and presentation of evidence elements; or c) Evaluator action elements. 260 The modification of elements from one component to the next are highlighted using bold text. C.5 Construction rules for classes 261 TBD C.6 Construction rules for families 262 TBD C.7 Construction rules for components 263 TBD C.8 Assurance component evaluation criteria 264 TBD D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 55 of 108 Annex D Specification of functional packages (normative) D.1 Overview 265 This chapter defines the requirements for content and presentation and the construction rules of the functional packages. The set of functional packages presented in Part 2 chapter 3 complies with these requirements and rules. 266 These requirements form the basis for criteria against which functional packages shall be evaluated and are mandatory for all functional packages claiming compliance with the CC. D.2 Functional package structure and content 267 Figure D.1 below illustrates the required functional package structure in diagrammatic form. The following subsections describe each section of the functional package structure in more detail. D.2.1 Package Identification 268 The package identification section provides descriptive information necessary to identify, categorise, register, and cross-reference a package. The following must be provided in every functional package: 269 A unique name. The name should reflect the functional purpose of the package. 270 A short name. A unique short form of the functional package name shall also be provided. This short name will serve as the principal reference name for the categorisation, registering and cross-referencing of the package. 271 A date. To identify when the package was created. 272 A short description. To explain the purpose of the package. This description shall be sufficient to establish the list of cross- references to other similar or related functional packages. 273 A list of cross-references. To identify other functional packages with similar or related functionality. This list will allow consumers to compare packages and choose the one which most closely fits with their specific security objectives and needs. D R A F T D - Specification of functional packages (normative) CCEB-94/082 Page 56 of 108 Version 0.9 94/10/31 D.2.2 Package behaviour 274 The package behaviour is a narrative description of the package stating its security objectives, the threat environment and threats which it is intended to counter, a general description of the functional requirements, and a rationale describing how the functional requirements counter the identified threats. These are described in more detail hereafter. Functional Package | | - Package Identification | | - Name | | - Short Name | | - Date | | - Cross references | | - Package Behaviour | | - Application Notes | | - Permitted Operations | | - Dependencies | | - Functional Components Figure D.1 - Functional package structure D R A F T CCEB-94/082 D - Specification of functional packages (normative) 94/10/31 Version 0.9 Page 57 of 108 a) The security objectives of the package shall be a clear and concise statement of the protection problem for which the package provides or contributes to the solution. b) The statement of threats or threat environment for the package shall state the categories of threats which the package is intended to counter. The specific details of threats should be developed from the threat statements of the functional components (and functional component families) incorporated into the package. c) The description of the functional requirements shall summarise the security behaviour associated with the functional security requirements which are incorporated in the package. This description shall be aimed at potential users who wish to assess whether the package is relevant to their specific security requirements. d) The rationale for the package shall explain, at a high level, why the functional security requirements identified address the stated threats in the indicated threat environment. The rationale is aimed at authors of protection profiles and security targets incorporating the package. D.2.3 Application notes 275 Application notes contains additional narrative information concerning the package which may be useful to users of the package; that is PP and ST writers, designers of TOEs incorporating the package and evaluators of such TOEs. The presentation of the application notes should be informal and may cover, for example, warnings about limitations of use of the package, identification of areas that require specific attention, and caveats or warnings that are specific interest to evaluators. This section should mainly focus on application notes that are applicable to the package as a whole and not individual components. However, a summary of the application notes contained in the functional components included in the package should also be provided. D.2.4 Permitted operations 276 Packages may be tailored for incorporation into a PP, an ST, or another functional package, based on the particular environment of use and security policies being addressed. The permitted operations are defined in section B.5.6. Not all operations need to be permitted on all packages. Each package shall identify all operations that can be applied against that package, the nature under which the operations can be applied, and the result of the application of the operations. "No permitted operations" is an acceptable description. D.2.5 Dependencies 277 For each package there shall exist a complete list of first order dependencies to functional and assurance component levels not included in the package. Dependencies exist when a package is not self sufficient and requires additional requirements, specified in other functional or assurance components or functional D R A F T D - Specification of functional packages (normative) CCEB-94/082 Page 58 of 108 Version 0.9 94/10/31 packages, to completely address a specific security objective or policy. Types of dependencies are defined in section B.5.7. "No dependencies" is an acceptable statement to be included in a functional package. 278 This dependency information is necessary to form the basis of a subsequent dependency analysis for the PP or ST. D.2.6 Functional Components 279 The main body of a functional package is composed of the set of security functional requirements derived from the combination of two or more functional components found in Part 2 of the CC. The functional components should be related in that they each should address similar security objectives with their combination providing a more complete solution to those objectives. 280 Specific attention must be paid to the resulting effects of combining functional components which identify application notes, permitted operations, and dependencies to ensure that conflicts are not introduced. D.3 Composition Rules for Packages D.3.1 Functional package behaviour composition 281 Security functional package behaviour composition consists of consolidating the functional component behaviours of the functional components that make up the package in a logical and consistent manner. 282 Each aspect of the security functional behaviour specified in the functional components being combined must be examined to determine if that aspect is: - Completely subsumed by the behaviour of another component or combination of components in the package; - Partially subsumed or altered by the behaviour of another component or components in the package; or - Unaffected by all other components in the package. 283 Aspects of a functional component's behaviour that are completely hidden as a result of the components combination with other components shall not be included in the functional package's behaviour. 284 Aspects of a functional component's behaviour that are partially hidden or altered by the behaviour of another component in the package shall be included in the package's behaviour after being rewritten to reflect the "new" behavioural aspect of the package. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 59 of 108 285 Aspects of a functional component's behaviour that are unaffected by all other components in the package shall be included in the package's behaviour unmodified. 286 Lastly, the functional package shall be examined to determine if the combination of functional components results in new behaviour not based upon the behaviours of the constituent functional components. Any such behaviour must be included in the description of functional package behaviour. D.3.2 Functional package application note composition 287 Application notes intended to provide guidance for users of functional packages and for evaluators of TOEs claiming to satisfy the requirements included in functional packages shall consist of a two parts: 288 The first part shall include guidance applicable to one or more functional components contained in the package. This guidance may include warnings about limitations of use of the package, identification of areas requiring specific attention, and caveats or warnings of interest to evaluators. Application notes in a functional package should not apply to a single component. 289 The second part shall consist of a summary description of the key concepts extracted from the application notes of the individual components included in the package. However, due to the specific nature of the guidance contained in the application notes for individual functional components, it is not expected for conflicts to exist between application notes when the related components are combined into a functional package. D.3.3 Functional package permitted operation composition D.3.4 Functional package dependency composition 290 The analysis of dependencies between functional components must be performed during functional package construction. This analysis must cover all dependencies in all functional components being included in the package and is applicable to both functional and assurance dependencies. This analysis will allow the package builder to avoid inadequate, inconsistent, incorrect specification of the functional package. It will also allow the package builder to avoid over-specification of required functionality. Lastly, the dependency analysis can also serve as a starting point for determining the impact of change, such as adding or removing components, to a security functional package. 291 Uses dependencies of security functional components included in the package may be satisfied by also including the dependent functional components. Alternatively, the residual dependencies must be identified in the package dependency list. 292 Each individual dependency of each included functional component must either be resolved, as determined by the dependency analysis, or included in the dependency list of the package. D R A F T D - Specification of functional packages (normative) CCEB-94/082 Page 60 of 108 Version 0.9 94/10/31 D.3.5 Functional package requirements composition 293 All functional packages shall be built from complete functional components. The use of a subset of the elements within a component is not permitted. 294 Due to the approach taken in the CC, functional components cannot be combined in a functional package based solely on their being of the same "level" (as per the levelling of the components within a family). Rather, selection of functional components should be driven by user needs and the analysis performed during functional component dependency composition. 295 The elements that make up a functional package shall be the simple union of the elements that make up the functional components included in the package. These elements may be modified using only the operations defined as valid for each of the elements in the source functional component. D.4 Evaluation criteria for functional packages 296 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 61 of 108 Annex E Specification of assurance levels (normative) E.1 Overview 297 This chapter defines the requirements for content and presentation and the construction rules of the assurance levels of the CC. The set of assurance levels presented in chapter 3 of Part 3 complies with these rules. 298 The aggregation of assurance components into predefined hierarchical assurance levels provides the following : a) Consistent expression of levels of assurance; b) Comparability of TOEs. E.2 Assurance level structure 299 Figure E.1 illustrates the required assurance level structure in diagrammatic form. E.2.1 Name 300 Every assurance level is assigned a unique name. The name provides descriptive information about the overall thrust of the assurance level. 301 A unique short form of the assurance level name is also provided. This is the primary means used to reference the assurance level. E.2.2 Objectives 302 The objectives section of the assurance level provides the overall purpose and goals of the assurance level (i.e., it is used to justify the existence of the assurance level). E.2.3 Threats 303 The threats section of the assurance level provides the categories of threats which the level is intended to counter. The description for the assurance level is kept at a general level. D R A F T E - Specification of assurance levels (normative) CCEB-94/082 Page 62 of 108 Version 0.9 94/10/31 E.2.4 Application notes 304 The application notes section of the assurance level contains additional narrative qualification of the assurance level. The application notes section only contains one subsection: user notes. E.2.4.1 User notes 305 The user notes subsection contains additional information which is of particular interest to users of the assurance level e.g., PP and ST writers and designers of TOEs targeting this assurance level. The presentation is informal and covers, for example, warnings about limitations of use and areas where specific attention may be required. Assurance Level | | - Name | | - Objectives | | - Threats | | - Application Notes | | - User Notes | | - Assurance Components Figure E.1 - Assurance level structure D R A F T CCEB-94/082 E - Specification of assurance levels (normative) 94/10/31 Version 0.9 Page 63 of 108 E.2.5 Assurance components 306 For each assurance level the appropriate number of assurance families has been chosen. In addition, for each assurance family, an appropriate assurance component has been chosen. 307 A high level of assurance can be achieved by: a) Including additional assurance families; or b) Including a higher assurance component from an assurance family. E.3 Composition rules 308 TBD D R A F T E - Specification of assurance levels (normative) CCEB-94/082 Page 64 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 65 of 108 Annex F Specification of Protection Profiles (normative) F.1 Overview 309 A PP is a unique set of security objectives and requirements for a particular class of TOEs which are intended to meet a common consumer need for IT security measures. Consumers can use a PP to express their requirements in an abstract manner. F.2 Content of Protection Profile 310 PPs shall conform to the structure and content requirements in this annex. A PP should be completely presented in a single document rather than in multiple documents. 311 The contents of the PP are portrayed in figure F.1. The description of PP contents is presented below. F.2.1 Descriptive elements 312 The descriptive elements section shall provide labeling and descriptive information necessary to identify, categorise, register and cross reference a PP. F.2.2 TLSO 313 The statement of top-level security objectives (TLSO) shall contain: a) Usage assumptions: shall describe the intended usage of the TOE. Aspects of usage that may be considered include the presumed application and type of product represented by the TOE. b) Environmental assumptions: shall describe the presumed environment in which the TOE is intended to be used. This includes information about the relevant regulatory, organisational, physical, personnel and connectivity aspects of the environment. It also includes general assumptions about the value of information to be protected and the assumed distribution of security responsibilities to non-TOE elements. D R A F T F - Specification of Protection Profiles (normative) CCEB-94/082 Page 66 of 108 Version 0.9 94/10/31 314 Protection Profile | | - Descriptive Elements | | - TLSO | | - Usage Assumptions | | - Environment Assumptions | | - Threats | | - Objectives | | - Requirements | | - Requirements Statement | | | - Functional Requirements | | | - Assurance Requirements | | | | - Rationale | | - Functions Rationale | | - Assurance Rationale | | - Application Notes Figure F.1 - Protection Profile structure c) Statement of threat: shall describe the threats which the TOE is intended to counter. This statement shall include a general discussion of the threats in the assumed environment, identifying those threats which the TOE is intended to counter, optionally identifying significant threats which the TOE does not counter. Threats countered should be discussed by addressing aspects such as the following. - Attacker opportunity: the postulated environmental conditions enabling a threat agent to launch specific attacks against the TOE. Included in this description are specific threat-enabling conditions and a statement of attack methods. - Attacker expertise: the postulated knowledge about the TOE, relevant skills, and ability that the threat agent can bring to bear to support attacks against the TOE. - Attacker resources: the postulated amount of effort the threat agent is likely to expend attacking the TOE, including expected attack D R A F T CCEB-94/082 F - Specification of Protection Profiles (normative) 94/10/31 Version 0.9 Page 67 of 108 frequency and duration. Equipment the threat agent may employ is also included. - Attacker motivation: the postulated benefits a threat agent may be seeking or environmental conditions that give rise to dangerous behaviour. Hostile or non-hostile intent is also included. This statement is intended to explain why the threat agent is a source of danger to the TOE. 315 Optionally, the intensity of each threat to be countered may be quantified, using the same factors as to describe it. 316 The TLSO shall be summarised in the form of a statement of security objectives to be met by the TOE in order to counter the identified threats. 317 Where the TOE is distributed in nature, it may be necessary to characterise threats and environmental assumptions separately for distinct sub-domains of the TOE environment. Where the threats defined are such that the threat level is sub-domain dependent, the TLSO shall explain this clearly such that any TOE strength claims can be traced back to the TLSO. F.2.3 Requirements 318 The requirements shall contain the following: a) Statement of requirements: the requirements statement shall state the security functional requirements for the TOE as functional components and/or packages contained in Part 2. The permitted operations from annex B may be used to express the requirements to the level of detail necessary to meet the needs of the PP author. The requirements statement may optionally prescribe or forbid the use of particular security mechanisms and techniques where necessary. The requirements statement shall also state the assurance requirements as one of the assurance levels (optionally augmented by additional assurance components) contained in Part 3. b) The statement of rationale: the rationale statement for the requirements shall show that the requirements are suitable to meet the TLSO. The following issues should be considered in this determination: 1) All functional requirements can be combined in accordance with the annex B dependency rules; 2) No functional requirements undermine the intent of any other functional requirements; 3) It is possible to implement the TOE with feasible technology; D R A F T F - Specification of Protection Profiles (normative) CCEB-94/082 Page 68 of 108 Version 0.9 94/10/31 4) The choice of the assurance level and augmenting assurance components, if any, are justified. F.2.4 Application notes 319 This section may contain additional supporting information which may be relevant to the construction, evaluation or use of the TOE. Examples include related or similar PPs and caveats on applicability. F.3 Protection Profile construction rules F.4 Source of Protection Profiles 320 The PP may be developed by user communities, IT product developers, or other parties interested in defining such a common set of requirements. Consumers or consumer groups, within government agencies or the private sector, can create PPs as a vehicle to present their common security requirements to the community of IT product suppliers. The consumer groups can represent not only end-users but also system integrators and value-added resellers. For example, a banker's association might propose a PP for secure electronic funds transfer. In addition, an alliance of national defence departments might propose a set of PPs to cover common military applications. 321 IT product suppliers can create PPs to present potential products to the consumer community. For instance, a consortium of operating system suppliers might propose a PP for common security requirements of their software. Suppliers' market-research groups are often acquainted with consumer security needs and could also propose PPs. A PP gives consumers a means of referring to a specific set of needs and facilitates future evaluation against those needs. 322 Multiple groups having similar needs may combine to sponsor a PP that meets their common need. Having multiple groups support a specific PP or profile family (group of profiles closely related by similar objectives and functional/assurance requirements) is an effective way to demonstrate the existence of a larger market to potential IT product developers. F.5 Evaluation criteria for Protection Profiles F.5.1 PPE Protection Profile Evaluation F.5.1.1 Objectives and Threats 323 The evaluation of a PP shall show that a conformant TOE can fulfill its IT security objectives. Moreover the evaluation shall prove that the publication of that PP is justified. D R A F T CCEB-94/082 F - Specification of Protection Profiles (normative) 94/10/31 Version 0.9 Page 69 of 108 F.5.1.2 Application Notes 324 TBD F.5.1.3 Dependencies 325 No dependencies F.5.1.4 Requirements Developers actions PPE_PPE.1.1D The developer shall provide a PP. Content and presentation of the evidence PPE_PPE.1.1C The PP shall contain a descriptive elements section, a statement of TLSO, and a statement of requirements. PPE_PPE.1.2C The statement of TLSO shall contain the usage assumptions of a conformant TOE. PPE_PPE.1.3C The statement of TLSO shall contain the environmental assumptions of a conformant TOE. PPE_PPE.1.4C The statement of TLSO shall contain the statement of threat. PPE_PPE.1.5C The statement of requirements shall present the security functional requirements for a conformant TOE in a manner which is defined in this Part 1 and Part 2 of the CC. PPE_PPE.1.6C The statement of rationale for the requirements shall show that all functional requirements can be combined in accordance with the annex B dependency rules. PPE_PPE.1.7C The statement of rationale for the requirements shall show that no functional requirements undermine the intent of any other functional requirement. PPE_PPE.1.8C The statement of rationale for the requirements shall show that all functional requirements are suitable to meet the TLSO. PPE_PPE.1.9C The statement of requirements shall present the assurance requirements for a conformant TOE in a manner which is defined in this Part 1 and Part 3 of the CC. PPE_PPE.1.10C The statement of rationale for the requirements shall justify the choice of the assurance level and the additional assurance components, if any. PPE_PPE.1.11C The statement of rationale for the requirements shall show that it is possible to implement the TOE with feasible technology. D R A F T F - Specification of Protection Profiles (normative) CCEB-94/082 Page 70 of 108 Version 0.9 94/10/31 Evaluator Actions PPE_PPE.1.1E The evaluator shall check that the PP meets all requirements for content and presentation of the evidence. PPE_PPE.1.2E The evaluator shall check that the PP is consistent. PPE_PPE.1.3E The evaluator shall check that it is appropriate to use the PP as the basis of development and evaluation of a conformant TOE. PPE_PPE.1.4E The evaluator shall check that the intended objectives of a conformant TOE are of such a general interest that the registration and publication of a PP are justified. PPE_PPE.1.5E The evaluator shall check that the selected security functional requirements and the assurance requirements provide the required security behaviour. PPE_PPE.1.6E The evaluator shall check that the PP can be implemented with feasible technology. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 71 of 108 Annex G Specification of security targets (normative) G.1 Overview 326 The security target (ST) serves both as a definition of the security functions of the TOE which will be evaluated and of the assurance measures which will be taken to achieve the required level of assurance. It forms the basis for agreement between the developers, evaluators, and consumers as to the scope and viability of the evaluation. The audience for the ST is not confined to those responsible for the production of the TOE and its evaluation, but also includes those responsible for managing, purchasing, installing, configuring, operating, and using the TOE. Editor Note: There is currently an overlap in requirements for evidence between ADV_FSP and those parts of the ST evaluation concerned with the evaluation of the definition of the security functions. As part of the follow-on activities there will be a resolution that allocates requirements for evidence and evaluation such that no requirement is duplicated in the CC. 327 The ST may be presented as a single document or as multiple documents (including reference to pre-existing material). Where multiple documents are presented, their relationships to one another shall be clearly indicated. 328 The ST may or may not claim conformance to a PP. If the ST does not make such a claim, then the ST shall contain at least the same information in its TLSO and statement of TOE requirements as that required of a PP. 329 The contents of the ST are portrayed in Figure G.1. The description of ST structure and contents is presented below. G.2 Content of security target G.2.1 Descriptive elements 330 The following general identification and reference material should be incorporated in the ST: a) TOE identification statement: this statement shall uniquely identify the TOE and should include information such as the name of the TOE, version number information, and date information. b) PP reference statement: this statement shall identify any PPs to which the TOE is claiming conformance. D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 72 of 108 Version 0.9 94/10/31 c) Documentation structure: this statement shall identify all parts of the ST document and define their relationships. d) Additional notes: this is a place holder for other high level or introductory material which the ST author considers relevant. 331 Security Target | | - Descriptive Elements | | - TLSO | | - PP Interpretation | | - TLSO statement | | - Requirements | | - PP Interpretation | | - Requirements Statement | | | - Functional Requirements | | | - Assurance Requirements | | | | - Rationale | | - Functions Rationale | | - Assurance Rationale | | - TOE Description | | - Security Functions | | | - Definition | | | - Strength | | | - Rationale | | | | - Assurance Measures | | - Definition | | - Rationale | | - Application Notes Figure G.1 - Security target structure D R A F T CCEB-94/082 G - Specification of security targets (normative) 94/10/31 Version 0.9 Page 73 of 108 G.2.2 TLSO G.2.2.1 Interpretation of PP TLSO 332 The interpretation of the PP TLSO is required if any claim of PP conformity is being made. The PP interpretation shall show how the PP is being instantiated to meet the specific objectives of the TOE. Editor Note: The use of the term interpretation is not entirely satisfactory given its widespread use in the security field, other terms such as elaboration should be considered for future issues. 333 The following specific interpretations shall be supplied: a) The interpretation of PP usage assumptions shall show that the usage assumptions that are stated in the PP are valid for the TOE given specific detail about the TOE primary application and type of product. b) The interpretation of the PP environmental assumptions shall show that the environmental assumptions that are stated in the PP are valid for the TOE. This may consider the provision of additional information about the organisational, physical, personnel, regulatory and connectivity aspects of the environment such as the citation of specific organisational security policies and the identification of planned or actual physical environments. c) The interpretation of the PP statement of threat shall show that the threats stated in the PP are valid for the TOE given more specific information about postulated threat agents and attacks. 334 The TLSO interpretations shall demonstrate that the overall security objectives of the PP are upheld by the TOE. G.2.2.2 Statement of TOE TLSO 335 The statement of TOE TLSO shall support and include any PP TLSO interpretations. 336 The statement of TOE TLSO is required if no PP conformity claim is being made, or if any PP conformity claim is being made and TOE security properties that exceed the PP requirements are being evaluated. If no additional TOE requirements are subject to evaluation, the PP TLSO interpretations shall serve as the statement of TOE TLSO. 337 The following specific statements are required: a) Usage assumptions: shall describe the actual or intended usage of the TOE. Aspects of usage that may be considered include the actual or presumed application and the type of product represented by the TOE. D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 74 of 108 Version 0.9 94/10/31 b) Environmental assumptions: shall describe the known or presumed environment in which the TOE is to be used. This may include information about the regulatory, organisational, physical, personnel and connectivity aspects of the environment such as the citation of specific organisational security policies and the identification of planned or actual physical environments. c) Threats: shall describe the threats which the TOE is intended to counter. This statement shall include a general discussion of the threats in the assumed or actual environment, identifying those threats which the TOE is intended to counter and optionally listing significant threats which the TOE does not counter. Discussion of threats countered should identify threat agents and cover aspects such as opportunity, expertise, resources, and motivation. The statement of threat shall quantify the intensity of each threat countered by the TOE, using the same factors as to describe it. 338 The TLSO shall be summarised in the form of a statement of security objectives to be met by the TOE in order to counter the identified threats. G.2.3 Requirements G.2.3.1 Interpretation of PP requirements 339 The interpretation of the PP requirements is required if any claim of PP conformity is being made. The PP interpretation shall show how the PP is being instantiated to meet the specific requirements of the TOE. 340 The following specific interpretations shall be supplied: a) All unresolved operations on the PP components shall be addressed in accordance with the rules for permitted operations in annex B; b) All further details which are necessary for a proper interpretation of the PP requirements for the TOE shall be supplied. These may include reference to specific detailed technical security policies or other necessary technical security requirements not appropriate to the PP level of abstraction. G.2.3.2 Statement of TOE requirements 341 The statement of TOE requirements shall uphold and include all PP requirements interpretations. 342 The statement of TOE requirements is required if no PP conformity claim is being made, or if a PP claim is being made and TOE security properties that exceed the PP requirements are being evaluated. If no additional TOE requirements are subject to evaluation, the PP plus the TOE requirements interpretations shall serve as the statement of TOE requirements. The statement of TOE requirements may refer to D R A F T CCEB-94/082 G - Specification of security targets (normative) 94/10/31 Version 0.9 Page 75 of 108 existing technical security requirements documents such as technical or TOE specific security policy documents. 343 All TOE security functional requirements additional to those of any cited PP shall be stated. Additional functional components incorporated in the ST shall be compliant with annex B requirements for content and presentation. Further components shall be incorporated as necessary to satisfy dependencies. 344 A claim of compliance with the requirements of an assurance level contained in Part 3 shall be made. Any TOE assurance requirements additional to the assurance level shall be stated. Additional assurance components incorporated in the ST shall be compliant with annex C and have all dependencies satisfied. 345 Additional components shall be incorporated as necessary to satisfy dependencies. 346 Checks shall be made to ensure that the stated component objectives support the stated TOE objectives and are compatible with and supportive of the other TOE requirements. G.2.3.3 TOE requirements rationale 347 The TOE requirements shall be supported by a statement of rationale which shows that the requirements are suitable to meet the TOE TLSO. The following aspects should be considered: a) That all functional requirements can be combined in accordance with the annex B dependency rules; b) That the operations of all functional requirements components are completed; c) That no functional requirements undermine the intent of any other functional requirements; d) That the TLSO and requirements of any PP to which the TOE is claiming conformity are not undermined by the totality of the TOE functional requirements; e) That the interpretation of any PP to which the TOE is claiming conformity is reasonable; f) That any known vulnerabilities of the functional requirements are acceptable in the context of the TOE objectives; g) That the totality of the TOE functional requirements forms a balanced and cohesive set of requirements; h) That the assurance requirements are applicable to a TOE conformant to the functional requirements; D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 76 of 108 Version 0.9 94/10/31 i) That any assurance requirements additional to the assurance level form a balanced and cohesive whole when combined with the assurance level. G.2.4 TOE description 348 The ST defines the instantiation of the security requirements for the TOE by providing a high level definition of the security functions claimed to meet the requirements and of the assurance measures taken to meet the assurance requirements. G.2.4.1 Statement of TOE security functions Definition of TOE security functions 349 The ST shall include a definition of the security functions provided by the TOE. The security functions shall be mapped to the security requirements so that it can be seen which functions satisfy which requirements. Every security function shall, as a minimum, contribute to the satisfaction of at least one security requirement. 350 The security functions shall be defined in an informal style to a level of detail necessary for understanding of the intent and behaviour of the function. In addition, at higher evaluation levels, semiformal and formal styles may be required. 351 All references to security mechanisms and techniques included in the ST shall be traced to the relevant security functions so that it can be seen which required techniques or mechanisms are used in the implementation of each function. Strength of TOE security functions 352 A strength of function rating may be claimed for any TOE security functions, or an assertion that a strength claim is inappropriate may be made. The strength of function claims shall be made in accordance with the requirements of assurance family AVA_SOF. Rationale for security functions 353 The definitions of the claimed TOE security functions shall be supported by a statement of rationale which shows that the claimed TOE security functions meet all functional requirements of the TOE and are suitable to meet the TOE TLSO. The following aspects shall be addressed: a) That all claimed TOE security functions work together in a mutually supportive manner so as to satisfy the TOE TLSO and requirements; b) That the objectives and requirements of any PP to which the TOE is claiming conformity are not undermined by the totality of the TOE security functions; c) That the strength of TOE function claims made are valid, or that such claims are unnecessary; D R A F T CCEB-94/082 G - Specification of security targets (normative) 94/10/31 Version 0.9 Page 77 of 108 d) That any known vulnerabilities declared or implied by the claimed TOE security functions are acceptable in the context of the TOE objectives. 354 The statement of rationale shall be presented at a level of discourse which matches the level of detail of the definition of the security functions. G.2.4.2 Statement of TOE assurance measures Definition of assurance measures 355 The ST shall include a definition of assurance measures provided by the TOE and its implementation environment. The assurance measures shall be traced to the assurance requirements so that it can be seen which measures satisfy which requirements. 356 If appropriate, the definition of assurance measures may be made by reference to relevant quality plans, life cycle plans, or management plans. Rationale for assurance measures 357 The definitions of the TOE assurance measures shall be supported by a statement of rationale which justifies the claim of compliance with the assurance requirements. G.2.5 Application notes 358 This section may contain additional supporting information which may be relevant to the construction, evaluation, or use of the TOE. G.3 Security Target construction rules 359 G.4 Source of security target 360 The sponsor, the person or organisation that requests the TOE evaluation, shall be responsible for providing the ST. G.5 Relationships between protection profile and security target G.5.1 Introduction 361 A PP is developed by a community of interest, typically a set of users with common IT security needs. That PP is then evaluated and is made available for general use via registration. A developer, perceiving the market demand represented by the PP, develops a potentially conformant IT product in response. The developer (or evaluation sponsor, if different) of the TOE produces a ST that describes the D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 78 of 108 Version 0.9 94/10/31 implementation of the PP requirements in the TOE. The ST is then evaluated for conformity to the PP, and the TOE is evaluated for conformity to the ST. The result demonstrates the conformance of the TOE to the security requirements of the PP. G.5.2 Common sections of a PP and a ST 362 PPs and STs are high-level design abstractions from which detailed implementations will result. Both PPs and STs must convey the same information relative to security issues. They both must demonstrate that the requirements and functions chosen are sufficient to address all the postulated threats, that they will be effective in countering those threats, that all dependencies are satisfied, and that they are internally consistent (i.e., that they can be further refined to lower levels of representation). 363 The contents of the ST and the PP are similar with the addition of the TOE description in the ST supported by the rationale for the security definitions. 364 The TLSO and requirements stated in a PP may be incorporated by reference into the ST. The ST may add further detail to the referenced PP requirements as necessary to interpret the requirements. Any additional requirements and objectives added to the PP in the ST must be fully justified with respect to the PP. 365 Table G.1 below summarises and compares the contents of the PP and ST. Table G.1 - Content comparison of Protection Profile and Security Target Descriptive Elements -------------------- PP - Provides labeling and descriptive information necessary to identify, categorise, register, and cross reference a PP in a registry. ST - Provides information required to identify the TOE and any claimed PP. Roadmap to the ST documentation required. TLSO Statement -------------- PP - Documents the assumed usage assumptions, environmental assumptions, and threats for the TOE. - - Threat intensity may optionally be present as a quantitative statement of the threat levels in terms of opportunity, expertise, resources, and motivation of potential attacker. ST - Documents the assumed usage assumptions, environmental assumptions, and threats for the TOE incorporating additional TOE specific detail. - Interprets and refines TLSO from cited PP in the TOE specific context. - Threat intensity must be present as a quantitative statement of threat levels as for PP. May enhance definition in PP with more TOE specific information. Requirements Statement ---------------------- PP - Defines the security functional requirements as CC functional components and/or packages. - - - States the assurance requirement as a CC assurance level. - Optionally calls up additional CC assurance components. ST - Defines the TOE security requirements. - Optionally calls up requirements expressed by a protection profile. - May interpret the protection profile with additional TOE specific detail. - May define additional functional requirements. - States the assurance requirements as a CC assurance level. - Optionally calls up additional assurance components. D R A F T CCEB-94/082 G - Specification of security targets (normative) 94/10/31 Version 0.9 Page 79 of 108 Table G.1 - Content comparison of Protection Profile and Security Target Rationale for Requirements -------------------------- PP - Shows that the selected CC functional components can be combined in accordance with the dependency criteria. - Shows that the stated functional requirements meet the TLSO. - - Provides justification for the choice of assurance level and any choice of additional assurance. ST - Shows that the functional components can be combined in accordance with the criteria. - Shows that the selected CC functional components and any additional functional requirements meet the TLSO. - Shows that the TLSO of any referenced PP is not undermined by enhancements. - Provides justification for the choice of assurance level and any choice of augmented assurance. TOE Description Statement ------------------------- PP - - ST - Defines the security functions against which the TOE will be evaluated. ST - Interprets assurance requirements in the context of the specific TOE to develop a more detailed assurance measures. Rationale --------- PP - - - ST - Shows that the defined security functions meet the requirements and do not introduce any unspecified security relevant behaviour contrary to requirements. - Shows that the assurance measures meet the assurance requirement. - Shows that all definitions meet the TOE TLSO. G.5.3 Three cases of relationship between a PP and a ST 366 An ST may claim exact conformance with a PP and reference the PP as the statement of requirements and purpose. In such a case, the ST should not restate the requirements and purpose of the PP other than to add any greater detail relevant to the specific TOE. Alternately, an ST may claim to meet additional requirements and related purposes in addition to conforming with a PP. In such a case, the additional requirements and purposes must be stated in the ST with supporting rationale demonstrating that the additional purposes are met without undermining the original PP requirements. 367 There are three cases of relationship between a PP and a ST that fall within the scope of the CC. All three cases are equally valid for evaluation of the TOE against the CC. 368 Case 1: the ST is claimed to be strictly conformant to the requirements contained in a PP. The ST shall re-use the contents of the PP, including the same statement of TLSO, functional and assurance requirements. The ST shall refine the requirements of the PP into function definitions and assurance measures for the TOE. 369 Case 2: the ST is claimed to be conformant to a PP with additional claims of security functions, assurance or both. The ST shall re-use the contents of the PP, including the same purpose, functional and assurance requirements. However, in this case, the D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 80 of 108 Version 0.9 94/10/31 ST shall include an additional statement of requirements, with supporting rationale, for the claims made beyond the PP. The ST shall refine the requirements of the PP, plus the additional requirements, into definitions for the TOE. 370 Case 3: the ST for a TOE makes no claim of conformity to a PP. The ST shall state the full purpose and security requirements for the TOE, with supporting rationale. The ST shall refine these requirements into specifications for the TOE. 371 The case where a ST claims to be partially conformant to a PP is not meaningful for CC evaluation purposes, and defaults to the third case. The way that STs are evaluated is determined by their claimed relationship to a PP. G.6 Evaluation criteria for Security Targets G.6.1 STE - ST Evaluation G.6.1.1 Objectives and threats 372 The ST is used as the baseline for the evaluation. It contains the TLSO of the TOE, the IT security functional and assurance requirements for the TOE, and definitions of the security functions and assurance measures of the TOE. 373 The ST evaluation shall show that the intended purpose of the TOE is realised and that the evaluation is feasible. The evaluation of the ST ensures that an appropriate concept exists for countering the threats to the TOE. G.6.1.2 Application Notes 374 TBD G.6.1.3 Dependencies 375 No dependencies G.6.1.4 Requirements Developer actions STE_STE.1.1D The developer shall provide a ST. Content and presentation of the evidence STE_STE.1.1C The ST may be presented as a single document or as multiple documents (including reference to pre-existing material). Where multiple documents are presented, their relationship to one another shall be clearly indicated. STE_STE.1.2C The ST shall contain a descriptive elements section, a statement of TOE TLSO, a statement of requirements, and a statements of TOE description. D R A F T CCEB-94/082 G - Specification of security targets (normative) 94/10/31 Version 0.9 Page 81 of 108 STE_STE.1.3C If the ST claims conformance to a PP, an interpretation of the PP TLSO including the PP usage assumptions interpretation, PP environmental assumption interpretation, and a PP threat interpretation shall be provided. STE_STE.1.4C If the ST claims conformance to a PP, the statement of the TOE TLSO shall uphold and include the PP interpretations. STE_STE.1.5C The statement of TOE TLSO shall contain the usage assumptions. STE_STE.1.6C The statement of TOE TLSO shall contain the environmental assumptions. STE_STE.1.7C The statement of TOE TLSO shall contain the statement of threat. STE_STE.1.8C If the ST claims conformance to a PP, an interpretation of the PP statement of requirements shall be provided. STE_STE.1.9C If the ST claims conformance to a PP, the ST statement of requirements shall uphold and include the PP interpretations. STE_STE.1.10C The statement of requirements shall present the security functional requirements in a manner which is defined in Part 1 and Part 2 of the CC. STE_STE.1.11C The statement of requirements shall present the assurance requirements in a manner which is defined in Part 1 and Part 3 of the CC. STE_STE.1.12C The statement of rationale for the requirements shall show that all functional requirements are suitable to meet the TOE TLSO. STE_STE.1.13C The statement of rationale for the requirements shall show that all functional requirements can be combined in accordance with the annex B dependency rules. STE_STE.1.14C The statement of rationale for the requirements shall show that the operations of all functional components are completed. STE_STE.1.15C The statement of rationale for the requirements shall show that the functional requirements bind together in a mutually supportive manner so as to satisfy the TOE TLSO. STE_STE.1.16C The statement of rationale for the requirements shall show that all known vulnerabilities of the functional requirements are acceptable in the context of the TOE objectives. D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 82 of 108 Version 0.9 94/10/31 STE_STE.1.17C The statement of rationale for the requirements shall show that the totality of the TOE functional requirements forms a balanced and cohesive set of requirements. STE_STE.1.18C The statement of rationale for the requirements shall justify the choice of the assurance level and the additional assurance components, if any. STE_STE.1.19C The statement of rationale for the requirements shall show that the assurance requirements additional to the assurance level form a balanced and cohesive whole when combined with the assurance level. STE_STE.1.20C The statement of rationale for the requirements shall show that the assurance requirements are applicable to a TOE conformant to the functional requirements. STE_STE.1.21C The statement of rationale for the requirements shall show that it is possible to implement the TOE with feasible technology. STE_STE.1.22C The statement of TOE description shall contain a statement of TOE security functions and a statement of TOE assurance measures. STE_STE.1.23C The statement of TOE security functions shall trace the security functions to the security requirements so that it can be seen which TOE security functions satisfy which requirements. 376 STE_STE.1.24C The TOE security functions shall be defined in an informal style to a level of detail necessary for understanding of the intent and behaviour of the function. Semiformal and formal styles have to be applied where required. STE_STE1.25C All references to security mechanisms and techniques included in the ST shall be traced to the relevant security functions so that it can be seen which techniques or mechanisms are used in the implementation of each function. STE_STE.1.26C If a strength of function rating is claimed for any TOE security functions, or an assertion is made that a strength claim is inappropriate, the strength of function claims shall be made in accordance with the requirements of assurance family AVA_SOF. STE_STE.1.27C The statement of TOE security functions shall contain a statement of rationale for the security functions of the TOE. D R A F T CCEB-94/082 G - Specification of security targets (normative) 94/10/31 Version 0.9 Page 83 of 108 STE_STE.1.28C The statement of rationale for the TOE security functions shall show that the set of TOE security functions meets all functional requirements of the TOE. STE_STE.1.29C The statement of rationale for the TOE security functions shall show that the security functions are suitable to meet the TLSO of the TOE. STE_STE.1.30C The statement of rationale for the TOE security functions shall show that all security functions bind together in a mutually supportive manner so as to satisfy the TOE TLSO and the requirements. STE_STE.1.31C The statement of rationale for the TOE security functions shall show that the objectives and requirements of any PP to which the TOE is claiming conformity are not undermined by the totality of the TOE security functions. STE_STE.1.32C If a claim of strength of function is made the statement of rationale for the TOE security functions shall show that these claims are valid. STE_STE.1.33C If an assertion is made that a strength claim is inappropriate the statement of rationale for the TOE security functions shall show that this assertion is valid. STE_STE.1.34C The statement of rationale for the TOE security functions shall show that all known vulnerabilities declared or implied by the security functions are acceptable in the context of the TOE objectives. STE_STE.1.35C The statement of TOE assurance measures shall contain a claim of compliance with the requirements of a CC assurance level. STE_STE.1.36C The statement of TOE assurance measures shall present any TOE security assurance requirements additional to the assurance level. STE_STE.1.37C The statement of rationale for the TOE assurance measures shall show that TOE assurances meet the assurance requirements. Evaluator Actions STE_STE.1.1E The evaluator shall check that the ST meets all requirements for content and presentation of the evidence. STE_STE.1.2E The evaluator shall check that the ST is self-consistent. STE_STE.1.3E The evaluator shall check that the TOE TLSO form a useful and cohesive set of objectives. STE_STE.1.4E The evaluator shall check that none of the objectives of any cited PP are undermined by the TOE specific interpretations. D R A F T G - Specification of security targets (normative) CCEB-94/082 Page 84 of 108 Version 0.9 94/10/31 STE_STE.1.5E The evaluator shall check that none of the objectives of any cited PP are undermined by the addition of TOE specific security objectives. STE_STE.1.6E The evaluator shall check that the functional requirements are suitable to meet the TOE TLSO. STE_STE.1.7E The evaluator shall check that all functional requirements are combined in accordance with the annex B dependency rules. STE_STE.1.8E The evaluator shall check that the operations of all functional components are completed. STE_STE.1.9E The evaluator shall check that all functional requirements bind together in a mutually supportive manner so as to satisfy the TOE TLSO. STE_STE.1.10E The evaluator shall check that all known vulnerabilities of the functional requirements are acceptable in the context of the TOE objectives. STE_STE.1.11E The evaluator shall check that the totality of the TOE functional requirements forms a balanced and cohesive set of requirements. STE_STE.1.12E The evaluator shall check that the choice of the assurance level and the additional assurance components, if any is, justified. STE_STE.1.13E The evaluator shall check that the assurance requirements additional to the assurance level form a balanced and cohesive whole when combined with the assurance level. STE_STE.1.14E The evaluator shall check that the assurance requirements are applicable to a TOE conformant to the functional requirements. . STE_STE.1.15E The evaluator shall check that the ST can be implemented with feasible technology. STE_STE.1.16E The evaluator shall check that the set of TOE security functions meets all functional requirements of the TOE. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 85 of 108 Annex H Security concepts and principles (informative) H.1 Introduction 377 The CC is based upon a set of assumptions about the general domain of security and IT security in particular. This annex provides a top level description of the CC principles of security and should be considered as introductory material only. H.2 General security context 378 Security is concerned with the protection of assets from threats where threat is categorised as the potential for abuse of protected assets. All categories of threat should be considered but in the domain of security greater attention is given to those threats which arise out of malicious or other human activities. Figure H.1 illustrates high level concepts and relationships. [Very graphical semantic net; too complicated to reproduce in text format ] Figure H.1 - Security concepts and relationships 379 The assets of interest are the responsibility of owners who place value on those assets. Actual or presumed threat agents may also place value on the assets and seek D R A F T H - Security concepts and principles (informative) CCEB-94/082 Page 86 of 108 Version 0.9 94/10/31 to abuse assets in a manner contrary to the interests of the owner. Owners will perceive such threats as potential for impairment of the assets such that the value of the assets to the owners would be reduced. Security specific impairment commonly includes, but is not limited to, damaging disclosure of the asset to unauthorised recipients (loss of confidentiality), damage to the asset through unauthorised modification (loss of integrity), or unauthorised deprivation of access to the asset (loss of availability). 380 Owners impose countermeasures which seek to mitigate the threat of asset impairment. Residual vulnerabilities will remain after the imposition of countermeasures, such vulnerabilities may be exploited by the threat agents resulting in a residual level of risk to the assets. Owners will seek to minimise the residual risk level. [Very graphical semantic net; too complicated to reproduce in text format ] Figure H.2 - Evaluation concepts and relationships 381 Owners will need to be confident that the countermeasures are adequate to counter the threats to assets before they will allow exposure of their assets to the specified threats. Owners may not themselves possess the capability to judge all aspects of the countermeasures and may therefore seek evaluation of the countermeasures. The outcome of evaluation is a statement about the extent to which the counter measures can be trusted to reduce the risks to the protected assets. The statement assigns assurance to the countermeasures, assurance being that property of the D R A F T CCEB-94/082 H - Security concepts and principles (informative) 94/10/31 Version 0.9 Page 87 of 108 countermeasures which gives grounds for belief in their proper operation. This statement can be used by the owner of the assets in deciding whether to accept the risk of exposing the assets to the threats. Figure H.2 illustrates these relationships. 382 Owners of assets will normally be held responsible for those assets and should, therefore, be able to defend the decision to accept the risks of exposing the assets to the threats. This, in turn, requires that the statements resulting from evaluation are themselves defensible. Thus evaluation should lead to objective and repeatable results that can be cited as evidence. The existence of a set of evaluation criteria is a necessary pre-condition for evaluation to lead to a meaningful result and to provide a technical basis for mutual recognition of evaluation results between evaluation authorities. H.3 Information technology security context 383 Many assets are in the form of information which is stored, processed and transmitted by IT systems to meet requirements laid down by owners of the information. In formation owners may require that dissemination and modification of any such information representations (data) be strictly controlled. They may demand that the IT system implement IT specific security controls as part of the overall set of security countermeasures put in place to counteract the threats to the data. 384 IT systems are procured and constructed to meet user specific requirements and may, for economic reasons, make maximum use of existing commodity IT products such as operating systems, general purpose application components, and hardware platforms. IT security countermeasures implemented by a system may use functions of the underlying IT products and depend upon the correct operation of IT product security functions. The IT products may, therefore, be subject to evaluation as part of the IT system security evaluation. 385 Where an IT product is incorporated or being considered for incorporation in multiple IT systems, there are cost advantages in evaluating the security aspects of such a product independently and building a catalogue of evaluated products. The results of such an evaluation should be expressed in a manner which supports the incorporation of the product in multiple IT systems without unnecessary repetition of work required to examine the product's security. 386 An IT system accreditor has the authority of the owner of the information to determine whether the combination of IT and non-IT security countermeasures furnishes adequate protection for the data and thus to decide whether to permit the operation of the system. The accreditor may call for evaluation of the IT countermeasures in order to determine whether the IT countermeasures provide adequate protection and whether the specified countermeasures are properly implemented by the IT system. This evaluation may take various forms and degrees of rigour, depending upon the rules imposed upon the accreditor. 387 The CC provides a basis for evaluation of the technical IT security properties of either products or systems D R A F T H - Security concepts and principles (informative) CCEB-94/082 Page 88 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 89 of 108 Annex I Security development and evaluation model (informative) I.1 Introduction 388 Evaluation criteria are most useful in the context of the engineering processes and regulatory frameworks which are supportive of secure TOE development and evaluation. This annex describes a framework in which the CC might be employed. It is provided for orientation and guidance purposes only and does not constrain the development processes or evaluation schemes within which the CC must be employed. I.2 Development of Security Requirements and Specifications 389 TOE development and evaluation depend on the existence of a sound set of security requirements and specifications which have been shown to be valid. Figure I.1 below shows processes through which the requirements and specifications may be derived. 390 All security requirements and specifications derive from the security environment and expert analysis of the security problems in the context of the environment. That analysis leads to a statement of risks and threats which is used as the foundation for development of requirements and specifications. 391 If relevant to the user or user organisation, a parallel activity may be, or may already have been, undertaken to develop relevant security policies. Such security policies may be pertinent to security in general or may be IT specific technically oriented policies. The CC does not constrain or state requirements for security policies in general but makes provision for the incorporation of constraints implied by required adherence to security policies. 392 The build objectives process develops the TLSO based on the stated risks and threats using knowledge about the environment and incorporating any required policy constraints. The process is essentially an expert judgment. The CC does not constrain or state requirements for the scope and granularity of the TLSO but does identify required informational content. 393 The process of developing requirements refines the TLSO into a more detailed statement of IT security requirements and is subject to environmental constraints. The process is essentially one of requirements capture and analysis using the requirements components and profiles of the CC where feasible. Requirements capture may be specific to a known TOE leading to a security requirements statement for that TOE, or it may be directed towards determining security D R A F T I - Security development and evaluation model (informative) CCEB-94/082 Page 90 of 108 Version 0.9 94/10/31 requirements for solving a more general class of problem. In the latter case, the requirements may be expressed as a protection profile. 394 TOE security specifications are developed through a process of design refinement. The TOE design process requires the application of expert design skills and knowledge drawn from the environment and leads to the security target for the TOE. The CC states requirements for the content of the ST which is the basis for the development and evaluation of TOE security . [ Complicated graphic not easily represented in text format; not included in this file ] Figure I.1 - Derivation of requirements and specifications D R A F T CCEB-94/082 I - Security development and evaluation model (informative) 94/10/31 Version 0.9 Page 91 of 108 I.3 Development of TOE 395 The CC does not mandate any specific development methodology or life cycle model. Figure I.2 below depicts underlying assumptions about the relationship between the security requirements and the (secure) TOE. The figure is used to provide a context for discussion and should not be construed as advocating a preference for one methodology (e.g. 'waterfall') over another (e.g. 'prototyping'). [ Complicated graphic not easily represented in text format; not included in this file ] Figure I.2 - TOE Development Model 396 The process commences with the interpretation of the security requirements as a set of security functional and assurance specifications expressed in the security target. D R A F T I - Security development and evaluation model (informative) CCEB-94/082 Page 92 of 108 Version 0.9 94/10/31 Each lower level of refinement represents a design decomposition with additional design detail. The least abstract design level is the TOE implementation itself. 397 The CC does not mandate a specific set of design refinements. The CC requirement is that there should be sufficient design refinements presented at a sufficient level of granularity to demonstrate where required: a) The refinement level is a complete instantiation of the less abstract levels. Thus all security functions, properties, and behaviour defined at the higher level of abstraction must be demonstrably present in the lower level. b) The refinement level is an accurate instantiation of the less abstract levels. Thus there should be no security functions, properties, and behaviour defined at the lower level of abstraction which are not required by the higher level. c) The refinement level is an effective instantiation of the less abstract level. Thus there should be no functions, properties, or behaviour defined at the lower level of abstraction which are counter to the security objectives of the TOE. 398 The CC assurance criteria identify the design abstraction levels of architectural design, detailed design, and implementation. Developers will be required to show how the proposed development methodology meets the CC assurance requirements. I.4 Evaluation context 399 The CC are the basis for the evaluation of the security properties of a TOE and presupposes the existence of a controlled framework in which to conduct evaluations. The CC does not state requirements for the regulatory framework. However, consistency between the regulatory frameworks of different evaluation authorities will be necessary to achieve the goal of mutual recognition of the results of such evaluations between evaluation authorities. Figure I.3 below depicts the major elements which form the context for evaluations. 400 The IT security evaluation process analyses the TOE representations in accordance with the CC. Representations are evaluated to determine whether they are self consistent, comprehensible, and correctly interpret the higher level requirements. Representations will be evaluated to determine their fitness for purpose with respect to the statement of high level security objectives. 401 The evaluation process operates on material from the developer and evaluates the TOE using technical methods and techniques prescribed in the evaluation methodology and the standards laid down in the evaluation criteria. 402 Use of a standard evaluation methodology contributes to the repeatability and objectivity of the results but is not sufficient. Many of the evaluation criteria require the application of expert judgment and background knowledge for which consistency is more difficult to achieve. In order to enhance the consistency of the D R A F T CCEB-94/082 I - Security development and evaluation model (informative) 94/10/31 Version 0.9 Page 93 of 108 [ Complicated graphic not easily represented in text format; not included in this file ] Figure I.3 - Evaluation context 403 evaluation findings, the provisional evaluation results should be submitted to a certification process. Certification is the independent inspection of the conduct and results of the evaluation leading to an authoritative statement of the results. The certified results and associated qualifying material is the external output of the evaluation and is available to parties with an interest in the security properties of the TOE. The certification activity is outside the scope of the CC and is shown as a means of demonstrating how greater consistency in the application of the more subjective criteria might be achieved. 404 The evaluation methodology is applied within the administrative and legal framework laid down by the evaluation scheme which sets the standards and administers the regulations to which the evaluation facilities and evaluators must conform. The evaluation scheme, methodology, and certification processes are the responsibility of the bodies that run national schemes and are outside the scope of the CC. I.5 Use of evaluation results 405 IT products and systems differ in respect to the use of the results of the evaluation. Figure I.4 shows options for processing the results of evaluation. Products can be evaluated and catalogued at successively higher levels of aggregation until operational systems are achieved, at which time they may be subject to evaluation in connection with system accreditation D R A F T I - Security development and evaluation model (informative) CCEB-94/082 Page 94 of 108 Version 0.9 94/10/31 406 . [ Complicated graphic not easily represented in text format; not included in this file ] Figure I.4 - Use of evaluation results 407 The TOE is developed in response to requirements which may take account of the security properties of any evaluated products incorporated and profiles referenced. Subsequent evaluation of the TOE leads to a set of evaluation results documenting the findings of the evaluation. 408 Following an evaluation of an IT product intended for wider reuse, a summary of the evaluation findings might be entered in a catalogue of evaluated products so that it becomes available to a wider market seeking to use secure IT products. 409 Where the TOE is, or will be included in, an installed IT system which has been subject to evaluation, the evaluation results will be available to the system accreditor. The CC evaluation results may then be considered by the accreditor when applying organisation specific accreditation criteria which call for CC evaluation. CC evaluation results are one of the inputs to the accreditation process leading to a decision on accepting the risk of system operation. Evaluated Products Catalogue Register of Protection Profiles Security requirements Develop & evaluate TOE Catalogue product Evaluation results Evaluated product (optional)(optional) Accredit system Evaluated system System accreditation criteria (alternatives) D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 95 of 108 Annex J Evaluation of systems and products (informative) J.1 Introduction 410 The term TOE is used throughout the CC to refer to the target of evaluation without being categorical about the nature of the item to be evaluated. Previous evaluation criteria have distinguished between IT products as being intended for general application in a defined set of circumstances, and IT systems as being specific installations performing a specific task under the control of known responsible security authorities. Not all previous criteria have been applicable to IT systems. 411 The system accreditor has the responsibility for determining whether the system is secure enough to permit operation. This annex discusses the intended role of the CC in the accreditation process. This material is provided for guidance and explanation only, it does not place any requirements on accreditation responsibilities or criteria. J.2 Boundaries of CC applicability 412 The security requirements and objectives for an IT product will be stated in a protection profile or in the relevant parts of the security target if no profile is cited. 413 The security requirements and objectives for an IT system will normally be discussed in a set of system related security policy documents as prescribed by the organisation procuring the system. The CC does not place constraints on the manner of expression of such organisation specific policy documentation. The requirement remains for the security target to state the TOE security requirements and objectives by reference to policy and profile material where appropriate. Where the external requirements material is deficient with respect to CC requirements for the security target, the security target will make good the deficiencies. 414 Whether the TOE is a product or system, a clear statement of security requirements and objectives as the assumed basis for evaluation is necessary and will be stated directly or indirectly by the security target. 415 The purpose of evaluation is to validate the TOE against the assumptions about the threat environment and security requirements. Accreditors must, therefore, be aware of the limitations of the results of such an evaluation. The evaluation can only show that the system claims are upheld with respect to the threats identified in the assumed environment. The accreditor retains the responsibility to ensure that the actual countermeasures, both IT and non IT, are fit for purpose in the actual environment before system operation can be permitted. There is thus a need for further accreditation specific work which evaluates the dependencies between the D R A F T J - Evaluation of systems and products (informative) CCEB-94/082 Page 96 of 108 Version 0.9 94/10/31 IT and non IT measures and also considers whether the assumed threat environment is plausible and, if not, what the consequences are. 416 Additionally, as a result of the evaluation, there may be observations and caveats on the results. The accreditor must be convinced that such observations are taken into account in any installed configuration. 417 This additional work will be closely allied to the evaluation work and requires similar skills and knowledge but is not part of the CC evaluation. Accreditors must make their own arrangements to complete this work. D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 97 of 108 Annex K Preservation of philosophy of source criteria (informative) Editor Note: This annex, when completed in the final CC version, will discuss how important philosophical concepts from the source criteria have been handled in the CC. Such a discussion is important for those readers familiar with any of the source criteria, as the concepts have been preserved while the terms themselves may have changed in the interests of alignment. Currently, a number of these issues have been dealt with in a Technical Rationale document to accompany the CC October 1994 version. K.1 Effectiveness and correctness 418 TBD K.2 Strength of mechanism 419 TBD K.3 Reference monitor 420 TBD K.4 Trusted computing base 421 TBD K.5 Development and evaluation assurance 422 TBD K.6 Extensibility of requirements 423 TBD D R A F T K - Preservation of philosophy of source criteria (informative) CCEB- 94/082 Page 98 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 99 of 108 Annex L Additional background material (informative) L.1 Introduction 424 The material contained in this annex covers a variety of subjects related to the CC and is retained for information during the process of developing the criteria. Each subject covered here is to be reviewed before final publication of the CC for either removal or inclusion as a permanent informative annex to Part 1. The material may eventually turn out to be appropriate for preparation of several annexes, e.g., reference monitor, level of assurance detail (formal, semi-formal, informal), and verbs used for evidence and evaluator actions. L.2 History of international evaluation criteria 425 The history of standardisation of criteria for evaluation of IT security within ISO is not a very long one. The Working Group 3 (WG3) assigned this task was created in Stockholm in 1990, coincident with the creation of its parent subcommittee 27 (SC27). At that time, several initiatives aiming at security evaluation, certification and evaluation facility accreditation had been taken on a national basis, and the needs for co-ordination and international standardisation were becoming very clear. Purely national standards for evaluation, coupled with certification and evaluation facility accreditation schemes based on purely national criteria, would quite efficiently preclude mutual recognition of evaluation results between countries. The lack of mutual recognition agreements would in turn create trade barriers between countries or groups of countries, and this would again lead to significantly higher costs for the users of security evaluated systems. L.2.1 Recent progress 426 Significant evolution of the national and multinational security evaluation criteria has taken place since 1990. The Information Technology Security Evaluation Criteria (ITSEC) Version 1.2 was published by the Commission of the European Communities (EC) in June 1991, for use by the EC (now European Union) on a trial basis. An accompanying publication, the Information Technology Security Evaluation Manual (ITSEM), version 1.0 was published in Fall 1993 by the Commission. In Canada, Version 3.0e of the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) was published in January 1993. In the United States, draft Version 1.0 of the new Federal Criteria for Information Technology Security (FC) was published in January 1993, to replace the Trusted Computer Systems Evaluation Criteria (TCSEC). In ISO, a series of working drafts of an international standard criteria were developed and discussed since 1991 without much D R A F T L - Additional background material (informative) CCEB-94/082 Page 100 of 108 Version 0.9 94/10/31 substantive progress in resolving the fundamental differences in approach and content among the various criteria. L.2.2 The Common Criteria project 427 In June 1993, the EC, along with the governments of Canada and the United States, began a project to align their three criteria into a single draft Common Criteria (CC). These governments formed a body called the Common Criteria Editorial Board (CCEB) to write the draft CC. At the Paris SC27 meeting in October 1993, a formal liaison was established between the CCEB and WG3. The stated intent of the project is to resolve the philosophical and technical differences now found in the three main published criteria, and then to deliver the still-draft results after testing to ISO as a contribution toward its work in progressing the international standard. 428 This CC Project will undoubtedly have a significant influence on the planned ISO criteria. The project has strong prospects for speeding the work of developing an acceptable international standard. At the same time, through active liaison between the CC project and WG3, the WG3 participants can continue to have strong influence upon the draft as it develops. L.3 Common Criteria project terms of reference 429 The scope and objectives of the CC Project, as described in an informal Terms of Reference document prepared by the project sponsors, are summarised below. L.3.1 Scope of Common Criteria project 430 The scope of the CC alignment activity is to harmonize the ITSEC, CTCPEC, and FC for use within Europe and North America. The ISO/IEC JTC1/SC27/WG3 draft criteria documents will provide the initial framework. The result will be put back to WG3 as a contribution to international standardisation. L.3.2 Objectives of Common Criteria project 431 The objectives of the CC alignment activity are: a) To acquire a clear picture of the similarities and differences in the ITSEC, CTCPEC and FC; b) To align the ITSEC, CTCPEC and FC; c) To use the most relevant parts of each of the three criteria as the basis for the CC. L.4 ISO Subcommittee 27 Working Group 3 terms of reference 432 The Terms of Reference for SC27/WG3, as amended at its second meeting in Tokyo, were: D R A F T CCEB-94/082 L - Additional background material (informative) 94/10/31 Version 0.9 Page 101 of 108 433 "Standards for IT security evaluation and certification of IT systems and products. This will include consideration of computer networks, distributed systems, associated application services, etc. 434 Three aspects may be distinguished: a) Evaluation criteria; b) Methodology for application of the criteria; and c) Administrative procedures for evaluation, certification, accreditation schemes for evaluation facilities. 435 This work will reflect the needs of relevant market sectors in society as represented in ISO, expressed in standards for security functions and assurance. 436 Account will be taken of related ISO standards for quality management and testing so as not to duplicate these efforts." D R A F T L - Additional background material (informative) CCEB-94/082 Page 102 of 108 Version 0.9 94/10/31 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 103 of 108 Annex M Bibliography (informative) M.1 Referenced standards a) Trusted Computer Systems Evaluation Criteria (TCSEC), US DoD 5200.28-STD, Dec. 1985. b) Information Technology Security Evaluation Criteria (ITSEC), Version 1.2, Office for Official Publications of the European Communities, June 1991. c) Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), Version 3.0, Canadian System Security Centre, Communications Security Establishment, Government of Canada, Jan. 1993. d) Federal Criteria for Information Technology Security (FC), Draft Version 1.0, (Volumes I and II), jointly published by the National Institute of Standards and Technology and the National Security Agency, US Government, Jan. 1993. e) Evaluation Criteria for IT Security, Part 1: General model of security evaluation, Fourth Working Draft, ISO/IEC/JTC1 SC27/WG3 N182, 1992- 12-16. f) Evaluation Criteria for IT Security, Part 2: Functionality of IT systems, products and components, Fourth Working Draft, ISO/IEC/JTC1 SC27/ WG3 N183, 1992-12-16. g) Evaluation Criteria for IT Security, Part 3: Assurance of IT systems, products and components, Fifth Working Draft, ISO/IEC/JTC1 SC27/WG3 N184, 1992-12-16. M.2 Applicable standards h) ISO Directive 3: Style guide. i) ISO Guide 2: 1991. General terms and their definitions concerning standardisation and related activities. D R A F T M - Bibliography (informative) CCEB-94/082 Page 104 of 108 Version 0.9 94/10/31 M.3 Related standards j) ISO 7498-2: 1989. Information processing systems - Open Systems Interconnection - Basic Reference Model, Part 2: Security Architecture. k) POSIX 1003.6 l) X509 437 D R A F T CCEB-94/082 94/10/31 Version 0.9 Page 105 of 108 Annex N Index (informative) This index will provide keywords to all parts. In this version of the CC only keywords to Part 1 are given. The format is: P-. A abbreviation P1-6 access right P1-31 type P1-31 accountability P1-31 accreditation P1-19, P1-31 accreditor P1-8, P1-18 administrator P1-33 application P1-17 architect P1-8 assurance P1-9, P1-13, P1-14, P1-23, P1- 26, P1-29, P1-31 component P1-15 level P1-15, P1-25, P1-26, P1-29, P1-31 rating P1-19 requirement P1-13, P1-15, P1-26 scale P1-13 assurance level P1- 13, P1-14 assurance rating P1-9 assurance requirement P1-9, P1-12 assurance specification P1-13 attacker P1-27 augmentation P1-31 augmented P1-21 part 3 P1-21 authority P1-8 availability P1-17, P1-31 B basic session locking P1-12 behaviour P1-13, P1-15, P1-32 C CC P1-1, P1-6 conformance P1-10 class P1-11, P1-12, P1-14, P1-32, P1- 37, P1-38 compliance P1-20 compliant P1-26 component P1-11, P1-12, P1-14, P1- 15, P1-25, P1-26, P1-32 functional P1-29 levelling P1-40 confidentiality P1- 17, P1-32 configuration list P1-12 configuration management P1-12 basic P1-12 conformance P1-10, P1-20 conformant P1-20, P1-21 CC P1-21 part 3 P1-21 part2 P1-20 conformant, part2 P1-20 constrain P1-32 construction P1-9 consumer P1-7 consumer group P1-7 correctness P1-24, P1-29, P1-32 cryptographic algorithm P1-18 cryptography P1-18 custodian P1-8 D definition P1-9 dependency P1-11, P1-13, P1-26, P1-32 design P1-24 developer P1-7, P1-15, P1-27 developer security P1-12 development P1-2 development environment P1-12 development process P1-2, P1-3, P1-12 disclosure P1-17 D R A F T N - Index (informative) CCEB-94/082 Page 106 of 108 Version 0.9 94/10/31 documentation P1-40 domain P1-34 E effectiveness P1-23, P1-24, P1-29, P1-32 electromagnetic emanation P1- 17 element P1-11, P1-12, P1-14, P1-32 encapsulation P1-32 end product P1-2 evaluation P1-2 evaluation process P1-3 input P1-4 evaluation result P1-20 evaluation scheme P1-2 evaluator P1-7, P1-8, P1-15 evidence P1-3 expertise P1- 27 extended P1-20, P1-21 part 3 P1-21 part2 P1-20 F family P1-11, P1-12, P1-14, P1-32, P1-37, P1- 38 behaviour P1-39 component P1-39 name P1-38 objective P1-39 rationale P1-39 reference name P1- 38 requirement P1-39 threat P1-39 formal P1-32 function P1-14, P1-23 expression of P1-20 functional package P1-14, P1-15 functional requirement P1- 9, P1-12 functional specification P1-13 H hardware P1-17 history P1-5 I informal P1-33 integrity P1-17, P1-33 interface P1-13 IT P1-6 IT development P1-2 IT security P1-1 IT security controls P1-2 L limitations of evaluation P1-19 loss of use P1-17 M mechanism P1-34 method of entry P1-12 modification P1-17 motivation P1- 27 mutual recognition P1-2, P1-5 N n P1-37 network P1-17 non-repudiation P1-17 note application P1-39 audit P1-40 documentation P1-40 evaluator P1-40 user P1-39 O object P1-33, P1-34 objective P1-2, P1-10, P1-23, P1-35, P1-38 top level security P1-10 operation P1-2, P1-4, P1-9 opportunity P1-27 P package P1-13, P1-25, P1-26, P1-33 D R A F T CCEB-94/082 N - Index (informative) 94/10/31 Version 0.9 Page 107 of 108 functional P1-14 part 2 conformant P1-20 part 3 conformant P1-21 part 3 extended P1-21 part2 extended P1-20 part3 augmented P1-21 personnel P1-17 policy P1-10, P1-29, P1-34 PP P1-2, P1-6, P1-7, P1-13, P1-25, P1-26, P1- 33 evaluation P1-29 protection profile P1-25 procedures P1-17 procurer P1-7 producer P1-7 product P1-7, P1-8, P1-9, P1-17, P1-24 product security specifications P1-2 protection profile P1-2, P1-6, P1-7, P1-13, P1- 14, P1-25, P1-26, P1-33 evaluation P1-29 predefined P1-16 Q quality P1-1 R re-evaluation P1-4 register P1-16 requirement P1-2, P1-23, P1-25, P1-27 analysis P1-23 assurance P1-9, P1-12, P1-13, P1-15, P1- 29 construction P1-26 construction rule P1-37 functional P1-9, P1-12, P1-15, P1-29, P1- 37 organisation of P1-11 presentation P1-37 register P1-26 re-use P1-26 source P1-25 residual risk P1-29 residual vulnerability P1-25 resource P1-27, P1-33, P1-34 re-use P1-26 reuse P1-2, P1-13 risk analysis P1-1, P1-7, P1-10 role P1-33 S safety P1-1 scale P1-19 scheme P1-2 scope P1-6, P1-17 scope of control P1-34 security P1-34 administrator P1-33 assurance requirement P1-9 attribute P1-17, P1-34 domain P1-34 environment P1-23 feature P1-17 function P1-6, P1-34 function policy P1-34 functional requirement P1-9 measure P1-17 mechanism P1- 34 objective P1-23, P1-35 organisational P1-17 physical P1-17 policy P1-10, P1-34 property P1-17 requirement P1-23, P1-24 specification P1-23, P1-24, P1- 27 security function P1-13 security objective P1-10 security objectives P1-2 security policy P1-10 security requirement P1-25 security specification P1-13 security target P1-2, P1-6, P1-13, P1-20, P1- 27, P1-29 security target, ST P1-34 semiformal P1-34 service P1-17 D R A F T N - Index (informative) CCEB-94/082 Page 108 of 108 Version 0.9 94/10/31 session locking P1-12 basic P1-12 user P1-12 SF P1-6, P1-34 SFP P1-34 software P1-17 specification P1-13, P1-23, P1-24, P1-27 assurance P1-13, P1-24 expression of P1-13 functional P1-13, P1-24 sponsor P1-8 ST P1-2, P1-6, P1-13, P1-20, P1-27, P1-29 statement of threat P1-10 strength claim P1-27 evaluation P1-28 of function P1-27 of TOE P1-27 subject P1-34 system P1-7, P1-8, P1-9, P1-17, P1-24 accreditation P1-17 system, distributed P1-17 T target of evaluation P1-6, P1-34 TCB P1-35 The P1-38 threat P1-29, P1- 39 environment P1-27 intensity P1-27, P1-39 level P1-27 level A P1-27 level B P1-27 level C P1-27 statement of P1-27 threat analysis P1-1 threat scenario P1-10 TLSO P1-6, P1-10, P1-13, P1-15, P1-23, P1- 24, P1-25, P1-35 TOE P1-6, P1-9, P1-10, P1-13, P1-17, P1-23, P1-24, P1-34, P1-35 consistency P1- 23 scope of control P1-35 security functions P1-34 security policy P1-34, P1-35 security specification P1-24 TOE Entry P1- 12 TOE Security Functions P1-6 TOE Security Policy P1-6 top level security objectives P1-6, P1-10, P1- 15, P1-23, P1-24 trusted channel P1-35 Trusted Computing Base P1-35 trusted path P1-35 TSC P1-6, P1-34, P1-35 TSF P1-6, P1- 34, P1-35 TSP P1-6, P1-34, P1-35 U untrusted P1-35 user P1-34, P1-35 authorised P1-31 human P1-33 machine P1-33 user data protection P1-12 user session locking P1-12 V vulnerability analysis P1-28