IWS - The Information Warfare Site
News Watch Make a donation to IWS - The Information Warfare Site Use it for navigation in case java scripts are disabled


Information Technology Security Evaluation Criteria ( ITSEC )

Harmonised Criteria of France - Germany - the Netherlands - the United Kingdom

Following extensive international review version 1.2 of the ITSEC is issued, with the approval of the (informal) EC advisory group, SOG-IS (Senior Officials Group - Information Systems Security), for operational use within evaluation and certification schemes, for a provisional period of two years from the date of issue. The practical experience acquired will be used to review and further develop the ITSEC at the end of this period. In addition, considerations arising from further international harmonisation will also be taken into account.

Printed and published by the Department of Trade and Industry, London, June 1991

Controller, HMSO 1991.

CONTENTS

 

  1. SCOPE
    • 1.1 Technical Security Measures
    • 1.4 Systems and Products
    • 1.9 Functionality and Assurance, Classes and Levels
    • 1.21 Assurance Profiles
    • 1.23 The Evaluation Process
    • 1.31 The Certification Process
    • 1.35 Relationship to the TCSEC
  2. FUNCTIONALITY
    • 2.1 Introduction
    • 2.3 The Security Target
    • 2.31 Generic Headings
    • 2.59 Predefined Classes
    • 2.65 Specification Style
    • 2.81 Formal Models of Security Policy
  3. ASSURANCE - EFFECTIVENESS
    • 3.1 Introduction
    • 3.2 Description of the Approach
    • 3.11 Systems and Products
    • 3.12 Effectiveness Criteria - Construction
    • 3.13 Aspect 1 - Suitability of Functionality
    • 3.17 Aspect 2 - Binding of Functionality
    • 3.21 Aspect 3 - Strength of Mechanisms
    • 3.25 Aspect 4 - Construction Vulnerability Assessment
    • 3.29 Effectiveness Criteria - Operation
    • 3.30 Aspect 1 - Ease of Use
    • 3.34 Aspect 2 - Operational Vulnerability Assessment
  4. ASSURANCE - CORRECTNESS
  5. RESULTS OF EVALUATION
    • 5.1 Introduction
    • 5.2 Rating
  6. GLOSSARY AND REFERENCES
    • 6.1 Introduction
    • 6.2 Definitions
    • 6.78 References

Annex A - EXAMPLE FUNCTIONALITY CLASSES

Annex B - THE CLAIMS LANGUAGE

FIGURES (missing)

  • Fig. 1 IT System
  • Fig. 2 IT Product
  • Fig. 3 Development and Evaluation Process
  • Fig. 4 Information used in a Vulnerability Analysis

0.INTRODUCTION

 

0.1 In the course of only four decades, Information Technology (IT) has come to play an important, and often vital, role in almost all sectors of organised societies. As a consequence, security has become an essential aspect of Information Technology.

0.2 In this context, IT security means,

  • confidentiality - prevention of the unauthorised disclosure of information;
  • integrity - prevention of the unauthorised modification of information;
  • availability - prevention of the unauthorised withholding of information or resources.

0.3 An IT system or product will have its own requirements for maintenance of confidentiality, integrity and availability. In order to meet these requirements it will implement a number of technical security measures, in this document referred to as security enforcing functions, covering, for example, areas such as access control, auditing, and error recovery. Appropriate confidence in these functions will be needed: in this document this is referred to as assurance, whether it is confidence in the correctness of the security enforcing functions (both from the development and the operational points of view) or confidence in the effectiveness of those functions.

0.4 Users of systems need confidence in the security of the system they are using. They also need a yardstick to compare the security capabilities of IT products they are thinking of purchasing. Although users could rely upon the word of the manufacturers or vendors of the systems and products in question, or they could test them themselves, it is likely that many users will prefer to rely on the results of some form of impartial assessment by an independent body. Such an evaluation of a system or product requires objective and well-defined security evaluation criteria and the existence of a certification body that can confirm that the evaluation has been properly conducted. System security targets will be specific to the particular needs of the users of the system in question, whereas product security targets will be more general so that products that meet them can be incorporated into many systems with similar but not necessarily identical security requirements.

0.5 For a system, an evaluation of its security capabilities can be viewed as a part of a more formal procedure for accepting an IT system for use within a particular environment. Accreditation is the term often used to describe this procedure. It requires a number of factors to be considered before a system can be viewed as fit for its intended purpose: it requires assurance in the security provided by the system, a confirmation of management responsibilities for security, compliance with relevant technical and legal/regulatory requirements, and confidence in the adequacy of other non-technical security measures provided in the system environment. The criteria contained in this document are primarily concerned with technical security measures, but they do address some non- technical aspects, such as secure operating procedures for personnel, physical and procedural security (but only where these impinge on the technical security measures).

0.6 Much work has been done previously on the development of IT security evaluation criteria, although for slightly different objectives according to the specific requirements of the countries or bodies involved. Most important of these, and a precursor to other developments in many respects, was the Trusted Computer System Evaluation Criteria [TCSEC], commonly known as the TCSEC or "Orange Book", published and used for product evaluation by the US Department of Defense. Other countries, mostly European, also have significant experience in IT security evaluation and have developed their own IT security criteria. In the UK this includes CESG Memorandum Number 3 [CESG3], developed for government use, and proposals of the Department of Trade and Industry, the "Green Book" [DTIEC], for commercial IT security products. In Germany, the German Information Security Agency published a first version of its own criteria in 1989 [ZSIEC], and at the same time criteria were being developed in France, the so- called "Blue-White-Red Book" [SCSSI].

0.7 Seeing that work was going on in this area, and much still needed to be done, France, Germany, the Netherlands and the United Kingdom recognised that this work needed to be approached in a concerted way, and that common, harmonised IT security criteria should be put forward. There were three reasons for harmonisation:

  • much experience had been accumulated in the various countries, and there would be much to gain by jointly building on that experience;
  • industry did not want different security criteria in the different countries;
  • the basic concepts and approaches were the same, across countries and even across commercial, government and defence applications.

0.8 It was therefore decided to build on the various national initiatives, taking the best features of what had already been done and putting them in a consistent, structured perspective. Maximum applicability and compatibility with existing work, most notably the US TCSEC, was a constant consideration in this process. Though it was initially felt that the work would be limited to harmonisation of existing criteria, it has sometimes been necessary to extend what already existed.

0.9 One reason for producing these internationally harmonised criteria is to provide a compatible basis for certification by the national certification bodies within the four co- operating countries, with an eventual objective of permitting international mutual recognition of evaluation results.

0.10 This document sets out the harmonised criteria. Chapter 1 contains a short presentation of the scope of the harmonised criteria. Chapter 2 deals with security functionality, that is the definition and description of security requirements. Chapter 3 defines criteria for evaluating assurance in the effectiveness of a Target of Evaluation as a solution to those requirements. Chapter 4 extends this to consideration of the correctness of the solution. Chapter 5 describes the permitted results of an evaluation, and Chapter 6 contains a glossary of those terms that take a more precise or different meaning in the book than in normal English (on first use they are printed in bold: whereas italics are used for emphasis). The glossary is intended to help the reader not only with the definition of words, but also with ideas and concepts that are special to the harmonised criteria.

0.11 The evaluation criteria in Chapters 3 and 4 are set out in a standardised way, which specifies what must be provided by the sponsor of the evaluation (the person or organisation requesting evaluation) and what must be done by the evaluator (the independent person or organisation performing evaluation). This categorisation is intended to assist in ensuring the consistency and uniformity of evaluation results. For each area of evaluation, documentation that must be provided by the sponsor of the evaluation is identified. This is then followed by the criteria for each relevant aspect or phase of evaluation of that area. These criteria are broken down into requirements for content and presentation of the relevant documentation that must be provided by the sponsor, requirements for evidence concerning what that documentation must show, and the evaluator actions required to be performed by the evaluator both to check the documentation provided and where necessary to perform additional tests or other activities. In the case of criteria concerning how the system or product is to be used operationally, the sponsor will not, in general, be able to provide evidence from actual use. Thus the evaluator must assume for the purposes of evaluation that the procedures specified by the sponsor will be followed in practice.

