Library No. 5-235,465
Version 1
The Trusted Network Interpretation Environments Guideline is a companion to the Trusted Network Interpretation of the. Trusted Computer System Evaluation Criteria (NCSC-TG~O5), published 31 July 1987. The Trusted Network Interpretation Environments Guideline provides insight into the issues relevant when integrating, operating, and maintaining trusted computer networks. This document identifies the minimum security protection required in different network environments such that network certifiers, integrators, and accreditors can determine what protection mechanisms and assurances are minimally required in specific network environments.
This document parallels Computer Security Requirements - Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments (CDC-STD~O3-85) and its technical rationale (CSC STD~0485). It also provides a descriptive presentation of the security issues that exist in networked computer systems as the networked computer system environment is inherently more complex and requires additional protection considerations over stand-alone computer systems.
As the Director, National Computer Security Center, I invite you suggestions for revising this document. We plan to review this document as the need arises.
PATRICK R. GALLAGHER JR. 1 August 1990
Director
National Computer Security Center
Special thanks are extended to the many members of the computer security community who enthusiastically gave their time and expertise in reviewing the material and providing valuable comments and suggested changes. Special thanks are extended to James P. Anderson of James P. Anderson Co., Donald L. Brinkley of Gemini Computers, Inc., Dr. Eric Roskos of The Institute for Defense Analysis, Dr. Tien Tao of Gemini Computers, Inc., and Dr. John M. Vasak of The MITRE Corporation for their extensive suggestions and recommendations.
For sale by the Superintendent of Documents, U.S. Government
Printing Office Washington DC 20402
The TNI [3] satisfies the first objective by interpreting the TCSEC for networks. The TNI also provides guidance for selecting and specifying other security services (e.g., communications integrity, denial of service, transmission security). The TNIEG is the first step toward addressing the second objective.
This guideline is not a tutorial on security and networking; it is assumed that the reader will have some background in both areas. Suggested background references are identified in Appendix B. This guideline is designed to be self contained; a fair amount of background information that can be found in the TNI is also included here. The interested reader may consult the TNI and other documents referenced in this guideline for further detail.
2~e distinction between a system and a subsystem is a matter of the viewpoint of the observer. One observer's system may be another observer's subsystem. For example, the vendor of a local area network may regard his product as a system, while the customer's network architect may consider it to be a subsystem along with hosts, workstations, etc.
~e THI uses component in the definition of NTCB Partition. We use subsystem to be consistent in this document.
Appendix C of the TNI uses component, as follows, where we would use subsystem:
Certification is conducted in support of the accreditation decision. For most systems, the hardware, system software, applications software, communications equipment, and the operational facility must be configured and tested during certification. Certification should be performed by technical personnel independent of the development organization, according to an acceptable methodology. Certification should identify the level of security protection with regard to a procedure, program, or system. Certification results in the issuance of the Certification Statement, which states whether system security requirements are met, describes all known remaining vulnerabilities, and advises the Accreditor relative to the accreditation decision. If requirements are no met, the Certification Statement lists problem areas and identifies suggested solutions (if known). A certification documentation package, called the Certification Report of Findings, submitted to the Accreditor includes the Certification Statement, certification analysis, results of Security Test and Evaluation, id results of Operational Test and Evaluation.
All AIS must be accredited before they may process or use sensitive or classified information, unless a written waiver is granted by the Accreditor. Accreditation is based on a technical investigation and a formal review of the certification Report of Findings. Before authorizing an AIS to operate, the Accreditor must ensure that satisfactory security measures have been installed and that any residual risk is within acceptable limits. Often, the Accreditor must weigh the technical shortcomings of an AIS against operational necessity. Lacking other ways to accomplish an operational mission, the Accreditor may determine that it is preferable to accept a residual security risk than to preclude the mission. To ensure that the accreditation goals and objectives are adequately met, the Accreditor must be involved throughout the system life cycle.
5 As mentioned in the introduction and the definitions, this TNIEG differs from DODD 5200.28 and the TNI in the usage of AIS and the definition of component. This quotation has been slightly edited to conform to the usage in this guideline. she content of a Memorandum of Agreement is discussed in Section 3.2
The security policy includes the set of laws, rules, and practices that govern how an organization manages, protects, and distributes sensitive information (including classified information). The overall security policy is addressed in a family of related documents consisting of a system security policy, a security policy model, and security requirements. The system security policy is developed first, followed by the other two. A system security policy interprets and applies regulations to systems. The security policy model defines subjects and objects and the accesses between the two. The security requirements document identifies valuable user requirements for a secure system.
The security architecture is that part of the system architecture that describes the required security services and features. The security architecture shows how the required level of assurance for the system is to be met. A mapping of security requirements to functional elements is documented in the security architecture; therefore, the security architecture is used to document security design decisions.
An NTCB implementation need not include all protocol layers. The precise security services and their granularity will depend on the highest protocol layer at which an NTCB partition is implemented.7 For example, in a Unified Network where layer 3 (the network layer) is the highest layer that implements the NTCB, the network will be able to enforce mandatory access control (MAC) and discretionary access control (DAC) decisions on the granularity of network addresses8. The network system being evaluated knows only about the range of classifications that the host (or other network) is permitted to handle and the hosts (or other networks) that are permitted to communicate with each other. Finer distinctions must be made by the hosts (or other networks) involved. When a trusted network provides all seven layers, the network is aware of and enforces MAC and DAC at the granularity of individual users.
A network device might not provide a complete set of end-user services through layer 7. Products that do not provide all system services through layer 7 may be NCSC-evaluated as components and subsequently used with other components to compose a network.
7 Since the publication of the TNI, the policy environment has changed. "User", as defined in DODD 5200.28, ad peer.entity, as defined in the 051 reference model, are comparable. Therefore, the TNIEG applies to all layers of the 051 architecture.
8 A network address refers to either a host or another network.
The NSAD, produced as part of the risk management process, documents the security services. As mentioned in Section 1, the primary focus of this TNIEG is on the AIS aspects of security. Depending on the particular environment, communications security (COMSEC), emanations security (TEMPEST), physical security, personnel security, administrative security, and other information security (INFOSEC) measures or safeguards are also incorporated in the NSAD. An NSAD results from a series of trade-offs among cost, effectiveness, technical risk, mission requirements, and risk management.
While the architecture part of the NSAD may be somewhat abstract, the design part should be quite concrete. The design maps the selected security services to system functional elements9. Next, these functional elements are assigned to components and subsystems.
___________________
9 Sections 4 and 5 of this document should guide the security manager in selecting those security services and safeguards that are appropriate for the given operational environment.
A typical network configuration will include multiple vendor's products. When the network is created, the security manager must reconcile the diverse NSADs of the constituents into a coherent NSAD for the configured network and identify any restrictions or new security services and assurance that must be added. The NSAD must implement national, service, and command policies for the environment in which the network will operate. The same process applies when previously accredited AIS are to be interconnected to support the exchange of information.
In contrast to the networks described above, when a network is created from scratch, the NSAD may be established before any devices are selected and may be included as part of the criteria for selecting the network devices.
Note that the network may include components that are not security-relevant and, therefore, do not have a component NSAD. The design decisions that result in the inclusion of non-security-relevant components are documented in the NSAD.
AIS may be combined into a network under conditions of a hierarchical relationship of their security managers. In this case the NSAD of the subordinate system must conform to the governing NSAD. For example, when a host computer connects to a common user network, the host computer must conform to the NSAD established by the security manager of the common user network, who has a responsibility to the security managers of all other connected AIS to maintain the network's trustworthiness. As discussed below, this conformance is recorded in a Memorandum of Agreement (MOA).
AIS whose security managers are not hierarchically related may also be combined to form a network. In this case, the security managers come to agreement on the NSAD for the network; this agreement is also recorded in an MOA.
10 In this guideline, NOA is used to identify the agreement between Accreditors and includes the NOR.
The procedure for determining the minimum security requirements for a network parallels the procedure for a stand-alone system, whereby the highest classification of data and the lowest clearance among system users are used in computing a risk index. The risk index is used to determine which NCSC evaluation rating is required of the system to provide adequate security. To emphasize, these are the minimum requirements. The TCSEC Environments Guideline does not address environmental factors such as the number of users and the percentage of users at different classification levels. These factors may become more significant in a network environment. Communications security risk in a network is addressed by the National Security Agency (NSA) and other cognizant organizations and results in a set of recommendations for the appropriate equipment or security procedures. Other factors, such as the number of connections, the physical distance between devices, the number of subsystems, the presence of encryption, and the possible presence of intervening systems between the resources being used and the ultimate user may result in more or less stringent requirements.
The literature on risk management is quite extensive. It is not the;Purpose of this document to survey the field. The interested reader is referred to FIPS PUB 65 [11]. The literature is constantly growing; a recent high-level introduction to general concepts and terminology can be found in Bell [12] and in the Proceedings of the First Invitational Workshop on Computer Security Risk Management [13].
DODD 5200.28 Enclosure (4) mandates the use of a methodology, extracted from the TCSEC Environments Guideline, to determine the recommended evaluation class(or requirements of an evaluation class) based on a specific environment. Enclosure (5) of the Directive also recommends this method to determine minimum computer-based requirements in a network. This guideline also uses that method. Use of a different method requires prior approval of the Assistant Secretary of Defense (ASD) Command, Control, Communications, and Intelligence (C31).
DODD 5200.28 Enclosure (4) contains six major steps in the risk assessment procedure. These steps are listed below. DODD 5200.28 Enclosure (4) applies in all steps.
Step 1. Determine system security mode of operation.
Step 2. Determine minimum user clearance or authorization rating.
Step 3. Determine maximum data sensitivity rating.
Step 4. Determine risk index.
Step 5. Determine minimum security evaluation class for computer-based controls.
Step 6. Determine adjustments to computer security evaluation class required.
An elaboration of step six given in Migues [14], involving a detailed analysis of both environmental and architectural risk factors, is based on Landwehr and Lubbes[15]. It presents a method which incorporates analysis of the applications environment. This analysis includes such factors as whether the system allows programming, or whether it is restricted to a limited set of applications. This more detailed information supports a finer determination of the level of trust required.
must determine the following:
11 Tables 1 and 2 are adapted from DODD 5200.28 (enclosure 4).
Table 1: Rating Scale for Minimum User Clearance (Rmin)
------------------------------------
Minimum User Clearance Rmin
Uncleared OR Not 0
Authorized (U)
Not Cleared but
Authorized Access to 1
Sensitive Classified
Information
Confidential (C) 2
Secret(S) 3
Top Secret (TS) and/or
current Background 4
Investigation (BI)
TS and/or current
Special Background 5
Investigation (SBI)
One Category (IC) 6
Multiple Categories 7
(MC)
------------------------------------
The number derived from Table 1 is used for Rmin; the one derived from Table 2 is used for Rmax. A risk index for the network is calculated using the following formula:Risk Index = Rmax - Rmin
Table 2: Rating Scale for Maximum Data Sensitivity(Rmax)
----------------------------------------------------------------
Maximum Rating Maximum Data Rating
Sensitivity (Rmax) with categories1,2 (Rmax)
Ratings
without
categories
Unclassi- 0 N/A 3
fied (U)
Not
Classified 1 N with one or more 2
but Categories
Sensitive
N4
Confiden- 2 C with one or more Cate- 3
tial C ories
S with one or more
Secret(S) 3 Categories only one 4
Category containing S
S with two or more 5
Categories containing S
TS with one or more
Top Secret 5 5 Categories only one 6
(TS) Category containing S or
TS 7
TS with two or more
Categories containing S
or TS
----------------------------------------------------------------
1 Where the number of categories is large or where a highly sensitive category is involved, a higher rating might be warranted.2 The only categories of concern are those for which some users are not authorized access. When counting the number of categories, count all categories regardless of the sensitivity level associated with the data. If a category is associated with more than one sensitivity level, it is only counted at the highest level. Systems in which all data are in the same category are treated as without categories.
3 Unclassified data by definition may not contain categories.
4 Examples of N data include financial, proprietary, privacy, and mission sensitive data. In some situations (e.g., those involving extremely large financial sums or critical mission-sensitive data), a higher rating may be warranted. This table prescribes minimum ratings.
5 The rating increment between the Secret and Top Secret data sensitivity levels is greater than the increment between other adjacent levels. This difference derives from the fact that the loss of Top Secret data causes EXCEPTIONALLY GRAVE damage to U.S. national security, whereas the loss of Secret data causes SERIOUS damage.
Table 3: Security Risk Index
------------------------------------------------------------------------
Risk Security Mode Minimum Security Class4
Index
0 Dedicated 5 No Minimum Class 1 2
0 System High C22
1 Multilevel Partitioned B13
2 Multilevel Partitioned B2
3 Multilevel B3
4 Multilevel A1
5 Multilevel *
6 Multilevel *
7 Multilevel *
------------------------------------------------------------------------
1 Although there is no prescribed minimum class, the integrity and denial of service requirements of many systems warrant at least class C2 protection.2 Automated markings on output must not be relied on to be accurate unless at least class B1 is used.
3 Where an AIS handles classified or compartmented data and some users do not have at least a Confidential clearance, or when there are more than two types of compartmented information being handled, at least a class B2 is required.
4 The asterisk (*) indicates that computer protection for environments with that risk index is considered to be beyond the state of current computer security technology.
5 Most embedded systems and desk top computers operate in the dedicated mode.
Table 3 12 is used, along with the Risk Index calculated above, to determine a minimum NCSC-evaluation rating for the system. Note that some terms that appear in the TCSEC Environments Guideline are no longer defined in DODD 5200.28. (Limited Access Mode, and Compartmented Mode fall under the heading of Partitioned Mode. Controlled Mode comes under the heading Multilevel. The prevt.ou:°sly used terms referred to the equivalent of the BI and B2 evaluation classes. In DODD 5200.28, Partitioned Mode is used in place of Compartmented Mode.)
____________________
12 Table 3 is adapted from the TCSEC Environments Guideline
Part II of the TNI focuses on those threats that occur between end systems (hosts) on the network. These security services include protection against compromise, denial of service, and unauthorized modification. In discussing these services, the TNI borrows heavily from the International Standards Organization (150) 051 Basic Reference Model [9] and Security Architecture [16]. The services discussed are closely related to those found in the latter reference. The TNI goes beyond the 051 Security Architecture in several respects. First, the 051 document does not address the relative strengths of different mechanisms nor the assurances that they operate as intended. Second, the protection against denial of service threats is not specifically addressed by 051 but is an important consideration in the TNI.
It is important to recognize that many Part II security services depend on (embedded) AIS. These AIS should be evaluated using Part I and Appendix A of the TNI. Encryption systems, for example, are highly dependent upon AIS; they are addressed in Appendix B of the TNI and Appendix C of this guideline. Appendix C presents some considerations concerned with applying Tables 1, 2, and 3 to encryption systems.
For security services that do not depend strongly on A!S, a qualitative evaluation approach is used. For functionality, a question and answer format is presented in Section 5.4.3. For strength of mechanism and assurance, the concept of a risk index is used in Sections 5.4.1 and 5.4.2.
Table 4: Evaluation Structure for Network Security Services
-------------------------------------------------------------
Network Security Criterion Evaluation
Service
Communications Functionality None present
Integrity Strength None - good
Authentication Assurance None - good
Communications Field Functionality None - good
Integrity Strength None - good
Assurance None - good
Non-repudiation Functionality None present
Strength None - good
Assurance None - good
Denial of Service Functionality None - good
Continuity of Operations Strength None - good
Assurance None - good
Protocol Based Functionality None - good
Protection Strength None - good
Assurance None - good
Network Management Functionality None present
Strength None - good
Assurance None - good
Compromise Protection Functionality None present
Data Confidentiality Strength Sensitivity level
Assurance None - good
Traffic Flow Confidenti Functionality None present
ality Strength Sensitivity level
Assurance None - good
Selective Routing Functionality None present
Strength None - good
Assurance None - good
-------------------------------------------------------------
Once the functionality has been determined, the strength of mechanism and appropriate level of assurance must be determined. The process is similar to the determination of Part I risk in Section 4 of this guideline. Since the strength of mechanism and assurance determination do not differ for the various services, these topics are addressed first.
For inadvertent threats, traditional risk management techniques are used. While some countermeasures may be the same for inadvertent and malicious threats, others may be effective only against the former. The security manager must determine the likelihood of a particular threat, the dollar cost of a countermeasure, and the residual risk if the countermeasure is put into effect. The manager concerned with these inadvertent threats is referred to the references on risk assessment previously cited.
For malicious threats, we consider the most sensitive information contained on the system and the lowest clearance of user who can gain physical access to some device in the system, including access to wireless transmissions. Some devices in the system may be physically protected in buildings that require a clearance for admittance. Other devices in the system, such as long-haul transmission lines, may have no physical protection.
Protection of the information in the network system is a combination of physical, administrative, procedural, and technical protections. The TNIl is concerned only with the AIS hardware, firmware, software, and configuration management protections. Various service or agency regulations describe methods for implementing the other protections.
The various devices in the system must be considered separately; for each device, the risk index will be based on the most sensitive information on the network system and the minimum clearance to gain physical access to the device. Note that this is different from the Part I risk index calculation (where the lowest cleared user is of concern). For some devices in the system (e.g., the communications media), the clearance of individuals with physical access may be lower than that for authorized users. For convenience, all the necessary tables are included here. Table 5, Minimum Clearance for Physical Access, is identical to Table 1. For each device in the system, the lowest clearance of individuals with physical access to that device is used. Table 6 for Maximum Data Sensitivity is identical to Table 2.
Table 5: Minimum Clearance for Physical Access -------------------------------- Minimum Use Clearance Rmin Uncleared OR Not 0 Authorized (U) Not Cleared but Authorized Access to 1 SensitiveUnclassified Information (N) Confidential (C) 2 Secret (S) 3 Top Secret (TS) and/or 4 current Background Investigation (BI) TS and/or current 5 Special Background Investigation (SBI) One Category (IC) 6 Multiple `Categories 7 (MC) --------------------------------
Table 6: Maximum Data Sensitivity
---------------------------------------------------------------
Maximum Maximum Data
SensitivityRatings Rating Sensitivity with Rating
without categories (Rmax) Categories1, 2 (Rmax)
Unclassified(U) 0 N/A 3
Not Classified but 1 N with one or more 2
Sensitive (N)4 Categories
Confidential (C) 2 C with one or more Cate- 3
ories
Secret(S) 3 S with two or more 4
Categories only one
Category containing S 5
S with two or more
Categories containing S
Top Secret (TS) 55 TS with one or more 6
Categories only one Cate-
gory containing S or TS 7
TS with two or more
Categories
---------------------------------------------------------------
1 Where the number of categories is large or where a highly sensitive category is involved, a higher rating might be warranted.2 The only categories of concern are those for which some users are not authorized access. When counting the number of categories, count all categories regardless of the sensitivity level associated with the data. If a category is associated with more than one sensitivity level, it is only counted at the highest level. Systems in which all data are in the same category are treated as without categories.
3 Unclassified data by definition may not contain categories.
4 Examples of N data include financial, proprietary, privacy, and mission-sensitive data. In some situations (e.g., those involving extremely large financial sums or critical mission-sensitive data), a higher rating may be warranted. This table prescribes minimum ratings.
5 The rating increment between the Secret and Top Secret data sensitivity levels is greater than the increment between other adjacent levels. This difference derives from the fact that the loss of Top Secret data causes EXCEPTIONALLY GRAVE damage to U.S. national security, whereas the loss of Secret data causes SERIOUS damage.
Table 7 now gives the strength of mechanism requirement based on the risk index calculated as
Risk Index = Rmax - Rmin
Table 7: Minimum Strength of Mechanism Requirement
------------------------
Risk Index Strength of
Mechanism
O None
1 Minimum
2 Fair
>2 Good
------------------------
One salient property of trusted systems is the reliance on a TCB. Similarly, trusted network systems rely on an NTCB. In addition to its other responsibilities, the NTCB prevents unauthorized modification to objects within the network system. In particular, the NTCB maintains the integrity of the programs which provide security services, thus ensuring that their assurance is continued. The NTCB provides an execution environment that is extremely valuable in enhancing the assurance of security services. Discretionary and mandatory access controls can be employed to segregate unrelated services. Thus, service implementation that is complex and error-prone or obtained from an unevaluated supplier can be prevented from degrading the assurance of other services implemented in the same device. Furthermore, an NTCB ensures that the basic protection of the security and integrity information entrusted to the network is not diluted by various supporting security services.
The relationship of the risk index to the required assurance is expressed in Table 8.
Table 8: Minimum Assurance Requirements
----------------------
Risk Index Part II
Assurance
Rating
0 None
1 Minimum
2 Fair
>2 Good
----------------------
Assurance of the design and implementation of Part II mechanisms is also related to the assurance requirements in Part I because service integrity depends on protection by the NTCB or TCBs. Table 9 expresses this dependency. The second column identifies the minimum Part I evaluation which supports the Part II assurance requirement. Note that Table 9 is applicable only to those Part II services not strongly dependent on A!S; the AIS implementing those services can be directly evaluated under Part I and Appendix A of the TNI.Note that the Evaluation Class calculation in Part I will not necessarily be the same as the Minimum Part I Evaluation in Table 9. This is because the Rmin for Part II may be different from that of Part I! since the Part II! protections are oriented towards outsiders (those with physical access) rather than towards users. Depending on the particular environment, either the Part I! requirement or the Part II requirement may dominate. The latter would be the case if a system were operated in the system high mode-where all users were cleared to see the most sensitive information-but the network was exposed to lower clearance individuals.
Authentication
Table 9: Part II Assurance Rating ----------------------------------- Part II Minimum Assurance Part I Rating Evaluation Minimum C1 Fair C2 Good B2 -----------------------------------If no, skip to Communications Field Integrity.
Interconnecting systems that support different security domains (e.g., classified, sensitive unclassified) adds additional complexity. Exchange of information among these different security domains requires identification of the markings and protection given to information when transmitted to another domain. For example, several evolving approaches to the protection of sensitive unclassified information [17] consider "that sensitive information is not part of the same hierarchy as classified information".
There are technical criteria for judging the trustworthiness of Interconnected Accredited AIS: an Interconnection Rule, which ensures that information conveyed between subsystems is labeled properly, and risk factors such as propagation of local risk and the cascading problem. These criteria are examined in some detail below.
___________
The range must be a single level in the case of a system high or dedicated device14. If the accreditation range comprises more than a single level, the system is trusted to reliably segregate data by level within its accreditation range, and label it accurately for transmission over multilevel interfaces. The accreditation range will be specified in the MOA. The accreditation range is used in determining whether communication between systems is permitted.
Figure 1
Information Levels and Accreditation Ranges
N/A TS
S-C S
N/A C
C2 Evaluation Class B3
S Accreditation Range TS-C
SH Operating Mode MLS
As shown in Figure 1, an AIS may contain information at levels that are below its accreditation range. For example, a C2 host which contsuns Secret (S) and Confidential (C) information, is not trusted to segregate this confidential and Secret information. Therefore, it is accredited to operate in system high (SH) mode at Secret (the highest sensitivity level of information on the system), and its accreditation range is the single level Secret. All exported information must be labeled with the system high sensitivity label until there is a manual review to assign the information a lower
Figure 2
Accreditation Ranges of Two Interconnected Sub systems
Subsystem X Subsystem Y
N/A TS
S S
C C
Class B1 Class B3
In a network, an accreditation range bounds the sensitivity levels of information that may be sent (exported) to or received (imported) from each interconnected subsystem15. For example, if a network consists of only dedicated and system high subsystems, each subsystem will be assigned single-valued accreditation ranges (i.e., an accreditation range consisting of one sensitivity level).
When the same communications channel processes information at different levels, the data must be labeled through some protocol agreed upon by the communicating systems.
______________
Although a 1/0 device is part of a subsystem, it may be designated to process a more restricted set of sensitivity levels than the accreditation rage of the subsystem as a whole. This leads to the concept of a device range. Each 1/0 device in a subsystem that is used to communicate with other subsystems in the network must have a device rage. The device rage may be single level, or it may be a set of levels (in which case the device is referred to as multilevel), and it must be included within the subsystem accreditation range. The TCSEC states that "systems that have been evaluated at classes B2 ad above must support minimum ad maximum security labels for all multilevel 1/0 devices". The purpose of device labels is to document the constraints placed on the security levels of information authorized for the devices.
Each physically attached multilevel system (if any) has a minimum ad maximum sensitivity level associated with it. A B1 or higher system interconnected to a second system must ensure that both imported and exported information is contained within appropriate sensitivity levels. Information Transfer Restrictions
The following points summarize the discussion on the restrictions imposed on information transfer between interconnected devices.
Information exported or imported using a single-level device is labeled implicitly by the security level of the device. As shown in Figure 3, any information transferred between the single-level (S) devices on Subsystems X and Y is implicitly labeled S.
Figure 3
Implicit Labeling
Subsystem X Subsystem Y
Information exported from one multilevel device and imported at another multilevel device must be labeled through an agreed-upon protocol, unless it is labeled implicitly by using a communications link that always carries a single level. For instance, in Figure 4, Secret and Confidential information may be transferred between the multilevel devices.
Figure 4
Protocol Labeling
Subsystem X Subsystem Y
Figure5
Compatibility Labeling
Subsystem X Subsystem Y
Information exported at a given security level can be sent only to a importing device whose device rage contains that level or a higher level. In Figure 5,Subsystem X is allowed to export only Secret information to Subsystem Y's multilevel device. Subsystem Y is allowed to export Secret ad Confidential information to Subsystem X, because the device rage Subsystem X is TS-S. If the importing device rage dominates the exported level, the information is implicitly or explicitly relabeled upon receipt at a higher level within the importing device range.
Figure 6
Relabeling
Subsystem X Subsystem Y
In Figure 6, Subsystem Y relabels information imported from Subsystem X. The information transfer restrictions also permit one-way communication (i.e., no acknowledgments) from one device to another whose rages have no level in common, as long as each level in the sending device rage is dominated by some level in the receiving device rage. It is never permitted to send information at a given level to a device whose rage does not contain a dominating level.
In most interconnected subsystems, the bidirectional flow of information is permitted. In this environment, the sensitivity level of any transmitted message must be within the accreditation range of both the sending and receiving systems. In some networks, an additional restriction on information flow may be unidirectional communications. This restriction may enhance security. The following discussions refer to Figure 7.
Figure 7
Bidirectional and Unidirectional Information Flow
Subsystem X Subsystem Y
TS (C or U) C
SH (TS) Subsystem Z (C) MLS (C-U)
TS
S
C
MLS (TS-C)
The system high mode is usually assigned to A!S that are unevaluated or are NCSC evaluated in class C. These AIS do not employ explicit labels because they cannot be trusted to differentiate between sensitivity levels. All information within these AIS is implicitly labeled. When exported on a single level channel, by default the information is labeled implicitly by the level of the channel. Human-readable output must be labeled at the system high level; it may be manually downgraded by an authorized reviewer.
Explicit labels are required on a multilevel channel. In order to export explicit labels, Subsystem X would normally be expected to be NCSC-evaluated at BI or above or employ an 1/0 device, such as those shown in Figure 6, NCSC evaluated at BI or above. Also, Subsystem X or the 1/0 device should be used as specified in Section 4 of this guideline. Lacking such NCSC evaluation, the MOA between the Accreditors would have to specifically address these labels.
Subsystem X can import a message from Subsystem Y, but cannot acknowledge receipt of that message, because an exported acknowledgment (labeled TS) cannot be imported by Subsystem Y, which can only receive C or U information. Transmitting an acknowledgment from Subsystem X to Subsystem Y would constitute a write-down (i.e., writing information at a lower sensitivity level-generally a security violation.)
Subsystems Y and Z can exchange information at C since this level is in the accreditation range of each subsystem. When only unidirectional communication (no acknowledgment) is utilized between two subsystems, write up is permitted if each sensitivity level in the source subsystem is dominated by a sensitivity level in the destination subsystem. The receiving subsystem must change the sensitivity level of the message when the message is received. For instance, U information sent from Subsystem Y will be labeled C by Subsystem Z.
According to the Interconnection Rule, a multilevel network may contain devices with different operating modes: dedicated, system high, partitioned, and multilevel. Also the devices may differ in the sensitivity levels and categories which they process, and the formal access approvals of their users (some users may not have access to all information).
Figure 7 illustrates the flexibility of the Interconnection Rule. For example, the Interconnection Rule will allow, with certain restrictions, a multilevel subsystem to communicate with a single-level subsystem and with another multilevel subsystem (and the two MLS subsystems may have different accreditation ranges). It also allows for one-way communication to a higher-level system. It is intended to be a non-restricting rule and yet ensure that each system receives only information that it can properly mark and handle. Interconnection in the context of the Interconnection Rule means only direct connections, that is, without any intermediate accredited subsystem.
The Interconnection Rule alone does not guarantee that classified information will not be exposed to greater risks in a network than in a stand-alone environment. One problem in networks that is dealt with at some length below is the cascading problem.
Figure 8
A Complex Interconnection
TS: P,A TS: Q,C
Subsystem X Subsystem Y
As discussed in the previous section, any subsystem that is connected to other subsystems must enforce the Interconnection Rule. Using the subsystem connection view, each subsystem responsible for maintaining the separation of multiple levels of information must decide locally whether or not information can be sent or received. This view, then, does not require a subsystem to know the accreditation ranges of all the subsystems on the network; only of those with which it can communicate without an intermediary.
The Interconnection Rule applies to communication between any two (or more) accredited systems. However, even when the Interconnection Rule is followed, there may be other potential security problems that will require the implementation of additional constraints on the network. In order to address these problems, it is necessary to adopt a global view of the network. This view requires a knowledge of the accreditation ranges of all the subsystems in the network. That is, it is no longer determinable locally whether or not a constraint is being satisfied. These accreditation ranges are taken into account when determining whether or not a subsystem should be allowed to connect to the network. In this way, the potential damage that can occur when information is compromised or modified can be limited to an acceptable level.
Two global concerns are discussed below. One concern is the propagation of local risk; the other is the cascading problem.
In the special case of a common user network such as DDN, it may be necessary to provide communications capabilities among systems that do not conform to the security requirements established by the network Accreditor (i.e., a system meeting no security requirements may be connected to a network.) One common way to provide network service to these non-conforming systems while still protecting the other, conforming, systems would be to segregate the non-conforming systems into closed communities that could not directly communicate with conforming systems. This approach is discussed in detail in the Defense Data Network Security Architecture [18].
The cascading problem results from the observation that subsystems may be connected in such a way that the network covers a larger sensitivity level range than the individual systems are accredited to handle. Depending on the actual topology of the interconnection and the characteristics of the installations, the amount of effort required for an attacker to take advantage of residual vulnerabilities may be less than what is required for the network sensitivity range.
To see how this is possible, consider two systems, each of which is accredited to handle two adjacent classifications of information, as shown in Figure 9. Subsystem A processes Secret and Top Secret information, and all users are cleared to at least the Secret level. Subsystem B processes Confidential and Secret information, and all users are cleared to at least the Confidential level.
The network as a whole has three levels of information. However, the leakage resistance of the network is only that offered by two systems qualified for only two levels. To make Top Secret information available to Confidential users, an attacker might attempt to:
Figure 9
Cascading Problem
Subsystem A
TS Subsystem B
S S
C
The question is, whether subverting two systems qualified for two levels of information is as hard as defeating one system qualified for three levels of information. In some cases it might be. Lee [19] gives an argument that if two systems have probabilistically independent flaw sources, "...the resistance to threat of a cascade of two B2 systems is approximately the same as, or even better than, that of a B3 system."
But Lee also remarks that demonstrating effective independence of flaw sources m a practical case is not easy, and that two systems may have the same or equivalent flaws, particularly if their TCBs are the same, or are separate implementations of a single flawed design. Exploitation of the flaws on two or more systems does present additional resistance to the attacker, but it should be kept in mind that physical access to all interconnected systems is not necessary to send untrusted software to them, as our experience with viruses shows unmistakably.
Whichever test for cascading is employed, its result is to focus attention on certain subsystems and their network connections that might potentially be subject to a cascading threat. The next step is to determine whether the systems involved are actually vulnerable to the multiple coordinated attack that is necessary for cascading, ad, if so, to consider countermeasures.
Another solution is to use a more trusted subsystem at appropriate nodes in the network, so that an attacker will be forced to overcome a protection mechanism commensurate with the seriousness of the potential compromise. In Figure 9, for example, if either subsystem A or subsystem B is NCSC-evaluated at class B3, which is sufficient according to Table 3 in Section 4 of this guideline for a range of Top Secret to Confidential, then the attacker is presented with an acceptable level of difficulty.
A cascading threat can also be interdicted by eliminating certain network connections, to break paths by which an attacker could compromise information with insufficient resistance. This solution is practical only when the links to be eliminated are not needed for operational reasons. Sometimes end-to-end encryption can be used to address a cascading threat while preserving necessary connectivity, by reducing the level of information available to intermediate systems on a communication path.
A.l Nesting Condition
The nesting condition is evaluated solely on the basis of the accreditation ranges of the subsystems. In the form given both here and in the TNI, it is applicable only when all sensitivity levels are totally ordered - that is, if they can be placed in order such that each one is higher than the one before it. This is true, in particular, if they are pure classifications, with no categories or compartments.
The nesting condition is satisfied, by definition, if the accreditation ranges of each pair of subsystems are either disjoint or nested. A pair of accreditation ranges is disjoint if they have no levels in common. They are nested if one range is included (as a subset) in the other. All possible pairs (not just those of adjacent subsystems) must be considered, but some pairs may be nested while others are disjoint.
If the nesting condition is satisfied, there is no cascading problem. Because the nesting condition does not take into account which network subsystems are actually connected to one another, it can sometimes give a pessimistic result, i.e., there are cases when the nesting condition fails, but there is actually no cascading problem.
Figure A-I
Accreditation Ranges of Two Interconnected Sub systems
Subsystem Y
Subsystem X TS
S S
C C
Class B1 Class B3
Example 1: Consider the situation illustrated in Figure A-I. The accreditation range of Subsystem X is nested within that of Subsystem Y (i.e., C-S is completely contained within C-TS). Therefore, the nesting condition is satisfied, and there is no cascading problem.
Figure A-2
Cascading Problem
Subsystem A
TS Subsystem B
S S
C
Example 2: Consider the situation illustrated in Figure A-2. The accreditation ranges of Subsystem A and Subsystem B are not disjoint; neither is one completely contained within the other. Therefore, the nesting condition fails, ad a cascading problem is possible. Note, however, that the nesting condition would still fail even if the two subsystems were not connected to one another, yet in that case there would be, no cascading problem.
The situation is more complex when sensitivity levels are drawn from a partially ordered set, so that the accreditation ranges of some subsystems have sensitivity levels that are incomparable. Two sensitivity levels are incomparable when neither is greater than or equal to the other. Sensitivity levels with category sets are, in general, incomparable. An extended form of the nesting condition has been devised that applies to partially ordered sensitivity level sets. [20]
A.2 Other Approaches
Appendix C of the TNI contains two other criteria for the cascading problem: the cascade condition, which is a mathematical characterization of the problem, and a heuristic procedure. These criteria have been superseded by improved methods since the publication of the TNI. The new approach is described in a separate report, in order to give adequate scope to the presentation of background and context necessary to apply it appropriately.
The need for a new approach arose from a recognition of the limitations of the existing criteria. The cascade condition is accurate but it is not, in itself, a computational procedure. It is limited by its assumption that all of the interconnected subsystems have been given evaluation classes. The heuristic procedure is believed to provide a conservative approximate test for cascading, but only when applied to interconnections in which all communication paths are two-way, i.e., capable of both sending and receiving. A simpler procedure is now available.
C.1 Use of Encryption
As indicated in the TN!, an encryption mechanism is evaluated differently than other mechanisms. Evaluating encryption mechanisms has a long history predating the TNI. Evaluation of an encryption mechanism is part of COMSEC. Generally, encryption mechanisms receive a rating of the highest level of classified information which may be protected using that mechanism. Therefore, the only rating applicable to an encryption mechanism is the classification level of the information that is to be protected. This classification level also establishes the requirement.
In general, organizations using the TNI and this document select their encryption mechanisms from a list provided by an organization which is responsible for evaluating such mechanisms. In many cases, that organization is the NSA.
A more complicated situation exists when encryption is employed above the Link Protocol Layer, layer 2. At layers 3 and 4 the protocols are concerned with the end systems or intermediate devices (e.g., hosts, network switches) that the links connect. Higher layers are concerned with other peer entities. Traditionally, encryption applied above layer 2 has been termed end-to-end encryption, or E3.
An E3 system may be provided as (part of) an NTCB. When the E3 system is integral to the NTCB, the use of the E3 system requires evaluation under the TCSEC with interpretations in the TNI. The evaluation must consider (1) the accreditation rage of the user interface, (2) the risk index for the bypass in the E3 device, and (3) the risk index between the highest sensitivity data ad the lowest clearance of user on the network.
Depending on the design, devices of an E3system may satisfy all requirements for a system evaluated under Part! of the TN!. MAC may be provided either explicitly or implicitly. Explicit MAC is provided if the packets sent by the encryption device include a security label. Implicit MAC is provided if the security level must be inferred from the encryption key used to protect the data. All data protected by that key must be classified at a single security level.
DAC is often provided in an E3 system as well. Typically, keys for exchanging data are provided to the E3 devices only after DAC has been applied. The encryption devices can provide identification ad authentication. While identification is generally done explicitly (by transmitting an identifier), authentication can be done implicitly (i.e., by the use of a unique key). The encryption devices may perform certain types of auditing as well. Typically, a device collects information and forwards it to another device for storage. Information collected may include: connections established, connections refused, packets with inappropriate labels, and misrouted packets. The granularity provided by these E3 mechanisms is determined by the protocol layer at which the service is offered.
Figure C-1
Typical Interconnected AIS
Host LAN Gateway WAN Gateway LAN Host
AIS 1 AIS 2 AIS 3 AIS 4 AIS 5 AIS 6 AIS 7
In a typical network there will be a number of A!S. For example, two hosts are often attached to separate local networks connected by a wide area network (WAN). As shown in Figure C-1, the path between the hosts (without E3) may involve 7 separate interconnected AIS.
E3 can help reduce the number of A!S. By placing E3 devices between each host and the LAN to which it is connected ad incorporating suitable key distribution components, the LANs and WAN collapse into a single network system and the path now traverses only three AIS, as shown in Figure C-2. A!S 2 provides security services to the hosts, therefore, it may be part of the NTCB.
Figure C-2
Using End-to-End Encryption to Reduce Number of AIS
Host E3 LAN Gateway WAN Gateway LAN E3 Host
AIS 1 AIS 2 AIS 3
There may be a hierarchy of trusted system views. For example, E3 may be provided at protocol layers 3,4, and 7. Depending on the architecture, the layers of E3 could constitute a single NTCB or each could be a separate NTCB. In the latter case, the devices supporting different layers would be part of different AIS and the interconnection rules would be applied between higher and lower protocol layers.
In general, an A!S at a higher protocol layer encompasses more devices than one at a lower protocol layer. The granularity of services offered is also finer at the higher protocol layer.
In a situation where the higher protocol layer encryption system also has a higher evaluation class, the lower protocol layers might be considered less trusted just as current E3 designs treat the subnetwork as untrusted. Continuing the analogy, just as certain physical security requirements are imposed on the untrusted subnetwork, the higher protocol layer encryption might rely on characteristics of the lower protocol layers.
However, one may be faced with a dilemma that the higher protocol layer E3 system has a lower security evaluation than the lower-protocol-layer trusted system. For example, a WAN with E3 at layer 3 might be evaluated Al. The system might also provide E3 at layer 4, but an NTCB that includes layer 4 might. only be rated B2. In this case, treating the subsystems constituting the separate layers as separate AIS and using the Interconnection Rule to accredit the network as a whole could prove advantageous, as illustrated in Figure C-3.
Figure C-3
Separate Layers Treated as Separate AIS
B2 B2
(N-C) (N-C)
A1
0SI Layer 3 Network
(N-TS)
B2 B2
(S-TS) (S-TS)
C.2 Encryption Mechanisms
In a trusted AIS, the recommended evaluation class is determined using a risk index based on the highest data classification and the lowest user clearance. In considering an E3 subsystem in a network, three separate indexes must be considered [21]: