Computers & Security, 13 (1994) 647-650

Security Evaluation in Information Technology Standards1 Francesco Gentile*, Luigi Giurb, Franc0 Guidae, Emilio Montolivo*, Michele Volpe- * Forr&zione Up Bmfoni, Via B. Castt$iorre, 59-00142 Rorva, Italy; ** .S& Via de/la Vipaccia, 4500163 Rortra, Italy

Introduction

This paper studies the problems that arise when security specifications of standards include a security evaluation, at a specified level, of the IT product or system built to that standard.The development ofan Information Tech- nology (IT) system or product, that must conform to a standard, depends on both developer’s choices and standard specifications. Therefore, the security evalu- ation of such a system or product may fail either because of inadequate developer’s choices or because of standard specifications that are considered unsuitable by the security evaluator. In the latter case no IT system or product built to that standard can be successfully evalu- ated as the standard itself, rather than the system or the product, is rejected by the evaluator. To face this prob- lem, evaluation criteria are required that provide a preliminary validation scheme of the security specifica- tions to be included into a standard.

In the analysis of the above problem, ITSEC criteria will be taken into account.

’ Work carried out in the framework of the agreement between the Italian PT Administration and Fondazione Ugo Uordoni.

Security Evaluation Against ITSEC

The system or product to be evaluated against ITSEC (IT Security Evaluation Criteria) is referred to as the target of evaluation (TOE). Each TOE needs a docu- ment called the ‘security target’. The security target of a system contains:

.A system security policy including the security objectives, the envisaged threats, the list of the security enforcing functions and the list of the physical,

personnel and procedural measures.

*A specification of the required security enforcing functions.

*A definition of the required security mechanisms

(optional).

l The claimed minimum strength of mechanisms rating.

l The target evaluation level.

The security target of a product contains a ‘product rationale’, instead of the system security policy. A product rationale identifies the intended method ofuse, the intended environment for use and the assumed threats within that environment.

0167-4048/94/$7.00 0 1994, Elsevier Science Ltd 647

Security Evaluation in IT Standards/Gentile et al

The person or organization requesting the evaluation (sponsor) also provides additional documentation which describes the system in more detail the higher the evaluation level, by specifying the implementation choices not in the security target. Such documentation distinguishes between documentation concerning the way the TOE is developed (construction) and documentation concerning the way it will be used (operation). The first kind of documentation describes both the development process (by means of documents that may contain, if requested by the evaluation level, a more precise definition of the security policy, the architectural design, the detailed design, and the implementation description) and the related development environment (by means ofdocuments that may describe, if requested by the evaluation level, the configuration control system, the programming languages and the compilers used in the implementation, and the security measures used in the development). The second kind of documentation describes the operational procedures (both for the user and for the TOE administrator), and the security procedures concerning the delivery, the installation and maintenance of the TOE.

A security evaluation against ITSEC is based on the concept of ‘assurance’. This concept is defined as the confidence that may be held in the security provided by the TOE. The ITSEC approach distinguishes the confidence in the correctness of the security enforcing functions (both from the development and the operational point of view) from the confidence in the effectiveness of those functions. ITSEC defines seven evaluation levels labelled EO to E6 representing ascending levels of confidence in correctness. Requirements for content and presentation, requirements for evidence, and evaluator actions are specified for each level. As far as effectiveness is concerned, the evaluator actions do not change as the level changes, and are as follows:

1)

2)

3)

Verify that the security enforcing functions and mechanisms of the TOE actually counter the threats to the security of the TOE specified in the security target (suitability of functionality).

Verify that the security enforcing functions and mechanisms of the TOE work together in a way mutually supportive and provides an integrated and effective whole (binding of functionality).

Verify that the security mechanisms are able to withstand direct attacks according to the minimum

4)

5)

6)

strength rating claimed in the security target (strength of mechanisms).

Verify that the construction vulnerabilities could not in practice compromise the security of the TOE (construction vulnerability assessment).

Verify that the TOE cannot be confibmred or used in a manner which is insecure but which an administrator or end-user of the TOE would reasonably believe to be secure (ease of use).