0.12 Within the criteria certain verbs are also used in a special way. Shall is used to express criteria which must be satisfied; may is used to express criteria which are not mandatory; and will is used to express actions to take place in the future. Similarly, the verbs state, describe and explain are used within criteria to require the provision of evidence of increasing levels of rigour. State means that relevant facts must be provided; describe means that the facts must be provided and their relevant characteristics enumerated; explain means that the facts must be provided, their relevant characteristics enumerated and justifications given.

0.13 Other than within Chapter 4, paragraphs are numbered sequentially within each chapter. In Chapter 4, criteria are set out separately for each evaluation level. The introductory paragraphs of that chapter are numbered as in other chapters, but then the criteria paragraphs are numbered sequentially for each level, with the same paragraph number covering the same topic at each level. However, each paragraph within the document is uniquely identified by the combination of chapter or level number and paragraph number.

0.14 This work draws from documents that have already been extensively discussed and used in practice; moreover, it is felt that the ideas and concepts have been carefully balanced and that the structure chosen for the ITSEC is the right one for maximum consistency and ease of use. The current version of the ITSEC benefits from significant revisions arising from widespread international review. The review process has been assisted by the Commission for the European Communities who organised an international conference at which version 1.0 was discussed, and a subsequent workshop at which an interim revision, version 1.1, was further refined. These events were supplemented by written comments from reviewers, which the authors have sought to take into account in preparing version 1.2.

0.15 It is therefore expected that these criteria will receive broad acceptance and use by a wide range of potential users and market sectors; however, it is recognised that improvements can and will be made. Comments and suggestions are therefore invited, and may be sent to any of the following addresses, bearing the marking "ITSEC Comments":

Commission of the European Communities Directorate XIII/F SOG-IS Secretariat Rue de la Loi 200 B-1049 BRUSSELS Belgium

Or, for France:

Service Central de la Scurit des Syst mes d'Information Division Information et Syst mes 18 Rue du Docteur Zamenhof F-92131 ISSY LES MOULINEAUX

For Germany:

Bundesamt fr Sicherheit in der Informationstechnik Am Nippenkreuz 19 D-5300 BONN 2

For the Netherlands:

Netherlands National Comsec Agency Bezuidenhoutseweg 67 P.O. Box 20061 NL-2500 EB THE HAGUE

For the United Kingdom:

Head of the Certification Body UK IT Security Evaluation and Certification Scheme Room 2/0805 Fiddlers Green Lane CHELTENHAM Glos GB-GL52 5AJ

0.16 Copies of the Community publication of ITSEC version 1.2 may be obtained from the Commission of the European Communities at the above address.

1 SCOPE

 

Technical Security Measures

1.1 A major part of the security of an IT system can often be achieved through non-technical measures, such as organisational, personnel, physical, and administrative controls. However, there is a growing tendency and need to employ technical IT security measures. Although the security criteria which follow are primarily concerned with technical security measures, they do address some non- technical aspects, most notably the related secure operating procedures for personnel, physical and procedural security of the systems or products involved (but only where these impinge on the technical security measures).

1.2 These criteria have been designed so as in the main part to be equally applicable to technical security measures implemented in hardware, software and firmware. Where particular aspects of evaluation are intended only to apply to certain methods of implementation, this is indicated as part of the relevant criteria.

1.3 These criteria are not intended to cover physical aspects of hardware security such as the provision of tamper resistant enclosures or the control of electromagnetic emanations.

Systems and Products

1.4 For the purposes of this document, the difference between systems and products can be explained as follows. An IT system is a specific IT installation with a particular purpose and known operational environment. An IT product is a hardware and/or software package that can be bought off the shelf and incorporated into a variety of systems. An IT system is generally constructed from a number of hardware and software components. Some components (for example, application software) will usually be specially constructed; other components (for example, hardware) will usually be standard products. For certain applications it may be possible to buy-in a single product to serve as a complete system, but usually at least some customisation and integration to meet system specific requirements will be necessary.

1.5 From the point of view of security, the main difference between systems and products lies in what is certain about their operational environment. A system is designed to meet the requirements of a specific group of end-users. It has a real world environment which can be defined and observed in every detail; in particular the characteristics and requirements of its end-users will be known, and the threats to its security are real threats which can be determined. A product must be suitable for incorporation in many systems; the product designer can only make general assumptions about the operational environment of a system of which it may become a component. It is up to the person buying the product and constructing the system to make sure that these assumptions are consistent with the actual environment of the system.

1.6 It is important for the sake of consistency that the same security criteria are used for both products and systems; it will then be both easier and cheaper to evaluate systems containing products which have already been successfully evaluated. This is why these criteria deal with the security evaluation of both IT products and IT systems. Within the rest of this document, the term Target of Evaluation (TOE) is used to refer to a product or system to be evaluated.

1.7 A TOE can be constructed from several components. Some components will not contribute to satisfying the security objectives of the TOE. Other components will contribute to satisfying the security objectives; these components are called security enforcing. Finally there may be some components that are not security enforcing but must nonetheless operate correctly for the TOE to enforce security; these are called security relevant. The combination of both the security enforcing components and the security relevant components of a TOE is often referred to as a Trusted Computing Base (TCB) (see figures 1 and 2).

1.8 Most evaluation work will concentrate on the components of the TOE that are stated to be security enforcing and security relevant, but all other components within the TOE will need to be considered during evaluation and shown to be neither security enforcing nor security relevant.

Functionality and Assurance, Classes and Levels

1.9 In order for a TOE to meet its security objectives, it must incorporate appropriate security enforcing functions, covering, for example, areas such as access control, auditing and error recovery.

1.10 These functions must be defined in a way that is clear and understandable to both the sponsor of evaluation and the independent evaluator. They may either be individually specified, or they may be defined by reference to a predefined functionality class. These criteria include ten example functionality classes. These example classes are based upon classes defined in the German National Criteria [ZSIEC], including five classes that correspond closely to the functionality requirements of the US Trusted Computer System Evaluation Criteria [TCSEC].

1.11 In all cases, the sponsor of an evaluation must define the security target for the evaluation. This must define the security enforcing functions to be provided by the TOE, and will also contain other relevant information, such as the security objectives of the TOE and the envisaged threats to those objectives. Details may also be given of the particular security mechanisms that will be used to implement the security enforcing functions.

1.12 The security enforcing functions selected to satisfy the security objectives of a TOE form but one aspect of the security target of a product or system. No less important is assurance that the security objectives are achieved by the selected security enforcing functions and mechanisms.

1.13 Assurance needs to be addressed from several different points of view and, in these harmonised criteria, it has been decided to distinguish confidence in the correctness in the implementation of the security enforcing functions and mechanisms from confidence in their effectiveness.

1.14 Evaluation of effectiveness assesses whether the security enforcing functions and mechanisms that are provided in the TOE will actually satisfy the stated security objectives. The TOE is assessed for suitability of functionality, binding of functionality (whether the chosen functions work together synergistically), the consequences of known and discovered vulnerabilities (both in the construction of the TOE and the way it will be used in live operation), and ease of use.

1.15 In addition, evaluation of effectiveness assesses the ability of the security mechanisms of the TOE to withstand direct attack (strength of mechanisms). Three strength levels are defined - basic, medium, and high - which represent ascending levels of confidence in the ability of the security mechanisms of the TOE to withstand direct attack.

1.16 Evaluation of correctness assesses whether the security enforcing functions and mechanisms are implemented correctly. Seven evaluation levels labelled E0 to E6 have been defined, representing ascending levels of confidence in correctness. E0 represents inadequate confidence. E1 represents an entry point below which no useful confidence can be held, and E6 represents the highest level of confidence. The remaining levels represent an interpolation in between. Correctness is addressed from the point of view of construction of the TOE, covering both the development process and the development environment, and also the point of view of operation of the TOE.

1.17 The evaluation levels are defined within the context of the correctness criteria. The requirements for effectiveness (including strength of mechanisms) do not change by level, but rather build upon the correctness assessment and are performed using the documents provided by the sponsor for that assessment; of course, in practice the correctness and effectiveness assessment activities will be interleaved.

1.18 If a TOE fails any aspect of evaluation at a particular level, because of a lack of information or for any other reason, the deficiency must be remedied, or the TOE withdrawn from evaluation at that level. Otherwise the TOE will be assigned a result of E0.

