D R A F T Common Criteria for Information Technology Security Evaluation CCEB-94/080 Common Criteria Technical Rationale P r e l i m i n a r y D R A F T Version 0.5 94/10/31 D R A F T This document is paginated from i to iv and from 1 to 28 D R A F T CCEB-94/080 Table of contents 94/10/31 Version 0.5 Page i of iv Table of contents Chapter 1 Introduction .................................................... 1 1.1 Disclaimer ............................................................ 1 1.2 Rationale ............................................................. 1 Chapter 2 Effectiveness and correctness .................................. 3 2.1 Introduction .......................................................... 3 2.2 Background ............................................................ 3 2.3 Discussion ............................................................ 3 2.3.1 The assurance issue ................................................. 3 2.3.2 The concepts of effectiveness and correctness ....................... 4 2.4 Technical approach .................................................... 5 2.5 Application .......................................................... 5 Chapter 3 Evaluation of systems and products ............................. 7 3.1 Introduction .......................................................... 7 3.2 Background ............................................................ 7 3.3 Discussion ............................................................ 8 3.4 Technical approach .................................................... 8 3.5 Application .......................................................... 9 Chapter 4 Strength of mechanism .......................................... 11 4.1 Introduction ......................................................... 11 4.2 Background ........................................................... 11 4.3 Discussion ........................................................... 12 4.4 Technical approach ................................................... 12 4.5 Application ......................................................... 13 Chapter 5 Extension of security requirements ............................. 15 5.1 Introduction ......................................................... 15 5.2 Background ........................................................... 15 5.3 Discussion ........................................................... 16 5.3.1 New requirements vs. new mechanisms ................................ 16 5.3.2 Criteria change management ........................................ 17 5.3.3 Limitations on introduction of new concepts ........................ 17 5.3.4 Limitations on applicability of assurance techniques ............... 17 5.3.5 CC conformance ..................................................... 17 5.4 Technical approach ................................................... 18 D R A F T Table of contents CCEB-94/080 Page ii of iv Version 0.5 94/10/31 5.5 Application ......................................................... 19 Chapter 6 Relationship of Protection Profiles to Security Targets ....... 21 6.1 Introduction ......................................................... 21 6.2 Background ........................................................... 21 6.3 Discussion ........................................................... 21 6.4 Technical approach ................................................... 22 6.5 Application ......................................................... 22 Chapter 7 The reference monitor and the TCB .............................. 25 7.1 Introduction ......................................................... 25 7.2 Background ........................................................... 25 7.3 Discussion ........................................................... 25 7.3.1 The reference monitor concept ...................................... 25 7.3.2 The Trusted Computing Base ......................................... 26 7.4 Technical approach ................................................... 27 7.5 Application ......................................................... 27 D R A F T CCEB-94/080 List of figures 94/10/31 Version 0.5 Page iii of iv List of figures Figure 5.1 - Relationships between types of conformance ................. 20 D R A F T List of tables CCEB-94/080 Page iv of iv Version 0.5 94/10/31 List of tables D R A F T 2 CCEB-94/080 94/10/31 Version 0.5 Page 1 of 28 Chapter 1 Introduction 1.1 Disclaimer 1 The Common Criteria (CC) is the outcome of a project to align the existing and emerging evaluation criteria (FC/USA including TCSEC, CTCPEC/Canada, ITSEC/Europe, and ISO). The CC is compatible with existing criteria. The material hereafter describes the initial thoughts on the preservation in the CC of the key concepts in the aforementioned source criteria. 2 Since the writing of this material, the CC has evolved and the current material does not necessarily reflect the current state of the CC. It is presented here to provide the readers with a background in the source criteria, to trace back the key concepts in the source criteria to the CC. Therefore, the material is given for informational purposes only, and no claims can be made based on this material. 1.2 Rationale 3 This rationale document is an attempt to capture the discussions that have taken place and the decisions that have been made in harmonising the existing criteria. This document is not an exhaustive list of all of the issues which have been discussed during the CC effort. Rather, it attempts to summarise those issue which have generated significant discussion and/or for which significant differences were found to exist between the input criteria. 4 A separate chapter is provided for each distinct issue. For each issue, the following information has been included: a) Title: the title of the chapter contains a short descriptive name for the issue. b) Introduction: the introduction section contains a brief description which characterises the issues being discussed. c) Background: the background section enumerates the concepts from the input criteria (TCSEC, ITSEC, CTCPEC, FC, and ISO criteria) and provides the backwards traceability to those criteria. The criteria from which the issues have originated should be included in the background section. d) Discussion: the discussion section clearly documents the discussion which has taken a place within the CCEB. e) Technical approach: the technical approach section enumerates the concepts which have been agreed. The concepts are those which will shape D R A F T 1 - Introduction CCEB-94/080 Page 2 of 28 Version 0.5 94/10/31 the technical approach in the CC. These concepts, which can be considered key to the approach, need not be indivisible. f) Application: the application section traces the agreed `key' concepts into the CC. Where a key concept is divided and used in more than one Part of the CC (or within a Part of the CC if this level of granularity is deemed necessary) traceability shall be maintained. D R A F T 6 CCEB-94/080 94/10/31 Version 0.5 Page 3 of 28 Chapter 2 Effectiveness and correctness 2.1 Introduction 5 The issue addressed in this paper is how the concepts of effectiveness and correctness are to be incorporated into the Common Criteria (CC). In particular, how these concepts are to be accommodated by the Assurance components and the Assurance component levels. The discussion starts with a description of a general model of the development process and then proceeds to how the notions of effectiveness and correctness are incorporated into the CC. 6 Section B.9 of the Conceptual Framework documents the initial agreement. 2.2 Background 7 The development model that forms the context for this discussion is one composed of a set of step-wise refinements of requirements into an implementation in hardware and software. This model presumes that there exists a statement of requirements for the system that are expressed in a narrative form. From this statement of requirements is derived an expression of a technical specification: the definition of the features, behaviour, and attributes to be provided by the hardware and software. This is the specification level; the highest level of abstraction of the system. This level of abstraction is interpreted into a high-level design. That is, this level of abstraction is refined into a level of specification containing more detail. In a sense, it is an implementation of the high-level design, but remains an abstract machine. This step-wise refinement continues until an implementation is realised; a real (vice abstract) machine is constructed that can be exercised and subjected to testing. 2.3 Discussion 2.3.1 The assurance issue 8 The central focus of assurance is the extent to which the presumed threats to the TOE have been countered and the presumed threats to the assets to be protected have been countered. Procedurally, this becomes the determination of whether or not the implementation is a complete and accurate interpretation of the technical specifications. That is, assurance addresses the question of the degree to which one can be certain that the implementation provides the security features, behaviour and attributes defined in the high- level abstractions; in particular, the technical specifications. D R A F T 2 - Effectiveness and correctness CCEB-94/080 Page 4 of 28 Version 0.5 94/10/31 2.3.2 The concepts of effectiveness and correctness 9 The concepts of effectiveness and correctness measure assurance in the following manner. 2.3.2.1 Effectiveness 10 Effectiveness is, in effect, a conditional judgment about the high- level abstractions of the system (primarily at the high-level design). It is a statement that the features proposed, if implemented correctly (i.e., without error) will have the security effects desired: they will be effective in countering the threats postulated. Critical aspects of this determination include: a) The suitability of the selected security functions in countering the identified threats; b) The implications of known security vulnerabilities; c) Whether or not the set of security functions compose into a integrated coherent and cohesive effective whole (i.e., the dependency issues). 2.3.2.2 Correctness 11 Correctness deals with the conditional part of the mapping. That is, it addresses the question of whether or not the implementation is a complete and accurate representation of the specifications. More specifically, correctness deals with the issues: a) Are all the specifications implemented; does the implementation contain everything that is stated in the specification; and b) Is there anything in the implementation that is not implied by the specifications; does the specification conceal unexpected functions? 12 The first condition means that the details of the specification must be mappable to details of the implementation, whereas the second condition means that the implementation must be shown to be nothing other than an expansion of the specification; that there is no details in the implementation that cannot be mapped back to a requirement of the original specification. 2.3.2.3 Evaluation judgment 13 Ultimately, one needs to reach a judgment about whether the TOE exhibits the security effects and behaviour desired. Especially, that the TOE counters the threats postulated. Such judgments become the end result of a series of incremental conclusions that allows an argument about the qualities of the implementation with reference to the original specifications. The quality and strength of the conclusions reached may vary (e.g., as a result of the level of evidence available and the granularity of development refinements), but the evaluation process must be D R A F T CCEB-94/080 2 - Effectiveness and correctness 94/10/31 Version 0.5 Page 5 of 28 complete, in the sense that a judgment is reached about the implementation relative to the specifications. 2.4 Technical approach 14 There will be no separate ratings for effectiveness or correctness. These concepts and the judgments about them will appear as integral elements of the judgments to be reached by analysis and supported by the evidence. 15 Assurance is presented in the CC in the form of a set of component levels. Each component level is in the form of a triple (i.e., the evidence required, the content of the evidence, and the analysis to be performed on the evidence). These will be organised in Part 3 in two formats: a) There will be an expression of each Assurance Level. Each is composed of all the specific requirements (i.e., all the triples) for achieving that level. The requirements span the entire development process and also cover other critical aspects (i.e., development environment and operation of the TOE). The definition of the Assurance Levels will appear in the main body of Part 3. b) There will be a listing of the triples ordered by the critical aspects covered by the Assurance Levels (i.e., the "ordering principles" or, assurance components). This listing will also include any triples needed for compatibility with the source documents and previous evaluations. That is, compatibility with existing IT security criteria and evaluation results is achieved either directly (i.e., direct application of an Assurance Level) or by augmentation of an Assurance Level. 16 In summary, the notions of effectiveness and correctness appear as aspects of the assurance triples, largely as determinations to be made as a result of the analysis of appropriate evidence. 2.5 Application 17 D R A F T 2 - Effectiveness and correctness CCEB-94/080 Page 6 of 28 Version 0.5 94/10/31 D R A F T 10 CCEB-94/080 94/10/31 Version 0.5 Page 7 of 28 Chapter 3 Evaluation of systems and products 3.1 Introduction 18 The applicability of CC evaluations to IT systems as well as products is discussed. 19 Current system accreditation practice in the US does not call for formal evaluation against TCSEC style criteria. The TCSEC targets products exclusively, the US evaluation community does not apply criteria style evaluations to accreditable systems and does not claim that systems are within the scope of the criteria. ITSEC regards system evaluations as in scope. For example, it is routine practice in the UK to subject systems to ITSEC evaluation as part of the accreditation process. The CC needs to reconcile these differing approaches. 20 Thus the question is whether it is necessary, or even appropriate, for the CC to claim to cover products and systems and, if so, what if any distinctions should be made in terms of evaluation approach, results and evidence. 21 Section B.8 of the Conceptual Framework documents the initial agreement. 3.2 Background 22 In the ITSEC, a product is defined as a package of IT software and/or hardware, providing functions designed for use or incorporation within a multiplicity of systems. In this definition, it is assumed that a product may be arbitrarily complex, and may be composed of other products (i.e., meta- product, compound product, complex product, subsystem). A system is a specific IT installation with a particular purpose and operational environment. In this definition, there is no specification of size or complexity. The key difference between product and system is therefore in usage of the entity: multiplicity of uses (a product) versus singularity of use (this system). 23 The ITSEC introduced the notion that it may be used as criteria for evaluation of the IT security aspects of operational systems in support of the accreditation decision. Certification of system evaluation results per the ITSEC was also seen to fit under the national scheme, in a way largely analogous to the way product evaluation results were handled. In the ITSEC, a key difference between products and systems was in the way that the security target is structured. A system security target may refer to organisation specific security policies to meet the requirements for security targets. 24 Security evaluation in support of accreditation has long been known and used in North America; however, accreditation specific evaluation criteria (not those used for product evaluation) have been used. The evaluation criteria to be used has been D R A F T 3 - Evaluation of systems and products CCEB-94/080 Page 8 of 28 Version 0.5 94/10/31 a matter left up to the individual organisation or agency, as has been the decision whether to use a third-party review of evaluation results. Consequently, the TCSEC, CTCPEC and FC do not address system evaluation (evaluation in support of the accreditation decision), instead focusing strictly on product evaluations. 3.3 Discussion 25 From a European perspective it is important that the CC preserve the ability to perform system evaluations in support of accreditation. 26 From a NA perspective, the CC might claim applicability to systems but should note that this is an accreditation option. There are many models for accreditation which need not involve a criteria based evaluation. 27 It was the EB view that there was no significant distinction to be made between systems and products with respect to evaluation. Both possessed an assumed threat scenario and claimed security functions to counter the threat, both could be evaluated on that basis. Any differences were likely to be in level of detail rather than substance. It is likely that more will be known about the system environment than a product environment and there may be a better basis for the assumed system threats than the relevant product threats. 28 The approach should therefore be that the CC will claim technical competence for systems but indicate that use for system evaluation is solely at the discretion of the accreditation authorities. 3.4 Technical approach 29 The security requirements for an IT product will be stated in a protection profile or directly in the security target if there is no PP referenced. In either case, a clear statement of security requirements is mandatory. 30 The security requirements for an IT system will normally be stated in a set of system related security policy documents as prescribed by the organisation procuring the system. It is not the intention of the CC to place constraints on the manner of expression of such organisation specific policies. The requirement remains for the security target to identify the security requirements statements by reference to such policy documentation where available. Where the organisation specific policy documentation is deficient with respect to requirements for the security target, the security target will contain the missing information. 31 Whatever the class of TOE, the requirements statement and the ST will state the threat environment which the evaluated functions must counter. There may be a difference of detail between the information available for systems viz products. 32 The purpose of the evaluation is to validate the claims against the assumed threat environment for the TOE. For a product or system, the outcome of evaluation is a statement to that effect. For a system, the output of evaluation is an input into D R A F T CCEB-94/080 3 - Evaluation of systems and products 94/10/31 Version 0.5 Page 9 of 28 accreditation. Whether there is independent certification of the system against the claims is a matter for system accreditation policy and controlling evaluation schemes. 33 Accreditors must be aware of the limitations of the results of such a CC evaluation. The CC evaluation can show that the system claims are upheld with respect to the threats identified in the assumed environment. The accreditor has responsibilities to ensure that the actual countermeasures, both IT and non IT, are fit for purpose before operation can be permitted. Thus there is a need for additional accreditation specific work which evaluates the binding between the IT and non IT measures (are the environmental assumptions upheld?), and also considers whether the assumed threat environment is still valid and, if not, what the consequences are. 34 Additionally, as a result of the CC evaluation, there may be observations and caveats on the results, the accreditor must be sure that such observations are taken into account in the installed configuration. 35 This additional work may be closely allied to the CC evaluation work and requires similar skills and preferably the same evaluation resources but is not part of the CC evaluation. Accreditors must make their own arrangements to complete this work. 3.5 Application 36 Part 1 discusses the differences between systems & products in the general model & notes that there are two principal discriminators, namely the manner of expression of security requirements and the destination of results/purpose of evaluation. These are the points where the distinction is made. 37 In practice, because typically more is known about the system environment, there will be more detail in the system requirements documentation but the differences are confined to presentation and level of detail. The requirements for content remain unchanged. 38 Is has been agreed that the term TOE will be used throughout parts 2 and 3, within these parts there is no obvious need to make the distinction. Should it be necessary to make the distinction on any point of detail, this can be handled as an exception. D R A F T 3 - Evaluation of systems and products CCEB-94/080 Page 10 of 28 Version 0.5 94/10/31 D R A F T 14 CCEB-94/080 94/10/31 Version 0.5 Page 11 of 28 Chapter 4 Strength of mechanism 4.1 Introduction 39 It is recognised that even though a security function can be shown to be correctly implemented, non-bypassable, and non-circumventable, it may still be possible to defeat the intention of the function by direct attack. This is due to possible deficiencies in the underlying approaches used at conceiving and implementing a security function. Both the ITSEC and the FC deal with these inherent functional security vulnerabilities in different ways. This issue paper describes and analyses both approaches and suggests a new strategy which is believed to preserve the intent of the ITSEC and the FC and is meaningful within the context of the CC. 40 Sections B.3 and B.4 of the Conceptual Framework document the initial agreements. 4.2 Background 41 The ITSEC addresses inherent functional security vulnerabilities through the use of a Strength of Mechanism (SoM) technique. The Strength of Mechanism (SoM) concept is treated in the ITSEC as an aspect of the assessment of the effectiveness of a TOE. This assessment demonstrates the ability of a security mechanisms to withstand direct attack against deficiencies in its underlying algorithms, principles and properties. The ITSEC recognises that mechanisms have limitations which can be exploited given an appropriate level of resources, expertise and opportunity. However, the goal of the ITSEC, is not to strive for a perfect mechanism, but rather to create a suitable mechanism that is appropriate for its intended environment of use. Within the context of the ITSEC, mechanisms are rated according to strength. This rating is in terms of the expertise, opportunity or resources and time that it would take to defeat the mechanism. The current rating scheme of the ITSEC (Basic, Medium, and High) could be perceived in some cases as being pejorative. Rating a mechanism as "basic" has a negative implication, while in reality the TOE may have done a good job (it was effective) at addressing the stated threats. 42 The Federal Criteria also saw the need to provide for a strength consideration, but in a slightly different context. The Federal Criteria describes strength as the "conditions" under which a function can withstand a defined attack or tolerates failures. In this respect, the FC's notion of SoM is not much different from that of the ITSEC's. However, the FC's approach at measuring and applying SoM criteria does differ from that of the ITSEC. The FC addresses strength at the requirement level, while the ITSEC addresses strength at a mechanism level, which includes its implementation. Therefore a more accurate description of the FC's notion of strength is "Strength of Requirement" (SoR). FC functional components are D R A F T 4 - Strength of mechanism CCEB-94/080 Page 12 of 28 Version 0.5 94/10/31 levelled in the form of requirements and can be selected for use in a Protection Profile based on strength. 43 It has been noted by CCEB members, who have experience with applying the SoM notions of the ITSEC that in practice the concept of SoM does not apply to all types of mechanism. This reality is also consistent with SoR of the FC, in that SoR is only applied to a small subset of all functional components (i.e., Identification and Authentication, Audit, Security Management and TCB physical protection). FC considers SoR aspects among others aspects when levelling components, or in accurate FC terms when "rating" functional components. Other rating aspects include the scope, granularity, and coverage of a functional component. 4.3 Discussion 44 The CCEB agreed that the CC should support a notion of strength in addressing direct attacks against mechanism. 45 The recommended approach at applying SoM & SoR to the CC drew upon relevant aspects of the ITSEC and FC. Fortunately, both the ITSEC and the FC support a common goal in addressing direct security mechanism attacks. That goal should not change in the CC. Some ITSEC/FC differences do exist and need to be considered in the context of the CC. Also, some problems have surfaced when attempting to apply SoM in the context of ITSEC evaluations. These problems should not be replicated in the CC. 4.4 Technical approach 46 It was felt that because strength of requirement/mechanism is so closely associated with the TOE's assumed/known environment that SoR/M is best considered at the mechanism or implementation level, not at the requirement level. It is at this point that the greatest amount of information is available about the impact of the threats analysed. 47 A security mechanism is defined as the logic or algorithm that implements a particular security function in hardware and/or software. Mechanisms should be classified in two categories: 48 A type A mechanism is a security mechanism with a potential vulnerability in its algorithm, principles or properties, whereby the mechanism can be overcome by the use of sufficient resources, expertise and opportunity in the form of a direct attack. An example of a type A mechanism would be an authentication program using a password: if the password can be guessed by attempting all possible passwords in succession, the authentication mechanism is of type A. Type A mechanisms often involve the use of a "secret" such as a password or cryptographic key. 49 All type A mechanisms in a TOE have a strength, which corresponds to the level of resources, expertise and opportunity required to compromise security by directly attacking the mechanism. D R A F T CCEB-94/080 4 - Strength of mechanism 94/10/31 Version 0.5 Page 13 of 28 50 The specification of required strength (strength claim) should be described within the Protection Profile and/or Security Target. Strength should be defined in terms of a mechanisms ability to resist direct attacks. Attacks should be qualified in terms of a threat agent's time and available resources, opportunity and expertise. 51 A type B mechanism is a security mechanism which, if perfectly conceived and implemented, is not amenable to direct attack. A type B mechanism can be considered to be impregnable to direct attack regardless of the level of resources, expertise and opportunity deployed. A potential example of a type B mechanism would be access control based on access control lists: if perfectly conceived and implemented, this type B mechanism cannot be defeated by direct attack. 52 Functional components defined in Part 2 of the CC should not be levelled using strength considerations. It is believed that components can be adequately levelled on the basis of some combination of scope, granularity and coverage alone. But for some components, the required use of type B mechanism may be used as a levelling basis. 53 The mechanism should be evaluated in terms of its underlying algorithms, principles and properties in the context of the TOE. 54 When assessing the strength of a mechanism, the operation environment in which the mechanism operates in the TOE should be taken into account. 55 SoM analysis should only apply to type A mechanisms. 4.5 Application 56 A new rating scheme for the SoR/M should be defined and described in Part 1 of the CC. The impact on Part 1 should be considered by the Part 1 sub working group. 57 Rules for component levelling should be defined in Part2. Specific requirements for type B mechanisms should be noted. A list of applicable type A mechanisms could be created and noted in Part 2 for guidance. The impact on Part 2 should be considered by the Part 2 sub working group. 58 Evaluation criteria and guidance for the assessment of SoR/M should be defined in Part 3 of the CC in order to reduce subjectivity, such that evaluation criteria could be uniformly applied and reproduced across multiple evaluation laboratories. The impact on Part 3 should be considered by the Part 3 sub working group. D R A F T 4 - Strength of mechanism CCEB-94/080 Page 14 of 28 Version 0.5 94/10/31 D R A F T 20 CCEB-94/080 94/10/31 Version 0.5 Page 15 of 28 Chapter 5 Extension of security requirements 5.1 Introduction 59 In order for the CC to be successful, it must be based upon an approach that accommodates all advances in the field of IT security & IT technology. One possible approach is for the CC to avoid, to the maximum extent possible, any connection to IT-specific technology. This approach would have the CC focus its attention primarily upon techniques, evidence, and analysis to determine the "quality" or utility of whatever technology is of interest. Another approach is for the CC to directly address well-understood security technology and establish an orderly processfor modifying the CC as the technical community's understanding and acceptance of the technology advances. 5.2 Background 60 The CC is an attempt to define a single IT security criteria that can address the needs of many nations and thus serve as a major expert input to the production of an international standard for IT security. To achieve this goal the criteria must be flexible and extensible enough to address a wide range of applications while at the same time clear and specific enough to allow different nations to use it for effectively communicating the security properties of an IT product or system. 61 The ITSEC has attempted to address these goals by focusing exclusively upon the assurance issues, allowing the sponsor to specify any security requirements or functions they are willing to have evaluated. While this allows maximum flexibility and extensibility of functions, it does not allow flexibility or extensibility in assurance nor does it provide a basis for easy comparison or communication of security needs or evaluation results. 62 The TCSEC's approach was to define not only security functional requirements and assurances but to define all permissible combinations of the two as well. While this allowed for easy communication and comparison of the security properties of IT products and systems, it limited the criteria's effective application to those domains and technologies specified by its authors. 63 The CTCPEC has taken yet another approach. Its approach was to specify both security functional requirements and assurances and place only the essential limits on their combination. In addition, the evaluation authority for the Canadian government will, on a provisional, case by case basis, perform evaluations against functional requirements not specified in the CTCPEC. This provides for easy communication and comparison of most results, flexibility to use the functinal aspects of the criteria in unanticipated applications, and a method of allowing D R A F T 5 - Extension of security requirements CCEB-94/080 Page 16 of 28 Version 0.5 94/10/31 innovation of functional requirements as understanding increases. It does not allow for flexibility or extensibility of assurance requirements. 64 The FC, insofar as it is was an extension of the TCSEC, defined both functional and assurance requirements. However, the FC incorporated considerable flexibility in the ability to express functional requirements and to tailor them to specific needs. Like the CTCPEC, the FC placed only essential limits on the combination of functions and assurances. That is, the expression of requirements was constrained by nothing other than fundamental technical limitations. However, the FC provided no capability to express either functional or assurance requirements that were not already expressed in the document.; it took the position that the FC was the compendium of the accepted technology, and the incorporation of new functions or assurances into the FC were to be the outcome of the social process whereby new technology gets introduced into, and accepted by the technical community. 65 The decisions concerning the topics of flexibility and extensibility are captured in section B.6 of the Conceptual Framework (CCEB-93/035) and in paragraph 3 of the decision paper "Agreements made by the CCEB Principal Members, 8-9 June, 1994." 5.3 Discussion 5.3.1 New requirements vs. new mechanisms 66 Evaluating IT products or systems for security properties is somewhat different than evaluating them for compliance with most other standards. Most standards simply require that the IT in question have a minimal level of functions, while security standards require that the IT not have any noncompliant functions. Reaching such a conclusion requires that the required functions be well understood by the designers and the evaluators. This is necessary so that appropriate design and evaluation techniques can be developed that will accurately measure (and hopefully avoid) the likelihood of unexpected failure. 67 It is critical that the CC be based upon an approach that accommodates advances in the field of IT security & IT technology. Advances in these fields are of two types, new problems (which the CC addresses through requirements) and new technology or solutions to problems (which the CC refers to as functions and mechanisms). 68 We have agreed that the CC will attempt to be mechanism independent (largely due to the rate of change of technology) and that it is the responsibility of the evaluators and evaluation authority to establish appropriate procedures (as part of their scheme) for ensuring adequate understanding of the technology under evaluation. 69 The scope of this chapter is to discuss only how the CC should handle new requirements (i.e., security assurance components). D R A F T CCEB-94/080 5 - Extension of security requirements 94/10/31 Version 0.5 Page 17 of 28 5.3.2 Criteria change management 70 The TCSEC, ITSEC, and CTCPEC depend upon an ad hoc, aperiodic process to change the criteria over time. This prevents the users and developers from effectively predicting when and how new security concepts will be integrated into the widely accepted criteria. This unpredictability may discourage some from utilising these new concepts. 71 Once the CC has been turned over to ISO, a regular, well controlled process will be available to allow the CC to be updated as required. A well known, well managed process guarantees the users that the CC will be updated in predictable (albeit lengthy) manner. The time required for update and the consensus nature of the process however may discourage some from utilising these new concepts. 5.3.3 Limitations on introduction of new concepts 72 As it is not currently possible to write a criteria for dependency analysis for all possible security functional and assurance component levels, the CC will define evaluation criteria for dependency analysis of the known security functional and assurance components contained in Part 2 and Part 3 and an evaluation process for a less objective form of dependency analysis based upon consensus among the participants for all other component levels. 73 As it is not currently possible to write a criteria for suitability analysis for all possible security assurance component levels, the CC will define evaluation criteria for suitability analysis of the known security asurance component levels contained in Part 3 and an evaluation process for a less objective form of suitability analysis based upon consensus among the participants for all other component levels. 5.3.4 Limitations on applicability of assurance techniques 74 In order for the CC to admit a priori all new security assurance components, it must be shown that all possible assurance component levels will be applicable and meaningful for all functional component levels in Part 2. 75 While it may be the case that many new assurance component levels can be validly applied to the Part 2 functional component levels, the absence of evidence of the universal applicability of new assurance component levels requires that the CC explain the known limits and provide a method for the community to extend its knowledge to validate the applicability of new assurance component levels to the functional component levels of Part 2. 5.3.5 CC conformance 76 There is a need for the CC to support the previous and existing activities of the evaluation authorities. Further, for the CC to be successful it must provide a clearly defined and well understood vocabulary that allows unambiguous and effective communication of evaluation results. D R A F T 5 - Extension of security requirements CCEB-94/080 Page 18 of 28 Version 0.5 94/10/31 5.4 Technical approach 77 The CC will allow the use of any combination of assurance component levels from Part 3 in conjunction with a targetable assurance level from Part 3. The only limits placed upon combinations will be completion of a satisfactory dependency analysis and a satisfactory suitability analysis. 78 It is expected that in some cases it is possible to apply other assurance component levels to Part 2 functional component levels, however the CC will only promise valid applicability for the application of Part 3 component levels to Part 2 component levels. 79 The following questions must be answered for each assurance component level: a) Does the assurance component level counter the claimed threats? b) What other assurance component levels and/or functional component levels does this assurance component level depend upon to yield a complete and valid result? c) Is it possible to apply this assurance component level to implementations of the functional component levels? d) Does this assurance component level provide a meaningful measure of confidence in the correctness and effectiveness of the functional component levels' implementation? 80 For assurance component levels from Part 3 question a is answered by the threats documented in the assurance component level, question b is answered by the dependencies documented in the assurance component level, and questions c and d are guaranteed to be true with respect to the Part 2 functional component levels by the CC sponsors. 81 Since Part 3 cannot provide answers to the four questions either directly or indirectly for assurance component levels not in Part 3, PP and ST writers using assurance component levels not found in Part 3 will have to provide their own answers to these questions using the processes defined in Part 3 and by their evaluation authority. 82 The CC cannot and will not limit the activities of recognised evaluation authorities. It is the responsibility of each evaluation authority to establish rules and processes based upon the questions above, the "Construction rules" of Part 3, and the evaluation criteria and processes of Part 3 for handling CC evaluation of TOEs claiming compliance with assurance component levels not specified in the CC. 83 The final results of any CC evaluation that includes assurance component levels not included in Part 3 must clearly distinguish Part 3 based results from non-Part 3 based results and must clearly document how it answers the 4 questions above and how it complies with any further requirements on non-Part 3 assurance component level evaluation established by the evaluation authority. D R A F T CCEB-94/080 5 - Extension of security requirements 94/10/31 Version 0.5 Page 19 of 28 84 It will be the responsibility of the evaluation schemes and relevant mutual recognition agreements, not the CC, to establish a basis of exchange of results based upon non-Part 3 assurance component levels. It is expected that exchange of results based only upon assurance components from Part 3 will be easier than exchange of results not based upon assurance components from Part 3. 85 The sponsors of the CC (hopefully this will one day be ISO), must establish a procedure for adding new assurance component levels to Part 3 as the need requires and our understanding permits. It is expected that this procedure will be based upon the concepts presented in the "social process" paper, the "Construction rules" of Part 3, and the evaluation criteria of Part 3. 5.5 Application 86 The following terms will be used in the document to provide the needed vocabulary to allow unambiguous communication of evaluation results: 87 Conformant: something is conformant if it is based upon an appropriate subset of requirements from the subject standard plus an arbitrary set of requirements not drawn from the subject standard. 88 Strictly Conformant: something is strictly conformant if and only if it is based upon only an appropriate subset of requirements from the subject standard. 89 Conformant with Part 2: based upon at least one functional component level from Part 2 and optionally other functional component levels expressed in a form that meets the structure and rules of Part 2 (i.e., regions 2, 3, 5, 6, 8, and 9 in figure 5.1). 90 Strictly Conformant with Part 2: based upon only functional component levels from Part 2 (i.e., regions 3, 6, and 9 in figure 5.1). 91 Conformant with Part 3: based upon at least AL-1 from Part 3 and optionally other security assurance component levels expressed in a form that meets the structure and rules for assurance component levels of Part 3 (i.e., regions 1, 2, 3, 4, 5, and 6 in figure 5.1). 92 Strictly Conformant with Part 3: based only upon an assurance level and optionally other assurance component levels from Part 3 (i.e., regions 1, 2, and 3 in figure 5.1). 93 Conformant with CC: conformant with Part 2 and Part 3 (i.e., regions 2, 3, 5, and 6 in figure 5.1). D R A F T 5 - Extension of security requirements CCEB-94/080 Page 20 of 28 Version 0.5 94/10/31 94 Strictly Conformant with CC: strictly conformant with both Part 2 and Part 3 (i.e., region 3 in figure 5.1). Strictly /-------|-------|-------\ Conformant | 1 | . 2 . | X 3 X | with Part 3 | | . . . | X X X | |-------|-------|-------| XXX = Strictly Conformant Conformant | 4 | . 5 . | . 6 . | with CC with Part 3 | | . . . | . . . | |-------|-------|-------| ... = Conformant with CC No Statement | 7 | 8 | 9 | about Part 3 | | | | \-----------------------/ No Conformant Strictly Statement with Conformant about Part 2 with Part 2 Part 2 Figure 5.1 - Relationships between types of conformance D R A F T 24 CCEB-94/080 94/10/31 Version 0.5 Page 21 of 28 Chapter 6 Relationship of Protection Profiles to Security Targets 6.1 Introduction 95 Protection Profiles and Security Targets are used to convey similar types of information. However, the level of detail and the purpose of each document differs significantly. If the CC is to preserve both notions, their relationship must be clearly understood and documented. 96 Section B.5 of the Conceptual Framework documents the initial agreement. 6.2 Background 97 A Protection Profile is defined in the FC as an abstract specification of the security aspects of a needed IT product. It is product independent, describing a range of products that could meet this same need. Required protection functions and assurances are bound together in a Protection Profile, with a rationale describing the anticipated threats and intended method of use. The Protection Profile specifies requirements for the design, implementation, and use of IT products. 98 A Security Target is defined in the ITSEC as a specification of the security required of a TOE, used as a baseline for evaluation. The security will specify the security enforcing functions of the TOE. It will also specify the security objectives, the threats to those objectives, and any specific security mechanisms that will be employed. 6.3 Discussion 99 A Protection Profile is a common, uniform, and controlled approach for specifying security protection requirements for which IT security TOEs are needed. A Protection Profile is a specific combination of functional and assurance requirements to meet a particular need which is expressed by means of a rationale (or set of security objectives) describing the anticipated threats and expected use. A single Protection Profile may apply to many TOEs meeting the same set of security objectives. 100 Protection Profiles must be evaluated before they can be adopted. The Protection Profile must be evaluated to ensure that the functions provided are sufficient to counter the identified threats to the TOE (suitability analysis) and to ensure that all functions provided by the TOE are mutually supportive (binding analysis). D R A F T 6 - Relationship of Protection Profiles to Security Targets CCEB-94/080 Page 22 of 28 Version 0.5 94/10/31 101 The information found in the Protection Profile will also be found in the Security Target but the Security Target will be TOE specific. The Security Target may be an instantiation of a Protection Profile or may be developed in the absence of a Protection Profile. The Security Target is the specification of the security required of a TOE and is used as a baseline for evaluation. 102 The Security Target may (and where possible will) draw on the predefined security requirements expressed in the CC Protection Profiles, packages, and components. The suitability rationale already incorporated will be automatically included and will not need restatement in the Security Target but the binding between those elements must be addressed. 103 If the Security Target instantiates only a Protection Profile, then the Security Target will be considered as valid if it can be shown that the Security Target maps directly to the Protection Profile i.e., the Security Target must include all functions specified in the Protection Profile and must not contain any additional functions. Only the mapping between the Security Target and the Protection Profile and the refinement of the Protection Profile by the Security Target needs validation. 104 If the Security Target is not developed from a Protection Profile, then the Security Target must be evaluated before the TOE is evaluated. The evaluation of the Security Target will be similar to the evaluation of a Protection Profile in scope and effort. 105 If the Security Target includes additional functions to that specified in the Protection Profile, then the Security Target must be evaluated to ensure that any additional functions are sufficient to mitigate additional threats to the TOE (suitability analysis) and to ensure that any additional functions provided by the TOE are supportive of the original functions specified in the Protection Profile (binding analysis). 6.4 Technical approach 106 Protection Profiles and Security Targets will be supported in the CC. A Security Target may be derived from a Protection Profile or may be derived in the absence of a Protection Profile. Additional functions may be included in a Security Target derived from a Protection Profile. A Security Target which lacks any function defined in a Protection Profile will be considered as non- conformant to that Protection Profile. 6.5 Application 107 Part 1 discusses the purpose and the target audience for both Protection Profiles and Security Targets. Their relationship to each other as well as to the security evaluation model is discussed. D R A F T CCEB-94/080 6 - Relationship of Protection Profiles to Security Targets 94/10/31 Version 0.5 Page 23 of 28 108 Part 3 provides evaluation criteria for both Protection Profiles and Security Targets. Three cases are considered for Security Targets: a) The evaluation of Security Targets derived solely from Protection Profiles; b) The evaluation of Security Targets that augment the requirements specified in a Protection Profile; and c) The evaluation of Security Targets that are not derived from Protection Profiles. D R A F T 6 - Relationship of Protection Profiles to Security Targets CCEB-94/080 Page 24 of 28 Version 0.5 94/10/31 D R A F T 28 CCEB-94/080 94/10/31 Version 0.5 Page 25 of 28 Chapter 7 The reference monitor and the TCB 7.1 Introduction 109 The issue addressed in this paper is the relevance of the notion of the reference monitor concept and the related notion of a Trusted Computing Base (TCB) to the CC, and how these concepts are incorporated into the CC. 7.2 Background 110 The notion of the reference monitor is well-established as the fundamental architectural principle for assuring that computer systems have the behaviour and properties desired. The notion of the TCB as the realisation of the reference monitor concept in hardware and software was originally defined in the TCSEC, and is a well-established notion in the community. 7.3 Discussion 7.3.1 The reference monitor concept 111 The essence of this work is to define an architectural approach to the security relevant elements of a system, without regard to the specific security features that may be implemented. It recognises the fundamental point that supportable arguments concerning system security attributes and behaviour stem from the hardware and software architectures, and from the engineering disciplines applied to the development of the product. 112 The reference monitor concept formalises these points by demanding that the security-relevant elements of the system (i.e., both hardware and software) be identifiable, and that they demonstrate specific properties. Specifically, it required that the security-relevant portion of the system exhibit the following properties: a) It is always invoked. That is, that it is possible to demonstrate that the refence monitor is invoked whenever a resource is referenced. In effect, this means that no resource may be accessed by processes except by making a request of the reference monitor (which is responsible for the enforcement of the desired policy). This property is usually demonstrated from the software architecture of the system; demonstrating that the reference monitor "owns" all the resources of the system, which are, therefore, only accessible via requests made through well-defined system calls. b) It is tamper-resistant. That is, it must be possible to demonstrate that no action by any process outside the reference monitor boundary can interfere D R A F T 7 - The reference monitor and the TCB CCEB-94/080 Page 26 of 28 Version 0.5 94/10/31 with it. In practice, this means that no untrusted code should be able to access, and especially tamper with, the internal code or data structures of the security-relevant elements of the system (i.e., the implementation of the reference monitor concept: the TCB). This property is normally argued from the hardware architecture, and in general it is required that the system support separate domains of execution (preferably in hardware), and that the TCB executes in a domain of its own. c) It is amenable to evaluation. In practice, this means that the implementation is at least conceptually simple. Furthermore, the level of confidence (i.e., assurance) derivable that the implementation functions correctly is a direct consequence of the complexity of the implementation. 113 The first two properties are essential. Without the ability to demonstrate that the security mechanisms are both unbypassable and tamper- resistant, no supportable conclusions can be reached about the security provided. Thus, the last property (i.e., analysability) is the aspect that tends to be the determinant of the assurance attainable. Assurance is primarily a measure of the confidence of the correct implementation of the specifications. This is a direct function of the ease or difficulty encountered in attempting to follow the high-level design through the various design decompositions to the final implementation in hardware and software. 7.3.2 The Trusted Computing Base 114 The TCB is defined in the TCSEC as, "the totality of protection mechanisms within a computer system, including hardware, firmware, and software, the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified (technical) security policy over a product or system. The ability of a TCB to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by administrative personnel of parameters (e.g., a user's clearance) related to the security policy." 115 The ITSEC makes the distinction between security-enforcing entities (i.e., those which directly implement a defined rules-set, or "policy") and the security-relevant entities (i.e., those that must work correctly if the TCB is to be judged to work correctly). Although no explicit distinctions of this sort are made in the TCSEC, FC, or CTCPEC, the distinctions have been recognised in practice (although without the implications regarding evaluation requirements, as in the ITSEC). 116 The notion of the TCB (and the more primitive notion of the reference monitor) are extensions of the tradition "security perimeter." Thus, the design and architecture of the system, in particular the hardware and interface description of the TCB, must demonstrate that no entity outside the TCB (i.e., untrusted processes) can interfere with the enforcement of the policy. Therefore, identification of the elements of the TCB defines the limit of what must be evaluated in order to reach supportable conclusions about the attributes and behaviour of the system. That is, if no non-TCB entities can impact the security behaviour of the system, then only the properties and correctness of the TCB are of issue. D R A F T CCEB-94/080 7 - The reference monitor and the TCB 94/10/31 Version 0.5 Page 27 of 28 117 What will be required of the developer of a product is to demonstrate that the TCB is a valid implementation of the reference monitor concept. In detail this requires the developer to: a) Demonstrate that the TCB is self-protecting; that it executes in a domain of its own such that no non-TCB process may tamper with either the internal code or data structures of the TCB. b) Demonstrate that the enforcement of the policy is continuous and complete; that each and every reference to resources is mediated in accordance with the policy and that the policy is applied to all sharable resources exported by the TCB. This further requires the developer to identify all the resources that can be shared between non-TCB processes. c) Provide evidence that allows at least some judgment to be made concerning the consistency of the implementation with the specifications. Although the depth and formality of the evidence may vary with the level of assurance desired, the evidence must be complete: it must allow the evaluator to assess the correctness of the implementation with respect to the specifications. 118 In summary, the reference monitor concept provides the minimum essential aspects of the system that must be demonstrable in order that valid and supportable conclusions about the security of the system may be reached. In particular, all security-enforcing components must be identifiable and identified, the security enforcing functions must be invoked on each and every reference, the security enforcing functions must be self-protecting, and the implementation must be amenable to test and analysis. The TCB is the instantiation of the reference monitor concept in hardware and software. It may have considerable structural complexity, but it must exhibit the properties defined for a reference monitor. The degree to which the implementation supports or inhibits analysis and evaluation is a direct determinant of the level of assurance that can be attained for the system. 7.4 Technical approach 119 The CC will include the reference monitor concept and contain explicit reference to the applicable literature base (e.g., the "Anderson Report"). Additionally, the CC will include the notion of the Trusted Computing Base (TCB) as the focus of security design, analysis, and evaluation. Specifically, this means that it must be possible to express requirements that capture these essential notions. The CC will provide the flexibility to articulate requirements for entities that are less than an entire TCB, and thus it must be possible to evaluate the behaviour and attributes of products that do not, on their own, implement the reference monitor concept. However, the notions of reference monitor and TCB must be expressible when appropriate and when required. 7.5 Application D R A F T 7 - The reference monitor and the TCB CCEB-94/080 Page 28 of 28 Version 0.5 94/10/31