Verify that the operational vulnerabilities could not in practice compromise the security of the TOE (operational vulnerability assessment).

However, the effectiveness assessment depends on the evaluation level for the above described actions being performed by using part of the documentation required for the correctness evaluation pertaining to the target evaluation level (see ITSEC, Fig. 4). For example, in order to evaluate a TOE against El or E2 evaluation level, the evaluator may ignore the detailed design for the effectiveness assessment. However, such a TOE might fail the evaluation on effectiveness grounds for a level greater than E2. In fact, for these levels, such documen- tation must be taken into account.

Security Evaluation as an IT Standard Specification

As far as security is concerned, an IT standard for a system or product includes a set of requirements singled out to address the security problems for that system or product.

Such requirements are the result of a study aimed to detect risks and threats for the system or product in question. Note that, in the case of a system, actual risks and threats are considered while, in the case ofaproduct, the intended environment for use and assumed threats within that environment are considered. In order to include the evaluation against specified criteria at a specified level, as a requirement in a standard, it is necessary to write the standard specification in a way that it cannot compromise the passing of the requested evaluation. For example, it is necessary to ascertain that the solutions chosen by a standardization body for the security problems of the system or product related to the standard are assumed as correct by the evaluator for

648

Computers & Security, Vol. 13, No. 8

the required evaluation level. To study this problem in detail, it is necessary to analyze the security specification for a certain standard. Such a specification may contain:

a) The security objectives for the system or product and the identified threats.

b) What is specified in a), and, partially or in full, the following:

bl) the security functions;

b2) the security mechanisms;

b3) information on the construction process;

b4) the operational procedures.

For example, regarding b3) the standard may specify both architectural design and detailed design.

Note that the case where the standard specifies counter- measures only is not taken into account. In fact, the evaluation makes sense only if it is performed conside- ring a given set of security objectives and identified threats (assumed threats, in the case of a product). For instance, objectives and threats must be part of the ITSEC security target and, if the standardization body does not specie them, then it is up to the sponsor to identitjr them even though he may ignore, in full or partially, how risk and threat analysis were performed by the standardization body.

The case described in a) would allow the sponsor to require an evaluation level as high as he wants being guaranteed that the requirements in the standard will not prevent the successful evaluation of the system or product in question. However, case a) is extremely rare since a standardization body, in every standard, often needs to describe the system or product in full detail. For example, this may happen because of the compati- bility needs between different systems. It will then be convenient to consider problems related to case b) which occur more frequently. For instance, after the ITSEC evaluator has performed the actions 1) and 2) discussed above for the requested evaluation level, he can also consider the security functions specified in a standard which are not suitable to address the security objectives. Analogous problems might arise if the evalu- ator, after action 3), assumes that the mechanisms, specified in the standard, are not suitable to address the requested level of strength of mechanisms. Finally, as far

as actions 4), 5) and 6) are concerned, some difficulties might be found if what is specified in b3) and b4) is included in the standard.

Summarising, it has been discussed how some require- ments included in a standard can be assumed, during the evaluation, as not suitable for the requested evaluation level. To avoid this, it is possible to describe the system or product in the standard at a low level of detail especially when a high evaluation level is required. However, this way offacing the problem is inappropriate and does not exclude all the risks discussed above.

A complete svlution to the problem can be obtained if an accredited evaluator validates the overall specifica- tion of the standard with respect to the required evaluation level. In detail, the validation will represent the evaluator declaration that it is possible for a de- veloper to construct a system or a product that conforms to the standard, and is capable to be successfully evalu- ated against the required evaluation level. Unfortunately, in the security evaluation criteria, currently under de- velopment or in use, the validation concept is not fully provided.

As far as ITSEC is concerned, it is possible to define functionality classes that contain, besides a collection of security functionalities, the security objectives, the in- tended environment, the assumed threats within that environment, the envisaged use, and, if necessary, the details of any mechanisms which are mandated for that class. However, these classes do not solve the problem of validating the standard specification because ITSEC does not provide class validation and registration by an accredited evaluator. Moreover, the functionality classes do not contain information about the system or product development process that is often described in a standard specification. Thus, even if validation and registration of ITSEC functionality classes were provided, the use of these classes within IT standards does not remove all doubts for a successful evaluation of the standardized system or product, for the standard requirements may include the architectural design and/or the detailed design.