1.19 The six successful evaluation levels E1 to E6 span a wide range of potential confidence. Not all of these levels will necessarily be needed by or appropriate for all market sectors that require independent evaluation of technical security measures. Not all combinations of functionality and confidence will necessarily be sensible or useful. For example, low confidence in the functionality required to support a military multilevel security requirement will not normally be appropriate. In addition, it is unlikely that high confidence in the correctness of a TOE will be combined with a requirement for a low strength of mechanisms.

1.20 These harmonised criteria are not a design guide for secure products or systems. It is up to the sponsor of an evaluation to determine the security objectives of his TOE and to choose security functions to satisfy them. However for each evaluation level, the assurance part of the criteria can be thought of as a compulsory "security checklist" to be satisfied.

Assurance Profiles

1.21 The criteria in this document require the sponsor to state the evaluation level as part of the security target. All of the security enforcing functions listed in the security target are then assessed to the same level of confidence, as required by the stated evaluation level.

1.22 For some TOEs, there may be a requirement to gain higher confidence in some security functions and lower confidence in others; for example, some security functions may be more important than others. In these circumstances, the sponsor may consider producing more than one security target for the TOE. The details of how this is achieved, and under what conditions, is beyond the scope of these criteria.

The Evaluation Process

1.23 The objective of the evaluation process is to enable the evaluator to prepare an impartial report stating whether or not a TOE satisfies its security target at the level of confidence indicated by the stated evaluation level.

1.24 The evaluation process is shown in context within figure 3.

It requires the close involvement of the sponsor of the evaluation. The higher the evaluation level, the greater will need to be the involvement of the sponsor. Both users and vendors can act as sponsors for evaluation. It is likely that a system evaluation will be sponsored by the intended end-users of the system or their technical representatives, and that a product evaluation will be sponsored by the product manufacturer or a vendor of the product, but this need not be so. Any party that can supply the necessary technical information may sponsor an evaluation.

1.25 First the sponsor must determine the operational requirements and the threats the TOE is to counter. In the case of a system, there is a need to examine the real world operational environment for the system, in order to determine the relevant threats that must be addressed. For a product, there is a need to decide what threats to security the product should address. It is anticipated that industry organisations and international standardisation bodies will with time define standard functionality classes for use as product security targets. Product developers who have no predetermined specialist market niche or type of user in mind may find that such predefined functionality classes make good security targets to design their products to match.

1.26 The security objectives for the TOE can then be determined considering legal and other regulations. These form the contribution to security (confidentiality, integrity and availability) the TOE is intended to provide. Given the security objectives, the necessary security enforcing functions can then be established, possibly in an iterative way, together with the evaluation level that the TOE will have to achieve to provide the necessary level of confidence.

1.27 The results of this work - the definition of the security enforcing functions, the identified threats, the identified security objectives, any specific security mechanisms to be employed - becomes the security target for the development.

1.28 For each evaluation level, the criteria enumerate items to be delivered by the sponsor to the evaluator. The sponsor must ensure that these items are provided, taking care that any requirements for content and presentation are satisfied, and that the items clearly provide, or support the production of, the evidence that is called for.

1.29 In order that evaluation can be performed efficiently, and at minimum cost, the evaluator must work closely with the developer and sponsor of the TOE, ideally from the beginning of development, to build up a good understanding of the security target, and to be able to pinpoint the evaluation implications of decisions as they are made. However, the evaluator must remain independent and must not suggest how to design or implement the TOE. This is analogous to the role of an external financial auditor, who must likewise build up a good working relationship with a financial department, and in many cases will, after examination, make use of their internal records and controls. However, he too must remain independent and questioning.

1.30 Security test and analysis requirements within the criteria deserve special mention; in all cases the responsibility for testing and analysis will rest with the sponsor. For all evaluation levels except E1, the evaluator will primarily check test and analysis results supplied by the sponsor. The evaluator will perform test and analysis work only to audit the results supplied, to supplement the evidence provided, and to investigate vulnerabilities. At evaluation level E1 it is optional as to whether testing results are provided. If not, the evaluator must in addition perform functional testing against the security target.

The Certification Process

1.31 In order for these criteria to be of practical value, they will need to be supported by practical schemes for the provision and control of independent evaluation, run by appropriately qualified and recognised national certification bodies. These bodies will award certificates to confirm the rating of the security of TOEs, as determined by properly conducted independent evaluations. They will approve procedures, as required by these criteria, for guaranteeing the authenticity of the delivered TOE. They will also be responsible for the selection and control of approved evaluators. Details of the procedures to be used by such bodies are beyond the scope of these criteria.

1.32 These criteria have been designed to minimise the subjectivity inherent in evaluation results. It will be the responsibility of national certification bodies to maintain the uniformity of certified evaluation results. How this is achieved is beyond the scope of these criteria.

1.33 In order for the results of an evaluation against these criteria to be certified by a national certification body, the evaluator will have to produce a report containing the results of evaluation in a form acceptable for consideration by the certification body. The precise format and content of such reports are beyond the scope of these criteria. 1.34 Most security targets and TOEs will change with time. The maintenance of a certified rating following changes to a TOE (whether security-related or not) or following changes to the security target (such as new threats or security objectives) will be regulated by the appropriate national certification body. Re-evaluation will be necessary in some circumstances and not others. The details of such regulations and procedures are also a matter beyond the scope of these criteria.

Relationship to the TCSEC

1.35 The Trusted Computer System Evaluation Criteria [TCSEC], commonly known as the TCSEC or "Orange Book", is a widely known and accepted basis for the security evaluation of operating systems. Originally published in 1983, it is used by the US Department of Defense in the US product evaluation scheme operated by the National Computer Security Center (NCSC). The TCSEC criteria are intended to match the security policy of the US Department of Defense. This policy is primarily concerned with maintaining the confidentiality of nationally classified information.

1.36 The TCSEC defines seven sets of evaluation criteria called classes (D, C1, C2, B1, B2, B3 and A1), grouped into four divisions (D, C, B and A). Each criteria class covers four aspects of evaluation: Security Policy, Accountability, Assurance and Documentation. The criteria for these four areas become more detailed from class to class, and form a hierarchy whereby D is the lowest and A1 the highest. Each class covers both functionality and confidence requirements.

1.37 The criteria set out in the ITSEC permit selection of arbitrary security functions, and define seven evaluation levels representing increasing confidence in the ability of a TOE to meet its security target. Thus these criteria can be applied to cover a wider range of possible systems and products than the TCSEC. In general, for identical functionality at an equivalent level of confidence, a TOE has more architectural freedom to meet the ITSEC criteria than to meet the TCSEC, but is more constrained in its permissible development practices.

1.38 A number of example functionality classes have been defined to correspond closely to the functionality requirements of the TCSEC classes C1 to A1. They are included, as F-C1 to F-B3, amongst the example functionality classes given in Annex A. It is not possible, however, to relate the evaluation levels directly to the confidentiality requirements of the TCSEC classes, as the ITSEC levels have been developed by harmonisation of various European IT security criteria schemes which contain a number of requirements which do not appear in the TCSEC explicitly. 1.39 The intended correspondence between these criteria and the TCSEC classes is as follows: 





   These Criteria        TCSEC Class








        E0        <--->       D








        F-C1, E1  <--->       C1








        F-C2, E2  <--->       C2








        F-B1, E3  <--->       B1








        F-B2, E4  <--->       B2








        F-B3, E5  <--->       B3








        F-B3, E6  <--->       A1

1.40 It should be noted that there is no functionality class F- A1 as the functionality requirements of TCSEC class A1 are the same as for class B3. A product which has been designed with the objective of successful evaluation against both the ITSEC and TCSEC, and which has been shown to meet one of the classes or combinations in the table above, should pass evaluation against the other criteria at the equivalent class or combination. However, at C1 the TCSEC requires evidence to be provided of system developer testing. Thus an [F-C1, E1] evaluation would only be equivalent to C1 evaluation if the sponsor had chosen to satisfy the optional E1 requirement to provide test documentation as evidence of adequate testing against the security target prior to evaluation.

1.41 Throughout the TCSEC, the combination of both the security enforcing and the security relevant portions of a TOE is referred to as a Trusted Computing Base (TCB). TCSEC TOEs representative of the higher classes in division B and division A derive additional confidence from increasingly rigorous architectural and design requirements placed on the TCB by the TCSEC criteria. TCSEC classes B2 and higher require that access control is implemented by a reference validation mechanism, a mechanism which implements the concept of a reference monitor [AND]. Such a reference validation mechanism must be tamper proof, it must always be invoked, and it must be small enough to be subject to analysis and tests, the completeness of which can be assured.

