Each of the specifications described in section 3.1 is a requirements specification. That a product (referred to as an ``Information Technology (IT) Product'' in computer security requirement specifications) satisfies some level of computer security criteria does not imply that such a product supports open system specifications. Such a product may be completely proprietary and fully satisfy computer security requirements. The goal of the developers of the specifications in section 3.1 is to insure computer system security.
Thus, for example, a program written using an API to access security features on one product that meets the Commercial Security 2 (CS2) protection profile of the Federal Criteria may or may not be portable to another CS2 product. The user interface to a utility required on a CS2 product may or may not be the same user interface to the same utility on another CS2 product. The display device used for access on a CS2 product over a communication channel may or may not interoperate with another CS2 product because the communications channel protocol used by one CS2 product differs from another.
The goal of open system standards is to insure portability and interoperability. Every open system specification was developed in response to a need by some user community. Once such a need is identified, functional requirements are developed in order to more precisely describe the needs a particular open system standard is to satisfy.
As a result of the specifications in section 3.1, the computer security community is reaching a level of consensus on requirements for computer security. The question arises as to how well products based on open system standards can meet these requirements. It is important to note that computer security functional requirements, such as those in section 3.1, are intended to be applied to implementations, i.e., products not open system specifications. With regard to a product based on open system specifications, computer security criteria would be applied to that product's implementation, not to the collection of open system specifications which that product supports. Nonetheless, the question can still be asked of the open system specifications themselves with the caveat that it is their implementation on which final evaluation is made.
This question of how well open systems can meet computer security criteria is not a question that has just recently been asked. While the primary goal is computer security, many of the developers of computer security criteria participate in the development of open system standards intended to support existing computer security requirements. POSIX.6 (see ch. 4) is one example of such an open system standards development activity.
NIST is interested in exploring the problems of quantifying how well open system standards meet consensus computer security functional requirements [PI93]. Before such a quantification can be made, several questions must be addressed.
One question is which computer security requirements specification should be used. While generally the same in intent, each has its own form and structure. It is possible that a system which satisfies some level of one specification may not satisfy any single level of another but may satisfy requirements from several levels. Because the Common Criteria will have the most flexible framework, users can choose a level to exactly meet their requirements. Consequently, the Common Criteria, the FIPS that will be developed by NIST and NSA, is the specification of choice for Federal Agencies and is intended to be useful to organizations in the private sector.
A difficult question is what does it mean for an open system standard to meet computer security functional requirements. For most functional requirements, the answer to this question is not immediately obvious. For example, consider a requirement for a utility to examine audit trails. An API to audit trail information which standardizes access by a program could be developed. As a result, portable utilities which satisfy the requirement could be developed. In addition, a standard user interface to the utility could be developed so that users would know how to interact with the utility on any secure product which satisfies the requirement. If audit information is generated in a network environment and transmitted to a central location, a standard protocol for the communication of audit information could be developed.
Once it has been determined what it means for an open system standard to meet given computer security functional requirements, it must be determined that there is a need for such an open system standard assuming one does not already exist. Consider again the example of a requirement for a utility to examine audit trails. It may be the case that a standard user interface to an audit trail utility in not necessary because such utilities are always developed with window-based desktop displays in which user access is self-evident. Consequently, the question of a user being able to interact with any such utility is moot. In the final analysis, the community of interest will likely determine the need for an open system standard to meet computer security requirements.
Another question is, of existing open system standards, which ones are applicable to be compared against computer security criteria. In order to answer this question, it must be determined what products are addressed by a particular computer security functional requirements specification.
Thus, while the Common Criteria can obviously be applied to products which support POSIX.1 and POSIX.6, it is not inappropriate to consider the application of the Common Criteria to a product supporting an open system specification such as SQL. SQL is certainly concerned with the manipulation of resources by named users and the protection of such resources against unauthorized access. On the other hand, with regard to the Common Criteria, it is not clear how computer security functional requirements would apply to a product which supports a protocol specification, such as, OSI Transport. Each existing open system standard should be considered a candidate to be compared against computer security functional requirements. One possible way to deal with this question is to look at sets or profiles of open system specifications and apply computer security criteria to these instead of individual specifications.
Clearly, there is much work to be done to answer these questions. Until these questions are answered, it is not not clear how well the security aspects of the open system specifications described in this report meet the functional requirements of computer security evaluation criteria such as the Common Criteria.