DRAFT

IDA DOCUMENT D-967

INTEGRITY-ORIENTED CONTROL
OBJECTIVES: PROPOSED REVISIONS
TO THE TRUSTED COMPUTER SYSTEM
EVALUATION CRITERIA (TCSEC), DoD
5200.28-STD

Terry Mayfield

John M. Boone

Steven R. Welke

August 1991

This document is still subject to modification or withdrawal and therefore may not be
referenced in any publication. It also should not be duplicated.

Prepared for

National Security Agency

INSTITUTE FOR DEFENSE ANALYSES

1801 N. Beauregard Street, Alexandria, Virginia 22311

DRAFT

1. INTRODUCTION

1.1 PURPOSE

This document proposes new and revised versions of the control objectives contained in
the Trusted Computer System Evaluation Criteria (TCSEC), DoD 5200.28-STD [TCSEC
1985, pp. 57-63]. These modifications extend the existing control objective statements to
encompass the promotion and preservation of data and systems integrity. They are
intended to be used as a strawman to foster further research and debate aimed at
developing a new or revised set of product evaluation criteria that addresses integrity as
well as confidentiality.

1.2 BACKGROUND

Control objectives are the fundamental computer security requirements as they apply to
general purpose automated information systems (AISs). As such, they serve as guidance
to the development of more specific evaluation criteria. Evaluation criteria, in turn, are
intended to ``... (a) provide users with a yardstick with which to assess the degree of
trust that can be placed in computer systems for processing classified or other sensitive
information; (b) provide guidance to manufacturers as to what to build into their new
widely-available trusted commercial products in order to satisfy trust requirements for
sensitive applications; and (c) provide a basis for specifying security requirements in
acquisition specifications'' [TCSEC 1985, p. v].

Given the rather far reaching implications of evaluation criteria, it is vital that such
criteria be built upon a clear and complete foundation. The modified control objectives
presented in this document represent only one step towards that foundation. This step,
directed towards enhancing the set of control objectives to address the needs of integrity,
begins the enabling for the development of new criteria. However, the proposed control
objectives are not intended to be adopted without further research and debate to derive
the best possible foundation for further development work.

1.3 SCOPE

This document extends the integrity framework developed in [Mayfield 1991] and takes
another step in developing and evolving product criteria that include integrity. The
document only addresses control objectives; specific criteria addressing integrity
concerns remain as future work. The document is complementary to other ongoing
research work in the topic of integrity, e.g., the electronic forum for the development of
new formal models of integrity in preparation for The Computer Security Foundations
Workshop IV which was held in Franconia, New Hampshire, 18-20 June 1991. The
document assumes that the control objectives for confidentiality, as contained in the
TCSEC, are adequate for that purpose. Through the study of relevant policies, we have
come to believe that the control objectives need to extend to applications running on a
vendor's system product in order to adequately address boundaries of responsibility
and criteria for implementing protection controls. However, this study concentrates
primarily on control objectives from a systems perspective-the issues involved with
extending the control objectives to applications cannot be explored in depth until a
systems perspective has been established. We do not make use of a particular formal
model of integrity, but rather use some of the concepts developed and modeled by
various model authors to arrive at our specific version of each control objective.

We have purposefully tried to not depart radically from the TCSEC. Our thinking was
that it would be much more beneficial to show minimal changes while increasing
support to various integrity policies than to try and "reinvent the wheel." To some, these
changes may still seem too radical, to others they will be insufficient. We hope that in
both cases our proposals serve to enhance the debate.

The major policy documents, with respect to integrity in AISs, are listed in Table 1.1.
These documents are addressed individually in separate sections in Appendix A. Each
individual section devoted to a particular document contains (a) a brief overview of the
document, (b) a listing of selected source text from the document, (c) a cross-reference
from the source text to affected integrity control objectives, and (d) a commentary
section. The commentary section is, in essence, a set of interpretive notes about control
aspects of the source text. We developed them to partially confirm, from a policy point of
view, what we had discovered in [Mayfield 1991] through an analysis of various
integrity-supporting mechanisms about possible objectives for control.

These government documents provide policy and guidance for controlling and
protecting information. Their contents can be interpreted in at least three distinct ways:
(1) having direct applicability to the certification of an Agency's system as part of the
process of obtaining an accreditation for system operations, (2) having direct
applicability to general application subsystems as evaluated subsystem products, and
(3) having applicability across a wide range of applications wherein the protection
mechanisms might generally provided by the underlying computer system (i.e.,
hardware, operating system, and communications subsystems). While our control
objectives are directed at the third interpretation, the reader will find that we did not
similarly confine our commentary notes on the selected policy text contained in
Appendix A. Our intention in the latter was to take a much broader system perspective
and then selectively use the material in supporting the specific wording of our control
objective proposals.

TABLE 1.1. List of Policy Documents

POLICY DOCUMENT

TITLE

FEDERAL LAWS

Public Law 92-579

The Privacy Act of 1974

Public Law 101-508

Computer Matching and Privacy Protection Amendments of 1990

Public Law 96-511

The Paperwork Reduction Act of 1980

Public Law 97-255

Federal Manager's Financial Integrity Act of 1982

Public Law 97-86

DoD Authorization Act of 1982

Public Law 100-235

Computer Security Act of 1987

EXECUTIVE/LEGISLATIVE

OMB Circular No. A-127

Financial Management Systems

OMB Circular No. A-130

Management of Federal Information Resources

OMB Circular No. A-123

Internal Control Systems

OMB Bulletin No. 90-08

Guidance for Preparation of Security Plans for Federal Computer
Systems that Contain Sensitive Information

OMB IC Guidelines

Internal Control Guidelines

GAO Title II

GAO Policy and Procedures Manual for Guidance of Federal
Agencies-Title 2 - Accounting

DEPARTMENT OF DEFENSE

DoD Directive 5010.38

Internal Management Control Program

DoD Directive 5200.28

Security Requirements for Automated Information Systems

DoD Directive 7740.1

DoD Information Resource Management Program

DoD Guideline 7740.1-G

ADP Internal Control Guideline

DoD Directive 7750.5

Management and Control of Information Requirements

2. PROPOSED CONTROL OBJECTIVES

The proposed control objective revisions contain the following major elements: (1) an
introduction to the control objective, (2) the original and revised control objectives, and
(3) a discussion of issues and rationale for revising the control objective. The discussion
and supporting rationale are intended to be useful whether the original control
objectives are to be modified as we propose, or entirely new control objectives are to be
developed.

When broadening the scope of the TCSEC to include integrity, we must consider the
effect upon the existing control objectives. There are two basic considerations: (1)
whether integrity policies call for additional technical features to be included in the
control statements, and (2) whether the existing abstractions currently associated with
the statements of control are adequate, given the increased scope of protection. Each
factor could have a subsequent effect on the control objective. The requirement for
additional technical features would compel a modification to the control objective itself
and is reflected in the proposed revisions. Generalizing control abstractions would
require a change in the interpretation of the statements of control. These interpretation
changes are noted in the discussion section of each affected revision.

As stated in the TCSEC [1985, p. 71], ``There is a large body of policy laid down in the
form of Regulations, Directives, Office of Management and Budget (OMB) Circulars,

Presidential Executive Orders, and Laws that form the basis for the handling and
processing of Federal information in general and classified information specifically.'' We
follow the TCSEC's example and illustrate the relationship of pertinent integrity policy
to product evaluation criteria using excerpts from Federal laws and Executive,
Legislative, and Department of Defense (DoD) policy documents.

The set of policy statements and guidance that are related to integrity in automated
information systems (AISs) are discussed in Appendix A. The security policy to be
specified for a given system should be derivable from this set of policies in conjunction
with those already cited in the TCSEC. The policy statements of interest originate from
one of three sources: the Federal or Executive branches of government, or the DoD.

Federal law addressing issues of integrity in information processing is best interpreted
not only by examining the Acts of Congress but also their legislative histories, which
aids one in understanding the establishment or modification of law.

The Executive branch of government, in implementing the laws passed by Congress,
issues directives and broad guidance to departments and agencies. The most significant
of these OMB (policy) Circulars are summarized with respect to their effect on integrity.
The General Accounting Office (GAO) is tasked by Congress to provide auditing and
accountability services to the Legislative Branch of Government. In providing such
services GAO issues related guidelines and standards for the Federal government. These
guidelines and standards are cited as references in various policy statements included in
our study, and hence are relevant to those policies of interest.