1.42 For compatibility with the TCSEC, the ITSEC example functionality classes F-B2 and F-B3 mandate that access control is implemented through use of such a mechanism. In addition, at higher evaluation levels the ITSEC places architectural and design constraints on the implementation of all the security enforcing functions. Combined with the ITSEC effectiveness requirements that security functionality is suitable and mutually supportive, this means that a TOE capable of meeting the higher ITSEC evaluation levels and which provides functionality matching these TCSEC-equivalent functionality classes, must necessarily satisfy the TCSEC requirements for a TCB and use of the reference monitor concept.

Fig. 1 IT System

Fig. 2 IT Product

Fig. 3 Development and Evaluation Process

2.FUNCTIONALITY

 

Introduction

2.1 A Target of Evaluation (TOE) which provides security (some combination of confidentiality, integrity and availability) must contain appropriate security features. Normally, it will be necessary to determine that an appropriate level of confidence can be held in those features. In order for this to be done, the features themselves must be specified. The document or documents which specify the features, together with the desired evaluation level, make up the security target for the TOE.

2.2 In these criteria, security features are viewed at three levels. The most abstract view is of security objectives: the contribution to security which a TOE is intended to achieve. To achieve these objectives, the TOE must contain certain security enforcing functions. These security enforcing functions, in turn, must be implemented by specific security mechanisms. These three levels can be summarised as follows:

  1. Security Objectives - Why the functionality is wanted.

  2. Security Enforcing Functions - What functionality is actually provided.

  3. Security Mechanisms - How the functionality is provided.

The Security Target

2.3 The security target serves as both a specification of the security enforcing functions, against which the TOE will be evaluated, and as a description relating the TOE to the environment in which it will operate. The audience for the security target is therefore not confined solely 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.

2.4 The required contents of a security target can be summarised as follows:

  1. Either a System Security Policy or a Product Rationale.

  2. A specification of the required security enforcing functions.

  3. A definition of required security mechanisms (optional).

  4. The claimed rating of the minimum strength of mechanisms.

  5. The target evaluation level.

    Each of these is described in greater detail below.

2.5 The requirements for the presentation of the security target depend on the target evaluation level. The evaluation level also determines other TOE documentation that must be supplied for evaluation, together with requirements on its content and presentation, and requirements for the evidence to be provided to show that the TOE satisfies the security target.

2.6 The security target may be presented as a single document, or as multiple documents. Where multiple documents are used, their relationships to one another shall be clearly indicated.

2.7 The sponsor of an evaluation is responsible for the provision and accuracy of the security target for the evaluation.

System Security Policy

2.8 The contents of a security target depend on whether the TOE is a system or product. In the case of a system, the actual environment within which the TOE will be used is known, its actual security objectives can be determined and actual threats and existing countermeasures can be considered. These details are given in a System Security Policy.

2.9 The System Security Policy specifies the set of laws, rules and practices that regulate how sensitive information and other resources are managed, protected and distributed within a specific system. It shall identify the security objectives of the system and the threats to the system. These security objectives shall be addressed by a combination of system security enforcing functions (implemented within the TOE), and also by physical, personnel, or procedural means associated with the system. The System Security Policy shall cover all aspects of security relating to the system, including these associated physical, procedural and personnel security measures.

2.10 All organisations will have general security standards that apply to all systems within the organisation and define the security relationship between the organisation and the outside world. These standards can be considered to be a Corporate Security Policy: the set of laws, rules and practices that regulate how assets, including sensitive information, are managed, protected and distributed within the organisation. Many organisations will have an explicit written Corporate Security Policy, which will specify the rules and practices and applicable national and international laws to which they conform. Where this is the case, it shall be referenced from the System Security Policy. Otherwise, all relevant aspects shall be stated within each System Security Policy of the organisation.

2.11 The primary responsibility of the Corporate Security Policy is to provide the context for the identification of system security objectives. Identifying relevant corporate assets, general threats, and the results from risk analysis will assist in the identification of these system security objectives. Discussion of the process of risk analysis is outside the scope of these criteria.

2.12 In the context of an individual system, the System Security Policy shall define the security measures to be used to satisfy the system security objectives in a way which is consistent with the Corporate Security Policy. The security measures required by the System Security Policy will be implemented by a combination of security enforcing functions implemented by the TOE, and by physical, personnel, and procedural means. The System Security Policy shall clearly indicate the division of responsibility between the security enforcing functions and the other means.

2.13 The IT security measures of a System Security Policy may be separated from the remainder of the System Security Policy, and defined in a separate document: a Technical Security Policy. This is the set of laws, rules and practices regulating the processing of sensitive information and the use of resources by the hardware and software of an IT system.

2.14 In many cases it may be convenient to include the specification of security enforcing functions as part of the System or Technical Security Policy.

2.15 The System or Technical Security Policy may be used as a basis for selecting suitable IT security products for incorporation within the system; such product selection is outside the scope of these criteria.

Product Rationale

2.16 In the case of a product, the precise environment within which the TOE will be used is not known to its developer, since it may be incorporated into more than one specific system and system environment. Instead, a rationale statement shall be provided giving the necessary information for a prospective purchaser to decide whether it will help to satisfy his system security objectives, and to define what else must be done for those system security objectives to be fully met.

2.17 The product rationale shall identify the intended method of use for the product, the intended environment for use of the product and the assumed threats within that environment. It shall include a summary of the product's security features, and define all assumptions about the environment and way in which the product will be used. This shall include personnel, physical, procedural and IT security measures required to support the product, and its dependencies on system hardware, software, and/or firmware not supplied as part of the product.

Specification of Security Enforcing Functions

2.18 The security target shall include a specification of the security enforcing functions to be provided by the TOE. These functions may be stated explicitly, or by reference to one or more predefined functionality classes, or by reference to an accepted standard that defines security functionality. Predefined classes are considered later in this chapter.

2.19 One or more standards documents which address security may form part of a security target, by reference or by inclusion within the target. Where the standard allows options, the selected ones shall be clearly identified. Where a standard does not provide all the information required, the necessary supplementary information shall be provided explicitly within the security target.

2.20 In the case of a system, the security enforcing functions shall be correlated to the security objectives, so that it can be seen which functions satisfy which objectives. (A function may satisfy, or help to satisfy, more than one objective.) Every function in the specification of security enforcing functions shall at a minimum help to satisfy at least one objective. The specification of security enforcing functions shall also show why the functions are adequate to counter the identified or stated threats to the security objectives.

2.21 In the case of a product, the security enforcing functions shall be correlated to the intended method of use of the product and the assumptions about the environment into which the product will be installed given in the product rationale. This correlation shall include any dependencies on other security enforcing functions and non-IT security measures assumed to be provided by the environment.

2.22 From the point of view of evaluation, the specification of security enforcing functions is the most important part of the security target. These functions shall always be specified in an informal style, using natural language. In addition, at higher evaluation levels they must also be specified using a semiformal or formal style of presentation. Details of such presentation styles are given later in this chapter.

Definition of Required Security Mechanisms

2.23 A security target may optionally prescribe or claim the use of particular security mechanisms. All security mechanisms included in a security target shall be correlated to its security enforcing functions, so that it can be seen which mechanisms implement each function (a mechanism may implement several functions, and a function may be implemented through the combination of several mechanisms).

2.24 Where security mechanisms are prescribed by the security target, it is the task of the developer to implement the required mechanisms. Otherwise, it is the task of the developer of the TOE to develop and produce mechanisms which, when combined, implement the required security enforcing functions.

Claimed Rating of Minimum Strength of Mechanisms

2.25 Every security target shall specify a claimed rating of the minimum strength of the security mechanisms of the TOE against direct attack. This shall be one of the ratings basic, medium or high as defined in Chapter 3 of these criteria.

Target Evaluation Level

2.26 Every security target shall specify a target evaluation level for evaluation of the TOE. This shall be one of the ratings E1, E2, E3, E4, E5 or E6 as defined in Chapter 4 of these criteria.

Examples of the Use of Existing Security Policy Documents

