FOREWORD
The National Computer Security Center is issuing A Guide
to Understanding Security
Modeling in Trusted Systems as part of the "Rainbow
Series" of documents produced by our
Technical Guidelines Program. In the Rainbow Series, we
discuss, in detail, the features of the
Department of Defense Trusted Computer System Evaluation
Criteria (DoD 5200.28-STD) and
provide guidance for meeting each requirement. The
National Computer Security Center, through
its Trusted Product Evaluation Program, evaluates the
security features and assurances of
commercially-produced computer systems. Together, these
programs ensure that organizations are
capable of protecting their important data with trusted
computer systems. Security modeling, in its
various forms, is an important component of the assurance
of the trust of a computer system.
A Guide to Understanding Security Modeling in Trusted
Systems is intended for use by
personnel responsible for developing models of the
security policy of a trusted computer system.
At lower levels of trust, this model is generally the
system"s philosophy of protection. At higher
trust levels, this also includes informal and formal
models of the protection mechanisms within a
system. This guideline provides information on many
aspects of security modeling, including the
process of developing a security policy model, security
modeling techniques, and specific ways to
meet the requirements of the Department of Defense
Trusted Computer System Evaluation
Criteria.
As the Director, National Computer Security Center, I
invite your suggestions for revising this
document. We plan to review and revise this document as
the need arises.
Patrick R. Gallagher, Jr. October
1992
Director
National Computer Security Center
ACKNOWLEDGMENTS
Special recognition and acknowledgment for their
contributions to this document are
extended to the following: Dr. James Williams, as primary
author of this document; Barbara
Mayer, Capt. James Goldston, USAF, and Lynne Ambuel, for
project management.
Special thanks are also given to the many evaluators,
vendors, and researchers whose careful
reviews and suggestions contributed to this document,
with special recognition for the advice of
David Bell, Daniel Schnackenberg, Timothy Levin, Marshall
Abrams, Deborah Bodeau, Leonard
La Padula, Jonathan Millen, William L. Harkness, Thomas
A. Ambrosi, Paul Pittelli, Dr. Michael
Sinutko, Jr, and COL Rayford Vaughn, USA.
TABLE OF CONTENTS
FOREWORD i
ACKNOWLEDGMENT ii
1. INTRODUCTION 1
1.1 Background 1
1.2 Purpose 2
1.3 Control Objectives 3
1.3.1 The Assurance Objective 3
1.3.2 The Security Policy Objective 4
1.4 Historical Overview 5
1.5 Content and Organization 7
2. OVERVIEW OF A
SECURITY MODELING PROCESS 9
2.1 Security Models and Their Purpose 9
2.2 Security Modeling in the System Development Process 11
2.3 Identifying the Contents of a Security Model 14
2.3.1 Step 1: Identify Requirements on the External
Interface 16
2.3.2 Step 2: Identify Internal Requirements 18
2.3.3 Step 3: Design Rules of Operation for Policy
Enforcement 20
2.3.4 Step 4: Determine What is Already Known 21
2.3.5 Step 5: Demonstrate Consistency and Correctness 22
2.3.6 Step 6: Demonstrate Relevance 23
2.4 Presentation for Evaluation and Use 24
3 .SECURITY
MODELING TECHNIQUES 27
3.1 Basic Concepts 27
3.1.1 Data Structures and Storage Objects 28
3.1.2 Processes and Subjects 29
3.1.3 Users and User Roles 31
3.1.4 I/O Devices 33
3.1.5 Security Attributes 35
3.1.6 Partially Ordered Security Attributes 37
3.1.7 Nondisclosure Levels 39
3.1.8 Unlabeled Entities and the Trusted Computing Base 40
3.2 Nondisclosure and Mandatory Access Control 41
3.2.1 External-Interface Requirements and Model 43
3.2.2 Information-Flow Model 45
3.2.3 Application to the Reference Monitor Interface 47
3.2.4 Access-Constraint Model 48
3.2.5 Tailoring the Models 51
3.3 Need-to-Know and Discretionary Access Control 53
3.3.1 DAC Requirements and Mechanisms 54
3.3.2 User Groups and User Roles 55
3.3.3 Sources of Complexity and Weakness 56
3.3.4 Tight Per-User Access Control 59
3.4 TCB Subjects-Privileges and Responsibilities 61
3.4.1 Identifying Privileges and Exemptions 62
3.4.2 Responsible Use of Exemptions 65
3.5 Integrity Modeling 66
3.5.1 Objectives, Policies, and Models 67
3.5.2 Error Detection and Recovery 68
3.5.3 Encapsulation and Level-Based Access Control 71
4. TECHNIQUES FOR SPECIFIC KINDS OF SYSTEM 5
4.1 Operating Systems 75
4.1.1Traditional Access Control Models 75
4.1.2 The Models of Bell and La Padula 77
4.2 Networks and Other Distributed Systems 78
4.2.1 Systems and Their Components 78
4.2.2 Model Structure and Content 80
4.2.3 Network Security Models 82
4.2.4 Individual Component Security Models 84
4.2.5 Underlying Models of Computation 85
4.3 Database Management Systems 86
4.3.1 System Structure 87
4.3.2 Integrity Mechanisms and Policies 89
4.3.3 Aggregation 90
4.3.4 Inference 91
4.3.5 Partially Automated Labeling 92
4.4 Systems with Extended Support for Label Accuracy 94
4.4.1 Factors Inhibiting Accuracy in Labeling 94
4.4.2 Floating Sensitivity Labels 95
4.4.3 Compartmented Mode Workstations (CMW) 95
4.4.4 The Chinese Wall Security Policy 96
5. MEETING THE REQUIREMENTS 99
5.1 Stated Requirements on the Security Model 99
5.2 Discussion of the B1 Requirements 100
5.3 Discussion of the B2 Requirements 103
5.4 Discussion of the B3 Requirements 104
5.5 Discussion of the A1 Requirements 105
APPENDIX A. SECURITY LEVELS AND PARTIALLY ORDERED SETS 107
A.l Terminology 107
A.2 Embeddings 109
A.3 Cartesian Products 109
A.4 Duality 110
APPENDIX B. AVAILABLE SUPPORT TOOLS 113
B.1 FDM: the Formal Development Methodology 114
B.2 GVE: the Gypsy Verification Environment 115
APPENDIX C. PHILOSOPHY OF PROTECTION OUTLINE 17
APPENDIX D. SECURITY MODEL OUTLINE 21
APPENDIX E. GLOSSARY 127
REFERENCES 45
1. INTRODUCTION
This document provides guidance on the construction,
evaluation, and use of security policy
models for automated information systems (AIS) used to
protect sensitive information whose
unauthorized disclosure, alteration, loss, or destruction
must be prevented. In this context, sensitive
information includes classified information as well as
unclassified sensitive information.
1.1 BACKGROUND
The National Computer Security Center (NCSC) was
established in 1981 and acquired its
present name in 1985. Its main goal is to encourage the
widespread availability of trusted AISs. In
support of this goal, the DoD Trusted Computer System
Evaluation Criteria (TCSEC) was written
in 1983. It has been adopted, with minor changes, as a DoD
standard for the protection of sensitive
information in DoD computing systems. [NCSC85] The TCSEC
is routinely used for the
evaluation of commercial computing products prior to
their accreditation for use in particular
environments. This evaluation process is discussed in
Trusted Product Evaluations: A Guide for
Vendors. [NCSC90c]
The TCSEC divides AISs into four main divisions, labeled
D, C, B, and A, in order of
increasing security protection and assurance. Divisions C
through A are further divided into
ordered subdivisions referred to as classes. For all
classes (C1, C2, B1, B2, B3 and A1), the TCSEC
requires system documentation that includes a philosophy
of protection. For classes B1, B2, B3,
and A1, it also requires an informal or formal security
policy model.
Although the TCSEC is oriented primarily toward operating
systems, its underlying concepts
have been applied much more generally. In recognition of
this, the NCSC has published a Trusted
Network Interpretation [NCSC87] and a Trusted Database
Management System Interpretation.
[NCSC91] In addition, the NCSC also provides a series of
guidelines addressing specific TCSEC
requirements, of which this document is an example.
1.2 PURPOSE
This guideline is intended to give vendors and evaluators
of trusted systems a solid
understanding of the modeling requirements of the TCSEC
and the Trusted Network Interpretation
of the TCSEC (TNI). It presents modeling and philosophy
of protection requirements for each of
the classes in the TCSEC, describes possible approaches
to modeling common security
requirements in various kinds of systems, and explains
what kinds of mode is are useful in an
evaluation. It is intended for vendors, evaluators, and
other potential builders and users of security
models.
This guideline discusses the philosophy of protection
requirement, explains how it relates to
security modeling, and provides guidance on documentation
relating to the system's philosophy of
protection and security policy model. It explains the
distinction between informal and formal
security policy models as well as the relationships among
application-independent models,
application-dependent security models, and model
interpretations. It also explains which
techniques may be used to meet the modeling requirements
at levels B1 through Al as well as the
advantages and disadvantages of the various modeling
techniques. Finally, it discusses the specific
TCSEC modeling requirements.
This guideline also addresses human aspects of modeling.
It describes how modeling captures
basic security requirements and how the security modeling
effort leads to better systems and
provides a basis for increased assurance of security.
Finally, this guideline answers common questions about
NCSC recommendations regarding
the construction of security models. Security policies
and models are supplied by vendors in
response to customer needs and TCSEC requirements; they
are not supplied by the NCSC or the
TCSEC. The TCSEC does, however, set minimum requirements
in the areas of mandatory and
discretionary access control. The TCSEC does not require
particular implementation techniques;
this freedom applies, by extension, to modeling
techniques. Acceptability of a technique depends
on the results achieved. More specifically, a security
model must provide a clear and accurate
description of the security policy requirements, as well
as key ideas associated with their
enforcement. Moreover, one must be able to validate the
model using assurance techniques
appropriate to the proposed evaluation class. Any
vendor-supplied modeling technique which
appears to be compatible with the security modeling
requirements will be seriously considered
during the course of a product evaluation.
Topics which are closely related to security modeling
include formulation of security policy
objectives, design specification and verification, covert
channel analysis, and implementation
correspondence analysis. These topics are addressed only
to the extent necessary to establish their
influence on the security modeling process. All but the
first of these topics are addressed in other
guidelines in this series. Security objectives for
trusted systems traditionally include
nondisclosure, integrity, and denial of service. [cf
NCSC88, AIS Security] However, the modeling
of denial of service is not addressed in this guideline,
due to the lack of adequate literature on this
topic. This guideline is written with the understanding
that security modeling will continue to
evolve in response to new policy objectives and modeling
techniques associated with future trusted
system designs.
Reading and understanding this guideline is not
sufficient to allow an inexperienced
individual to develop a model. Rather, he or she should
read this document in conjunction with one
or more of the published models in the list of
references. This guideline assumes a general
familiarity with the TCSEC and with computer security. A
general text such as Building a Secure
Computer System [GASS87] may provide useful background
reading. Additional mathematical
background needed for formal modeling can be found in
general texts on mathematical structures
such as Introduction to Mathematical Structures [GALO89].
The approaches to security modeling presented in this
document are not the only possible
approaches to satisfying TCSEC modeling requirements, but
are merely suggested approaches.
The presentation of examples illustrating these approaches
does not imply NCSC endorsement of
the products on which these examples are based.
Recommendations made in this document are not
supplementary requirements to the TCSEC. The TCSEC itself
(as supplemented by announced
interpretations [NCSC87, NCSC88a, NCSC88b, NCSC91]) is
the only metric used by the NCSC
to evaluate trusted computing products.
1.3 CONTROL
OBJECTIVES
The requirements of the TCSEC were derived from three
main control objectives: assurance,
security policy, and accountability. The security
modeling requirements of the TCSEC support the
assurance and security policy control objectives in
systems rated B1 and above.
1.3.1 THE
ASSURANCE OBJECTIVE
The TCSEC assurance control objective states, in part,
"Systems that are used to process or handle
classified or other sensitive information
must be designed to guarantee correct and accurate
interpretation of the security policy and
must not distort the intent of that policy."
[NCSC85, § 5.3.3]
Assurance in this sense refers primarily to technical
assurance rather than social assurance. It
involves reducing the likelihood that security mechanisms
will be subverted as opposed to just
improving people's confidence in the utility of the
security mechanisms.
1.3.2 THE
SECURITY POLICY OBJECTIVE
The TCSEC security policy control objective states, in
part,
"A statement of intent with regard to control over
access to and dissemination of
information, to be known as the security policy, must be
precisely defined and
implemented for each system that is used to process
sensitive information. The security
policy must accurately reflect the laws, regulations, and
general policies from which it is
derived." [NCSC85, § 5.3.1]
The security
policy objective given in the TCSEC covers "mandatory security
policy,"
"discretionary security policy," and
"marking" objectives. The mandatory security policy
objective requires the formulation of a mandatory access
control (MAC) policy that regulates
access by comparing an individual's clearance or
authorization for information to the classification
or sensitivity designation of the information to be
accessed. The discretionary access control
objective requires the formulation of a discretionary
access control (DAC) policy that regulates
access on the basis of each individual's need-to-know,
Finally, the marking objective gives labeling
requirements for information stored in and exported from
systems designed to enforce a mandatory
security policy.
The access controls associated with security policies
serve to enforce nondisclosure and
integrity. Nondisclosure controls prevent inappropriate
dissemination of information. Integrity
controls prevent inappropriate modification of
information.
The security policy control objective requires that the
security policy accurately reflect the
laws, regulations, and general policies from which it is
derived. These may include the revised
DoD Directive 5200.28, Security Requirements for
Automated Information Systems (AISs).
[DOD88a] Section D of Directive 5200.28 gives policy
relating to both integrity and
nondisclosure. It mentions safeguards "against
sabotage, tampering, denial of service, espionage,
fraud, misappropriation, misuse, or release to
unauthorized users." Enclosure 2 defines relevant
terms and, in particular, extends the concept of
"user" to include processes and devices interacting
with an automated information system on behalf of users.
Enclosure 3 gives general security
requirements, including data-integrity requirements. The
revised 5200.28 does not use the MAC/
DAC terminology. Instead, it requires accurate marking of
sensitive information and the existence
of an (undifferentiated) access control policy based
partly on the identity of individual users. It
treats need-to-know as a form of least privilege.
Security policy relating to nondisclosure stems from
Executive Order 12356 [REAG82] and,
in the case of DoD systems, from DoD 5200.1-R. [DOD86]
Depending on the application, the
security policy may be constrained by a variety of other
regulations as well. The collection,
maintenance, use, and dissemination of personal
information is protected by DoD Directive
5400.11 [DOD82, § E.2] and by Public Law 100-503 [CONG88].
Classified and other sensitive
information needed for the conduct of federal programs is
protected by the Computer Security Act
of 1987, Public Law 100-235 [CONG87], which requires
safeguards against loss and unauthorized
modification.
1.4 HISTORICAL
OVERVIEW
The starting point in modeling a MAC policy is the
observation that security levels are
partially ordered (see Appendix A). This fact was first
reflected in the design of the ADEPT-50,
an IBM 360-based, time-sharing system with both mandatory
and discretionary controls.
[WEIS69, LAND81] The central role of partial orderings in
MAC policy models was then
recognized in subsequent work. [POPE73; BELL73; BELL74a]
These partial orderings on security
levels have become known as dominance relations.
Independently of this, access control matrices were used
by Lampson and Graham [LAMP71;
GRAH72] to represent protection data. These works modeled
discretionary access control using
matrices whose rows and columns represented subjects and
objects. Subjects were active entities
such as processes and users. Objects were entities such
as data structures that played a passive role,
but often included subjects as well. Each entry in an
access matrix told what a given subject was
allowed to do with a given object by giving a set of
allowed operations such as read, write, execute,
or change ownership. The AIS used the access matrix to
mediate all accesses by subjects to objects.
An Air Force Computer Security Technology Planning Study
[ANDE72], referred to as "the
Anderson Report," discussed use of a reference
monitor to enforce nondisclosure policies and
advanced the idea of formal security verification- the
use of rigorous mathematical proofs to give
(partial) assurance that a program design satisfies
stated security requirements. This idea was
investigated by Schell, Downey and Popek. [SCHE73]
At that time, Bell and La Padula adapted access control
matrices for use in modeling both
mandatory and discretionary access controls and codified
the reference monitor concept using state
machines. Their machine states included access matrices
and other security-relevant information
and are now often referred to as protection states.
Having established the necessary framework,
they observed that a portion of DoD policy for
nondisclosure of classified information could be
formalized as invariant properties of protection states
[LAPA73], that is, as properties which hold
in all reachable states of the system. Their invariants
constrained the allowed accesses between
subjects and objects. The most significant of these was
their *-property It included a form of the
simple security property and guaranteed that the security
level of every object read by an untrusted
subject was at or below the security level of every
object written by that subject. [BELL74] These
ideas and their use in enforcing nondisclosure are
covered in detail in Sections 3.2.4 and 4.1.
To complete their state machine, Bell and La Padula
introduced a set of state transformations,
called rules of operation, that modeled basic changes in
a protection state and then rigorously
proved that the rules of operation preserved the
identified state invariants. [LAPA73, BELL74,
BELL76] This work contains the first widely discussed use
of mathematical proof for studying
multilevel security.
In parallel with Bell and La Padula, Walter and others
developed a similar approach to
verifying multilevel security. [WALT74, WALT74a] A strong
point of the work by Walter et al.
is the use of modularity and data abstraction techniques
that have since been accepted as
indispensable for verifying large systems.
The intent of the state invariants identified by Bell and
La Padula is that information is
allowed to flow from one entity to another only if the
second entity is at an equal or higher security
level than the first. Denning and others attempted to
formalize this idea directly using "information
flow" models. [DENN76, DENN77, COHE77, REIT79, ANDR80].
These models differed in style
from access control models in that they referred
explicitly to information flow, but, in contrast to
more recent investigations, did not actually define
information flow. Denning's work did,
however, point out an interesting distinction. In the
conditional assignment
if a = 0 then b := c,
information flows explicitly from c to b (when a = 0) and
implicitly from a to b (when b c).
Denning also pointed out that, in the case of the
ADEPT-50, access control can easily allow
implicit information flow. [DENN77] This problem is
discussed in detail in Section 3.2.
Discrepancies between information flow and access control
open up the possibility of covert
channels- paths of information flow that malicious processes
can use to bypass the access control
mechanism and thereby violate underlying security
objectives. [cf LAMP73] Information flow
models and concern over covert channels have led to the
development of techniques and tools for
covert channel analysis that are capable of detecting a
variety of covert channels. [MILL76,
MILL81, FEIE77, FEIE80]
The developments just described provided the technical
background for the security modeling
requirements given in the TCSEC. A variety of important developments
not explicitly reflected in
the TCSEC have taken place in the last decade and will be
presented later in this guideline. The
class of security policies that can be formally modeled
has been greatly extended, beginning with
Biba's (pre-TCSEC) work on integrity. [BlBA77] Work has
also gone into tailoring nondisclosure
security to particular applications. Finally, various
external-interface models have been developed
that do not constrain internal system structure, an
example of which is the noninterference model
of Goguen and Meseguer. [GOGU82] These models provide a
rationale for rigorously assessing
new approaches to access control.
1.5 CONTENT AND
ORGANIZATION
Section 2 presents an overview of the security modeling
process, with emphasis on
correctness and utility. Section 3 presents technical
detail on how to model concepts of interest,
including nondisclosure and integrity policies, mandatory
and discretionary access controls, and
exemption from access control within the Trusted
Computing Base (TCB).
Section 4 shows how to apply the techniques from Section
3 to various kinds of systems;
including operating systems, networks, database systems,
and multilevel workstations. Finally,
Section 5 summarizes all of the TCSEC security modeling
requirements for B1, B2, B3, and A1
computing systems.
Appendix A presents facts about lattices and partially
ordered sets that are needed for Sections
3 and 4. Appendix B contains brief descriptions of
available support tools. Appendices C and D
contain suggested outlines for a philosophy of protection
and a security policy model. Finally,
Appendix E is a glossary giving definitions of technical
terms. This glossary includes all terms that
are introduced in italics throughout the guideline.
When TCSEC requirements are discussed in this guideline,
they are identified either by the
key words "must" or "shall" or by
explicit quotations from the TCSEC. By way of contrast, when
desirable but optional actions and approaches are
discussed, they are presented without exhortation
and are instead accompanied by an explanation of specific
advantages or benefits. In a few cases,
possible requirements are designated by
"should," because the implications of the TCSEC are not
fully understood or agreed upon.
2. OVERVIEW OF A
SECURITY MODELING PROCESS
A security model precisely describes important aspects of
security and their relationship to
system behavior. The primary purpose of a security model
is to provide the necessary level of
understanding for a successful implementation of key
security requirements. The security policy
plays a primary role in determining the content of the
security model. Therefore, the successful
development of a good security model requires a clear,
well-rounded security policy. In the case
of a formal model, the development of the model also must
rely on appropriate mathematical
techniques of description and analysis for its form.
Sections 2.1 and 2.2 explain what security models
describe, why they are useful, and how they
are used in the design of secure systems. Section 2.3
introduces general definitions relating to
security models and explains how security models are
created. Finally, Section 2.4 discusses the
presentation of a security model in a modeling document.
2.1 SECURITY
MODELS AND THEIR PURPOSE
Early security models focused primarily on nondisclosure
of information. More recently, the
importance of data as a basis for decisions and actions
has stimulated interest in integrity models.
[DOD88a, WHIT84] For example, nondisclosure properties
alone do not protect against viruses
that can cause unauthorized, malicious modification of
user programs and data.
A wide variety of concepts can impact nondisclosure and
integrity in particular system
designs. As a result, the content of security models is
quite varied. Their primary purpose is to
provide a clear understanding of a system's security
requirements. Without such an understanding,
even the most careful application of the best engineering
practices is inadequate for the successful
construction of secure systems.
Inadequacies in a system can result either from a failure
to understand requirements or from
flaws in their implementation. The former problem,
defining what a system should do, is relatively
difficult in the case of security. The definition must be
precise in order to prevent undesired results,
or subtle flaws, during the implementation of the system
design.
During the entire design, coding, and review process, the
modeled security requirements may
be used as precise design guidance, thereby providing
increased assurance that the modeled
requirements are satisfied by the system. The precision
of the model and resulting guidance can be
significantly improved by casting the model in a formal
language.
Once the system has been built, the security model serves
the evaluation and accreditation
processes. It contributes to the evaluators' judgement of
how well the developers have understood
the security policy being implemented and whether there
are inconsistencies between security
requirements and system design. Moreover, the security
model provides a mechanism for tailoring
the evaluation process to the vendor's needs because it
presents the security concept that is
supported by the system being evaluated. The inclusion of
particular facts in the security model
proclaims to evaluators and potential customers that
those facts are validated at the level of
assurance which the TCSEC associates with that system's
evaluation class.
Upon successful evaluation and use, the security model
provides a basis for explaining
security-relevant aspects of system functionality. Later,
during maintenance, it provides a basis for
guidance in making security-relevant modifications.
Finally, by suppressing inessential design
detail, security models facilitate a broader
understanding of security that can be applied to
increasingly larger classes of systems. Among the many
examples of such generalizations is the
adaptation of traditional reference monitor concepts
referenced in the TNI to provide a basis for
understanding network security requirements. [NCSC87]
The intended purpose of a security model suggests several
desirable properties. The
requirements captured by a good model pertain primarily
to security, so that they do not unduly
constrain the functions of the system or its
implementation. A good model accurately represents
the security policy that is actually enforced by the
system. Thus, it clarifies both the strengths and
the potential limitations of the policy. (As an extreme
example, if the system can simply declassify
all objects and then proceed normally, as in McLean's
System Z [MCLE87], a good model would
show this.) Finally, a good model is simple and therefore
easy to understand; it can be read and
fully understood in its entirety by its intended
audience. This last property cannot be achieved
without significant care in choosing the contents,
organization, and presentation of the security
model. For example, the desire to provide a security
model with the "look and feel" of UNIX,
might need to be tempered by the need for simplicity and
abstraction. [cf NCSC90b, Sec. 6.2]
2.2 SECURITY
MODELING IN THE SYSTEM DEVELOPMENT PROCESS
Security requirements are best identified early in the
system development process. Not
identifying security requirements in a timely fashion is
likely to have devastating effects on
security assurance, security and application
functionality, development schedule, and overall
development costs. For example, in the case of a
development using DOD-STD-2167A, [DOD88]
this identification process would be part of the system
requirements analysis. The identification of
security requirements begins with the identification of
high-level security objectives (as described
in Section 1.3) and the methods by which they are to be
met, including automated, procedural, and
physical protection methods. This identification of
security requirements and their derivation from
identified higher-level security objectives is the
initial material for a philosophy of protection
(POP). As indicated in Appendix C, the philosophy of
protection may also include a broad range
of other topics such as the structure of the trusted
computing base (TCB) and physical and
procedural security mechanisms.
Those requirements in the philosophy of protection which
deal with automated protection
methods provide an initial definition of security for a
security policy model. The model's purpose
is to precisely state these requirements and to compare
them with key aspects of the security
enforcement mechanism. A security policy model in this
sense contains two essential portions: a
"definition of security" portion that captures
key security requirements and a "rules of operation"
portion that shows how the definition of security is
enforced.
The model's definition of security can be used to avoid
major system development errors. It
can be used to guide the design of basic software
protection mechanisms and to influence the
design, selection and use of underlying firmware and
hardware protection mechanisms. The initial
draft model, and supporting documentation, provides
guidance as to system security during
reviews of the system design. However, there often are
discrepancies between the design and the
model. Some of these are resolvable and can be identified
and corrected during the normal design
review process. In some cases, however, discrepancies are
unavoidable and can only be resolved
by making some assumptions that simplify the problem.
These assumptions need to be justifiable,
based on the model. These discrepancies can also be
addressed through procedural restrictions on
the use of the system. There are some portions of a
security model that may require design
information that is not initially available and must,
therefore, be postponed. Possible examples
include detailed rules of operation for a security kernel
and security models for specific security-
critical processes. In such cases, the system designer
must ensure that discrepancies are noted and
the completed system will satisfy the completed model.
To ensure that a design satisfies modeled security
requirements, it is necessary to give a model
interpretation which shows how the model relates to the
system. For evaluation classes B1 and B2,
this involves explaining how each concept in the model is
embodied by the system design and
informally demonstrating that the modeled requirements
are met. Since the model's rules of
operation must conform to the model's definition of
security, the model interpretation need
demonstrate only that the rules of operation are adhered
to. For classes B3 and A1, the model
interpretation is done in two steps. The design, as
reflected in a top-level specification (TLS), is
shown to be consistent with the model, and the
implementation is shown to be consistent with the
TLS. For Class B3, an informal descriptive top-level
specification (DTLS) is used, an informal
correspondence from the DTLS to the model is performed,
and the implementation is shown to be
consistent with the DTLS. At Class A1, the DTLS is
supplemented with a formal top-level
specification (FTLS), a formal verification proves that
the FTLS is consistent with the model, and
the implementation is shown to be consistent with the
FTLS. A fuller summary of model-
interpretation requirements is given in Section 5.
The role of security modeling in relation to other
aspects of system development is
summarized in Figure 2.1. Aspects that do not directly
involve modeling, per se, are shaded in grey.
Requirements concerning the model are summarized at the
beginning of Section 5. The broadest
document is the philosophy of protection (POP); it covers
higher-level security objectives, derived
security policies constraining the design and use of the
system, and the protection mechanisms
enforced by the TCB. The POP, the security policy, and
the model all cover the system's definition
of security. Both the POP and the model cover key aspects
of the TCB protection mechanisms. At
B2 and above, the formal model supports a rigorous proof
showing that the rules of operation
enforce the definition of security, and the DTLS gives a
functional description of the TCB
protection mechanisms with emphasis on the TCB interface.
At A1, the FTLS formalizes a large
portion of the DTLS in order to verify that the TCB
design satisfies the modeled security
requirements.
Figure 2.1. Security Documentation
The above paragraphs refer to a single security model but
networks, database systems, and
other complex systems may involve several security models
or submodels. When a system is made
up of several complex components or subsystems,
interfaces between the components or
subsystem layers must be modeled, if they play a key role
in security protection. In this case, the
best approach may be to develop separate models for each
component or layer in order to show
how the various subsystems contribute to overall system
security. A danger with this approach,
however, is that the combined effect of the various
submodels may not be obvious. This is
discussed further in Section 4.
2.3 IDENTIFYING
THE CONTENTS OF A SECURITY MODEL
The most basic strategy in identifying the contents of a
security model is perhaps that of divide
and conquer. The modeling effort may be subdivided
according to higher-level security objectives.
Requirements on a system can be mapped to derived
requirements on subsystems. Requirements
for a particular objective can be classified according to
level in a requirements hierarchy.
Security modeling provides a five-stage elaboration
hierarchy for mapping a system's
security policy requirements to the behavior of the
system. As a result of this hierarchy, the phrases
"security policy" and "security
model" have taken on a variety of meanings. The five relevant
stages are as follows:
1. Higher-level
policy objectives
2. External-interface
requirements
3. Internal
security requirements
4. Rules of
operation
5. Top-level
specification
A higher-level objective specifies what is to be achieved
by proper design and use of a computing
system; it constrains the relationship between the system
and its environment. The TCSEC control
objectives belong to this first level of the requirements
hierarchy. An external-interface
requirement applies a higher-level objective to a
computing system's external interface; it explains
what can be expected from the system in support of the
objective but does not unduly constrain
internal system structure. Internal security requirements
constrain relationships among system
components and, in the case of a TCB-oriented design,
among controlled entities. Rules of
operation explain how internal requirements are enforced
by specifying access checks and related
behaviors that guarantee satisfaction of the internal
requirements. A top-level specification is a
completely functional description of the TCB interface.
It also specifies behavior of system
components or controlled entities.
In various contexts, the phrase security policy may refer
to any or all of the first four stages
of elaboration. In many contexts, the term security
policy refers to organizational security policy.
[cf NCSC85, Glossary] From a modeling perspective,
organizational policies are the source of
higher-level policy objectives. In much of the literature
on security modeling, a system security
policy is part of the requirements stages of development
and provides the definition of security to
be modeled. Additional thoughts on the importance of
distinguishing among policy objectives,
organizational policies, and system policies may be found
in Sterne's article "On the Buzzword
"Security Policy." [STER91] The terms "AIS
security policy" and "automated security policy" are
synonyms for "system security policy."
The security policy model is a model of the security
policy enforced by the TCB. It is
simultaneously a model of the policy and of the system
for which the model is given. The portions
of the system which are constrained by the model belong
to the TCB by definition. The model's
definition of security may contain external-interface
requirements, but more traditionally consists
of internal requirements. Its rules of operation may, in
some cases, amount to a top-level
specification. There is no firm boundary between rules of
operation and top-level specifications:
both explain how internal requirements are enforced by
the TCB. However, more detail is required
in a TLS, including accurate descriptions of the error
messages, exceptions, and effects of the TCB
interface. Security requirements occur implicitly in
rules of operation and top-level specifications.
In this form they are often referred to as security
mechanisms. Internal requirements are sometimes
classified as "policy" or "mechanism"
according to whether or not they are derived from a specific
higher-level policy objective.
Conceptually, the security modeling process takes place
in two main phases. Requirements
modeling takes place after a system security policy is
fairly well understood. This is accomplished
by constraining the system's design and use based on the
higher-level objectives. Rules of
operation may be deferred until after the definition of
security is established and the basic
architecture of the system has been identified.
The following paragraphs contain general suggestions for
the construction of security models.
Suggestions pertaining to specific kinds of security
requirements and specific kinds of systems are
given in Sections 3 and 4, respectively.
These suggestions are broken down into six steps that
could be carried out with respect to an
entire system and security policy or, more simply, for a
given component and higher-level policy
objective. The first step is to identify externally
imposed security policy requirements on how the
system (or component) must interact with its environment.
The second is to identify the internal
entities of the system and to derive the requirements
portion of the model in such a way as to extend
the external-interface requirements. The third is to give
rules of operation in order to show how the
modeled security requirements can be enforced. After
completion of step three enough information
generally is available to determine reliably whether the
model is inherently new or can be
formalized by known techniques. At classes B2 and above,
this is the fourth step. The first three
steps taken together result in the identification of
several submodels. The fifth step is to
demonstrate consistency among these various submodels, so
that they fit together in a reasonable
way to form a completed security policy model. Finally,
the sixth step is to demonstrate relevance
of the model to the actual system design. Typically, the
majority of the security modeling effort is
associated with these last two steps and associated
revisions to the model. The total effort needed
to produce a security policy model varies considerably,
but is often between six staff-months and
two staff-years.
2.3.1 STEP 1:
IDENTIFY REQUIREMENTS ON THE EXTERNAL INTERFACE
The first step is to identify major security requirements
and distinguish them from other kinds
of issues. These identified requirements should
adequately support known higher-level policy
objectives for use of the system. An emphasis on
external-interface requirements helps prevent an
unrecognized mixing of security and design issues. Such
mixing could interfere with the
understanding of security and could impose unnecessary
constraints on the system design.
External-interface requirements for a computer system can
be described in several ways. An
elegant, but possibly difficult, approach is to limit the
discussion purely to data crossing the system
interface; this is the "black-box" approach.
The best known example of the black-box approach is
noninterference (see Section 3.2.1). Alternatively, one
can describe the system in terms of its
interactions with other entities in its environment, such
as other computing systems, users, or
processes. Finally, one can give a hypothetical
description of internal structure that ensures the
desired external-interface behavior.
In general, the system's interaction with its environment
is constrained by the sensitivity of
the information handled and by the authorizations of the
individuals and systems accessing the
system. Identified user roles, associated privileges, and
the extent to which certain roles are
security-critical also limit the system's interface to
the environment. These constraints determine
security attributes that are associated with the system's
inputs and outputs. Security attributes may
include classification, integrity, origin, ownership,
source of authorization, and intended use,
among others. The use of such attributes in the
construction of security models is discussed in
Section 3.
In the case of mandatory access control policies,
information must be accurately labeled and
handled only by authorized users. This requirement places
restrictions on how information is input
to the system and, implicitly, on how it will be
processed. Authorized handling of information is
modeled in terms of constraints on what information may
flow from one user to another:
information input to the system as classified information
should be output only to authorized
recipients.
In addition to general regulations, there are often
site-dependent and application-dependent
constraints that may need to be modeled. In particular,
there may be site-dependent constraints on
allowed security labels.
Having identified the security requirements on the system
interface, it is necessary to decide
on the requirements to be covered in the model's
definition of security. It must then be decided
which of these requirements should be modeled directly or
indirectly in terms of internal
requirements on system entities and the TCB interface.
The set of requirements to include is
constrained by minimal TCSEC requirements, the need to
adequately support relevant policy
objectives, and the need for a simple, understandable
model. The inclusion of more requirements
may provide more useful information for accreditation
once the system is evaluated, but it also
increases the difficulty of the vendor's assurance task.
The inclusion of more requirements also
suggests a more careful structuring of the model in order
to show how various aspects of security
fit together.
Several factors may influence a decision of whether to
directly include external-interface
requirements in the security model. The direct inclusion
of external-interface requirements can
help explain how the model supports higher-level policy
objectives. In the case of an application
security model, the direct modeling of user-visible
operations may be more relevant to end users,
a point of view reflected in the SMMS security model.
[LAND84] In the case of a network security
model, understanding is facilitated by modeling of the
network's interaction with hosts in its
environment, as will be discussed in Section 4.2.
2.3.2 STEP 2:
IDENTIFY INTERNAL REQUIREMENTS
To support the identified external requirements, the
system must place constraints on the
controlled entities of the system. These internal
constraints traditionally form the model's
definition of security. In a model whose definition of
security contains external-interface
requirements, internal constraints can provide a needed
bridge between the definition of security
and the rules of operation.
The controlled entities themselves should be identified
at a level of granularity that is fine
enough to allow needed security-relevant distinctions
among entities. At class B2 and above, the
controlled entities should include all (active and
passive) system resources that are accessible
outside of the TCB. For convenience, controlled entities
may be grouped into subclasses in any
way that facilitates understanding of the system. Such
groupings will depend on the system to be
modeled. For an operating system, the relevant controlled
entities might include buffers, segments,
processes, and devices. In most models, it has been
convenient to group entities according to
whether they play an active or a passive role in order to
help show how the TCB implements the
reference monitor concept . For networks and other
complex systems, identification of controlled
entities may need to be preceded by identification of
subsystems and their derived security
requirements.
Constraints on controlled entities are best stated as
general properties and relationships that
apply to all (or a broad class of) entities and accesses.
Greater generality eliminates unnecessary
constraints on the system design, improves on's intuition
about the model, and can greatly reduce
the overall effort needed to validate correctness of the
identified constraints.
The identification of necessary constraints on controlled
entities and their interactions is a
nontrivial task; familiarity with similar systems and
security models can be of great benefit. To
define the necessary constraints, it will be necessary to
label each entity with appropriate security
attributes and to identify possible kinds of
interactions, or accesses, between controlled entities. As
used here, an access is any interaction that results in
the flow of information from one entity to
another. [cf DOD88a]
In describing access constraints, it may be useful to
know that some kinds of accesses are
highly restricted, as when a process accesses a file by
executing it. The notion of causality may also
be important: a transfer of information from entity e1 to
e2 might occur because e1 wrote e2,
because e2 read e1,or because a third entity directly
copied e1 to e2 without actually reading e1. [cf
MCLE90, Sec. 2]
In the particular case of state machine models,
constraints often take the form of state
invariants, as in the work of Bell and La Padula. Recent
efforts suggest that state-transition
constraints are an attractive alternative to state
invariants for certain kinds of security requirements.
[MCLE88; NCSC90b, Sec. 6.7] The simplest well-known,
state-transition constraint is the
tranquility principle of Bell and La Padula, which says
that the security level of a controlled entity
cannot change during a state transition. Tranquility can
be artificially rephrased as a state invariant:
in any reachable state, the level of an entity coincides
with its level in the initial state. Consider,
however, the DAC requirement that a subject which gains
access to an object must possess the
necessary DAC permissions when the access request is
made. This is harder to rephrase as a state
invariant because DAC permissions can change from one
state to the next. Good tutorial examples
of state invariants and state-transition constraints may
be found in Building a Secure Computer
System [GASS87, Sec. 9.5.1, 9.5.2]; more complex examples
occur in the TRUSIX work
(NCSC90b, Sec. 2].
The number of internal requirements in a typical model
varies considerably depending on the
desired level of assurance, the complexity of the policy
and system being modeled, and the
granularity of the individual requirements. For example,
the Trusted UNIX Working Group
(TRUSIX) model covers TCSEC access control requirements
for a B3 Secure Portable Operating
System Interface for Computer Environments (POSIX) system
and has eleven state invariants and
ten state-transition constraints. [NCSC90b]
The question of which security requirements to cover in
the model's internal requirements is
answered as much by issues of good engineering practice
as by the TCSEC. At a minimum, the
model must cover the control of processes outside the
TCB. Such processes are potentially a
significant security risk because they may be of unknown
functionality and origin. According to
current practice, those portions of the TCB that do not
support user-requested computation do not
have to be modeled. For example, the security
administrator interface does not have to be modeled.
However, if significant user-requested computation is
performed by some portion of the TCB, it
should be modeled. A typical example would be a trusted
downgrading process available to
authorized users (not necessarily the security
administrator). A more extreme example would be a
multilevel database management system implemented as a
TCB subject whose database consisted
of a single highly-classified file.
Finally, there is the possibility that some security
requirements might be included in the
model, but only in the rules of operation. The rules of
operation may allow the application of good
security practice closer to the implementation level. The
rules of operation can then contain
security conditions that are not explicitly required by
the security policy. Rules of operation can
not make up for an inadequate definition of security,
however. The task of inferring a modeled
security policy from the rules of operation may be
excessively difficult, especially if the rules are
complex. [cf NCSC90b, Sec. 6.8]
2.3.3 STEP 3:
DESIGN RULES OF OPERATION FOR POLICY ENFORCEMENT
How can the modeled security requirements on system
entities be enforced? The rules of
operation answer this question in broad terms by
describing abstract interactions among system
entities with particular emphasis on access control and
other policy-enforcement mechanisms. In
the case of an operating system kernel, the rules of
operation would typically describe state
transformations and associated access checks needed to
uphold the definition of security. In the
case of a formal model, this step amounts to the
construction of a miniature FTLS. It is a useful
preliminary step, even if a full FTLS specification is
planned. The rules of operation together with
the modeled requirements on controlled entities form the
security policy model.
In giving rules of operation, it is important that system
behavior be adequately represented.
However, actual interactions among controlled entities
need not be directly specified when they
can be described as a composition of several rules of
operation. There is no need for an
implementation to directly support an individual rule
where several rules have been combined to
describe an action. An appropriate level of detail for
rules of operation is illustrated by the work of
Bell and La Padula. [BELL76] Good tutorial examples may
be found in Building a Secure
Computer System. [GASS87, § 9.5.1 (Step 3)] More complex
examples may be found in the
TRUSIX work. [NCSC90b] The rules of operation will
usually be more readable if they are not too
detailed. At class B3 and above, it is especially
important to avoid details that are not security
relevant. This is because their inclusion in the model
may force their inclusion in the TCB in order
to achieve a successful model interpretation, thereby
violating the TCB minimization
requirements. [NCSC85, Sec.3.3.3.1.1]
In the case of a B1 informal model, the rules of
operation may reasonably contain information
that, for higher evaluation classes, would be found in a
DTLS. Thus, a stronger emphasis on policy
enforcement than on policy requirements may be useful.
This is especially true if the TCB is large
and complex, as, for example, when security is
retrofitted onto a previously unevaluated system.
[BODE88]
A formal model needs to formalize the idea that a
particular state transformation is being
executed on behalf of a particular subject. Two
traditional approaches are to add an extra input to
the state transformation that gives the subject id and to
add a "current subject" field to the system
state. With the former approach, accompanying
documentation should explain clearly how the
subject-identity parameter is passed, in order to avoid
the erroneous impression that the subject is
responsible for identifying itself to the TCB. The latter
approach suggests that the system being
modeled has a single central processing unit. This may be
a problem for the model interpretation
if the system actually contains multiple CPUs. See the
TRUSIX work for further discussion.
[NCSC90b, Sec. 6.13]
Finally, in designing rules of operation, it may be
convenient to separate access decisions
from other kinds of system functionality, including the
actual establishment or removal of access.
This separation facilitates exploration of new access
control policies. Only the access decision
portion is affected by a change in policy because access
enforcement depends only on the access
decision, not on how it was made. [LAPA90, ABRA90]
Isolation of the access decision
mechanism occurs in the LOCK system design [SAYD87] and
in the security policy architecture
of Secure Ware's Compartmented Mode Workstation [NCSC91b,
Section 2.2.1.].
2.3.4 STEP 4:
DETERMINE WHAT IS ALREADY KNOWN
Usually some, if not all, aspects of the identified
security model will have been studied before.
The identification of previously used terminology allows
security issues to be presented in a
manner that is more easily understood; and making the
connection to previously studied issues may
provide valuable insight into their successful solution.
For classes B2 and above, the modeling effort must be
based on accepted principles of
mathematical exposition and reasoning. This is because
formal models and mathematical proofs
are required. The chosen mathematical formalism must
allow for an accurate description of the
security model and should provide general mechanisms for
its analysis. This is necessary so that
specific interactions among the entities of the model can
be verified as being appropriate.
In practice, needed mathematical techniques are usually
adapted from previous security
modeling efforts because security modeling, per se, is
generally much easier than the development
of new mathematical techniques. Extensive use of past
modeling techniques is especially feasible
in the case of fairly general and familiar policy
requirements. System-dependent modeling is
generally required for policy enforcement, but
established techniques are often available for
demonstrating consistency with the modeled requirements.
If new mathematical techniques are used, their
credibility is best established by exposure to
critical review, in order to uncover possible errors in
the mathematics and its intended use. This
review process is facilitated by the development of
comparative results that give useful
relationships between new models and old ones.
2.3.5 STEPS:
DEMONSTRATE CONSISTENCY AND CORRECTNESS
Since the security provided by a system is largely
determined by its security model, it is
important that the model capture needed security
requirements and that its rules of operation show
how to enforce these requirements.
The first crucial step of identifying security
requirements on the system interface cannot be
directly validated by mathematical techniques. [cf
MCLE85] Human review is needed to establish
what security requirements need to be addressed and
whether these requirements are reflected in
later mathematical formalizations. For systems in class
B2 and above, real-world interpretations
are assigned to key constructs of the formal model in
order to provide a common semantic
framework for comparing the model and the security
policy.
The appropriate technique for validating requirements on
controlled entities (Step 2) depends
partly on the novelty of the approach. Informal human
review is required to assure that the modeled
requirements support the original system security policy.
Careful comparisons with previous
models of the same or related policies may help to show
how new modeling techniques relate to
previously accepted techniques for handling particular
policy concepts. (See, for example,
[MCLE87; MCLE90, Sec. 3 & Sec. 4].) An alternate
technique is to give an external-interface
model and then mathematically prove that the constraints
on system entities imply satisfaction of
the external-interface model. The external-interface
model is easily compared with a security
policy or policy objective. The constraints on system
entities are those identified in the
requirements portion of the security policy model. This
technique is illustrated in Section 3.2.
If the rules of operation are given correctly (Step 3),
they will comply with the constraints
given in the requirements portion of the model. A formal
proof of compliance is required for
classes B2 and above. In a state-transition model, state
invariants are proved by induction: one
proves that they hold for the initial state and are
preserved by each state transition given in the rules
of operation. (See, for example, [CHEH81].)
State-transition constraints are straightforwardly
proved by showing that each state transition satisfies
the constraints.
2.3.6 STEP 6:
DEMONSTRATE RELEVANCE
The rules of operation should be a correct abstraction of
the implementation. A preliminary
model interpretation that is done as part of the modeling
process can provide an informal check on
whether the rules of operation are sensible and relevant.
This model interpretation shows how
enforcement mechanisms modeled in the rules of operation
are realized by the system. A model
interpretation explains what each model entity represents
in the system design and shows how each
system activity can be understood in terms of the given
rules of operation. Thus, for example, a
"create file" operation in the system might be
explained as involving a restricted use of the rules
for "create object," "write object,"
and/or "set permissions" in the model, depending on the actual
arguments to the "create file" command.
An appropriate, somewhat novel, example of a model
interpretation is found in the TRUSIX
work. [NCSC90b, Sec. 4] The model interpretation is
described as an informal mapping from the
TRUSIX DTLS to the TRUSIX model. This interpretation
first explains how UNIX entities are
represented in the model and the DTLS. For example,
messages, semaphores, and shared memory
are entities that the DTLS refers to as interprocess
communication (IPC) objects but that are treated
as "files" in the model. Thirty-six UNIX system
interface functions are then described by giving
pseudocode that shows how each function can be expressed
in terms of the state transformations
given by the rules of operation. In other words, the
transformations given in the rules of operation
form a toy security kernel that could be used to
implement UNIX if efficiency were irrelevant.
The SCOMP and Multics model interpretations are examples
based on Secure Computer
System: Unified Exposition and Multics Interpretation.
[BELL76]. In the SCOMP interpretation,
a set of security-relevant kernel calls and trusted
processes are identified as `SCOMP rules of
operation." [HONE85] For each such SCOMP rule, a
brief summary of security-relevant
functionality is given and then interpreted as the
combined effect of restricted use of one or more
rules from the above work by Bell. [BELL76] The specific
restrictions are enumerated in an
appendix, along with a rationale for omitting some kernel
calls and trusted functions from the
interpretation. The correspondence between the rules in
this work [BELL76] and actual SCOMP
behavior is rather complex. The Multics interpretation,
by way of contrast, is more sketchy, but the
actual correspondence appears to be simpler. [MARG85]
2.4 PRESENTATION
FOR EVALUATION AND USE
The most important factors in the successful presentation
of a security model are the
simplicity of the model, its appropriateness, and an
understanding of its intended uses.
The presentation of the model must demonstrate that the
model correctly describes the system
security policy. A clear explanation of the policy from
which the model is derived should be
available for this demonstration. Sufficiency of the
model may be demonstrated by presenting the
relationship of the model to the policy and by carefully
explaining and justifying the modeling
decisions behind this relationship. In addition to
modeled requirements, the system may support
other security requirements that are not suitable for
inclusion in the model, especially if it is a
formal model. Unmodeled security requirements can be
presented in an appendix so that TCB
developers have all of the security requirements in a
single document.
An overview of the model interpretation is needed so that
readers can understand the
relevance of the system's security model to the security
policy and to the overall system-
development process. All of these topics may be
legitimately covered in a philosophy of
protection. In fact, it is highly desirable that the
philosophy of protection be the first document
delivered by the vendor in a system evaluation, so that
it can serve as a basis for further
understanding of the security model and other system
documentation.
In the case of a formal model, an informal explanation or
presentation of the model prepared
for a general audience is highly desirable. This is
partly for reasons mentioned in Section 2.3.5 and
partly because of the general need to acquaint system
developers, implementors, and end users
with the basic security principles that are to be
supported by the system. The informal presentation
can reasonably be included in the philosophy of
protection.
A well-written explanation of the model's definition of
security can be used by potential
buyers of a secure system to determine compatibility
between the computing system and their
organization's security policies and needs. To evaluate
the ability of a computing system to support
these policies, potential users may wish to construct an
informal model of their security policies
and compare it to the definition of security supported by
the computing system. This use of the
security model and the fact that some aspects of security
modeling can only be validated by social
review suggest that portions of the security model and
the philosophy of protection be made
available to a relatively wide audience, for example,
treating them as publicly released,
nonproprietary documents.
For systems at the B2 level or above, the requirement of
mathematical proof necessitates the
presentation of a rigorous mathematical formalization as
well. For a mathematical audience,
standards of precision may preclude a style that will be
appropriate for a general audience. In this
case, an informal presentation of the model is also
needed in order to reach the general audience.
At the A1 level of assurance, the formal model is
directly involved in the formal verification
of the FTLS. As a result, it may be appropriate to
present the model in the formal specification
language of an endorsed verification system (see Appendix
B). Authors and readers must be fully
aware of the nuances of the descriptive notation of the verification
system used in order to avoid
errors due to discrepancies between author intent and
reader expectation. Furthermore, if a formal
verification system is used to check proofs, it is
necessary to achieve a correct translation of what
is to be proved into the language of the verification
system. Further discussion of these points may
be found in [FARM86; NCSC90b, Sec. 6.3].
3. SECURITY
MODELING TECHNIQUES
Having introduced the major topics involved in security
modeling, we now consider detailed
modeling issues with emphasis on mathematical structure
as well as empirical justification. In this
section, a review of basic concepts is followed by
discussions on the modeling of various kinds of
policies and objectives: nondisclosure, need-to-know,
integrity, and special-purpose policies of
particular TCB subjects.
In most cases, modeling techniques are introduced, with
details handled via references to the
available literature. Inclusion of these references does
not imply NCSC endorsement of referenced
products incorporating the techniques discussed.
3.1 BASIC CONCEPTS
As discussed in Section 2, the identification of
controlled entities plays a crucial role in the
development of a security policy model. At B2 and above,
the controlled entities must include all
system resources. If the policy is multifaceted, with
separate subpolicies for mandatory and
discretionary access controls, it may be acceptable to
decompose the system into different sets of
controlled entities for different subpolicies. A secure
computing system may decompose into data
structures, processes, information about users, I/O
devices, and security attributes for controlled
entities. In general, the number of different kinds of
entities depends on what security-relevant
distinctions are to be made. The following paragraphs
discuss how to perform such a
decomposition for typical kinds of entities, with the
goal of modeling security requirements in such
a way as to allow an accurate, useful model
interpretation.
An explicitly controlled entry is one that has explicitly
associated security attributes. In the
TRUSIX model, for example, the explicitly controlled
entities are referred to as "elements". They
consist of subjects and three kinds of objects; files,
directories, and entries (i.e., links). [NCSC90b,
Sec. 6.9-6.11] In addition to explicitly controlled
entities, a system will have implicitly controlled
entities. Such an entity might be contained in an
explicitly controlled entity or might be a
composite entity composed of explicitly controlled
entities having potentially different security
attributes.
The discussion of security attributes in this section
emphasizes security levels used for
mandatory access control because the TCSEC labeling
requirements apply primarily to mandatory
access control and auditing. However, much of what is
said about MAC labels applies to other
kinds of security attributes including, for example,
discretionary access control lists.
It is necessary to model creation and destruction of most
kinds of controlled entities. A
simpler model results if the same approach is used in all
cases. In a formal model, one can model
the creation of new controlled entities by modeling
changes in the set of all controlled entities. A
fixed set of possible controlled entities, together with
an indication of which entities are available
for use in a particular state (e.g., which subjects are
active, which objects or object-ids are
allocated) can also be used. [cf NCSC90b]
3.1.1 DATA
STRUCTURES AND STORAGE OBJECTS
In this guideline, a data structure is a repository for
data with an internal state, or value, that
can be written (i.e., changed) and/or read (i.e.,
observed) by processes (and, possibly, devices)
using well defined operations available to them. A data
structure is distinct from its value at a
particular time, which is, in turn, distinct from the
information conveyed by that value. The
information content depends not only on the value but
also on how it is interpreted. Similarly, a
data structure is distinct from a name for that data
structure.
A data structure that is explicitly associated with
exactly one security level by the security
policy model is a storage object. There are no a priori
restrictions on the level of abstraction at
which data structures and storage objects are modeled. In
particular, objects may be abstract data
structures that are accessed using high-level operations
provided by an encapsulation mechanism.
In this case, a user would have access to the high-level
operations but could not access the
encapsulated data directly via more concrete operations
that may have been used to define the high-
level operations. This lack of direct access would have
to be enforced by the TCB.
Ordinarily, the storage objects in a security model are
disjoint. This means that, in principle,
changes to one object do not force changes to other
objects. If a state-machine model is used,
disjoint storage objects can be modeled as separate
components of the underlying machine state.
If two objects at different security levels were not
disjoint, then access to data in their intersection
would be allowed or denied according to which label is
used. This ambiguity can be resolved by
explicitly associating a level with their intersection.
In this case, the associated level allows the
intersection to also be regarded as a separate storage
object, thereby restoring disjointness. Thus,
disjointness in storage objects simplifies one's
understanding of how security labels are used to
control access. It has also been argued that disjointness
simplifies covert channel analysis via
shared resource matrices.
In some systems, collections of objects are combined to
form multilevel data structures that
are assigned their own security levels. Multilevel data
structures called "containers" are used in the
Secure Military Message System (SMMS) to address
aggregation problems. [LAND84] The
level of a container must dominate the levels of any
objects or containers inside it.
When an object or other controlled entity is created, it
must be assigned security attributes and
initialized in such a way as to satisfy the object reuse
requirement. The modeling of object reuse
policies (e.g., objects are erased when allocated) can be
useful, but object reuse is not found in
traditional access control models because the object
reuse requirement deals with the content of
objects and TCB data structures. The initialization of
security attributes, however, plays an
essential role in access control and can be modeled by
distinguishing between "active" and
"inactive" entities, as in [NCSC90b]. The
security attributes of a newly created object may be taken
from, or assigned by, the subject that created it. In
many systems, creating an object is essentially
a special case of writing to it: its value changes from
undefined to null. If this change is visible to
non-TCB subjects and the new object is created by a non-TCB
subject, then the security level of
the new object must dominate that of the creating
subject. DAC attributes, by way of contrast, are
usually given by system- or user-supplied defaults.
3.1.2 PROCESSES
AND SUBJECTS
A process may create, destroy, and interact with storage
objects and other processes, and it
may interact with I/O devices. It has an associated
run-time environment and is distinct from the
program or code which defines it. For instance, the
program would ordinarily be modeled as
information contained in a storage object. An explicitly
controlled process is a subject. It normally
has a variety of associated security attributes including
a security level, hardware security
attributes such as its process domain, the user and user
group on whose behalf it is executing,
indications of whether it belongs to the TCB, and
indications of whether it is exempt from certain
access control checks.
The issues regarding disjointness of storage objects
mentioned in Section 3.1.1 apply to
subjects as well. If two subjects share memory, it is
advisable to model the shared memory as an
object separate from either subject in order to achieve
the disjointness needed for information-flow
analysis. Local memory need not be separately modeled,
but must be properly taken into account
when modeling the subject. Registers (including the
instruction pointer) are technically shared
memory but can often be treated abstractly as unshared
local memory. This is especially true if
registers are saved and restored during process swaps and
the information they contain is not
shared between processes.
Security levels for processes are ordinarily similar to
security levels for storage objects. The
TCSEC requires that a subject have a nondisclosure level
that is dominated by the clearance and
authorization of its user. A TCB subject may reasonably
be assigned separate levels for reading
and writing in order to allow partial exemption from
access control (see Section 3.4). Other TCB-
related entities may also need separate levels for
reading and writing in some systems. One such
example is /dev/null in UNIX. [GLIG86] This object is
system high in the sense that any process
can write to it; but it is system low in the sense that
any process can read from it because its value
is always null.
In general, the security-relevant attributes of a subject
are part of its run-time environment.
Some attributes are relatively static and are inherited
from the subject's executable code or are
stored with its code. In UNIX, the property of being a
set-user-id program is a statically determined
attribute, as is the effective user-id. Other attributes
are dynamically assigned and are inherited
from a subject's parent or are actively assigned by the
parent (assuming it has a parent process). In
the latter case, the parent must be relied upon to assign
the child's security attributes appropriately.
As a result the parent usually belongs to the TCB in this
latter case. A secure terminal server, for
example, might create a subject and assign it security
attributes based on the determined identity
of a user logging in.
There are potential difficulties in associating user-ids
with TCB subjects. A terminal server
would appear to operate on behalf of the user currently
logged in or on behalf of the Identification
and Authentication mechanism if no one was logged in. A
print spooler acts on behalf of the users
in its print queue. Such TCB subjects are, in reality,
associated with multiple user-ids, a fact which
is relevant to the design of the audit mechanism. A TCB
subject that does not act on behalf of a
given user can be handled either as having a dynamically
modifiable user-id or as acting on behalf
of the system (equivalently, as acting on behalf of a
system-defined pseudo-user).
When a subject creates a child subject by executing a
program, the resulting child might
belong to the TCB and be exempt from certain access
control checks, even if the original subject
was not in the TCB. This is possible if exemptions are
associated with the program object itself.
With the advent of multitasking languages such as Ada,
there is a question of when two
threads of control belong to the same subject.
Pragmatically, to be the same subject, they should
have the same security attributes. To qualify as separate
subjects, their separation should be
enforceable by the TCB. Finally, nothing explicitly
prohibits a multithreaded process from
consisting of several subjects operating at different
security levels. Of course, intraprocess
communication will be somewhat limited for such a process
unless it contains TCB subjects that
are exempt from some of the MAC constraints.
3.1.3 USERS
AND USER ROLES
User-related topics often turn up in security models in
spite of the fact that users are not
controlled entities and thus do not need to be directly
modeled. The users of a system may perform
specific user roles by executing associated role-support
programs. In general, a user may engage
in a combination of several roles. As a matter of policy,
a given user role may require system-
mediated authorization and may provide specific system
resources needed for performance of the
role. Although the following paragraphs discuss only
individual user roles, most of the basic
concepts extend to roles for other kinds of clients in
the environment of a computing system
including user groups and, in the case of a network,
hosts or subjects running on hosts.
The TCSEC requires support for certain trusted user
roles. For systems at B2 and above, these
roles include the security administrator role and the
system operator role. The administrator role
governs security attributes of users, moderates
discretionary and mandatory access control, and
interprets audit data. The operator role ensures
provision of service and performs accounting
activities. [NCSC90a] These roles may be subdivided so
that they can be shared by multiple users.
In addition, they do not preclude the addition of other
trusted roles. In general, trusted user roles
are characterized by the fact that they involve handling
security-critical information in a way that
violates access restrictions placed on non-TCB subjects.
As a result, processes that support trusted
roles can be misused and must have restricted access. By
definition, such trusted role processes
have security properties that are unacceptable without
special constraints on the behavior of their
users. These observations suggest (but do not mandate)
the modeling of support for user roles,
especially trusted user roles. Trusted role processes are
usually treated as TCB subjects. Additional
information on modeling them is given in Section 3.4.
Instructive examples of role definitions may be found in
Secure Xenix [GLIG86] and the
SMMS security model [LAND84]. Secure Xenix restructured
the Guru role into four separate
roles. The SMMS security model included a system security
officer role, a downgrader role and a
releaser role. In both of these systems, the roles
support separation of duty in that each role has
privileges not available to the other roles. Separation
of duty has been emphasized by Clark and
Wilson, who have given a general scheme for constraining
user roles by using triples of the form
(user, program, object-list) in order to control how and
whether each user may access a given
collection of objects. [CLAR87] A similar
role-enforcement mechanism is supported by type
enforcement. [BOEB85] The type-enforcement mechanism
itself assigns "types" to both subjects
and objects; subject types are referred to as
"domains." The accesses of each subject are
constrained by a "type table" based on subject
domain and object type. Each user has a set of
domains associated with subjects running on his behalf.
These domains are used to define user
roles. [cf THOM90]
3.1.4 I/O
DEVICES
Although users are external to the computing system and
need not be directly modeled, it is
still useful to model their allowed interactions with the
system in order to document security-
relevant constraints that are enforced by the system.
User interactions may be modeled in terms of
constraints on I/O devices if there is a convention for
discussing the current user of a device.
Devices which are accessible to subjects outside the TCB
should be modeled either implicitly or
explicitly as part of the interface between the non-TCB
subjects and the TCB. An additional reason
for interest in I/O devices is that I/O typically
accounts for a large portion of the TCB. The
following paragraphs present general information on the
modeling of devices with emphasis on
device security requirements and then discuss when they
should be modeled as objects, as subjects,
or as their own kind of entity.
Normally, security models discuss abstract encapsulated
devices rather than actual physical
devices. An encapsulated device is an abstract
representation of a device, its associated device
driver, and possibly other associated entities such as
attached hardware and dedicated device
buffers. Thus, for example, one might discuss a line
printer connected to the system but not the
actual RS-232 device used to achieve the connection or
its associated device driver.
By definition, an input device injects information into
the system in a way that the system
cannot entirely control. The next state of the system may
depend on the actual input as well as on
the current state and the particular state transformation
being executed. This fact can be
accommodated in several ways in an FTLS or a model that
addresses object content. One can treat
the actual input as a parameter to the transformation. If
there are only a few different input values,
one can associate different transformations with
different inputs. Finally, one can treat the
transformation as being nondeterministic, meaning that
several different states can result from
executing the transformation in a given state.
Abstract encapsulated devices are often passive entities,
in contrast to their underlying
hardware. Security requirements for devices, however,
differ significantly from those for either
storage objects or controlled processes:
· External
policy on use of the system requires that devices pass information only to
authorized users.
· Devices may
transport either unlabeled data or labeled data and are classified as single
level or multilevel devices accordingly.
· At B2 and
above, the TCSEC requires that every device have a minimum and maximum
device level that represents constraints imposed by the
physical environment in which
the device is located.
Authorized use of a device may be enforced by requiring
that any piece of information output
by the device have a security level that is dominated by
the clearance and authorization of the
recipient. A combination of procedural and automated
methods are needed to correctly associate
the security level of the information, the user who will
receive that information, and the security
level of that user. Typically, the device itself will
also have a security level. The user who receives
information from a device may well be different than the
user who sent that information to the
device. If a device with local memory (an intelligent
terminal, for example) is allocated to different
users or different security levels at different times, it
will typically need to be reset between users
in order to meet requirements on authorized transmission
of information.
Both single-level and multilevel devices may handle
multiple levels of information. A single-
level device can only handle a single level at a time but
may have some convention for changing
levels. A multilevel device, by way of contrast, can
handle different levels of data without altering
its security designation, but still might be used in such
a way as to carry data at only one fixed
security level.
The TCSEC requirement for device ranges does not explain
how they are to be used. The most
common option is to require that the level of any object
transmitted by the device be within the
range. Another option is to require that the security
clearance of any user be within the range.
Separate decisions regarding device minimum and device
maximum are also possible. In the
Trusted Xenix system, a user with a secret clearance can
have an unclassified session on a
terminal with a secret device minimum. The intended
interpretation of the device minimum is that
the device is in a restricted area that should contain
only users whose clearance is at least the device
minimum. If the device minimum is secret, then a login
attempt by an uncleared user is treated as
a violation of physical security. [GLIG86]
The question of whether devices should be modeled in the
same way as other kinds of
controlled entities depends on the complexity of the
devices involved, observed similarities
between devices and other modeled entities, and goals
relating to the simplicity and accuracy of
the model. The TRUSIX group decided to model devices in
the same way as file objects, a decision
that depended heavily on both the nature of UNIX and the
specific goals of the TRUSIX effort.
[NCSC90b, § 6.9] The SMMS model treats devices as
containers in order to capture the fact that
the device maximum must dominate the level of all data
handled by the device. [LAND84] Yet
another alternative is to model devices by modeling their
device drivers as TCB subjects. In
general, more sophisticated I/O devices need greater modeling
support, with the limiting case
being intelligent workstations modeled as autonomous
computing systems.
3.1.5 SECURITY
ATTRIBUTES
A security attribute is any piece of information that may
be associated with a controlled entity
or user for the purpose of implementing a security
policy. The attributes of controlled entities may
be implicit; they need not be directly implemented in
data structures. Labels on a multilevel tape,
for example, can be stored separately from the objects
they label, provided there is an assured
method of determining the level of each object on the
tape. [cf NCSC88b, C1-C1-05-84]
Primary attributes of security policies that are usefully
reflected in the security model include
locus of policy enforcement, strength and purpose of the
policy, granularity of user designations,
and locus of administrative authority. These policy
aspects lead to a taxonomy of policies and
security attributes.
There are several types of security attributes of any
given system: informational attributes,
access control attributes, nondisclosure attributes, and
integrity attributes. Informational attributes
are maintained for use outside the given computing
system, whereas access control attributes limit
access to system resources and the information they
contain. Purely informational attributes are
somewhat uncommon; an informative example is given in
Section 4.4. Access control attributes
may be classified according to what they control. A loose
access control attribute controls access
to the entity it is associated with, whereas a tight
access control attribute also controls access to
information contained in that entity. Thus, access
restrictions determined by tight attributes must
propagate from one object to another when (or before)
information is transferred, because control
over the information must still be maintained after it
leaves the original entity. Nondisclosure
attributes are used to prevent unauthorized release of
information, whereas integrity attributes are
used to prevent unauthorized modification or destruction
of information.
Attributes can also be classified by the granularity and
authority of their control. The user
granularity of an attribute may be "coarse,"
controlling access on the basis of broadly defined
classes of users, or it can be "per-user,"
controlling access by individual users and processes acting
on their behalf. Finally, centralized authority implies
that policy for use of attributes is predefined
and takes place under the control of a system security
administrator, whereas distributed authority
implies that attributes are set by individual users for
entities under their control. This classification
of security attributes is based partly on the work of
Abrams. [ABRA90]
When applied to typical security policies for B2 systems,
these distinctions among security
attributes might take the form given in Figure 3.1. MAC
policies must enforce nondisclosure
constraints on information and may enforce integrity constraints
as well. They must regulate access
to information on the basis of user clearance and labeled
sensitivity of data. The involvement of
user clearances typically comes at the expense of
per-user granularity because several users are
likely to have the same clearance. Authority to assign
security attributes is usually somewhat
centralized. Users can create entities at various levels,
but ability to change the levels of existing
entities is usually restricted to authorized users.
DAC policies must enforce access constraints on both
reading and writing. They must provide
per-user granularity as criteria for access decisions,
although they often include a group
mechanism for coarse gained access decisions as well. DAC
policies are normally used to enforce
both nondisclosure and integrity, but constraints on
access to named objects do not necessarily
imply corresponding constraints on access to information
in those objects. Authority to change
discretionary attributes is usually distributed among
users on the basis of ownership.
MAC DAC
Binding
Strength: Tight Loose
Purpose: Nondisclosure10 Nondisclosure & Integrity
User
Granularity: Coarse Per-user
Authority Centralized Distributed10
Figure 3.1. Typical Classification of Access Control
Policies
3.1.6 PARTIALLY
ORDERED SCURITY ATTRIBUTES
A security attribute belonging to a partially ordered set
may be referred to as a level. The
associated partial ordering may be referred to as the
dominance relation; in symbols, L1 is
dominated by L2 if and only if L1 £ L2. The use of
partially ordered levels is usually associated
with tight access control policies and constraints on
information flow. Constraints on information
flow can arise for several different reasons. As a result
a multifaceted policy might have a different
partial ordering for each reason. Often, the combined
effect of constraints associated with several
partial orderings can be expressed in terms of a single
composite ordering. In this case, facts about
Cartesian products of partially ordered sets given in
Appendix A may be used to simplify the
formal model and, possibly, the system's implementation
as well. The following paragraphs
discuss the connection between levels and constraints on
information flow, the use of these
constraints for supporting nondisclosure and integrity
objectives, and the tailoring of level-based
policies to particular applications.
A dominance relation is often viewed as an abstraction of
allowed information flows:
information can flow from entity E1 to entity E2 only if
the level of E1 is dominated by the level of
E2. This rather general view, which is an analogue of the
original *-property of Bell and La Padula,
allows the illustration of some basic issues in the use
of levels, but it is overly simple in some
respects. It does not address whether information flows
properly or whether the flow is direct or
indirect. Moreover, this view does not contain any
explicit assumption about why information may
be prevented from flowing from one entity to another.
Partially ordered levels and related constraints on
information flow have been suggested for
use in enforcing both nondisclosure and integrity
objectives. The motivation for these suggestions
may be understood from the following considerations.
Suppose that access controls could enforce
the above information-flow constraints perfectly. Suppose
that the two objects contain the same
information, but one is labeled at a higher level than
the other. In this situation, information is less
likely to be disclosed from the higher-level object
because fewer subjects have a sufficiently high
level to receive this information. Conversely, if
lower-level subjects can write higher-level objects,
then inappropriate modification of the lower-level object
is less likely because fewer subjects have
a sufficiently low level to write to it. This dual
relationship may cause the goals of nondisclosure
and integrity to conflict, especially if the ordering on
levels is strongly hierarchical. As explained
in Section 3.5, this duality between nondisclosure and
integrity has some significant limitations. A
given set of security levels designed for enforcing
nondisclosure may be in appropriate for
enforcing integrity, and not all integrity policies use
partially ordered security attributes.
When a computing system is accredited for use at a
particular site, it is assigned a host
accreditation range - a set of levels at which the host
may store, process, and transmit data. A
host range can prevent the aggregation of certain classes
of data. If several objects have different
levels and no level in the host range dominates all of
them, then there is no legitimate way of
concatenating these objects. This use of host ranges is
discussed further in Section 4.4.
A desirable constraint holds between a host range and
device ranges: if the host range contains
a level that does not belong to any device range, a
non-TCB subject running at that level can not
communicate bidirectionally without using covert
channels. By way of contrast, a device range
may reasonably contain levels not in the host range.
Suppose, for example, that A and B are
incomparable levels dominated by a level C that does not
belong to the host range. A device might
reasonably use C as a maximum device level in order to
allow use of the device at either level A
or level B. But, in this case, the system would need to
check that each object input from the device
actually belonged to the host range.
3.1.7 NONDlSCLOSURE
LEVELS
The following paragraphs discuss the structure of
nondisclosure levels as it relates to their
abstract mathematical properties, to TCSEC requirements,
and to their intended use. Analyses
given in the following paragraphs suggest that the
structure of nondisclosure levels that are used
to enforce nondisclosure policies is often not needed for
modeling purposes. If their structure plays
no significant role in a given model, their inclusion is
unnecessary and may limit the applicability
of the model.
The TCSEC requires that nondisclosure levels contain a
classification component and a
category component. The hierarchical
"classification" component is chosen from a linearly
ordered set and the nonhierarchical "category"
component must belong to a set of the form *(C),
the set of all subsets of C, for some set C of
categories. [cf NCSC85, Sec. 9.0, Sec. 3.1.1.4] In some
applications, thousands of categories may be needed. In
others, only the four clearance levels
"unclassified", "confidential",
"secret", and "top secret" are needed, as a result of
Executive Order
12356. [REAG82] These facts illustrate the importance of
configuration-dependent host
accreditation ranges to remove unused security levels.
As explained in Appendix A, any partially ordered set may
be fully embedded in one based
on categories. As a result, TCSEC constraints on
nondisclosure levels do not restrict the class of
partially ordered sets that may be used for such levels
(although these constraints do affect the use
of human-readable names). The decomposition of levels
into classification and category
components can be configuration-dependent and may be
given along with the host accreditation
range. This fact is of some interest for computing
systems with both commercial and military
applications. [cf BELL90] In this case, the model should
be general enough to embrace all intended
configurations.
Even if labels are explicitly assumed to contain
classification and category components,
nothing in the TCSEC prevents the addition of
vendor-supplied components because such
additions do not invalidate the mandated access checks.
Thus, for example, each label could
contain a release date after which the contained
information will be valueless and, therefore,
unclassified. If release dates are chronologically
ordered, later dates would represent a higher
nondisclosure level. The initial specification of release
dates, like that of other nondisclosure
attributes, needs to be handled by trusted path software.
The regrading from classified -outdated to
unclassified would be carried out by trusted software in
conformance with accepted downgrading
requirements.
A nondisclosure level is, by definition, commensurate
with the level of harm that could result
from unauthorized disclosure, and it should also be
commensurate with the level of assurance
against unauthorized disclosure that is to be found in
the system's TCB and surrounding physical
environment. Various rules of thumb have been worked out
to correlate risk with levels of
nondisclosure and assurance. [DOD88a, NCSC85a] While
these relationships are not likely to
show up in the security model itself, they may affect the
kinds of security attributes that are
included in the nondisclosure level.
3.1.8 UNLABELED
ENTITIES AND THE TRUSTED COMPUTING BASE
In addition to controlled entities, there are system
resources that either are not user accessible
or are part of the mechanism by which user-accessible
resources are controlled. These latter
resources are the software, hardware, and internal data
structures which make up the TCB. At
higher levels of assurance, significant effort goes into
minimizing the size and complexity of the
TCB in order to reduce the overall effort needed to
validate its correct operation.
The TCB typically consists of the implemented access
control mechanism and other entities
that must be protected in order to maintain the overall
security of the system. A TCB process which
is not part of the access control mechanism may be
assigned security attributes and controlled as a
subject in order to help enforce the principle of least
privilege within the TCB. Conversely, certain
subjects may need to be included within the TCB because
they assign security levels to input,
support trusted user roles, transform data in such a way
as to legitimately alter the data security
level, or perform some other security-critical function.
A data structure may also be security-
critical, as when it contains user-authentication data, a
portion of the audit trail, audit-control data,
or security attributes of controlled entities. It is not
always necessary to assign security attributes
to TCB processes and security-critical data structures,
but this is often done to enforce the principle
of least privilege within the TCB and to regulate access
by non-TCB subjects to security critical
data structures.
If a piece of data can be accessed as a direct effect of
a system call (i.e. access directly
specified in a parameter) then it must be accounted for
in the interpretation of controlled entities in
such away as to satisfy MAC requirements. But some data
structures may not be directly
accessible. Possible examples include security labels,
the current access matrix, internal object
names that are not accessible to users of the system, and
transient information related to access
control, opening of files, and so forth. A data structure
which is not directly accessible does not
have to be labeled. A decision to supply a label may
complicate the modeling process, whereas a
decision not to supply a label may increase the
difficulty of the covert channel analysis.
While there is no explicit requirement to model the TCB,
the model must capture security
requirements imposed by the TCSEC, including reference
monitor requirements relating to non-
TCB subjects and the entities they manipulate. [cf
NCSC87, Appendices B.3.4, B.7.1] A possible
approach to modeling these reference monitor requirements
is discussed in Section 3.2.4. If
significant aspects of the system security policy are
embodied in TCB subjects that are exempt
from modeled access constraints on non-TCB subjects, then
exempt subject modeling is also
needed. This topic is discussed further in Section 3.4.
3.2 NONDISCLOSURE
AND MANDATORY ACCESS CONTROL
How can nondisclosure requirements be accommodated in a
model's definition of security?
To what extent can access control succeed in enforcing
nondisclosure? What impact do
nondisclosure and access control requirements have on
trusted systems design? The first of these
questions is customarily addressed by imposing access
constraints on controlled entities (e.g., the
*-property). But various research efforts have
contributed additional approaches that provide a
useful context in which to explain how access constraints
can support nondisclosure objectives.
Both traditional and newer research-related approaches
are discussed below. The ordering is top-
down, beginning with nondisclosure requirements on the
external system interface, as in the
modeling paradigm described in Section 2.3.
Section 3.2.1 shows how nondisclosure requirements can be
formalized in an external-
interface model. In Section 3.2.2, external-interface
requirements are elaborated to obtain an
information-flow model, in order to facilitate later
analysis. Section 3.2.3 introduces the reference
monitor interface and applies the information-flow
requirements to individual subject instructions.
Section 3.2.4 presents an access-constraint model that
ensures satisfaction of the information-flow
requirements at the reference monitor interface. Finally,
Section 3.2.5 only briefly discusses rules
of operation because of their system-specific nature.
Each of the three models presented in Sections 3.2.1,
3.2.2, and 3.2.4 provides adequate
conceptual support for nondisclosure requirements found
in the TCSEC mandatory security
objective and could serve as a definition of mandatory
security in a security policy model.
Adequacy of the access-constraint model, in particular,
is established by comparison with the
previous two models. Comments regarding the impact of
these models on overall system design
are distributed among the various subsections, with the
third access-constraint model providing the
most explicit basis for designing rules of operation and
judging correctness of implementation.
These models are very simple and need to be adjusted to
accommodate policy variations
found in particular trusted systems. These models do not
address aggregation and inference. For
sake of simplicity, no accommodation is made for trusted
processes or discretionary access control.
The presented access-constraint model is especially
relevant to systems in which all user-initiated
computation is performed by subjects outside of the TCB.
It may not be adequate for systems
whose TCB contains major trusted applications (e.g., a multilevel
DBMS implemented as a TCB
subject). Finally, the entire analysis assumes that the
system to be modeled is deterministic in the
sense that its behavior is completely determined by its
combined input sequence and data initially
in the system.
3.2.1 EXTERNAL-INTERFACE
REQUIREMENTS AND MODEL
Consider a system where each input or output is labeled
with a nondisclosure level. Users
work with I/O streams containing items at a given level
and provide inputs in such a way that the
level of a given input stream accurately reflects the
sensitivity of the informatIon it contains. The
system creates each output item by extracting information
from input items (possibly at several
different levels) and affixing an appropriate label. A
combination of automated and procedural
methods is used to combine input streams into a single
input sequence and to separate the resulting
combined output sequence into separate output streams at
different levels.
The actual nondisclosure requirement is this: outputs
labeled with a given level must contain
only information whose sensitivity is dominated by that
of their label. This requirement is pictured
in Figure 3.2, where lighter shadings represent higher
information security levels: for level A
dominates for
level B, which dominates for level C.
This requirement is difficult to model (let alone
implement) because it talks about the actual
sensitivity of output information, whereas the system is
only given the attributed sensitivity of its
data. These difficulties can be avoided with the
following alternate requirement: a given labeled
output must not contain information derived from data
whose attributed sensitivity fails to be
dominated by the level of the output's label. This alternate
requirement applies to both data
supplied in the input streams, and data residing in the
system itself. This alternate requirement is
slightly stronger than the original provided that
information at a given level cannot be synthesized
by aggregation and inference from information at strictly
lower levels. In this case, any classified
information in the system either came from the input
stream or was already contained in the system
when it was installed level .
Figure 3.2 Intended Use of a Secure System
In the first external-interface model, each item in the
system's input stream is taken to be a
labeled value, as is each item in the output stream.
There are two "nondisclosure security"
requirements which are given relative to an arbitrary
level L:
Noninterference:
Any output stream at level L remains unchanged when
inputs at levels not dominated by L are
altered or removed.
Nonobservability:
Any output stream at level L remains unchanged when data
in the system whose sensitivity is
not dominated by L is altered or removed.
These two terms and the requirements they name are
similar; the only distinction is that
noninterference discusses independence from high-level
input whereas nonobservability
discusses independence from high-level data in the
system.
As with any mathematical modeling effort, there is a need
to specify the physical
interpretation of the model. There are also choices to be
made as to which aspects of the system's
observable behavior are actually addressed by this
external-interface model. An "accurate"
interpretation of this model is a physical system whose
I/O streams and data are related according
to the above two requirements. In a "complete"
interpretation of this model, the input stream would
contain all external influences on the system being
modeled; the output stream would contain all
observable effects of the system on its environment; and
the data in the system would include all
data that can influence the value of the output stream.
An accurate interpretation can be "useful"
without being complete if it includes all outputs
associated with normal use as well as enough of
the inputs and system state to predict the included
outputs. It is standard engineering practice to
avoid details that would make the modeling problem
intractable and then consider them in a
separate covert channel analysis.
The noninterference requirement is due to Goguen and
Meseguer. (GOGU82] Under useful
interpretations, this requirement rules out
resource-exhaustion channels associated with those
aspects of the system that are covered by the model's
interpretation. Suppose that some system
resource (such as memory) is used for processing both
low-level and high-level inputs, and that the
processing of low-level inputs cannot proceed when that
resource is unavailable. In this case, the
system may not emit a low-level diagnostic explaining the
nature of the problem, since the
diagnostic could reveal "interference" by
high-level input. The low-level diagnostic, if allowed,
would have provided a resource-exhaustion channel.
The nonobservability requirement was developed as part of
the LOCK verification effort. It
covers situations in which classified data is entered
during system configuration using information
paths not addressed in the security modeling process. A
superficially stronger requirement is that
the system initially contains no classified information.
This stronger requirement occurs implicitly
in the original noninterference models of Goguen and
Meseguer. [GOGU82, GOGU84] With this
stronger requirement, useful physical interpretations
would need to include any classified inputs
that occurred during the construction, installation, or
booting of the system.
3.2.2 INFORMATION-FLOW
MODEL
The information-flow model is discussed next because of
its close relationship to
noninterference. The requirements of this model are
motivated by an informal view of how
information flows through a deterministic state-machine
system. The possible paths of information
flow during a state transition are depicted as arrows in
Figure 3.3, where I, O, and S abbreviate
input, output, and state, respectively
.
Figure 3.3. Information Flows in a Deterministic State Machine
Each input is assumed to induce a state transition and a
(possibly empty) sequence of labeled
outputs. As indicated in the above diagram, there are
just four possible flows: directly from input
to output, from an input to the next system state, from a
given state to the next state, and from a
given state to an output. Correspondingly, there are four
flow-security requirements for the
information-flow model that must hold for any
nondisclosure level L. They refer to "portions" of
the state, meaning collections of variables (i.e., state
components):
I/O Security:
An output at level L can only be induced by an input
whose level is dominated by L.
I/S Security:
An input at level L can affect only those portions of the
system state whose levels
dominate L.
S/O Security:
An output at level L can depend only on those portions of
the system state whose levels
are dominated by L.
S/S Security:
A portion of the state which is at level L can affect
only those portions of the state whose
levels dominate L.
To see the effect of these requirements, suppose, for
example, that the current time is
maintained as a state component that is implicitly
incriminated by every input instruction
according to the time needed for its execution. The I/S
security property implies that the clock level
must dominate every level in the input stream because
every input affects this particular state
component. This observation does not imply that all
"system" clocks have to be system high,
however. One possibility is to partition time into
several disjoint "slices." This partitioning
effectively creates a virtual clock for each time slice.
Processes running in a given time slice affect
only the virtual clock associated with that time slice,
so that the level of the virtual clock need only
dominate the levels of these processes. Consequently, a
process that reads the virtual clock for its
time slice must have a level that dominates those of
other processes running in that time slice.
The four requirements of the information-flow model imply
those of the nondisclosure-
requirements model. This fact is an example of an
"unwinding" theorem in that it shows how to
recast nondisclosure in terms of individual inputs and
state transitions. An informal justification of
this fact can be given as follows. First, consider the
nonobservability requirement: information at
a given level L in the output stream cannot come directly
from portions of the state not dominated
by L (by the S/O security property), and it cannot come
indirectly from a preceding state transition
(by the S/S security property). Now consider
noninterference: information in the output stream at
a given level L cannot come directly from inputs not
dominated by L (by the I/O security property),
and it cannot come indirectly via an intermediate system
state as a result of the I/S security and
nonobservability properties.
All four of the flow-security requirements are necessary
for noninterference. Moreover, there
is a partial converse: in the case of systems that
contain "print" commands capable of outputting
arbitrary state components, the four flow-security
requirements follow from the nondisclosure
requirements.
This information-flow model is similar to those of
Feiertag, Levitt, and Robinson [FEIE77]
but it makes some minor improvements: an input that
causes a state change may also induce output;
a given input may induce outputs at several different
levels; and it is not required that each input
be associated with an identified user. The correctness of
this model with respect to the
nondisclosure-requirements model is formally proven in
[WILL91]. The result is a variant of the
unwinding theorem of Goguen and Meseguer. [GOGU84,
RUSH85] An exposition of Rushby's
treatment of the unwinding theorem can be found in the
article "Models of Multi level Security."
[MILL89]
3.2.3 APPLICATION
TO THE REFERENCE MONITOR INTERFACE
Security policy models traditionally emphasize the
reference monitor interface and cover the
processing of subject instructions but ignore issues
associated with the sequencing of subject
instructions and their synchronization with external
inputs. These ignored issues are handled
separately via covert channel analysis. This is due to
the lack of general, well-developed modeling
techniques for dealing with time, concurrence, and
synchronization. Subject-instruction
processing, by way of contrast, is readily modeled. In
particular, the above external-interface and
information-flow models can be used for
subject-instruction processing, just by giving them a new
physical interpretation.
Under this new interpretation, the inputs of the state
machine are the instructions that subjects
execute, including system traps whose semantics are
defined by the TCB's kernel-calI software.
External system inputs are also included in the case of
"input instructions." Each instruction is
executed to produce a state change and zero or more
outputs. The outputs include external system
outputs and, possibly, feedback to the unmodeled
instruction-sequencing mechanism.
Notice that subjects do not literally execute
instructions (since they are untrusted). The TCB
itself executes each subject instruction on behalf of an
associated subject controlled by the TCB.
In particular, each hardware instruction available to
processes outside of the TCB (i.e., each "user-
mode" instruction) is executed by the CPU, which is
part of the TCB. To ensure nondisclosure
security, all subject instructions, including user-mode
hardware instructions, must satisfy the
reinterpreted model requirements, either by virtue of the
hardware design or by enforced
restrictions on their use. For example, security may be
violated if a subject can follow a kernel call
with a "branch-to-previous C ontext"
instruction that inadvertently restores all of the access
privileges used during the processing of that kernel
call. Instructions implemented by the hardware
but not used by compilers should be modeled if the
compilers are bypassable. In the unusual case
where non-TCB subjects can directly execute microcode
instructions, these too need to be
modeled.
The actual accesses of a given subject to various objects
in its environment are determined by
the instructions it executes (or attempts to execute).
Therefore, it is this stream of subject
instructions that the reference validation mechanism must
mediate in order to carry out the
recommendations of the Anderson Report. [ANDE72] The
application of noninterference and
information flow to subject-instruction processing dates
back to [FEIE77] where a form of
noninterference is referred to as "property
P1." The validation of noninterference as applied to
LOCK subject-instruction processing is presented in
[HAIG87a; FINE90]. Keefe and Tsai have
adapted noninterference for use in modeling DBMS
schedulers. [KEEF90] It can be shown that
information flow for subject-instruction processing,
together with a variant of noninterference for
subject-instruction sequencing, implies noninterference
and nonobservability for the entire system.
[WlLL91]
3.2.4 ACCESS--CONSTRAINT
MODEL
An access-constraint model can be obtained by expanding
the information-flow model of
instruction processing to include traditional notions of
access control, including subjects, objects,
a current-access matrix, and access constraints. This is
not a complete access control model in the
traditional sense because it lacks rules of operation. It
is a definition of mandatory security for
instruction processing; it does not show how access
constraints are actually enforced.
The access-constraint model assumes that the instruction
processing state is made up of
labeled state components called objects. The model does
not explicitly assume that subjects are
controlled processes, but it does assume that every
computation involving either access to objects
or output has an associated subject. Each subject has a
nondisclosure level and is assumed to
include its local data space (including stack, program
counter, and so forth). Consequently, each
subject is also considered to be an object that could
passively be acted on by other subjects. The
system state, st, contains a "current-access matrix,"
Ast (s, o), that associates each subject-object
pair with a set of "modes." For simplicity, the
possible modes are taken to be just "observe" and
"modify."
The requirements of the access-constraint model fall into
three groups: traditional
requirements, constraints on the semantics of observation
and modification, and I/O requirements.
These requirements are formulated for systems with
file-like objects that are opened (in accordance
with simple security and the *-property), accessed for a period
of time (in accordance with the
observe-semantics and modify-semantics requirements), and
then closed. Each of the eight
requirements must hold in every reachable state.
Simple Security:
A subject may have observe access to an object only if
its level dominates that of the
object.
*-Property:
A subject may have modify access to an object only if its
level is dominated by that of
the object.
Tranquility:
The level of a given subject or object is the same in
every reachable state.
Variants of simple security and the *-property are found
in virtually all mandatory security
models. The tranquility requirement can be weakened
without compromising the mandatory
security objective, but possibly at the expense of a more
complicated model. [cf MCLE88]
The requirements which constrain the semantics of reading
and writing are a major factor in
deciding what checks must appear in the rules of
operation. Other major factors include the actual
system design and the degree of detail needed in the
model.
Observe Semantics:
A subject that executes an instruction whose behavior
depends on the value of some state
component must have observe access to that state
component.
Modify Semantics:
A subject that executes an instruction which modifies a
given state component must have
modify access to that state component.
The observe-semantics requirement is slightly stronger
than necessary. A subject (e.g., a mail
program) that knows the existence of two objects at a higher
level might reasonably cause
information to be transferred from one to the other by
means of a "blind" copy instruction, but this
is directly ruled out by the observe-semantics
requirement. As noted by McLean [MCLE90, Sec.
4], Haigh's analysis contains a similar restriction.
[HAIG84] A very careful treatment of what
constitutes observation may be found in "A Semantics
of Read." [MARC86] The use of a
semantics of reading and writing may be found also in
several other security modeling efforts,
including those by Cohen, [COHE77] Popek, [POPE78] and
Landwehr [LAND84].
The following requirements constrain allowed associations
between subjects and I/O streams.
They assume that each input is read on behalf of an
associated subject referred to as its "reader."
Reader Identification:
The decision as to which subject is the reader for a
given input must be based only on
information whose level is dominated by that of the
reader.
Reader Authorization:
The level of the data read must be dominated by that of
the reader.
Writer Authorization:
A subject that executes an instruction which produces an
output must have a level that is
dominated by that of the output.
In some implementations, the associations between inputs
and subjects are relatively static, and
their validation is straightforward. In others, subjects
are created dynamically to service inputs as
they arrive, and explicit modeling may be useful.
If the eight requirements of this access-constraint model
are satisfied, then so are the
requirements of the information-flow model. [WILL91] This
observation supports the thesis that
access constraints can provide an adequate definition of
mandatory security. Related comparisons
of access control models and information-flow models may
be found in the works by Gove and
Taylor. [GOVE84, TAYL84] Unfortunately, this
access-constraint model also shares some
potential weaknesses of the previous models. In
particular, use of the simple security and *-
properties to enforce nondisclosure rests on the
following implicit assumption: a non-TCB subject
either outputs information at its own level or outputs
information of an unknown lower level that
must, therefore, be given worst-case protection. This
assumption ignores the possibility that a
process may be able to produce information which is more
highly classified than its inputs through
some form of aggregation or inference. Security models
which address this possibility in the case
of database management systems are discussed in Section
4.3.
3.2.5 TAILORING
THE MODELS
The remaining tasks in modeling nondisclosure are to
tailor the definition of mandatory
security to meet specific system needs and to provide
rules of operation describing the kinds of
actions that will be exhibited by the system being
modeled. The following paragraphs discuss
adaptations relating to lack of current access and the
desirability of modeling error diagnostics,
trusted operations, and nondeterminacy.
In most systems there are some operations that access
objects without being preceded by an
operation that provides access permission. For these
operations, authorization must be checked on
every access, and either the model or its interpretation
must treat the combined effects of the simple
security and observe-semantics properties, and of the
*-property and modify-semantics properties.
If this is done in the model, the result is as follows:
Observe Security:
A subject may execute an instruction whose behavior
depends on the value of an object
only if its security level dominates that of the object.
Modify Security:
A subject may execute an instruction that modifies an
object only if its level dominates
that of the object.
These axioms omit reference to the traditional
current-access matrix and are particularly well-
suited to systems that do not have an explicit mechanism
for granting access permissions.
Although it is necessary to model unsuccessful execution
resulting from attempted security
violations, it is not necessary to model resulting error
diagnostics. If the model only covers normal
use of the system, it is both acceptable and traditional
to omit error diagnostics, as would typically
be the case in an informal model of a B1 system. For
higher evaluation classes, however, an
available option is to give detailed rules of operation
that explicitly model some or all error returns.
Their inclusion in the model can provide an alternative
to examining them by means of a more
traditional covert channel analysis, as well as
additional information for judging correctness of the
system's design and implementation. Error diagnostics
resulting from unsuccessful instruction
executions can reasonably be modeled either as output or
as information written into the subject's
data space.
A variant of the above modeling strategy has been carried
out for the LOCK system. The
LOCK verification is based on noninterference and
nonobservability applied to subject-instruction
processing (as opposed to the entire system). The inputs
consist of LOCK kernel requests and user-
mode machine instructions. LOCK uses a
"conditional" form of noninterference in which certain
"trusted" inputs are explicitly exempted from
the noninterference requirement. The LOCK model
was elaborated by means of an unwinding theorem and then
augmented to obtain an access control
model. Technically, the LOCK noninterference verification
is an extension of traditional access
control verification because the first major step in
proving noninterference was to verify the
traditional Bell & La Padula properties for the LOCK
access control model. This access-control
verification represents about half of the LOCK
noninterference verification evidence. The LOCK
developers compared noninterference verification with a
traditional covert channel analysis
technique based on shared resource matrices. [HAIG87,
FINE89] They have since concluded that
the noninterference approach is preferable, especially if
both nonobservability and noninterference
are verified, because of the extensive hand analysis
associated with the shared resource matrix
approach.
Noninterference has been generalized to nondeterministic
systems in several ways. A variety
of nonprobabilistic generalizations has been proposed for
dealing with nondeterminacy, but they
do not provide a full explanation of nondisclosure
because of the possibility of noisy information
channels. [WITT90] Despite this limitation,
nonprobabilistic generalizations of noninterference
provide useful insight into the nature of security in
distributed systems. An interesting result is that
a security model can be adequate for sequential systems,
but is not adequate for a distributed
system. This is because the process of "hooking
up" its sequential components introduces new
illegal information channels that are not addressed by
the model. [MCCU88a] A state-machine
model that overcomes this lack of "hook-up"
security has been provided by McCullough.
[MCCU88] It relies on state-transition techniques and,
like the original Goguen and Meseguer
models, has a demonstrated compatibility with traditional
design verification methodologies.
3.3 NEED-TO-KNOW
AND DISCRETIONARY ACCESS CONTROL
Discretionary access control (DAC) mechanisms typically
allow individual users to protect
objects (and other entities) from unauthorized disclosure
and modification. Many different DAC
mechanisms are possible, and these mechanisms can be
tailored to support a wide variety of user-
-controlled security policy objectives. Users may impose
need-to-know constraints by restricting
read access and may guard the integrity of their files by
restricting write access. As explained
below, the use of group names may also allow specific
objects and processes to be associated with
specific user roles in support of least privilege.
Discretionary security mechanisms are more varied
and tend to be more elaborate than mandatory mechanisms.
The policy requirements for them are
weaker in order to allow for this variation. As a result,
a well-understood discretionary security
model can play a larger role both in clarifying what is
provided in a particular system and in
encouraging an elegant security design.
Traditionally, systems have been built under the
assumption that security objectives related to
DAC are both user-enforced and user-supplied. A variety
of well-known weaknesses are traceable
to this assumption. By way of contrast, vendor cognizance
of user security objectives allows the
development of a DAC security model whose mechanisms
correctly support higher-level, user-
enforced security policies. Moreover, modeling of these
higher-level policies would provide a
suitable basis for validating correctly designed DAC
mechanisms and for supplying guidance on
their use for policy enforcement.
DAC mechanisms and requirements are summarized in Section
3.3.1. Group mechanisms and
their use in supporting user roles are covered in Section
3.3.2.