The DoD has the responsibility for interpreting and implementing the policy issuances
from higher authority. This is done via DoD Directives, regulations, manuals and other
guidance formats. Each of these DoD policy issuances must be interpreted and
implemented by the DoD Components and Agencies.

2.1 SECURITY POLICY

In general, a security policy states what protection controls should be provided in the
administration or operational management of a set of valued resources. A security
policy may define the protection requirements in terms of perceived threats, risks, and/
or goals of an organization. Security policy from the highest levels of Government (e.g.,
Laws and Executive Orders) is put into force through its promulgation in subordinate
Agency or Component implementation directives. Each subsequent level refines the
implementation detail for protection. When these implementation details are carried out,
the policy is enforced. As the general policy statements are refined, the resulting
statements of specific requirements serve to drive product specifications for the design
and operation of policy enforcement mechanisms. Thus, ``a given system can only be
said to be secure with respect to its enforcement of some specific policy'' [TCSEC 1985, p.
59].

2.1.1 Original and Revised Security Policy Control Objectives

Original

A statement of intent with regard to control over access to and dissemination of
information, to be known as the security policy, must be precisely defined and
implemented for each system that is used to process sensitive information. The security
policy must accurately reflect the laws, regulations, and general policies from which it is
derived [TCSEC 1985, p. 59].

Revised

A set of statements of intent with regard to controls over computing resources and
information processing including origination, acquisition, access, use, maintenance,
dissemination, and disposal of information within computer systems, to be known
collectively as the security policy, must be precisely defined and implemented for each
system that is used to process classified and sensitive information. The security policy
must accurately reflect the laws, regulations, and general policies from which it is
derived.

2.1.2 Discussion

Automated information system security policy is a set of statements indicating the
protection controls that should be focused on computing resources and on how
information within computer systems is originated, acquired, accessed, used,
maintained, disseminated, or disposed. The current Security Policy control objective is
limited by the breadth and scope of the laws, regulations, and general policies from
which it is drawn, i.e., non-disclosure of classified and other sensitive information. To
extend the breadth and scope of the TCSEC Security Policy control objective to integrity,
one must first examine the regulations, policies, and/or laws that might be applicable.

Although existing policy [DoD 5200.28-D] states that safeguards for the preservation of
systems and data integrity shall be in place in DoD computers, implementing
regulations and manuals do not precisely define the means for providing these
safeguards. This is in contrast to the uniform system for safeguarding national security
information as prescribed by Executive Order 12356 [EO 12356], which specifically
assigns responsibility to promulgate implementing regulations for confidentiality
protection. This assignment of responsibility has led to well-defined regulations for
protection against unauthorized disclosure, (e.g., [DoD 5200.1-R]). There appear to be no
Executive Orders of equivalent weight and specificity for the direct establishment of
regulations for integrity, and thus regulations applicable to system or data integrity are
not as specific and well-defined.

There are Federal laws and policies which both directly and indirectly address integrity
issues. We assert both as being applicable to integrity protection. They address, in an
overlapping fashion, requirements for automated information security, information and
internal management, and internal controls. These laws and policies are individually
summarized in Appendix A. In addition to current TCSEC policy guidance on
confidentiality, the integrity requirements and guidelines provided by these laws and
policies should be used to shape the detailed security policy into a clear specification of
what must be done to preserve and promote both confidentiality and integrity.

The essence of these laws and policies with respect to information security pertains to
the definitions of sensitive government information and sensitive applications, and the
protection of sensitive information from loss, misuse, unauthorized access, or
modification. Specific to integrity, these laws and policies require that information must
be protected from unauthorized, unanticipated or unintentional modification including
the detection of such activities. Personnel, life support, safety critical and financial
transaction systems are cited as sensitivity examples. The laws and policies define
restrictions on the collection, use, and maintenance of information in Federal AISs,
including timeliness, accuracy, and completeness, and relevance to the agencies needs.
They require appropriate safeguards and individual accountability. The essence of the
laws and policies with respect to information and internal management pertains to the
definition of information and computer resources as assets that must be managed, and to
the establishment of management controls. These management controls include internal
management control procedures, general supervision, input/output and procedural
controls for information processing operations, system administration, information
resource management, training, responsibility assignments, resource allocation, and
vulnerability assessments.

The essence of laws and policies with respect to internal controls pertains to individual
competence, authorization, and accountability; data and application validation; data
completeness, accuracy, and timeliness; and auditability and other procedures to
maintain and to periodically determine the extent of conformance with legal and ethical
standards.

Several Federal laws, along with their implementing policies, mandate action to
preserve and promote data and systems integrity and considerably broaden the scope of
protection requirements over those requirements for confidentiality. The proposed
revision reflects these broader protection requirements by modifying the original TCSEC
version to allow a comprehensive coverage of controls. This modification preserves the
intent of the original objective with respect to control for confidentiality and allows for
the incorporation of additional controls for integrity.

The modification pluralizes the ``statement of intent'' and the term ``control'' to
recognize a wider variety of protection intents and controls and then collectively terms
them ``the security policy.'' Further, it removes the more narrowly focused words
``access to and dissemination of information'' from the original objective statement and
replaces those words with the phrase ``information processing including origination,
acquisition, access, use, maintenance, dissemination, and disposition of information
within computer systems.'' Each of these elements should have a precise statement of
enforcement requirements with the collective statement resulting in a consistent and
complete security policy.

2.2 MANDATORY CONTROL

Mandatory security is based on laws or regulations which establish the rules that must
be enforced and the designations of attributes to be used by these rules. Thus, it is often
referred to as ``rule-based'' security. In the TCSEC, mandatory security refers to the
enforcement of a set of access control rules that constrains an individual's access to
information on the basis of a comparison of attributes that designate an individual's
clearance and/or authorization to the information, the classification and/or sensitivity
designation of the information, and the form of access being mediated. In general,
system enforcement of mandatory policies either requires or can be satisfied by systems
that implement a partial ordering or mathematical lattice of such designations [TCSEC
1985, p. 60].

2.2.1 Original and Revised Mandatory Security Control Objectives

Original

Security policies defined for systems that are used to process classified or other
specifically categorized sensitive information must include provisions for the
enforcement of mandatory access control rules. That is, they must include a set of rules
for controlling access based directly on a comparison of the individual's clearance or
authorization for the information and the classification or sensitivity designation of the
information being sought and indirectly on considerations of physical and other
environmental factors of control. The mandatory access control rules must accurately
reflect the laws, regulations, and general policies from which they are derived.

Revised