2.27 These criteria aim to permit the use of existing security policy documents developed to other criteria or standards as part or all of the security target for a system. Therefore, the precise contents of the documents comprising the security target are not prescribed. The minimum information required for evaluation against these criteria has been stated above. Since a security target may consist of more than one document, existing styles of policy document can be accommodated (although supplementary documents may be required to complete the information required for the security target).

2.28 Two examples are given below as to how particular types of security policy documents can meet the requirements for a security target.

2.29 In the UK it is mandatory to produce a System Security Policy (SSP) for all systems that will process nationally classified information. If the authorising authority decides that security evaluation is necessary, a System Electronic Information Security Policy (SEISP) must also be produced. For some target evaluation levels, a Security Policy Model (SPM) must also be produced. The SSP contains a definition of the scope of the system, the security objectives of the system, the security measures to be enforced and the allocation of responsibilities for enforcing them (i.e. it corresponds closely to a System Security Policy as described in these criteria). It also contains a derivation of the required target evaluation level based on key characteristics of the system and its environment. If necessary, an SEISP is developed from the SSP. It is a more detailed statement of the hardware and software security aspects of the SSP, but still in an informal style: it corresponds to a Technical Security Policy as described in these criteria. The SPM is a parallel specification of the security enforcing functions of an SEISP in a formal or semiformal style. It is produced where such a parallel specification is required for the target evaluation level.

2.30 A Claims Document is a list of claims about security enforcing functionality provided by a product, made by the developer of the product, and expressed in a semiformal style using the Claims Language defined in Annex B of this document. It includes assumptions and constraints about the way the product must be used for these claims to be valid. It also includes an identification of security objectives, an informal specification of the claims, a correlation of claimed security enforcing functions to security objectives, and the desired evaluation level, in order to complete a product security target as required by these criteria.

Generic Headings

2.31 It will be easier to understand a security target if the specification of its security enforcing functions has been presented in a sensible order. This will aid the comparison of security targets and simplify the work of evaluators. There exist natural groupings of security enforcing functions to give such ordering, and a recommended set of eight generic headings for one such grouping is included as part of these criteria.

2.32 The recommended headings are:

  • Identification and Authentication
  • Access Control
  • Accountability
  • Audit
  • Object Reuse
  • Accuracy
  • Reliability of Service
  • Data Exchange

2.33 It is recommended that these standard headings are used whenever possible. Their use will simplify comparison with other security targets and make it easier to determine whether or not a particular security target includes, or precludes, functions of a particular type.

Identification and Authentication

2.34 In many TOEs there will be requirements to determine and control the users who are permitted access to resources controlled by the TOE. This involves not only establishing the claimed identity of a user, but also verifying that the user is indeed the user claimed. This is done by the user providing the TOE with some information that is known by the TOE to be associated with the user in question.

2.35 This heading shall cover any functions intended to establish and verify a claimed identity.

2.36 This heading shall include any functions to enable new user identities to be added, and old user identities to be removed or invalidated. Similarly, it shall include any functions to generate, change, or allow authorised users to inspect, the authentication information required to verify the identity of particular users. It shall also include functions to assure the integrity of, or prevent the unauthorised use of, authentication information. It shall include any functions to limit the opportunity for repeated attempts to establish a false identity.

Access Control

2.37 In many TOEs there will be requirements to ensure that users and processes acting on their behalf are prevented from gaining access to information or resources that they are not authorised to access or have no need to access. Similarly, there will be requirements concerning the unauthorised creation or amendment (including deletion) of information.

2.38 This heading shall cover any functions intended to control the flow of information between, and the use of resources by, users, processes and objects. This includes the administration (i.e. the granting and revocation) of access rights and their verification.

2.39 This heading shall include any functions to set up and maintain any lists or rules governing the rights to perform different types of access. It shall include any functions concerned with temporarily restricting access to objects that are simultaneously accessible by several users or processes and are needed to maintain the consistency and accuracy of such objects. It shall include any functions to ensure that upon creation, default access lists or access rules apply to objects. It shall include any functions to control the propagation of access rights to objects. It shall also include any functions to control the inference of information by the aggregation of data from otherwise legitimate accesses.

Accountability

2.40 In many TOEs there will be requirements to ensure that relevant information is recorded about actions performed by users or processes acting on their behalf so that the consequences of those actions can later be linked to the user in question, and the user held accountable for his actions.

2.41 This heading shall cover any functions intended to record the exercising of rights which are relevant to security.

2.42 This heading shall include functions related to the collection, protection and analysis of such information. Certain functions may satisfy requirements for both accountability and auditability and so be relevant to both headings. Such functions may be included under either heading, but shall be cross-referenced to the other heading.

Audit

2.43 In many TOEs there will be requirements to ensure that sufficient information is recorded about both routine and exceptional events that later investigations can determine if security violations have actually occurred, and if so what information or other resources were compromised.

2.44 This heading shall cover any functions intended to detect and investigate events that might represent a threat to security.

2.45 This heading shall include functions related to the collection, protection and analysis of such information. Such analysis may also include trend analysis used to attempt to detect potential violations of the security target before a violation occurs. Certain functions may satisfy requirements for both accountability and auditability and so be relevant to both headings. Such functions may be included under either heading, but shall be cross-referenced to the other heading.

Object Reuse

2.46 In many TOEs there will be requirements to ensure that resources such as main memory and areas of disk storage can be reused while preserving security.

2.47 This heading shall cover any functions intended to control the reuse of data objects.

2.48 This heading shall include functions to initialise or clear unallocated or reallocated data objects. It shall include any functions to initialise or clear reusable media such as magnetic tapes, or to clear output devices such as display screens when not in use.

Accuracy

2.49 In many TOEs there will be requirements to ensure specific relationships between different pieces of data are maintained correctly, and that data is passed between processes without alteration.

2.50 This heading shall cover any functions intended to ensure that data has not been modified in an unauthorised manner.

2.51 This heading shall include functions to determine, establish and maintain the accuracy of the relationships between related data. It shall also include functions to ensure that when data is passed between processes, users and objects, it is possible to detect or prevent loss, addition or alteration, and that it is not possible to change the claimed or actual source and destination of the data transfer.

Reliability of Service

2.52 In many TOEs there will be requirements to ensure that time critical tasks are performed when they are necessary, and not earlier or later, and that non-time critical tasks cannot be made time critical. Similarly, in many TOEs there will be requirements to ensure that access to resources is possible when it is needed, and that resources are not requested or retained unnecessarily.

2.53 This heading shall cover any functions intended to ensure that resources are accessible and usable on demand by an authorised entity (i.e. a user or a process acting on his behalf) and to prevent or limit interference with time- critical operations.

2.54 This heading shall include error detection and error recovery functions intended to restrict the impact of errors on the operation of the TOE and so minimise disruption or loss of service. It shall also include any scheduling functions that ensure that the TOE responds to external events and produces outputs within specified deadlines.

Data Exchange

2.55 In many TOEs there will be requirements for the security of data during transmission over communications channels. This is normally referred to as communications security, as distinct from computer (IT) security.

2.56 This heading shall cover any functions intended to ensure the security of data during transmission over communications channels. It is recommended that such functions are broken down under the following subheadings taken from the OSI Security Architecture:

  • Authentication
  • Access Control
  • Data Confidentiality
  • Data Integrity
  • Non-Repudiation

2.57 Functions shall be grouped under these subheadings in a way consistent with their usage and definition in the OSI Security Architecture [OSI].

2.58 Certain functions may satisfy requirements for both computer and communications security and so be relevant to other headings. In this case there shall be a cross- reference to the other relevant headings.

Predefined Classes

2.59 Many systems will have similar security objectives; it will often be possible to identify common sets of security enforcing functions that meet such objectives. Similarly, many security products will be aimed at satisfying the same market need and thus possess similar functionality. Such predefined classes of common functions can be used as the basis for individual system and product security targets, or can be used as guidelines, to assist users in selecting appropriate security functionality to meet their particular security objectives, and to help manufacturers select functions to include within products. To obtain the maximum benefit from such commonality, it is desirable that standards for predefined functionality classes exist. These criteria have therefore been designed to permit reference within security targets to predefined classes of security enforcing functions. Any security target may reference one or more predefined classes to define part or all of its security enforcing functions.