2 Clearly, if the standardization body wcrc an accredited evnlu.~tor there would be no need of questing the prelimrnary wlidation of the standard to an external facility. Currently, it is not foresecablr whether this circumstance can be realized or not. Thus, in the rat of the paper the standardization body will be considered distinct from the evaluator.

649

Security Evaluation in IT Standards/Gentile et al

In the case of the US Federal Criteria (which is still in a draft format), the basis for security evaluation is the ‘protection profile’ which is a collection of security requirements for a generic product that can be used as part ofa system. A protection profile includes protection function requirements, assurance requirements, and a rationale describing the anticipated threats and intended method of use. A protection profile must be analyzed to assess, among other things, whether the proposed protection functions are right to counter the identified threats and are commensurate to the proposed assurance requirements. The assurance requirements are not defined by a fixed evaluation level (as in ITSEC) but they are specified as a collection of assurance components that are individually defined by levels.

To require security evaluation against the Federal Criteria in a standard, a standardization body must select a set of assurance components with the appropriate levels to obtain the needed assurance degree. Regarding the validation of the overall standard specification by an accredited evaluator, it must be noted that the Federal Criteria provides neither the definition of protection profiles that specifies security requirements for generic systems, nor the possibility to include information about the product (or system) development process in the protection profile.

To complete the scenario of the security evaluation criteria, it is important to mention the Evaluation Criteria for IT Security currently under development by IS0 (even though these criteria have not yet reached a stable form). It is noteworthy that these criteria permit the definition of protection profiles which are similar to those of the Federal Criteria (as they provide validation and registration by accredited evaluators), but they can specify security requirements both for systems and for products. However, the impossibility of including information about the product or system development process in the protection profile still exists in these new criteria.

Conclusions

The analysis carried out has shown that security evaluation criteria currently available or in development, are not suitable to address the problems that arise when a standard requires a security evaluation against those criteria. To solve these problems, it is necessary to make use ofsecurity evaluation criteria that permit the preliminary validation of the overall standard

security specification, in order to avoid that systems or products that conform to the standard may fail evaluation at the required evaluation level due to incorrect security requirements included in the standard. The validation process might consist of a security evaluation performed without having the implemented system or product at disposal, and using only a part of the required documentation for the target evaluation level. A validated standard will ensure that it is possible to implement a system or a product that conforms to the standard specification and is capable of passing evaluation at the required evaluation level. If the evaluation ofthis system or product fails, then the reason for failure resides in its implementation and is not due to the standard specification. Thus, if the standard is preliminarily validated, then no question about it will arise whenever a conforming system or product fails the security evaluation.

References

[FCI] Federal Criteria For Information Technology Security, Volume 1, Protection Profile Development, Version 1.0, National Institute of Standards and Tech- nology and National Security Agency, December 1992.

[FC2] Federal Criteria For Information Technology Security, Volume 11, Registry of Protection Profiles, Version 1.0, National Institute of Standards and Tech- nology and National Security Agency, December 1992.

[ISOl] Evaluation Criteria for IT Security. Part 1 - Introduction and General Model, ISO/IEC/JTCl/SC27/WG3 Nl82, December 16, 1993.

[IS021 Evaluation Criteria for IT Security. Part 2 - Functionality ofIT Products,Systems and Components, ISO/IEC/JTCl/SC27/WG3 N183, December 16, 1993.

[IS031 Evaluation Criteria for IT Security Part 3 - Assurance of IT Systems, etc., ISO/IEC/JTCl/SC27/WG3 N184, December 16, 1993.

[ITS] Information Technology Security Evaluation Criteria (ITSEC), Provisional Harmonized Criteria, Version 1.2, June 1991, Commission of the European Communities, Directorate-General XIII, Rue de la Eoi 200, B-1049, Brussels, Belgium.

650