Security policies defined for systems that are used to process classified or other
specifically categorized sensitive information must include provisions for the
enforcement of mandatory access control rules. That is, they must include a set of rules
for controlling access based directly on (1) a comparison of the individual`s clearance or
authorization for the information and the classification or sensitivity designation of the
information being sought, and/or (2) a comparison of the duty to be performed with the
duties mapped in the individual's current role, and indirectly on (3) considerations of
physical and other environmental factors of control. The mandatory access control rules
must accurately reflect the laws, regulations, and general policies from which they are
derived.

2.2.2 Discussion

Integrity protection requires that user actions be constrained by mandatory controls
beyond the traditional specification of a sensitivity label and a formal authorization that
form a ``confidentiality'' lattice. These additional constraints will be described in this
discussion.

It is Federal law that any information which could adversely affect the national interest
must be protected from loss, misuse, unauthorized access, and unauthorized
modification [CSA 1987]. It is also Federal law that ``internal accounting and
administrative controls... shall provide reasonable assurances that [resources] are
safeguarded against waste, loss, unauthorized use, or misappropriation'' [FMFIA 1982].
Federal and DoD policy reflect these protection requirements in their implementing
directives. For example, it is Federal policy that resources must be ``protected against
fraud, waste, mismanagement or misappropriation'' [OMB A-123, p. 1].

Separation of duties is a mandatory policy that has been implemented, particularly in
the commercial sector, to address fraud, misuse, etc. Separation of duties also is cited
explicitly as an internal control standard [GAO 1983] and is required in several Federal
and DoD policies. DoD's directive on its internal management control program, [DoD
5010.38-D], in discussing dependencies for internal control, provides rationale for this
mandatory policy. ``Internal control depends largely on the elimination of opportunities
to conceal errors or irregularities. This, in turn, depends on the assignment of work in
such a fashion that no one individual controls all phases of an activity or transaction''
[DoD 5010.38-D, Encl.3]. From this requirement to separate duties or phases of an
activity, we derive the need for implementing the concept of roles. To separate duties,
attributes must be identified that will allow duties to be categorized into different sets.
We define a duty to be an operation on an object, class of objects, or defined system
resource; it provides the binding for objects and operations. Each set of duties is mapped
to a role. Thus, a role is an encapsulation that defines which duties (i.e., manual or
automated operations on particular objects, classes of objects, or system resources) a user
possessing the designation of that role is allowed to perform (invoke). In essence, a role
conveys a ``privilege'' to perform a set of duties; it provides the binding for users,
operation, and objects. Roles aggregate users, duties aggregate objects and their
operations.

Where separation is required, two roles may have partially but not totally overlapping
duties; no single role can encompass all of the duties required to complete a sensitive
activity or transaction. Roles may be assigned as expressly permitted or denied, or they
may be enabled by a sequence of events performed by another role. Once the duties are
divided between different roles, the system or role administrator must ensure that a
single individual is not given multiple roles that would effectively allow that individual
to perform all duties required to process a sensitive transaction. For example, if duties A,
B, and C are required to perform a particular transaction, the system might assign duties
A and B to role 1 and duty C to role 2 to achieve separation of duties. But, in order to
maintain the separation, the system or role administrator must ensure that the same
individual is not assigned to both role 1 and role 2.

Roles must be registered in the system for all operations on objects, classes of objects,
and system resources. Newly created operations cannot be invoked without the
intervention of a system or human administrator to register the operation's associated
roles. Roles assigned to individuals must relate to roles assigned to operations according
to mandatory rules, (e.g., separation of duties must be enforced). These role designations
can provide partial ordering and dominance relations necessary for the mechanics of a
lattice.

DoD policy constrains the concept of separation of duties even further by requiring
``authorized [resource] access and [transaction] execution'' [DoD 5010.38-D, Encl.3].
From this mandatory policy requirement, we derive the joining together of the
(authorized) individual, in a specific role, executing a specified duty (i.e., operation), on
a specific resource (i.e., data object). By combining access to data with separation of
duties, the computer system must implement user-program-data bindings to control
which users can invoke which programs on particular data items. A model for achieving
user-program-data bindings is given in [Clark 1987, 1989]. Our approach is to use roles
and duties as the bindings. Lee [1988] discusses an alternative approach using roles in a
lattice to implement the Clark and Wilson model.

Mandatory controls address more than access control, they also address information
flow. Where the integrity issue of ``contamination'' of high quality information with low
quality information from low quality sources is a mandatory concern, the ability to
attribute subjects and objects with a designated quality grade will be required. Biba
[1977], in his integrity model, introduced the term integrity grade to designate
gradations of quality for subjects and objects. In essence, an integrity grade is a
determination of a subject or object's quality with respect to a defined standard. In this
respect, such a grade can be thought of as analogous to a classification or a sensitivity
label in the DoD scheme. These integrity designations also would provide partial
ordering and dominance relations necessary for the mechanics of a lattice structure.

DoD requirements for integrity grades for subjects are derivable from the statement that
``managers and employees shall have personal and professional integrity and shall
maintain a level of competence that allows them to accomplish their assigned duties...''
[DoD 5010.38-D, Encl.3]. This ``competency'' requirement implies some specific standard
of quality associated with an individual (e.g., a level of professional maturity). It further
implies that individuals not meeting a certain level of quality should not be allowed to
perform certain duties, because they may lack competence to successfully accomplish
such duties. Thus, we derive a mandatory requirement to characterize individuals, in
conjunction with their role specification, with a level of quality that reflects their ability
to carry out specified duties (e.g., apprentice, journeyman, master, supervisor).

Integrity grades for objects are not always directly derivable from formal standards or
policy, but often can be derived from experience. Here, we are concerned with attributes
of information that indicate the information's ``maturity'' (e.g., initial, preliminary, and
final versions) that convey a degree of effort placed into developing the information and
the results of that effort to a subjective or objective standard. In this case, the idea of
maturity recognizes that earlier versions of information may not have as high a
``quality'' as later versions. Similar attributes, some with specific standards such as
precision, accuracy, etc., can be addressed under the rubric of information quality.

Where contamination is an issue, a specific set of information flow rules must be
established. For example, a rule based on the competency of individuals might state that
information entered by an expert cannot be modified by a novice. A rule based on the
maturity of information (e.g., unedited version vs. final product version) might state that
the ``quality'' of the information increases only by progressing the information through
specific events (e.g., editing and formal review). It is through this event progression that
the effort put into the information's development is seen to produce measurable results
(e.g., edited and approved versions). As a further requirement, the information maturity
rule might state that a proper sequence of such events must be followed. To be
enforceable, these potential mandatory quality rules will require some form of integrity
grade designation implementation. The standards for such integrity designation
requirements have not been developed for widespread use, and attributing subjects and
objects with gradation designations may not be as straightforward for integrity policies
as was the case for confidentiality policies.

The additional comparisons added to the mandatory controls are seen to be vital in
preserving the integrity of systems and data. With these comparisons, we recognize that
there are at least two levels of mandatory control. The first level provides a reference
monitor which is invoked to meet the requirements of preventing disclosures of
classified information and/or preventing contamination of high quality information
with low quality information. Notice that although the same wording used in the
original control objective has been used in (1), it is interpreted to imply the extension of
integrity grades to prevent contamination. The second level provides mandatory
indirection between a user and system resources to enforce separation of duty as well as
control of object execution, modification, or manipulation. This second level of
mandatory control extends the notion of a reference monitor provided by the first level,
and provides more discrete control by binding the user authorization to a particular
action upon a particular object.

2.3 DISCRETIONARY CONTROL

The concept of discretionary control extends from the principle of ownership, providing
for user-controlled sharing that promotes the maximum efficiency of system data and
resource administration while retaining protection effectiveness. Efficiency is gained by
reducing central system administration and effectiveness is maintained by bounding an
individual's discretion. Thus, discretionary control is the administration of data and
resources by individuals who are provided with a set of explicit and/or implicit
privileges to operate on sets of those data and resources, and with the ability to grant or
deny (at their discretion) privileges for the data and resources under their control to
other individuals. Because it is related to explicitly identifying individuals, this form of
control often is termed identity-based control. The original Discretionary Security
control objective was derived from DoD confidentiality policy requiring each individual,
in addition to being cleared for access, to also have been determined by a competent
authority to have a need-to-know for particular items of information for the
performance of that individual's job. The concepts and mechanisms developed
originally to implement controlled sharing were employed to enforce need-to-know.

2.3.1 Original and Revised Discretionary Security Control Objectives

Original

Security policies defined for systems that are used to process classified or other sensitive
information must include provisions for the enforcement of discretionary access control
rules. That is, they must include a consistent set of rules for controlling and limiting
access based on identified individuals who have been determined to have a need-to-
know for the information [TCSEC 1985, p. 61].

Revised

Security policies defined for systems that are used to process classified or other sensitive
information must include provisions for the enforcement of discretionary control rules.
That is, they must include a consistent set of rules for controlling and limiting (1) access
based on identified individuals who have been determined to have a need-to-know for
the information, and (2) execution of duties based on identified roles and individuals
who have been determined to have a need-to-perform those duties.

2.3.2 Discussion

The wording of the existing control objective reflects its original focus. The term ``need-
to-know'' is relevant only to confidentiality, and has no essential bearing in terms of
integrity policies. It can be argued that beyond this single instance, the wording of the
existing control objective is general enough to apply to integrity protection. However,
although the term ``access'' is currently interpreted in the general sense for AIS security
[NCSC 1988, p. 3], in many regulations its meaning is strictly limited to confidentiality.
Examples of more narrow usage can be found in [DoD 5200.1-R] and the Privacy Act of
1974 [PA 1974]. Still, if the over-specificity of its terms were its only deficiency, the
existing control objective could serve the purposes of integrity with relatively minor
changes.

The restricted scope of the existing control objective also results in a more fundamental
flaw when considering integrity protection at a purely functional level. Because integrity
protection is concerned with the flow of information into an object, ``proper''
modifications can only be defined in terms of the particular code segment (e.g.,
program) which performs a modification. In particular, the code which manipulates an
object must do so by adhering to the object's format, at a minimum. Because functional
concerns require the binding of particular code to a particular object or class of objects
for integrity protection, it follows that ``privileges'' should not allow a less restrictive
binding. The generality implied by ``controlling and limiting access to... information,'' is
simply insufficient to convey the required degree of protection. This concept is
expressed through the definition of a duty, as discussed in Section 2.2.2, under
Mandatory Control.

One needs to consider the differences between the basic concerns of confidentiality and
integrity to understand why this additional degree of control is required. Confidentiality
protection is concerned with preventing the unauthorized flow of information from one
object to another. This flow is characterized essentially by one class of operation
performed by a system (i.e., ``read''). In terms of information flow, each and every
``read'' operation can be considered equivalent. Such a simplification is not possible for
integrity protection. The inward-directed information flow is, similar to confidentiality,
characterized by a single class of operation (i.e., ``write''). However, in contrast to the
apparent equivalence of all read operations, write operations are distinguished by the
context in which they are performed. For example, two programs, each performing a
series of write operations upon an object, may produce entirely different effects in terms
of the object's integrity. In this regard a ``write'' privilege, in giving a user the right to
modify an object in a very general manner, does not provide the correct level of
abstraction in specifying privileges in terms of integrity protection.

A relationship between mandatory and discretionary controls has been assumed in the
preceding discussion: the rules specifying what is allowable under mandatory controls
are expressed at the same level of abstraction at which discretionary controls are
applied. For instance, the Bell-La Padula model definition of allowable operations for
both mandatory and discretionary controls are equivalent sets (i.e., read, write, and
execute operations) [Bell 1975]. It should not be assumed that this equivalence relation
must always be present. It is possible for discretionary controls to exist in the absence of
mandatory controls. In such a case, an equivalence relation is neither possible nor
necessary. The converse case, where mandatory controls exist in the absence of
discretionary controls, is not explicitly excluded by the original TCSEC control
objectives, although it is excluded in the actual Criteria. However, it is likely that this
converse case may be more acceptable in practice for integrity protection than for
confidentiality protection, and subsequent evaluation criteria should address such a
possibility. In addition, we assert that whenever both mandatory and discretionary
protection is provided by a system, there must be an equivalence relation between
mandatory and discretionary control abstractions.

A consequence of this relationship is the complementary role in which mandatory and
discretionary controls provide comprehensive protection. If ``privileges'' are expressed
using identical abstractions, mandatory controls can enforce the context in which a
privilege is valid, while discretionary controls imply the permission to exercise the
privilege, given a valid context. One way of looking at this relationship is that
mandatory controls specify what is potentially allowed, while discretionary controls
specify what is intentionally allowed. The two sets of controls are complementary in that
access is dependent upon passing both mandatory and discretionary tests. This
complementing property can only exist if the operational classes at both the mandatory
and discretionary levels are equivalent, as discussed above. We assume that such a
complementing property between mandatory and discretionary controls for integrity
protection would be desirable, as has been the case for confidentiality protection. We
have discussed under the Mandatory Control (Section 2.2.2) the basic abstractions,
defined as roles and duties, which capture the necessary elements for integrity
protection.

Bacic [1989], in addressing integrity as set forth in the Clark and Wilson Model [Clark
1987], suggests that discretionary controls for integrity are user-defined execution
controls. Bacic notes that these discretionary controls operate at the user level, provide
access only to executable objects, and are confined to a set of duties (i.e., the role) for an
individual as prescribed by mandatory controls. Bacic's discretionary execution controls
(DECs) complement his mandatory execution controls (MECs) and can be viewed as a
logical extension of discretionary access controls. They relate a user to a set of processes
(e.g., a program) that fulfills a set of duties which can only execute on particular sets of
data objects. We find that integrity protection can be provided only by addressing
discretionary concerns at these (more complex) levels of specification and abstraction.
However implemented, execution controls essentially define roles. As such, the
proposed control objective addresses the appropriate relationship between roles and
duties for discretionary integrity protection with the term ``need-to-perform.''

In addition to proposing changes to the existing control objective, we need to examine
the traditional abstractions associated with discretionary controls, in order to interpret
the subject in the context of integrity protection. The distinguishing feature of existing
discretionary controls is the capability they provide to allow an individual to control
access to resources, based on a ``principle of ownership.'' An ``owner'' (often the creator)
of a resource possesses a set of privileges over that resource, of which each may be
granted explicitly to other users. In some implementations, the ``grant'' privilege itself
may be conveyed to other users, either for singular privileges or for the entire set of
privileges inherent to the owner.

The principle of ownership must be generalized for integrity protection to embody role
administration. The administrator of a set of resources should not have the privileges
that the analogous ``owner'' of property has; rather, ownership should be considered a
special case of administration. The definitions for sensitive data and sensitive
application found in [OMB A-130, p. 52742] imply that an individual creating, using, or
maintaining sensitive resources should have strictly limited administrative rights to
those resources. For example, a user creating an object associated with sensitive
information or a sensitive application should not necessarily have the ability to destroy
that object at the user's discretion. Therefore, an AIS should support the ability to restrict
the set of default privileges associated with the administration of resources, on a per-
application basis. Additionally, an AIS should support the ability to designate
individuals (other than the creator) as having discretionary administrative control over a
particular resource or set of resources.

Similarly, an administrator of a set of resources should not, in general, be able to grant
privileges to other entities simply because he possesses such privileges. In other cases, it
may be appropriate for an administrative user to grant certain privileges to other users
which are unavailable to the administrator. This issue is related to a broader area of
concern: the control over propagation of privileges. A user receiving access to a resource
via discretionary controls should not, in general, be able to arbitrarily pass that privilege
on to other entities, nor to amplify the privilege in any way. Therefore, an AIS should
support measures to arbitrarily define which discretionary privileges are ``grantable''
and provide a means to prevent the (undesired) propagation of privileges, on a case-by-
case basis (i.e., per application).

These discretionary issues must be addressed through use of the same abstraction(s) in
which mandatory controls are expressed (i.e., roles). The role-implementing features of a
system must therefore address three different areas of functionality. The first area is the
definition of roles with respect to a set of processing resources. This set of resources can
be described as the domain to which the defined roles are applicable. The definition of
roles within a domain is an administrative function associated with mandatory policies.
Also, this definition must include the specification of which users are authorized to
operate within the defined domain. The second area which must be addressed is the
discretionary administration of the system-defined roles. Conceptually, this area
implements the ``ownership'' of roles, under which domain-specific roles can be
allocated or assigned. The third area which must be provided by the system is the
binding of a subject (i.e., a user-process pair) to only those actions defined by its
operational role.

Note that together these three areas of functionality provide an equivalence set between
mandatory and discretionary controls to provide complementary protection
mechanisms. The mandatory specification defines which resources, roles, and
individuals are available, and who has discretionary control over the assignment of
roles. The ``owner'' or role administrator of the domain assigns roles and resources to
individuals. For a user to operate within a role, that user must be specified through the
mandatory definition as being allowed to operate within that domain, and be assigned a
role and resources by the ``owner'' of the domain.

Clark and Wilson [Clark 1987, 1989] provide a set of extended access controls which
address some of the deficiencies associated with the traditional notion of discretionary
controls in providing integrity protection. In their model, access control is specified (via
``triples'') in terms of controlling accesses by identifiable segments of code (i.e., the
``transformation procedure'' or TP) to specified objects. This additional restriction is
similar to the type enforcement mechanisms of certain programming languages,
although it is applied at the system level. Thus, this feature of the model can be
considered to involve a finer specificity of control than contained in traditional DAC.
However, the notion of ``discretion'' in [Clark 1989] is distinct in that there is no explicit
mechanism by which (non-administrative) users can transfer privileges to others.
Although the concept of ``triples'' is identity based, triples are not discretionary but are,
in fact, mandatory.

This is not to say that extensions to the Clark and Wilson model could not address
discretion access controls, however. The set of all triples which apply to particular user-
object pairs is conceptually similar to our notion of a role definition.1 One can
hypothesize a privilege-granting TP in which the object acted upon is the specification of
privileges (i.e., a set of triples) for some other object. The triple specifying such a
privilege-granting TP would give the specified user the ability to control access to
particular objects under that user's administration, similar to the ability of owners to
alter an access control list in

----------------------------

1. Roles, for different implementations, might also be interpreted as either the set of
triples associated with a single object or those associated with a single user.

----------------------------

more traditional models. Thus, any particular subject may be an ``administrator'' with
respect to an arbitrary set of objects. This administrative user need not be privileged
with respect to the system, nor to other resources outside a particular administrative
domain. It may also be possible to construct arbitrary, discretionary control domains
(e.g., hierarchical, independent, or overlapping), while retaining the beneficial
extensions offered in the original Clark and Wilson model.

The proposed control objective revision recognizes that discretionary controls in support
of data and systems integrity require extensions to traditional access control.
Specifically, they require the ability of the user to specify-and the system to test for-the
identity and authorization of an individual and that individual's role, as well as specific
duties within the role that specify the functionality associated with the access. In essence,
the integrity revision constrains discretionary control to user operations on executable
objects. The term ``need-to-perform'' is intended to capture this essence of discretionary
control with respect to integrity, as discussed in the previous review of [Bacic 1989].
Such controls necessarily would be further constrained by mandatory controls.

2.4 MARKING CONTROL

Marking is the concept of designating or providing information attributes, (e.g.,
classification or sensitivity), each having a specified range of values, that can be used in
rule-based mechanisms to implement mandatory security policies. A clear implication of
mandatory controls is that the system must assure that the mandatory security
designations cannot be arbitrarily changed since such changes could permit individuals
to access information in unauthorized ways.

Marking control is necessary to ensure accurate and consistent internal rule-based
decision making and also necessary to ensure that, when the information is transformed
to an external representation, the marking conveys how the information is to be handled
in the external world. Since these attribute values, or labels, are key to decision making,
it is important that they remain essentially stable. Labels should be created and
maintained by the system, or installed and maintained by specified systems
administrators, and only changed in a well-defined manner so that a label continues to
be consistent with the sensitivity of the information that the label represents.

2.4.1 Original and Revised Marking Control Objectives

Original

Systems that are designed to enforce mandatory security policy must store and preserve
the integrity of classification or other sensitivity labels for all information. Labels
exported from the system must be accurate representations of the corresponding
internal sensitivity labels being exported [TCSEC 1985, p. 61].

Revised

Systems that are designed to enforce mandatory security policy must store and preserve
the integrity of classification, other sensitivity, or integrity labels for all information. The
labeling must be sufficient to implement rule-based checking of mandatory linkages
between subjects, data, and operations upon the data as required by the mandatory
control objective. Labels exported from the system must be accurate representations of
the corresponding internal labels being exported.

2.4.2 Discussion

Identification of attributes used in mandatory rule-based decisions are key to marking
requirements. Many of these attributes may be developed in the context of an
application rather than at the operating system level. It is important that the overall
protection system maintain the integrity of any labels required by the marking policy
even if the labels are developed at the application level.

The marking policy and specific marking requirements for handling classified
information to prevent unauthorized disclosure are well covered in the TCSEC.
Numerous policy documents are cited in the TCSEC with clear confidentiality marking
requirements. There are no similar ``clear'' statements in policy to convey the marking
requirements for integrity.

Given the integrity constraints described under the proposed mandatory control
objective, we can now derive marking requirements for integrity. From the mandatory
requirement for separation of duties, we derived the need to identify within the system a
set of roles, each with a unique set of duties. Roles themselves can be used as marking
designations, as can the duties they encapsulate. Each duty is mapped to specific system
operations on objects and resources. At some level of abstraction, separated duties may
be identified as either ``enabling'' or ``completing'' functions [Guttman 1991], and the
same individual should not have the ability to perform both in the same role. This
constraint may imply the requirement that certain objects carry an ``enabled'' label.

From the mandatory requirement to join together an individual, in a specific role,
executing a specified program on a specific data set, we derived the need to effectively
implement user-program-data bindings. Here, the options may be to use some variation
of Clark and Wilson ``triples'' [Clark 1987]. Variations could include labeling each
system operation with the set of roles established for manipulating the specified data set
(e.g., use of abstract data types (ADTs)), with each individual user or process being
linked to a specified set of ADTs. This set of rules acts as an access control list (ACL)
such that each individual user or process gains access only to specified operations. For
finer granularity, the set of roles also could be used as labels on individual data items
with the user or process gaining access to a specified operation on the specified date item
only if the user or process role matched a role on the data item's list of roles.

To prevent the contamination of high quality information with low quality information,
we derive a requirement to mark subjects (in conjunction with the use of roles) and
objects with a level of quality, or integrity grade. For subjects, the integrity grade should
reflect an individual's ability to carry out specified duties (e.g., apprentice, journeyman,
master, supervisor). For objects, the integrity grade should reflect the data's quality (e.g.,
initial draft, preliminary strawman, final prototype, final finished product). Such terms
again indicate a level of quality, maturity, or competence against some objective or
subjective standard.

The marking changes extend labeling to integrity attributes of information and require
labels to support the mandatory integrity linkages (i.e., separation of duties, user
program data bindings, and integrity grades) made in the mandatory control objective.

2.5 ACCOUNTABILITY CONTROL

The concept of holding an individual accountable for his actions is fundamental to
policy enforcement. Accountability can be defined, traditionally, as ``the property that
enables activities on a system to be traced to individuals who may then be held
responsible for their actions'' [NCSC 1988, p. 4]. The concept requires the ability to
continuously identify individuals with their actions and with those of their surrogates
within the system. To be effective, mandatory and discretionary security policies are
dependent upon a system's ability to adequately identify, authenticate, maintain
individuation, and account for those individuals to which access controls are applied.
The ability to record and review the (system-related) actions of individuals provides (1)
a deterrent to malicious actions, (2) a means to detect malicious actions or attempts, and
(3) the ability to undertake preventive measures when attacks are detected. Thus, the
concept further requires that a history of an individual's actions and the system's
reactions be continuously maintained and protected from unauthorized manipulation
for real-time or subsequent use in auditing analyses.

2.5.1 Original and Revised Accountability Control Objectives

Original

Systems that are used to process or handle classified or other sensitive information must
assure individual accountability whenever either a mandatory or discretionary security
policy is invoked. Furthermore, to assure accountability, the capability must exist for an
authorized and competent agent to access and evaluate accountability information by a
secure means, within a reasonable amount of time, and without undue difficulty
[TCSEC 1985, p. 62].

Revised

Systems that are used to process or handle classified or other sensitive information must
assure individual accountability whenever either a mandatory or discretionary security
policy is invoked. Systems must assure that the accountability for individual
performance of duties can be determined through an independent consistency check
between internal representations of information within the system and the external
information being represented. Systems must maintain the required degree of logical
consistency for duplicate, identically derived, and/or corresponding internal instances
of the same information throughout the existence of such information on the system.
Furthermore, to assure individual accountability, the capability must exist for an
authorized and competent agent to access and evaluate accountability information by a
secure means, within a reasonable amount of time, and without undue difficulty.

2.5.2 Discussion

It is the policy of the U.S. Government that agencies ``shall establish and maintain a cost-
effective system of internal controls to provide reasonable assurance that Government
resources are protected against fraud, waste, mismanagement, or misappropriation...''
[OMB A-123, p. 1].

DoD policy requires that each DoD component maintain accountability over their assets
and that they implement a comprehensive system for internal management control that
provides reasonable assurance: obligations and costs comply with applicable law; assets
are safeguarded against waste, loss, unauthorized use, and misappropriation; revenues
and expenditures applicable to DoD operations are recorded and accounted for properly
[DoD 5010.38-D, pp. 1-2].

AIS internal control is defined within DoD guidelines as ``the steps taken... and all the
methods and techniques used to safeguard AIS resources and provide reasonable
assurance of the accuracy and reliability of computer-based input, processing and
output; ensure the adherence to applicable laws, regulations and policies; and promote
the effectiveness, efficiency and economy of AIS operations and systems'' [DoD 7740.1-
G, p. 1-4]. The DoD guidelines include the following specific forms of application
control: authorized transactions, valid transactions, complete information, accurate
information, timely information, secure system and data, and auditable system.

Accountability is fundamental to internal control and, as such, is a vital aspect of
promoting and preserving systems and data integrity. Internal control adds another
dimension to accountability, the application dimension.

The TCSEC's original control objective appears sufficiently general to include the
specific requirements for integrity with respect to user activity on a system. However,
there is no stipulation for the assignment of responsibility for actions which need to be
performed and yet are not properly carried out. This ``deficiency'' of action may affect,
most characteristically, the internal and external consistency of the information
maintained by a system. In many applications, the concept of accountability may require
the synchronized comparison of internal information states with the external world the
information represents.

As a result of this increase in scope for accountability, additional functionality will be
required of systems conforming to this new control requirement. It would no longer be
enough for a system to passively monitor and record user access activity, and provide
the means to adequately review user access activity information. Instead, a system
would need to be able to enforce authorized actions with respect to ``valid'' objects,
where an object's validity is determined through some measure of its internal and
external consistency. This implies that a system would need to (1) define, specify, and
enforce valid state transitions for objects, or (2) dynamically validate an object's state.

Both of these notions are presented by Clark and Wilson in [Clark 1987]. In their
notation, an Integrity Verification Procedure (IVP) performs a dynamic check to
determine whether objects controlled under the system's integrity policy conform to its
specification, and a TP guarantees valid state-to-state transitions for controlled objects.
Thus, an IVP may verify that an object accurately reflects the current status of an
inventory item (external consistency), and a TP may guarantee that all copies of a
particular object are updated concurrently (internal consistency). Individuals are
directly linked to the execution of a TP or an IVP on a specific set of data.

The proposed changes to this control objective reflect an extension to traditional scope of
accountability. This revision is driven by internal management control policy
requirements which outline the need for application controls including the proper
correspondence between external information and the representation of that information
on a system (i.e., data). In essence, this correspondence cannot occur without the proper
recording of this external information and adequate reviewing procedures to verify that
system data is accurate. These procedures are at least partially external to the system,
and thus are best described as ``accountability'' control. Additionally, the individual's or
system's initiation, use, and maintenance of duplicate or redundant data raise integrity
issues with respect to accuracy, timeliness, and the effect of those attributes on the
internal (logical) representations of information. The procedures to properly constrain
these actions are policy driven and are, therefore, subject to accountability controls.

2.6 ASSURANCE CONTROL OBJECTIVE

The concept of assurance is concerned with the measures taken to guarantee that the
implementation of protection features is correct and that it properly enforces security
policies. A consideration for ``proper enforcement'' is whether the protection features
accomplish what they are designed to do, but nothing else (i.e., there are no unspecified
features implemented). The TCSEC defines two types of required assurance: life cycle
and operational. Life-cycle assurance deals with the management of system design,
development, and maintenance. In essence, lifecycle assurance provides confidence that
a system's protection features are themselves protected from attack throughout the
lifetime of the system. Life-cycle assurance includes the control of design changes and
the effect changes may have in enforcement of the defined security policies. Operational
assurance ``focuses on features and system architecture used to ensure that the security
policy is uncircumventably enforced during system operation'' [TCSEC 1985, p. 63].

2.6.1 Original and Revised Assurance Control Objectives

Original

Systems that are used to process or handle classified or other sensitive information must
be designed to guarantee correct and accurate interpretation of the security policy and
must not distort the intent of that policy. Assurance must be provided that correct
implementation and operation of the policy exists throughout the system's life-cycle
[TCSEC 1985, p. 63].

Revised

Systems that are used to pro cess or handle classified or other sensitive information must
be designed to guarantee correct and accurate interpretation of the security policies and
must not distort the intent of those policies. Assurance must be provided that correct
implementation and operation of the policy exists throughout the system's life-cycle.
Application subsystems used to process or handle classified or other sensitive
information must be designed, implemented, controlled, and operated in a manner
which provides assurance that the goals of both application-specific security policies and
system-wide security policies are met without circumvention.

2.6.2 Discussion

Although this control objective is sufficiently general to include the specific
requirements for integrity, it should be noted that integrity requirements may have a
different emphasis than confidentiality requirements. Because integrity dependencies
are more likely to be domain specific as opposed to system wide, the development and
introduction of any new application dealing with a particular (sensitive) data set will
need to be tightly controlled. The ``correct implementation and operation'' concerns
most likely will be interpretable primarily in the domain of the application. Thus,
assurance control needs to be extended from the current systems domain to each specific
application domain resident on the system.

The proposed assurance control objective recognizes that there exists the possibility of
multiple, application-specific security policies which may apply only to particular
subsets of resources within the system. Software residing within a particular application
domain should only extend the degree of control over resources, and should in no
manner nullify the degree of control required for all system resources or for resources
within a different application domain. Assurance must be provided that application and
system software meets the security policy objectives for both the system and the
application. The ``adequacy'' of this assurance must be determined strictly in terms of
the sensitivity of the application and resources within that domain.

2.7 FAULT TOLERANCE CONTROL

The concept of fault tolerance extends from the need to continue operations in the
presence of faults. As there are no guarantees of the absence of some form of fault, risk
reduction becomes the focus of this control. Tolerance is established through a robust
ability to detect and correct faults, and through a risk analysis that enables the setting of
thresholds to maintain an acceptable degree of processing robustness in degraded
operational modes.

Increasing complexity of systems yields an increase in the number of potential failure
points and places a greater demand for fault tolerant system implementations. Electronic
parts fail, waveforms get scrambled, magnetic properties of media deteriorate, etc. With
more complex computers being incorporated into more complex commercial and
military aircraft flight control systems, industrial controllers, space applications,
banking systems, etc., erroneous computer performance can be devastating to financial
records, environmental safety, national security, and even human life. Therefore, when
faced with potential failures in complex systems, fault tolerance plays an important part
in maintaining data and systems integrity.

2.7.1 Original and Revised Fault Tolerance Control Objectives

Original

[There is no original control objective for fault tolerance contained in the TCSEC.]

Revised

Systems that support safety or mission-critical applications must provide measures to
promote continued safe or correct operation, within defined tolerances, in the presence
of integrity failures. Systems must include provisions for detecting integrity failures,
even if those failures cannot be corrected, and provisions for correcting integrity failures
when possible. System designs must include provisions for identifying and classifying
potential integrity failures, determining the likelihood of such failures, and possible
outcomes of such failures.

2.7.2 Discussion

Fault tolerance essentially 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.

The second part of fault tolerance is the attempted correction of errors. 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 to compare these
when determining whether the data integrity has been violated. This approach 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.

Applying the concept of fault tolerance is commonly associated with redundant
processing. Redundancy in computer systems is a risk-reducing concept that involves
the duplication of hardware, software, information, time, or other resources to detect the
failure of a single duplicate component and to continue to obtain correct results despite
the failure [Johnson 1989]. 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.

In some situations, it is sufficient to shut down a system when a failure occurs and is
detected. This solution is not very efficient, but it may be the safest solution and at least
it eliminates incorrect operations by the system. In many other situations, however, it is
more important that the system continue to operate, even if the performance is
degraded. For example, it may be more important for communications to continue
during a time of war, even if many of the transmissions have to be ignored due to static,
jamming, etc. In addition, it is important to ensure that safety or mission-critical
applications that are time sensitive are guaranteed to execute within their time
limitations. For example, an order to ``attack at dawn'' is not useful if it is not delivered
until the next afternoon.

Systems that support safety or mission-critical applications must not only preserve
integrity to the extent possible, but also must continue to operate in a safe or correct
manner in the presence of integrity failures that result from unavoidable situations, such
as physical failures of equipment or media. Fault tolerance requirements define what is
meant by safe or correct operation, and the level of redundancy will vary depending on
these requirements. The system must detect when a failure has occurred before it can
take any action. Once a failure is detected, there may be enough redundancy for correct
operation to continue or it may be necessary to take action to correct the failure.

REFERENCE LIST

[1] Bacic 1989 - Bacic, E.M. 1989. Process Execution Controls as a Method for Ensuring
Integrity. In Report of the Invitational Workshop on Data Integrity, January 25-27,
1989, Gaithersburg, Maryland, B.2-1B.2-8. Gaithersburg, MD: National Institute of Stan-
dards and Technology. NIST Special Publication 500-168.

[2] Bell 1975 - Bell, D. and L. La Padula. 1975. Secure Computer System: Unified Exposi-
tion and Multics Interpretation. Bedford, MA: MITRE Corporation. MITRE Technical
Report 2997.

[3] Biba 1977 - Biba, K.J. 1977. Integrity Considerations for Secure Computer Systems.
Bedford, MA: MITRE Corporation. MITRE Technical Report 3135.

[4] Clark 1987 - Clark, D.D. and D.R. Wilson. 1987. A Comparison of Commercial and
Military Computer Security Policies. Proceedings of the IEEE Symposium on Security
and Privacy, April 27-29, Oakland, California, 184-194. Washington, D.C.: IEEE Com-
puter Society Press.

[5] Clark 1989 - Clark, D.D. and D.R. Wilson. 1989. Evolution of a Model for Computer In-
tegrity. In Report of the Invitational Workshop on Data Integrity, January 25-27, 1989,
Gaithersburg, Maryland, A.2-1A.2-13. Gaithersburg, MD: National Institute of Stan-
dards and Technology.

[6] CMPPA 1990 - U.S. Congress. Computer Matching and Privacy Protection Amend-
ments of 1990. Public Law 101-508. November 5, 1990. Washington, D.C.: U.S. Gov-
ernment Printing Service.

[7] CSA 1987 - U.S. Congress. House. Computer Security Act of 1987. Public Law 100-
235. January 8, 1988. H. R. 145. Washington, D.C.: U.S. Government Printing Service.

[8] DoD 5200.1-R - Department of Defense. 1986. Information Security Program Regula-
tion. DoD Regulation 5200.1-R. Washington, D.C.: U.S. Government Printing Office.

[9] DoD 5200.28-D - Department of Defense. 1988. Security Requirements for Automated
Information Systems (AISs). DoD Directive 5200.28-D. Washington, D.C.: U.S. Govern-
ment Printing Office.

[10] DoD 5200.28-M - Department of Defense. 1973. ADP Security Manual. DoD Manual
5200.28-M. Washington, D.C.: U.S. Government Printing Office.

[11] DoD 5010.38-D - Department of Defense. 14 April 1987. Internal Management Control
Program. DoD Directive 5010.38-D. Washington, D.C.: U.S. Government Printing Of-
fice.

[12] DoD 7740.1-D - Department of Defense. 20 June 1983. DoD Information Resources
Management Program. DoD Directive 7740.1-D. Washington, D.C.: U.S. Government
Printing Office.

[13] DoD 7740.1-G - Department of Defense. Office of the Assistant Secretary of Defense
(Comptroller). July 1988. ADP Internal Control Guideline. DoD Guideline 7740.1-G.
Washington, D.C.: U.S. Government Printing Office.

[14] DoD 7750.5-D - Department of Defense. 7 August 1986. Management and Control of In-
formation Requirements. DoD Directive 7750.1-D. Washington, D.C.: U.S. Government
Printing Office.

[15] DoDAA 1982 - U.S. Congress. Senate. Department of Defense Authorization Act, 1982.
Public Law 97-86. December 1, 1981. S. 815. Washington, D.C.: U.S. Government
Printing Service.

[16] EO 12356 - The White House. 2 April 1982. National Security Information. Executive
Order 12356. Washington, D.C.: U.S. Government Printing Office.

[17] FMFIA 1982 - U.S. Congress. House. Federal Managers' Financial Integrity Act of
1982. Public Law 97-255. September 8, 1982. H. R. 1526. Washington, D.C.: U.S. Gov-
ernment Printing Service.

[18] GAO 1983 - Government Accounting Office. 1 June 1983. Office of the Comptroller.
Standards for Internal Control in the Federal Government. Washington, D.C.: U.S. Gov-
ernment Printing Office.

[19] GAO Title 2 - Government Accounting Office. August 1987 (Revised May 1988). Of-
fice of Policy. GAO Policy and Procedures Manual for Guidance of Federal Agencies-
Title 2, Accounting. Washington, D.C.: U.S. Government Printing Office.

[20] Guttman 1991 - Guttman, Joshua. 4 March 1991. Private communication with authors.

[21] H. Rept. 100-153(I) - U.S. Congress. House. Committee on Science, Space, and Technol-
ogy. Legislative History of the Computer Security Act of 1987. June 11, 1987. House
Report No. 100-153(I). Washington, D.C.: U.S. Government Printing Service.

[22] Johnson 1989 - Johnson, Barry W. 1989. Design and Analysis of Fault-Tolerant Digital
Systems. Reading, MA: Addison-Wesley.

[23] Lee 1988 - Lee, Theodore M.P. 1988. Using Mandatory Integrity to Enforce ``Commer-
cial'' Security. In Proceedings of the IEEE Symposium on Security and Privacy, April
18-21, 1988, Oakland, California, 140-146. Washington, D.C.: IEEE Computer Society
Press.

[24] Mayfield 1991 - Mayfield, Terry, J. Eric Roskos, John M. Boone, Stephen R. Welke,
and Catherine W. McDonald. 1991. Integrity in Automated Information Systems. Alex-
andria, VA: Institute for Defense Analyses. IDA Paper P-2316.

[25] NCSC 1988 - National Computer Security Center (NCSC). 1988. Glossary of Computer
Security Terms. Washington, D.C.: U.S. Government Printing Office.

[26] OMB 1991 - Office of Management and Budget. 4 March 1991. ``Advance Notice of
Plans for Revision of OMB Circular A-130,'' in the Federal Register, Vol. 56, No. 42.,
pp. 9026-9028. Washington D.C.: U.S. Government Printing Office.

[27] OMB ICG - Office of Management and Budget. December 1982. Internal Control Guide-
lines: Guidelines for the Evaluation and Improvement of and Reporting on Internal Con-
trol Systems in the Federal Government. Washington, D.C.: U.S. Government Printing
Office.

[28] OMB 90-08 - Office of Management and Budget. 9 July 1990. Guidance for Preparation
of Security Plans for Federal Computer Systems That Contain Sensitive Information.
OMB Bulletin No. 90-08. Washington, D.C.: U.S. Government Printing Service.

[29] OMB A-123 - Office of Management and Budget. 4 August 1986. OMB Circular No. A-
123, Revised. Internal Control Systems. Washington, D.C.: U.S. Government Printing
Service.

[30] OMB A-127 - Office of Management and Budget. 19 December 1984. OMB Circular
No. A-127. Financial Management Systems. Washington, D.C.: U.S. Government Print-
ing Service.

[31] OMB A-130 - Office of Management and Budget. 12 December 1985. OMB Circular
No. A-130. Management of Federal Information, in the Federal Register, Vol. 50, No.
247. Washington D.C.: U.S. Government Printing Office.

[32] PA 1974 - U.S. Congress. Senate. Privacy Act of 1974. Public Law 92-579. S. 3418.
Washington, D.C.: U.S. Government Printing Service.

[33] PRA 1980 - U.S. Congress. House. Paperwork Reduction Act of 1980. Public Law 96-
511. December 11, 1980. H. R. 6410. Washington, D.C.: U.S. Government Printing Ser-
vice.

[34] Russell 1991 - Russell, Deborah and G. T. Gangemi Sr. 1991. Computer Security Ba-
sics. Sebastopol, CA: O'Reilly & Associates, Inc.

[35] TCSEC 1985 - Department of Defense. 1985. DoD Trusted Computer System Evalua-
tion Criteria. DoD Standard 5200.28-STD. Washington, D.C.: U.S. Government Printing
Office.

ACRONYMS

ADP Automated Data Processing

ADT Abstract Data Type

AIS Automated Information System

DAA Designated Approval Authority

DAC Discretionary Access Control

DBMS Data Base Management System

DEC Discretionary Execution Control

DoD Department of Defense

EFT Electronic Funds Transfer

EPL Evaluated Products List

FIPS Federal Information Processing Standard

FMS Financial Management System

GAO General Accounting Office

IC Internal Control

IDA Institute for Defense Analyses

IG Inspector General

IMC Internal Management Control

IRM Information Retrieval Management (Program)

IVP Integrity Verification Procedure

MCP Management Control Plan

MEC Mandatory Execution Control

OMB Office of Management of Budget

NCSC National Computer Security Center

NIST National Institute of Standards and Technology

NSA National Security Agency

TCSEC Trusted Computer System Evaluation Criteria

TP Transformation Procedure

USC United States Code

APPENDIX A

A. SOURCE TEXT AND CROSS-REFERENCES

This Appendix contains a subsection for each policy document used in our formulation
of integrity-related control objectives. Each subsection is arranged in identical fashion.
First, a brief overview of the policy document is provided. This overview concentrates
on the AIS-integrity relevant aspects of the document rather than providing a
comprehensive summary. The overview is followed by a listing of ``Selected Source
Text'' (i.e., material quoted directly from the original document). Following the Selected
Source Text is a ``Cross-Reference'' section. The Cross-Reference section contains a table
indicating which statements from the Selected Source Text have affected our
formulation of (proposed) changes to the current TCSEC control objectives. In the table,
statement numbers from the Selected Source Text material are cross-referenced to each
current control objective by marking an ``X'' in the appropriate row-column intersection.
Each row is associated with a single section or statement from the Selected Source Text
while each column is associated with a single control objective.

The meaning associated for each ``X'' in the table (indicating a cross-reference) is that the
associated statement from the Source Text either (a) has implications for modifying the
original control objective, or (b) has implications for interpreting the proposed control
objective. Specific implications considered include the following:

· a new topic;

· a new viewpoint;

· suggests specific mechanisms, policies, or controls;

· demands interpretation;

· demands modification; and

· touches, influences, or constrains control.

Following the table is a list of comments (one for each ``X'' in the table) which provides
details for the implications of particular policy statements upon each control objective.
These comments represent notes made in analyzing the policy documents, and in
determining the adequacy of the original control objectives in light of the increased
scope of AIS security policy. The comments in this section are ``informal'' in the sense
that they were not written to stand independently, outside the context of the included
source text and related comments. In general, the comments do not attempt to address
each issue comprehensively, and some issues may not receive equal treatment in
different comments.

Some entries cross-referenced under the Security Policy heading are not further
specified under MAC, DAC, or Marking headings. These additional headings are left
blank whenever the security policy implications might be considered organization or
application specific and do not clearly indicate specific MAC, DAC, or Marking
ramifications, or particular technical implementations.

We have found that the topic of accountability should be generalized from its current
focus on ``user accountability'' as stated in the existing control objective. From the policy
documents we have studied, an expansion of the concept of accountability to include
user, organization, and general accountability concepts with respect to both applications
and systems would be useful. Our comments under specific Accountability cross-
references indicate such an expanded approach. Such an approach represents the
concept of a ``total sense'' of accountability (i.e., its most general meaning). As such,
some accountability features may in fact be external to a system. The exact placement
and nature of mechanisms is neither predetermined nor explicitly considered in our
comments.

In addition, we have assumed a similar generalization in addressing the topic of
assurance. In particular, we have found policy statements which address assurance (i.e.,
the ``trustedness'') of controls extending to (a) entities external to the traditional bounds
of AISs, and/or (b) to areas outside the traditional scope of protection mechanisms (e.g.,
application sub-systems).

Some material provided in the ``Selected Source Text'' does not have a cross-reference.
Such material was included if it provided valuable background, context, or general
information which might aid in understanding either the source text itself or related
comments. Additionally, in some instances the selected source text is formatted and/or
numbered slightly differently from the original; this was intended to clarify the
presentation of this material-care was taken not to misrepresent the intent or meaning of
the original material.

A.1 Privacy Act of 1974-Public Law 93-579

Public Law 93-579 requires the U.S. government to safeguard personal data processed
by federal agency computer systems. This Act also requires the government to provide
ways for individuals to find out what personal information is being recorded and to
correct inaccurate information. The Act spells out physical security procedures,
information management practices, and computer and network controls. This act also
mandated the creation of the Privacy Protection Study Commission [Russell 1991, p.
287].

This Act extends the responsibility for management and protection of information
resources to the area of privacy. The Act notes that the increasing use of computer and
information technology has greatly magnified the potential harm to individuals that can
occur from any collection, maintenance, use, or dissemination of personal information.
The Act requires the Federal agencies to issue appropriate administrative orders,
provide personnel sanctions, and establish appropriate technical and physical
safeguards to ensure the security of the information system and the confidentiality of the
data. The Act further requires that the information is as timely, complete, accurate, and
relevant to its intended use as possible, and that ``adequate safeguards'' to prevent
misuse are provided. Also required are administrative actions to keep account of the
employees, other individuals and organizations having access to the system or file, and
the disclosures and uses made of the information.

The Act requires that Federal agencies establish rules of conduct with regard to the
ethical and legal obligations in developing and operating a computerized data system
and in handling personal data, and take action to instruct all employees of such
obligations. As ``privacy'' is used in the Act, information management responsibility
includes the proper collection, maintenance, use, and dissemination of any information
which can be associated with a particular individual. The Act specifies that punitive
actions can be levied against the Government for failure to uphold these responsibilities.
We conclude that other factors which must be considered include (1) the moral
obligation of government officials to maintain the constitutional rights of its citizens, (2)
the adverse affect on government functioning in the absence of accurate information,
and (3) the penalties associated with adverse public opinion which are likely to result
from any breach of privacy as defined in the Act.

The following table contains selected sections of Public Law 93-579. The cross-reference
table and comments appear in the next section.

TABLE A-2. Privacy Act of 1974-Selected Source Text

Sec. 2(a) The Congress finds that-

(1) the privacy of an individual is directly affected by the collection, maintenance, use,
and dissemination of personal information by Federal agencies;

(2) the increasing use of computers and sophisticated information technology, while es-
sential to the efficient operations of the Government, has greatly magnified the harm to
individual privacy that can occur from any collection, maintenance, use, or dissemina-
tion of personal information;

(3) the opportunities for an individual to secure employment, insurance, and credit, and
his right to due process, and other legal protections are endangered by the misuse of cer-
tain information systems;

(4) the right to privacy is a personal and fundamental right protected by the Constitution
of the United States; and

(5) in order to protect the privacy of individuals identified in information systems main-
tained by Federal agencies, it is necessary and proper for the Congress to regulate the
collection, maintenance, use, and dissemination of information by such agencies.

Sec. 2(b) The purpose of this Act is to provide certain safeguards for an individual
against an invasion of personal privacy by requiring Federal agencies, except as
otherwise provided by law, to-

(1) permit an individual to determine what records pertaining to him are collected, main-
tained, used, or disseminated by such agencies;

(2) permit an individual to prevent records pertaining to him obtained by such agencies
for a particular purpose from being used or made available for another purpose without
his consent;

(3) permit an individual to gain access to information pertaining to him in Federal agen-
cy records, to have a copy made of all or any portion thereof, and to correct or amend
such records;

(4) collect, maintain, use, or disseminate any record of identifiable personal information
in a manner that assures that such action is for a necessary and lawful purpose, that the
information is current and accurate for its intended use, and that adequate safeguards are
provided to prevent misuse of such information;

(5) permit exemptions from the requirements with respect to records provided in this
Act only in those cases where there is an important public policy need for such exemp-
tion as has been determined by specific statutory authority; and

(6) be subject to civil suit for any damages which occur as a result of willful or inten-
tional action which violates any individual's rights under this Act.

A.1.1 Cross-References and Comments

TABLE A-3. Privacy Act of 1974-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

Sec.2(b)(1)

X

X

Sec.2(b)(2)

X

X

Sec.2(b)(3)

X

X

X

Sec.2(b)(4)

X

X

X

X

X

X

Sec.2(b)(5)

X

X

Sec.2(b)(6)

X

Sec.2(b)(1)

[Security Policy] The type(s) of information about a particular individual, represented as
records which are stored and processed by an agency, must be releasable to that individ-
ual. [Accountability] An agency is accountable for the accurate and timely response to
individuals requesting the types of privacy information collected, maintained, used, or
disseminated by that agency.

Sec.2(b)(2)

[Security Policy] The capability for an individual to restrict subsequent, additional uses
of personal information which was collected for a particular use is implied. [Accountabil-
ity] An appropriate history of the actual uses of personal information must be main-
tained.

Sec.2(b)(3)

[Security Policy] Individuals have to right to obtain copies of personal information held
by an agency. A process to correct or amend personal information must exist. [Accounta-
bility] All corrections and amendments of individual records should be auditable. [Assur-
ance] Appropriate controls on the correction and amendments process should exist.
These controls should include the validation of source data used in modifying a record.

Sec.2(b)(4)

[Security Policy] Safeguards must exist to prevent misuse of information. Federal agen-
cies are constrained to necessary and lawful purposes in collecting, maintaining, using,
or disseminating personal information. In addition to disclosure, privacy concerns in-
clude the acquisition, storage, and manipulation of information relating to individuals.
[MAC, DAC] Collection, maintenance, use, and dissemination of personal information
are subject to mandatory controls. [Marking] Information associated with a particular in-
dividual must be appropriately marked. [Accountability] The actual use of information
must be audited whenever such use does not comply with standing policies. [Assurance]
Information must be current and accurate with respect to its intended use.

Sec.2(b)(5)

[Security Policy] The capability to permit exemptions via override of normal controls is
required. Such exemptions may remain subject to other mandatory controls. For in-
stance, certain records about individuals held by the Internal Revenue Service may not,
under normal operating procedures, be accessed by the Federal Bureau of Investigation
(FBI); these records may become releasable to the FBI during the course of an investiga-
tion, but only after a valid warrant has been issued. [Accountability] Exemptions to nor-
mal operating policies may require auditing. The exemption categories listed by this Act
may each have unique auditing requirements.

Sec.2(b)(6)

[Accountability] An agency is held accountable for all its uses of personal information.
Individuals having administrative control over personal information must be held ac-
countable for their actions with respect to uses of that information.

A.2 Computer Matching and Privacy Protection Amendments of 1990-
Public Law 101-508

Public Law 101-508 provides protection against privacy violations due to information
matching policies of the Federal government [Russell 1991, p. 288]. This Act amends 5
USC 552a, the codified version of the Privacy Act of 1974. It sets forth requirements for
the independent verification of information about individuals produced by ``matching
programs,'' i.e., through automated techniques. The Act requires that such information
be verified before any adverse action-such as the denial of payment under a Federal
benefit program-is carried out. The essence of this law with respect to integrity-related
control objectives is to impose procedural controls on the modification of data. Also
specified in this Act are the notification requirem