2.60 Organisations for standardisation or representing particular market sectors have already developed some standard definitions. It is anticipated that the availability of these criteria will encourage the development of predefined classes, in a form consistent for use with these criteria. However, since IT security will continue to evolve rapidly, it will be necessary to define further predefined classes in the future as new groups of functions become sufficiently common to make such classes worthwhile.

2.61 As well as the specification of its security functions, each predefined class shall state the objective of the class, giving its envisaged use, and reasons for the choice of the particular functions included. Predefined classes may also contain other information necessary for inclusion within a security target, such as the details of any mechanisms which are mandated for a class. Provided that details of the contents of such classes are publicly available, the details need not be repeated within each security target that references them.

2.62 The use of predefined classes is not obligatory. There will be cases where a sponsor of evaluation will wish not to use them, and cases where they cannot be used, for example because no predefined class describes the desired security features. As an alternative to the use of predefined classes, the security enforcing functions can always be specified individually. A statement of individual functions can be used in combination with one or more predefined classes which partially, but not entirely, describe a security target. However, a predefined class shall only be specified as part of a security target if all aspects of that class form part of the target.

2.63 Ten example predefined classes are given in Annex A. These have been derived from functionality classes given in [ZSIEC]. All are presented in informal style, and in the current version of the ITSEC are in draft form only. They are:

  1. Example functionality classes F-C1, F-C2, F-B1, F-B2 and F-B3 are hierarchically ordered confidentiality classes which correspond closely to the functionality requirements of the TCSEC classes C1 to A1 [TCSEC].

  2. Example functionality class F-IN is for TOEs with high integrity requirements for data and programs. Such requirements may be necessary in database TOEs, for example.

  3. Example functionality class F-AV sets high requirements for the availability of a complete TOE or special functions of a TOE. Such requirements are significant for TOEs that control manufacturing processes, for example.

  4. Example functionality class F-DI sets high requirements with regard to the safeguarding of data integrity during data communication.

  5. Example functionality Class F-DC is intended for TOEs with high demands on the confidentiality of data during data communication. An example candidate for this class is a cryptographic device.

  6. Example functionality class F-DX is intended for networks with high demands on the confidentiality and integrity of the information to be communicated. For example, this can be the case when sensitive information has to be communicated via insecure (for example: public) networks.

2.64 There is no restriction on the specific functionality which can be claimed or required as a security target. The security enforcing functions of any security target can be fully described within the available specification formats. The existence of predefined classes will not therefore restrict product manufacturers seeking to advance the state of the art, but will lessen the work involved in specifying products or systems which are similar to the stereotypes described, and will provide a basis for comparison of functionality offered. Product security targets may, even when claiming conformance to a predefined class, specify additional constraints and details of the required surrounding environment in order to assist potential users to determine if the product would be suitable for their actual real-world environment.

Specification Style

2.65 These criteria do not prescribe the use of particular proprietary or standardised methods or styles for the specification of security functions. Nor are any methods or styles precluded, so long as the requirements for presentation and evidence of the target evaluation level are met. For the purpose of categorising possible approaches to specification, three types of style have been identified within these criteria: informal, semiformal, and formal. Each type of style is further described below.

2.66 Not all people who will need to use a security target will be familiar with specifications written in a semiformal or formal style. Thus all security targets shall contain a specification of the security enforcing functions using an informal style. Although informal specifications do not require special training to understand, they are prone to ambiguity and imprecision. Semiformal and formal specifications reduce that possibility of ambiguity and imprecision. Thus at the higher evaluation levels, the informal specification of the security enforcing functions shall be supported by a parallel semiformal or formal specification.

2.67 The specification technique or style used within a security target for defining the security objectives, and for defining any prescribed or claimed security mechanisms, is outside the scope of these criteria.

2.68 If a security target is required to contain a specification of the security enforcing functions in a particular type of style, that specification may be wholly or partially replaced by a reference to one or more predefined classes written in such a style.

2.69 Whenever a specification in any style is required, it may be presented as a single document, or multiple documents. Where multiple documents are used, their relationships shall be clearly indicated.

Informal Specification

2.70 An informal specification is written in natural language, rather than a notation requiring special restrictions or conventions. Natural language is the term for communication in any commonly spoken tongue (for example: Dutch, English, French, German). Specifications written in natural language are not subject to any special restrictions, but do need to conform to the ordinary conventions for that language (for example: grammar and syntax).

2.71 A natural language specification shall be written with the aim of minimising ambiguity, by (as a minimum) ensuring that all terms are used consistently, and by ensuring that any terms with a specialised meaning (a meaning not defined in a widely used dictionary) are defined in one or more glossaries, which is included or referenced. It is unlikely that ambiguity can be completely eliminated. Evaluation will seek to identify and resolve any ambiguities that remain.

Semiformal Specification

2.72 A semiformal style of specification requires the use of some restricted notation (or notations), in accordance with a set of conventions which are included in or referenced by the specification. The conventions are specified informally. Such a notation shall allow the specification of both the effect of a function and all exceptional or error conditions associated with that function.

2.73 A semiformal style may either be graphical in presentation, or based on restricted use of natural language (for instance, restricted sentence structure and keywords with special meanings). Examples of semiformal styles include data-flow diagrams, state transition diagrams, entity- relationship diagrams, data structure diagrams, process or program structure diagrams, and the CCITT recommended specification notation SDL.

2.74 Structured design and development methods normally incorporate at least one such semiformal notation for requirements capture, together with prescriptive guidance (for instance, measures of complexity and management methods) on how to use the notation. Examples of structured design methods including such notations are: the Yourdon Structured Method [YSM], Structured Analysis and Design Technique [SADT], Structured Systems Analysis and Design Method [SSADM], and the Jackson Structured Design [JSD] and Jackson Structured Programming [JSP] methods.

2.75 A particular example of a semiformal notation that has been successfully used in the definition of security targets is the Claims Language. The Claims Language is a subset of English; both the vocabulary and the syntactic form of claim sentences are restricted. It was designed (as the name suggests) to provide a structured way in which claims could be made about the security features of IT products. The Claims Language provides for the use of natural language to express those parts of the definition of a security target which support the definition of the claimed security enforcing functions. A full definition of the Claims Language, consistent with these criteria, can be found in Annex B.

Formal Specification

2.76 A formal style of specification is written in a formal notation based upon well-established mathematical concepts. The concepts are used to define the syntax and semantics of the notation, and the proof rules supporting logical reasoning. Formal specifications must be capable of being shown to be derivable from a set of stated axioms, and must be capable of showing the validity of key properties such as the delivery of a valid output for all possible inputs. Where hierarchical levels of specification exist, it must be possible to demonstrate that each level maintains the properties established for the previous level.

2.77 The syntactic and semantic rules supporting a formal notation used in a security target shall define how to recognise constructs unambiguously and determine their meaning. Where proof rules are used to support logical reasoning, there shall be evidence that it is impossible to derive contradictions. All rules supporting the notation shall be defined or referenced. All constructs used in a formal specification shall be completely described by the supporting rules. The formal notation shall allow the specification of both the effect of a function and all exceptional or error conditions associated with that function.

2.78 Example formal notations are VDM, described in [SSVDM], Z, described in [ZRM], the RAISE Specification Language, described in [RSL], Ina Jo, described in [IJRM], the Gypsy Specification Language, described in [GYPSY], and the ISO protocol specification language [LOTOS]. The use of constructs from predicate (or other) logic and set theory as a formal notation is acceptable, provided that the conventions (supporting rules) are documented or referenced (as set out above).

Consistency of Parallel Specifications in Different Styles

2.79 Parallel specifications shall be presented in such a way that the relationships between the specifications are clear, and that where each specification addresses the same point, that point is addressed consistently. Parallel specifications may be presented as separate documents, or may be interleaved in a single document.

2.80 Where ambiguity exists in an informal specification, the corresponding formal or semiformal specification shall resolve the ambiguity. However, it shall be an error for parallel specifications to be inconsistent. Any such error must be resolved by reference to further information outside the security target and one or both specifications amended.

Formal Models of Security Policy

2.81 At evaluation levels E4 and above, a TOE must implement an underlying model of security policy, i.e. there must be an abstract statement of the important principles of security that the TOE will enforce. This shall be expressed in a formal style, as a formal model of security policy. All or part of a suitable published model can be referenced, otherwise a model shall be provided as part of the security target. Any of the formal specification styles identified above may be used to define such a model.

