TURNING MULTIPLE EVALUATED PRODUCTS INTO TRUSTED SYSTEMS NCSC TECHNICAL REPORT-003 Library No. S-241,353 July 1994 FOREWORD This Technical Report "Turning Multiple Evaluated Products Into Trusted Systems," is provided to stimulate discussion on how evaluated products can be combined to produce trusted systems. We establish the premise that the integrator/system designer has the responsibility to retain, in as much as possible, an evaluated product's rating while it, the product, is performing within the context of the integrated (larger) system. In this manner, we therefore propose that a modified evaluated product has advantage over the use of a non-evaluated product for similar functionality. Recommendations for revision to this publication are encouraged and will be reviewed periodically by the NCSC. Address all proposals for revision through appropriate channels to: National Computer Security Center 9800 Savage Road Fort George G. Meade, MD 20755-6000 ATTN: Standards, Criteria, and Guidelines Division Reviewed by:_______________________________________ GLENN GOMES Chief, INFOSEC Standards, Criteria & Guidelines Division Released by:_______________________________________ ROBERT J. SCALZI Chief, INFOSEC Systems Engineering Office ACKNOWLEDGEMENTS This document was written by Joan Fowler and Dan Gamble of Grumman Data Systems for the Procurement Guideline Project. The project leader was MAJ (USA) Melvin L. De Vilbiss. Besides many NSA organizations, the document was reviewed by Department of the Army (ASIS), DISA, MITRE, and NAVELEXSECSEN. TABLE OF CONTENTS FORWARD ACKNOWLEDGEMENTS 1. INTRODUCTION 2. SYSTEM DESIGN APPROACH 2.1 Classic High Level View of a System 2.2 Determine System Functions/Services 2.3 Define Functions/Services Interdependencies 2.4 Specify Dependency Lattice 2.5 Define Products and Platform 3. TRUSTED SYSTEM DESIGN APPROACH 3.1 Evaluated Products List (EPL) Product Determination 3.2 Product Conflict Resolution 3.3 Architecture Relies on External Dependencies 3.4 Trusted Computing Base (TCB) Definition 3.4.1 Product Analysis 3.4.2 System Interface Analysis 3.4.3 Application Audit Example 3.4.4 Example for An Integrated System 4. TRUSTED SYSTEM ASSURANCE 4.1 Product Assurance Documentation 4.2 System Assurance Documentation 4.3 System Documentation Standards and Analysis 5. CONCLUSION BIBLIOGRAPHY 1 INTRODUCTION In the past few years, more Commercial Off-The-Shelf (COTS) products have been populating the Evaluated Products List (EPL) than in previous years. In the current economic environment, the tendency is to use evaluated products when designing trusted systems to meet specific procurement requirements. The process to design a trusted system composed of evaluated products is fundamentally the same as designing any system using COTS products. The concept that makes the process of designing trusted systems unique is that the combination of different products composes a totally new security environment. A trusted system, in the context of this paper, is a system composed of multiple products. This system, at the interface to the Trusted Computing Base (TCB), conforms to the Department of Defense (DoD) Trusted Computer System Evaluation Criteria (TCSEC) (DoD 5200.28-STD) [1] and the forthcoming TCSEC-derived protection profiles to be embodied in future U.S./international criteria. This paper discusses how evaluated products can be combined to produce trusted systems which meet the requirements specified in a procurement document, thereby modifying, adapting, or eliminating portions of the composing product's TCB. Frequently, the requirements specified necessitate changes to the product TCBs. Because the product's rating may be invalidated when the product's TCB is changed without understanding, justification, and review; system-level assurances are necessary to compensate for the changes. It is the responsibility of the system integrator/system designer to do the utmost to retain and not invalidate the product rating. However, even with this possible invalidation, the use of an evaluated product in a system provides the knowledge that the original product was scrutinized, and those portions of the product that are not changed continue to retain that scrutiny for the correctness of processing. Therefore, even if a product's TCB must be modified, adapted, or portions eliminated, the use of an evaluated product in a system development is advantageous over the use of a non-evaluated product for the similar functionality. The combination of unequal security qualified components to build a system is another dilemma in the integration process which will not be discussed in this paper. The need for the modification, adaptation, or elimination of a TCB in evaluated products has greatly diminished in recent years. When the modification, adaptation, or elimination is dictated due to system requirements, these changes can take many forms. The easiest and most trusted form is to tune the product using the product's configuration options, "hooks", or switches. (For example, in many products it is possible to audit all or no activity for a user.) Another form is to use the product as it was not necessarily intended to be used. If a product with Mandatory Access Control (MAC) labels and controls is used in a system high environment, the MAC processing actually occurs in the execution of the software, but it does not have any security relevancy in the system. Another form of adapting an evaluated product's TCB is to develop an extension to overcome the shortcomings of the combined products used in a system. A final form of eliminating security functionality is to actually modify the code of the product. This form is the least desirable and should only be done when the system requirements dictate that product code modification is the only solution. No matter which form the modification takes, great care must be taken to determine the effect on the entire system. The time required to integrate evaluated products into a trusted system and ascertain the effects on each facet of the product must be assessed since that time, in some cases, may be greater than the time required to develop a trusted system, or a portion of a trusted system, from the beginning. 2 SYSTEM DESIGN APPROACH This section discusses an approach to designing a system to integrate COTS products. This approach is a single method that can effectively be used for system integration, although it is not the only approach. The approach, as it is described in this section, is used for the integration of untrusted systems from COTS products. It is also applicable to the integration of EPL products into trusted systems, with a few modifications to the approach. This revised approach for trusted systems will be discussed in following sections. 2.1 CLASSIC HIGH LEVEL VIEW OF A SYSTEM The textbook high level view of a system is a processing box which receives inputs, processes the inputs according to a set of requirements, and generates outputs. This is the high level view of a system whether it is trusted or not. The list of requirements which must be satisfied by the system processing is defined by the operational needs and outputs required of the system. In the case of trusted systems, the security policy of the system also determines some of the system requirements. All of these requirements may be defined in a Request for Proposal, a System Specification, a Statement of Work, or some other type of requirements document. Finally, these requirements must be available to the system integrators/designers for analysis and subsequent design of the system. 2.2 DETERMINE SYSTEM FUNCTIONS/SERVICES When designing a system, the first step beyond this classic high level view of a system is to determine what functions must be performed, as defined by the requirements for the system. A function is a "series of related activities, involving one or more entities, performed for the direct, or indirect, purpose of fulfilling one or more missions or objectives. It should be identifiable and definable, but may or may not be measurable." A function may be composed of one or more subfunctions. [2] Subfunctions perform a portion of the overall task assigned to the function. Each function selected for the system should be internally cohesive in that it performs a single task and requires little interaction with other functions in the system. [5] Another objective in determining the functions is to minimize coupling between the functions to make them as independent as possible. [4] Of course, no system can exist without some coupling to preserve the cohesiveness of the system as a whole. By definition, a function that is not bypassable becomes primitive within an architecture. That function's implemented security policy will be invoked between each domain that it invokes. Unintentional or intentional emergent behavior can be created when integrating functions which detract from the cohesiveness of the system functionality. Some examples of high level functions that may be determined for a system are data base management, man-machine interface (MMI), communications, or mail. In trusted systems, MAC, Discretionary Access Control (DAC), Audit, and Identification and Authentication (I&A) are all possible functions to be defined. The definition of any or all of these functions is determined by the set of requirements for the system. There are security requirements that are not normally characterized as functions. Examples of these are domain isolation, integrity, and trusted path. However, if a system or product has a trusted path available to the user for example, some mechanism (e.g., "function") must provide this capability. 2.3 DEFINE FUNCTIONS/SERVICES INTERDEPENDENCIES The next step toward designing a system is to determine the coupling that has to exist between functions. This coupling forms interdependencies between the functions or services. An example of this interdependency at a high level is a mail function that may be dependent on the MMI to "deliver" the mail to a user's terminal. Of the security functions, applications may be dependent on the TCB to perform security functions. Additionally, the I&A function may need the MMI to allow the user to input his/her logon identification sequences. Finally, the MAC and DAC functions depends on an I&A function to authenticate and provide the correct information for the user. 2.4 SPECIFY DEPENDENCY LATTICE Once all of the functions have been defined and the interdependencies have been determined, a dependency lattice can be described. Figure 1 illustrates a dependency lattice for generic functions. This lattice defines those functions that are dependent on other functions, as well as those functions that are independent. 2.5 DEFINE PRODUCTS AND PLATFORM Finally, the independent functions are used to determine, from the products available, those products that will best meet the requirements of the system. This is done by comparing the functions required by the system with the functionality provided by all the available products. When a close match is determined, a product can be selected. Sometimes dependent functions have to be rearranged to better fit the products that are available. There is never a perfect match between the requirements for a system defined into functions and the specifics of a single product or a group of products. The products will either not collectively contain a needed dependent function, will contain functions that are not requirements for the system, or will contain redundant functions among the group of products. Once the best correlation between all the functions or services and available software products is made, then the physical requirements are taken into account. These physical requirements include performance, reliability, interfaces, and other requirements [5] which further constrain the choice of available software products, and thus determine the platform (e.g., hardware) for the system. Again, there is never a perfect map between the software products selected, the system's physical requirements, and the platforms available even when the platform is selected at the end of the process. However, selecting the platform prior to determining the software products that will satisfy the system requirements increases the differences between the map of the platform and the products and physical requirements. 3 TRUSTED SYSTEM DESIGN APPROACH The approach to the design of trusted systems using evaluated products must be taken a step further than the approach described above. When designing trusted systems, the security functionality of each individual product may not satisfy all of the security requirements of a system. For instance, one product may have a compliant I&A (e.g., with an automatic password generator), while another product may have a compliant audit mechanism (e.g., with all of the reporting capabilities for the audit log). However, the security functionality of all of the products together may present a redundant surplus of security functionality. Redundant security functionality is especially important to deal with when there are conflicts between the security functions of the various products to be used for the system. A possible example of a conflict is the case of object reuse functions in a system in which one product clears objects before releasing the object to the user, and the other product in the system clears the object after the user has released the object. In this case, the potential exists for the user to receive, under the right circumstances, an object that has not been cleared by either product; or the user may suffer performance degradation when the object is cleared by both. In this case, a unified object reuse policy for the system would need to be established. 3.1 EVALUATED PRODUCTS LIST (EPL) PRODUCT DETER- MINATION An evaluated product is selected much as any other product would be selected, based on a set of functions that the product must satisfy. As stated above, when a function and its dependent functions are compared to a product, there are almost always requirements that are not satisfied by the product. Additionally, there is functionality in the product that is not included in the list of requirements for the system as a whole. This surplus may lead to conflict between products when each attempts to satisfy the same single requirement in a system with a cohesive policy. An example of this conflict is a single processor system that has requirements translating into a need for an evaluated operating system and a trusted application, (e.g., mail). The operating system will probably contain I&A, DAC, and audit capabilities. The application may also have I&A, DAC, and audit capability. In all other aspects, the two products are a perfect match for the system requirements. However, in this case, there is a redundancy of security functionality. The application is not an operating system and the operating system can not perform the non-security capabilities required of the application. Therefore, neither of the products individually satisfies both the security and non-security requirements of the system. If two products with a reference monitor are included in a system, one of the reference monitors is going to be bypassed at some time during operation of the system. The redundant features issue can be decomposed into security policies and mechanisms to implement the policy. If both the policy and the mechanism are identical, as in the case of a homogeneous network environment with a single policy in which the workstation and server both use the same evaluated operating system, then there might be user resistance (e.g., to a double logon). If the same intended policy is implemented with different mechanisms, as in the case of a heterogeneous network environment in which two different operating systems are used with different labeling schemes, then there exists a conflict between the two mechanisms. The label conflict may be resolved by a conversion function developed as an extension to the TCBs of either or both of the products. Additionally, if the policy is different but the same mechanism is used, a policy conflict exists even in a homogeneous workstation and server environment with the same operating system containing the same DAC mechanism. The workstation may be using different "Group" definitions and Access Control Lists (ACLs) than the server. This conflict would violate one of the policies without the knowledge of the violated processor. Finally, if both the policy and the mechanism are different, a heterogeneous network environment in which the label policy and the labeling mechanism are both different, then conflicts that might not be able to be resolved may exist. In this case, something fundamental in the policy or the mechanism would have to be changed. The simple conversion of the label format would not suffice to integrate these two systems. 3.2 PRODUCT CONFLICT RESOLUTION It is not efficient to have differing DAC or audit schemes when designing a cohesive system. This is not to state that redundancy can not, in some circumstances, strengthen the security of a system, provided that it is user friendly and not counter to human intuition. However, there is always a concern for consistency of the global security policy of the system where redundancy is involved. It is not advantageous to incorporate two I&A mechanisms into a single secure operational system, without at least some dominance of one over the other. (Most systems today require a limiting of a single logon for a user session.) Each of the redundant security functions may need to be modified or disabled in one of the products (through extensions to the product TCB, switches, configuration options, if possible; or TCB code modifications, if necessary) in order that the system may have a single I&A, DAC, or audit. This is done by modifying, adapting, or eliminating one or the other product to disable or limit the function. Then the other product, in which the function is not disabled or limited, must be changed to interface with the product in which the function has been disabled or limited. The process of modifying or adapting an evaluated product by limiting functionality has ramifications to the evaluation of the modified product. It may invalidate the EPL rating of the product, if not done with review, justification and understanding. The integration of multiple evaluated products may stay within the bounds of the assumed parameters as stated in the individual product's evaluation report, or the integration effort may violate those bounds. If necessary, it is the responsibility of the system integrators/designers to compensate for any invalidation of the product rating using system-level, as opposed to product-level, assurance. This will be discussed later in this paper. The product vendor is always the best choice to make modifications to products. The vendor may make a business decision on the marketability of changes required for a system acquisition. If the modification can be productized, the vendor will insert the change into the standard product and perhaps take the modification through the Rating Maintenance Program (RAMP) frequently with no charge to the acquisition. This is the most advantageous course of action. The spectrum from the above (vendor made changes) down to the integrator performing the changes without any vendor support are possible scenarios. The average contract design, integration, and/or development strategy will lie somewhere along this spectrum. 3.3 ARCHITECTURE RELIES ON EXTERNAL DEPENDEN- CIES Frequently, there are external dependencies which affect the architecture of a trusted system which would not affect the architecture of an untrusted system. An example of this is a system that receives labeled input. This system receives the labeled input directly into the processing stream for all data. Since the input is labeled at the source of the data outside of the system boundary, the integrity of the label must be assumed to be trusted as far as the system is concerned. (Mechanisms are available to ensure this to be true.) Therefore, the MAC performed using this label is solidly based. However, if the data received by the same system architecture is not labeled and is at multiple classification levels, then the system does not have a basis for MAC. The architecture could be changed to include some sort of labeling entity prior to the unlabeled data entering the mainstream of the system. Depending on the requirements of the system, this could be a human on a terminal reviewing and labeling all data; it could be a front-end component labeling all data from a single level device; or, it could be an operating system labeling all data from a single level port. For this example, it does not matter what the architectural change would be, just that the overall system architecture must accommodate the differences between labeled and unlabeled input. 3.4 TRUSTED COMPUTING BASE (TCB) DEFINITION Once the products are selected and the architecture is defined, the TCB for the system must be established. Under the premise of this report, the system would be designed using COTS components (both trusted and non-trusted products). A single system TCB would, in this case, be defined using the product TCBs as the basis and satisfying the reference monitor assumptions and the system security policy. This is done by examining the various TCBs of the products, identifying the mechanisms and interfaces that will remain for the resulting system, and analyzing what additional mechanisms and interfaces may be necessary for the system. 3.4.1 Product Analysis As stated previously, there is never a perfect match between requirements, functions, and products. If functionality is lacking in all of the products selected, then the integration process must include the development of that functionality or the inclusion of a non-trusted component to handle the functionality. Occasionally during a tradeoff analysis, a non-automated solution (e.g., a locked room) is determined to be the preferable manner to address any missing functionality. However, the more likely occurrence, when a collection of evaluated products are combined, is redundant security functionality. An analysis must be made to determine which security features will be used in each product. This analysis must be carried a step further for evaluated products. An additional analysis must be made to determine how the security characteristics of each individual component may affect the composite characteristics of the system, and what the resulting effect will be to the overall product and system when a product's security feature is not used, either disabled or limited. It is important that this analysis be performed in the early stages of a program to inform the program management of the correct integration options, even if the demonstration/proof of the satisfaction of the requirements of the TCSEC by the modified system is required for the integrated system. To rely on the later assurance proof for this analysis will inform the program, after delivery, that the system has already been integrated/developed incorrectly. At that point, the information is not beneficial to the program. 3.4.2 System Interface Analysis Beyond the analysis of the product and the selection of which product features to use and not use, a system analysis must be performed to identify the interfaces that will be needed within the system TCB. This analysis includes the system interfaces that will occur between the products without modification, or as the manufacturer delivered it. (Again, the use of the code of products as they are delivered by the manufacturer is the preferable manner in which to use a product.) Additionally, the analysis must take into account the interfaces which are newly created when the products are modified to eliminate certain features, or add a system capability. A desirable result of any trusted system integration is to minimize the overall system TCB while minimizing the impact on the product TCBs composing the system TCB. Using evaluated products, each will contain a TCB. When all of the product TCBs (as well as the new TCB functions developed for the integration effort) are taken into account for the system, the resulting overall TCB will be a certain value. To eliminate a portion of a product's TCB is to diminish the size of the overall system TCB by the complexity and value of the portion of the product TCB that is eliminated. This serves to minimize the overall system TCB by the value of the excluded portions of all the products' TCBs. However, this minimization action must be accomplished with care. Eliminating parts of a component TCB may increase your risk because of internal dependencies within the product. Additionally, it may increase program cost because the impact of removing the portion of the product TCB must be determined. Tradeoffs and compromises must be made. 3.4.3 Application Audit Example Figure 2 is a pictorial description of the audit function of a trusted application. The application could be anything trusted, a trusted mail application, a trusted Database Management System, etc. This particular audit function has a security administration subfunction which sets the criteria on which auditing will occur. The criteria are placed in a database. The next subfunction is the audit interface in the TCB which detects a criteria match. When a match is detected, the event recorder subfunction records the event using the user ID, success/fail criteria, event data, and time which are held for the application in a database, table, or global common, depending on the implementation. The event recorder writes the audit record to the application's audit log. There is also a real time subfunction which checks thresholds and responds to the matching of these thresholds. An example of this functionality is a limit of three attempts to logon using a single user ID. On the fourth attempt, the real time subfunction may lock a user out of the system. There are also several administrative subfunctions dealing with the application's audit log. The data reduction subfunction handles the queries and responses to the audit log. The administrative subfunction allows an administrator to archive and purge the audit log. 3.4.4 Example for An Integrated System To carry on with this example, the following is a single approach to use this product in an integrated system. (This approach is not the only approach that can be used, neither is it meant to be a procedural description of composing systems.) The product has been selected to perform whatever application it does. In this example, the product will be used in a distributed architecture which has a requirement for centralized administration of the auditing capability and a centralized system audit log. This is not to imply that an application's audit log must be deactivated if there is a system audit log. Figure 3 illustrates the system with centralized audit administration and storage. The application described in the previous subsection is in the figure as the lightly shaded large box. In order to achieve centralized administration, an audit management subfunction must be developed that sets the criteria for the entire system. A portion of this subfunction must be written to interface with the security administration subfunction of the application. To have the application's event recorder subfunction write the audit records to the system audit log instead of the application's audit log, a common interface must be written between the event recorder subfunction and the system audit log. Assuming that there is more than one application in the system which produces audit records, the common interface subfunction would translate all of the application audit record formats and data packing schemes to a single system audit record format. Additionally, the interface between the application event recorder subfunction and the application's audit log must be severed. As can be seen from Figure 3, there are two new subfunctions in this system view, the audit management and the common interface. These subfunctions are denoted in the boxes without shading. There are also three new interfaces. In the figure, these interfaces are denoted by the heavy arrow lines. There is a new interface between the new system audit management subfunction and the application security administration subfunction. There is another new interface between the application event recorder and the new common interface subfunction. And, finally, there is a new interface between the new common interface subfunction and the system audit log. Since all of the audit records are now being processed into the system audit log, the application's audit log is no longer used. Therefore, the interface between the application event recorder subfunction and the application's audit log is severed. This is designated in the figure with a heavy "X". Finally, since the application's audit log is no longer used, the three subfunctions that support the application's audit log are also no longer needed. These three subfunctions (data reduction, real time, and administrative) and the application's audit log are all designated in the heavily shaded boxes. 4 TRUSTED SYSTEM ASSURANCE The use of evaluated products is an extremely good starting point for the certification and accreditation efforts of systems. However, the combination of evaluated products, with the resulting changes to the products as described above, may invalidate the rating of the product when the changes are performed without the proper review and understanding. The assurances developed at the system level during the integration process must compensate for any invalidation of the product rating. The TCSEC is the standard used to develop the assurance of products. The TCSEC defines the assurance documentation required for a TCB. The design documentation requirements are a subset of the overall documentation described in the TCSEC. The TCSEC requires that "If the TCB is composed of distinct modules, the interfaces between these modules shall be described." [1] This is true for all classes defined in the TCSEC above the Minimal Protection Division (D). Additionally, the TCSEC requires that "The specific TCB protection mechanisms shall be identified..." [1] This is a requirement for all classes in the Mandatory Protection Division (B) and Verified Protection Division (A). Of course, there are additional assurance documentation requirements that include: a security policy model, a Philosophy of Protection, a Descriptive Top Level Specification, a Formal Top Level Specification, a covert channel analysis, a TCB verification report, a Configuration Management Plan, administrator and user manuals, and testing documentation. The modification, adaptation, or elimination of product TCB functionality (mechanisms and interfaces) has a ripple effect through all of the assurance documentation for the system. Security testing, as well as other activities such as architecture, recovery, and verification, are also required as assurance mechanisms. Security testing of the combined evaluated products demonstrates that the modified mechanisms and interfaces perform as intended and that the overall level of protection has not been diminished. Finally, this testing will serve to validate the completeness of the system level documentation. Security testing of the system, as with all assurance activities, is performed to support a certification and accreditation, and not an evaluation, of the system. All the engineering efforts to assure a system are documented (e.g., security testing is reflected in the test plan, procedures, and report required by the TCSEC for testing). Therefore, the remainder of this paper uses the term "documentation" to refer to all of the assurance documents required by the TCSEC for evaluation. Included in the use of the term "documentation" are all the activities (e.g., testing, design engineering, covert channel analysis) that are performed in order to produce these assurance documents. 4.1 PRODUCT ASSURANCE DOCUMENTATION In order for a product to be evaluated, TCSEC documentation requirements have to be satisfied. But what happens to this product assurance documentation when the product is modified for use in a system? Most of the product documentation should still be valid. If the product changes so much that a total rewrite of the documentation is needed, then perhaps the product is not really a match for the requirements of the system, and another product should be selected. 4.2 SYSTEM ASSURANCE DOCUMENTATION Assuming that most of the product is going to be utilized as evaluated in the system, and that most of the product's documentation is therefore valid, the few modifications, adaptations, and eliminations made to the product must be documented. When composing evaluated products into trusted systems, new subfunctions may be needed to couple products, new interfaces are included to these new subfunctions, some of the mechanism of the original product may be disabled, and original interfaces may be excluded. These four types of modifications break down into two categories: TCB interfaces and mechanisms. The modifications are the two sides of each of these categories: eliminated and new TCB interfaces; and eliminated and new mechanisms. The existing evaluation version of the product documentation should describe all interfaces and protection mechanisms to include both the original interfaces and mechanisms that have been eliminated during the integration of the system. The system level documentation should describe the effect that the elimination of the mechanisms and interfaces of the evaluated product has on the system TCB as a whole. The previous paragraph covers the elimination of original interfaces and mechanisms of the evaluated product used in the system. The addition of new mechanisms and the resulting additional interfaces to the combined product TCBs for the system must also be documented in the system-level assurance documentation. These mechanisms and interfaces are not described in any of the product-level documentation since they are probably either not available in any of the individual products, or were not required to perform in the product as they are in the system. There are options to the system integrator/developer when the modification of product documentation is done. The vendor may develop the code modifications and document those modifications. Or, the integrator may buy the code and documentation, and then modify each as required. Between these two ends of the spectrum are a range of options to both the program and the integrator. 4.3 SYSTEM DOCUMENTATION STANDARDS AND ANALY- SIS The Data Item Descriptions (DIDs) which have been developed for the series "A Guide to Procurement of Trusted Systems, Volume 3," were written to be applied to products [3]. However, they require the definition of the TCB interfaces and the identification of the TCB protection mechanisms. In the procurement of trusted systems, these DIDs are applicable for system-level assurance documentation. The orientation (e.g., system-level, product-level) of the DID must be expanded outside the framework of the DID. The Statement of Work (SOW) or the Contract Data Requirements List (CDRL) calling out the DID should include statements for the system-level orientation of the resulting assurance documentation. These SOW or CDRL statements should require the examination of the interfaces and mechanisms between products and the analysis of the elimination of interfaces and mechanisms. A real challenge in the replacement of invalidated product-level documentation is the analysis of the validity of the system-level assurance documentation. The certifier validates the assurance documentation for the system and certifies that the system meets certain requirements. However, it is ultimately left to the accreditor of the system to determine the validity of the assurance documentation for the system and give the permission for the system to operate. There is no other body willing to assess the validity of system-level assurance documentation at this time. 5 CONCLUSION In conclusion, this paper has presented a single approach to the composition of evaluated products into trusted systems. These evaluated products can be combined into trusted systems with assurance. The system-level assurances must compensate for any invalidation of the individual products' ratings. The system-level assurance must document the same types of information that the product-level assurance has documented, i.e. interfaces and mechanisms. The only difference is that excluded and eliminated product mechanisms and interfaces must also be assessed in the system- level documentation. When procuring these systems, the SOW or CDRL should include direction to the integrator to examine the new interfaces and mechanisms between the products and assess the elimination of interfaces and mechanisms. BIBLIOGRAPHY [1] Department of Defense, "Trusted Computer System Evaluation Criteria" (TCSEC), DoD 5200.28-STD, December 1985. [2] Modell, Martin E., A Professional's Guide to Systems Anal- ysis, McGraw-Hill Software Engineering Series, McGraw-Hill Book Company, New York, 1988. [3] NCSC-TG-024, Version 1 Volume 1/4, "A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements," December 1992 Volume 2/4, "A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work - An Aid to Procurement Initiators," June 30, 1993 Volume 3/4, "A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Descriptions Tutorial," February 28, 1994 Volume 4/4, "A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document - An Aid to Procurement Initiators and Contractors," (Draft) [4] Page-Jones, Meilir, The Practical Guide to Structured Sys- tems Design, Yourdon Press, Englewood Cliffs, New Jersey, 1988. [5] Pressman, Roger S., Software Engineering, A Practitioner's Approach, McGraw-Hill Series in Software Engineering and Tech- nology, McGraw-Hill Book Company, New York, 1987.