|
USE OF THE TRUSTED COMPUTER SYSTEM
EVALUATION CRITERIA(TCSEC) FOR
COMPLEX, EVOLVING, MULTIPOLICY
SYSTEMS
NCSC TECHNICAL REPORT-002
Library No. S-241,321
July 1994
FOREWORD
This Technical Report "Use of the Trusted Computer System Evaluation
Criteria (TCSEC) for Complex,
Evolving, Multipolicy Systems," though addressing a more general
problem, and not written in the form
of an interpretation, is written in the spirit of the "Trusted Database
Management System Interpretation
(TDI) of The Trusted Computer System Evaluation Criteria." This approach
can be used in conjunction
with TDI developed systems or in the cases where the TDI does not apply.
The document is intended to
be used as a basis update to, NCSC-TG-024, Version 1, Volume 2/4, "A
Guide to Procurement of Trusted
Systems: Language for RFP Specifications and Statements of Work - An Aid
to Procurement Initiators."
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 Howard L. Johnson of Information Intelligence
Sciences, Inc., supported
and revised by U.S. Army Major Melvin L. DeVilbiss. Besides many NSA organizations,
the document
was reviewed by Department of the Army (ASIS), DISA, Grumman, MITRE, and
NAVELEXSECSEN.
TABLE OF CONTENTS
FOREWORD
ACKNOWLEDGEMENTS
1. Introduction
1.1 Purpose
1.2 Today's Operational Systems
1.3 Security Policy
1.3.1 Regulatory Security Policy
1.3.2 Operational Security Policy
1.4 The TCSEC, TNI, and TDI
2. Proposed Approach
2.1 Domains of Constant Policy (DOCPs)
2.1.1 Mechanisms
2.1.2 Kinds of Isolation
2.1.3 Phased Build
2.1.4 Levels of Assurance
2.1.5 Policy Iteration
2.2 Interface Policy
2.2.1 Communications Responsibility - Sending
2.2.2 Communications Responsibility - Receiving
2.2.3 Exposed Risk
2.2.4 Mutual Suspicion
2.3 Global Policy
2.3.1 Shared Mechanisms
2.3.2 Discretionary Access Control
2.3.3 Identification/Authentication
2.3.4 Audit
2.3.5 Security Administrator
2.3.6 Recovery
2.3.7 Global Noncompliance
3. Risk Management
3.1 Propagated Risk Assessment
3.2 Policy Iteration
3.3 Protection Assessment
3.4 Design Iteration
4. Summary
Bibliography
Acronyms
Glossary
LIST OF FIGURES
Figure 1. Relationship of Policy to TCB
Figure 2. The Primitive Property
Figure 3. Domains of Constant Policy
Figure 4. Mechanisms Associated with a DOCP
Figure 5. Policy Iteration
Figure 6. Design Iteration
1 INTRODUCTION
NSA recently published "Design and Evaluation of INFOSEC Systems:
The Computer Security
Contribution to the Composition Discussion" [1]. It discusses how
the TNI [2] and the TDI [3]
complement the TCSEC [4] and provide powerful tools for extensibility
to INFOSEC systems. The
problem addressed "for both designers and evaluators, is how to approach
a complex system such that
the elements derived from the high-level system objectives (in the TCSEC
context) enforce the security
policy and that they can be shown to compose those objectives."
This paper addresses a different problem (though often it is mistaken
as the same). The audience
addressed here includes procurement initiators, certification evaluators,
and Designated Approving
Authorities (DAAs). The objective is to deal with existing, evolving systems,
where the individual
elements support security policies but do not in general support high-level
system objectives. This paper
details how to develop a set of high-level system objectives and to retrofit
system elements in a cost/risk
effective manner to allow continued secure evolution, accreditation, and
secure mission support.
Today there exists a tremendous investment in evolving Department of
Defense (DoD) command and
control systems made up of intercommunicating entities. Many of these
systems were developed without
a precisely defined set of system level security objectives or security
preserving interface rules. Elements
are often heterogeneous in the security policies supported, the degree
of assurance provided, and the
inherent trust present. Often cascading security risk has not been considered.
Only classification data
policies have been supported at the interfaces. Most importantly, these
systems support highly sensitive
and critical U.S. missions on a daily basis.
We endorse and support the goals and concepts of [1] in its context.
It is believed, however, that new
goals and concepts are needed to deal with the current "evolving
system acquisition problem."
1.1 PURPOSE
The purpose of this paper is to provide a methodology to assist the heads
of DoD components to procure,
certify, and accredit existing, evolving, multipolicy systems against
the TCSEC [4] requirements,
consistent with the guidance provided in the TNI [2] and the TDI [3].
This methodology must come to
grips with the problems that exist in current operational command and
control systems. The intended
audience is anyone concerned with any aspect of these objectives.
A more immediate goal, once these ideas have been finalized, is to develop
a STRAWMAN follow-on
version of Volume 2 of the Procurement Guideline Series "Language
for RFP Specifications and
Statements of Work - An Aid to Procurement Initiators [5]," but it
will apply to complex systems. This
will provide a way to extend the guideline's application from the procurement
of Evaluated Products List
(EPL) [6] products (or the equivalent) to procurement of integrated systems,
encouraging maximum use
of EPL products in the system development/evolution.
1.2 TODAY'S OPERATIONAL SYSTEMS
Operational systems continue to be developed for the military, adding
custom built elements onto
existing systems. Some elements still in use were developed in the 70s.
The TCSEC [4], first published in
1983, was used selectively on a few experimental developments in the early
80s. The TCSEC [4] was not
made a DoD standard until 1985 and was slow to be adopted into policies
and directives of the individual
services. Part of the reason was lack of guidance on adaptation to complex
connected systems of the type
being implemented. This void was partially filled by the publication of
the TNI [2] in mid 1987, the
update to DoDD 5200.28 [7] in 1988, and availability of "The Trusted
Network Interpretation
Environments Guideline [8]," in late 1990. Practical experience was
gained in several pilot projects.
Today, guidance is still lacking on exactly how the TCSEC [4], used primarily
for products, can be
adapted to evolving, built-to-specification systems. Problems exist in
downgrade, cascading risk, and
contractual compromise; not to mention the unavailability of trained expertise
for testing and evaluation.
The result is a wide variation in trust and security, perpetuated by continued
misconceptions about the
adequacy of existing protection and the nature of potential threat.
The following is a list of problems that can be encountered in operational
environments and represents
problems that must be solved. Components of existing/evolving systems:
Seldom are on the Evaluated Products List (EPL) [6] - Although this will
change in the future, existing
operational systems often do not use NSA evaluated products.
Often have different policies - System components evaluated during certification
against different
Orange Book division/class requirements, different security modes, or
different operational policies are
often linked together in complex systems by busses and networks.
Have been built with conflicting regulatory policies - Rigor was employed
to make the TCSEC [4]
internally consistent. The TNI [2] and TDI [3] have also been written
with this goal in mind. The basic
DoD set of three documents (5200.28 directive [7], manual [9], and standard
[4]) are also consistent, for the
most part. However, existing systems have employed additional directives
from each of the individual
services and agencies. These documents can lag DoD documents because of
lengthy update cycles or they
can lead DoD documents based on preemptive need. (Sometimes internal service
policy will be
developed hoping that it will be subsequently adopted by the DoD.)
Have varying degrees of trust and assurance - Some system components
have been operating since the
70's, others received initial accreditation before the TCSEC [4] became
a requirement, some used the
TCSEC [4] requirements, and a few use Evaluated Products List (EPL) [6]
trusted technologies.
Recertifications and reaccreditations often list many deficiencies, but
with the risks accepted by DAAs
(feeling the pressures of high corrective costs and operational immediacy).
Generally do not consider cascading risk - Until publication of the TNI
[2], cascading risk was not fully
understood or appreciated. DoDD 5200.28 [7] states that the DAA "should
be aware that connection to a
network may involve additional risks" and that the concern is only
with "connections to adjacent AISs."
This has given the DAA the flexibility to largely ignore cascading risk.
Only enforce "classification policy" at the interface - Policy
at interfaces normally includes more than
classifications and clearances. There are discretionary and category (compartment,
caveat)
considerations. The concept of least privilege and other privilege restrictions
(e.g., two man rule) must be
supported.
Do not have well stated, enforced global objectives - Connected trusted
components of existing
evolving systems support their individual assigned policies, but do not
in general support a global policy,
such as those addressed in the TNI [2] and TDI [3].
Are not always strictly reaccredited with each added element - Once an
element has undergone rigorous
certification evaluation, and has been used operationally, there is a
reluctance to subject it to another
recertification when elements are added to the connected system, even
though additional risk may have
been introduced.
Are often crucial to National defense - Especially in crisis situations
(e.g., the Gulf War) security is
considered a secondary objective and if there is any conflict with the
primary mission, the security of the
system may be sacrificed.
1.3 SECURITY POLICY
1.3.1 Regulatory Security Policy
In the controlled process of Computer Security (COMPUSEC) product evaluation,
the primary
requirements document is DoD 5200.28-STD [4]. In the operational DoD world,
two additional
documents are equally important: DoDD 5200.28 [7] and DoD 5200.28-M [9].
a. DoD Directive 5200.28, "Security Requirements for Automated
Information Systems (AISs)" [7] - This
Directive applies to all automated information systems processing classified,
sensitive unclassified, or
unclassified information. It specifies the applicability of DoD 5200.28-STD
[4]. It also specifies that
systems requiring at least controlled (C2) access based on the risk assessment
procedure (i.e., not all users
necessarily have the need-to-know for all information) must have been
upgraded by the end of 1992. This
directive identifies the relationships of other areas of security to COMPUSEC.
Enclosure 4 to DoDD
5200.28 [7] provides the risk assessment procedure to be carried out to
determine the operating mode and
division/class required to support the system's environment.
b. DoD 5200.28-M, "Automated Information System Security Manual"
(Draft) [9] - This manual
specifies automated information system (AIS) security roles and responsibilities.
It outlines the risk
management process: threat assessment, risk analysis, cost benefit analysis,
and the selection and
implementation of safeguards. Certification and accreditation requirements
are discussed. The
document discusses the relationship of Security Test and Evaluation to
other areas of testing. This
document also addresses provisions of the Computer Security Act of 1987,
not addressed in DoDD
5200.28 [7].
c. DoD 5200.28-STD, "DoD Trusted Computer System Evaluation Criteria"
[4] - This standard, referred
to as the "Orange Book," deals with confidentiality protection
for classified and sensitive data. It contains
a set of basic requirements and evaluation criteria for assessing the
effectiveness of security protection
features provided to an automated information system. It specifies the
discretionary and mandatory
security policies to be enforced and the rules for access control.
For each DoD organization, there are also regulations imposed by organization
or application specific
security documents as well.
1.3.2 Operational Security Policy
Operational security policy specifies the security critical aspects of
the system and the manner in which
the regulatory policy is to be satisfied. Operational security policy
specifies the tradeoff decisions made
by the DAA between COMPUSEC and other security methods of protection.
It involves a functional
allocation of the various security related tasks to the elements of the
system. It identifies security
clearance requirements for users of different system elements and isolates
classified and unclassified data
from other data within the system. It determines where users must access
multiple security levels in near
real-time.
The actual assignment of operational security policy is arbitrary in
the sense that there are usually many
ways to satisfy security requirements. Cost, performance, and risk tradeoffs
will help determine the
eventual way in which the system will be built and deployed. The operational
security policy may
change several times during development and even over the rest of the
system life-cycle.
1.4 THE TCSEC, TNI, AND TDI
Figure 1 provides a simple depiction of the relationship between policy,
component(s), and trusted
computing bases (TCBs, defined in the glossary). The TCSEC [4] addresses
a single TCB and pertains to a
single policy (i.e., division/class). However, throughout the TCSEC [4]
one finds system; computer
system; assembly of hardware, software and firmware. It is easy to interpret
the TCB as being within a
component or across components. Thus, the relationship in Figure 1 is
too simplistic to accurately portray
the ideas of the TCSEC [4].
The TDI [3], like the TCSEC [4], deals with TCBs. TCB subsets are defined
in the TDI [3] by a relationship
between them called "primitive." Figure 2 shows two less primitive
TCBs for which it is not possible to
verify the specification of either without a statement about the specification
of the more primitive TCB.
One could imagine, for example, constructing a single network TCB and
then attaching to it less primitive
nodal TCBs, satisfying the TCB subset requirements of the TDI [3], and
gaining the advantage of
evaluation by parts.
Partial order is a necessary condition for the structure of TCB subsets.
There are no examples in the TDI
[3] of multiple "more primitive" TCBs, nor is there anything
obvious that prevents the possibility.
Nothing appears to preclude different specifications from a subsetted
architecture from being drawn
from different division/classes, however, it is intuitive that as dependencies
of a higher division/class
less primitive subset become more complicated, that there is a greater
chance that the lower division/
class specifications of the more primitive subset will not meet the specifications
of the former. It still does
not invalidate this approach as a structure. It just means that the full
benefits of the evaluation-by-parts
approach cannot be realized.
Cascading risk occurs when a penetrator can take advantage of multiple
TCBs to compromise information
across a range of security levels that is greater than the accreditation
range of any of the TCBs he/she
must defeat to do so. Because different division/classes are not addressed
directly in the TDI [3], neither
is cascading risk.
The TNI [2] primarily addresses a single trusted system view, where a
single policy lies across
components and the single Network TCB (NTCB) can be partitioned across
some of those network
components. There is no requirement, or even expectation, that every component
have a partition, nor
that any partition comprise a complete TCB. Thus, the TNI [2] deals with
a single policy supported across
multiple components and a single TCB partitioned across multiple components.
The TNI [2] supports
evolving systems only to the extent that added components do not invalidate
the NTCB.
The TNI [2] acknowledges the existence of interconnected, accredited
AISs and states that "it may not be
practical to evaluate such a network using this interpretation or to assign
it a trusted system rating." The
TNI [2] Appendix C describes the rules for connecting separate accredited
AISs and the circumstances in
which these rules apply. Included in this description is a discussion
of operational security policy, though
not specifically stated as such, in the form of interconnection rules
and the cascading problem.
2 PROPOSED APPROACH
As was stated earlier, it is not designers and (product) evaluators to
whom this paper is directed. This
paper, and its concepts, is directed to procurement initiators, certification
evaluators, and DAAs. Further,
we are dealing with the difficult case where the system being considered
is an existing, evolving, multiple
policy system, is being dealt with.
Reference [1] strongly makes the point that:
Design and Analysis of Systems Proceeds from Policy to Mechanisms.
The TCSEC [4], the TNI [2], and the TDI [3] incorporate the Bell-La Padula
rules for implementing the
DoD security policy. The policy from which we begin here is the organization's
operational security
policy, which assumes the Bell-La Padula model and assigns the required
security variables to elements of
the system. A way to ensure a proper statement of the operational policy
is through Domains of Constant
Policy (DOCPs). In the rest of this section we will do the following:
o Define domains of constant policy in such a way that it addresses evolution,
multiple policy, and
shared risk in connected systems.
o Address interface policy required between intercommunicating DOCPs.
o Address global policy and its application to systems where global policy
has not previously been
concern.
The idea of domains of constant policy was presented in [10] as a way
to better test systems. It was
expanded in [11] to deal with requirements definition in a phased build.
2.1 DOMAINS OF CONSTANT POLICY (DOCPs)
The primary reason for defining DOCPs is to have an entity analogous
to a single policy system to which
a division/class of the TCSEC [4] applies. Thus, for each DOCP, our goal
is to identify or provide a set of
mechanisms and a level of assurance that would satisfy the prescribed
division/ class. If this is done
properly, certification evaluation can make the statement that the requirements
of the division/class have
been satisfied for this DOCP.
Simply defined, a DOCP is that part of a system to which a single, unique
operational security policy has
been defined. It follows then that DOCPs are nonoverlapping subsets of
the system, that, in combination,
completely cover the system, as shown in Figure 3. More rigorously defined,
a DOCP consists of a well-
defined boundary (where an isolation mechanism exists or can be employed)
and an n-tuple of policy
defining security characteristics. (The isolation is required to ensure
that communications is taking place
only over the known, designated channels.)
Each DOCP will have a TCB for support of its own security requirements,
however, some of the
mechanisms (e.g., audit) may be shared with another DOCP. The boundary
may be created by physical
isolation or logical isolation (e.g. supported by the TCB reference monitor,
defined by cryptographic
isolation, or use of guard isolation). The n-tuple that represents operational
policy can be simple
(clearance and classification levels) or complicated (with categories
and other parameters). For the
purposes of this document, the basic portion of the n-tuple will be values
of the parameters:
Minimum classification of data
Maximum classification of data
Minimum security clearance
Maximum security clearance
Categories (compartments/caveats)
Build status (existing, EPL [6] product, to be built)
Level of assurance achieved (EPL [6] evaluation at some level, certification
evaluation at some level,
none, other).
The derived portion of the n-tuple will be the values of the parameters:
Risk index
Exposed risk index due to cascading (discussed further in section 3)
Mode
TCSEC [4] division/class.
Some clarifying comments should be made at this point of the discussion:
o One possible policy is "no policy," e.g., no confidentiality
requirement, thereby requiring no trust
technology.
o This approach does not preclude using TNI [2] and TDI [3] approaches
in any way. It does, however,
deal with the cases in which they cannot be employed. In the case of an
NTCB, all policies are
incorporated into a single DOCP. In the case of the TDI [3], one DOCP
depends on the mechanisms of
another DOCP to satisfy its TCB requirements.
o A DOCP is a working entity in the sense that (as will be seen later)
tradeoff decisions concerning
policy, costs, and mechanisms may make it necessary to change the operational
policy and therefore the
DOCPs.
o No attempt has been made here to deal with integrity or denial of service
in this document, however
such an extension has been included in a straight forward manner elsewhere.
The reasons DOCP use is recommended as the conceptual approach in existing,
evolving systems
instead of TCBs (TCB subsets or peer entity TCBs) are as follows:
o It offers a more concrete definition and intuitive notion to procurement
administrators and DAAs.
o It enforces the statement of operational policy.
o Since the operational policy is defined by the using organization,
then so are the DOCPs.
o It enforces precise system covering boundary definition.
o It is not constrained to components.
o It allows, and in fact encourages, cost risk tradeoffs and iteration
of operational policy assignment.
o It allows application to the pre TCSEC [4], pre TNI [2] and/or pre
TDI [3] systems where the
definitions of TCB must be interpreted.
o It does not preclude, and in-fact supports, use of the NTCB or TCB
subsetting requirements of the
TNI [2] and TDI [3] respectively.
o It forces consideration of cascading, interface policy based on mutual
suspicion, and global
considerations, where in general no formal global policy has been enforced
or evaluated for the connected
system.
o It accommodates/promotes the use of EPL [6] products since the basic
building block entity of a
system (a DOCP) has a single policy represented by a division/class requirement
of the TCSEC [4].
o It addresses security interface requirements which must be satisfied
if an EPL [6] product component
is going to be integrated into the overall security of the AIS system,
which may in turn contain other EPL
[6] products, existing secure systems, or "to be custom built"
specifications.
The rest of this section will deal with some of the specific considerations
in the DOCP approach.
2.1.1 Mechanisms
The mechanisms associated with a DOCP are illustrated in Figure 4. They
correspond to what is required
by the TCSEC [4]. The asterisks on the figure identify mechanisms that
require global consideration.
There are times in which the mechanism that satisfies the requirements
of the domain of constant policy is
actually outside the domain. This is equivalent to the dependencies that
a less primitive TCB subset may
have, as stated in the TDI [3]. For example, users might be identified
in a different place or audit data may
actually be collected and analyzed outside the domain. These mechanisms
still must be assured to meet
the requirements of this particular DOCP. The concept of global mechanisms
will be discussed in Section
2.3.
2.1.2 Kinds of Isolation
Isolation, as referred to in the TCSEC [4], involves the responsibility
within the TCB to provide isolation
of separate domains under its control in response to the single security
policy which it must support. This
is usually done by the reference monitor, but other parts of the TCB also
play a role. In many current
implemented evolving multi-policy systems, the controls that represent
the single TCBs have been
individually certified, however, because no system level certifications
have been accomplished,
deficiencies exist at the data interfaces and in the policies that support
those interfaces. Here, we are
expanding beyond what is required of a single TCB to a more global consideration,
that is, the isolation of
individual Domains of Constant Policy from one another.
There are forms of isolation, other than logical, that exist in addition
to what is accomplished by the
reference monitor. They include electronic isolation, cryptographic isolation,
and guard enforced
isolation, each of which can be used effectively to separate DOCPs.
2.1.3 Phased Build
The "build" type and time are used as parameters in determining
DOCPs. Any part of the system that
exists and is being used in support of the operational mission has undergone
the scrutiny of the
certification/accreditation process (perhaps more than once) and has been
used in the operational
environment. Anything existing probably was built under a different set
of rules than the ones that
currently apply (TNI [2], TDI [3], and even in a few cases, TCSEC [4]).
The existing part of the system may
be further broken into several DOCPs because of policy differences.
An EPL [6] product is known to precisely follow the letter of the evaluated
division/class from the TCSEC
[4], and, if applicable, as interpreted by the TNI [2] or the TDI [3].
It will be assured to have the level of
trust accorded that division/class rating in a non-application environment.
The greatest difficulty is the
adaptation to a more specific set of operational policies, its connectivity
to other elements of the system,
and their mutual satisfaction of the set of required global policies.
Any portion of the system to be built or modified (including the modification
of an EPL [6] product)
carries with it the highest risk. There are many reasons for this, not
all of which apply to each specific
development situation. The portion to be built may be complex or may require
division into several
DOCPs, thereby introducing technical risk. Contractors often have many
requirements to satisfy, in
addition to security, that may dilute the contractor's ability to provide
security requirements with
sufficient emphasis. The security experience of the design team is often
not as great as it is in a continuing
product line, thereby introducing additional risk. The requirements and
guidance to the contractor for
special security requirements within an application are often not as succinct
as those provided by NSA in
DoD 5200.28-STD [4] for a product to be evaluated. In a custom development,
more cost risk exists
because it is a one-time expenditure. Overruns in the development of a
secure product can be amortized
over many copies.
Note that there may be a great difference in assurance provided between
existing systems, EPL [6]
products, and developmental systems. This is considered as a separate
factor in the next section. The
boundaries of build type and homogeneous assurance often coincide.
2.1.4 Levels of Assurance
Even though the same division/class functional requirements are used,
for any two parts of a given
system, there may still be a disparity between the quality and completeness
of assurance.
Factors include whether it is an approved EPL [6] product or a custom
component, development
configuration management, the qualifications of the people performing
assurance functions, the
environment of assurance, or the size and complexity of the system. One
approach to measure and
compensate for differences is to develop some criteria (e.g., figure-of-merit)
for assurance, consider the
figure-of-merit as a risk factor, and take action on those portions of
the system that have the highest risk
factors as funds become available. The action alternatives can be to shut
down and rebuild the system,
retest, upgrade and retest again, or change the operational policy that
is supported. The following is a list
of some of the measurement topics that can be employed in the figure-of-merit
determination, in addition
to what is stated in the TCSEC [4]:
o Point in time of development and evaluation with respect to publication
and acceptance of the
TCSEC [4], the TNI [2], the TDI [3] and other pertinent guidance documents.
o Time expended in assurance functions.
o Amount, quality, consistency, and completeness of evidence.
o Skill of team: academic, training, experience (EPL [6] product versus
one-time build).
o Development and usage environment.
o Resolution of problems discovered (exception handling).
o The degree/quality of configuration control.
2.1.5 Policy Iteration
There is a high functional dependency between mechanism cost, security
risk, and the functional
assignment of operational policy; and therefore the allocation of DOCPs.
There is normally an increase in
number of TCBs with more DOCPs. This means more mechanisms and a higher
security cost. However,
more DOCPs can more closely model involved operational policies and therefore
probably decrease the
risk of policy violation.
If policy is changed to combine what used to be two DOCPs by broadening
the policy range of each
DOCP onto one DOCP, there can be an accompanying cost savings. The broadened
policy range most
often is accompanied by a risk increase (as illustrated by the risk assessment
procedure in enclosure 4 of
DoDD 5200.28 [7]). This risk increase for a new acquisition might drive
the new single DOCP to support
a higher division/class, thereby potentially increasing costs. In other
cases, mutual boundaries can be
moved to decrease mechanism cost.
Stated another way, two connected DOCPs will each have a risk index less
than or equal to the risk index
of a DOCP formed by combining them (e.g., two system high DOCPs have less
than or equal risk than one
two level DOCP.) Increasing the number of DOCPs has the potential to decrease
the assessed risk, and
never to increase it. Remember, the statements above are made without
considering mechanisms.
The DAA must go through a cost/risk tradeoff and iteration procedure
until he/she finds the appropriate
operational policy (i.e., assignment of DOCPs) that best meet the needs
of his/her system.
These are not new ideas. A system high or dedicated security mode is
normally a combining of multiple
policies to decrease mechanism cost. Nevertheless, in so doing, operational
flexibility is decreased and
the risk to operational security is increased by potentially creating
a sizable downgrade problem.
2.2 INTERFACE POLICY
A system strictly designed and developed according to the subset TCB
concept defined by the TDI [3] or
the Network TCB concept of the TNI[2] need not consider additional interface
or global policy. However,
in situations where individual accredited entities have been connected,
both interface policy and global
policies must be supported. Interface policy will be discussed in this
section and global policy will be
discussed in Section 2.3.
In particular, there needs to be an explicit interface policy considered
between each DOCP and every
other DOCP with which it communicates. The interface policy can be thought
of as an augmentation to
the exportation policy of the TCSEC [4], however, in many cases, both
exportation and importation
concerns are expressed. The need for a trusted path to share and mediate
security variables also should
be assessed.
2.2.1 Communications Responsibility - Sending
In communications data, a DOCP must support intercommunication (exporting)
policies established by
its division/class.
A DOCP has two interface responsibilities: 1) it must ensure that data
it sends continues to be supported
by the policies imposed on it, and 2) it must appropriately handle data
it receives based on any policy
information known about that data.
External, intercommunicating domains of constant policy (physically interfacing
or not) are of two types:
virtual communication channels and trusted absorbing nodes. If the sending
DOCP somehow specifies a
destination other than a physically connected DOCP and the intermediate
DOCPs have the primary
responsibility of seeing that the data (and often its policy) proceeds
to its correct destination, the
intermediate DOCPs are virtual communication channels. It is up to the
sending DOCP to ensure that the
virtual communications channels and the destination can be trusted to
transfer the data according to its
policy.
A trusted absorbing node is a DOCP somewhere in the path to the destination
that can be trusted to
receive the data, properly interpret the policy, and incorporate the policy
for that data into its TCB. If this
is not the final destination of the data, the trusted absorbing node assumes
the security responsibility. An
intercommunicating DOCP may be considered both a virtual communications
channel and a trusted
absorbing node depending on the circumstances. Often the determination
is difficult. The most
conservative approach, if there is any question, is to treat the intermediate
node as a virtual
communication channel.
Policy must be established with the eventual data recipient or the first
intermediate trusted node. The
policy can be discretionary and or mandatory and includes categories (compartments,
caveats, need to
know). The responsibility for establishing the policy, linking it with
the data, and assuring proper
understanding by the receiver is that of the sender. Policy can be preestablished
based on data
identification through DOCP agreements, it can be communicated via labels,
or it can be communicated
and implemented manually by security administrators.
Sending DOCPs must be assured that data is being released into a system
that can be trusted to interpret
and carry out the policy. Factors to consider include the potential for
eavesdropping, spoofing, or policy
alteration.
2.2.2 Communications Responsibility - Receiving
Once data is in the possession of a trusted node or receiving DOCP, it
becomes the responsibility of that
DOCP's TCB to impose its knowledge of the policy on that data and treat
it accordingly. Suspected or
actual violations of interface policy must be treated as a special case
and the data must be protected.
2.2.3 Exposed Risk
A DOCP may not be affordably and certifiably able to support division/class
increases determined by
considering exposed risk. Special communications mechanisms or added protection
features within the
potentially receiving DOCP may help to ameliorate this situation. This
can provide an operational
solution that must be agreed to by the potentially sending DOCP. In any
case, the DAA from the sending
DOCP ultimately has responsibility for the decision.
2.2.4 Mutual Suspicion
A sending DOCP must establish interface policy consistent with the level
of trust it has established for
potentially receiving DOCPs. If the level of trust determined does not
coincide with the certification and/
or accreditation level given that DOCP, the sending DOCP should further
restrict the communication
policy, beyond that normally implied by the TCSEC [4] and its interpretations,
to a level where the
sending DOCP is willing to accept the remaining risk. Similarly, if a
receiving DOCP cannot trust the
content or policy associated with data provided by another DOCP, then
a receipt and handling policy
must be established consistent with the risk the receiving DOCP is willing
to accept. This policy may be
more restrictive than required by the TCSEC [4] and its interpretations.
2.3 GLOBAL POLICY
These considerations pertain to systems for which there can be or has
been no accreditation against a well
defined global policy such as those stated in the TDI[3] TCB subset policy
and the TNI [2] NTCB policy.
2.3.1 Shared Mechanisms
If TCBs share mechanisms (e.g., identification/authentication or audit)
each individual TCB must be
accredited with both using that mechanism. The DAA must use the evidence
from those accreditations to
ensure consistency with interface policy between the entities and any
less primitive policy of which this
shared mechanism is a part.
2.3.2 Discretionary Access Control
To be secure, the entire connected system should satisfy a single discretionary
access control policy. This
can only be accomplished by isolation of objects under protection of a
single TCB to the subjects within
that TCB. Otherwise, it must be accomplished by sharing access control
mechanisms or sharing access
control information between mechanisms. In older systems that do not allow
subjects to access objects in
other systems, this requirement is often satisfied because only standard
messages are formatted and
allowed to be transmitted. In these cases the subjects do not have access
to objects beyond the scope of
their own TCB.
2.3.3 Identification/Authentication
Even if each TCB has its own data for identification and authentication,
the information for individual
users that may potentially request access in more than one TCB or may
have access to objects in more than
one TCB must be consistent. The individual cannot assume more than one
identity or be performing two
functions simultaneously (unless the system has accounted for such support).
2.3.4 Audit
There must be a way to associate audit records generated by different
TCBs for the same individual
subject.
2.3.5 Security Administrator
Someone must be assigned the authority and assume the responsibility
of security administrator for each
of the TCBs. In addition, a security administrator must represent the
authority of each hierarchical stage
of DAAs.
2.3.6 Recovery
Implications of failure of one of the component TCBs must be reviewed
from the standpoint of impact to
all of the other intercommunicating entities. A way to cooperatively shut
down and recover in a secure
manner must exist.
2.3.7 Global Noncompliance
A TCB that has not been assured of external compliance with global considerations,
yet still has been
allowed to operate within a connected system, must be treated as a risk
within itself, to other connected
TCBs, and to the system.
3 RISK MANAGEMENT
Several topics of risk management are discussed in this section, including
the following:
o Propagated risk assessment to account for cascading risk.
o Policy iteration to optimize operational policy resulting from this
assessment.
o Assessment of the risk once the protection mechanisms have been determined.
o Design iteration to again adjust the operational policy based on the
cost risk analysis.
Many of these concepts of propagated risk were previously presented
in [12].
3.1 PROPAGATED RISK ASSESSMENT
One small part of the risk management process is the risk assessment
procedure identified in DoDD
5200.28, enclosure 4 [7], and the resultant action taken by the DAA. The
risk assessment procedure
proposed here is a simple extension to the procedure in that enclosure,
treating cascading risk in its
simplest interpretation. By-products are summed contributions of risk
that are management flags to the
DAA indicating which elements of his/her system are the major risk contributors.
The risk assessment procedure is similar to that in "Trusted Network
Interpretation Environments
Guideline [8]," except that this document recognizes that cascading
risk does not just result from
contiguous components.
The risk inherent to a DOCP is calculated from DoDD 5200.28, enclosure
4 [7], as if the DOCP were in
isolation, and is called inherent risk. The exposed risk is the amount
of change (increase) in DOCP risk
resulting from consideration of cascading risk from all other DOCPs. This
parameter may result in a
change to the risk index and potentially assigned division/class. In the
search for increased exposed risk,
the search may end along a single path once a previously evaluated trusted
absorbing node is
encountered. Otherwise the search is to each logical receiver of data.
Contributed risk is the summed amount of increase in exposed risk potentially
contributed by a single
DOCP to all other DOCPs. (Two DOCPs could potentially change the risk
level of a third DOCP from its
original level, but in the analysis technique, only one actually does.
Nevertheless, they both receive an
increase in contributed risk.) Solely contributed risk is the risk contributed
by a DOCP which could not
have been also contributed by another DOCP.
Cascading risk is determined by the exposed risk factor. This parameter
results in a change to the risk
index and potentially the assigned division/class. the exposed risk can
only be decreased by changing
either the local operational policies or the operational policies of the
contributing DOCPs. The
contributed risk factors are an indicator to the DAA where the changing
of policy or the
implementation of mechanisms (e.g., security guards), for example, can
do the most good in reducing
the risk of the overall system.
The four risk factors (risk index, exposed risk index, contributed risk,
and solely contributed risk) become
part of the system "operational security policy." The procedure
in DoDD 5200.28 enclosure 4 [7] deals
only with security levels and clearances.
3.2 POLICY ITERATION
Before mechanisms are considered in the solution, Figure 5 shows how
the operational requirements
specification can be iterated, along with the definitions of DOCPs, based
on risk considerations. The two
contributed risk factors help identify to the DAA the areas where changes
in operational policy can have
the largest risk reduction advantage. The propagated risk assessment is
reaccomplished to assess the
shared risk aspects of the adjustments.
3.3 PROTECTION ASSESSMENT
The next step considers existing or planned security mechanisms. Compatibility
with division/class
criteria, use of downgrade guards, existence of interface enforcement
mechanisms, and the approach to
global enforcement are all important considerations. Temporal inconsistencies
and potential
vulnerabilities are assessment concerns, as are trusted startup, shutdown
and recovery.
Besides protection mechanism assessment, there needs to be an assessment
of assurance. This includes
determining the evaluation rigor used, or planned to be used, in testing
and evaluating the DOCP. This
assessment uses the figures-of-merit approach discussed earlier.
3.4 DESIGN ITERATION
The second iteration, illustrated in Figure 6, like the first iteration,
allows reexamination of the process all
the way back to the specification of operational policy, modification
of DOCPs, and respecification of
interface policies to the identification mechanisms. The two contributed
risk factors again help identify to
the DAA areas where changes in operational policy can have the largest
risk and cost reduction
advantage. The protection assessment can be reaccomplished. What remains
is a statement of the
residual risk within the system. The DAA must determine what additional
corrections or operational
constraints must be observed to declare the system accredited to operate
in the environment. The final
statement of operational security policy and mechanism architecture is
then used as the basis for
certification evaluation and accreditation.
4 SUMMARY
This paper has introduced a way to deal with evolving, multipolicy systems
using the TCSEC [4]. Rules
are provided for the assembly and assurance of existing, new build, and
EPL [6] components. This
approach considers cascading risk and accommodates operational downgrade
through data guards, an
approach often used by the military to eliminate unnecessary policy constraints.
This approach
incorporates risk assessment. It provides an easily recognized strategy
to the DAA for reducing risk with
the minimum expenditure of funds. This approach also specifies assurance
deficiencies in the system and
helps to provide a strategy for correcting these deficiencies.
The domains of constant policy approach is a major step toward achieving
the security recommended in the network
TCB approach of the TNI [2] and the TCB approach recommended in the TDI
[3] for evolving systems. In many
cases the goal can be achieved without major redesign of existing systems.
As systems continue to evolve, adding
more function and capability, rigorous security goals can be realized.
BIBLIOGRAPHY
[1] C Technical Report 32-92, "The Design and Evaluation of INFOSEC
Systems: The Computer
Security Contribution to the Composition Discussion," June 1992
[2] NCSC-TG-005, "Trusted Network Interpretation (TNI) of the Trusted
Computer System Evaluation
Criteria(TCSEC)," National Security Agency, July 31, 1987
[3] NCSC-TG-021 "Trusted Database Management System Interpretation
(TDI) of The Trusted
Computer System Evaluation Criteria (TCSEC)," National Security
Agency, April 1991
[4] DoD 5200.28-STD, "Department of Defense Trusted Computer System
Evaluation Criteria,"
December 1985
[5] 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)
[6] "Information Systems Security Products and Services Catalogue,"
Prepared by the National
Security Agency, (Published Quarterly)
[7] DoD Directive 5200.28, "Security Requirements for Automated
Information Systems (AISs),"
March 21, 1988
[8] NCSC-TG-011, "Trusted Network Interpretation Environments Guideline,"
National Security
Agency, August 1, 1990
[9] DoD 5200.28-M, (Draft) "Automated Information System Security
Manual," April 29, 1991
[10] Johnson, H.L., "An Approach to Security Test," AFCEA 4th
Annual Symposium on C3I
Technology, Information and Security, Philadelphia, PA, August 16-18,
1988
[11] AFSSM 5031, "Complex System Guide," Air Force Special
Security Instruction," Air Force
Cryptologic Support Center, Air Force Intelligence Command, 1991
[12] Johnson, H.L., and J.D. Layne, "Modeling Security Risk in Networks,"
Proceedings 11th National
Computer Security Conference, NIST and NCSC, October 17-20, 1988, pp.
59-64
ACRONYMS
AIS Automated Information System
COMPUSEC Computer Security
DAA Designated Approving Authority
DOCP Domain of Constant Policy
DoD Department of Defense
EPL Evaluated Products List
INFOSEC Information Security
NTCB Network Trusted Computing Base
RFP Request for Proposal
TCB Trusted Computing Base
TCSEC Trusted Computer System Evaluation Criteria
TDI Trusted Database Management System Interpretation
TNI Trusted Network Interpretation
GLOSSARY
Automated Information System - An assembly of computer hardware, software,
and/or firmware
configured to collect, create, communicate, compute, disseminate, process,
store, and/or control data or
information. (DoDD 5200.28)
Automated Security Policy - The set of restrictions and properties that
specify how an AIS supports the
Security Policy.
Certification - The technical evaluation of an AIS's security features
and other safeguards, made in
support of the accreditation process, which establishes the extent that
a particular AIS design and
implementation meets a set of specified security requirements. (DoDD 5200.28)
Certification Evaluation - (See Certification and Evaluation)
Contributed Risk - The summed amount of increase in exposed risk to all
other DOCPs potentially
contributed by a single DOCP.
Depends - A TCB subset depends (for its correctness) on TCB subset B
if and only if the (engineering)
arguments of the correct implementation of A with respect to its specification
assume, wholly or in part,
that the specification of B has been implemented correctly. (NCSC-TG-021)
Domain - The unique context in which a program is operating; in effect,
the set of objects that a subject has
the ability to access.
Domain of Constant Policy - That part of a system to which a single,
unique operational security policy
has been defined. DOCPs are nonoverlapping subsets of the system, that,
in combination, completely
cover the system. A DOCP consists of a well-defined boundary (where an
isolation mechanism exists or
can be employed) and an n-tuple of policy defining security characteristics.
Evaluation - Two types of evaluation are referred to: product evaluation
and certification evaluation.
Exposed Risk - The amount of change (increase) in DOCP risk resulting
from consideration of cascading
risk from all other DOCPs. This parameter results in a change to risk
index and potentially the assigned
division/class.
Inherent Risk - Calculated risk for the element as if it were in isolation.
Network Trusted Computing Base - The totality of the protection mechanisms
within a network system -
including hardware, firmware, and software - the combination of which
is responsible for supporting
security policy. (NCSC-TG-005)
NTCB Partition - The totality of mechanisms within a single network component
for enforcing the
network policy, as allocated to the component; the part of the NTCB within
a single network component.
Operational Security Policy - The policy decisions made by the DAA in
accordance with DoDD 5200.28
(policy concerning security levels of user, classifications of data, security
mode and assignment of all the
above to different elements of the system). (NCSC-TG-005)
Primitive - An ordering relation between TCB subsets based on dependency
(see "depends" above). A
TCB subset B is more primitive than a second TCB subset A (and A is less
primitive than B) if (a) A
directly depends on B or (b) a chain of TCB subsets from A to B exists
such that each element of the chain
directly depends on its successor in the chain. (NCSC-TG-021)
Product - Used here in the same sense as used in the EPL, NSA Information
System Security Products and
Services Catalogue.
Product Evaluation - An evaluation performed on the hardware and software
features and assurances of a
computer product from a perspective that excludes the application environment.
This term is used here
in the same sense as used in the EPL, NSA Information System Security
Products and Services Catalogue.
Regulatory Security Policy - Security policy represented by regulatory
documents imposed on the
procurement organization (especially DoDD 5200.28, DoD 5200.28-M, and
DoD 5200.28-STD).
Security Evaluation - An evaluation accomplished to assess the degree
of trust that can be placed in
systems for the secure handling of sensitive information. One type, a
product evaluation, is an evaluation
performed on the hardware and software features and assurances of a computer
product from a
perspective that excludes the application environment. The other type,
a system evaluation, is done for
the purpose of assessing a system's security safeguards with respect to
a specific operational mission and
is a major step in the certification and accreditation process.
Security Policy - The set of laws, rules, and practices that regulate
how an organization manages, protects,
and distributes sensitive information.
Solely Contributed Risk - The risk contributed by a DOCP to another DOCP
that was not also contributed
by another DOCP.
System - (See Automated Information System)
TCB Subset - A set of software, firmware, and hardware (where any of
these three could be absent) that
mediates the access of a set S of subjects to a set O of objects on the
basis of a stated access control policy P
and satisfies the properties:
(1) M mediates every access to objects O by subjects in S,
(2) M is tamper resistant; and,
(3) M is small enough to be subject to analysis and tests, the completeness
of which can be assured.
(NCSC-TG-021)
Trusted absorbing Node - A DOCP somewhere in the path from the sending
DOCP to the destination
DOCP that can be trusted to receive the data, properly interpret the policy,
and incorporate the policy for
that data into its TCB. If this is not the final destination, the trusted
absorbing node takes the security
responsibility from the sending DOCP from that point on. It is the responsibility
of the sending DOCP to
communicate the data, the recipient DOCP, and the appropriate policy to
the trusted Absorbing Node.
Trusted Computing Base (TCB) - The totality of protection mechanisms
within a computer system -
including hardware, firmware, and software, the combination of which is
responsible for enforcing
security policy.
Virtual Communications Channel - If a sending DOCP somehow specifies
a destination other than a
physically connected DOCP, and the intermediate DOCPs each have the responsibility
of seeing that the
data (and often its policy) gets to its correct destination, these DOCPs
are called virtual communication
channels. It is up to the sending DOCP to be assured that the virtual
communications channels and the
destination can be trusted to transfer the data according to its policy.
|