2.82 The formal model need not cover all the security enforcing functions specified within the security target. However, an informal interpretation of the model in terms of the security target shall be provided, and shall show that the security target implements the underlying security policy and contains no functions that conflict with that underlying policy.

2.83 Examples of published formal models of security policy are:

  1. The Bell-La Padula model [BLP] - modelling access control requirements typical of a national security policy for confidentiality.

  2. The Clark and Wilson model [CWM] - modelling the integrity requirements of commercial transaction processing systems.

  3. The Brewer-Nash model [BNM] - modelling access control requirements for client confidentiality, typical of a financial services institution.

  4. The Eizenberg model [EZBM] - modelling access control rights that vary with time.

  5. The Landwehr model [LWM] - modelling the data exchange requirements of a message processing network.

3.ASSURANCE - EFFECTIVENESS

 

Introduction

3.1 This chapter sets out evaluation criteria addressing the effectiveness aspect of assurance for a Target of Evaluation (TOE). The baseline for evaluation is the security target, as defined in Chapter 2, which is simultaneously evaluated for effectiveness, in accordance with the criteria set out in this chapter, and correctness, in accordance with the criteria set out in Chapter 4 following.

Description of the Approach

3.2 Assessment of effectiveness involves consideration of the following aspects of the TOE:

  1. The suitability of the TOE's security enforcing functions to counter the threats to the security of the TOE identified in the security target;

  2. The ability of the TOE's security enforcing functions and mechanisms to bind together in a way that is mutually supportive and provides an integrated and effective whole;

  3. The ability of the TOE's security mechanisms to withstand direct attack;

  4. Whether known security vulnerabilities in the construction of the TOE could in practice compromise the security of the TOE;

  5. That the TOE cannot be configured or used in a manner which is insecure but which an administrator or end- user of the TOE would reasonably believe to be secure;

  6. Whether known security vulnerabilities in the operation of the TOE could in practice compromise the security of the TOE.

3.3 The assessment of each of the aspects of effectiveness identified above is performed using documentation supplied by the sponsor and also documentation and evaluation results from the evaluation of correctness of the TOE. This means that although evaluation of effectiveness can proceed in parallel with the evaluation of correctness, it cannot be completed until after the final results of the assessment of correctness are available.

3.4 Specifically, the assessment of effectiveness is based on a vulnerability analysis of the TOE. This analysis has the objective of searching for all the ways in which it is possible for a user of the TOE to deactivate, bypass, corrupt, circumvent, directly attack, or otherwise defeat the security enforcing functions and mechanisms of the TOE. As a minimum, the sponsor's vulnerability analysis must consider all the information specified in figure 4 for the evaluation level in question (i.e. a search for vulnerabilities is to be performed using part of the total information provided by the sponsor for that evaluation level). As the evaluation level increases, the correctness criteria of Chapter 4 requires the information specified in figure 4 to be provided at increasing levels of rigour, as indicated by the use of the verbs state, describe, and explain.

3.5 All critical security mechanisms (i.e. those mechanisms whose failure would create a security weakness) are assessed for their ability to withstand direct attack. The minimum strength of each critical mechanism shall be rated either basic, medium or high.

3.6 For the minimum strength of a critical mechanism to be rated basic it shall be evident that it provides protection against random accidental subversion, although it may be capable of being defeated by knowledgeable attackers.

3.7 For the minimum strength of a critical mechanism to be rated medium it shall be evident that it provides protection against attackers with limited opportunities or resources.

3.8 For the minimum strength of a critical mechanism to be rated high it shall be evident that it could only be defeated by attackers possessing a high level of expertise, opportunity and resources, successful attack being judged to be beyond normal practicality.

3.9 A TOE will only fail evaluation on effectiveness grounds if an exploitable vulnerability, which is found during evaluation of effectiveness, has not been eliminated before the end of evaluation. This includes methods of successful direct attack found during the assessment of minimum strength of mechanisms which invalidates the claimed rating. If any such vulnerability exists the TOE will be awarded an overall evaluation level of E0, indicating that it would be unsuitable for use as proposed.

3.10 Effectiveness of a TOE is always assessed in the context of the given security target. For example, a security product sold for incorporation within systems may contain known covert channels. If, however, the system security target has no access control requirements for confidentiality, then the presence of covert channels in the product is irrelevant and will not effect the ability of the TOE to meet its security target, and will not cause the TOE to fail evaluation. If there are system access control requirements for confidentiality, then the system security target may specify acceptable maximum covert channel bandwidths. If covert channels are identified which exceed these bandwidths, or if no bandwidth is actually specified, then the evaluator must determine if the identified covert channels will cause the TOE to fail evaluation on the grounds of unsuitable functionality.

Systems and Products

3.11 There are different requirements and options for the content of a security target for a TOE, depending on whether the TOE is being evaluated as a system or product. These differences are set out under Construction - Phase 1 - Requirements in Chapter 4, and further explained in Chapter 2.

Effectiveness Criteria - Construction

Documentation

3.12 The sponsor shall provide the following documentation in addition to that required for evaluation of correctness:

  • Suitability Analysis
  • Binding Analysis
  • Strength of Mechanisms Analysis
  • List of Known Vulnerabilities in Construction.

Aspect 1 - Suitability of Functionality

Definition

3.13 As part of the documentation required for the evaluation of correctness, the sponsor will provide a security target. As part of the assessment of correctness, that target is examined for coverage and consistency. For this aspect of effectiveness the security target is used to determine whether the security enforcing functions and mechanisms of the TOE will in fact counter the threats to the security of the TOE identified in the security target.

Requirements for Content and Presentation

3.14 The suitability analysis shall link security enforcing functions and mechanisms to the threats, enumerated in the security target, that they are designed to counter.

Requirements for Evidence

3.15 The suitability analysis shall show how the threats are countered by the security enforcing functions and mechanisms. It shall show that there are no threats that are not adequately countered by one or more of the stated security enforcing functions. The analysis shall be performed using, at minimum, all the information given in figure 4 for the evaluation level in question.

Evaluator Actions

3.16 Check that the suitability analysis provided meets all requirements for content and presentation and evidence. Check that the analysis has considered all of the information given in figure 4 for the evaluation level in question.

Aspect 2 - Binding of Functionality

Definition

3.17 This aspect of effectiveness investigates the ability of the security enforcing functions and mechanisms of the TOE to work together in a way that is mutually supportive and provides an integrated and effective whole.

Requirements for Content and Presentation

3.18 The binding analysis shall provide an analysis of all potential interrelationships between security enforcing functions and mechanisms.

Requirements for Evidence

3.19 The binding analysis shall show that it is not possible to cause any security enforcing function or mechanism to conflict with or contradict the intent of other security enforcing functions or mechanisms. The analysis shall be performed using, at minimum, all the information given in figure 4 for the evaluation level in question.

Evaluator Actions

3.20 Check that the binding analysis provided meets all requirements for content and presentation and evidence. Check that the analysis has considered all of the information given in figure 4 for the evaluation level in question.

Aspect 3 - Strength of Mechanisms

Definition

3.21 Even if a security enforcing mechanism cannot be bypassed, deactivated, corrupted, or circumvented, it may still be possible to defeat it by a direct attack based on deficiencies in its underlying algorithms, principles or properties. For this aspect of effectiveness the ability of these mechanisms to withstand such direct attack is assessed. This aspect of effectiveness is distinguished from other aspects in that it requires consideration of the level of resources that would be needed for an attacker to execute a successful attack.

Requirements for Content and Presentation

3.22 The strength of mechanisms analysis shall list all security enforcing mechanisms that have been identified as critical within the TOE. It shall include or reference analyses of the underlying algorithms, principles and properties of those mechanisms.

Requirements for Evidence

3.23 The strength of mechanisms analysis shall show that all critical mechanisms satisfy the claimed minimum strength of mechanisms rating, as defined in paragraphs 3.6 to 3.8: in the case of cryptographic mechanisms, this shall take the form of a statement of confirmation from the appropriate national body. Other analyses shall be performed using, at minimum, all the information given in figure 4 for the evaluation level in question.

Evaluator Actions

