|
C TECHNICAL REPORT 79-91
Library No. S-237,254
(IDA PAPER P-2316)
September 1991
INTEGRITY IN AUTOMATED
INFORMATION SYSTEMS
Prepared for
National Computer Security Center (NCSC)
by
Terry Mayfield
J. Eric Roskos
Stephen R. Welke
John M. Boone
INSTITUTE FOR DEFENSE ANALYSES
1801 N. Beauregard Street, Alexandria, Virginia 22311
FOREWORD
This NCSC Technical Report, ``Integrity in Automated Information Systems,''
is
issued by the National Computer Security Center (NCSC) under the authority
of and in
accordance with Department of Defense (DoD) Directive 5215.1, ``Computer
Security
Evaluation Center.'' This Publication contains technical observations,
opinions, and
evidence prepared for individuals involved with computer security.
Recommendations for revision to this publication are encouraged and will
be
reviewed periodically by the NCSC. Address all proposals for revision
through
appropriate channels to:
National Computer Security Center
9800 Savage Road
Fort George G. Meade, MD 20755-6000
Attention: Chief, Standards, Criteria & Guidelines Division
Reviewed by:_________________________________ September 1991
RON S. ROSS, LTC (USA)
Chief, Standards, Criteria & Guidelines Division
Released by:_________________________________ September 1991
THOMAS R. MALARKEY
Chief, Office of Computer Security Publications and Support
TABLE OF CONTENTS
1. INTRODUCTION................................................................................................
1
1.1 PURPOSE.........................................................................................................
1
1.2 BACKGROUND..............................................................................................
1
1.3 SCOPE...............................................................................................................
3
2. DEFINING INTEGRITY........................................................................................
5
2.1 DATA INTEGRITY.........................................................................................
6
2.2 SYSTEMS INTEGRITY...................................................................................
6
2.3 INFORMATION SYSTEM PROTECTION GOALS...................................
7
2.4 INTEGRITY GOALS........................................................................................
8
2.4.1 Preventing Unauthorized Users From Making Modifications..........
8
2.4.2 Maintaining Internal and External Consistency...................................
8
2.4.3 Preventing Authorized Users From Making Improper Modifications....
9
2.5 CONCEPTUAL CONSTRAINTS IMPORTANT TO INTEGRITY................. 9
2.5.1 Adherence to a Code of Behavior.............................................................
10
2.5.2 Wholeness......................................................................................................
11
2.5.3 Risk Reduction.............................................................................................
11
3. INTEGRITY PRINCIPLES........................................................................................
15
3.1 IDENTITY..............................................................................................................
15
3.2 CONSTRAINTS...................................................................................................
16
3.3 OBLIGATION.....................................................................................................
16
3.4 ACCOUNTABILITY............................................................................................
17
3.5 AUTHORIZATION.............................................................................................
18
3.6 LEAST PRIVILEGE...........................................................................................
18
3.7 SEPARATION.....................................................................................................
19
3.8 MONITORING...................................................................................................
20
3.9 ALARMS.................................................................................................................
21
3.10 NON-REVERSIBLE ACTIONS...........................................................................
21
3.11 REVERSIBLE ACTIONS......................................................................................
22
3.12 REDUNDANCY.....................................................................................................
22
3.13 MINIMIZATION....................................................................................................
23
3.13.1 Variable Minimization..................................................................................
23
3.13.2 Data Minimization.......................................................................................
24
3.13.3 Target Value Minimization......................................................................
24
3.13.4 Access Time Minimization.........................................................................
24
3.14 ROUTINE VARIATION.....................................................................................
25
3.15 ELIMINATION OF CONCEALMENT...........................................................
25
3.16 ACCESS DETERRENCE..................................................................................
26
4. INTEGRITY MECHANISMS................................................................................
27
4.1 POLICY OF IDENTIFICATION AND AUTHENTICATION.................. 29
4.1.1 Policy of User Identification and Authentication...............................
29
4.1.2 Policy of Originating Device Identification........................................
32
4.1.2.1 Mechanism of Device Identification..........................................
32
4.1.3 Policy of Object Identification and Authentication...........................
33
4.1.3.1 Mechanism of Configuration Management..............................
. 37
4.1.3.2 Mechanism of Version Control...................................................
38
4.1.3.3 Mechanism of Notarization.........................................................
38
4.1.3.4 Mechanism of Time Stamps........................................................
39
4.1.3.5 Mechanism of Encryption............................................................
39
4.1.3.6 Mechanism of Digital Signatures...............................................
40
4.2 POLICY OF AUTHORIZED ACTIONS......................................................
40
4.2.1 Policy of Conditional Authorization....................................................
41
4.2.1.1 Mechanism Conditional Enabling.................................................
41
4.2.1.2 Mechanism of Value Checks.........................................................
42
4.2.2 Policy of Separation of Duties...............................................................
43
4.2.2.1 Mechanism of Rotation of Duties................................................
45
4.2.2.2 Mechanism of Supervisory Control.............................................
46
4.2.2.3 Mechanism of N-Person Control.................................................
47
4.2.2.4 Mechanism of Process Sequencing..............................................
47
4.3 POLICY OF SEPARATION OF RESOURCES.............................................
48
4.3.1 Policy of Address Separation..................................................................
49
4.3.1.1 Mechanism of Separation of Name Spaces..................................
49
4.3.1.2 Mechanism of Descriptors...............................................................
50
4.3.2 Policy of Encapsulation..............................................................................
51
4.3.2.1 Mechanism of Abstract Data Types.................................................
52
4.3.2.2 Mechanism of Strong Typing............................................................
53
4.3.2.3 Mechanism of Domains......................................................................
54
4.3.2.4 Mechanism of Actors..........................................................................
54
4.3.2.5 Mechanism of Message Passing.......................................................
55
4.3.2.6 Mechanism of the Data Movement Primitives................................
56
4.3.2.7 Mechanism of Gates............................................................................
56
4.3.3 Policy of Access Control.............................................................................
56
4.3.3.1 Mechanism of Capabilities................................................................
57
4.3.3.2 Mechanism of Access Control Lists..................................................
57
4.3.3.3 Mechanism of Access Control Triples............................................
58
4.3.3.4 Mechanism of Labels.........................................................................
59
4.4 POLICY OF FAULT TOLERANCE...................................................................
60
4.4.1 Policy of Summary Integrity Checks.........................................................
60
4.4.1.1 Mechanism of Transmittal Lists........................................................
60
4.4.1.2 Mechanism of Checksums..................................................................
61
4.4.1.3 Mechanism of Cryptographic Checksums........................................
61
4.4.1.4 Mechanism of Chained Checksums.........................................
62
4.4.1.5 Mechanism of the Check Digit.................................................
62
4.4.2 Policy of Error Correction..................................................................
62
4.4.2.1 Mechanism of Duplication Protocols......................................
63
4.4.2.2 Mechanism of Handshaking Protocols...................................
63
4.4.2.3 Mechanism of Error Correcting Codes....................................
64
5. INTEGRITY MODELS AND MODEL IMPLEMENTATIONS.................. 67
5.1 INTEGRITY MODELS.................................................................................
67
5.1.1 Biba Model...........................................................................................
67
5.1.1.1 Discussion of Biba......................................................................
67
5.1.1.1.1 Low-Water Mark Policy...................................................
69
5.1.1.1.2 Low-Water Mark Policy for Objects...............................
69
5.1.1.1.3 Low Water Mark Integrity Audit Policy........................
69
5.1.1.1.4 Ring Policy..........................................................................
70
5.1.1.1.5 Strict Integrity Policy........................................................
70
5.1.1.2 Analysis of Biba..........................................................................
71
5.1.2 GOGUEN AND MESEGUER MODEL............................................
72
5.1.2.1 Discussion of Goguen and Meseguer.......................................
72
5.1.2.1.1 Ordinary State Machine Component..............................
73
5.1.2.1.2 Capability Machine Component.....................................
74
5.1.2.1.3 Capability System.............................................................
74
5.1.2.2 Analysis of Goguen and Meseguer........................................
75
5.1.3 SUTHERLAND MODEL....................................................................
76
5.1.3.1 Discussion of Sutherland..........................................................
76
5.1.3.2 Analysis of Sutherland..............................................................
78
5.1.4 CLARK AND WILSON MODEL.....................................................
78
5.1.4.1 Discussion of Clark and Wilson..............................................
78
5.1.4.2 Analysis of Clark and Wilson..................................................
80
5.1.5 BREWER AND NASH MODEL...........................................................
82
5.1.5.1 Discussion of Brewer and Nash..................................................
82
5.1.5.2 Analysis of Brewer and Nash......................................................
85
5.1.6 SUMMARY OF MODELS......................................................................
86
5.2 INTEGRITY MODEL IMPLEMENTATIONS..............................................
86
5.2.1 LIPNER IMPLEMENTATION................................................................
87
5.2.1.1 Discussion of Lipner.......................................................................
87
5.2.1.2 Analysis of Lipner...........................................................................
88
5.2.2 BOEBERT AND KAIN IMPLEMENTATION......................................
90
5.2.2.1 Discussion of Boebert and Kain.....................................................
90
5.2.2.2 Analysis of Boebert and Kain..........................................................
91
5.2.3 LEE AND SHOCKLEY IMPLEMENTATIONS......................................
92
5.2.3.1 Discussion of Lee and Shockley.......................................................
92
5.2.3.2 Analysis of Lee and Shockley...........................................................
93
5.2.4 KARGER IMPLEMENTATION.................................................................
94
5.2.4.1 Discussion of Karger..........................................................................
94
5.2.4.2 Analysis of Karger..............................................................................
95
5.2.5 JUENEMAN IMPLEMENTATION...........................................................
96
5.2.5.1 Discussion of Jueneman.....................................................................
96
5.2.5.1.1 Subject Integrity Label...............................................................
97
5.2.5.1.2 Data File Integrity Label...........................................................
97
5.2.5.1.3 Program Integrity Label............................................................
98
5.2.5.2 Analysis of Jueneman..........................................................................
98
5.2.6 GONG IMPLEMENTATION.......................................................................
99
5.2.6.1 Discussion of Gong...............................................................................
99
5.2.6.2 Analysis of Gong....................................................................................
102
5.2.7 SUMMARY OF MODEL IMPLEMENTATIONS.......................................
103
5.3 GENERAL ANALYSIS OF MODELS AND
MODEL IMPLEMENTATIONS..........................................................................
103
5.3.1 Hierarchical Levels..................................................................................
104
5.3.2 Non-hierarchical categories...................................................................
104
5.3.3 Access Control Triples...........................................................................
104
5.3.4 Protected Subsystems.............................................................................
105
5.3.5 Digital Signatures/Encryption..............................................................
105
5.3.6 Combination of Capabilities and ACLs................................................
105
5.3.7 Summary of General Analysis...............................................................
105
6. CONCLUSIONS.....................................................................................................
107
6.1 SUMMARY OF PAPER...................................................................................
107
6.2 SIGNIFICANCE OF PAPER............................................................................
108
6.3 FUTURE RESEARCH.......................................................................................
109
REFERENCE LIST........................................................................................................
111
APPENDIX - GENERAL INTEGRITY PRINCIPLES............................................
117
1. TRADITIONAL DESIGN PRINCIPLES..............................................................
117
1.1 ECONOMY OF MECHANISM......................................................................
117
1.2 FAIL-SAFE DEFAULTS...................................................................................
118
1.3 COMPLETE MEDIATION..............................................................................
118
1.4 OPEN DESIGN.................................................................................................
118
1.5 SEPARATION OF PRIVILEGE.......................................................................
118
1.6 LEAST PRIVILEGE...........................................................................................
118
1.7 LEAST COMMON MECHANISM.................................................................
119
1.8 PSYCHOLOGICAL ACCEPTABILITY..........................................................
119
2. ADDITIONAL DESIGN PRINCIPLES....................................................................
119
2.1 WORK FACTOR.................................................................................................
119
2.2 COMPROMISE RECORDING.........................................................................
120
3. FUNCTIONAL CONTROL LEVELS..............................................................
120
3.1 UNPROTECTED SYSTEMS.....................................................................
120
3.2 ALL-OR-NOTHING SYSTEMS...............................................................
121
3.3 CONTROLLED SHARING......................................................................
121
3.4 USER-PROGRAMMED SHARING CONTROLS................................
121
3.5 LABELLING INFORMATION...............................................................
121
ACRONYMS........................................................................................................
123
GLOSSARY...........................................................................................................
125
LIST OF FIGURES
Figure 1. Integrity Framework.........................................................................
13
Figure 2. Cascade Connection of Capability System....................................
74
LIST OF TABLES
TABLE 1. Integrity Mechanisms Grouped by Policy and SubPolicy.............
28
EXECUTIVE SUMMARY
As public, private, and defense sectors of our society have become increasingly
dependent on widely used interconnected computers for carrying out critical
as well as
more mundane tasks, integrity of these systems and their data has become
a significant
concern. The purpose of this paper is not to motivate people to recognize
the need for
integrity, but rather to motivate the use of what we know about integrity
and to
stimulate more interest in research to standardize integrity properties
of systems.
For some time, both integrity and confidentiality have been regarded
as inherent
parts of information security. However, in the past, more emphasis has
been placed on
the standardization of confidentiality properties of computer systems.
This paper shows
that there is a significant amount of information available about integrity
and integrity
mechanisms, and that such information can be beneficial in starting to
formulate
standardizing criteria. We have gone beyond the definition of integrity
and provided
material that will be useful to system designers, criteria developers,
and those
individuals trying to gain a better understanding of the concepts of data
and systems
integrity. This paper provides foundational material to continue the efforts
toward
developing criteria for building products that preserve and promote integrity.
We begin by discussing the difficulty of trying to provide a single definition
for the
term integrity as it applies to data and systems. Integrity implies meeting
a set of defined
expectations. We want a system that protects itself and its data from
unauthorized or
inappropriate actions, and performs in its environment in accordance with
its users'
expectations. We also expect internal data and any transformations of
that data to
maintain a correct, complete and consistent correspondence to itself and
to what it
represents in the external environment. Addressing these multiple views
in a single
definition is difficult. We conclude that a single definition is not needed.
An operational
definition, or framework, that encompasses various views of the issue
seems more
appropriate. The resulting framework provides a means to address both
data and
systems integrity and to gain an understanding of important principles
that underlie
integrity. It provides a context for examining integrity preserving mechanisms
and for
understanding the integrity elements that need to be included in system
security
policies.
We extract a set of fundamental principles related to integrity. These
are based on
our framework, a review of various written material on the topic of integrity,
and an
investigation of existing mechanisms deemed to be important to preserving
and
promoting integrity. These principles underlie the wide variety of both
manual and
automated mechanisms that are examined. The mechanisms have been categorized
to
show that they serve a relatively small set of distinct purposes or policies.
Some
mechanisms that promote integrity are not documented in traditional literature
and not
all of the mechanisms addressed here are implemented in computer systems.
All of these
do, however, provide insight into some of the controls necessary and the
types of threats
that automated integrity mechanisms must counter. We also provide an overview
of
several models and model implementations (paper studies) of integrity.
These models
are still rather primitive with respect to the range of coverage suggested
by examining
both data and systems integrity. The model we found to be receiving the
most attention
at this time is the Clerk-Lesion Model. Although this is not a formal
mathematical
model, it provides a fresh and useful point of departure for examining
issues of
integrity.
From this study, we conclude that it is possible to begin to standardize
data and
systems integrity properties. Principles exist, trial policies can be
formulated and
modelled, and mechanisms can be applied at various layers of abstraction
within a
system. The Institute for Defense Analyses (IDA) has initiated a follow-on
study to look
at the allocation and layering of mechanisms. We also conclude that there
are gaps in our
information and that the standardization process could help guide certain
studies. Such
studies should include the analysis of existing interfaces and protocols
to determine the
appropriate integrity interfaces or the need to design new protocols.
Other
demonstration/validation studies should be conducted to show that mechanisms
are
workable, interfaces are well understood, protocol concepts are valid,
and standardized
criteria are testable. We conclude that criteria development efforts can
occur
concurrently with the protocol and demonstration/validation studies.
ACKNOWLEDGMENTS
The National Computer Security Center extends special recognition to
the principle
authors from the Institute for Defense Analyses (IDA): Terry Mayfield
(Task Leader), Dr.
J. Eric Roskos, Stephen R. Welke, John M. Boone, and Catherine W. McDonald,
as well
as the Project Leader (NSA C81), Maj. Melvin De Vilbiss (USA).
We wish to thank the external reviewers who provided technical comments
and
suggestions to earlier versions of this report. Their contributions have
caused this
document to evolve significantly from the original efforts. We wish also
to express
appreciation to the principle reviewers at IDA, Dr. Karen Gordon and Dr.
Cy Ardoin, for
their technical support. A special thanks goes to Katydean Price for her
tremendous
editorial support during the course of this project.
The principle authors have dedicated this document in memory of their
close friend,
Dr. J. Eric Roskos-a talented computer scientist and colleague who performed
much of
the original research for this effort. His tragic death left a tremendous
gap in the research
team. Eric is often thought of and very much missed.
1 INTRODUCTION
1.1 PURPOSE
This paper provides a framework for examining integrity in computing
and an
analytical survey of techniques that have potential to promote and preserve
computer
system and data integrity. It is intended to be used as a general foundation
for further
investigations into integrity and a focus for debate on those aspects
of integrity related to
computer and automated information systems (AISs).
One of the specific further investigations is the development and evolution
of
product evaluation criteria to assist the U.S. Government in the acquisition
of systems
that incorporate integrity preserving mechanisms. These criteria also
will help guide
computer system vendors in producing systems that can be evaluated in
terms of
protection features and assurance measures needed to ascertain a degree
of trust in the
product's ability to promote and preserve system and data integrity. In
support of this
criteria investigation, we have provided a separate document [Mayfield
1991] that
offers potential modifications to the Control Objectives contained in
the Trusted
Computer System Evaluation Criteria (TCSEC), DOD 5200.28-STD [DOD 1985].
The
modifications extend the statements of the control objectives to encompass
data and
systems integrity; specific criteria remain as future work.
1.2 BACKGROUND
Integrity and confidentiality are inherent parts of information security
(INFOSEC).
Confidentiality, however, is addressed in greater detail than integrity
by evaluation
criteria such as the TCSEC. The emphasis on confidentiality has resulted
in a significant
effort at standardizing confidentiality properties of systems, without
an equivalent effort
on integrity. However, this lack of standardization effort does not mean
that there is a
complete lack of mechanisms for or understanding of integrity in computing
systems. A
modicum of both exists. Indeed, many well-understood protection mechanisms
initially
designed to preserve integrity have been adopted as standards for preserving
confidentiality. What has not been accomplished is the coherent articulation
of
requirements and implementation specifications so that integrity property
standardization can evolve. There is a need now to put a significant effort
on
standardizing integrity properties of systems. This paper provides a starting
point.
The original impetus for this paper derives from an examination of computer
security requirements for military tactical and embedded computer systems,
during
which the need for integrity criteria for military systems became apparent.
As the
military has grown dependent on complex, highly interconnected computer
systems,
issues of integrity have become increasingly important. In many cases,
the risks related
to disclosure of information, particularly volatile information which
is to be used as soon
as it is issued, may be small. On the other hand, if this information
is modified between
the time it is originated and the time it is used (e.g., weapons actions
based upon it are
initiated), the modified information may cause desired actions to result
in failure (e.g.,
missiles on the wrong target). When one considers the potential loss or
damage to lives,
equipment, or military operations that could result when the integrity
of a military
computer system is violated, it becomes more apparent why the integrity
of military
computer systems can be seen to be at least as important as confidentiality.
There are many systems in which integrity may be deemed more important
than
confidentiality (e.g., educational record systems, flight-reservation
systems, medical
records systems, financial systems, insurance systems, personnel systems).
While it is
important in many cases that the confidentiality of information in these
types of systems
be preserved, it is of crucial importance that this information not be
tampered with or
modified in unauthorized ways. Also included in this categorization of
systems are
embedded computer systems. These systems are components incorporated to
perform
one or more specific (usually control) functions within a larger system.
They present a
more unique aspect of the importance of integrity as they may often have
little or no
human interface to aid in providing for correct systems operation. Embedded
computer systems are not restricted to military weapons systems. Commercial
examples include anti-lock braking systems, aircraft avionics, automated
milling
machines, radiology imaging equipment, and robotic actuator control systems.
Integrity can be viewed not only in the context of relative importance
but also in the
historical context of developing protection mechanisms within computer
systems. Many
protection mechanisms were developed originally to preserve integrity.
Only later were
they recognized to be equally applicable to preserving confidentiality.
One of the
earliest concerns was that programs might be able to access memory (either
primary
memory or secondary memory such as disks) that was not allocated to them.
As soon as
systems began to allocate resources to more than one program at a time
(e.g.,
multitasking, multiprogramming, and time-sharing), it became necessary
to protect the
resources allocated to the concurrent execution of routines from accidentally
modifying
one another. This increased system concurrency led to a form of interleaved
sharing of
the processor using two or more processor states (e.g., one for problem
or user state and
a second for control or system state), as well as interrupt, privilege,
and protected
address spaces implemented in hardware and software. These ``mechanisms''
became
the early foundations for ``trusted'' systems, even though they generally
began wit the
intent of protecting against errors in programs rather than protecting
against malicious
actions. The mechanisms were aids to help programmers debug their programs
and to
protect them from their own coding errors. Since these mechanisms were
designed to
protect against accidents, by themselves or without extensions they offer
little protection
against malicious attacks.
Recent efforts in addressing integrity have focused primarily on defining
and
modelling integrity. These efforts have raised the importance of addressing
integrity
issues and the incompleteness of the TCSEC with respect to integrity.
They also have
sparked renewed interest in examining what needs to be done to achieve
integrity
property standardization in computing systems. While a large portion of
these efforts
has been expended on attempting to define the term integrity, the attempts
have not
achieved consensus. However, many of these definitions point toward a
body of
concepts that can be encompassed by the term integrity. This paper takes
one step
further in that it not only proposes an operational definition of integrity,
but also
provides material for moving ahead without consensus. This is done through
an
examination of various integrity principles, mechanisms, and the policies
that they
support as well as an examination of a set of integrity models and model
implementations
1.3 SCOPE
Our examination of integrity takes several viewpoints. We begin in Section
2 by
looking at the issue of defining integrity. Here we build a framework
or operational
definition of integrity that will serve our purpose in analyzing mechanisms
that provide
integrity. This framework is derived from a number of sources, including:
(1) what
people generally say they mean when they discuss having a system provide
integrity, (2)
from dictionary definitions, and (3) other writings on the topic that
we have interpreted
to provide both specific integrity goals and a context for data and system
integrity.
In Section 3, we extract a set of fundamental principles from these goals
and
contextual interpretations. Principles are the underlying basis on which
policies and
their implementing mechanisms are built. An additional set of basic protection
design
principles, extracted from Saltzer & Schroeder's tutorial paper, The
Protection of
Information in Computer Systems [Saltzer 1975], has been provided as an
appendix for
the convenience of the reader. These design principles apply to the general
concept of
protection and, thus, are important additional considerations for standardizing
integrity
preserving properties in computer systems.
Next, in Section 4, we examine a wide variety of manual and automated
mechanisms
that address various problems related to integrity. Most of these mechanisms,
evolving
over the course of many years, remain in use today. Several of the mechanisms
intended
to promote integrity are not documented in traditional computer security
literature.
Not all of the mechanisms we examine are implemented in computer systems,
although
they give insight into the types of controls that need to be provided
and the types of
threats that must be countered by automated integrity mechanisms. Some
of the
mechanisms we examine appear primarily in embedded systems and others
are found in
more familiar application environments such as accounting. The mechanisms
have been
categorized to show that they serve a relatively small set of distinct
purposes. We use the
term policy to describe the higher-level purpose (categorization) of a
mechanism since
such a purpose generally reflects administrative courses of action devised
to promote or
preserve integrity.
Independent of the mechanisms a small number of formal models has been
established with differing approaches to capturing integrity semantics.
In Section 5, we
examine several models that have been proposed in the last decade to address
issues of
integrity. Several paper studies have suggested implementations of these
models as
possibilities for real systems. We also look at a number of these model
implementations
intended to promote or preserve integrity. This examination provides us
with a better
understanding of the sufficiency of coverage provided by the proposed
models and
model implementations.
Finally, in Section 6, we present our study conclusions and recommend
a set of
further studies that should be performed to enhance our understanding
of integrity and
better enable us to standardize integrity protection properties in systems.
A reference list is provided at the end of the main body; a list of acronyms
and a
glossary are provided after the appendix.
2 DEFINING INTEGRITY
Integrity is a term that does not have an agreed definition or set of
definitions for use
within the INFOSEC community. The community's experience to date in trying
to define
integrity provides ample evidence that it doesn't seem to be profitable
to continue to try
and force a single consensus definition. Thus, we elect not to debate
the merits of one
proposed definition over another. Rather, we accept that the definitions
generally all
point to a single concept termed integrity.
Our position is reinforced when we refer to a dictionary; integrity has
multiple
definitions [Webster 1988]. Integrity is an abstract noun. As with any
abstract noun,
integrity derives more concrete meaning from the term(s) to which it is
attributed and
from the relations of these terms to one another. In this case, we attribute
integrity to two
separate, although interdependent, terms, i.e., data and systems. Bonyun
made a similar
observation in discussing the difficulty of arriving at a consensus definition
of integrity
[Bonyun 1989]. He also recognized the interdependence of the terms systems
and data in
defining integrity, and submitted the proposition that ``in order to provide
any measure
of assurance that the integrity of data is preserved, the integrity of
the system, as a
whole, must be considered.''
Keeping this proposition in mind, we develop a conceptual framework or
operational definition which is in large part derived from the mainstream
writing on the
topic and which we believe provides a clearer focus for this body of information.
We
start by defining two distinct contexts of integrity in computing systems:
data integrity,
which concerns the objects being processed, and systems integrity, which
concerns the
behavior of the computing system in its environment. We then relate these
two contexts
to a general integrity goal developed from writings on information protection.
We
reinterpret this general goal into several specific integrity goals. Finally,
we establish
three conceptual constraints that are important to the discussion of the
preservation and
promotion of integrity. These definitions, specific goals, and conceptual
constraints
provide our framework or operational definition of integrity from which
we extract
integrity principles, analyze integrity mechanisms and the policies they
implement, and
examine integrity models and model implementations. A diagram of this
framework is
found in Figure 1 at the end of this section.
2.1 DATA INTEGRITY
Data integrity is what first comes to mind when most people speak of
integrity in
computer systems. To many, it implies attributes of data such as quality,
correctness,
authenticity, timeliness, accuracy, and precision. Data integrity is concerned
with
preserving the meaning of information, with preserving the completeness
and
consistency of its representations within the system, and with its correspondence
to its
representations external to the system. It involves the successful and
correct operation of
both computer hardware and software with respect to data and, where applicable,
the
correct operations of the users of the computing system, e.g., data entry.
Data integrity is
of primary concern in AISs that process more than one distinct type of
data using the
same equipment, or that share more than one distinct group of users. It
is of concern in
large scale, distributed, and networked processing systems because of
the diversity and
interaction of information with which such systems must often deal, and
because of the
potentially large and widespread number of users and system nodes that
must interact
via such systems.
2.2 SYSTEMS INTEGRITY
Systems integrity is defined here as the successful and correct operation
of
computing resources. Systems integrity is an overarching concept for computing
systems, yet on that has specific implications in embedded systems whose
control is
dependent on system sensors. Systems integrity is closely related to the
domain of fault
tolerance. This aspect of integrity often is not included in the traditional
discussions of
integrity because it involves an aspect of computing, fault tolerance,
that is often
mistakenly relegated to the hardware level. Systems integrity is only
superficially a
hardware issue, and is equally applicable to the AIS environment; the
embedded system
simply has less user-provided fault tolerance. In this context, it also
is related closely to
the issue of system safety, e.g., the safe operation of an aircraft employing
embedded
computers to maintain stable flight. In an embedded system, there is usually
a much
closer connection between the computing machinery and the physical, external
environment than in a command and control system or a conventional AIS.
The
command and control system or conventional AIS often serves to process
information
for human users to interpret, while the embedded system most often acts
in a relatively
autonomous sense.
Systems integrity is related to what is traditionally called the denial
of service
problem. Denial of service covers a broad category of circumstances in
which basic
system services are denied to the users. However, systems integrity is
less concerned
with denial of service than with alteration of the ability of the system
to perform in a
consistent and reliable manner, given an environment in which system design
flaws can
be exploited to modify the operation of the system by an attacker.
For example, because an embedded system is usually very closely linked
to the
environment, one of the fundamental, but less familiar, ways in which
such an attack
can be accomplished is by distorting the system's view of time. This type
of attack is
nearly identical to a denial-of-service attack that interferes with the
scheduling of time-
related resources provided by the computing system. However, while denial
of service
is intended to prevent a user from being able to employ a system function
for its
intended purpose, time-related attacks on an embedded system can be intended
to alter,
but not stop, the functioning of a system. System examples of such an
attack include the
disorientation of a satellite in space or the confusing of a satellite's
measurement of the
location of targets it is tracking by forcing some part of the system
outside of its
scheduling design parameters. Similarly, environmental hazards or the
use of sensor
countermeasures such as flares, smoke, or reflectors can cause embedded
systems
employing single sensors such as infrared, laser, or radar to operate
in unintended ways.
When sensors are used in combination, algorithms often are used to fuse
the sensor
inputs and provide control decisions to the employing systems. The degree
of
dependency on a single sensor, the amount of redundancy provided by multiple
sensors, the dominance of sensors within the algorithm, and the discontinuity
of
agreement between sensors are but a few of the key facets in the design
of fusion
algorithms in embedded systems. It is the potential design flaws in these
systems that
we are concerned with when viewing systems from the perspective of systems
integrity.
2.3 INFORMATION SYSTEM PROTECTION GOALS
Many researchers and practitioners interested in INFOSEC believe that
the field is
concerned with three overlapping protection goals: confidentiality, integrity,
and
availability. From a general review of reference material, we have broadly
construed
these individual goals as having the following meanings:
1. Confidentiality denotes the goal of ensuring that information is protected
from improper disclosure.
2. Integrity denotes the goal of ensuring that data has at all times
a proper
physical representation, is a proper semantic representation of informa-
tion, and that authorized users and information processing resources
perform correct processing operations on it.
3. Availability denotes the goal of ensuring that information and information
processing resources both remain readily accessible to their authorized
us-
ers.
The above integrity goal is complete only with respect to data integrity.
It remains
incomplete with respect to systems integrity. We extend it to include
ensuring that the
services and resources composing the processing system are impenetrable
to
unauthorized users. This extension provides for a more complete categorization
of
integrity goals, since there is no other category for the protection of
information
processing resources from unauthorized use, the theft of service problem.
It is
recognized that this extension represents an overlap of integrity with
availability.
Embedded systems require one further extension to denote the goal of consistent
and
correct performance of the system within its external environment.
2.4 INTEGRITY GOALS
Using the goal previously denoted for integrity and the extensions we
propose, we
reinterpret the general integrity, goal into the following specific goals
in what we believe
to be the order of increasing difficulty to achieve. None of these goals
can be achieved
with absolute certainty; some will respond to mechanisms known to provide
some
degree of assurance and all may require additional risk reduction techniques.
2.4.1 Preventing Unauthorized Users From Making Modifications
This goal addresses both data and system resources. Unauthorized use
includes the
improper access to the system, its resources and data. Unauthorized modification
includes changes to the system, its resources, and changes to the user
or system data
originally stored including addition or deletion of such data. With respect
to user data,
this goal is the opposite of the confidentiality requirement: confidentiality
places
restrictions on information flow out of the stored data, whereas in this
goal, integrity
places restrictions on information flow into the stored data.
2.4.2 Maintaining Internal and External Consistency
This goal addresses both data and systems. It addresses self-consistency
of
interdependent data and consistency of data with the real-world environment
that the
data represents. Replicated and distributed data in a distributed computing
system add
new complexity to maintaining internal consistency. Fulfilling a requirement
for
periodic comparison of the internal data with the real-world environment
it represents
would help to satisfy both the data and systems aspects of this integrity
goal. The
accuracy of correspondence may require a tolerance that accounts for data
input lags or
for real-world lags, but such a tolerance must not allow incremental attacks
in smaller
segments than the tolerated range. Embedded systems that must rely only
on their
sensors to gain knowledge of the external environment require additional
specifications
to enable them to internally interpret the externally sensed data in terms
of the
correctness of their systems behavior in the external world.
It is the addition of overall systems semantics that allows the embedded
system to
understand the consistency of external data with respect to systems actions.
1. As an example of internal data consistency, a file containing a monthly
summary of transactions must be consistent with the transaction records
themselves.
2. As an example of external data consistency, inventory records in an
ac-
counting system must accurately reflect the inventory of merchandise on
hand. This correspondence may require controls on the external items as
well as controls on the data representing them, e.g., data entry controls.
The accuracy of correspondence may require a tolerance that accounts for
data input lags or for inventory in shipment, but not actually received.
3. As an example of systems integrity and its relationship to external
consist-
ency, an increasing temperature at a cooling system sensor may be the
re-
sult of a fault or an attack on the sensor (result: overlooking of the
space)
or a failure of a cooling system component, e.g., freon leak (result:
over-
heating of the space). In both cases, the automated thermostat (embedded
system) could be perceived as having an integrity failure unless it could
properly interpret the sensed information in the context of the thermostat's
interaction with the rest of the system, and either provide an alert of
the ex-
ternal attack or failure, or provide a controlling action to counter the
attack
or overcome the failure. The essential requirement is that in order to
have
the system maintain a consistency of performance with its external environ-
ment, it must provided with an internal means to interpret and flexibility
to adapt to the external environment.
2.4.3 Preventing Authorized Users From Making Improper Modifications
The final goal of integrity is the most abstract, and usually involves
risk reduction
methods or procedures rather than absolute checks on the part of the system.
Preventing improper modifications may involve requirements that ethical
principles not
be violated; for example, an employee may be authorized to transfer funds
to specific
company accounts, but should not make fraudulent or arbitrary transfers.
It is, in fact,
impossible to provide absolute ``integrity'' in this sense, so various
mechanisms are
usually provided to minimize the risk of this type of integrity violation
occurring.
2.5 CONCEPTUAL CONSTRAINTS IMPORTANT TO INTEGRITY
There are three conceptual constraints that are important to the discussion
of
integrity. The first conceptual constraint has to do with the active entities
of a system.
We use the term agents to denote users and their surrogates. Here, we
relate one of the
dictionary definitions [Webster 1988] of integrity, adherence to a code
of behavior, to
actions of systems and their active agents. The second conceptual constraint
has to do
with the passive entities or objects of a system. Objects as used here
are more general
than the storage objects as used in the TCSEC. We relate the states of
the system and its
objects to a second of Webster's definitions of integrity, wholeness.
We show that the
constraint relationships between active agents and passive entities are
interdependent.
We contend that the essence of integrity is in the specification of constraints
and
execution adherence of the active and passive entities to the specification
as the active
agent transforms the passive entity. Without specifications, one cannot
judge the
integrity of an active or passive entity. The third system conceptual
constraint deals with
the treatment of integrity when there can be no absolute assurance of
maintaining
integrity. We relate integrity to a fundamental aspect of protection,
a strategy of risk
reduction. These conceptual constraints, placed in the context of data
integrity and
systems integrity and the previous discussions on integrity goals, provide
the
framework for the rest of the paper.
2.5.1 Adherence to a Code of Behavior
Adherence to a code of behavior focuses on the constraints of the active
agents under
examination. It is important to recognize that agents exist at different
layers of
abstraction, e.g., the user, the processor, the memory management unit.
Thus, the focus
on the active agents is to ensure that their actions are sanctioned or
constrained so that
they cannot exceed established bounds. Any action outside of these bounds,
if
attempted, must be prevented or detected prior to having a corrupting
effect. Further,
humans, as active agents, are held accountable for their actions and held
liable to
sanctions should such actions have a corrupting effect. One set of applied
constraints are
derived from the expected states of the system or data objects involved
in the actions.
Thus, the expected behaviors of the system's active agents are conditionally
constrained
by the results expected in the system's or data object's states. These
behavioral
constraints may be statically or dynamically conditioned.
For example, consider a processor (an active agent) stepping through
an application
program (where procedural actions are conditioned or constrained) and
arriving at the
conditional instruction where the range (a conditional constraint) of
a data item is
checked. If the program is written with integrity in mind and the data
item is ``out of
range,'' the forward progress of the processor through the applications
program is halted
and an error handling program is called to allow the processor to dispatch
the error.
Further progress in the application program is resumed when the error
handling
program returns control of the processor back to the application program.
A second set of applied constraints are derived from the temporal domain.
These
may be thought of as event constraints. Here, the active agent must perform
an action or
set of actions within a specified bound of time. The actions may be sequenced
or
concurrent, they may be performance constrained by rates (i.e., actions
per unit of time),
activity time (e.g., start & stop), elapsed time (e.g., start + 2hrs),
and by discrete time
(e.g., complete by 1:05 p.m.)
Without a set of specified constraints, there is no ``code of behavior''
to which the
active agent must adhere and, thus, the resultant states of data acted
upon are
unpredictable and potentially corrupt.
2.5.2 Wholeness
Wholeness has both the sense of unimpaired condition (i.e., soundness)
and being
complete and undivided (i.e., completeness) [Webster 1988]. This aspect
of integrity
focuses on the incorruptibility of the objects under examination. It is
important to
recognize that objects exist a different layers of abstraction, e.g.,
bits, words, segments,
packets, messages, programs. Thus, the focus of protection for an object
is to ensure that
it can only be accessed, operated on, or entered in specified ways and
that it otherwise
cannot be penetrated and its internals modified or destroyed. The constraints
applied
are those derived from the expected actions of the system's active agents.
There are also
constraints derived from the temporal domain. Thus, the expected states
of the system or
data objects are constrained by the expected actions of the system's active
agents.
For example, consider the updating of a relational database with one
logical update
transaction concurrently competing with another logical update transaction
for a portion
of the set of data items in the database. The expected actions for each
update are based
on the constraining concepts of atomicity, i.e., that the actions of a
logical transaction
shall be complete and that they shall transform each involved individual
data item from
one unimpaired state to a new unimpaired state, or that they shall have
the effect of not
carrying out the update at all; servility i.e., the consecutive ordering
of all actions in the
logical transaction schedule; and mutual exclusion, i.e., exclusive access
to a given data
item for the purpose of completing the actions of the logical transaction.
The use of
mechanisms such as dependency ordering, locking, logging, and the two-phase
commit
protocol enable the actions of the two transactions to complete leaving
the database in a
complete and consistent state.
2.5.3 Risk Reduction
Integrity is constrained by the inability to assure absoluteness. The
potential results
of actions of an adversarial attack, or the results of the integrity failure
of a human or
system component place the entire system at risk of corrupted behavior.
This risk could
include complete system includes relatively assured capabilities provided
by protection
mechanisms plus measures to reduce the exposure of human, system component,
and
data to loss of integrity should be pursued. Such a risk reduction strategy
could include
the following:
a) Containment to construct ``firewalls'' to minimize exposures and opportuni-
ties to both authorized and unauthorized individuals, e.g., minimizing,
sep-
arating, and rotating data, minimizing privileges of individuals, separat-
ing responsibilities, and rotating individuals.
b) Monitors to actively observe or oversee human and system actions,
to con-
trol the progress of the actions, log the actions for later review, and/or
alert other authorities of inappropriate action.
c) Sanctions to apply a higher risk (e.g., fines, loss of job, loss of
professional
license, prison sentence) to the individual as compared to the potential
gain from attempting, conducting, or completing an unauthorized act.
d) Fault tolerance via redundancy, e.g., databases to preserve data or
proces-
sors to preserve continued operation in an acknowledged environment of
faults. Contingency or backup operational sites are another form of redun-
dancy. Note: layered protection, or protection in depth, is a form of
redun-
dancy to reduce dependency on the impenetrability of a single protection
perimeter.
e) Insurance to replace the objects or their value should they be lost
or dam-
aged, e.g., fire insurance, theft insurance, and liability insurance.
(Figure 1. Not available for electronic version.)
Figure 1. Integrity Framework
3 INTEGRITY PRINCIPLES
``There is a large body of principles from among which those pertinent
to any
application environment can be selected for incorporation into specific
policy
statements. There is a need to identify as many as possible of those principles
as might
be of sufficiently general benefit to warrant their inclusion in a list
of such principles
from which the formulators of policy can select, cafeteria-style, those
appropriate to their
needs'' [Courtney 1989].
In this section we discuss important underlying principles that can be
used in the
design of integrity policies and their supporting or implementing mechanisms.
These
principles involve not only those that we believe are fundamental to integrity,
but also
those which underlie risk reduction with respect to integrity. These principles
were
developed from a review of various written material on the topic of integrity,
from our
framework formulated in the previous section, and by an investigation
of existing
mechanisms deemed to be important to preserving and promoting integrity.
3.1 IDENTITY
The principle of identity is fundamental to integrity in that it defines
``sameness in all
that constitutes the objective reality of a thing: oneness; and is the
distinguishing
character of a thing: individuality'' [Webster 1988]. Identity allows
one to distinguish
and name or designate an entity. It is through identity that relationships
are attributed
and named. It is through identity that functions are distinguished and
named.
Identification of users, programs, objects, and resources includes both
their
classification, i.e., their membership in classes of entities that will
be treated in the same
or similar manner, and their individuation, i.e., their uniqueness that
will allow the
individual entities to be addressed separately. It is through the process
of identity that
one can establish the specification of wholeness and a specification of
behavior.
All protected systems requiring authorization and accountability of individuals
depend on the unique identification of an individual human user. User
identities need to
be protected from being assumed by others. User identities need to be
authenticated to
confirm that the claimed identity has been validated by a specific protocol
executed
between the system and the unique user. Further, to ensure traceability
throughout the
system, the individual identity must be maintained for its entire period
of activity in the
system.
Identity, through the use of conventions for naming, attributing, labelling,
abstracting, typing, and mapping, can provide for separation and control
of access to
entities. Objects created within the system may require additional attribution
to expand
the dimensional scope of their identity to meet specific system objectives
such as
confidentiality, proof of origin, quality, or timeliness.
Another fundamental dimension of both subject and object identity is
the
conveyance of identity attributes via the relationships of inheritance
or replication.
Inheritance relationships include part-whole, parent-child, and type instantiation.
Attributes of interest include privileges conveyed by users to other users
or to surrogate
subjects (processes acting on behalf of users), and authenticity of origin
conveyed to
object copies. This aspect of identity is important to most identity-based
policies for
access control, especially with respect to the propagation, review, and
revocation of
privileges or object copies.
3.2 CONSTRAINTS
The principle of constraints is fundamental to integrity. A constraint
denotes the state
of an active agent being checked, restricted, or compelled to perform
some action. This is
central to the conceptual constraint of adherence to a code of behavior-or
to what others
have termed ``expected behavior.'' Constraints establish the bounds of
(integrity)
actions. When viewed from the context of objects, constraints are the
transformation
restrictions or limitations that apply in transforming an object from
an initial state to a
new specified (constrained) state. Constraints establish the bounds of
(integrity) states.
3.3 OBLIGATION
The binding, constraining, or commitment of an individual or an active
agent to a
course of action denotes the principle of obligation. Obligation is another
fundamental
principle of integrity. It is reflected in the terms duty (required tasks,
conduct, service,
and functions that constitute what one must do and the manner in which
it shall be
done) and responsibility (being answerable for what one does). The bound
course of
action, or constraint set, is generally interpreted as always being required
or mandatory
and not releasable until the course of action comes to a natural conclusion
or specified
condition. However, the sense of obligation is lost should the individual
or active agent
become corrupted, i.e., the binding is broken rather than released. In
this sense, an active
agent within a system, once initiated, is bound to proceed in its specified
actions until it
reaches a natural or specified termination point or until the state of
the system reaches a
failure or corruption point that drives the active agent away from the
course of action to
which it is bound. This failure or corruption point could be the result
of an individual
yielding to the temptation to perform an unauthorized action either alone
or in collusion
with others. It also could be the result of faulty contact with the external
environment
(e.g., undetected input error at a sensor), loss of support in the internal
environment
(e.g., hardware failure), contact with corrupted objects (e.g., previously
undetected
erroneous states), or contact with another corrupted active agent (e.g.,
improper
versioning in the runtime library).
There is also a temporal dimension to the course of action to which an
active agent
becomes bound. This dimension binds sequencing, sets deadlines, and establishes
bounds of performance for the active agent. Obligation is then thought
of in terms of
initiation or completion timing, e.g., eventually starting or completing,
beginning or
finishing within an elapsed time, initiating or ending at a specified
clock time, initiating
or completing in time for a new course of action to begin, or completing
a specified
number of action cycles in a specified time. System designers, especially
those involved
in real-time or deadline-driven systems, use the temporal dimension of
obligation to
develop time slices for concurrent processes. Significant obligation issues
in time slicing
include interprocess communication synchronization and the access of concurrent
processes to shared data.
One example of obligation is the concept of protocols, which are obligatory
conventions or courses of action for external and/or internal active entities
to follow in
interacting with one another. Protocols can constrain the states of data
or information to
be exchanged, a sequence of actions, or the mutual exclusion or synchronization
of
concurrent asynchronous actions sharing resources or data objects.
3.4 ACCOUNTABILITY
Integrity, from the social and moral sense, implies that an individual
has an
obligation to fulfill and that the individual is answerable to a higher
(legal or moral)
authority who may impose sanctions on the individual who fails to adhere
to the
specified code of action. Holding the individual answerable is the principle
of
accountability, from which requirements are derived to uniquely identify
and
authenticate the individual, to authorize his actions within the system,
to establish a
historical track or account of these actions and their effects, and to
monitor or audit this
historical account for deviations from the specified code of action. The
enforcement
strength of sanctions may impact some individuals more than others; simply
a reminder
of what is expected and the consequences of not meeting those expectations
may prove
useful in promoting and preserving integrity.
3.5 AUTHORIZATION
One aspect of binding the active entity to a course of action is that
of authorization. In
essence, authorization is the right, privilege, or freedom granted by
one in authority
upon another individual to act on behalf of the authority. Employing the
principle of
authorization provides one means of distinguishing those actions that
are allowed from
those which are not. The authority may be the leader of an organization,
an
administrator acting on behalf of that leader, or the owner of a particular
asset who may
grant another individual access to that asset. The authority may not only
grant access to
a particular asset, but may also prescribe a specific set of constrained
actions that ensue
from the access authorization. Thus, there is a binding between the individual,
the
course of action, and the asset(s) to be acted upon. Attempting to perform
outside of
these privilege bounds without additional authority is an integrity violation.
Authorizations may be granted for a particular action or for a period
of time;
similarly, authorization may be revoked. Authorized actions may be further
constrained
by attributes of the authority, the recipient, and the object to be acted
upon. For example,
in many systems, the creator of a data object becomes its owner gaining
discretionary
authority to grant access, revoke granted accesses, and restrict modes
of access to that
data object. Such access authorization is identity based. However, access
to that object
may be constrained by certain of its attributes (identified by labels).
These constraints
may reflect an augmenting rules-based access policy that mandatory checking
of
corresponding attributes in the individual be accomplished in accordance
with specified
rules prior to completing the access authorization. These attributes could
include
National Security Classification Markings, other organizational sensitivity
hierarchies or
compartmentation, or label attributes related to the quality, e.g., lower
quality, ``initial
draft,'' associated with document transcribers vs higher quality, ``final
edited draft,''
associated with document editors.
There may be a requirement in certain systems to provide for the dynamic
enabling
or overriding of authorizations. Whether or not the conditions for enabling
or
override are to be predetermined or left to the judgement of the user,
explicit procedures
or specific accountable action to invoke an enabling or bypass mechanism
should be
provided.
3.6 LEAST PRIVILEGE
Privileges are legal rights granted to an individual, role, or subject
acting on the
behalf of a user that enable the holder of those rights to act in the
system within the
bounds of those rights. The question then becomes how to assign the set
of system
privileges to the aggregates of functions or duties that correspond to
a role of a user
or subject acting on behalf of the user. The principle of least privilege
provides the
guidance for such assignment. Essentially, the guidance is that the active
entity should
operate using the minimal set of privileges necessary to complete the
job. The purpose
of least privilege is to avoid giving an individual the ability to perform
unnecessary
(and potentially harmful) actions merely as a side-effect of granting
the ability to
perform desired functions. Least privilege provides a rationale for where
to install the
separation boundaries that are to be provided by various protection mechanisms.
Least privilege will allow one individual to have different levels of
privilege at
different times, depending on the role and/or task being performed. It
also can have the
effect of explicitly prohibiting any one individual from performing another
individual's
duties. It is a policy matter as to whether additional privileges are
``harmless'' and thus
can be granted anyway. It must be recognized that in some environments
and with some
privileges, restricting the privilege because it is nominally unnecessary
may
inconvenience the user. However, granting of excess privileges that potentially
can be
exploited to circumvent protection, whether for integrity or confidentiality,
should be
avoided whenever possible. If excess privileges must be granted, the functions
requiring
those privileges should be audited to ensure accountability for execution
of those
functions.
It is important that privileges and accesses not persist beyond the time
that they are
required for performance of duties. This aspect of least privilege is
often referred to as
timely revocation of trust. Revocation of privileges can be a rather complex
issue when it
involves a subject currently acting on an object or who has made a copy
of the object and
placed it in the subject's own address space.
3.7 SEPARATION
Separation refers to an intervening space established by the act of setting
or keeping
something apart, making a distinction between things, or dividing something
into
constituent parts. The principle of separation is employed to preserve
the wholeness of
objects and a subject's adherence to a code of behavior. It is necessary
to prevent objects
from colliding or interfering with one another and to prevent actions
of active agents
from interfering or colluding with one another. Further, it is necessary
to ensure that
objects and active agents maintain a correspondence to one another so
that the actions of
one agent cannot effect the states of objects to which that agent should
not have
correspondence, and so that the states of objects cannot affect the actions
of agents to
which they should not have correspondence.
One example of separation is the concept of encapsulation, which is the
surrounding
of a set of data, resources, or operations by an apparent shield to provide
isolation, (e.g.,
isolation from interference or unspecified access). With encapsulation,
the protection
perimeter has well-defined (often guarded) entry and exit points (interfaces)
for those
entities which have specified access. Encapsulation, when applied in the
context of
software engineering, generally incorporates other separation concepts
associated with
principles of software design, e.g., modularity and information hiding,
and employs the
mechanism of abstract data types found in many modern programming languages.
Other separation concepts include time or spatial multiplexing of shared
resources,
naming distinctions via disjunctive set operators (categorical or taxonomic
classification,
functional decomposition, hierarchical decomposition), and levels of indirection
(virtual
mapping). All these separation concepts can be supported by the incorporation
of the
principle of least privilege.
3.8 MONITORING
The ability to achieve an awareness of a condition or situation, to track
the status of
an action, or to assist in the regulation of conditions or actions is
the essence of the
principle of monitoring. Conceptually, monitoring combines the notion
of surveillance
with those of interpretation and response. This ability requires a receiver
to have
continuous or discrete access to specified source data through appropriate
forms of
sensors. It also requires a specification of the condition, situation,
event, or sequence of
events that is to be checked, observed, or regulated, and a specification
of the response
that should be provided. This response specification generally includes
invocation
linkages to alarms and to a family of handler processes, such as resource
or device
handlers and exception or error handling processes. In some cases, monitors
will
require more privilege than other subjects within the system.
The principle of monitoring is key to enforcement of constrained actions
in that the
actions must be observed, understood, and forced to comply with the imposed
constraints. When the actions are not compliant, either additional system-provided
corrective actions or alarms to request external corrective actions are
invoked.
The principle of monitoring is used in mutual exclusion schemes for concurrent
processes sharing data or resources (e.g., Hoare's Monitors) and in the
operation of
interprocess communications of asynchronous processes to provide process
synchronization. Monitoring is the basis for auditing and for intrusion
detection. Other
examples employing this principle include range, value, or attribute checking
mechanisms in the operating system, database management systems (DBMS),
or in an
applications program; an embedded feedback-loop control system, such as
a
thermostat-driven cooling system; and the security ``reference'' monitor
in trusted
systems.
3.9 ALARMS
Whenever systems encounter an error or exception condition that might
cause the
system to behave incorrectly with respect to the environment (an integrity
failure), the
system designer should incorporate the principle of alarms to alert the
human operator
or individuals in the external environment to the unmanageable condition.
This fact
mandates a careful analysis of not only the internal aspects of system,
but also an
analysis of possible influences from the external environment. Further,
the designer
must not only consider the alarms, but also their sufficiency.
Alarms must be designed such that they are sufficient to handle all possible
alarm
conditions. For example, if a small field on a display is allocated to
displaying all alarm
conditions, and only one alarm condition may be displayed at once, a minor
alarm (such
as a low-power alarm) may hide a major alarm (such as indication of intrusion).
Thus, if
an intruder could artificially generate a low-power condition, he could
hide the alarm
indicating an unauthorized access.
Alarm sufficiency is a technical design issue which, if overlooked, can
have serious
impact. It must be required that alarms not be able to mask one another.
While there
may not be room for all alarm messages to be displayed at once, an indicator
of the
distinct alarm conditions must be given so that the user does not mistakenly
believe that
an ``alarm present'' indicator refers to a less severe condition than
the alarm actually
involved. In general, a single indicator should not group several events
under the same
alarm message. The central concepts here are that alarms must always reflect
an accurate
indication of the true status of events and alarm messages must always
be visible.
3.10 NON-REVERSIBLE ACTIONS
Non-reversible actions can prevent the effect of an action from later
being hidden or
undone. Non-reversible actions support the principle of accountability
as well as
address a unique set of problems, i.e., emergency revocations or emergency
destruction.
Non-reversible actions are in general, simply a type of restriction on
privilege. Thus, the
principle can often be implemented using mechanisms intended for granting
privileges.
For example, a non-reversible write operation can be provided by giving
a user write
access but no other access to an object. Likewise, an emergency destruction
operation
can be provided, at least in the abstract, by giving a user ``destroy''
permission but not
``create'' permission on an object.
``Write-once'' media provide one example of the use of this principle.
These media
are useful when the integrity concern is that the users not be able to
later modify data
they have created. Creation of audit records is another example employing
this principle
in which users may be allowed to write data, but then not modify the written
data to
prevent users from erasing evidence of their actions. Disposable locks
used on shipping
containers (which can only be locked once and cannot be reused) are yet
another
example of this principle's use.
3.11 REVERSIBLE ACTIONS
The ability to recognize an erroneous action or condition that would
corrupt the
system if actions that depend on the erroneous conditional state were
allowed to
continue often establishes the need to back out the erroneous action or
``undo'' the
condition. This is the principle of reversible actions. System designers
most often
incorporate this principle at the user interface, e.g., in text editors,
where a user may
readily notice keying errors or command errors and reverse them prior
to their having a
detrimental and not easily reversible or non-reversible effect on the
object state. This
principle is also used to support atomicity in database transaction processing
through
the protocol of ``rulebook,'' which undoes the portion of a transaction
already
accomplished when the entire transaction cannot be accomplished. Such
reversible
actions are key to leaving the database in a complete and unimpaired state.
3.12 REDUNDANCY
Redundancy in computer systems is a risk-reducing principle that involves
the
duplication of hardware, software, information, or time to detect the
failure of a single
duplicate component and to continue to obtain correct results despite
the failure
[Johnson 1989]. Redundant processing is commonly used in fault-tolerance
applications.
The same processing is performed by more than one process, and the results
are
compared to ensure that they match. The need for redundancy varies depending
on the
application. Redundant processing is commonly used in the implementation
of critical
systems in which a need for high reliability exists. Examples include
multiply redundant
processors in avionics systems, and traditional accounting systems in
which auditors
reproduce the results of accountants to verify the correctness of their
results. In
situations where a system may be subjected to adverse conditions, such
as on the
battlefield or hazardous environment, or in systems which may be subject
to an adve-
rsarial attack that is attempting to disable operations controlled by
the system,
redundancy may be essential. Thus, it may be desirable to require it for
certain systems.
Hardware redundancy is the most familiar type of redundancy, and involves
duplicating hardware components. Software redundancy involves adding software
beyond what is necessary for basic operation to check that the basic operations
being
performed are correct. N-version programming in which different teams
provide unique
versions of the same application program vs replicated versions is one
example of
software redundancy. The efficacy of software redundancy to support correct
operations
remains an open issue. For example, it has been shown that n-version programming
teams tend to have difficulty with the identical hard problems of an application
[Knight
1986].
Information redundancy involves duplication of information. Duplicate
copies of
information are maintained and/or processed, so that failures can be detected
by
comparing the duplicated information. To further assist in detection of
failures, the two
copies of information may be represented in different ways, (e.g., parity
bits or cyclic
redundancy codes). By exchanging bit positions of individual data bits
in a byte or word,
or by complementing the bits of all data, failures such as those that
modify a specific bit
position in a byte or word, or which force specific bits to always be
zero or one, can be
detected.
Time redundancy involves repeating an operation at several separated
points in
time, (e.g., resenting a message that was transmitted with errors). While
this approach
will not detect constant, persistent failures that always cause an operation
to fail in the
same way, it can often detect intermittent or transient failures that
only affect a
subset of the repeated operations.
3.13 MINIMIZATION
Minimization is a risk-reducing principle that supports integrity by
containing the
exposure of data or limiting opportunities to violate integrity. It is
applicable to the data
that must be changed (variable minimization and the more general case,
data
minimization), to the value of information contained in a single location
in the system
(target value minimization), to the access time a user has to the system
or specific data
(access time minimization), and to the vulnerabilities of scheduling (scheduling
regularity minimization). Each application is discussed in more detail
in the
following sections.
3.13.1 Variable Minimization
The ability of a subject to violate integrity is limited to that data
to which a subject
has access. Thus, limiting the number of variables which the user is allowed
to change
can be used to reduce opportunities for unauthorized modification or manipulation
of a
system. This principle of variable minimization is analogous to least
privilege. Least
privilege is usually used to describe restrictions on actions a subject
is allowed to
perform, while variable minimization involves limiting the number of changeable
data
to which a subject has access.
For example, a subject may be authorized to transmit messages via a
communications system, but the messages may be in a fixed format, or limited
to a small
number of fixed messages in which the subject can fill in only specific
fields. Thus, a
subject may be allowed to say ``fire type X missile on coordinates __,
__'' but may not be
allowed to substitute missile type Y for missile type X.
3.13.2 Data Minimization
Variable minimization generalizes to the principle of data minimization,
in which the
standardized parts of the message or data are replaced by a much shorter
code. Thus
``Fire missile'' might be replaced with the digit ``1'', and ``on coordinates''
might be
eliminated altogether, giving a message of the form
1 X ___ ___
where ___ ___ is replaced by the coordinates. The shortened forms of
standardized
messages or phrases are sometimes called brevity codes. When implemented
in a
computer system, integrity can be further enhanced by providing menu options
or
function keys by which the operator specifies the standardized message,
thus reducing
the potential for error in writing the code. On the other hand, as these
codes become
shorter, there is an increased likelihood of spurious noise or errors
generating an
unintentional valid message.
3.13.3 Target Value Minimization
The threat of attack on a system can be reduced by minimizing target
value. This
practice involves minimizing the benefits of attack on a given system,
for example, by
avoiding storing valuable data on exposed systems when it can be reasonably
retrieved
from a protected site on an as-needed basis. Distributing functionality
among subjects is
another means of minimizing target value and, thus, reduces vulnerability.
Highly
distributed systems use this approach, in which any one processing element
is of little
importance, and the system is sufficiently widely distributed that access
to enough
processing elements to have major impact is not feasible.
3.13.4 Access Time Minimization
Access time minimization is a risk-reducing principle that attempts to
avoid
prolonging access time to specific data or to the system beyond what is
needed to carry
out requisite functionality. Minimizing access time reduces the opportunity
for abuse.
Timeouts for inactivity, rotation, and binding of access to ``normal''
or specified working
hours are variations of this approach. This principle can serve distinct
integrity
functions, particularly in the case of more analytically oriented users
of data.
3.14 ROUTINE VARIATION
It is desirable to avoid scheduling vulnerabilities, in which time-dependent
vulnerabilities can become known, by employing the risk-reducing principle
of routine
variation. For example, if audits are scheduled at regular times, a bank
employee that is
capable of successfully subverting other controls may know exactly when
to abscond
with bank funds allowing sufficient time to cover up the theft or to make
a safe getaway.
Similarly, if communications are known to occur at specific times, synchronized
with a
master clock, an adversary is enabled to concentrate efforts for attack
on the known
periods of activity. The adversary, for instance, could degrade performance
of a radio-
based network by jamming the frequencies in use at known transmission
times.
3.15 ELIMINATION OF CONCEALMENT
If a system contains structures that allow concealment of integrity-violating
devices,
the risk of undetected access is increased. This fact applies not only
to physical
concealment (such as places to locate undetected hardware devices), but
it applies also
to software concealment. Software concealment includes places such as
large, poorly
structured code that allows Trojan horse or virus code to be inserted
without detection,
and features of elaborate and complex command languages where ``back door''
command sequences may be hidden without significant risk of accidental
or routine
discovery during normal usage of the system.
The ``debug'' feature used by the Internet Worm in 1988 is an example
of software
concealment. ``Debug'' was part of a large electronic-mail program called
``sendmail.''
The code for the ``sendmail'' program was so large and its command structure
so
complex that few people other than the implementer of the ``debug'' feature
knew of its
existence. The feature was further concealed by the very limited documentation
of the
``sendmail'' program in proportion to its complexity, and by the fact
that its command
language and syntax were so obscure that guessing the undocumented command
was
unlikely.
The problem concerning this feature was that the large, poorly structured
code of
``sendmail'' made it easy to hide a security vulnerability from systems
security
personnel performing a systematic search for security vulnerabilities,
while not hiding it
sufficiently from those who could exploit it. If the proportion of man-hours
spent
searching for security vulnerabilities during a security evaluation is
small in proportion
to the number of man-hours spent searching for vulnerabilities in order
to exploit them,
code whose complexity aids the concealment of security vulnerabilities
is more likely to
result in an actual breach of security.
3.16 ACCESS DETERRENCE
The risk-reducing principle of access deterrence is employed in mechanisms
that
discourage rather than prevent access. These mechanisms are useful in
certain
situations. For example, a system that makes an unpleasant and distracting
noise when
an unauthorized access attempt is first detected may reduce the ability
of an adversary
to concentrate on attacking the system. When used on a battery-powered
system in the
field, such a device could also serve to disable the system by discharging
the system's
batteries if the deterrent device is not deactivated within a short period
of time.
A conventional intrusion alarm siren is an example of an access deterrent.
They are a
deterrent rather than an absolute mechanism. Devices which produce unpleasant
by-
products while in operation function similarly, since they discourage
tampering with
devices during or after operation. An example is the water-activated battery
used in
some disposable meteorological equipment in the early 1970s. An unpleasant
smelling
material was left inside of the battery compartment, thus discouraging
persons who
found the discarded equipment from trying to reactivate the radio transmitter
by
replacing the battery. Clearly, use of such mechanisms is limited to unusual
conditions.
4 INTEGRITY MECHANISMS
In this section, we examine a wide variety of manual and automated mechanisms
that address various problems related to integrity. Most of these mechanisms,
evolving
over the course of many years, remain in use today. Not all of the mechanisms
we
examine are implemented in computer systems. These non-automated mechanisms
were included in our study because they give insight into what types of
controls need to
be provided and the types of threats which must be countered by automated
integrity
mechanisms. Also, since it is impossible to predict what functions can
or will be
automated in the future, we felt that it would be more productive to examine
integrity
mechanisms in general, rather than to limit our study to currently automated
mechanisms. No single mechanism provides the solution to integrity problems,
and
certain mechanisms may not be appropriate for certain systems. Rather,
each mechanism
can increase integrity protection for systems that satisfy the assumptions
identified in
the respective sections.
The mechanisms have been categorized to show that they serve a relatively
small set
of distinct purposes. We use the term policy to describe the higher-level
purpose of a
mechanism. In [NCSC 1988], security policy is defined as the set of laws,
rules, and
practices that regulates how an organization manages, protects, and distributes
sensitive
information. Our usage of the term ``policy'' is intended to be narrower
than its
generally accepted usage. We use this term to describe administrative
courses of action
which characterize a group of mechanisms in promoting or preserving integrity.
The
relationship among mechanisms grouped under a policy is a common, abstract
course of
action which addresses one facet of integrity. For example, fault tolerance
(discussed in
Section 4.4) is an important aspect of integrity protection for a wide
array of
applications, and can be provided by a variety of mechanisms. Table 1
is a summary of
the policies and corresponding mechanisms identified in this chapter.
(TABLE 1 not available for electronic version.)
TABLE 1. Integrity Mechanisms Grouped by Policy and Sub-Policy
4.1 POLICY OF IDENTIFICATION AND AUTHENTICATION
Identification and authentication (I&A) are elements of a supporting
policy required
for integrity, just as for confidentiality. In order to enforce access
controls it is necessary
to uniquely identify with confidence who is attempting access. Likewise,
when new data
is created it is necessary to identify the creator of the data in order
to assign any access
control attributes based on the data's origin, such as ownership, hierarchical
``quality''
measures, or categories reflecting specialized knowledge on which the
data may be
based.
The prevalent understanding and discourse on I&A deals primarily
with what we
have termed ``user I&A.'' However, there are corresponding identification
(and
authentication) concerns for other entities, such as devices and objects,
that must be
voiced to address this topic in full generality. Since the underlying
principles of user
I&A can be applied equally as well to a variety of entities, the traditional
view should be
extended to include these entities which have not previously been associated
with
I&A. Thus, while we will emphasize user I&A, we are motivated
to include a
discussion of I&A for devices and objects as well. Our discussion
of this policy is not
meant to be a treatise on I&A mechanisms, but rather to highlight
some I&A concerns
with respect to integrity.
4.1.1 Policy of User Identification and Authentication
There exists a wide range of user I&A mechanisms in use today, including:
passwords, biometric devices, behavior analysis, and identification badges.
We will
not discuss each of these mechanisms separately, as the purposes of all
these
mechanisms are the same: (1) the identity of an individual needs to be
established in
order to enforce policies which relate to those individuals, (2) the identification
needs
to be established with assurance that the individual is whom he claims
to be, and (3) the
activity of the individual needs to be captured for accountability. Our
discussion will
instead focus on the general types of mechanisms which are commonly employed
and
the issues related to the use of each of these types of mechanisms for
user I&A.
In order to be effective, I&A mechanisms must uniquely and unforgeably
identify an
individual. Traditionally, user I&A is based on the use of ``something
you know,''
``something you are'' (variably, ``something you can do''), or ``something
you have.''
Both ``something you know'' and ``something you have'' are limited in
effectiveness
by the fact that they are only associated with a person by possession.
A person
possesses knowledge or some identifying object, but both of these can
be acquired by
someone wishing to pose as that individual. Each approach has advantages
and
disadvantages. What distinguishes these two approaches is how effectively
each type
of authentication item can be protected.
The principal weakness of ``something you know'' is that it may be duplicated.
Not
only is it sometimes very easy to learn something someone else knows,
but it may be
possible to guess it. Because ``something you know'' can be readily retained
and
reproduced by humans, no special tools, skills, or equipment are generally
required to
duplicate this type of authentication item. But ease of duplication is
also an advantage
of this type of authentication item because such information tends to
be easily
represented to the trusted computing base (TCB) without special equipment.
Any
authentication data ultimately must be encoded, in some form, in the TCB's
authentication database; in this sense, a ``copy'' of the information
has to be kept by the
TCB in order to be usable in authentication. Since ``something you know''
can usually
be directly represented as a character string, it is easy to store for
later use by the TCB.
Although easy to copy, if ``something you know'' is genuinely unique,
such as a
unique nonsense word or number, it may be easier to guard than a physical
object.
This advantage results from the fact that an item of knowledge normally
is fully in the
possession of the person it identifies at all times. Unlike a key, card,
or other device,
``something you know'' cannot be stolen while temporarily left sitting
on a desk,
cannot accidentally fall out of a pocket, and in many cases cannot be
forcefully
acquired unless the person stealing it has a way of verifying at the time
that it is correct.
However, poor security practices such as writing one's password down can
negate the
advantages of using this technique. ``Something you know'' is also inherently
vulnerable to interception at its point of entry into the system. The
ease of duplication
always makes ``something you know'' an imperfect form of authentication,
and it is
subject to conscientious protection of information for its effectiveness.
By comparison, the major strength of ``something you have'' lies in its
difficulty of
duplication. ``Something you know'' is, literally speaking, an example
of ``something
you have,'' so when we speak of ``something you have'' we will by convention
mean a
physical object rather than an item of knowledge. While such objects require
more
effort to guard from theft, they can be made using special equipment or
procedures that
are generally unavailable to the population which poses a threat to the
system. The
intent is to make duplication of I&A objects too costly with respect
to whatever is to
be gained by falsifying the I&A objects. This fact discourages duplication,
though it
does not necessarily prevent duplication by a determined intruder.
The third type of authentication item, ``something you are,'' is much
stronger than
the first two. After all, the goal of authentication is to verify ``who
you are,'' and
``something you are'' is very closely tied to this goal. But, there are
also problems with
this type of authentication. A major obstacle is the difficulty of building
cost-effective
peripherals that can obtain a complete enough sample of ``something you
are'' to
entirely distinguish one individual from another. Cost is also a factor
in identifying
``something you have,'' but the authentication item itself can usually
be designed to
simplify identification by the TCB. ``Something you are'' cannot usually
be easily
encoded by conventional computer peripherals. It may be relatively easy
to build
devices that confirm that someone has some distinguishing features, such
as weight or
finger length. However, the cost of peripherals which have the ability
to detect
additional detail required to completely distinguish one person from another
can
be substantially greater.
Fortunately, not everything about a person is required for an adequately
unique
identification. Specific methods, such as fingerprinting or retinal scans,
may be used
to reduce costs in comparison to a total examination of all of a person's
physical
attributes. Yet, even these methods incur greater costs than the use of
a password,
which requires no additional hardware at all. Furthermore, such methods
are not
guaranteed to be infallible: identical twins, for instance, would not
be distinguishable
by DNA readers, and might not be distinguishable by any other specific
tests of
physical characteristics. In the hypothetical case of entirely identical
twins, the two
individuals might be solely distinguished by things in the ``something
you know''
category.
It may sometimes be useful to distinguish between ``something you are''
and
``something you can do.'' Examples include an individual's speech, writing,
or keystroke
dynamics, which might uniquely authenticate a particular individual's
identity.
Obviously the strength of this approach is directly related to how well
such a
mechanism can distinguish ``unique'' and ``authentic'' behavior. For instance,
the
mechanism might not be able to distinguish between two very rapid typists,
or perhaps
a speech-recognition mechanism could be ``spoofed'' by a high fidelity
recording of
someone's voice.
Other refinements of particular authentication methods may strengthen
the
mechanism while increasing costs in terms of additional performance or
management
overhead. For example, the requirement for one-time passwords places some
additional constraints on the user and the mechanism, but is very effective
in dealing
with the problem of reuse or ``playback'' of authentication information.
Nonetheless, simple mechanisms (e.g., a ``standard'' password mechanism)
can be both
effective and efficient in specific applications and environments.
Thus, not only are there cost and feasibility tradeoffs between the various
authentication methods, but several methods may be required to give adequate
certainty of authentication, which at the most theoretical level is always
subject to
some amount of error. A common concern for all I&A mechanisms is the
degree of
assurance which must be assumed regarding the facts that the mechanism
is actually
communicating with a bona fide user and that such communication has been
neither
intercepted nor tampered with. Additional measures such as physically
securing
communication lines and complementing an I&A mechanism with trusted
path features
can substantially increase the assurance of authentication.
The need for user I&A is essential for integrity when the permitted
operations or
accesses vary among different individuals. Without identification, it
is not possible to
know which user a given subject represents, and thus it is not possible
to determine
access rights. Without authentication, it is not possible to verify that
a user's stated
identification accurately reflects the user's identity. I&A policies
and mechanisms play
a fundamental part in supporting most other protection policies. As a
result, the
protection and integrity of the I&A mechanism(s) and related data
is essential.
4.1.2 Policy of Originating Device Identification
One possible extension to I&A is the need for originating device
identification.
Particularly in the battlefield, where it must be expected that a certain
number of
devices will be captured, it is essential that it be possible to uniquely
identify each
device in order to distinguish captured (and thus untrusted) devices from
those
which are still trusted. Terminal units may be assigned to specific groups
in the field,
and since the risk of capture of these devices must be considered, unique
hardwired
identification of each device is desirable. This identification mechanism
can be
protected against tampering and substitution, for example, by a mechanism
that
destroys the terminal unit or one of the unit's critical subcomponents
(such as
encryption keys) if the unit is physically accessed.
The authentication issue is different for device vs human-user identification.
A
problem with human-user identification is that many of the identification
mechanisms
are based on something the user knows (an identifier string) which must
be further
authenticated. In the case of the device with a hardwired identifier,
the identifier is
part of ``what the device is,'' thus reducing the authentication burden:
the concern then
focuses on what user is accessing the known device.
4.1.2.1 Mechanism of Device Identification
In traditional systems, devices are uniquely identified primarily to
allow them to be
separately addressed. In the commercial environment, the need for unique
identification has become an issue due to the desire to limit software
use to specifically
licensed machines. The use of ``serial number'' read-only memories (ROMs)
or similar
mechanisms is being increasingly used for this purpose.
Where security is concerned, device identification must be unforgeable
to the extent
possible to prevent a user from easily changing a device to masquerade
as another. In
a hostile environment, a conventional identifier ROM is not sufficient,
since it may be
easily replaced. Any identification mechanism that leaves signal and control
lines
exposed to tampering may allow the enemy to easily modify the identifier,
depending
on the architecture of the device interface. For example, if data lines
beyond the
device select logic are exposed, the identifier could be modified by simply
grounding
or cutting the data lines. If the system bus is exposed and the device
addressing
mechanism is known, identifier modification can be accomplished with greater
difficulty by building a clip-on device that monitors address lines for
the ROM
address and then drives the bus data lines to the desired identifier values.
For this reason, it is recommended that the data path between the identifier
ROM
and the hardware that accesses it be protected from access. This path
could be protected
by locating the ROM on the same integrated circuit (IC) as the related
processor circuits,
and by isolating the processor from the external bus while the ROM is
being read.
Similar protections must be used between the time the identifier is read
and when it is
transmitted to the device or subject requesting the device identifier.
At some point in
this path, the protection mechanism must shift from physical protection
to encryption
and related mechanisms because the data will be exposed to modification
during
transmission to the remote site.
These identification mechanisms, however, do not preclude attack from
a
sophisticated adversary; they only make it more difficult for the enemy
soldier on the
battlefield to successfully infiltrate such a system. It is still possible
to construct work-
alike hardware that allows the device identifier to be changed, and such
hardware
may be used by the enemy to falsify this identifier as part of an attack.
Because of this vulnerability, device identification should be used to
restrict or
disable captured devices, rather than to grant privileges or to serve
as user identi-
fication. Furthermore, it is undesirable to give specific access-control
meanings to
specific identifier values, other than to distinguish the devices from
one another.
Despite its limitations, proper design of device identification is essential
to giving an
increased level of control over devices distributed in the field.
4.1.3 Policy of Object Identification and Authentication
For our purposes, objects are simply passive entities within a system-our
use of
particular terminology should not be construed to suggest a particular
implementation of objects (e.g., object-oriented systems). The topic of
object I&A
may require a broadening of one's traditional focus on user I&A, and
the realization
that the principles underlying user I&A may be applied equally to
objects. An object's
identity can include its class (e.g., classification, type) and a unique
name used to
reference a particular instance of the class. Similarly, active entities,
besides having
unique names, can be grouped via clearance level or group membership,
thereby
forming classes which are meaningful in relation to policy enforcement.
An object's
class is specified via attributes associated with the object instances,
although all
attributes of an object need not apply specifically to policy enforcement.
Policy can
specify proper activity in terms of an (active or passive) entity's name,
attributes, or
some combination thereof.
In some cases, such principles have been applied in existing mechanisms
which
enforce policy in relation to objects, but are simply not recognized as
I&A principles,
perhaps due to an over specialization of the term. For instance, one purpose
of user
identification is to provide a means to capture the activity of users.
However, user
activity is usually defined in terms of actions on specific objects within
the system. Thus,
an object's identity must be established with certainty in order to accurately
capture the
activity of a user. Alternate naming facilities, such as aliases or symbolic
links, must
not hinder the system's ability to resolve and record the unique identity
of the
physical object. Here we see that the same principle (unique identification)
must be
applied equally to users and to objects, otherwise unauthorized actions
might go
undetected.
An object's identity provides a means for both the system and users to
bind a logical
entity with its physical (i.e., machine) representation. As such, an object's
identity can
also be expanded by attaching contextual attributes (e.g., owner, type,
authenticity),
allowing the system to achieve a greater degree of functionality in regard
to its
interactions with objects. In particular, object identity and its associated
attributes
enable the system to enforce various policies related to specific operations
on instances
of objects. Policy decisions are based either directly or indirectly (through
associated
attributes) on an object's identity. The correspondence of a logical entity
to its
physical representation can make policy enforcement difficult, or may
create
opportunities to otherwise circumvent policies. This correspondence can
be expressed
as the unification of a logical entity with its physical representation;
in general, this
unification must be maintained during all operations on an object, throughout
its
period of existence on the system.
Problems associated with the unification of information with data result
from two
causes: physical or logical dispersion of object identity. Physical dispersion
exists
because there may be multiple ways to physically access the logical entity
specified by a
unique system identifier. If physical resources can be directly accessed,
then protection
mechanisms based on object identification can be circumvented. If temporary
objects
can be accessed, such as a buffer holding the results of a database query
or a scratch
file on disk, the integrity of other (permanent) objects may be compromised.
Also,
objects within a system will exist in different forms (i.e., on disk,
in cache, in memory)
over their lifetime within the system. If all forms of an object are not
sufficiently
protected, the integrity of the object can eventually be compromised.
For instance, a file
may be protected by the operating system while in memory, but a channel
device
which contains maliciously written software may modify the file while
transferring it
to or from the disk.
While physical dispersion concerns an internal (to the system) binding
of an object to
an identity, logical dispersion is associated with the binding of an external
``infor-
mation unit'' to a system object or set of objects. It is important that
an object's identity
and associated attributes reflect the external expectation of what that
object represents.
For instance, if duplicate, sensitive information is entered into two
different text files on
a system, then that information is necessarily represented internally
by two different
object identities. If the two files are marked with different integrity
attributes, then
policy decisions may be inconsistent with respect to identical units of
information.
One of the text files may be marked as Sales and the other as Development,
or perhaps
they are ``owned'' by different subjects. While, the system may perform
flawlessly in
enforcing an integrity policy based on these labels or ownership, different
actions may
be specified, allowed, or disallowed for each object due to the difference
in their
attribute specifications. Thus, drastically different versions may emerge
over time.
The scope of this problem increases when one realizes that the information
in one
internal object can be copied to other objects. Even if the attributes
associated with the
(original) object are faithfully transferred to all objects which contain
all or part of the
original information, each of those ``new'' objects must have different
internal iden-
tities. While the overall intent of some integrity policy may be to control
access to a
``specific instance of information,'' the system may have dispersed internal
identities
which contain that information. Because a system's enforcement of policy
is usually on a
per object basis, it may be impossible for that system to enforce (integrity)
policies
which address the information ``identity,'' rather than internal object
identities.
An example exhibiting the dispersion problem is that of updating identical,
distributed databases. The databases represent a single, logical ``instance
of
information,'' yet at any given moment the actual contents of the databases
may be
different. If the overall system depends on the cooperation and interaction
of
components, some of which have different values for the same logical entity,
the results
are unpredictable. The integrity of such a system's operations may be
suspect.
The problems associated with dispersion are compounded when one considers
that
for integrity concerns, the attributes associated with an identity might
not need to be
identical for all versions of an object, but there may in fact need to
be some variation of
the original attributes for each copy. Thus, we suspect that a mechanism
to address the
dispersion problem will have some of the properties of a ``version control''
or
configuration management system which binds related system objects to
a single system
identity.
Another concern associated with object I&A is that the true identity
of an object may
be known only by considering the totality of that object's representation
on the system
(e.g., its name and location). The presence of variable search paths for
executable
objects may result in the unintended invocation of improper programs.
On some
systems, executables can be referenced by a sequential search for the
program through
an arbitrary series of file system locations (i.e., directories). This
series is arbitrary in the
sense that the specific locations and the order in which they occur in
the search path
are not fixed properties of the system, but may be specified and varied
on a subject to
subject basis. If two programs have the same name but reside in different
directories, the
actual program executed through invoking that name would depend on which
directory occurred earlier in a subject's search path.
The presence of different forms of referencing an object generally reflects
the
desire for flexibility in systems. However, such flexibility can result
in some uncer-
tainty about which objects are actually referenced by the invocation of
identical
commands in different environments. It would seem that the definite resolution
of
object identity must be guaranteed by the system in order to maintain
a high assurance
of integrity. This implies that some method of absolute referencing be
provided by the
system, and used exclusively in operations which are integrity-sensitive.
Absolute
referencing should extend to interactive commands, dynamic references
of applications,
and system-internal references. However, for universal absolute referencing
to be
practical, the referencing mechanism must be flexible. The explicit-path
method
described above may prove too cumbersome; however, flexible alternatives
already exist (e.g., capabilities), although these alternatives may have
drawbacks of
their own.
Object ``authentication'' may often simply mean that its source of origination
is
genuine the user who created the object has been authenticated. It may
be suggested
then that object authentication is then equivalent in some sense to user
I&A. However,
there are some additional constraints which are assumed in such a proposition.
In
general, nothing associated with an object throughout its lifetime on
the system is static.
Its identity can be changed by renaming or making a copy. Attributes associated
with
an object can be modified and then possibly changed back to the original.
For many if
not most objects, the contents of that object will change over time. The
authenticity
of an object created and maintained by a particular user cannot be ascertained
if other
users are able to modify the object's name, attributes, or contents. Also,
an object may
be copied and illegitimately presented as original. As such, the authenticity
of an object
is highly dependent upon a system's capabilities and the proper administration
of
controls over that object.
In general, object authentication can be addressed to varying degrees,
depending on
the capabilities and features offered by a particular system. Some systems,
such as net-
work and other communications systems, may provide strong authentication
of objects
through their protocol structures. The primary motivation is to be able
to recognize
``valid'' frames and packets, discarding those with errors or possibly
rerouting others to
their proper address. However, the protocol structure provides a convenient
location
to insert more rigorous object authentication mechanisms, in general [ISO
1990]. Other
systems such as stand-alone, personal computers, may offer no intrinsic
object
authentication mechanisms. Objects on such systems may be ``authenticated
by
recognition,'' but no formal protection features are offered.
Some systems may provide general authentication mechanisms such as digital
signatures, notarization, or encryption, which are discussed below. While
general
authentication mechanisms provide the capability to protect specific objects
on
demand, general authentication of all objects within a system using these
methods
may entail a prohibitive administrative overhead. The topic of practical
object
authentication is one requiring more research to arrive at general solutions.
4.1.3.1 Mechanism of Configuration Management
Configuration management (CM) can be thought of as a mechanism which
incorporates aspects involving both identification and authentication
of objects within a
system. In its most widely accepted usage, CM deals with controlling the
construction
of complex objects, extending to both identifying the components of an
object and how
those components are combined. Configuration management may incorporate
features
of access control for greater measures of protection, but can provide
unique protection
services independently of access control. Protection provided by CM mechanisms
can
extend to an arbitrary level over each object considered a component of
a more complex
object.
Configuration management mechanisms are currently in wide use in the
software
development industry today, aiding in the control of production software.
A more
general adaptation of CM techniques in the control of related objects
seems plausible.
It should be noted that an application (i.e., a program or set of programs)
will often
provide a significant amount of control over objects within its particular
domain.
Therefore, a more generalized CM mechanism focused on object integrity
would need
to extend CM controls over inter-application objects and possibly related,
system-
level objects.
4.1.3.2 Mechanism of Version Control
A mechanism which is usually integrated into CM systems is that of version
control.
Version control allows distinct versions of an object to be identified
and associated with
independent attributes in a well-defined manner. For instance, three different
versions of a software package could be marked as ``invalid,'' ``distribution,''
and
``next release,'' respectively. Each version can be handled differently
with respect to a
particular policy. Version control can include such features as the destruction
of ``inva-
lid'' objects or distribution of sanitized versions.
4.1.3.3 Mechanism of Notarization
In the context of distributed systems, it has been suggested that the
originator of an
object should be responsible for assuring its confidentiality, while the
recipient of an
object should be responsible for assuring its integrity [Jueneman 1989].
From a
detection oriented viewpoint, these are valid points. However, when emphasizing
the
prevention of policy violations, we find that the converse situation must
also apply:
the recipient of an object must also protect an object's confidentiality,
while the
originator must provide some protection of an object's integrity. In particular,
the
authenticity of an object must, in part, be the responsibility of the
originator. The
originator must be responsible for the proper creation, maintenance, and
administration of the object up until the time of its transmission to
the recipient.
Similarly, the system on which the object resides must provide the proper
mechanisms
to support the originator's protection of the object.
Given that an object is beyond the ability of the recipient to protect
before it is
received, the recipient may be forced to assume that the originator intended
for that
particular object to be sent, and that the object had been appropriately
protected while
it resided on the originator's system. This assumption can be unfounded
for several
reasons: (1) it is possible that the originator's intentions are malicious,
(2) the
authentication mechanism may have been applied improperly, (3) the authentication
mechanism itself may contain faults, and (4) it may have been possible
to intercept and
replay authentic traffic. In this respect, some authentication measures
taken by the
recipient often only verify that the originator of an object is genuine.
One technique which can strengthen recipient's assurance in the authenticity
of an
object is the generalized mechanism of notarization. With this mechanism,
an interme-
diary entity intercedes between the originator and recipient during an
object transfer, to
establish and certify the authenticity of the object. The intermediary,
or notary,
``seals'' the object that bears the signature and/or seal of the originator.
In its normal
usage, notarization primarily serves to verify the authenticity of originator
of an
object, rather than the object itself. A generalized extension of this
technique seems
particularly well suited for automated systems. In automated systems,
the originator of
an object transfer might simply supply a notary entity with the object,
while the notary
entity would perform the actual application of the authentication mechanism.
This
technique has the property of separating the ability to both originate
and authenticate
an object, which would perhaps be desirable for certain systems or applications.
Furthermore, a notary entity might supplement the authentication measures
taken by
the originator, thereby reducing the required degree of trust for both
entities.
4.1.3.4 Mechanism of Time Stamps
One measure which can be used either independently or as a strengthening
feature
of other mechanisms (e.g., notarization) is the mechanism of time stamps.
Time stamps
can be provided by a system automatically as an integral part of the system's
object-
transfer mechanism(s). Time stamps can be used to enforce ``time of use''
dependencies,
and can provide added assurance that an object received by an entity is
still valid. For
instance, in a real-time system, stale data from sensors could be detected
and
discarded by a recipient processor if the time differential was too great
for tolerances.
Similarly, there exists multiuser systems today which limit the valid
``time of use''
period for sensitive objects via the use of time stamps [Steiner 1988].
Automated
features such as time stamps do not completely solve all aspects of the
problems
associated with object authentication, although they can provide extra
protection. The
main advantages of time stamps are that they can be made efficient, transparent,
and
uncircumventable.
4.1.3.5 Mechanism of Encryption
In general, the mechanism of encryption effectively seals the information
within an
object inside an additional (logical) container. Used primarily to provide
confidentiality,
general encryption can be used to ensure the detection of integrity violations
and to
otherwise hinder integrity attacks. Encryption is not absolute protection,
as the
sealing process may only be as safe as the encryption key. Also, encryption
of an object
does not in and of itself prevent damage to its integrity. However, encryption
does
provide an additional level of protection which must be circumvented in
order to violate
protection policies, or to succeed at making violations without detection.
A distinct
advantage of encryption is its flexibility of use its ability to be used
either as blanket
protection or ``on demand,'' and its applicability to a wide array of
object types. There
is a great deal of existing literature on the various uses and methods
of employing
encryption which will not be summarized in this paper for the purpose
of brevity.
However, specific uses of encryption which are the most relevant to the
issues of
integrity are discussed below.
4.1.3.6 Mechanism of Digital Signatures
The mechanism of digital signatures is intended to produce the same (desired)
effect
as a real signature: an unforgeable proof of authenticity. In [Rivest
1978] the
authors describe a specific implementation of digital signatures in a
public key
cryptosystem. Every user (and TCB) has a unique, secret decryption procedure
D that
corresponds to a publicly available encryption procedure E. As an example
scenario,
suppose that A and B (also known as Alice and Bob) are two users of a
public key
cryptosystem. Their encryption and decryption procedures can be distinguished
with subscripts: EA,DA,EB,DB. If Bob wants to send Alice a ``signed''
message M in
a public key cryptosystem, he first computes his ``signature'' S for the
message M using
DB:
S = DB(M)
He then encrypts S using EA (for privacy), and sends the result EA(S)
to Alice. He
need not send M as well; it can be computed from S.
Alice first decrypts the ciphertext with DA to obtain S. She knows who
the
presumed sender of the signature is (in this case, Bob); this can be given
if necessary in
plain text attached to S. She then extracts the message with the encryption
procedure of
the sender, in this case EB (available on the public file):
M = EB(S)
She now possesses a message-signature pair (M, S) with properties similar
to those of a
signed paper document. Bob cannot later deny having sent Alice this message,
since
no one else could have created S = DB(M).
4.2 POLICY OF AUTHORIZED ACTIONS
Users assigned to particular tasks may have certain actions for which
they are
uniquely authorized. For example, only the approval authority may be authorized
to
give the order to launch an attack on the enemy. In computer systems,
these
authorized actions are often called privileges. Authorized actions can
be either
unconditional or conditional. Unconditional authorization immediately
authorizes an
action, although the action may not take place until some time in the
future.
Conditional authorization authorizes an action, but only if certain conditions
hold.
When looking at the topic of authorized actions, we are considering ways
in which
access may be controlled, without implying any underlying strategy (such
as
strategies for deterrence). There may be situations in which the need
for dynamic
modification of authorized actions is required. Such modifications are
usually
performed by an authorized individual such as a security officer, or by
a trusted
software component. However, there may be cases in which such modifications
must
be allowed to be made by normally unauthorized individuals under controlled
conditions. It is necessary that emergency situations be considered in
the design of
authorization systems, since survival of the users may require that overrides
be possible.
An authorized actions policy specifies which actions a subject is allowed
to perform,
rather than controls on which data the subject is allowed to access. We
examine several
mechanisms that can be used to specify authorized actions under the policy
of
separation of duties. We begin, however, by addressing the policy of conditional
authorization.
4.2.1 Policy of Conditional Authorization
If we consider the fully prohibited (disabled) and fully permitted (enabled)
conditions to be the two extremes of unconditional authorization, there
are
intermediate states between these two where conditional authorization
can also be
important. We will examine two conditional authorization mechanisms: conditional
enabling and value checks. Conditional enabling authorizes an action only
when
certain conditioning events exist, and value checks are used to restrict
actions based
on authorized values.
4.2.1.1 Mechanism of Conditional Enabling
Conditional enabling disables the ability to perform a given action (such
as to fire a
weapon) when the action has not been authorized. Attempting to perform
the action
will produce no effect. However, if conditionally enabled, an authorization
override or
bypass mechanism is provided. If the user of the disabled device actuates
some
arming control, for example, the previously disabled function will now
operate. It is
expected (and enforced by disciplinary measures as appropriate) that the
operator of the
device will not bypass the required authorization except in situations
that necessitate
it. The mechanism serves primarily to prevent accidental actions from
being initiated.
The requirement that the operator take an explicit action to override
the normal
requirement for authorization serves to ensure that the action was intentional,
and
places greater reliance on the operator's contribution to the integrity
of the system.
An example of this mechanism that is directly related to our topic is
that of
recently-designed ``fly-by-wire'' aircraft [Seecof 1989]. These aircraft
have computer
controlled restrictions on which actions the pilot may perform; the computer
determines
which actions might be damaging to the aircraft if carried out, such as
excessively
abrupt changes in direction or excessive engine speed. If the pilot attempts
to operate
a control outside the calculated safe range, the system prevents the control
from being
moved into that position. However, if the pilot pushes the control with
unusual force,
the system will allow him to move it beyond the restricted position. This
override
allows the pilot to exceed calculated safety limits in emergency situations,
such as
collision evasion. Considerable controversy has surrounded designs of
commercial aircraft that have failed to incorporate such overrides, including
suggestions by aircraft engineers at competing manufacturers that such
aircraft will
not perform adequately in emergency situations [Outposts 1989].
For this reason, it seems advisable that support for conditional overrides
of this
type be available in safety critical systems where the operators are considered
suffi-
ciently skilled, or where absence of the override may result in dangers
that the operator
could otherwise prevent. In designing such an override, individual analysis
of the
design is necessary to determine whether and to what extent the override
should be
provided. It is not possible to give rules that will cover all cases adequately
without
examination of individual cases. Simply omitting to provide support for
such
overrides, or prohibiting them in standards, appears inadvisable.
4.2.1.2 Mechanism of Value Checks
Value checks are a weak form of type enforcement, and historically are
the
predecessor to abstract data types and strong typing discussed in Sections
4.3.1.1 and
4.3.1.2. There are several related types of checking techniques that we
have grouped
under the heading of value checks: discrete value checks, range checks,
and data
attribute checks.
With discrete value checks, data may be permitted to have only certain
values out
of a wider possible set, or may be restricted not to have particular values.
For example,
target coordinates may be restricted such that artillery could not be
directed to fire
upon friendly forces.
Range checks verify that data is within a certain range of values. For
example,
memory parameters passed from a memory management process to the kernel
must
be checked to be certain that they fall within certain bounds. Range checks
supported by the machine architecture have generally been limited to those
required for
correct operation of the instruction set, such as checks for arithmetic
overflows, and
those required in support of the memory protection subsystem, such as
checks to ensure
that addresses are not out of range.
Data attribute checks, such as verifying that data is in a particular
numeric format,
have been present for several decades in the instruction sets of commercial
machines.
These elementary checks usually involve only verifying that the data is
in a format
suitable for correct processing by the machine's defined set of operations,
e.g., that
a packed decimal number consists only of the hexadecimal representation
of the digits
0-9 followed by a valid sign digit (A-F) [Struble 1975]. More complex
attribute checking
is possible through programming language constructs. For example, values
may be
required to be numeric or alphabetic, numbers may be required to be even
or
multiples of some other value, and strings may be required to be of a
certain length.
Checking mechanisms beyond these have been implemented either at the
programming language level, or as a programming practice in applications
development. Subscript range checking, for example, has been a debug feature
provided by some compilers even when the language involved does not incorporate
strong type enforcement, simply because it helped to detect a commonly
occurring
error. However, such checks were often considered debug-only features,
and were
usually removed for efficiency reasons in production software.
Newer languages retain these checking mechanisms, but extend them by
providing
for exception handlers: when an error is detected, a means is provided
for the
program to retain control and handle the error appropriately. Similar
error-handling
mechanisms existed in much earlier systems, but generally were a feature
of the
processor architecture which might on occasion be extended into the operating
system
interface where it was accessible to the user. They were not well integrated
into most
programming languages.
4.2.2 Policy of Separation of Duties
Many integrity violations result when a subject fails to perform expected
duties in
the appropriate way. A violation can involve willful inappropriate actions
(e.g., con-
spiracy, coercion, and duping), failure to perform duties, or performance
of duties in
inadequate ways. To promote prevention and detection of these types of
violations,
separation of duties may be employed. In this type of policy, different
subjects are
given distinct but interrelated tasks, such that failure of one subject
to perform as
required will be detectable by another. To avoid circumvention of this
mechanism, any
one subject is explicitly prohibited from performing another subject's
duties.
This policy is based partly on the expectation that not all subjects
involved in
interrelated tasks will attempt integrity violations at the same time
(i.e., collaborate),
and that those who do not attempt integrity violations will detect the
failure of their
counterparts. People may be less likely to attempt integrity violations
if they know
that their actions will be visible to others who are performing related
duties. Likewise,
people may be more likely to notice and recognize situations that are
anomalous and to
report them. Depending on how duties are partitioned, separation of duties
may
altogether prevent a single individual from violating integrity. For example,
some
tasks may be partitioned among several subjects such that, while none
of the subjects
can observe their counterparts' actions, the task cannot be completed
without a
contribution from all the subjects.
It must be noted that the preventive effect may not always be provided
by a simple
separation of duties. For example, if one individual is allowed to issue
checks but not
update inventory records, and another is allowed to update inventory records
but not
issue checks, the first individual may still issue unauthorized checks.
The fact that
the checks are unauthorized will be detected by auditors who find that
the payments
did not result in items being added to the inventory, so the fear of being
detected is
the principal deterrent. The example could be enhanced to include the
preventive
effect if the duty of issuing checks was further divided to limit a first
person to pro-
viding a proposed table of check addresses and amounts, and a second person
to
authorizing the AIS to print the checks and controlling the check stock.
It should also be noted that restricting access may prevent an individual
from
filling in for another individual in an emergency situation, such as a
situation in which
the individual originally assigned a given task is injured on the battlefield.
Thus,
separation of duties also increases the extent to which individuals become
critical
components in the overall functioning of a system. If other persons are
prevented from
substituting for the missing person, the system may be disabled more easily
by the
failure of an individual to perform their assigned duty.
One of the stronger points of separation of duties is that, in certain
systems, it is
possible to be reasonably certain that not all subjects will fail. For
example, it may be
expected that an intruder will not be able to find ways to violate the
integrity of all
subjects among which duties are separated, and thus that the remaining
subjects will
detect the attempted integrity violations of the other subjects. On the
other hand, if this
expectation is incorrect, and the intruder finds a way to cause ``collaboration''
between all the subjects involved, this policy will not detect or prevent
the violation.
In the case of machine processes, the preventive effect can be achieved
when it is
possible to partition the functions of the different processes such that
a single errant
process cannot in itself cause a harmful result to occur. However, the
psychological
element involving the fear of detection is absent in machine processes.
Since they
merely perform their operations as programmed, without detailed evaluation
of risks,
machine processes will not be deterred a priori from committing integrity
violations. In
the same way, they will only detect violations for which they have been
programmed
to check, and are not likely to recognize many forms of suspicious behavior
by their
counterparts. A machine process which is involved in separation of duties
with a
human counterpart is particularly vulnerable, since the person may find
it easy to
``outwit'' the machine's checks, especially if the person comes to understand
the
machine's checking algorithms.
The enforcement of separation of duties can be either static or dynamic.
The
simplest approach is static separation, where the system administrator
in charge of
maintaining access controls is responsible for understanding the way the
rules achieve
separation of duties and for making appropriate assignments. This approach
is limited
in functionality because it is often necessary or desirable to reassign
people to duties
dynamically. An alternative approach is for the system to keep track dynamically
of
the people who have executed the various actions in the task sequence,
and to ensure,
for any particular execution, that proper separation has occurred. However,
there are
several hard problems to solve in order to implement dynamic separation
of duties, such
as encoding valid sequences and separately tracking each execution of
a particular
sequence.
4.2.2.1 Mechanism of Rotation of Duties
In some tasks, it is likely that a person performing the task may discover,
through
random events, ways to compromise the integrity of the system. If such
a person is
corrupt or corruptible, the probability that the person can cause an integrity
violation
increases the longer he is assigned to the same duty. The probability
that the viola-
tion will remain undetected is also increased in certain instances. To
address these
vulnerabilities, rotation of duties is used, in which a person is assigned
to a given task
for only a limited amount of time before being replaced by another person.
For example, a person may discover exploitable ``loop-holes'' in a system
and may
decide to use them to violate the integrity of the system. If the person
is rotated out of
a given position before such loopholes are discovered, some threat to
integrity may be
reduced. Note, however, that communication between current and former
occupants
of the vulnerable role may defeat the protection provided by this mechanism.
Rotation
may also give the user a broader understanding of the operation of the
system, giving
more insight into how to circumvent integrity.
Additional features of rotation of duty involve limiting the damage one
individual
can do and increasing the likelihood of detection. If a given individual
is seeking to
bring about violations of integrity, rotation can accomplish two things.
First, if there is
only one task in which an individual has discovered a way to perform an
access in
violation of policy, rotation will reduce that individual's exposure to
the vulnerable
task. Second, rotation may enable identification of the individual involved
in an
integrity violation: if an audit shows that a problem exists only while
a given
individual is assigned to a particular task, this provides evidence that
individual may
be associated with the problem in some way. If the individual has discovered
ways to
violate integrity in multiple duties, an audit may indicate that the problem
``follows''
the individual as rotation occurs, again providing evidence that the individual
in
question may be involved in the violation.
Rotation of duty also addresses an integrity threat that does not involve
willful
malicious action: the tendency for errors to increase when a person performs
a
monotonous task repeatedly. In this case, rotation of duty reduces the
amount of
time the repeated, monotonous task must be performed by a given person.
In general,
electronic systems do not have an analogous property, although mechanical
systems
may (i.e., rotation to distribute mechanical wear among exchangeable parts).
This mechanism implies separation of duties, since in order for duties
to be rotated
among different users, the duties must first be partitioned among these
users. Thus, it
is necessary that a mechanism be provided to enforce separation of duties.
For rotation
of duties, this enforcement must be extended to allow orderly, policy
driven rotation of
assignments to specific duties. The rotation may occur at a specific point
in time, or in
response to requests by an administrator.
Rotation of duties can also be used to effectively rotate data. For example,
if three
accountants are maintaining the accounts of three different companies,
the
accountants could be rotated among the different companies periodically.
The duty of
accounting would not change (and thus no additional training would be
necessary),
but the data being maintained would be rotated among the accountants,
reducing the
probability that an authorized user would make improper modifications.
4.2.2.2 Mechanism of Supervisory Control
In some cases, authorization may be delegated to subjects in controlled
ways.
Supervisory control exists when a subject in a supervisory role is required
to authorize
specific actions to be carried out by a subordinate subject as certain
conditions arise. In
general, the authorization would apply to exactly one occurrence of an
action so that
overall control of the activity remains with the supervising subject.
Supervisory control
may involve either requiring an individual to give final approval to an
action being ini-
tiated by another individual, or requiring an individual to give final
approval only to
actions that meet certain constraints (such as those that have particularly
severe conse-
quences). Normal activity outside the scope of these constraints would
not require the
approval of the supervisor.
This mechanism provides for delegation of less integrity critical tasks
to less trusted
individuals, with only the integrity critical portions being dependent
on the
supervisor. One example is check cashing authority at grocery checkout
stands. A
checkout clerk can initiate the check cashing procedure, but must receive
final
approval from a supervisor for the actual transaction to take place.
Supervisory control is often a complexity-control mechanism. The delegation
of
action is often a tradeoff, since it might be desirable under ideal circumstances
for all
actions to be performed by the most trusted individual, but doing so would
not be
possible due to the number of individual actions that must be decided
upon and
undertaken. This fact highlights one vulnerability associated with supervisory
control if the critical conditions which require a response occur with
high frequency, the
supervisor may spend an unacceptable portion of time issuing authorizations
to
subordinates to deal with the occurrences. Therefore, it may be inadvisable
to rely on
supervisory control if such a high frequency situation is likely to occur,
unless this
contingency has been planned for (e.g., through the granting of blanket
authorizations).
4.2.2.3 Mechanism of N-Person Control
N-person control (where N is a number, typically 2) requires more than
one subject
to request or participate in the same action in order for the action to
be successful. An
example of this mechanism is a system for commanding missile launches
in which two
physically separated controls must be operated by two people simultaneously.
The
rationale is that n people are less likely to spuriously decide to initiate
an action than
would one person.
This is a unique mechanism, which is not provided in most existing computer
systems. It is roughly analogous in its underlying purpose to the preventive
aspect of
separation of duties, in that it serves to require that multiple persons
cooperate to bring
about a controlled action. The difference is that in N-person control,
separate
individuals are performing the same duty (as opposed to different duties
in separation
of duties) to bring about a single action. N person control often also
requires that these
persons perform actions simultaneously; by comparison, separation of duties
usually
does not involve this requirement for simultaneity. As with may other
mechanisms, N-
person control can be strengthened by incorporating other security features,
such as
time tokens, trusted path, and physical security.
4.2.2.4 Mechanism of Process Sequencing
Certain duties may be required to be performed in a certain order; this
process
sequencing can serve at least two purposes. First, this mechanism can
ensure that all
steps necessary for a multi-step procedure are followed in the proper
order. Second, if
the sequence is known only by current authorized users, it may be more
difficult for
an adversary to successfully discover the sequence and violate the integrity
of the
system. Process sequencing especially discourages trial-and-error attacks,
if the
sequence is long and an improper sequence makes it necessary for the user
to start over
at the beginning. However, it can also make it more difficult for an authorized
user to
succeed at the required steps, if the procedure or environment is such
that errors by
users are likely.
4.3 POLICY OF SEPARATION OF RESOURCES
In addition to separating duties among different persons or processes,
access to
resources can also be separated. In this policy, the resources to which
subjects have
access are partitioned so that a given subject has access only to a subset
of the
resources available. More precisely, a given subject and the tools (e.g.,
programs,
system utilities, system applications) available to that subject are allowed
access only
to specific resources. An example is disk quota enforcement, in which
the amount of
disk space that each subject may use is limited to a fraction of the total
space available
in the system. This policy can overlap with the separation of duties policy
discussed
previously if the resources that are controlled limit the duties that
each subject can
perform. However, separation of resources can also have other effects,
such as lim-
iting the extent of damage to otherwise homogeneous resources that can
be caused
by a given errant subject.
Similar principles apply to separation of resources as apply to separation
of duties.
As with separation of duty, a means of partitioning is required, but the
partitioning sep-
arates resources rather than duties and tools. To accomplish this end,
the TCB should
provide a means of enforcing an appropriate partitioning of resources
such that they
are accessible only to persons or processes in specific roles.
To a certain extent, such mechanisms are already provided in existing
systems.
Identity based access control allows such discretionary partitioning,
e.g., owner has
discretion to grant access. In some cases such partitioning is ``mandatory.''
For
example, in many systems, only the owner of a file is allowed to perform
certain
operations on it, such as deleting it or changing its access attributes.
Permission to
change access permissions, identified in [Bishop 1979] as ``grant'' permissions
(sometimes inexactly called ``control'' permissions), is ``mandatory''
on such a system
because it is not possible for anyone to modify this permission to allow
someone else
other than the owner of the file to change the access permissions. Thus,
the presence
of this access control is mandated by the implementation of the system
security policy,
and cannot be overridden at the discretion of the users. The word ``mandatory''
in this
sense has a different meaning than the word ``Mandatory'' in ``Mandatory
Access
Controls,'' since the latter usage refers to a specific type of access
control whose
mandatory nature is based on rules that must be followed. Adding further
mandatory or rule based restrictions specified on a per user basis could
strengthen most
identity based, discretionary partitioned systems.
However, there is an additional aspect to separation of resources. If
there is also a
restriction in terms of which programs (or classes of programs) are allowed
access to
resources, it is possible to limit the damage that can result from self
propagating
programs such as computer viruses. By separating resources, the principle
of least
privilege can be applied to limit the damage a virus could cause if one
did get into the
system. Such viruses normally act as Trojan horses: while performing operations
on
some authorized resource, they also covertly perform operations on resources
(executable program files) which they should not be permitted to modify.
If a program
whose purpose is to display mail files, for example, is prevented from
accessing
other program files because they are a type of resource not appropriate
or necessary
for the mail reader program to access, the mail reader program is prevented
from
covertly modifying the other program files while it is performing its
normal, authorized
function. This topic will be discussed further under encapsulation mechanisms.
The
remainder of this chapter discusses separation of resources mechanisms
grouped under
three policies: address space separation, encapsulation, and access control.
4.3.1 Policy of Address Separation
Throughout the history of computer architectures a variety of file and
memory
protection schemes have been developed to prevent a process from incorrectly
accessing a resource or overwriting memory that is not allocated to the
process.
Overwrite prevention is necessary since such memory often contains another
process's
code or data, or a portion of the operating system, control tables, or
device registers for
the system. We describe two address separation mechanisms that can be
used to
prevent unauthorized access or overwrites: separation of name spaces and
descriptors.
4.3.1.1 Mechanism of Separation of Name Spaces
Fundamental to the separation of name spaces is the principle that an
object that
cannot be named also cannot be addressed. This mechanism, separate from,
although
often confused with memory protection, is both an elementary way to think
about
protection and a basis for file protection. In this approach, users are
provided distinct
separate naming or ``catalog'' spaces, such that the same name (e.g.,
home directory)
refers to separate, non-overlapping objects when used by each user. The
result is that
each user's processes are unable to name or access the other's named objects,
the
object's addresses are resolved to a different locational meaning. This
was the primary
file system protection scheme of M.I.T's Compatible Time Sharing System
[Saltzer
1977]. This mechanism can be applied to protecting arbitrary named resources
where
each user or process has its own distinct name space in which it may use
resource
names without having to consider name usage by other processes. The principle
drawback of this mechanism is that it precludes sharing, at least via
named objects. It
does not provide for ``controlled sharing'' at all. So other mechanisms
have been
developed to address protection (e.g., access control lists) and sharing
of
information (e.g., working directories).
4.3.1.2 Mechanism of Descriptors
The approach to memory protection that is the basis of ``segmented''
memory
systems is based on special hardware implementing a descriptor table.
In the
descriptor based approach, all memory references by a processor are mapped
through
this special piece of hardware. The descriptor table controls exactly
which parts of
memory are accessible.
The entries in the descriptor table are called descriptors and describe
the location and
size of memory segments. A descriptor contains two components: a ``base''
value and a
``bound'' value. The base is the lowest numbered memory address a program
may use,
and the bound is the number of memory locations beyond the base that may
be used.
A program controlling the processor has full access to everything in the
base bound
ranges located in the descriptor table.
The descriptor based approach to memory protection operates on the assumption
that the address (name) of an object in memory is equivalent to the object
itself, and
thus that controlling the ability to use the address to reference the
object provides
control over the object. The advantages and disadvantages of descriptors
are a
direct result of this assumption. Because objects in primary memory are
always
referenced via an addressing mechanism, into which the descriptor based
protection
mechanism is interposed, it is straightforward to show that this protection
mechanism
serves as a reference monitor for objects that are in memory.
But not all objects reside in memory; they also reside on other devices,
some of
which (such as data on conventional 9-track tapes) are not referenced
by addresses at
the hardware level. Thus, it is necessary to impose control on access
to the device, then
implement additional protection mechanisms in software to control access
to the data
stored on the device. This approach complicates verification and is less
consistent with
the requirement that the reference monitor be ``small enough to be subject
to analysis
and tests.'' Furthermore, some memory locations, such as the CPU registers,
are not
protected in this way at all; the approach taken is to view these memory
locations as
being part of the subject, and thus the protection mechanism seeks to
prevent data from
being moved into these memory locations.
Granularity of segments is another problem in such systems. Since segment
sizes
vary, locating available space in memory is not trivial. As a result,
fixed sized
segments (commonly called pages) are used in most modern computer architectures.
Fixed sized segments, pages, also eliminate the need for the ``bound''
component of the
descriptor since all pages have the same bound.
One other disadvantage of descriptors is that the attributes of objects
protected by
descriptor based mechanisms are not attached to the objects in a consistent
and direct
way. Objects of similar attributes are grouped together where they can
be
protected under the same descriptor; if values are copied out of them
into registers or
into other objects, the attributes of the original object do not automatically
follow the
information. This is one of the principal reasons for the information
flow restrictions
that result from the traditional mandatory access control disclosure rules:
the rules are
intended to keep data with similar attributes together. However, there
are no
theoretical impediments that preclude direct attachment. Rather, this
is an
implementation issue and reflects the industry's past success and failure.
There are also advantages to the descriptor based approach. It is usually
very
efficient to implement in hardware, and access rights can be associated
with each
segment via the descriptors. The block sizes which descriptors reference
(the
granularity) are chosen specifically for this reason. These block sizes
enable the
otherwise time consuming arithmetic for computing permissions to be performed
by
partitioning the binary addresses into groups of digits, and routing these
groups of
digits through the hardware which processes the addresses to determine
access
permissions. Thus, the mechanism tends to be time and hardware efficient.
There is also the advantage of experience. Because this approach has
been
extensively used for several decades, it is well understood and well developed.
It has
strongly influenced the current view of computer security, as well as
the basic machine
architecture most people associate with a computer. Thus, existing concepts
fit well
into this approach.
4.3.2 Policy of Encapsulation
Encapsulation mechanisms provide important design paradigms for producing
systems with improved integrity properties. These mechanisms provide support
for the
type of system architecture requirements of the TCSEC (for B3 level features
and
assurance) which state, ``the TCB shall incorporate significant use of
layering,
abstraction, and data hiding'' [DOD 1985, p 38].
Underlying these design paradigms is the goal that software and hardware
components should be structured so that the interface between components
is clean
and well defined, and that exposed means of input, output, and control,
besides those
defined in the interface, do not exist. This approach serves to limit
complexity of the
module interfaces, as well as complexity of the software as a whole, since
it restricts
the means by which the modules of the system can interact. It also serves
to impose an
architectural discipline on those implementing the system, when provided
as a
mechanism rather than simply as a design paradigm, because it prevents
the
implementers from circumventing the defined interfaces in the course of
implementation. Four encapsulation mechanisms are discussed below: abstract
data
types, strong typing, domains, and actors. Given that certain resources
within the
system are encapsulated, we describe three well-defined interface mechanisms
that can
be used to manipulate those encapsulated resources: message passing, data
movement
primitives, and gates.
4.3.2.1 Mechanism of Abstract Data Types
Abstract data types precisely define the semantics of data and control
the operations
that may be performed on them. This mechanism defines a type to be a particular
set
of data values and a particular set of operations to perform on those
data. Thus, just as
there is usually a set of ``integers'' in a programming language, it is
possible to
define a ``degree'' type which consists of the degrees of a circle, and
operations
performed on values of this type. More complex types are also possible,
and may be
used to represent physical objects (robot arms, mechanical equipment,
etc.) for
programming purposes. Abstract data typing is a fundamental mechanism
of modern
high order languages.
Abstract data types have substantially improved the ability to support
integrity.
Their use addresses two of the three goals of integrity cited earlier.
They allow the
programmer to define data to be of types more directly derived from the
things the
data actually represents; thus, there is less of a ``semantic gap'' between
what the
programmer is trying to represent and what form the data actually takes.
This supports
the goal of ``maintaining internal and external consistency of data.''
With respect to
the other two goals, the mechanism, as it is normally used, does not prevent
unauthorized users from modifying the data; however, it can aid in preventing
authorized users from modifying the data in inappropriate ways, as long
as they
correctly use the defined operations for that type.
The existence of support for abstract data types does not in itself completely
ensure
that subjects cannot modify data in inappropriate ways since many implementations
allow programmers to override the data typing mechanisms. The adherence
to the
defined data types in such implementations is the responsibility of the
programmer.
4.3.2.2 Mechanism of Strong Typing
The mechanism of strong typing is simply the strong enforcement of abstract
data
types. The permitted values and operations of an abstract data type are
strongly
enforced by the compiler or hardware, and cannot be circumvented. Programmers
are
prevented from taking convenient and possibly efficient shortcuts in their
manipulations of the data, but integrity is enhanced by constraining programmers
to
manipulate data in well-defined ways. Users are prevented from accidentally
misusing the data type, especially when they may not understand the details
of a
particular data type. Even though an object's representation might be
compatible
with operations not associated with that data type, such operations will
not be
permitted.
For example, consider a data type whose value represents the angular
position of a
gun turret. Suppose that the angular position is represented using the
computer's
hardware representation for a floating point number. Even though this
floating point
number is allowed by the hardware to take on a very wide range of values,
the use of
strong typing could prevent the normal floating point operations from
being
performed on the number. Instead, a new set of operations would be provided
for
modifying the number, which constrains the resulting values to meet acceptable
conditions.
Thus, the ``+'' operation might be defined to prevent a programmer from
incrementing the turret position such that its angle was greater than
360 degrees. This
``+'' operation might also prevent a programmer from adding more than
a certain
increment to the position in a single operation (to meet physical restrictions
of the
machinery that rotated the turret). This ``+'' operation might also be
defined to have the
side effect of repositioning the turret to the new value whenever the
number was
changed, so that the number always accurately reflected the position of
the turret.
Strong typing would prevent the use the machine's general floating point
``+'' operation
instead of the operation defined for the turret-position data type. Thus,
it would not be
possible to either (1) set the turret position to invalid values, or (2)
set the number so it
did not accurately reflect the turret position. This form of strong typing
is currently
available in the Ada programming language and in other high order languages.
Strong typing is not limited to programming languages. For example, the
mechanism may be used to prevent a pilot of a particular type of aircraft
from
commanding it to perform an operation for which it was not designed and
that would
be damaging to the aircraft's structure. The values to which aircraft
controls may be set
can be considered analogous to the set of values that data of a particular
type may take
on. The specific set of allowed operations the pilot may perform on the
controls may
be considered to be analogous to the allowed set of operations on a conventional
data
type. Ultimately, the control values and operations may actually be represented
via
conventional programming language data types in, for example, a ``fly
by wire''
system; in such a case, maintaining a consistent mapping between the programming
language type restrictions and the user interface (aircraft controls)
in a way acceptable to
the pilot may prove a significant design challenge.
4.3.2.3 Mechanism of Domains
A domain is a mechanism that uses the principle of separation to protect
resources.
A domain achieves protection by encapsulating its resources in what is
effectively a
distinct address space. As described in [Boebert 1990] there are at least
two ways to
implement domains: as common subsets of subjects, and as equivalence classes
of
subjects.
Domains are typically implemented as common subsets of subjects. The
Multics
ring mechanism is a prototypical example of domains implemented in this
way. The
common subsets are the rings. The address space of each subject is subdivided
into a
series of rings. The rings have a hierarchical relationship, with the
innermost ring being
the one with highest privilege. Program code executing in a given ring
can access data
objects in rings of lower privilege, and they can make procedure calls
to rings of higher
privilege. Due to the hierarchical relationship among domains in this
type of
implementation, domains of higher privilege are protected from domains
of lower
privilege. Protection between mutually suspicious domains cannot be supported.
The LOCK architecture [Boebert 1990] overcomes this problem by implementing
domains as equivalence classes of subjects. Each instance of a domain
is encapsulated
in a single subject, and has its own separate address map to achieve isolation.
Shared
objects, which are mapped into the address space of two or more subjects,
provide the
means of data flow between domains. Control flow requires a special mechanism
because each subject has its own execution point which stays within the
address space
of that subject. The mechanism used in LOCK is intersubject signalling.
4.3.2.4 Mechanism of Actors
Programs can be designed to function as actors, in which the user of
the program
issues a request to access an object in a particular way, and the program
then acts on the
request itself. In such a case, the program interprets the request and
then performs the
appropriate action, rather than having the action performed upon the object
by an
outside entity. An example would be an integer object, which would be
given the
request ``add 12 to yourself.''
Actors are partly software structuring mechanisms; they help to organize
software
into distinct, autonomous parts. But they also reduce the risk of ``tampering''
with
the object by direct modification, since the only way to cause the object
to be modified
is by requesting the program (actor) to do so itself. The program can
be designed to
check requests before acting upon them, and to reject improper requests.
Actors are
distinct from mechanisms in which the user process ``executes'' a segment
of code
directly in order to manipulate an object (i.e., a subroutine written
to manipulate data
of a particular type). The underlying implementation distinctions between
the two,
however, can be subtle.
The actor concept explicitly requires that individual modules are responsible
for
performing operations on their data themselves, in response to requests
from modules
that use them. This is, in part, simply a way of looking at the software.
Thus, the same
operation ``a+b'' can be thought of as meaning either ``fetch values a
and b and perform
the `+' operation on them, giving a new value,'' or ``request a to add
b to itself and
return the new value to the requester.'' The conceptual difference is
that the ``fetch
and perform'' concept implies that the user directly accesses the values,
whereas the
latter (actor) concept implies that the values are autonomous entities
that respond to
user requests.
The actor concept suggests that the values are less passive and thus
more able to be
self-protecting-a view that can promote a better software architecture
from the security
standpoint. It is, however, necessary to continue to keep efficiency and
the architecture
of the underlying hardware in mind when using actors. The higher level
of abstraction
should not hide the importance of efficient architectural design from
the implementer,
particularly in embedded systems that often have real-time requirements.
4.3.2.5 Mechanism of Message Passing
Message-passing mechanisms, when used as the primary interface between
modules, restricts improper access because requests and data are communicated
to the
software components through a well-defined mechanism that is distinct
from the
mechanisms used to modify data directly (e.g., direct writes to memory,
input/output
operations, branches into module code entry points). Trusted Mach [Branstad
1989] is
an example of the use of such a mechanism. Message passing mechanisms,
of course,
use some of these direct-access mechanisms internally. But the message
passing
paradigm controls the accesses into components implementing the message
passing
mechanism, rather than distributing the use of the direct-access mechanisms
throughout the system.
As a result, implementation of a reference monitor, as well as verification
of the
mechanisms used to affect intermodule communication, are simplified by
this
localization of function. The operations that are directly available to
the users (the
individual software modules wishing to communicate with one another) do
not
provide a way to directly modify or execute portions of other modules;
they only
provide the ability to enqueue well-defined requests to pass data to the
other modules.
These requests can then be checked for correctness, and the modifications
can be
carried out at a time when the receiving module is ready to handle the
data (i.e.,
when the receiving module executes a receive message operation).
4.3.2.6 Mechanism of the Data Movement Primitives
Most computer architectures equate a data object with the place in which
it is stored.
A computer architecture which uses the data movement primitives ``get''
and ``put''
distinguishes a data object from its storage location [Roskos 1984]; it
is possible for a
process to move (get) an object out of its storage location (which may
be shared
among many processes) into a private location, perform operations on the
object, and
then move (put) it back into the shared location. During the time the
object is in the
private location, it cannot be accessed by other processes, and references
to the shared
location generate an exception condition. This architecture addresses
integrity
problems in which multiple processes share data and try to update it at
the same time,
causing the data object to be corrupted.
4.3.2.7 Mechanism of Gates
When an object (or simply a subroutine) is able to be executed directly
by a process,
it is possible to limit the actions that the process can perform through
the use of gates.
A gate is a controlled entry point into a segment of code. It is not possible
to enter the
code except through the gate, and restrictions can be enforced regarding
which
processes are allowed to enter the gate (e.g., only code with certain
privileges, or
acting on behalf of a given user, may be allowed to do so).
Gates can also be used to cause a transition in privilege. For example,
a process
which enters a routine via a gate may gain extra access permissions or
allowed
operations, since use of the gate ensures that a specific segment of code
will be
executed while these permissions are granted. The code can be verified
to ensure that
it does not allow unauthorized use of the privileges. Upon exit from the
routine, the
extra privileges are revoked by the system.
4.3.3 Policy of Access Control
The policy of access control restricts which data a subject is allowed
to access. An
evolving framework for addressing restrictions on access control is given
in
[Abrams 1990]. Restrictions can be either identity-based or rule-based.
Identity-based
controls are typically associated with discretionary security policies,
and rule-based
controls are typically associated with mandatory security policies. In
identity-based
mechanisms, the identity of a subject or object must match the identity
specified in the
particular access control mechanism. We discuss three mechanisms that
can be used
to enforce identity-based access restrictions: capabilities, access control
lists, and
access control triples. In rule-based mechanisms, one or more attributes
of a subject
must obey specified rules in relation to corresponding attributes of an
object that the
subject desires to access. We discuss labels as a mechanism to enforce
rule-based
access restrictions.
4.3.3.1 Mechanism of Capabilities
Capabilities provide a general and flexible approach to access control.
A capability
is a specially protected object (or value representing it) that contains
the name of the
object to which it refers along with a specific set of attributes or permissions
that specify
what types of access the possessor of the capability is granted. It can
be thought of as
an unforgeable ticket, which, when presented, can be taken as incontestable
proof that
the presenter is authorized to have the specified access to the object
named in the
ticket. Thus, when a subject wants to access an object, the subject simply
presents the
appropriate capability and a descriptor is immediately created (giving
the subject access
to the object) with no additional permission checks being performed.
The system can invalidate a capability (so that possession of it no longer
grants
access), can control whether or not it is possible to give away the capability
to another
process, or can limit the number of times a capability may be used to
access an object.
Capabilities provide a very powerful and flexible means of controlling
access to
resources, and distributing that access to others. This topic is discussed
further and
many implementations are identified by Gligor et al. [1987].
4.3.3.2 Mechanism of Access Control Lists
Where capabilities employ a ticket-oriented strategy to access control,
access control
lists (ACLs) employ a list-oriented strategy. An access control list contains
the names
of subjects that are authorized to access the object to which it refers,
as well as specific
permissions that are granted to each authorized subject. Thus, when a
subject wants to
access an object, the system searches for an entry for the subject in
the appropriate ACL.
If an entry exists, and if the necessary permissions are part of that
entry, then a
descriptor is created. The list-oriented strategy requires one more permission
check
than the ticket-oriented approach when a subject requests access to an
object.
ACLs can be thought of as a somewhat more flexible form of strong typing,
although
conceptually they are not as powerful for programming purposes. Their
generality
allows one to set access permissions arbitrarily, with the result that
someone who does
not fully understand an application might grant a user access to programs
and data
which were incompatible. This could result in a program operating upon
data it was not
designed to handle, and thus performing incorrectly. This situation is
largely an
educational concern for users, but is of importance in the design of programmable
systems.
In a system in which names are considered equivalent to objects, such
that
controlling the use of names controls access to the objects they reference,
a potential
problem exists if multiple names are allowed to reference the same object.
These names
essentially provide alternate ``paths'' to the same object, and if ACLs
are associated
with the names rather than with the object itself, a user's access may
be restricted if a
reference is made via one name, but not restricted if the reference is
made via another
name. The result is that a given user's access permissions for an object
can be
inconsistent when viewed in terms of these multiple names. Multiple names
can be a
problem in database systems where multiple ``views'' are provided with
access
controls associated with the views. It is also a problem in conventional
operating
systems when access permissions are associated with directories and multiple
``links''
(directory references) exist to the same file. This problem exists regardless
of
whether the access permissions for files are stored in the directories,
or whether access
controls on the directories themselves are used to control access to the
objects
referenced within the directories.
4.3.3.3 Mechanism of Access Control Triples
An access control triple is a list-oriented mechanism that was conceptually
introduced by Clark and Wilson [1987] to address access control requirements
more
commonly associated with ``commercial'' computer systems rather than ``military''
systems. It provides a finer granularity of access control than normally
associated
with capabilities and ACLs by specifying required linkage for a user,
program, and
object along with specific permissions that are granted to the user while
invoking the
particular program on the given object. The triples of the Clark-Wilson
model
essentially define allowed type operations, and the Integrity Verification
Procedures
(IVPs) of the Clark-Wilson model define a set of permitted values for
data of a given
type.
A principal distinction, then, is the association of a given set of triples
with a given
object, rather than with a given type. This distinction is necessary because
the Clark-
Wilson triples control which users may perform operations on a given object,
and thus
provide one of the components of integrity enforcement which is missing
from
conventional strong typing. To do this form of integrity enforcement,
access permissions
must be specified on a per object basis, not simply by type. ACLs also
specify these
access permissions, but they do not include a detailed specification of
what operations
may be performed: they simply indicate whether or not each predefined
set of
operations is permitted.
Access control triples are not a strict generalization of strong typing
because the per
object specification property of Clark-Wilson does not allow triples to
implement
conventional strong typing. A single triple describes an existing object,
not a set of
objects that will be created in the future. A similar argument can be
made with regard
to ACLs. That is, ACLs permit a wide variety of operations to be performed
without
explicitly specifying them as long as they do not violate the access restrictions
imposed
by the ACLs.
4.3.3.4 Mechanism of Labels
It is also possible to associate one or more labels with each user, process,
and
resource to implement rule-based access control. Processes inherit user
labels, and a
process is granted access to a resource only if their two labels meet
some criterion of
comparison. For example, a TCSEC mandatory access control label has both
a
hierarchical and a non-hierarchical component. Each subject is assigned
a clearance and
one or more categories or compartments, and each object is typically assigned
a
classification and one category. A subject is granted access to an object
based on a
comparison of these values. In this case, the comparison is via an ordering
relation
rather than an equivalence relation, but the underlying principle is the
same. This
mechanism also addresses the concepts of rings and privilege states, in
which a
process is granted access to successively greater numbers of resources
as its label
increases in value according to some ordering relation.
The underlying concept of labels has analogies to capabilities in the
sense that the
subject has ``possession'' of a particular value which gives the subject
access to certain
objects. As with capabilities, the subject cannot change the value stored
in the label;
unlike capabilities, the subject can only have one access label value
per rule set at a
given time. For example, a user may be cleared to the Secret level, but
if he has
logged on at the Unclassified level, the rule set will not allow him to
access data at the
Secret level.
A label is a relatively simple mechanism that can serve as the basis
for a number of
more complex mechanisms. The principal limitation is that a subject can
only have
one access label value per rule set at a given time. This fact limits
the flexibility of the
mechanism. Increasing the number of labels per subject or object limits
their benefit,
since complexity of label assignment rapidly increases unless a structured
mechanism such as capabilities, access control lists, or access control
triples is used
instead.
4.4 POLICY OF FAULT TOLERANCE
Systems that support mission-critical applications must not only preserve
integrity to
the extent possible, but also must detect and attempt to correct integrity
failures that
result from unavoidable situations, such as physical failures of equipment
or media.
Systems which do this support a policy of fault tolerance.
The policy of fault tolerance potentially involves two parts. The first
part is the
detection of errors. Detection is necessary for a system to determine
when a failure
has occurred. Detecting errors that are corrected by the system is as
essential as
detecting failures that cannot be corrected, since such failures may indicate
a potential
degradation of system performance, or may indicate that the system is
approaching a
threshold at which errors are no longer correctable. We will discuss fault
tolerant
error detection mechanisms under the policy of summary integrity checks.
The second
part of the policy of fault tolerance is the attempted correction of errors.
We will discuss
fault tolerant error correction mechanisms under the policy of error correction.
4.4.1 Policy of Summary Integrity Checks
All mechanisms supporting the policy of summary integrity checks provide
a
``second copy'' of a group of data against which the first copy may be
compared in
order to detect changes. Nearly all of these mechanisms operate by producing
a
smaller piece of data which is computed from the collection of data whose
integrity is to
be verified. This approach has an inherent weakness because reducing the
size of the
summary data will result in loss of information, except to the extent
that the original
data has redundancies which can be removed by data compression techniques.
The
result is there will be more than one value of the original data for which
the summary
data is identical, and by judiciously changing the original data, the
computed
summary data may still indicate that the data is unchanged. This ``judicious
changing''
type of attack is used by some virus programs to circumvent checksum programs
intended to detect the viruses. We describe five summary integrity check
mechanisms
below: transmittal lists, checksums, cryptographic checksums, chained
checksums, and
the check digit.
4.4.1.1 Mechanism of Transmittal Lists
When batches of data are stored or transmitted together, a transmittal
list may
be attached to the data. This list identifies what data are included in
the batch, and
may be used to verify that no data are missing. Transmittal lists are
used to provide
confirmation that all the components of a multipart data object are present,
but do not
generally provide for detection of modification of the components still
present, unless
combined with other techniques. The same is true with data counts, a generalization
of
a transmittal list in which simple counts of data are used to ensure that
no data are
missing. Data counts are weaker than transmittal lists in the sense that
they do not
provide information on missing components.
4.4.1.2 Mechanism of Checksums
When a block of data is transferred from one point to another, a checksum
is often
added to the block of data to help detect errors. A checksum is a numeric
value that is
computed based on the entire contents of the data. When the original data
is created, a
checksum is calculated and appended to it. The checksum is then regenerated
when
the data is received at its destination or, in some applications, when
the data is read
from memory. The regenerated checksum and the original checksum are then
compared to determine if an error has occurred. Checksums do not, however,
protect
the data from destruction; they only provide a means for detecting when
the data has
been tampered with.
A checksum is one of the stronger mechanisms for integrity checking.
It can be very
difficult for an adversary to change the data without causing the checksum
computed
from the changed data to be different from the checksum computed from
the original
data. There are two properties of checksums that must be considered. First,
checksums
need to be accompanied by other mechanisms (e.g., time stamps) to prevent
replay.
Second, it must be realized that if the check- sum has fewer bits (contains
less
information) than the data itself, there will always be more than one
value of the data
that will result in the same checksum value. Given this fact, the function
used to
compute the checksum should be such that changing a single, small portion
of the data
will result in a high probability that the checksum will change. Also,
the set of all
possible values of the data should produce all possible values of the
checksum, with the
probability of generating a given checksum being evenly distributed for
all possible
values of the data.
4.4.1.3 Mechanism of Cryptographic Checksums
When data is transmitted over an open communications medium, where both
the
data and the checksum are exposed to modification, the original data may
be
vulnerable to undetected modification. An adversary may be able to modify
the data,
recalculate the checksum, and store them in place of the original pair.
To counteract
this threat, cryptographic techniques are used. Once a checksum is computed,
it is
encrypted with a protected encryption ``key.'' If the checksum is encrypted,
an
adversary must gain access to the encryption algorithm and key to change
the checksum
to indicate that the data is still unmodified. With protected keys, the
encryption
algorithm may be assumed to be known or discoverable by the adversary
without harm
as long as the specific key remains unknown. Keeping both the algorithm
and the
keys protected increases the work factor of the adversary in attacking
the system,
but may also increase the cost of the system.
4.4.1.4 Mechanism of Chained Checksums
Checksums (either conventional or cryptographic), when applied to sequenced
data,
may be made a function of the previously seen data. In accounting, these
chained
check- sums are termed run-to-run totals. For example, a checksum may
be computed
across multiple data, each of which has a checksum itself. This method
is used to give
assurance via a single number that all preceding data is unaltered. However,
as the
amount of data included in the chain or sequence increases, the probability
of
undetected errors increases because there are more data values that will
give the same
checksum as the number of bits of data increases in comparison to the
number of bits of
the checksum. Thus, chained checksums have the advantage that they can
detect
deletion of portions of the data, but have the disadvantage that the size
of the data being
checked can become large in proportion to the size of the checksum.
4.4.1.5 Mechanism of the Check Digit
A check digit is simply a special case of a checksum, where the checksum
is a single
digit. It is normally used only to check for gross unintentional errors,
such as
mistyping of a numeric identifier code. A check digit does not provide
much protection
against malicious attacks or against noisy transmission lines because
the probability is
relatively high that even a randomly chosen digit will occasionally be
correct. A ``parity
bit'' is an example of a binary check digit.
4.4.2 Policy of Error Correction
In addition to simply detecting incorrect data, it is possible to use
methods to correct
errors in the data. The simplest approach to error detection would be
to provide a
certain number of redundant copies of the data, possibly by different
channels, and then
compare these at the time when it is desired to determine whether the
data integrity
has been violated. This concept can be extended to error correction if
it is possible to
tell which of the redundant copies of the data has not been altered. Various
error
correction methods give varying probabilities of retrieving the original,
unaltered data.
We describe two of these redundant copy methods below: duplication protocols
and
handshaking protocols.
The process of providing redundant data can be improved upon in terms
of
efficiency if assumptions are made about the types of errors likely to
occur. In
particular, if it is expected that only a small portion of any one block
of data is likely to
be altered, it is possible to reduce the amount of redundant data that
has to be sent in
proportion to the number of bits of data expected to be changed. Error
correcting codes
can be used to achieve error correction with less than a completely redundant
copy
of the original data.
4.4.2.1 Mechanism of Duplication Protocols
In environments in which there is only one-way data communication, such
as data
distributed by one-way radio broadcast, duplication protocols are used.
These
generally involve duplicating the data being sent. One approach involves
duplication in time, re-sending the same data value several times, along
with check
information. For example, a standard data protocol used in commercial
shipping
communications involves representing each distinct data value as a binary
number, the
sum of whose digits is a constant number, and sending small groups of
consecutive
values several times. If it is found that one of the data values consists
of digits that do
not add up to the constant, the value is assumed incorrect, and one of
the redundant
copies of the data is tried. By timing the resending of redundant information
according
to known error-generating properties of the medium, it is possible to
minimize the
probability that all copies of the data value will be in error. The sending
of small
groups of values several times rather than immediately repeating each
value before
proceeding to the next serves to increase the likelihood that an error-generating
phenomenon will have abated before the data are resent.
Another approach to duplication of one-way data is by sending it by multiple
media. In the case of radio transmissions, the data may be sent on several
frequencies
at the same time, since phenomena that interfere with communication on
one frequency
often do not affect a different frequency at the same time. In the case
of
communications by networks, the data can be sent simultaneously by several
paths.
These approaches are essentially a form of redundant processing.
The simple redundancy exemplified by duplication protocols has a principal
benefit
of simplicity; the algorithms needed to regenerate the data are simpler
than those of
more compact error correction codes, and the density of error allowed
may be greater.
Use of a diversity of media likewise allows for a greater density of errors;
one or more
of the redundant channels may fail completely as long as one other channel
continues
to function without error. But considerably more hardware resources may
be required
for such an approach to duplicate all the components that may fail.
4.4.2.2 Mechanism of Handshaking Protocols
Handshaking protocols are one of the most frequently seen approaches
to error
correction where two-way communication exists, as in computer networks.
In
handshaking protocols, a block of data is sent, along with a check value
for use with a
summary integrity check mechanism; the check value is used to check the
transmitted
block for error on the receiving end. A reply is then returned to the
sender indicating
whether or not the received data checked as valid. If an error is detected,
the receiver
repeatedly requests the data until it is received without error. An example
of a
handshaking protocol is the X.25 protocol used in hardwired and radio-based
communications networks.
This protocol is complicated by the fact that either messages or replies
may be
entirely lost, and thus such a protocol must handle non-responses as well
as
negative responses. This is the reason that messages indicating successful
transmission
are returned, not just unsuccessful transmission. Furthermore, efficient
use of the
communications medium may require that long delays not be incurred waiting
for a
reply to come back from the receiver; in such a case, later blocks of
data may be sent
while awaiting a reply to the first block. If a reply eventually comes
back indicating
that a given block was not received, it can be resent out of sequence.
This in turn
requires use of the chained checksum mechanism discussed earlier, to ensure
that all
blocks are received and are put in the proper order.
To avoid building up an excessive backlog of unacknowledged messages,
there is
usually a ``window'' of unacknowledged messages that are allowed to be
outstanding;
if more messages would be sent than are allowed by this limit, sending
stops until the
backlog is filled. Some protocols which allow sending messages in two
directions at
the same time obtain further efficiency by combining acknowledgement messages
for
data messages going in one direction with data messages going in the opposite
direction, and vice versa. The design of these protocols can become quite
complex, but
the area is well researched and can result in very efficient protocols.
On the other hand,
an isolated error in a message may require the entire message to be resent,
and thus
the size of the message unit in proportion to the frequency of errors
is an important
consideration in designing these protocols. This mechanism is commonly
used in
supporting the real-time requirements of most computer systems, although
it is
omitted from certain high-performance computer systems.
4.4.2.3 Mechanism of Error Correcting Codes
Duplication and handshaking protocols assume that failure occurs at
an
intermediate point beyond the sender of the data. If the sender's copy
of the data is
damaged, these protocols will not be able to recover the data. Thus, an
error
correcting code must be used on the original copy. For example, Hamming
codes
employ the concept of overlapping parity to achieve error correction of
original data.
The Hamming single error correcting code is formed by partitioning the
original
data bits into parity groups and specifying a parity bit for each group.
The ability to
locate which bit is erroneous is obtained by overlapping the groups of
bits. A given data
bit will appear in more than one group in such a way that if the bit is
erroneous, the
parity bits that are in error will identify the erroneous bit. For example,
suppose that
there are four data bits (d3,d2,d1,d0) and, as a result, three parity
check bits
(c1,c2,c3). The bits are partitioned into groups as (d3,d1,d0,c1), (d3,d2,d0,c2),
and
(d3,d2,d1,c3). Each check bit is specified to set the parity, either even
or odd, of its
respective group. Now, if bit d0, for example, is erroneous, both c1 and
c2 are incorrect.
However, c3 is correct because the value of d0 has no impact on the value
of c3.
Therefore, the error in bit d0 can be corrected.
Typically, an error correcting code is used to allow some limited portion
of the
original message to be regenerated, given the correct value of the remaining
portion.
As the amount of lost information that the code is supposed to be capable
of
regenerating increases, the size of this code increases, so a tradeoff
is made based on
the expected rate of error in the data. If the error rate is low, a smaller
code may be
used, since the probability of a large number of errors in a single block
decreases.
5 INTEGRITY MODELS AND MODEL IMPLE-
MENTATIONS
A computer security model is a high-level specification or an abstract
machine
description of what a system does [Goguen 1982]; it provides a framework
for linking
a security policy (security requirements for a given system) to the mechanisms
that are
used to implement the policy. While models describe what types of mechanisms
are
necessary to satisfy an integrity policy, model implementations describe
how specific
mechanisms can be used together in a system to achieve integrity protection
required by
a particular security policy. Several models and model implementations
are examined
in this chapter.
5.1 INTEGRITY MODELS
In this section, we describe and analyze five models that suggest different
approaches to achieving computer integrity: Biba, Goguen and Meseguer,
Sutherland,
Clark and Wilson, and Brewer and Nash. (footnote #1) Three of these models
(Goguen
and Meseguer's, Sutherland's, and Brewer and Nash's) were not originally
intended as
integrity models, but we show how they can be viewed as applying to the
needs of
integrity. Although all five of these approaches establish sound restrictions
for
limiting the manipulation of data, we have not been able to empirically
determine
whether any of the models are complete or sufficient with respect to integrity.
[1] The Clark and Wilson model is not stated in formal mathematical terms
like the others, but formal axioms are not necessary to compare the ad-
vantages and disadvantages of each model.
5.1.1 Biba Model
5.1.1.1 Discussion of Biba
The model defined in [Biba 1977] was the first of its kind to address
the issue of
integrity in computer systems. This approach is based on a hierarchical
lattice of integ-
rity levels. The following basic elements are used to mathematically define
the Biba
model:
S: the set of subjects s; the active, information processing elements
of a
computing system;
O: the set of objects o; the passive information repository elements
of
a computing system (the intersection of S and O is the null set);
I: the set of integrity levels;
il: S x O ==> I; a function defining the integrity level of each subject
and object; defines a lattice under the relation leq;
leq: a relation (subset of I x I) defining a partial ordering ``less
than or
equal'' on the set of integrity levels I;
min: POWERSET(I) ==> I, a function returning the greatest lower bound
(meet) of the subset of I specified;
o: a relation (subset of S x O) defining the capability of a subject,
s
element_of S, to observe an object, o element_of O: s o o;
m: a relation (subset of S x O) defining the capability of a subject,
s
element_of S, to modify an object, o element_of O: s m o; i:a relation
(sub-
set of S x S) defining the capability of a subject, s1 element_of S, to
invoke
another subject, s2 element_of S: s1 i s2.
Integrity is evaluated at the subsystem level. A subsystem is some subset
of a
system's subjects and objects isolated on the basis of function or privilege;
a computer
system is defined to be composed of any number of subsystems, including
only one.
Integrity threats are classified by Biba as being either internal or external
to a
subsystem. An internal threat arises if a component of the subsystem is
malicious or
incorrect. An external threat is posed by one subsystem attempting to
change
(improperly) the behavior of another by supplying false data or improperly
invoking
functions. Biba feels internal threats are sufficiently handled by program
testing and
verification techniques; the Biba model then only addresses external threats.
The Biba model elements support five different integrity policies, which
are
described below: the Low-Water Mark Policy, the Low-Water Mark Policy
for Objects,
the Low-Water Mark Integrity Audit Policy, the Ring Policy, and the Strict
Integrity
Policy. There is a sixth policy, called the Discretionary Integrity Policy,
based on
ACLs and the Ring Policy that actually describes a specific proposal for
modelling
integrity protection in the Multics operating system. Since ACLs are discussed
earlier
and the Ring Policy is discussed here, the Discretionary Integrity Policy
is not
addressed separately.
5.1.1.1.1 Low-Water Mark Policy
In this policy, the integrity level of a subject is not static, but is
a function of its
previous behavior. The policy provides for a dynamic, monotonic, and non-increasing
value of il(s) for each subject. The value of il(s), at any time, reflects
the low-water mark
of the previous behavior of the subject. The low-water mark is the least
integrity level
of an object accessed for observation by the subject, and is formalized
by the following
axioms:
for_all s element_of S, o element_of O
s m o ==> il(o) leq il(s)
for_all s1,s2 element_of S
s1 i s2 ==> il(s2) leq il(s1)
For each observe access by a subject s to an object o:
il'(s) = min {il(s), il(o)}
where il'(s) is the integrity level of s immediately following the access.
5.1.1.1.2 Low-Water Mark Policy for Objects
In addition to changing the integrity level of subjects, the Low-Water
Mark Policy
for Objects postulates that the integrity level of modified objects also
changes. This
alternate policy can be characterized by the following rules.
For each observe access by a subject s to an object o:
il'(s) = min {il(s), il(o)}
For each modify access by a subject s to an object o:
il'(o) = min {il(s), il(o)}
5.1.1.1.3 Low-Water Mark Integrity Audit Policy
This audit policy is an unenforced variant of the Low-Water Mark Policy
for Objects.
It provides a measure of possible corruption of data with ``lower'' integrity
level
information. A ``current corruption level'' (cl) for subjects and objects
is defined in the
following manner.
For each observe access by a subject s to an object o:
cl'(s) = min {cl(s), cl(o)}
For each modify access by a subject s to an object o:
cl'(o) = min {cl(s), cl(o)}
The value of cl for an object represents the least integrity level of
information which
could have been used to modify the object.
5.1.1.1.4 Ring Policy
The Ring Policy provides kernel enforcement of a protection policy addressing
direct modification. The integrity levels of both subjects and objects
are fixed during
their lifetimes and only modifications of objects of less than or equal
integrity level are
allowed. Flexibility of the system is substantially increased by allowing
observations
of objects at any integrity level. The policy is defined by two axioms:
for_all s element_of S, o element_of O
s m o ==> il(o) leq il(s)
for_all s1,s2 element_of S
s1 i s2 ==> il(s2) leq il(s1)
5.1.1.1.5 Strict Integrity Policy
The Strict Integrity Policy is the mathematical dual of the confidentiality
policy
presented in the TCSEC [DOD 1985]. It consists of three parts: a Simple
Integrity
Condition, an Integrity *-property, and an Invocation Property. The Simple
Integrity
Condition states that a subject cannot observe objects of lesser integrity.
Written in
Biba's mathematical notation
for_all s element_of S, o element_of O
s o o ==> il(s) leq il(o)
This rule constrains the use of objects (data or procedures) to those
whose non-
malicious character (by virtue of their integrity level) the subject can
attest (those
objects having an integrity level greater than or equal to that of the
subject). Biba
considers execute access to be equivalent to observe access, so objects
must have an
integrity level greater than or equal to that of the requesting subject
in order to be
executed.
The Integrity *-property states that a subject cannot modify objects
of higher
integrity. Written in Biba's notation
for_all s element_of S, o element_of O
s m o ==> il(o) leq il(s)
This rule ensures that objects may not be directly modified by subjects
possessing
insufficient privilege. The rule, however, assumes that the modifications
made by an
authorized subject are all at the explicit direction of a non-malicious
program. The
unrestricted use of subsystems written by arbitrary users (to whose non-malicious
character the user cannot attest) does not satisfy this assumption; the
Simple Integrity
Condition guarantees this assumption is satisfied.
The Invocation Property states that a subject may not send messages to
subjects of
higher integrity. Mathematically, the integrity level of the receiving
subject must be
less than or equal to the integrity level of the sending subject:
for_all s1,s2 element_of S
s1 i s2 ==> il(s2) leq il(s1)
Invocation is a logical request for service from one subject to another.
Since the
control state of the invoked subject is a function of the fact that the
subject was
invoked, invocation is a special case of modification. Therefore, this
rule follows
directly from the Integrity *-property.
5.1.1.2 Analysis of Biba
Biba defines integrity as a relative measure; it is not absolute. According
to this
definition, a subsystem possesses the property of integrity if it can
be trusted to
adhere to a well-defined code of behavior. No a priori statement as to
the properties
of this behavior are relevant to determining whether or not the subsystem
possesses
integrity; all that is required is that the subsystem adhere to the code
of behavior. For
this model, the goal of computer system integrity is thus the guarantee
that a subsystem
will perform as it was intended to perform by its creator.
This is a rather broad interpretation of integrity. The goal of every
computer
system should be to perform as it was intended to perform; the real issue
is whether the
creator designed the system in a manner that can achieve integrity. The
Biba model
provides a hierarchical lattice for identifying authorized users and providing
separation at the user type level. These attributes allow the Biba model
to address the
first goal of integrity identified at the beginning of the paper: preventing
unauthorized
users from making modifications.
Of the integrity policies discussed by Biba, the Strict Integrity Policy
is by far the
most widely addressed, so much so that this policy is often assumed when
the Biba
model is discussed. The Strict Integrity Policy is the dual of one of
the most common
and most thoroughly studied computer security policies/models, Bell and
LaPadula.
A drawback to Biba's Strict Integrity Policy is how to assign appropriate
integrity
labels. The Bell and LaPadula model fits the government classification
system (e.g.,
hierarchical levels like Top Secret and Secret, and non-hierarchical categories
like
NATO). There are established criteria for determining which disclosure
levels and
categories should be given to both personnel (subjects) and documents
(objects).
There are currently no corresponding criteria for determining integrity
levels and
categories. In fact, the use of hierarchical integrity levels, which suggests
that some
determination will be made about the ``quality'' of data and the ``quality''
of users,
seems inapplicable to most practical problems.
5.1.2 GOGUEN AND MESEGUER MODEL
5.1.2.1 Discussion of Goguen and Meseguer
Goguen and Meseguer [1982] introduce an approach to secure systems that
is
based on automaton theory and domain separation. Their approach is divided
into
four stages: first, determining the security needs of a given community;
second,
expressing those needs as a formal security policy; third, modelling the
system which
that community is (or will be) using; and last, verifying that this model
satisfies the
policy. Their paper focuses on stages two (policy) and three (model);
this discussion
focuses on the model.
Goguen and Meseguer distinguish sharply between a security policy and
a security
model. A security policy is defined as the security requirements for a
given system
(based on the needs of the community). In general, security policies are
very simple,
and should be easy to state in an appropriate formalism. Goguen [1982,
p 11] provides
a very simple requirement language for stating security policies, based
on the concept
of noninterference, where
one group of users, using a certain set of commands, is noninterfering
with another group of users if what the first group does with those com-
mands has no effect on what the second group of users can see.
A security model is defined as an abstraction of the system itself; it
provides a basis
for determining whether or not a system is secure, and if not, for detecting
its flaws.
A high-level specification or an abstract machine description of what
the system does
are examples of a security model. The authors develop a set theoretic
model which is a
sort of generalized automaton, called a ``capability system.'' They achieve
noninterference by separating users into different domains; a domain is
defined as the
set of objects that a user has the ability to access [NCSC 1988]. The
Goguen and
Meseguer model has an ordinary state machine component, along with a capability
machine component which keeps track of what actions are permitted to what
users.
5.1.2.1.1 Ordinary State Machine Component
The model is introduced by starting with the classic case in which what
users are
permitted to do does not change over time. It is assumed that all the
information
about what users are permitted to do is encoded in a single abstract ``capability
table.'' The system will also have information which is not concerned
with what is
permitted; this information will include users' programs, data, messages,
etc. In the
Goguen and Meseguer model, a complete characterization of all such information
is
called a state of the system, and S is defined as the set of all such
states. The system
will provide commands that change these states; their effect can be described
by a
function
do: S x U x C -> S
where C is the set of state changing commands and U is the set of users.
It might be
that if user u is not permitted to perform a command c, then do(s,u,c)
= s; such
security restrictions can be implemented by consulting the capability
table, and are
simply assumed to be built into the function do.
It is also assumed that for a given state and user, we know what output
(if any) is
sent to that user. This aspect of the system can be described by a function
out: S x U -> Out
where Out is the set of all possible outputs (e.g., screen display states,
listings, etc.). It
is assumed that all information given to users by the system is encoded
in this
function. Putting this all together and adding an initial state, the result
is an ordinary
state machine M consisting of the following:
a. A set U whose elements are called ``users.''
b. A set S whose elements are called ``states.''
c. A set C whose elements are called ``state commands.''
d. A set Out whose elements are called ``outputs.''
together with
a. A function out: S x U -> Out which ``tells what a given user sees
when the machine is in a given state,'' called the output function.
b. A function do: S x U x C -> S which ``tells how states are updat-
ed by commands,'' called the state transition function.
c. A constant s0, the initial machine state, an element of S.
The connection with the standard form of the definition of state machine
is to take
U x C to be the set of inputs.
5.1.2.1.2 Capability Machine Component
In order to handle the dynamic case, in which what users are permitted
to do can
change with time, it is assumed that in addition to the state machine
features there are
also ``capability commands'' that can change the capability table. The
effects of
such commands can be described by the function
cdo: Capt x U x CC -> Capt
where Capt is the set of all possible capability tables, U is the set
of all users, and CC is
the set of capability commands. If a user u is not allowed to perform
the capability
command c on the table t, the cdo(t,u,c) may be just t again; as before,
this security
restriction is determined by consulting the capability table. The capability
machine
component is itself a state machine, with state set Capt and input set
U x CC; it models
the way in which the capability table is updated, and includes such possibilities
as
passing and creating capabilities.
5.1.2.1.3 Capability System
The entire capability system is a cascade connection of the capability
machine
component with the ordinary state machine component. In Figure 2, illustrating
the
cascade connection, the function Check returns the information from the
capability
table needed to determine whether or not a given command is authorized
for a given
user.
(Figure 2. Not available for electronic version.)
Figure 2. Cascade Connection of Capability System
In order to distinguish capability commands from state commands, the
definition of
a capability system denotes the set of all state commands by SC. So that
the state
transitions and the outputs can be checked for security against the capability
table, a
capability table component is added to the state transition function and
to the output
function. Adding all this to the definition of an ordinary state machine,
and also
adding an initial capability table, the result is a capability system
M consisting of the
following:
a) A set U whose elements are called ``users.''
b) A set S whose elements are called ``states.''
c) A set SC whose elements are called ``state commands.''
d) A set Out whose elements are called ``outputs.''
e) A set Capt whose elements are called ``capability tables.''
f) A set CC whose elements are called ``capability commands.''
together with
a A function out: S x Capt x U -> Out which ``tells what a given
user sees when the machine, including its capability component, is in
a given state,'' called the output function.
b) A function do: S x Capt x U x SC -> S which ``tells how states
are
updated by commands,'' called the state transition function.
c) A function cdo: Capt x U x CC -> Capt which ``tells how capabili-
ty tables are updated,'' called the capability transition function.
d) Constants t0 and s0, the ``initial capability table'' and the ``initial
machine state,'' respectively elements of Capt and of S.
5.1.2.2 Analysis of Goguen and Meseguer
Goguen and Meseguer's model is based on automata theory with all of the
state
transitions predefined. The predefined transitions address the first goal
of integrity
(preventing unauthorized users from making modifications). A significant
advantage
of having the model based on a standard notion like the automaton is that
extensive
literature and well-developed intuition become immediately applicable
to the problem
domain. The fact that the states and corresponding transitions are predefined
is both a
blessing and a curse. It is a great advantage to know exactly what the
system will do
at any particular instant. However, it will be very difficult to define
all of the states
and all of the transitions from one state to another. It will also be
difficult to design the
system in a flexible manner so that new states can be easily added to
the existing design.
Capabilities (as opposed to descriptors) provide the flexibility necessary
to
implement domain separation. But traditional capabilities cannot control
the
propagation, review, and revocation of access privileges [Gligor 1987].
It is unclear
whether traditional capabilities can be modified to realistically overcome
these
weaknesses.
5.1.3 SUTHERLAND MODEL
5.1.3.1 Discussion of Sutherland
Sutherland [1986] presents a model of information that addresses the
problem of
inference (e.g., covert channels). Sutherland uses a state machine as
the basis of his
model, but he generalizes the model, apparently to avoid limiting it to
the semantic
details of one particular type of state machine. Thus, his state machine
consists of the
following:
a) A set of states
b) A set of possible initial states
c) A state transformation function mapping states to states
For each possible initial state, there is an execution sequence defined
for each
sequence of possible state transformations starting from that initial
state. Sutherland
generalizes the state machine's set of execution sequences as a set W
of all such
execution sequences, which he terms ``possible worlds.'' A given execution
sequence
or ``possible world'' is denoted w, where wW. The ``possible world'' of
Sutherland's
model is actually even more abstract than we have represented here. As
illustrated in a
``state machine instantiation'' appearing later in [Sutherland 1986],
under one
interpretation of the model, an element w of the set W may consist not
only of states,
but of ``signals'' (analogous to the ``requests'' and ``decisions'' of
the Bell-LaPadula
model) interspersed between the states.
Sutherland formally represents the information obtainable from a subsequence
of w
by defining a set of information functions, fi. Each fi represents the
information that
can be obtained from one view of w. For example, assume a user has full
access to the
subsequence of w needed to compute f1(w). If this user knows of an
interdependence (covert channel) between f1 and another information function,
f2, to
which the user may have been prohibited access, the user can infer at
least some
information about f2(w) from the user's knowledge of f1(w). Sutherland
presents this
inference formally as follows.
1. The user knows f1(w)=x.
2. The user deduces w element_of S where S={y|f1(y)=x}.
3. The user deduces f2(w) element_of T where T=f2(S).
4. If there is an interdependence between f1 and f2 such that
there_exists z element_of f2(W)[z not_element_of T]
the user deduces
f2(w) =/= z.
Steps 1-3 above are straightforward generalizations from what the user
knows of
f1; the f2 in step 3 could be an arbitrary function, and calling it f2
in step 3 only antici-
pates step 4.
It is in step 4 that the user makes the significant inference. The inference
results
specifically from the user's knowledge that when the result of a particular
subsequence
of states is seen, it is impossible for the system to have produced the
result z. In such a
case, the user is able to conclude that the system has not produced a
particular result to
which the user may have been denied direct access. The extent to which
this
inference is useful depends on how much information is represented by
knowing that
result z was not produced. If the user knows that only two results are
possible, knowing
``not z'' would be of considerable value. Since the Sutherland model is
so general, it
does include this and similar inferences.
A concrete example of such an inference would be the observation ``when
program
1 produces result x, due to a flaw in the system, program 2 will be unable
to
compute result z.'' Or, ``while the weapons control system is under test,
the target
tracking system will not recognize a new target.'' Sutherland defines
the case in which
information flows from f1 to f2 as the case in which a user seeing f1(w)
is able to infer
that f2(w) =/= z.
Sutherland goes on to prove a theorem identifying cases in which inference
is
possible (specifically, cases in which f1 and f2 are dependent), and from
this theorem
derives an important corollary: that information flows are always symmetric.
This
corollary has importance to integrity since it shows that the user who
can control the
computation of f1 can influence the result of f2. This situation can be
thought of as
a reverse covert channel.
5.1.3.2 Analysis of Sutherland
Sutherland's corollary that information flows are always symmetric suggests
that
the model may have applicability to integrity. Sutherland speaks in terms
of an
observer noting that the value of one information function f1 influences
another
information function f2's set of possible values at a given point in time.
If a user can
influence the subsequence w which is the argument to f1, and if information
flows from
f1 to f2, the user can at least partially influence the value resulting
from f2. In terms of
our previous example, a user who is able to initiate a test of the weapons
control system
will be able to cause the target tracking system to malfunction, even
though testing may
have been thought to be a harmless operation. Thus, the Sutherland model
addresses
the first goal of integrity: preventing unauthorized users from making
modifications.
The type of integrity violation represented in the Sutherland model is
analogous to
a traditional covert channel. Whereas a covert channel communicates data
from within
a protection domain that should be inaccessible to an outsider, a violation
of the type
represented by the Sutherland model allows an outsider to influence the
outcome of
processing occurring within an otherwise inaccessible protection domain.
The Sutherland model differs from some other integrity models in that
it does not
emphasize a specific abstract protection mechanism. In the last section
of the model's
exposition [Sutherland 1986, p 177], Sutherland does define a legal_to_get
predicate
which represents abstract access control, and the formal definition of
security is given
as
information_flows(f2,f1)==>legal_to_get(f1,f2).
Since f1 can be an abstraction for a subject (i.e., the information ``known''
by the
subject or in the subject's memory), this predicate can represent access
restrictions
placed on a particular subject, as well as information flow restrictions
between
individual data repositories, such as files or ``objects''. But the Sutherland
model is
primarily involved with representing the goal of protection rather than
with a means
of enforcing it.
5.1.4 CLARK AND WILSON MODEL
5.1.4.1 Discussion of Clark and Wilson
Clark and Wilson [Clark 1987, 1989] make a distinction between military
security
and commercial integrity, and present a model for achieving data integrity.
They
defend two conclusions. First, security policies related to integrity,
rather than
disclosure, are of highest priority in the commercial data processing
environment.
Second, separate mechanisms are required for enforcement of these policies,
disjoint
from those in the TCSEC [DOD 1985]. This model has sparked the information
systems
and computer security communities to press forward with integrity-related
research.
There are two keys to the Clark and Wilson integrity policy: the well-formed
transaction and separation of duty. A well-formed transaction is structured
so that a user
cannot manipulate data arbitrarily, but only in constrained ways that
preserve or
ensure the internal consistency of the data. Separation of duty attempts
to ensure the
external consistency of data objects: the correspondence between a data
object and the
real world object it represents. This correspondence is ensured indirectly
by
separating all operations into several subparts and requiring that each
subpart be
executed by a different person.
The Clark and Wilson model is defined in terms of four elements: constrained
data
items (CDIs), unconstrained data items (UDIs), integrity verification
procedures (IVPs),
and transformation procedures (TPs). CDIs are data items within the system
to which
the integrity model must be applied. UDIs are data items not covered by
the integrity
policy that may be manipulated arbitrarily, subject only to discretionary
controls. New
information is fed into the system as a UDI, and may subsequently be transformed
into
a CDI. IVPs and TPs are two classes of procedures that implement the particular
integrity policy. The purpose of an IVP is to confirm that all of the
CDIs in the system
conform to the integrity specification at the time the IVP is executed.
An IVP checks
internal data consistency, and also may verify the consistency between
CDIs and
external reality. TPs correspond to the concept of well-formed transactions
discussed
above. The purpose of TPs is to change the set of CDIs from one valid
state to another.
There are nine certification (C) and enforcement (E) rules that govern
the
interaction of these model elements. Certification is done by the security
officer, system
owner, and system custodian with respect to an integrity policy; enforcement
is done
by the system. The rules are stated as follows:
C1: All IVPs must properly ensure that all CDIs are in a valid state
at the
time the IVP is run.
C2: All TPs must be certified to be valid. That is, they must take a
CDI
to a valid final state, given that it is in a valid state to begin with.
For
each TP, and each set of CDIs that it may manipulate, the security officer
must specify a relation, which defines that execution. A relation is thus
of the form: (TPi,(CDIa,CDIb, CDIc, ...)), where the list of CDIs defines
a
particular set of arguments for which the TP has been certified.
E1: The system must maintain the list of relations specified in rule
C2,
and must ensure that the only manipulation of any CDI is by a TP, where
the TP is operating on the CDI as specified in some relation.
E2: The system must maintain a list of relations of the form: (UserID,
TPi, (CDIa, CDIb, CDIc, ...)), which relates a user, a TP, and the data
ob-
jects that TP may reference on behalf of that user. It must ensure that
only executions described in one of the relations are performed.
C3: The list of relations in E2 must be certified to meet the separation
of
duty requirement.
E3: The system must authenticate the identity of each user attempting
to
execute a TP.
C4: All TPs must be certified to write to an append-only CDI (the log)
all information necessary to permit the nature of the operation to be
re-
constructed.
C5: Any TP that takes a UDI as an input value must be certified to per-
form only valid transformations, or else no transformations, for any possi-
ble value of the UDI. The transformation should take the input from a
UDI to a CDI, or the UDI is rejected.
E4: Only the agent permitted to certify entities may change the list
of
such entities associated with other entities: specifically, the entities
asso-
ciated with a TP. An agent that can certify an entity may not have
any execute rights with respect to that entity.
Together, these nine rules define a system that enforces a consistent
integrity policy.
The ultimate goal of the Clark and Wilson model is to stimulate the development
of
better security systems and tools in the commercial sector. The authors
suggest that
the first step toward this goal would be to develop a new set of criteria
that would
more clearly address integrity enforcement. Clark [1987] offers a first
cut at such a set
of criteria, and further refines the initial effort [Clark 1989].
5.1.4.2 Analysis of Clark and Wilson
The second goal of computer integrity was defined as maintaining the
internal and
external consistency of data. The Clark and Wilson model addresses this
goal through
the use of IVPs and TPs. The purpose of an IVP is to confirm that all
of the CDIs in the
system conform to the integrity specification at the time the IVP is executed.
An
example of an IVP is the accounting principle of an independent audit,
in which the
books are balanced and reconciled to the external environment. An IVP
verifies not
only internal consistency but also external consistency by periodically
cross-checking
internal data with the external reality that it represents.
TPs maintain internal consistency by taking the system from one valid
state to
another valid state. TPs are structured so that a user cannot manipulate
data
arbitrarily, but only in constrained ways that preserve or ensure the
internal
consistency of the data. In the accounting example, a TP would correspond
to a
double entry transaction. Double entry bookkeeping ensures internal data
consistency
by requiring that any modification of the books be composed of two parts,
which
account for or balance each other. For example, if a check is to be written
(which
implies an entry in the cash account), there must be a matching entry
on the accounts
payable account.
Separation of duty is another major part of the Clark and Wilson model
that
addresses the third goal of computer integrity: preventing authorized
users from
making improper modifications. This goal is achieved indirectly by separating
all
operations into several subparts and requiring that each subpart be executed
by a
different person. For example, the process of purchasing and paying for
some item
might involve subparts: authorizing the purchase order, recording the
arrival of the
item, recording the arrival of the invoice, and authorizing payment. The
last step
should not be executed unless the previous three are properly done. If
each step is
performed by a different person, improper modifications should be detected
and
reported unless some of these people conspire. If one person can execute
all of these
steps, then a simple form of fraud is possible in which an order is placed
and payment
made to a fictitious company without any actual delivery of items. In
this case, the
books appear to balance; the error is in the correspondence between real
and recorded
inventory.
The separation of duty method is effective except in the case of collusion
among
employees. While this vulnerability might seem risky, the method has proved
very
effective in practical control of fraud. Separation of duty can be made
very powerful by
thoughtful application of the technique, such as random selection of the
sets of people
to perform some operation, so that any proposed collusion is only safe
by chance.
One of the nine rules defining this policy, rule E2, points out the major
difference
between the Clark and Wilson model and the Bell and LaPadula model. Whereas
the
lattice model of Bell and LaPadula defines access restrictions for subjects
to objects, the
Clark and Wilson model (like the Lipner implementation) partitions objects
into
programs and data, and rule E2 requires subject/program/data access triples.
Access
triples are used to address the first integrity goal and also to implement
the
separation of duties concept.
An access triple (or triple) is a relation of the form: (UserID, TPi,
(CDIa, CDIb, CDIc,
...)). The system maintains a list of triples to control which persons
can execute which
programs on specified CDIs. Chen [1989] suggests that it is possible to
combine a
``user-to-program'' binding (which is already required in [DOD 1985])
with a ``pro-
gram-to-data'' binding to enforce the triple. According to Chen [1989],
several systems
are capable of accommodating these bindings. In addition to the type manager/
pipeline approach taken by Boebert [1985] and the category approaches
suggested by
Shockley [1988] and Lee [1988], the Resource Access Control Facility (RACF)
and the
Access Control Facility 2 (ACF2) also appear capable of supporting user/program
and
program/data bindings.
Initial examination of Chen's implementation of access triples indicates
that it would
fail. Consider a system with two users (S1, S2), two transformation procedures
(TP1,
TP2), and three constrained data items (CDI1, CDI2, CDI3). The system
security officer
decides that the following triples should be enforced: (S1,TP1,CDI1),
(S1,TP2,CDI2),
(S2,TP1,CDI2), (S2,TP2,CDI3). The following bindings would be required
in order to
implement these triples using the approach suggested in [Chen 1989]: (S1,TP1),
(S1,TP2), (S2,TP1), (S2,TP2), (TP1,CDI1), (TP1,CDI2), (TP2,CDI2), (TP2,CDI3).
The
(S1,TP1) binding required to satisfy the first triple combined with the
(TP1,CDI2)
binding required to satisfy the third triple results in user S1 having
access to data item
CDI2 through program TP1; this extra triple, (S1,TP1,CDI2), is a violation
of system
integrity.
There is evidence to suggest that implementing triples directly on an
actual system
may be prohibitively expensive in terms of performance [Karger 1988],
or that
requiring triples may reduce design and implementation flexibility at
the operating
system level [Chen 1989]. At the same time, triples do provide a means
for limiting the
risk of authorized users making improper modifications. In fact, the Clark
and
Wilson model effectively addresses all three goals of computer system
integrity; the
question is whether this model can be implemented realistically.
5.1.5 BREWER AND NASH MODEL
5.1.5.1 Discussion of Brewer and Nash
The Brewer and Nash model [Brewer 1989] presents a basic mathematical
theory
which is used to implement dynamically changing access permissions. The
model is
described in terms of a particular commercial security policy, known as
the Chinese
Wall. The model is developed by first defining what is meant by a Chinese
Wall, and
then by devising a set of rules such that no person (subject) can ever
access data
(objects) on the wrong side of that wall. The Chinese Wall security policy
can be
most easily visualized as the code of practice that must be followed by
a market
analyst who is providing corporate business services. Such an analyst
cannot advise
corporations where he has ``insider knowledge'' about a competitor, but
the analyst is
free to advise corporations which are not in competition with each other,
and also to
draw on general market information.
The following basic elements are used to mathematically define the Brewer
and Nash
model:
S: the set of subjects s; the users, or any program that might act on
their be-
half;
O: the set of objects o; files in which items of information are stored;
X(o), Y(o):functions which determine respectively the x and y components
of the security label for a given object o;
xj, yj: X(oj) and Y(oj) respectively;
N: a boolean matrix with elements N(v,c) corresponding to the members
of SxO; the elements N(v,c) take the value true if subject sv has, or
has
had, access to object oc or the value false if sv has not had access to
object
oc;
In the Brewer and Nash model, all corporate information is stored in
a
hierarchically arranged filing system where there are three levels of
significance:
a At the lowest level, individual items of information, each concerning
a
single corporation, are called objects.
b) At the intermediate level, all objects which concern the same corporation
are grouped together into a company dataset.
c) At the highest level, all company datasets whose corporations are
in com-
petition are grouped together into a conflict of interest class.
Associated with each object oj is the name of the company dataset yj
to which it
belongs and the name of the conflict of interest class xj to which that
company dataset
belongs.
The basis of the Chinese Wall policy is that people are only allowed
access to
information which is not held to conflict with any other information that
they have
accessed previously. In this approach, a subject is initially given complete
freedom to
access any object he cares to choose. For example, if there were three
conflict of
interest classes with the following member datasets (a, b, c) (d, e, f)
and (g, h, i), a
subject would initially be allowed access to all datasets a through i.
If the subject
then accessed an object in dataset e, the subject subsequently would be
denied access to
datasets d and f, while still having access to datasets a through c and
g through i. If the
subject next accessed an object in dataset a, the subject would be denied
access to
datasets b and c as well as d and f, leaving datasets a, e, g, h, and
i accessible.
Two rules, the simple security rule and the *-property, are devised so
that no subject
can access objects on the wrong side of the Wall. The simple security
rule formally
defines that read access to any object or by any subject su is granted
if and only if for all
N(u,c) = true (i.e., su has had access to oc):
((yc = yr) or (xc <> xr))
In other words, read access is only granted if or is in the same company
dataset y as
an object already accessed by that subject (i.e., within the Wall) or
if or belongs to an
entirely different conflict of interest class x. Once a subject has read
an object, the only
other objects readable by that subject lie within the same company dataset
or within
a different conflict of interest class. At most, a subject can have read
access to one
company dataset in each conflict of interest class.
The *-property is based on the concept of sanitized information defined
by the
authors. Sanitization takes the form of disguising a corporation's information,
in
particular, to prevent the discovery of that corporation's identity. If
sanitization can be
accomplished to prevent backward inference of origin, the sanitized information
can
be generally compared with similarly sanitized information relating to
other
corporations. Formally, for any object os, ys = yo implies that os contains
sanitized
information, and ys <> yo implies that os contains unsanitized information.
Thus, the *-property formally defines that write access to any object
ob by any subject
su is permitted if and only if N'(u,b) = true and there does not exist
any object oa
(N'(u,a) = true) which can be read by su for which:
ya <> yb and ya <> yo
In other words, write access is only permitted if access is permitted
by the simple
security rule, and if no object can be read which is in a different company
dataset to the
one for which write access is requested and contains unsanitized information.
Thus, the
flow of unsanitized information is confined to its own company dataset;
sanitized
information may however flow freely throughout the system.
5.1.5.2 Analysis of Brewer and Nash
This Brewer and Nash model was introduced in the context of commercial
confidentiality requirements. We believe that a reinterpretation of this
policy to address
integrity issues would be both productive and straightforward. This model
could be
used in cases in which being able to access and make changes to two objects
would
allow a subject to manipulate the information in these two objects to
fraudulent ends.
For example, suppose a consultant works for two competing companies,
Ace and
Acme, which both store information on their designs in a centralized DoD
database. If
the consultant has knowledge of both company's products, the consultant
could subtly
modify the design for Ace's product such that it had poor electromagnetic
compatibility
with Acme's product. Even though it worked at other times, Ace's product
would fail
in unexplained ways when used in the integrated weapons system in which
Acme's
product also was used. Ace's product would function correctly during testing,
but
would be perceived to be faulty in comparison to Acme's product when actually
put
into use.
There would be no evidence that this failure had been the result of an
integrity
violation in the design database; it would likely be perceived that Ace
simply had done
an inadequate job in the design of their product, or just that their product
tended to fail
a lot in the field. This type of conflict of interest problem was the
origin of the Chinese
Wall policy, although the original application was in the financial community.
The
Chinese Wall policy would prevent the consultant from accessing both companies'
information. Thus, it addresses the third goal of integrity - preventing
authorized users
from making improper modifications.
The Chinese Wall policy was presented by Brewer et al. [1989] at the
1989 IEEE
Symposium on Security and Privacy as an example of a policy which it was
felt could
not be addressed by the TCSEC requirements. As such, it is productive
to identify
whether proposed TCSEC revisions add the functionality needed to implement
this
policy. As was pointed out by John McLean in discussion following Brewer's
presentation, the policy can in fact be implemented using categories if
the user's
allowed category set is permitted to change dynamically, and if this ability
is used to
vary the category set as a result of user accesses in accordance with
the Chinese Wall
policy.
Thus, it appears that categories or a comparable access partitioning
mechanism are
sufficient to implement the Chinese Wall, if a mechanism is also provided
to change
the user's allowed category set in response to user accesses. This feature
is not
necessarily provided by existing TCSEC implementations, since the TCSEC
neither
requires nor precludes support for dynamically changing category sets.
Security
policies which prohibit changes in mandatory access permissions for active
processes as
a result of a Tranquillity Principle that requires subjects to be inactive
in order for their
security labels to change, will not be able to support the Chinese Wall.
5.1.6 SUMMARY OF MODELS
Five models have been developed which suggest fundamentally different
ways of
achieving computer integrity. Biba [1977] was the first model to address
integrity in a
computer system, and it has the most established base of research because
it is based
on the Bell and LaPadula model for confidentiality. This model emphasizes
the use of
hierarchical levels. There are still no criteria for determining integrity
levels and
categories, so the Biba model does not seem to be the best approach for
integrity.
Goguen [1982] notes the advantages of domain separation and automaton-based
state
transformations. Capabilities would seem to be the most effective mechanism
for
implementing this model; the question is whether capability systems can
be modified
to control propagation, review, and revocation of access privileges. Sutherland
[1986]
addresses the effect of covert channels on integrity. The Sutherland model
is primarily
involved with representing the goal of protection rather than with a means
of
enforcing it. Clark and Wilson [1987] introduce the concept of access
control triples that
can be used to effectively implement separation of duties. This model
was designed to
meet commercial data integrity needs, but it can also be used in meeting
integrity needs
of secure military systems. Brewer [1989] presents a mathematical theory
that
implements dynamically changing access permissions.
Each of the models described in this chapter addresses one or more of
the integrity
goals defined at the beginning of the paper. All of the approaches address
the first and
most basic goal of computer system integrity. The second goal is addressed
by the
Clark and Wilson model, and the third goal is addressed by the Clark and
Wilson
and the Brewer and Nash models.
5.2 5.2 INTEGRITY MODEL IMPLEMENTATIONS
In this paper, implementations suggest realistic approaches to the theoretical
basics identified in different models. While models describe what types
of mechanisms
are necessary to satisfy an integrity policy, implementations describe
how specific
mechanisms can be used together in a system to achieve integrity protection
required by a particular security policy. Six methods have been identified
as proposed
implementations of one or more of the fundamental models described in
the
previous appendix: Lipner, Boebert and Kain, Lee and Shockley, Karger,
Jueneman,
and Gong. Lee and Shockley are two independently developed studies that
are
counted as one as they take essentially the same approach. The Boebert
and Kain
implementation is the only one we have been made aware of that is being
actively
pursued as a worked example.
5.2.1 LIPNER IMPLEMENTATION
5.2.1.1 Discussion of Lipner
Lipner [1982] examines two ways of implementing integrity in commercial
data
processing systems. The first method uses the Bell and LaPadula security
lattice model
by itself. The second method combines the Bell and LaPadula model with
Biba's
integrity lattice model.
Lipner's approach requires looking at security requirements in a different
way from
the prevalent view taken in the national security community. In particular,
non-hierar-
chical categories are considered more useful than hierarchical levels.
While a company
will typically have organizational divisions (that correspond to categories),
there will
almost never be a notion of individuals having a clearance (that corresponds
to a
security level). Almost all employees work at the same level; they just
do different
things within that level. The key is to appropriately define a set of
access classes, user
types, and file types.
In Lipner's use of the Bell and LaPadula model, each subject and each
object is
assigned an access class. An access class is composed of one hierarchical
classification
level (e.g., Top Secret, Secret, Confidential, Unclassified) and one or
more non-
hierarchical, descriptive categories (e.g., NATO, Intelligence). In forming
a lattice
implementation to meet integrity requirements, the initial step is to
define a set of
access classes appropriate to achieve the desired restrictions.
In Lipner's first method, two levels distinguish between system managers
and
all other users, and four categories describe the types of work that are
performed.
Several user types and file types are assigned different levels and categories
to
implement integrity. Since almost all subjects and objects are assigned
the ``System-
Low'' level, categories are the most important part of the access class.
By appropriately
defining and assigning the categories, programmers, users, and system
programmers are each limited to their own sphere of activity.
In the second method, Biba's integrity model is added to the basic (security)
lattice
implementation. The second method, like the first, assigns levels and
categories to
subjects and to objects. Its objective, however, is to prevent the contamination
of high-
integrity information by the infusion of lower-integrity data and by processing
with
lower-integrity programs. Integrity levels are provided to prevent the
modification of
system programs; integrity categories are used to separate different environments
(e.g., development and production). This approach is used to simplify
and render
more intuitive a lattice policy application. It also limits the possibility
of introducing
a ``Trojan horse.''
5.2.1.2 Analysis of Lipner
Lipner's implementation of the Bell and LaPadula and Biba models is the
first work
to suggest that non-hierarchical categories are more important for integrity
than
hierarchical levels. Categories are used to address the first goal of
integrity. Lipner
took a survey of AIS auditors and AIS security officers to find that,
in general,
commercial users do not write their own programs and commercial program
developers
do not use the programs they write. Thus, users should not be ``above''
programmers,
and programmers should not be ``above'' users; both types of users are
at the same
``level,'' but should be completely separated from one another. Therefore,
the
appropriate use of categories is more important than the use of levels.
Lipner also appears to be the first person to separate objects into data
and programs.
This distinction is important because it is the first step toward addressing
the third
integrity goal (Clark and Wilson [1987] expand on this concept). Programs
can be either
passive (when they are being developed or edited) or active (when they
are being
invoked on behalf of a particular user), while data items are always passive.
Programs
are the means by which a user can manipulate data; thus, it is necessary
to control
which programs a user can execute and which data objects a program can
manipulate.
Lipner's emphasis on categories and his separation of programs and data
are
positive steps forward. However, this approach has several drawbacks:
a Controls are at the level of user types and file types as opposed to
being
at the granularity of individual users and files; this is also a disadvan-
tage of the Bell and LaPadula and Biba models. This drawback means
that the granularity of control is inadequate to enforce access control
triples.
b) Lipner recognizes that data should be manipulated only by certified
(pro-
duction) programs, but his controls do not provide a way to control what
data a particular program can manipulate; there is no program-to-data
binding explicitly called for.
c) Lipner's first method results in an ``all-powerful'' system manager
who
could conceivably manipulate the system at will. An all-powerful mem-
ber of a computer system is always a risk because the least-privilege
principle is not enforced in such a situation.
d) Lipner's second method is complex and will be difficult to administer.
The last item requires some explanation. Assume we have a system with
two
confidentiality levels (HiConf, LoConf) and two integrity levels (HiInteg,
LoInteg);
assume that proper category assignments exist for the sake of simplifying
this
explanation. The following combinations are possible:
a User1: HiConf, HiInteg
b) User2: HiConf, LoInteg
c) User3: LoConf, HiInteg
d) User4: LoConf, LoInteg
The Bell and LaPadula and Biba models use the operating system-oriented
concepts of
read and write. These can also be generalized to communications-oriented
concepts of
receive and send respectively. Bell and LaPadula requires that there be
``no read up''
and ``no write down'' in confidentiality level; Biba requires that there
be ``no write up''
and ``no read down'' in integrity level. Thus, User1 may read (LoConf,
HiInteg) and
(HiConf, HiInteg) objects and write (HiConf, LoInteg) and (HiConf, HiInteg)
objects.
User2 may read any object and write only (HiConf, LoInteg) objects. User3
may
read-only (LoConf, HiInteg) objects and may write any object. User4 may
read (LoConf,
LoInteg) and (LoConf, HiInteg) objects and write (LoConf, LoInteg) and
(HiConf,
LoInteg) objects.
Notice that User1 would be allowed to read any object if there were no
integrity
levels, but that the HiInteg level prevents him from reading half of the
object types.
Similarly, User 4 would be allowed to read any object if there were no
confidentiality
levels, but the LoConf level prevents him from reading half of the object
types. The
point is that confidentiality and integrity levels have an effect on one
another;
understanding this interaction and appropriately assigning levels to both
users and
objects is complex and will be difficult to administer.
5.2.2 BOEBERT AND KAIN IMPLEMENTATION
5.2.2.1 Discussion of Boebert and Kain
Boebert and Kain [Boebert 1985, Boebert 1988] introduce an implementation
of the
Goguen and Meseguer model using the concept of assured pipelines in the
LOCK
(LOgical Coprocessor Kernel) machine-formerly known as the Secure Ada
Target
(SAT). Assured pipelines provide a mechanism for ensuring that data of
particular
types can only be handled by specific trusted software. An assured pipeline
is a
subsystem that satisfies three properties: 1) it cannot be bypassed, 2)
its actions cannot
be undone, and 3) its actions must be correct.
The LOCK reference monitor system, SIDEARM, checks every individual access
attempt for consistency with the security policy being enforced. The reference
monitor is implemented in hardware, and resides between the processor,
which
generates memory access requests, and the memory system, which satisfies
these
requests. The LOCK reference monitor is actually a combination of a memory
management unit (MMU), which has conventional rights checking facilities
(read, write,
etc.), and a tagged object processor (TOP), a new module responsible for
the system's
protection state. In particular, the TOP sets up the tables that define
the access rights
checked by the MMU. The link between the two of them is the MMU tables
and the
highly privileged code that sets the tables based on outputs from the
SIDEARM
[Boebert 1990].
Security attributes are associated with both subjects and objects, and
the TOP must
make appropriate comparisons between these security attributes to establish
proper
access rights in the MMU. Three security attributes are associated with
subjects and
three attributes are associated with objects. First, both subjects and
objects have
security (confidentiality) levels. Each subject performs its function
for some ``user,''
whose identity is the second subject security attribute. The corresponding
object's
second security attribute is its access control list (ACL), which lists
those users who are
allowed access to the object's contents, along with the maximum access
rights that each
designated user is permitted. The third subject security attribute is
the ``domain'' of its
execution, which is an encoding of the subsystem of which the program
is currently a
part. The corresponding object's third security attribute is the ``type''
of the object,
which is an encoding of the format of the information contained within
the object.
The process of determining the access rights to be accorded a particular
subject for
access to a particular object uses all three security attributes. To enforce
the
mandatory access policy, the TOP first compares security levels of the
subject and of
the object, and computes an initial set of access rights according to
the algorithm
defined in Section 4.1.1.4 of the TCSEC.
To enforce the discretionary access policy, the TOP then checks the ACL
for the
object; the ACL entry that matches the user portion of the subject's context
is
compared against the initial set of access rights from the mandatory policy
computation.
Any access right in the initial set which does not appear in the ACL is
deleted from
the initial set. The result of this second determination check is an intermediate
set of
access rights.
The third LOCK access rights determination check compares the subject's
domain
against the object's type. Each domain is itself an object, and one of
its attributes is a
list of the object types accessible from the domain and the maximum access
rights
permitted from the domain to each type. Conceptually, the aggregation
of these
domain definition lists constitutes a table, which is called the Domain
Definition Table
(DDT). To make the domain-type check, the TOP consults the DDT row for
the
executing domain, finds the column for the object's type, and compares
the resultant
entry against the intermediate set of access rights. Any right in the
intermediate set
which does not appear in the DDT entry is dropped, and the result is the
final set of
access rights, which is transmitted to the MMU.
Domain changing may occur as a side effect of a procedure call. If the
called
procedure is not executable within the caller's domain, either the call
is illegal or a
domain change is necessary to complete the call. Information concerning
domain
changes is stored in a Domain Transition Table (DTT), which is stored
as a set of lists
associated with the calling domain. The LOCK system creates new subjects
to handle
domain changes, as required. When a call requires a domain change, LOCK
suspends
the calling subject and activates the called subject. The called subject
has a different
execution context, name space, and access rights, all of which will prevail
for the
duration of the procedure's execution.
5.2.2.2 Analysis of Boebert and Kain
Boebert and Kain's implementation is an object-oriented approach that
addresses the
first goal of integrity by focusing more on isolating the action than
isolating the user.
In other words, domains restrict actions to being performed in only one
place in only
one way; if you don't have access to that domain, you can't perform that
action. This
approach should help in preventing users from gaining unauthorized access
through
non-obvious paths.
This implementation is based on the Goguen and Meseguer model. The possible
states are defined by the DDTs, and the state transitions are defined
by the DTTs. Thus,
integrity is achieved by carefully controlling these tables; this appears
to be an
achievable goal, although storage and management of the large number of
tables may
be complex. The Boebert and Kain approach is the only model
``implementation'' that is actually being implemented on a real system
(LOCK). Their
reported experience to date has shown that least privilege can be achieved
without
affecting system speed. The LOCK team is currently developing tools to
aid in DDT
construction and assurance [Boebert 1990].
Boebert and Kain's implementation provides a great deal of flexibility.
In order to
perform a certain action (e.g., modify an account balance), the user must
have access to
the appropriate domain. The domain may then further restrict what specific
programs
and data files the user can access (e.g., record a deposit for any account
other than
the user's, and only delete from the user's account). However, this flexibility
may make
the system more difficult to manage; some of the features may have to
be restricted
to ensure that unintentional errors are not made which jeopardize integrity
(e.g., the
user may be added to another account group that allows him to record deposits
to his
own account).
5.2.3 LEE AND SHOCKLEY IMPLEMENTATIONS
5.2.3.1 Discussion of Lee and Shockley
Independently, Lee [1988] and Shockley [1988] developed implementations
of the
Clark and Wilson model using Biba integrity categories and (partially)
trusted
subjects. Both implementations are based on a set of sensitivity labels.
This set is built
from two essentially independent components: every label represents a
sensitivity
with respect to disclosure, and an independent component representing
a sensitivity
with respect to modification. The labels corresponding to disclosure restrictions
are
not discussed; here, only the integrity labels are discussed in detail.
Using Lee's notation, a trusted subject, S, has two integrity labels,
view-minimum
and alter-maximum, denoted v-min(S) and a-max(S). Every object has one
integrity
label, label(O). An integrity label is simply a set of integrity categories;
the notion of a
hierarchical integrity level is not useful in this context. An integrity
category can be
interpreted as the name of a particular type of protected data. A subject,
S, may write
into an object, O, only if label(O) is a subset of a-max(S); S may read
O only if either v-
min(S) or a-max(S) is a subset of label(O). Any subject S with v-min(S)
= a-max(S) is an
untrusted subject.
Data is manipulated by ``certified transactions'' (TP in Clark and Wilson),
which are
partially trusted subjects. A partially trusted subject is allowed to
transform data from
a limited set of input types to a limited set of output types: it can
read data that is
marked with at least one of the categories specified in the subject's
view-minimum label
and still be allowed to write into data containers with any or all of
the types in its alter-
maximum label.
5.2.3.2 Analysis of Lee and Shockley
In addition to the two integrity labels, v-min(S) and a-max(S), every
subject, S, also
has two disclosure labels, v-max(S) and a-min(S). Each object has a disclosure
label
and an integrity label, which are made up of one or more disclosure and
integrity
categories respectively. Two requirements must be met for a subject to
write to an
object. First, the object's disclosure label must dominate a-min(S)-no
write down with
respect to disclosure. Second, a-max(S) must dominate the object's integrity
label-no
write up in integrity. The subject similarly may not read up in disclosure-v-max(S)
must dominate the object's disclosure label-or read down in integrity-the
object's
integrity label must dominate v-min(S). These views address the first
integrity goal.
The views provide subject-to-program, subject-to-object, and program-to-
object bindings, which is sufficient to control which program a subject
can invoke to
manipulate a particular object. However, views in general bind only classes-or
types-
of subjects, programs, and objects, whereas the primary access control
mechanism of
the Clark and Wilson model (triples) binds individual users, programs,
and objects.
(footnote #2) Thus, while Lee and Shockley demonstrate a transformation
of the Clark
and Wilson model to a lattice-based implementation, the actual operation
of the such
an implementation would likely prove to be cumbersome. Shockley also states
that
additions need to be designed and coded for building and checking tables
of user/
program/data triples.
[1] It should be noted that the Shockley implementation does provide
features for
control based on individual, identified programs.
The major difficulty with the Lee and Shockley implementations seems
to be
management of large numbers of categories identified by Karger [1988].
Shockley
notes that the Gemini Secure Operating System (GEMSOS) TCB has 90 bits
available to
represent access restrictions. The interpretation of these bits is confined
to a single
internal module that is easily modified. Although GEMSOS can encode a
large number
of categories (data types), managing these categories (storing all of
the different
combinations and performing the dominance checks) was not discussed and
would
seem to be a potential bottleneck.
The Lee and Shockley implementations do make three important contributions.
First, categories can be interpreted as data types; thus, strong typing
is important for
implementing integrity. Second, a transaction-oriented approach seems
best; thus,
database technology should be very relevant. Finally, non-hierarchical
categories
alone are sufficient to implement the desired non-discretionary component
of a Clark/
Wilson policy; thus, Biba's hierarchical levels are unnecessary. In this
case, an
important question to ask is, will Bell and LaPadula's hierarchical lattice
fit with this
non-hierarchical category approach? It is our conclusion that it will-the
hierarchical
disclosure part should be able to be added to the non-hierarchical categories
as an
additional restriction on access. In other words, assuming all of the
sensitivity label
requirements were satisfied, a hierarchical disclosure level would just
be one more
restriction on accessing an object.
5.2.4 KARGER IMPLEMENTATION
5.2.4.1 Discussion of Karger
Karger [1988] proposes an implementation of the Clark and Wilson model
which
combines SCAP, his secure capability architecture [Karger 1984], with
the lattice
security model. In this scheme, a capability-based protection kernel supports
ACLs
(representing the security lattice) at the outer level. In a typical capability
system, the
processor automatically loads capabilities into a cache for quick reference.
Karger's
proposal is to cause a fault or trap to the most privileged software domain
(i.e., the
security kernel) so that this privileged domain can evaluate whether the
lattice model
permits the capability to be used. Once a capability has been evaluated,
it is placed in
the cache so that it does not have to be reevaluated. If a lattice entry
is changed,
revocation can be achieved by flushing all of the capabilities for that
object from the
cache (causing new requests for the object to be freshly evaluated).
Karger suggests building CDIs out of abstract data types, with TPs as
the
operations of the type manager. Sealed (encrypted) SCAP capabilities can
be used to
implement abstract type management. As described above, SCAP can also
intercept
attempts to exercise capabilities by the TPs and require that special
access control list
checks be made to enforce separation of duty. Such an access control list
for a TP would
contain the Clark and Wilson triples.
As part of this implementation, audit trails form a much more active
part of
security enforcement than in previous systems. Karger introduces ``token
capabilities''
to make the use of audit information easier. While taking the form of
capabilities to
prevent unauthorized tampering, token capabilities are in fact separate
copies of
individual audit records. They include both the name of the transaction
and the name
of the user who executed the transaction. The user's name must be recorded
so that one
can ensure that TP1 and TP2 are executed by different people. The name
of the TP is
recorded to prevent the token capability from being used more than once.
Once used,
the token capability is marked to prevent further use.
Token capabilities are used in conjunction with access control lists
to ensure that
permission to execute certain transactions or to modify certain CDIs can
only be
granted if certain previous transactions have been executed by specific
individuals.
Attempts to exercise regular capabilities cause an object's audit records
(token
capabilities) to be examined and compared with the appropriate ACL entry.
If the
request is determined to be legal, the regular capability is accepted
and the desired
action can be performed. Token capabilities simply provide a mechanism
for making
the proper audit records available for integrity policy decisions on a
timely basis.
Entries in a separation of duty ACL are more complex than the simple
ACLs
supported in previous systems. Each entry consists of a boolean expression
in which
the first term is the name of the user who proposes to execute the action,
and the
other terms are token capabilities for required predecessor transactions.
The boolean
expression identifies the name and order of the preceding transactions
that must be
executed. As a final note, the author states that mechanism complexity
and system
performance will be problems regardless of the protection strategy that
is adopted.
5.2.4.2 Analysis of Karger
By combining capabilities and access control lists, Karger greatly increases
the
implementation flexibility for achieving integrity. Karger requires that
the ACLs
contain the Clark and Wilson triples. This requirement by itself provides
enough
functionality for a system designer to implement static separation of
duties
(addressing both the first and third goals of integrity). Karger does
not say how he
would implement the triples or whether current systems would be sufficient;
this is an
important issue that must be addressed in future work.
The other part of Karger's implementation is the use of capabilities
in support of the
ACLs. Capabilities are used to provide domain separation so that actions
are limited to
particular domains, and also for quicker access. When a new capability
is presented for
invoking a certain program on a particular object, a trap to the security
kernel is made
to check the appropriate ACL entry. If the request is legal, the capability
is stored in a
cache to make subsequent accesses much faster.
Karger's complex ACLs not only contain triples, but they also specify
the order in
which transactions must be executed. These enhanced ACLs are used along
with
audit-based token capabilities to enforce dynamic separation of duties.
Token
capabilities can also be used to enforce well-formed transactions. The
history of
actions contained in these capabilities can be used to implement two-phase
commit
protocols. The two-phase commit protocol requires log records of all actions
to ensure
that any transaction either completely succeeds or does not occur at all.
These log
records are exactly the same records needed for making security policy
decisions.
Notice that this implementation allows three levels of protection. First,
triples
implemented in the ACLs allow for basic integrity (static separation of
duties).
Second, capabilities can be used to support these ACLs to provide faster
access and
domain separation. Finally, enhanced ACLs and token capabilities support
both
dynamic separation of duties and well-formed transactions.
The additional flexibility provided by this implementation also creates
some
problems. Enhanced ACLs are much more complex than the ACLs implemented
on
current systems; thus, they may be more difficult to develop and to maintain.
Token
capabilities will add overhead that may become overly burdensome on system
performance. Also, adding new applications may have a significant effect
on existing
separation of duty ACLs. Most importantly, future research needs to develop
an
efficient way of implementing access control triples.
5.2.5 JUENEMAN IMPLEMENTATION
5.2.5.1 Discussion of Jueneman
Jueneman [1989] proposes a defensive detection scheme that is based on
mandatory
and discretionary integrity controls, encryption, checksums, and digital
signatures.
This approach is intended for use on dynamic networks of interconnected
Trusted
Computing Bases (TCBs) that communicate over arbitrary non-secure media.
Mandatory Integrity Controls prevent illegal modifications within the
TCB, and
detect modifications outside the TCB. Discretionary Integrity Controls
are useful in
supplementing the mandatory controls to prevent the modification, destruction,
or
renaming of an object by a user who has the necessary mandatory permissions,
but is
not authorized by the owner of the object. Encryption is used by the originator
of an
object to protect the secrecy or privacy of information. Checksums provide
immutability and signatures provide attribution to allow the recipient
of an object to
determine its believability. The originator of an object should be responsible
for
assuring its confidentiality. The recipient should be responsible for
determining its
integrity.
It is assumed that the TCBs provide the equivalent of at least a B2 level
of trust in
accordance with the TCSEC. The B2 level provides mandatory and discretionary
access controls and labels, process isolation achieved through the provision
of distinct
memory spaces under the control of the TCB, and the use of memory segmentation
and
read/write protection. In addition, in order to support the concept of
separation of
duty, the ability to exclude individuals or groups of individuals from
accessing
specified objects is assumed-a B3/A1 feature. Embedded cryptographic functionality
is
also assumed.
This implementation enforces mandatory and discretionary integrity controls
across
a computer network through the use of integrity labels. Two concepts are
basic to an
integrity label: integrity domain and integrity marking. Jueneman defines
an integrity
domain as the set of allowable inputs to a program (process) together
with syntactic
and semantic rules used to validate or reject those inputs and optionally
produce one or
more outputs. This use of the term ``domain'' is different from the definition
used in
both the TCSEC and the Boebert and Kain implementation, i.e., the set
of objects that
a subject has the ability to access.
An integrity marking has both hierarchical and non-hierarchical components.
A
hierarchical integrity level is an estimated probability that the process
which created an
object did so in accordance with the rules of a particular integrity domain
or domains.
Combining two or more integrity domains, the probabilities are assumed
to be
independent and are multiplied together to get an overall level (probability).
A non-
hierarchical integrity category qualifies the hierarchical integrity level;
it is a
shorthand representation of identifying the rules of the integrity domain
that applied
to that subject or object.
Integrity labels are incorporated as header and trailer labels within
encrypted subject
information or encrypted objects themselves. Subjects, data files, and
programs each
have different integrity labels. The particular elements included in these
label types
are discussed below.
5.2.5.1.1 Subject Integrity Label
A subject's integrity label contains a readclass, a writeclass, and a
digital signature.
A readclass is the range from the minimum integrity-read-limit to the
maximum
security-read-limit; a writeclass is the range from the minimum security-write-limit
to
the maximum integrity-write-limit. The read and write limits are made
up of integrity
markings.
A digital signature is a means by which a particular user or TCB digitally
``signs''
for the validity of objects it modifies. It provides non-repudiation protection
of both the
authorship of an object and the object's contents. Once a user has modified
an object, he
can digitally sign the object to unambiguously indicate his willing and
conscious
approval of the results. A receiver may require the originator's digital
signature before
an object will be processed.
5.2.5.1.2 Data File Integrity Label
The integrity label for a data file contains an integrity marking, a
cryptographic
checksum of the entire contents of the file, the name and cryptonym (digital
signature) of the originator, and a bottom-up system of digitally signed
certificates. A
checksum is a separable code that is added to a block of data to help
detect errors
[Johnson 1989].
When original data is created, an extra piece of information, called
the checksum, is
appended to the block of data. The checksum is then regenerated when the
data is
received at its destination; the regenerated checksum and the original
checksum are
compared to determine if an error has occurred in the data, the checksum
generation,
the checksum regeneration, or the checksum comparison. Once a checksum
has been
computed, the original data and the check-sum are encrypted to produce
a
cryptographic checksum.
The digitally signed certificates are actually individual audit records.
Each audit
record has a ``pedigree'' part and a (optional) ``provenance'' part. The
pedigree
records which users ran what processes against what data inputs in order
to produce
given output(s); it is digitally signed by a TCB to show the TCB's approval.
The
provenance contains ancillary information (documentation, specifications,
test cases
and results, etc.); it is digitally signed by a user to show the user's
intent.
5.2.5.1.3 Program Integrity Label
A program's integrity label contains all of the elements listed for a
data file, and
also includes the program's integrity domain.
5.2.5.2 Analysis of Jueneman
Jueneman makes a very good point when he says that ``it is almost impossible
to
discover or stop all [illegal actions] by [malicious] programs'' (e.g.,
virus, Trojan
horse, unintentional errors in any systems or applications program). Therefore,
his
approach is to use a defensive containment mechanism that can at least
detect any
change to a subject or object, and that cannot itself be subverted, in
order to prevent such
programs from affecting the rest of the system. This approach itself seems
to be a very
appropriate type of design philosophy for integrity: detection instead
of prevention.
Jueneman chooses to implement this design philosophy with some mechanisms
that appear impractical, and some mechanisms that appear quite effective.
His use of
hierarchical probabilities and qualifying, non-hierarchical rules (categories)
for
achieving TCB integrity is complex and would be difficult to implement.
It would be
difficult to assign a consistent numerical value as to whether certain
rules were
followed (other than 0 or 1), and developing appropriate rules would be
slow and
application specific at best. Thus, it would seem more reasonable to use
another
implementation for TCB integrity.
However, Jueneman's use of encryption, checksums, and digital signatures
seems
to be an excellent proposal for addressing the first integrity goal at
the distributed
system level. Significant work has already been done in these three areas.
Encryption,
checksums, and digital signatures are well understood, and they add necessary
integrity protection for distributed systems. To re-emphasize Jueneman's
approach: the originator of an object is responsible for assuring its
confidentiality,
and the recipient is responsible for determining its integrity.
5.2.6 GONG IMPLEMENTATION
5.2.6.1 Discussion of Gong
Gong [1989] presents the design of an Identity-based CAPability protection
system
(ICAP), which is aimed at a distributed system in a network environment.
ICAP
merges the ACL approach and the capability approach; ACLs support a capability
protection mechanism (just the opposite of Karger's SCAP), and nicely
solve the
problem of revocation. Gong's design provides support for administrative
activities
such as traceability. This approach also works for a centralized system.
Compared
with existing capability system designs, ICAP requires much less storage
and has the
potential of lower cost and better real-time performance.
A classic capability is represented as
(Object,Rights,Random)
in which the first item is the name of the object and the second is the
set of access rights.
The third is a random number to prevent forgery and is usually the result
of a one-
way function f,
Random = f(Object,Rights)
Here, f can be a publicly known algorithm. It should not be based on
other secret keys
because key distribution introduces other difficulties. Its requirements
are that it is
computationally infeasible to inverse f and, given a pair of input and
matching output, it
is infeasible to find a second input which gets the same output. When
an access
request arrives at the object server together with a capability, the one-way
function f is
run to check the result against the random number to detect tampering.
If the
capability is valid, the access is granted to the subject.
In a classic system, a capability is created for each different set of
access rights
required for each object, and the capabilities that are kept by the server
and other
subjects for the same set of rights are the same. For example, if subject
S1 possesses a
read-only right and S2 possesses a read and write right for an object,
the server has to
have two different capabilities, C1 and C2. S1 holds C1 and S2 holds C2.
In ICAP, only one capability for each object is stored at the server,
and different
subjects' capabilities for the same object are distinct. This improvement
in storage is
achieved by changing the semantics of those items in traditional capabilities
to
incorporate identities, e.g., the owner-id, into the capabilities. When
the server creates
a new object on behalf of a subject S1, an ``internal'' capability is
created as
(Object,Random0)
and stored in the server's internal table. As usual, this table is protected
against
tampering and leakage. S1 is sent an ``external'' capability
(Object,Rights,Random1)
which looks exactly the same as a classic capability but
Random1 = f(S1,Object,Rights,Random0)
When S1 presents the capability later, the server runs the one-way function
f to check its
validity. Note the number Random0 should possess a kind of freshness to
counter a
playback attack. For example, it could have a timestamp.
The server holds only one internal capability for each object, regardless
of how
many different subjects have access to a particular object. Thus, there
is a reduction in
the amount of storage required at the server. Subjects continue to hold
distinct external
capabilities for each object they are allowed to access.
When S1 wants to pass its external capability
(Object,Rights,Random1)
to a process owned by S2, it must explicitly present the request to the
server. If the
request complies with the security policy, the server retrieves the secret
Random0
from its internal table, creates
(Object,Rights,Random2)
where
Random2 = f(S2,Object,Rights,Random0) and passes it to S2.
Because the internal random number is kept secret, external capabilities
are
protected against forgery. Moreover, since proper authentication is done,
subjects
cannot masquerade as others. Subject S2 cannot use S1's capability even
if S2 possesses a
copy of S1's capability because the identities are different, hence the
results of
applying f will be different; S2 must be given its own capability to access
a particular
object. Any valid propagation has to be completed by the server rather
than by the
subjects. In other words, the server can monitor, mediate, and record
any capability
propagation.
When a capability is to be propagated, the kernel or an ``access control
server'', which
may or may not be the object server, checks to see whether to allow the
propagation,
according to the security policy. The intuitive motive of this scheme
is the
observation that the number of capability propagations is usually much
less than the
number of their uses, so it seems more economic to check the security
policy at
propagation time than at access time. The object server does not check
against the
security policy when a capability is later used for access. Instead, exception
lists and
propagation trees are used to revoke access.
Exception lists are associated with each internal capability to achieve
rapid
revocation. When S1 wants to revoke a capability it gave S2 earlier, it
presents the
request to the server. The server then updates the corresponding exception
list.
When an access is required, both the exception list and the capability's
validity are
checked. These checks can be done in parallel.
Capability propagation trees are stored at the access control server,
and they can be
resolved in background mode to achieve complete revocation. For a capability
passed
from S1 to S2 and then to S3, the propagation tree entry would look like
(Object,Rights,S1,S2,S3,Random3)
where
Random3 = f(S1,S2,S3,Object,Rights,Random0)
When something goes wrong, it is straightforward to know from the access
control
lists who has what access to an object. In addition, it is easy to know
from the
propagation trees how the access rights were propagated.
5.2.6.2 Analysis of Gong
Gong's implementation is an effective, conceptually straight-forward
implementation of access control lists supporting a capability-based protection
system.
His approach takes advantage of the domain separation and performance
characteristics of capabilities, while maintaining control over propagation
and
revocation of access rights. Just as importantly, the structure of the
implementation is
simple and allows the incorporation of any disclosure and/or integrity
policy. This
implementation can be used to address the first and third goals of integrity.
The implementation is made up of users, objects, object server(s), and
a centralized
access control server. The access control server maintains ACLs that describe
the
desired protection policy, and it also monitors any new requests for capabilities.
An
object server maintains one internal capability for each object, and communicates
with
the access control server on behalf of the users. These two types of servers
each contain
additional data structures that Gong uses to solve the two main problems
encountered
in the past with capability-based protection systems: propagation and
revocation.
Propagation trees are stored on the access control server to keep track
of which users
have access to an object and how they obtained that access. Each object
server stores an
exception list that records when a user wants to revoke access to another
user.
This implementation provides flexibility in several areas. The most significant
accomplishment is that the type of protection policy is immaterial to
Gong's
implementation; it could be a Bell and LaPadula disclosure lattice, a
Biba integrity
lattice, Clark and Wilson triples, or Lee/Shockley non-hierarchical categories.
Whatever
the policy, it is incorporated as part of the access control server.
There are other aspects to Gong's implementation that allow for flexibility
of use.
First, domain IDs can be incorporated into user IDs, if necessary. Second,
discre-
tionary control can be added on top of the existing non-discretionary
control structure.
Third, sealed (encrypted) capabilities can be used to implement protected
subsystems.
Finally, the given capability structure can be expanded.
Gong's implementation has two additional advantages besides flexibility.
First,
the protection policy is checked at propagation time, which is more economic
than
checking the policy on each access. Second, although exception lists are
very useful for
achieving rapid revocation, complete revocation can be performed in the
background
by the access control server. This structure also allows revocation to
be withdrawn.
Since revocation is initially marked in the exception list, a false alarm
or error can be
resolved without invoking the expensive full revocation mechanism.
A disadvantage in the Gong implementation is that it can only implement
static
separation of duties because the ACLs are not checked at access time.
This limitation
may be a major drawback in the long run if dynamic separation of duties
becomes an
accepted and required part of system specifications.
5.2.7 SUMMARY OF MODEL IMPLEMENTATIONS
Based on one or more of the models we have discussed, seven implementations
have been identified and analyzed. Lipner [1982] is the first work to
emphasize the
importance of non-hierarchical categories for achieving integrity. This
implementation
also introduces the important distinction between program objects and
data objects.
Boebert [Boebert 1985, Boebert 1988] presents a flexible, object-oriented
approach that
focuses more on isolating the action than isolating the user. Lee [1988]
and Shockley
[1988] introduce minimum and maximum views for controlling access to objects.
This
approach may be difficult to manage, but it does point out the usefulness
of strong
typing and transaction-based operations. Karger [1988] and Gong [1989]
both combine
the advantages of capabilities (speed and domain separation) and ACLs
(review and
revocation). Karger's approach uses capabilities in support of ACLs; Gong
uses ACLs
in support of capabilities. Karger provides more flexibility, but Gong's
approach seems
to be more realistic for use in an actual system. Jueneman [1989] has
a highly complex
approach for TCB integrity, but his use of encryption, checksums, and
digital signatures
seems to be an excellent proposal for promoting and preserving certain
aspects of
integrity in distributed systems.
Each of the implementations described in this section address one or
more of the
integrity goals defined at the beginning of the paper. All of the approaches
address
the first, and most basic, goal of computer system integrity. The second
goal is not
addressed directly by any of the implementations. The third goal is addressed
by
several implementations [Lee 1988, Shockley 1988, Karger 1988, Gong 1989]
that
recommend using concepts described in the Clark and Wilson model.
5.3 GENERAL ANALYSIS OF MODELS AND MODEL IMPLE-
MENTATIONS
Models and model implementations that protect information in computer
systems
are all based on some policy variation of the principle of separation.
A common theme
is to restrict access to information by separating more ``sensitive''
information from less
important data, and concentrating the protection effort on the sensitive
information.
We have described several models and implementations which have different
philosophies on the concept of separation. Now we look at the pros and
cons of five
separation philosophies: hierarchical levels, non-hierarchical categories,
access control
triples, protected subsystems, digital signatures, and encryption. We
also discuss the
combination of capabilities and ACLs, and conclude with a general analysis.
5.3.1 Hierarchical Levels
One of the earliest computer protection models was developed in 1975
by Bell and
LaPadula, with the emphasis being to prevent unauthorized disclosure of
data or
information. Their approach to modelling separation was through a lattice,
designed to
neatly coincide with the existing governmental classification structure
(e.g, Top Secret,
Secret, Confidential, Unclassified). The Bell and LaPadula model was the
inspiration
for Biba's integrity model. Both models emphasize levels in establishing
rules for
information protection.
The current governmental classification system is oriented toward preventing
improper disclosure of information; Bell and LaPadula developed their
model with
this classification system in mind. If a similar classification system
were developed for
preventing improper modification, the Biba model would be a good choice
for
representing these needs. Until then, hierarchical levels will not be
very useful for
computer system integrity.
5.3.2 Non-hierarchical categories
The term ``category'' is used to describe non-hierarchical separation.
In 1982, Lipner
expressed the need to have a different outlook on computer security. He
recommended that primary emphasis be placed on categories, and only minor
emphasis be placed on levels. Outside of the government, few organizations
operate
according to the concept of levels. Most companies have employees at the
same
``level'', but with different responsibilities. Even if levels are implemented,
categories
must provide appropriate separation between users within each level. The
concept of
``roles'' may be more accurate or applicable.
5.3.3 Access Control Triples
Lipner was the first person to identify the need for distinguishing between
program
objects and data objects. Clark and Wilson built on this distinction to
establish the
concept of access control triples. Clark and Wilson view triples as being
necessary
for implementing integrity because triples allow the explicit identification
of which
data a user is allowed to manipulate with a particular program. Triples
also provide the
ability to implement separation of duty, another necessary attribute of
a computer
system that has integrity.
Triples provide a useful paradigm for implementing integrity. While the
Clark
and Wilson model does not have all the details worked out, we believe
that it is a
useful guide for future research in addressing computer system integrity.
5.3.4 Protected Subsystems
Goguen and Meseguer introduced an automaton-based model that focuses
on the
transition from one valid state to the next as defined by the particular
security policy
being enforced. The emphasis of this model is to separate users' working
spaces to
provide non-interference and to prevent unauthorized access. Boebert and
Kain's
implementation is based on this concept of protected subsystems.
Protected subsystems implement a finer degree of separation within categories.
They exclude certain access rights that a user has outside the subsystem.
A user can
only access certain objects from within the protected subsystem, and then
only in
constrained ways defined by the subsystem.
Strong typing is a promising area for implementing protected subsystems.
Strong
typing provides separation by limiting the number of entry points for
executing
certain programs. In other words, a user must have access to the appropriate
type in
order to execute the programs within that domain. However, strong typing
does not
limit the execution of specific programs once a user has entered the domain;
that is the
responsibility of access controls (i.e., triples).
5.3.5 Digital Signatures/Encryption
The last philosophy of separation is based on digital signatures and
encryption.
Jueneman is the biggest supporter of this approach; he strongly argues
that digital
signatures and encryption are the only way to provide protection across
a distributed
network. Jueneman may be correct in this matter, although the use of digital
signatures
and encryption appears to be a necessary rather than a sufficient mechanism
for
protection in distributed environments.
5.3.6 Combination of Capabilities and ACLs
Both Karger and Gong combine the advantages of capabilities (protection
domains
and performance) and ACLs (control over propagation and revocation of
access rights)
to provide protection. Karger's model allows for dynamic separation of
duties, but
Gong's model is simple, implementable, and more efficient for static separation
of
duties.
5.3.7 Summary of General Analysis
Having analyzed each of the individual models, some overall conclusions
can be
identified. First, as Lipner suggested, categories seem to be much more
important
than levels for implementing integrity. Also, it is important to distinguish
between
program and data objects because programs are the means by which a user
modifies
data objects. Second, the Clark and Wilson model appears to be a useful
starting point
for addressing the issues of integrity. In particular, access triples
are recommended (if
not required) to explicitly identify which programs a user may invoke
to modify
particular data objects; triples cannot be implemented with existing systems.
Third,
encryption and digital signatures look to be an effective way of maintaining
integrity
over a distributed network. Fourth, the combination of capabilities and
access control
lists provides maximum separation, efficiency, and access review. Finally,
many of the
models talk about validation and verification of the programs that carry
out the actual
manipulations (TPs in Clark and Wilson). Continued research needs to focus
on
methods for assuring that programs do what they are intended to do and
nothing more.
6 CONCLUSIONS
This paper has discussed the need for integrity to be promoted and preserved
with
respect to data and systems. It has recognized that this need exists for
military, public,
private, and commercial organizations who depend on the integrity of their
systems
and their data in automated information processing, process control, and
embedded
computing applications. Further, it has shown that this need has been
recognized since
the early days of computer systems development, and that many of the protection
mechanisms now routinely incorporated into today's computers were the
result of
addressing concerns of integrity. This latter point is important in that
often the
argument is made that we have had no worked examples of integrity and
that we need
to conduct a significant amount of research before any criteria are written.
This paper
tries to add some balance to that argument. The paper illustrates that
there is a sig-
nificant body of knowledge available about integrity and integrity mechanisms,
and
that such knowledge can be presented in a way to aid in initial formulations
of
criteria. The paper also recognizes that there are many aspects of integrity
that
require further investigation. It is the idea of concurrently pursuing
both criteria and
criteria-enabling research that we believe is key to making the rapid
advances necessary
in meeting the recognized needs for integrity.
6.1 SUMMARY OF PAPER
The paper discussed the difficulty of trying to provide a single definition
for the term
integrity as it applies to data and systems. We conclude that a single
definition is
probably not possible and, indeed, not needed. An operational definition
that
encompasses various views of the issue seems more appropriate. We offer
such an
alternative so that progress beyond definitional aspects can be made.
Our framework,
or operational definition, provides a means to address both data and systems
integrity
and to gain an understanding of important principles that underlie integrity.
It
provides a context for examining integrity preserving mechanisms and for
understanding the integrity elements that need to be included in system
security
policies.
The paper has provided a set of principles that are important to integrity.
We do
not claim that the set is complete or applies to all systems or applications.
We do
believe that it is useful as basis for developing integrity policies and
mechanisms. We
encourage others to debate and to strengthen this set of principles.
We have shown that the promotion and preservation of data and systems
integrity
can involve a wide diversity of mechanisms. The mechanisms have been categorized
to show that they serve a relatively small set of distinct purposes. Separation
stands out
as the most pervasive feature. We use the term ``policy'' to describe
the administrative
courses of actions which characterize a group of mechanisms in promoting
or
preserving integrity. We acknowledge that not all of these mechanisms
are automated,
but we believe that by including them we have given greater insight into
what types of
controls need to be provided and the types of threats which must be countered
by
automated integrity mechanisms. A significant number of these mechanisms
serve to
support human-enforced integrity; thus, without humans involve in the
process, these
mechanisms will not necessarily provide additional benefits. The costs
and benefits of
research required to automate some of these mechanisms should be evaluated.
All of
these mechanisms need to be examined in light of other protection goals,
i.e.,
confidentiality, to ensure that any conflicting goals are identified and
resolved prior
to the inclusion of these mechanisms into systems that need to satisfy
multiple
protection goals.
The paper has provided an overview of several models and model
implementations (paper studies) of integrity. These models are still rather
primitive
with respect to the range of coverage suggested by examining both data
and systems
integrity. No model, on its own, supports all of the integrity policies
that we have
identified. Of these models, the Clark and Wilson model now seems to be
receiving the
most research attention. It is not a formal mathematical model, and its
lack of
preciseness in its details still leaves many elements ambiguous. Although
these
ambiguities need to be resolved and many aspects empirically proven, the
Clark and
Wilson model provides a fresh and useful point of departure for examining
issues of
integrity. The Biba model addresses a more fundamental concept, that of
contamination.
While this model may seem initially appealing, it seems contrary to what
is actually
occurring in data processing where most of the mechanisms we apply are
meant to
increase the integrity of the data. Further, it does not seem to be practical
or easily
implementable, i.e., the determination of labels for specific data and
the subsequent
labelling operations of data items may be extremely difficult and of a
much higher cost
than the value returned. The Goguen and Meseguer model is related to integrity
by
the concept of non-interference, which can be used to model behaviors
of active
entities and to show that actions are separate and non-interfering.
6.2 SIGNIFICANCE OF PAPER
By going beyond attempting to define integrity, the document provides
material
that we believe will be useful to system designers, criteria developers,
and to
individuals trying to gain a better understanding of the issues of data
and systems
integrity. The study provides a framework and foundational material to
continue the
efforts toward developing criteria for building products which preserve
and promote
data and systems integrity. However, this study is only a beginning and
remains
incomplete in terms of fully addressing the topic. Further principles
should be
sought out. Additional mechanisms in the areas of fault tolerance, database
management, communications, and in specific application areas should be
described and analyzed.
The paper reinforces the realization that data and systems integrity
are important
and necessary, and that they need to be addressed in a determined and
methodical
manner. We conclude that there is a great deal known about certain aspects
of data and
systems integrity and, in many cases, that there exists a history of experiences
with
both the principles and the mechanisms. We also conclude that there are
many things
yet to be learned with respect to assembling this experience and knowledge
into
coherent systems, e.g., moving from manual mechanisms to automated mechanisms.
One of the main conclusions that can be drawn from this paper is that
mechanisms can
be applied at various layers of system abstraction. This concept of layering
needs to be
examined to determine what, if any, interfaces need to exist between mechanisms
at
different system layers and what protocols need to exist within layers.
IDA is
undertaking a follow-on study to address the allocation and layering of
mechanisms.
Integrity criteria need to be written. For some aspects, we conclude
that there is
sufficient understanding to write specific criteria, but for other aspects
of such criteria,
more experience, research, debate, and proofs of concepts will be needed.
We believe
that this partial knowledge should not delay the writing of criteria.
Rather, we
recognize the need to establish a means to make the criteria, and thus
the systems,
evolvable with respect to integrity protection. Establishing this means
may require
more participation by systems vendors in the evolutionary development
of integrity
criteria than there was in the development of confidentiality criteria.
The key here is
to understand what is involved in designing systems for evolution so that
criteria do not
unnecessarily stifle new system designs or new concepts for preserving
or promoting
integrity.
6.3 FUTURE RESEARCH
The following studies are suggestive of those that should be undertaken
to extend
and apply the principles, mechanisms, models, and model implementations
that have
been presented in this paper.
Allocation Study
The understanding of layering and allocating the various integrity mechanisms
needs to be broadened. There are many questions that need to be addressed
as part of
this understanding. For example, how should the various mechanisms be
allocated
across the applications, operating systems, database management systems,
networking systems, and hardware bases? What is the basis for this allocation?
What
are the interactions between and among layers? What are the concerns between
allocation and system evolution? What might one expect from a vendor's
product as
a result of allocation? This study is critical to refining specifications
for product-
oriented control objectives that will form the basis of product criteria.
Interface and Protocol Studies
Where there appears to be a need for interaction between mechanisms in
different
system layers, the specific interfaces and communications protocol must
be established.
These studies should examine current interfaces and develop new ones as
appropriate.
They should design new or show how existing protocols can be used. These
studies
should examine the efficiency and effectiveness of potential interfaces
and protocols.
Where appropriate, these studies should recommend proofs of concept research.
Demonstration/Validation Studies
We need to have some worked examples to ensure that the arrangement of
mechanisms is workable, that interface and protocol concepts are valid,
and that
criteria are testable. These studies should incorporate a variety of systems
architectures
to preclude development of criteria with a single or limited focus.
Criteria Development Study
We need to begin to develop criteria in parallel with the protocol and
demonstration/validation studies. This effort should interact with these
two areas in
receiving and providing direction. One major part of the criteria study
should be form,
a second part should be scope and specific content, a third part should
address the
evolution of criteria, and a final part should address the linkages of
product criteria to
certification and accreditation of systems by using authorities.
REFERENCE LIST
[1] Abrams 1990
Abrams, Marshall D., Leonard J. La Padula, Kenneth W. Eggers, and In-
gred M. Olson. 1990. A Generalized Framework for Access Control: An
Informal Description. In Proceedings of the 13th National Computer Se-
curity Conference, 1-4 October 1990, Washington, D.C., 135-143. Gaith-
ersburg, MD: National Institute of Standards and Technology.
[2] Biba 1977
Biba, K.J. 1977. Integrity Considerations for Secure Computer Systems.
Bedford, MA: MITRE Corporation.
[3] Bishop 1979
Bishop, M. and L. Snyder. 1979. The Transfer of Information and Au-
thority in a Protection System. In Proceedings of the 7th Symposium
on Operating Systems Principles, 10-12 December 1979, Pacific Grove,
California, 45-54. New York: Association for Computing Machinery.
[4] Boebert 1985
Boebert, W.E. and R.Y. Kain. 1985. A Practical Alternative to Hierarchical
Integrity Policies. Proceedings of the 8th National Computer Security
Conference, 30 September-3 October 1985, Gaithersburg, Maryland, 18-27.
Gaithersburg, MD: National Bureau of Standards [now the National Insti-
tute of Standards and Technology].
[5] Boebert 1988
Boebert, W.E. 1988. Constructing an Infosec System Using LOCK Technolo-
gy. In Proceedings of the 11th National Computer Security Conference,
17-
20 October 1988, Baltimore, Maryland: Postscript, 89-95. Gaithersburg,
MD: National Bureau of Standards [now the National Institute of Stand-
ards and Technology].
[6] Boebert 1990
Boebert, W.E. 1990. Electronic communication to authors.
[7] Bonyun 1989
Bonyun, David A. 1989. On the Adequacy of the Clark-Wilson Defini-
tion of Integrity. In Report of the Invitational Workshop on Data Integri-
ty, January 25-27, 1989, Gaithersburg, Maryland, B.5B.5-9. Gaithersburg,
MD: National Institute of Standards and Technology.
[8] Branstad 1989
Branstad, Martha, Homayoon Tajalli, Frank Mayer, and David Dalva.
1989. Access Mediation in a Message Passing Kernel. In Proceedings of
the 1989 IEEE Computer Society Symposium on Security and Privacy,
May 1-3, 1989, Oakland, California, 66-72. Washington, D.C.: IEEE Com-
puter Society Press.
[9] Brewer 1989
Brewer, David F. C. and Michael J. Nash. 1989. The Chinese Wall Securi-
ty Policy. In Proceedings of the 1989 IEEE Computer Society Symposium
on Security and Privacy, May 1-3, 1989, Oakland, California, 206-214.
Washington, D.C.: IEEE Computer Society Press. Oakland, CA
[10] Chen 1989
Chen, Tom. 1989. Operating Systems and Systems-Group 1 Report. In
Report of the Invitational Workshop on Data Integrity, January 25-27,
1989, Gaithersburg, Maryland, 4.1-14.1-11. Gaithersburg, MD: National
Institute of Standards and Technology. NIST Special Publication 500-168.
[11] Clark 1987
Clark, D.D. and D.R. Wilson. 1987. A Comparison of Commercial and
Military Computer Security Policies. Proceedings of the IEEE Symposi-
um on Security and Privacy, 184-194, Oakland, CA.
[12] Clark 1989
Clark, David D. and David R. Wilson. 1989. Evolution of a Model for
Computer Integrity. In Report of the Invitational Workshop on Data In-
tegrity, January 25-27, 1989, Gaithersburg, Maryland, A.2-1A.2-13. Gaith-
ersburg, MD: National Institute of Standards and Technology. NIST
Special Publication 500-168.
[13] Courtney 1989
Courtney, Robert H. 1989. Some Informal Comments About Integrity
and the Integrity Workshop. In Report of the Invitational Workshop
on Data Integrity, January 25-27, 1989, Gaithersburg, Maryland, A.1-1A.1-
5.1. Gaithersburg, MD: National Institute of Standards and Technolo-
gy. NIST Special Publication 500-168.
[14] DOD 1985
Department of Defense. 1985. DoD Trusted Computer System Evalua-
tion Criteria. DoD 5200.28-STD. Washington, D.C.: U. S. Government
Printing Office.
[15] Eichin 1989
Eichin, Mark W. and Jon A. Rochlis. 1989. With Microscope and Tweez-
ers: An Analysis of the Internet Virus of November 1988. In Proceed-
ings of the 1989 IEEE Computer Society Symposium on Security and Pri-
vacy, May 1-3, 1989, Oakland, California, 326-343. Washington, D.C.:
IEEE Computer Society Press.
[16] Gligor 1987
Gligor, V.D., J.C. Huskamp, S.R. Welke, C.J. Linn, and W.T. Mayfield.
1987. Traditional Capability-Based Systems: An Analysis of Their Abili-
ty to Meet the Trusted Computer Security Evaluation Criteria. IDA Pa-
per P-1935, available as NTIS AD-B119 332. Alexandria, VA.
[17] Goguen 1982
Goguen, J.A. and J. Meseguer. 1982. Security Policies and Security Models.
Proceedings of the 1982 Berkeley Conference on Computer Security, 11-
20. Berkeley, CA.
[18] Gong 1989
Gong, Li. 1989. A Secure Identity-Based Capability System. In Proceed-
ings of the 1989 IEEE Computer Society Symposium on Security and
Privacy, May 1-3, 1989, Oak- land, California, 56-63. Washington, D.C.:
IEEE Computer Society Press.
[19] ISO 1990
International Standards Organization/International Electrotechnical Com-
mission Joint Technical Committee 1/Subcommittee 21 (ISO/IEC
JTC1/SC21). 1990. Information Technology-Security Frameworks for Open
Systems-Part 2: Authentication Framework. N 5281 (proposed Second
CD 10181-2).
[20] Johnson 1989
Johnson, Barry W. 1989. Design and Analysis of Fault-Tolerant Digital
Sys-
tems. Reading, MA: Addison-Wesley.
[21] Jueneman 1989
Jueneman, Robert R. 1989. Integrity Controls for Military and Commer-
cial Applications, II. Falls Church, VA: Computer Sciences Corporation.
CSC/PR-89/3001.
[22] Karger 1984
Karger, Paul A. and Andrew J. Herbert. 1984. An Augmented Capability
Architecture to Support Lattice Security and Traceability of Access. In
Proceedings of the 1984 IEEE Symposium on Security and Privacy,
April 29-May 2, 1984, Oakland, California, 2-12. Silver Spring, MD:
IEEE Computer Society Press.
[23] Karger 1988
Karger, Paul A. 1988. Implementing Commercial Data Integrity with Se-
cure Capabilities. In Proceedings of the IEEE Symposium on Security
and Privacy, April 18-21, 1988, Oakland, California, 130-139. Washing-
ton, D.C.: IEEE Computer Society Press.
[24] Knight 1986
Knight, J.C., and N.G. Leveson. 1986. An Experimental Evaluation of the
Assumption of Independence in Multiversion Programming. IEEE Trans-
actions on Software Engineering 12 (January): 96-109.
[25] Lee 1988
Lee, Theodore M.P. 1988. Using Mandatory Integrity to Enforce ``Com-
mercial'' Security. In Proceedings of the IEEE Symposium on Security
and Privacy, April 18-21, 1988, Oakland, California, 140-146. Washing-
ton, D.C.: IEEE Computer Society Press.
[26] Lipner 1982
Lipner, S.B. 1982. Non-Discretionary Controls for Commercial Applica-
tions. Proceedings of the IEEE Symposium on Security and Privacy, 2-10.
Oakland, CA
[27] Longley 1987
Longley, Dennis and Michael Shain. 1987. Data & Computer Security:
Dictionary of Standards, Concepts and Terms. New York: Stockton
Press.
[28] Mayfield 1991
Mayfield, Terry, John M. Boone, Stephen R. Welke. 1991. Integrity-Ori-
ented Control Objectives: Proposed Revisions to the Trusted Compu-
ter Systems Evaluation Criteria (TCSEC), DoD 5200.28-STD. Alexandria,
VA: Institute for Defense Analyses. IDA Document D-967.
[29] NCSC 1988
National Computer Security Center (NCSC). 1988. Glossary of Compu-
ter Security Terms. Washington, D.C.: U.S. Government Printing Office.
[30] Outposts 1989
Air Safety: Is America Ready to `Fly by Wire'? The Washington Post
April 2, 1989. Outposts section: C3.
[31] Rivest 1978
Rivest, R.L., A. Shamir, and L. Adleman. 1978. A Method of Obtaining
Digital Signatures and Public-Key Cryptosystems. Communications of
the ACM 21, 120-126 (February).
[32] Roskos 1984
Roskos, J.E. 1984. Data Movement, Naming, and Ambiguity. Nashville,
TN: Vanderbilt University, Department of Computer Science. Technical
Report CS-84-05.
[33] Saltzer 1975
Saltzer, J.H. and M.D. Schroder. 1975. The Protection of Information
in
Computer Systems. Proceedings of the IEEE 63, (September): 1278-1308.
[34] Saltzer 1977
Saltzer, J.H. 1977. Naming and Binding of Objects. In Operating Sys-
tems: An Advanced Course, 99-208. New York: Springer-Verlag.
[35] Schaefer 1989
Schaefer, M., W. C. Barker, and C. P. Pfleeger. 1989. Tea and I: An Al-
lergy. In Proceedings of the 1989 IEEE Computer Society Symposium on
Security and Privacy, May 1-3, 1989, Oakland, California, 178-182.
Washington, D.C.: IEEE Computer Society Press.
[36] Seecof 1989
Seecof, M. and R. Hoffman. 1989. A320/MD-11 F-B-W differ on pilot au-
thority. Electronic posting to the Forum on Risks to the Public in Comput-
ers and Related Systems. Vol. 9, Issue 4 (July 13).
[37] Shockley 1988
Schockley, W.R. 1988. Implementing the Clark/Wilson Integrity Policy
Using Current Technology. In Proceedings of the 11th National Com-
puter Security Conference, 17-October 1988, Baltimore, Maryland, 29-37.
Gaithersburg, MD: National Bureau of Standards [now the National Insti-
tute of Standards and Technology].
[38] Steiner 1988
Steiner, Jennifer, Clifford Neuman, Jeffrey I. Schiller. 1988. Kerberos:
An
Authentication Service for Open Network Systems. Cambridge, MA: Mas-
sachusetts Institute of Technology.
[39] Struble 1975
Struble, George E. 1975. Assembler Language Programming: The IBM
System/360 and 370. Reading, MA: Addison-Wesley.
[40] Sutherland 1986
Sutherland, David. 1986. A Model of Information. In Proceedings of the
9th National Computer Security Conference, 15-18 September 1986,
Gaithersburg, Maryland, 175-183. Gaithersburg, MD: National Bureau
of Standards [now the National Institute of Standards and Technology].
[41] Webster 1988
Webster's Ninth New Collegiate Dictionary. 1988. Springfield, MA:
Merriam-Webster, Inc.
APPENDIX : GENERAL INTEGRITY PRINCIPLES
Several general security concepts should be borne in mind while considering
the
mechanisms described in Section 4. These concepts are based primarily
on a paper
by Jerome Saltzer and Michael Schroeder which has formed the basis for
many of the
ideas in later computer security work, including the TCSEC. This appendix
is intended
to help give a perspective to the very diverse set of mechanisms reviewed
in Section 4.
In their 1975 paper, ``The Protection of Information in Computer Systems,''
Saltzer
and Schroeder address a number of issues related to computer security
[Saltzer
1975]. While the focus of the paper was not exclusively integrity, many
of the ideas and
concepts presented in that paper relate to current integrity issues. In
particular, the
authors discuss ``Functional Levels of Information Protection'' and ``Design
Principles,''
which will be reviewed in this appendix. In addition to being applicable
to integrity,
these principles relate directly to many concepts in the TCSEC. This paper
compiles
and draws on a large amount of early material dealing with computer security.
References to those sources will not be noted here, but can be found in
the original
report.
1 TRADITIONAL DESIGN PRINCIPLES
The design principles presented by Saltzer and Schroeder are intended
to reduce
design and implementation flaws which lead to unauthorized disclosure,
modification, or denial of system resources. The authors emphasize that
these
principles should not be taken as absolute rules, but that violations
of the principles
should be taken as potential sources of trouble and therefore should not
be
undertaken lightly. These principles tend to reduce both the number and
severity of
flaws.
1.1 ECONOMY OF MECHANISM
This principle states that the design, for all aspects of the system
and especially for
protection mechanisms, should be kept as simple and small as possible.
The rationale
behind this principle is that techniques such as code verification are
required to
discover design and implementation flaws which occur only under exceptional
conditions. Such techniques are effective only if the design is simple
and the actual code
is minimized as much as possible.
1.2 FAIL-SAFE DEFAULTS
This principle asserts that access decisions should be based on permission
rather
than exclusion. This equates to the condition in which lack of access
is the default, and
the ``protection scheme'' recognizes permissible actions rather than prohibited
actions.
The authors mention that decisions based on exclusion present the wrong
``psychological base'' for a secure system. Also, failures due to flaws
in exclusion-based
systems tend to grant (unauthorized) permission, whereas permission-based
systems
tend to fail safe with permission denied.
1.3 COMPLETE MEDIATION
This principle stresses that ``every access request to every object must
be checked for
authority.'' This requirement forces a global perspective for access control,
during all
functional phases (e.g. normal operation, maintenance). Also stressed
are reliable
identification of access request sources and reliable maintenance of changes
in
authority.
1.4 OPEN DESIGN
This principle stresses that secrecy of design or the reliance on the
ignorance of
(malicious) users is not a sound basis for secure systems. Open design
allows for open
debate and inspection of the strengths, or origins of a lack of strength,
of that particular
design. Secrecy, a strong protection mechanism in itself, can be implemented
through
the use of passwords and keys. Secrecy implemented through the use of
these objects is
much easier to maintain than secrecy of design, where disclosure permanently
effects
system security. By comparison, passwords and keys are easily changed
if disclosed,
restoring security of the system.
1.5 SEPARATION OF PRIVILEGE
This principle asserts that protection mechanisms where two keys (held
by different
parties) are required for access are stronger mechanisms than those requiring
only one
key. The rationale behind this principle is that ``no single accident,
deception, or
breach of trust is sufficient'' to circumvent the mechanism. In computer
systems the
separation is often implemented as a requirement for multiple conditions
to be met
before access is allowed.
1.6 LEAST PRIVILEGE
This principle specifies that ``every program and user of the system
should operate
using the least set of privileges necessary to complete the job.'' One
effect of this
principle is that the potential for damage caused by an accident or an
error is limited.
This principle addresses the need for minimal interactions between privileged
programs and the need to prevent improper uses of privilege. An example
of the results
of not applying the least privilege principle was seen in the November,
1988 Internet
``Virus'' [Eichin 1989]. One of the ways in which this virus gained access
to its host
systems was by exploiting the ability of the UNIX ``sendmail'' Simple
Mail Transfer
Protocol (SMTP) server to execute arbitrary programs. The ability to execute
arbitrary
programs was not necessary to the operation of SMTP and, under the least
privilege
principle, should not have been provided. Its unnecessary presence gave
an extra
privilege, the execution of arbitrary programs on the remote host, to
users of sendmail,
and thus allowed the ``virus'' to exploit this privilege to compile and
execute its initial
components on remote systems it wished to ``infect.''
1.7 LEAST COMMON MECHANISM
This principle requires the minimal sharing of mechanisms either common
to
multiple users or ``depended upon by all users.'' Sharing represents possible
communications paths between subjects which can be used to circumvent
security
policy. Global mechanisms must be adequately secure in terms of the user
with the
strictest requirements on the system; this encourages non-global mechanisms.
1.8 PSYCHOLOGICAL ACCEPTABILITY
This principle encourages the routine and correct use of protection mechanisms
by
making them easy to use, thus giving users no reason to attempt to circumvent
them.
Also addressed is the need for the supplied mechanisms to match the user's
own image
of his protection goals. This requirement prevents the user from attempting
to
implement his protection goals in an unnatural or arcane manner using
poorly fitting
mechanisms, since such an approach would be more prone to error.
2 ADDITIONAL DESIGN PRINCIPLES
Saltzer and Schroeder present the following principles as being employed
in the area
of physical security. They observe that these principles do not apply
as well to
computer systems as do the principles discussed earlier. We have found
that this is
similarly the case for some of the integrity mechanisms we have examined.
2.1 WORK FACTOR
This principle permits the use of mechanisms that are vulnerable to systematic
attack, because the cost or amount of work involved in the attack is out
of proportion to
the value of the protected objects. It is a weaker mechanism by definition,
since many
alternate protection mechanisms are not vulnerable to systematic attacks,
but can
only be defeated by a hardware failure, design error, etc. Besides this
inherent
vulnerability, another problem is that the actual work factor which is
implemented
may be hard to determine exactly or may sometimes be reduced through
automated attacks. In particular, a mechanism that may give an intolerable
work
factor in a manual system may be quite easy to attack on a computer system,
since the
computer, being designed to perform difficult, repetitive tasks, will
perform the
difficult work for the attacker. Thus the computer can often be used as
a tool to assist
in an attack upon its own security mechanisms.
2.2 COMPROMISE RECORDING
This principle calls for the accurate reporting of information compromise
as a
substitute for relying on more complex, preventive mechanisms. This principle
is not
as strong in computer systems, since the reporting mechanism itself must
be protected
from tampering and interference, otherwise violations may not be recorded.
If the
reporting mechanism is co-resident on the system being protected, an intruder
may be
able to gain access to the reporting mechanism at the same time the intruder
gains
access to other resources.
3 FUNCTIONAL CONTROL LEVELS
Saltzer and Schroeder also offer a categorization of protection functionality,
or ``the
kinds of access control that can be expressed naturally and enforced.''
This func-
tionality is the result of design decisions, with higher levels of functionality
being
harder to attain in implementation. The authors also discuss a concept
which is
independent of the level of functionality: dynamics of use. This term
refers to the way
in which access privileges are specified, and how the system allows modification
of that
specification. They mention that while static expressions of protection
are (relatively)
easy to implement, dynamic specification (requests to change the specification
which are
made by executing programs) can introduce considerable complexity into
the system.
Two problems associated with the dynamics of use are access determination
and
access revocation. The authors also mention that while the focus of their
paper is on
protection concerns which are internal to the computer, some functionality
may be
added through external protection methods. A short summary of the authors'
categorization follows.
3.1 UNPROTECTED SYSTEMS
These systems are not stressed, but they are worth mentioning because
they were the
most common type then in use (1975). Essentially, these systems have no
inherent,
effective means of preventing any user from access to all information
on the system.
Examples are batch data processing systems and most popular PC operating
systems.
This is of concern in the light of the widespread use of PCs today, including
analogous
machines in the tactical systems environment. These systems offer ``mistake-
prevention features,'' but no real security. Such features just ensure
that breaches of
control are intentional rather than accidental.
3.2 ALL-OR-NOTHING SYSTEMS
The main feature of these systems is the isolation of user environments
and
information. This isolation is sometimes moderated by such features as
a public library
mechanism, with users able to contribute information to that library.
Still, the
emphasis is on all users having equal access privileges, and all users
have a view of the
system as if it were a private machine.
3.3 CONTROLLED SHARING
A significant rise in complexity is required in these systems, which
control access to
each data item. Access control lists are a typical mechanism which enforces
controlled sharing. Although conceptually simple, the control mechanisms
tend to be
intricate and difficult in implementation. Generic access types (e.g.,
read, write,
execute) tend to be system defined to allow specification of user access
privileges.
3.4 USER-PROGRAMMED SHARING CONTROLS
These systems allow users to restrict access to files in non-standard
ways (as
defined by the system). For example, time constraints may be imposed upon
certain accesses, or multiple users' privileges (or actions) may be required
for other
accesses. These systems often implement the concept of protected objects
and
subsystems (emphasis in original), which effectively confines all accesses
to the
protected objects to programs within the protected subsystems. Entry to
the subsystem
is confined to specified entry points, allowing users to develop any programmable
form
of access control for objects created by the user. Other concepts include
content-based
and context-based (access) decision policies.
3.5 LABELLING INFORMATION
The previous three types of systems address the conditions under which
an
executing program is allowed access to information. In addition there
are other
systems which attempt to bring about continuing access control after the
initial access
decision. These systems also prevent or control the propagation of access
privileges. A
typical technique employed by these systems is the use of labels on data
objects, which
are used by the protection mechanism(s) to make access decisions. The
authors state
that such systems are rare and incomplete. This is still true today, but
not to the same
extent as when the paper was published.
ACRONYMS
ACF2 Access Control Facility 2
ACL Access Control List
AIS Automated Information Systems
C Certification
CDI Constrained Data Item
CIC Combat Information Center
CPU Central Processing Unit
DBMS Database Management System
DDT Domain Definition Table
DNA Deoxyribonucleic Acid
DoD Department of Defense
DTT Domain Transition Table
E Enforcement
I&A Identification & Authentication
I/O Input/Output
IC Integrated Circuit
ICAP Identity-based Capability
ID Identification or Identifier
INFOSEC Information Security
ISO International Standards Organization
IVP Integrity Verification Procedures
LED Light Emitting Diode
LOCK Logical Coprocessor Kernel
MMU Memory Management Unit
NCSC National Computer Security Center
PC Personal Computer
RACF Resource Access Control Facility
ROM Read-Only Memory
SAT Secure Ada Target
SCAP Secure Capability
SMTP Simple Mail Transfer Protocol
TCB Trusted Computing Base
TCSEC Trusted Computer System Evaluation Criteria
TOP Tagged Object Processor
TP Transformation Procedure
UDI Unconstrained Data Item
GLOSSARY
abstract data type. A mechanism which associates a set of permissible
values and
operations with an identified class of objects. See type.
access control list. A special case of access control tuples, where the
specification of
access to an object is implied by grouping all subject and permitted operation
information into a list, and attaching the list directly to the object.
access deterrence. A design principle for security mechanisms which is
based on a
user's fear of detection of violations of security policies rather than
absolute prevention
of violations.
access time minimization. A risk-reducing principle that attempts to
avoid
prolonging access time to specific data or to the system beyond what is
needed to carry
out requisite functionality.
access triple. A type of access control specification proposed in [Clark
1987] in which a
user, program, and data item are listed for each allowed operation.
accountability. A principle which calls for holding individuals responsible
for their
actions. In automated systems, this is enabled through Identification
and
Authentication (I&A), the specification of authorized actions, and
the auditing of the
user's activity.
actor. A term used to describe an object in object-oriented systems,
where the object
consists of both data and the operations which manipulate the data contents.
agent. A term used to denote a user or an automated surrogate acting
on behalf of a
user.
alarm. A signal that warns or alerts [Webster 1988].
anticipation. A technique related to polling, in which the resource detects
that it has not
been accessed by an active subject within an expected interval.
atomicity. A property of a transaction in which each data item involved
is either
transformed from one unimpaired state to a new unimpaired state, or the
initial
unimpaired state is restored if the transaction fails.
authorization. The principle whereby allowable actions are distinguished
from those
which are not.
authorization override. The ability to take a definite action under exceptional
circumstances to circumvent normal controls. authorized actions. The set
of actions
which a subject is allowed to perform.
availability. In computer security, availability denotes the goal of
ensuring that
information and information processing resources both remain readily accessible
to
their authorized users.
check digit. A checksum calculated on each digit of a numeric string
(e.g., parity
bits).
brevity codes. A shortened form of standardized messages which reduces
the amount
of input required by valid users while often hiding the message type,
or other
information obtained from the user interface, from unauthorized users.
capabilities. A protected identifier that both identifies the object
and specifies the
access rights to be allowed to the accessor who possesses the capability.
In a capability-
based system, access to protected objects such as files is granted if
the would-be
accessor possesses a capability for the object [NCSC 1988].
category. A restrictive label that has been applied to classified or
unclassified data as
a means of increasing the protection of the data and further restricting
access to the data
[NCSC 1988].
chained checksum. A checksum technique in which the hashing function
is a function
of data content and previous checksum values.
checksum. A numeric value which is computed (by some particular algorithm)
based
on the entire contents of a data object.
Chinese Wall model. A model presented in [Brewer 1989] to address confidentiality
policies in the context of dynamically changing access permissions.
classification. (1) In data security, a determination that information
requires, in the
interest of national security, a specific degree of protection against
unauthorized
disclosure together with a designation signifying that such a determination
has been
made [Longley 1987]. (2) Systematic arrangement in groups or categories
according to
established criteria [Webster 1988].
conditional authorization. A type of authorization which is activated
only at the
occurrence of conditioning events.
conditional enabling. A type of control in which actions are physically
disabled
unless an authorization for the action is granted.
conditioning events. Events which are specified as being sufficient to
invoke a
reaction from a conditionally authorized subject.
confidentiality. The concept of holding sensitive data in confidence,
limited to an
appropriate set of individuals or organizations [NCSC 1988].
configuration management. The management of security features and assurances
through control of changes made to a system's hardware, software, firmware,
documentation, test, test fixtures and test documentation throughout the
development
and operational life of the system [NCSC 1988].
constraint. The state of being checked, restricted, or compelled to avoid
or perform
some action [Webster 1988].
cryptographic checksum. A checksum computed by an algorithm which produces
a
unique value for each possible data value of the object.
cryptography. The principles, means and methods for rendering information
unintelligible, and for restoring encrypted information to intelligible
form [NCSC 1988].
data attribute checks. A verification that data has particular attributes.
data compression. Techniques which reduce the size of data objects by
encoding
redundancies in the data to a more compact form.
data integrity. The attribute of data relating to the preservation of
(1) its meaning and
completeness, (2) the consistency of its representation(s), and (3) its
correspondence to
what it represents. See integrity.
data minimization. A generalization of the principle of variable minimization,
in
which the standardized parts of a message or data are replaced by a much
shorter code,
thereby reducing the risk of erroneous actions or improper use.
data movement primitives. A method of controlling shared objects by providing
primitive operations which (logically) move the shared object into private
addressing
space when being accessed, thus preventing simultaneous access to the
object by
another process.
denial of service. Any action or series of actions that prevent any part
of a system
from functioning in accordance with its intended purpose. This includes
any action
that causes unauthorized destruction, modification, or delay of service
[NCSC 1988].
digital signature. In authentication, a data block appended to a message,
or a complete
encrypted message, such that the recipient can authenticate the message
contents and/
or prove that it could only have originated with the purported sender.
The digital
signature is a function of (1) the message, transaction or document to
be signed (2)
secret information known only to the sender and (3) public information
employed in the
validation process [Longley 1987].
discrete value checks. A verification that data has either certain permissible
values or
does not have other restricted values, out of a wider set of possible
values.
discretionary access control. A means of restricting access to objects
based on the
identity and need-to-know of the user, process and/or groups to which
they belong.
The controls are discretionary in the sense that a subject with a certain
access
permission is capable of passing that permission (perhaps indirectly)
on to any other
subject [NCSC 1988].
domain. The unique context (e.g., access control parameters) in which
a program is
operating. In effect, the set of objects that a subject has the ability
to access [NCSC
1988].
duplication protocol. A communications protocol which duplicates the
data being
sent in order to provide fault tolerance.
duty. A required task, conduct, service, and/or function that constitute
what one must
do and the manner in which it should be done.
dynamics of use. Pertaining to the way in which access privileges are
specified, and
how the system allows modification of that specification [Saltzer 1975].
embedded system. A system that performs or controls a function, either
in whole or in
part, as an integral element of a larger system or subsystem [NCSC 1988].
encapsulation. The principle of structuring hardware and software components
such
that the interface between components is clean and well-defined, and that
exposed
means of input, output, and control other than those that exist in the
interface do not
exist.
encryption. See cryptography.
error correcting code. A technique in which the information content of
the error-control
data of a data unit can be used to correct errors in the message data
of that unit.
error correction. Techniques which attempt to recover from detected data
transmission
errors.
event constraint. A type of constraint in which the active agent must
perform an action
or set of actions within a specified bound of time.
fault tolerance. The ability of a system to continue to perform its tasks
after the
occurrence of faults [Johnson 1989].
gate. An encapsulation implementation technique which provides access
between
domains only via specific locations (the gates) which provide a well-defined,
controlled interface.
handshaking protocol. Techniques in which two or more communicating entities
exchange information about successful or unsuccessful reception of data
for error
control.
hierarchical supervision. A technique in which integrity critical actions
are handled or
controlled by a more trusted or more experienced user while less critical
actions are
delegated to subordinates.
identity. The sameness in all that constitutes the objective reality
of a thing: oneness;
and is the distinguishing character of a thing: individuality [Webster
1988].
individuation. The determination of the individual in the general [Webster
1988].
integrity. (1) A subgoal of computer security which pertains to ensuring
that data
continues to be a proper representation of information, and that information
processing resources continue to perform correct processing operations.
(2) A subgoal of
computer security which pertains to ensuring that information retains
its original level
of accuracy. (3) Sound, unimpaired or perfect condition [NCSC 1988]. See
data integrity,
system integrity.
label. Written or printed matter accompanying an article to furnish identification
or
other information [Webster 1988]. See security label.
least privilege. The principle that requires that each subject be granted
the most
restrictive set of privileges needed for the performance of authorized
tasks. The appli-
cation of this principle limits the damage that can result from accident,
error, or
unauthorized use [NCSC 1988].
mandatory access control. A means of restricting access to objects based
on the
sensitivity (as represented by a label) of the information contained in
the objects and the
formal authorization (i.e., clearance) of subjects to access information
of such sensitivity
[NCSC 1988].
minimization. A risk-reducing principle that supports integrity by containing
the
exposure of data or limiting opportunities to violate integrity.
minimizing target value. A risk-reducing practice which stresses the
reduction of
potential losses incurred due to a successful attack, and/or the reduction
of benefits
an attacker might receive in carrying out such an attack.
monitor. To watch, observe, or check-especially for a special purpose
[Webster 1988].
mutual exclusion. The guarantee of exclusive access to a given data item
for the
purpose of completing a critical action in order to avoid interference
by other
entities attempting to simultaneously access the same data item.
N-person control. A method of controlling the actions of subjects by
distributing a
task among more than one (N) subjects.
noninterference. A concept proposed in [Goguen 1982] whereby a member
of
particular class cannot initiate actions that affect what is observed
by members of a
different class.
non-reversible action. A type of action which supports the principle
of accountability
by preventing the reversal and/or concealment of activity associated with
sensitive
objects.
notarization. The authentication of an object which is being transferred
between two
parties by an independent entity.
object. A passive entity that contains or receives information. Access
to an object
potentially implies access to the information it contains. Examples of
objects are
records, blocks, pages, segments, files, directories, directory trees,
and programs, as
well as bits, bytes, words, fields, processors, video displays, keyboards,
clocks, printers,
and network nodes [NCSC 1988].
obligation. The binding, constraining, or commitment of an individual
or an active
agent to a course of action.
privilege. (1) In operations, pertaining to a program or user and characterizing
the
type of operation that can be performed [Longley 1987]. (2) An authorization
to
perform an action.
privilege states. The states of a system in which a normally prohibited
set of actions
are allowed. Typically, use of privilege states is limited to ``trusted
processes'' which
are known or believed to use the normally prohibited actions only in specific,
controlled ways. See protection ring.
process sequencing. A technique which controls the order in which specific
tasks or
subtasks are completed.
protection ring. One of a hierarchy of privileged modes of a system that
gives certain
access rights to user programs and processes authorized to operate in
a given mode.
protocol. (1) A code prescribing strict adherence to correct procedures.
(2) In
telecommunications, it is a set of characters at the beginning and end
of a message
that enables communications between computers at various abstract service
layers.
These layers establish peer-entities between the communicating systems.
range checks. A verification that data is within a certain range of values.
read. A fundamental operation that results only in the flow of information
from an
object to a subject [NCSC 1988].
receive. A communications-oriented generalization of the read operation.
redundancy. (1) The part of a message that can be eliminated without
loss of essential
information. (2) The use of duplicate components to prevent failure of
an entire system
upon failure of a single component.
responsibility. Being answerable for what one does.
reversible action. An action that, once initiated, can be undone leaving
the object being
acted upon in a state as if the action had never been initiated.
risk reduction. The function of reducing one or more of the factors of
risk, e.g., value
at risk, vulnerability to attack, threat of attack, protection from risk.
role. A distinct set of operations required to perform some particular
function.
rotation of duty. A method of reducing the risk associated with a subject
performing a
(sensitive) task by limiting the amount of time the subject is assigned
to perform the
task before being moved to a different task.
routine variation. The risk-reducing principle which underlies techniques
which
reduce the ability of potential attackers to anticipate scheduled events
in order to
minimize associated vulnerabilities.
run-to-run totals. Checksums which are applied to sequenced data, in
which the
hashing function is made a function of the previously seen data.
security label. A piece of information that represents the security level
of an object
[NCSC 1988].
security model. A formal presentation of the security policy enforced
by the system. It
must identify the set of rules and practices that regulate how a system
manages, pro-
tects, and distributes sensitive information [NCSC 1988].
security policy. The set of laws, rules, and practices that regulate
how an organization
manages, protects, and distributes sensitive information [NCSC 1988].
send. A communications-oriented generalization of the write operation.
sensitive information. Any information, the loss, misuse, modification
of, or
unauthorized access to, could affect the national interest or the conduct
of Federal
programs, or the privacy to which individuals are entitled under Section
552a of Title 5,
U. S. Code, but that has not been specifically authorized under criteria
established by an
Executive order or an act of Congress to be kept classified in the interest
of national
defense or foreign policy [NCSC 1988].
separation. An intervening space established by the act of setting or
keeping apart.
separation of duty. The partitioning of tasks and associated privileges
among different
users or subjects, or to different, mutually-exclusive roles associated
with a single
user.
separation of name spaces. A technique of controlling access by precluding
sharing-
names given to objects are only meaningful to a single subject and thus
cannot be
addressed by other subjects.
serializability. Having the capability to consecutively order all actions
in a logical
transaction schedule.
strong typing. The application of type enforcement during all operations
upon
instances of abstract data types within a system or program.
summary integrity check. A method for checking the correct-
ness of data by comparing it with a ``summary'' of the data.
See checksum.
subject. An active entity, generally in the form of a person, process,
or device, that
causes information to flow among objects or changes the system state.
Technically, a
process/domain pair [NCSC 1988].
supervisory control. A method of controlling particular
actions of a subject by making those actions dependent on
the authorization of a supervisor.
system integrity. The attribute of a system relating to the successful
and correct
operation of computing resources. See integrity.
tactical system. A system which is used as an integral part of or in
support of a
weapon(s) system.
theft of service. The unauthorized use of information processing resources.
time
stamping. The method of including an unforgeable time stamp with object
structures,
used for a variety of reasons such as sequence numbering and expiration
of data.
timeouts for inactivity. The setting of time limits for either specific
activities or for
non-activity. See anticipation.
Tranquillity Principle. A requirement that changes to an object's access
control
attributes be prohibited as long as any subject has access to the object.
transmittal list. A list, stored and transmitted with particular data
items, which
identifies the data in that batch and can be used to verify that no data
are missing.
Trojan horse. A computer program with an apparently or actually useful
function
that contains additional (hidden) functions that surreptitiously exploit
the
legitimate authorizations of the invoking process to the detriment of
security or
integrity [NCSC 1988].
trusted computing base (TCB). The totality of protection mechanisms within
a
computer system, including hardware, firmware, and software, the combination
of
which is responsible for enforcing a security policy. A TCB consists of
one or more
components that together enforce a unified security policy over a product
or system.
The ability of a TCB to enforce correctly a unified security policy depends
solely on
the mechanisms within the TCB and on the correct input by system administrative
personnel of parameters (e.g., a user's clearance level) related to the
security policy
[NCSC 1988].
trusted path. A mechanism by which a person at a terminal can communicate
directly
with the TCB [trusted computing
base]. This mechanism can only be activated by the person or the TCB
and cannot be
imitated by untrusted software [NCSC 1988].
two-phase commit protocol. A mechanism which requires the logging of
a record for
all actions to ensure that any transaction either completely succeeds,
or may be
rolled back so that effectively no changes have occurred.
type. In programming, pertaining to the range of values and valid operations
associated
with a variable [Longley 1987].
type enforcement. The enforcement of allowable operations on an instance
of an
abstract data type, and on the permissible values that instance may take.
See strong
typing.
unconditional authorization. A type of authorization which enables immediate
action
on the part of the authorized subject.
value checks. A precursor to type enforcement mechanisms, value checks
are checks
against a definition of meaningful values through explicit enumeration
and/or
exclusion.
variable minimization. A method of reducing the number of variables to
which a
subject has access to the minimum required, thereby reducing the risk
of malicious or
erroneous actions by that subject. This concept can be generalized to
include data
minimization.
version control. A mechanism which allows distinct versions of an object
to be
identified and associated with independent attributes in a well-defined
manner.
virus. A self-propagating Trojan horse, composed of a mission component,
a trigger
component, and a self-propagating component [NCSC 1988].
well-formed transaction. Proposed in [Clark 1987] as a mechanism to prevent
a user
from manipulating a data item arbitrarily, but rather in constrained ways
that preserve
or ensure the internal consistency of data.
wholeness. Having all its parts or components-includes both the sense
of unimpaired
condition (i.e., soundness) and being complete and undivided (i.e., completeness).
write. A fundamental operation that results only in the flow of information
from a
subject to an object [NCSC 1988].
X.25. An International Organization for Standards (ISO) telecommunications
standard
for the network and data link levels of a communications network.
 |