3.24 Check that all mechanisms that are critical have been identified as such. Check that the strength of mechanisms analysis provided meets all requirements for content and presentation and evidence. Check that the analysis has considered all of the information given in figure 4 for the evaluation level in question. Check that the specifications/definitions of all critical mechanisms support the claimed minimum strength rating. Perform penetration testing where necessary to confirm or disprove the claimed minimum strength of mechanisms.

Aspect 4 - Construction Vulnerability Assessment

Definition

3.25 Before and during the other aspects of evaluation of the TOE, various vulnerabilities in the construction of the TOE (such as ways of deactivating, bypassing, corrupting, or circumventing security enforcing functions and mechanisms) will have been identified by both sponsor and evaluator. For this aspect of effectiveness these known vulnerabilities are assessed to determine whether they could in practice compromise the security of the TOE as specified by the security target.

Requirements for Content and Presentation

3.26 The list of known vulnerabilities provided by the sponsor shall identify all vulnerabilities in the construction of the TOE known to him. It shall identify each known vulnerability, provide an analysis of its potential impact, and identify the measures proposed or provided to counter its effect.

Requirements for Evidence

3.27 The analysis of the potential impact of each known vulnerability shall show that the vulnerability in question cannot be exploited in the intended environment for the TOE, because either:

  • The vulnerability is adequately covered by other, uncompromised, security mechanisms, or

  • It can be shown that the vulnerability is irrelevant to the security target, will not exist in practice, or can be countered adequately by documented technical, personnel, procedural or physical security measures outside the TOE. These external security measures shall have been defined within (or shall have been added to) the appropriate documentation.

The analysis shall be performed using, at minimum, all the information given in figure 4 for the evaluation level in question.

Evaluator Actions

3.28 Check that the list of known vulnerabilities in construction meets all requirements for content and presentation and evidence given above. Check that the analysis of the potential impact of each vulnerability has considered all of the information given in figure 4 for the evaluation level in question. Perform an independent vulnerability analysis, taking into account both the listed and any other known construction vulnerabilities found during evaluation. Check that all combinations of known vulnerabilities have been addressed. Check that the analyses of the potential impact of vulnerabilities contain no undocumented or unreasonable assumptions about the intended environment. Check that all assumptions and requirements for external security measures have been appropriately documented. Perform penetration testing to confirm or disprove whether the known vulnerabilities are actually exploitable in practice.

Effectiveness Criteria - Operation

Documentation

3.29 The sponsor shall provide the following documentation in addition to that required for evaluation of correctness:

  • Ease of Use Analysis
  • List of Known Vulnerabilities in Operational Use

Aspect 1 - Ease of Use

Definition

3.30 This aspect of effectiveness investigates whether the TOE can be configured or used in a manner which is insecure but which an administrator or end-user of the TOE would reasonably believe to be secure.

Requirements for Content and Presentation

3.31 The ease of use analysis shall identify possible modes of operation of the TOE, including operation following failure or operational error, their consequences and implications for maintaining secure operation.

Requirements for Evidence

3.32 The ease of use analysis shall show that any human or other error in operation that deactivates or disables security enforcing functions or mechanisms will be easily detectable. It shall show that if it is possible to configure or cause the TOE to be used in a way which is insecure (i.e. the security enforcing functions and mechanisms of the TOE do not satisfy the security target), when an end-user or administrator of the TOE would reasonably believe it to be secure, then this fact will also be detectable. The analysis shall be performed using, at minimum, all the information given in figure 4 for the evaluation level in question.

Evaluator Actions

3.33 Check that the ease of use analysis provided meets all requirements for content and presentation and evidence. Check that the analysis has considered all of the information given in figure 4 for the evaluation level in question. Check the analysis for undocumented or unreasonable assumptions about the intended environment. Check that all assumptions and requirements for external security measures (such as external procedural, physical and personnel controls) have been appropriately documented. Repeat any configuration and installation procedure to check that the TOE can be configured and used securely, using only the user and administration documentation for guidance. Perform other testing where necessary to confirm or disprove the ease of use analysis.

Aspect 2 - Operational Vulnerability Assessment

Definition

3.34 Before and during the other aspects of evaluation of the TOE, various vulnerabilities in operation of the TOE will have been identified by both sponsor and evaluator. For this aspect of effectiveness these known vulnerabilities are assessed to determine whether they could in practice compromise the security of the TOE as specified by the security target.

Requirements for Content and Presentation

3.35 The list of known vulnerabilities provided by the sponsor shall identify all vulnerabilities in operation of the TOE known to him. It shall identify each known vulnerability, provide an analysis of its potential impact, and identify the measures proposed or provided to counter its effect.

Requirements for Evidence

3.36 The analysis of the potential impact of each known vulnerability shall show that the vulnerability in question cannot be exploited in the intended environment for the TOE, because either:

  • The vulnerability is adequately covered by other, uncompromised, external security measures, or

  • It can be shown that the vulnerability is irrelevant to the security target or will not be exploitable in practice

The analysis shall be performed using, at minimum, all the information given in figure 4 for the evaluation level in question. Any required external security measures shall have been defined within (or shall have been added to) the appropriate documentation.

Evaluator Actions

3.37 Check that the list of known vulnerabilities in operation meets all requirements for content and presentation and evidence given above. Check that the analysis of the potential impact of each vulnerability has considered all of the information given in figure 4 for the evaluation level in question. Perform an independent vulnerability analysis, taking into account both the listed and any other known operational vulnerabilities found during evaluation. Check that all combinations of known vulnerabilities have been addressed. Check that the analyses of the potential impact of vulnerabilities contain no undocumented or unreasonable assumptions about the intended environment. Check that all assumptions and requirements for external security measures have been appropriately documented. Perform penetration testing to confirm or disprove whether the known vulnerabilities are actually exploitable in practice.

INFORMATION OBTAINED FROM A CORRECTNESS ASSESSMENT WHICH IS USED TO PERFORM A VULNERABILITY ANALYSIS

Fig. 4 Information used in a Vulnerability Analysis

4.ASSURANCE - CORRECTNESS

 

Introduction

4.1 This chapter sets out evaluation criteria addressing the correctness aspect of assurance for a Target of Evaluation (TOE). The baseline for evaluation is a security target defined in accordance with Chapter 2. The security target shall contain the necessary elements specified in Chapter 2 for a system or product as appropriate. This shall include the target evaluation level and the claimed rating for minimum strength of mechanisms. The effectiveness aspect of assurance is covered by the criteria detailed in Chapter 3.

Characterisation

4.2 Seven evaluation levels are defined in respect of the confidence in the correctness of a TOE. E0 designates the lowest level and E6 the highest.

4.3 The seven evaluation levels can be characterised as follows:

Level E0

4.4 This level represents inadequate assurance.

Level E1

4.5 At this level there shall be a security target and an informal description of the architectural design of the TOE. Functional testing shall indicate that the TOE satisfies its security target.

Level E2

4.6 In addition to the requirements for level E1, there shall be an informal description of the detailed design. Evidence of functional testing shall be evaluated. There shall be a configuration control system and an approved distribution procedure.

Level E3

4.7 In addition to the requirements for level E2, the source code and/or hardware drawings corresponding to the security mechanisms shall be evaluated. Evidence of testing of those mechanisms shall be evaluated.

Level E4

4.8 In addition to the requirements for level E3, there shall be an underlying formal model of security policy supporting the security target. The security enforcing functions, the architectural design and the detailed design shall be specified in a semiformal style.

Level E5

4.9 In addition to the requirements for level E4, there shall be a close correspondence between the detailed design and the source code and/or hardware drawings.

Level E6

4.10 In addition to the requirements for level E5, the security enforcing functions and the architectural design shall be specified in a formal style, consistent with the specified underlying formal model of security policy.

Summary of Requirements

4.11 Remaining sections of this chapter contain the detailed criteria to be satisfied at each correctness evaluation level, under detailed headings, repeated for each of the levels E1 to E6. The major differences between levels follow from additional requirements in the investigation of the Development Process. To assist understanding of these differences, the following diagrams show the relationship between key items to be supplied by the sponsor and the evaluation level at which they are first required by the evaluator.

CORRECTNESS CRITERIA BY LEVEL - DEVELOPMENT PROCESS

CORRECTNESS CRITERIA BY LEVEL - DEVELOPMENT ENVIRONMENT

CORRECTNESS CRITERIA BY LEVEL - OPERATION

Approach to Descriptions <