exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

C-TR-111-91.txt

C-TR-111-91.txt
Posted Aug 17, 1999

C Technical Report 111-91: Integrity-Oriented Control Objectives: Proposed Revisions to the TCSEC, October 1991.

tags | paper
SHA-256 | fd03ddc9985555a813afacf3e136efaa208011af3de4e949c4d58a0aa5e9cbe4

C-TR-111-91.txt

Change Mirror Download
13 May 1992

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 requirements of an agency to an individual who
is subject to adverse action.

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

TABLE A-4. Computer Matching and Privacy Protection Amendments of 1990-Selected
Source Text

Sec. 7201. Computer Matching of Federal Benefits Information and Privacy Protection.

(b) Verification Requirements Amendment.-- (1) Subsection (p) of section 552a of title
5, United States Code, is amended to read as follows:

(p) Verification and Opportunity to Contest Findings.--

(1) In order to protect any individual whose records are used in a matching pro-
gram, no recipient agency, non-Federal agency, or source agency may suspend, ter-
minate, reduce, or make a final denial of any financial assistance or payment un-
der a Federal benefit program to such individual, or take other adverse action
against such individual, as a result of information produced by such matching pro-
gram, until--

(A) (i) the agency has independently verified the information; or (ii) the
Data Integrity Board of the agency, or in the case of a non-Federal agency
the Data Integrity Board of the source agency, determines in accordance
with guidance issued by the Director of the Office of Management and Budg-
et that-- (I) the information is limited to identification and amount of bene-
fits paid by the source agency under a Federal benefit program; and (II)
there is a high degree of confidence that the information provided to the re-
cipient agency is accurate;

(B) the individual receives a notice from the agency containing a statement
of its findings and informing the individual of the opportunity to contest
such findings; and

(C) (i) the expiration of any time period established for the program by stat-
ute or regulation for the individual to respond to that notice; or...

(2) Independent verification referred to in paragraph (1) requires investigation and
confirmation of specific information relating to an individual that is used as a ba-
sis for an adverse action against the individual, including where applicable investi-
gation and confirmation of--

(A) the amount of any asset or income involved;

(B) whether such individual actually has or had access to such asset or in-
come for such individual's own use; and

(C) the period or periods when the individual actually had such asset or in-
come.

(3) Notwithstanding paragraph (1), an agency may take any appropriate action oth-
erwise prohibited by such paragraph if the agency determines that the public
health or public safety may be adversely affected or significantly threatened during
any notice period required by such paragraph.

A.2.1 Cross-References and Comments

TABLE A-5. Computer Matching and Privacy Protection Amendments of 1990-Cross-
References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

(p)(1)

X

(p)(1)(A)

X

(p)(1)(B-C)

X

X

(p)(2)(A-C)

X

(p)(3)

X

(p)(1)

[Security Policy] One may not directly modify data based on the results of automated
``matching programs.'' Procedural controls and control information are required to verify
information which forms the basis of an adverse action throughout the process of carry-
ing out the adverse action against an individual. May apply to application-specific securi-
ty policies, with some applications having unique requirements.

(p)(1)(A)

[Assurance] The information which forms the basis of an adverse action must either (i)
be independently verified or (ii) be limited in scope, with a high degree of confidence in
its accuracy.

(p)(1)(B-C)

[Marking] The capability to enable or disable transactions conferring benefits is implied.
Transaction of adverse action requires marking to indicate expiration of a grace period
and/or an individual's possible response (i.e., a pending challenge to decision). Transac-
tion of adverse action requires marking that individual has received notice. [Accountabil-
ity] Procedural controls must exist to ensure that no adverse action proceeds without
first meeting verification and/or control information requirements. The system must be
able to record and collate appropriate historical information related to benefits transac-
tions. The system must keep account of the initiation, length, and expiration of the grace
period.

(p)(2)(A-C)

[Assurance] Independent verification requires investigation and confirmation of specific
information which forms the basis of an adverse action.

(p)(3)

[Security Policy] Stated requirements are subject to exemption when considering addi-
tional policies (i.e., public health and public safety policies).

A.3 Paperwork Reduction Act of 1980-Public Law 96-511

Public Law 96-511 promotes the use of efficient office systems (e.g., electronic mail,
document storage, and electronic imaging systems) under the management of OMB
[Russell 1991, p. 279]. This Act simultaneously encourages the automation of
information services and adds responsibilities for the use of automation. Under this Act,
automation must be used to improve both services provided by, and management of,
Federal Agencies. Additionally, such automation must be cost effective (maximizing
usefulness of information while minimizing costs to collect, maintain, use, and
disseminate information) and supportive of ``uniform'' Federal information policies.

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

TABLE A-6. Paperwork Reduction Act of 1980-Selected Source Text

Sec.2.(a) Chapter 35 of title 44, United States Code, is amended to read as follows:

3501. Purpose The purpose of this chapter is-

(1) to minimize the Federal paperwork burden for individuals, small business,
State and local governments, and other persons;

(2) to minimize the cost to the Federal Government of collecting, maintaining, us-
ing, and disseminating information;

(3) to maximize the usefulness of information collected by the Federal Govern-
ment;

(4) to coordinate, integrate and, to the extent practicable and appropriate, make uni-
form Federal information policies and practices;

(5) to ensure that automatic data processing and telecommunications technologies
are acquired and used by the Federal Government in a manner which improves
service delivery and program management, increases productivity, reduces waste
and fraud, and, wherever practicable and appropriate, reduces the information
processing burden for the Federal Government and for persons who provide infor-
mation to the Federal Government; and

(6) to ensure that the collection, maintenance, use and dissemination of informa-
tion by the Federal Government is consistent with applicable laws relating to confi-
dentiality, including section 552a of title 5, United States Code, known as the Pri-
vacy Act.

3506. Federal agency responsibilities

(a) Each agency shall be responsible for carrying out its information management
activities in an efficient, effective, and economical manner, and for complying
with the information policies, principles, standards, and guidelines prescribed by
the Director.

A.3.1 Cross-References and Comments

TABLE A-7. Paperwork Reduction Act of 1980-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

3501(4)

X

3506(a)

X

X

3501(4)

[Security Policy] The essence of this law affects Security Policy in that its purpose is to
coordinate, integrate, and make uniform Federal information policies and practices. One
integration framework might include the information life cycle (e.g., origin or acquisi-
tion through final disposition). Factors to consider include cost effectiveness and risk re-
duction relating to information processing activities. Cost effectiveness is a function of
the cost of controls versus the degree of acceptable risk.

3506(a)

[Security Policy] Information management must be efficient, effective, and economical.
Minimizing the paperwork burden and associated costs of collecting, maintain, using,
and disseminating information are required. Automated systems are required to improve
service delivery, program management, productivity, and to reduce waste, fraud, and in-
formation processing burden. Confidentiality policies must also be enforced. Information
which is not useful should not be collected. Maximizing the usefulness of collected in-
formation is required. Information that is no longer useful should not be maintained. Sys-
tems are required to enforce integrated policies. This implies a significant effort must be
undertaken to address the overall system security policy, and in particular the issue
where different component policies might produce conflicts. [Accountability] Compli-
ance with multiple policies, standards, and guidelines is required.

A.4 Department of Defense Authorization Act of 1982-Public Law 97-86

The Warner Amendment to Public Law 97-86 exempts certain types of DoD
procurements from the Automatic Data Processing Equipment Act (Public Law 89-306,
also know as the Brooks Act). The exempted procurements includes those in which the
function, operation, or use of a particular piece of equipment or a service involves one or
more categories related to national security or military interests [Russell 1991, p. 280].

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

TABLE A-8. DoD Authorization Act of 1982-Selected Source Text

Sec. 908.(a)(1) Chapter 137 of title 10, United States Code, is amended by adding at the
end thereof the following new section:

2315. Law inapplicable to the procurement of automatic data processing equipment and
services for certain defense purposes

(a) Section 111 of the Federal Property and Administrative Services Act of 1949 (40
U.S.C. 795) is not applicable to the procurement by the Department of Defense of auto-
matic data processing equipment or services if the function, operation, or use of the
equipment or services-

(1) involves intelligence activities;

(2) involves cryptologic activities related to national security;

(3) involves the command and control of military forces;

(4) involves equipment that is an integral part of a weapon or weapons system; or

(5) subject to subsection (b), is critical to the direct fulfillment of military or intel-
ligence missions.

(b) Subsection (a)(5) does not include procurement of automatic data processing equip-
ment or services to be used for routine administrative and business applications (includ-
ing payroll, finance, logistics, and personnel management applications)...

A.4.1 Cross-References and Comments

TABLE A-9. DoD Authorization Act of 1982-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

2315(a)(1-5)

X

2315(b)

X

2315(a)(1-5)

[Security Policy] This Act excludes certain systems, during acquisition, from the applica-
tion of specific aspects of Federal law. The exclusions named in this Act, relating to the
procurement of automatic data processing (ADP) equipment or services, extend to most
of all the other Acts applying to Federal systems. Most of these exclusion categories re-
late to systems requiring secrecy and integrity protection. Simply having authorization to
be exempt does not make it a good practice to avoid a thorough analysis of a system's
protection needs. Each acquisition should address its protection needs through the formu-
lation and analysis of a systems security policy that will enable a more informed deci-
sion regarding invocation of this Act.

2315(b)

[Security Policy] Explicitly precludes from ``mission critical'' exemption many DoD
auto mated systems relating to routine administrative and business applications. There-
fore, many systems used within the DoD are subject to Federal laws.

A.5 Federal Managers' Financial Integrity Act of 1982-Public Law 97-255

This Act extends security policies into the realm of internal controls. Systems of internal
control are of interest when considering integrity in AISs because (a) primary
applications, which are the focus of traditional internal controls, are being automated to
greater degrees, and (b) internal control systems themselves are being automated to
greater degrees. Internal controls are usually associated with assets having ``value.''
Information within Federal AISs is readily termed a valuable asset according to [OMB
A-130]. This Act requires adherence to the Comptroller General's (GAO) Standards for
Internal Control in the Federal Government [GAO 1983], which are incorporated into
[GAO Title 2, App.II].

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

TABLE A-10. Federal Managers' Financial Integrity Act of 1982-Selected Source Text

Sec. 2. Section 113 of the Accounting and Auditing Act of 1950 (31 U.S.C. 66a) is
amended by adding at the end thereof the following new subsection:

(d)(1)(A) To ensure compliance with the requirements of subsection (a)(3) of this
section, internal accounting and administrative controls of each executive agency
shall be established in accordance with standards prescribed by the Comptroller
General, and shall provide reasonable assurance that-

(i) obligations and costs are in compliance with applicable law;

(ii) funds, property, and other assets are safeguarded against waste, loss, un-
authorized use, or misappropriation; and

(iii) revenues and expenditures applicable to agency operations are properly
recorded and accounted for to permit the preparation of accounts and reliable
financial and statistical reports and to maintain accountability over the assets.

(B) The standards prescribed by the Comptroller General under this paragraph
shall include standards to ensure the prompt resolution of all audit findings....

(3)... the head of each executive agency shall... prepare a statement-

(A) that the agency's systems of internal accounting and administrative con-
trol fully comply with the requirements of paragraph (1); or

(B) that such systems do not fully comply with such requirements.

(5) The statements and reports required by this subsection... shall also be made
available to the public, except that, in the case of any such statement or report con-
taining information which is-

(A) specifically prohibited from disclosure by any provision of law; or

(B) specifically required by Executive order to be kept secret in the interest
of national defense or the conduct of foreign affairs, such information shall
be deleted prior to the report or statement being made available to the public.

A.5.1 Cross-References and Comments

TABLE A-11. Federal Managers' Financial Integrity Act of 1982-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

(d)(1)(A)(i-iii)

X

X

X

X

X

X

(d)(1)(B)

X

(d)(3)

X

(d)(5)

X

X

X

X

X

(d)(1)(A)(i-iii)

[Security Policy] Legal compliance related to organizational obligations and costs (e.g.,
contracts, logistics, funds transfer, services, etc.) must be considered in the formulation
of Security Policy. Security policy must address waste, loss, unauthorized use, and mis-
appropriation in terms of both AIS assets as well as other assets, whenever these non-
AIS assets are either represented within or controlled via AISs. [MAC, DAC, Marking]
Because the control of ``unauthorized use'' is explicitly called for, authorization features
are required. [Accountability] Costs and obligations must be internally accounted for
within an organization to the level of a responsible individual acting within the scope of
his authority. [Assurance] Reasonable assurance is required.

(d)(1)(B)

[Accountability] Prompt resolution of audit findings requires specific features for AIS
systems. These may include audit reduction tools, real-time alerts, etc.

(d)(3)

[Assurance] The head of each executive agency is required to produce a report on the
state of that agency's internal control system.

(d)(5)

[Security Policy] Mandated disclosure of information is also subject to restrictions of na-
tional security and other (confidentiality) policies. [MAC, DAC, Marking] The overlap-
ping of confidentiality and integrity policy coverage has implications for MAC policy
with regard to information sanitation and downgrading of classified or sensitive informa-
tion. There are also implications for DAC policy with regard to the designated individu-
als performing these types of operations. [Accountability] Auditing of all downgrading
and sanitation activity shall be performed.

A.6 Computer Security Act of 1987-Public Law 100-235

Public Law 100-235 expands the definition of computer security protection and clarifies
the role of the (NBS now the National Institute of Standards and Technology) [Russell
1991, p. 283]. A primary function of this Act is to prescribe authority and assign
responsibilities for developing security standards and guidelines for Federal computer
systems. This Act has broadens the scope of applicability for security policies in three
areas: the range of resources, the type(s) of information, and the types of systems.

Significantly, this Act also increases types of computers under consideration as well as
the scope of information which must be protected. The Act defines computer systems
broadly and includes support services as an area which must be considered. This can be
interpreted to mean that effective controls must exist over AIS support systems and
personnel, as well as those individuals who operate the primary applications. The
traditional scope of information protection was increased as well. Previously, explicit
protection policy applied only to ``classified'' and ``specifically categorized sensitive''
information. This Act applies to a more encompassing term, ``sensitive information,''
which is defined in detail below.

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

TABLE A-12. Computer Security Act of 1987-Selected Source Text

Sec.2. Purpose.

(a) In General.-The Congress declares that improving the security and privacy of sensi-
tive information in Federal computer systems is in the public interest, and hereby creates
a means for establishing minimum acceptable security practices for such systems, with-
out limiting the scope of security measures already planned or in use.

(b) Specific Purposes.-The purposes of this Act are-

(1) by amending the Act of March 3, 1901, to assign to the National Bureau of
Standards responsibility for developing standards and guidelines for Federal com-
puter systems, including responsibility for developing standards and guidelines
needed to assure the cost-effective security and privacy of sensitive information in
Federal computer systems, drawing on the technical advice and assistance (includ-
ing work products) of the National Security Agency, where appropriate;

(2) to provide for promulgation of such standards and guidelines by amending sec-
tion 111(d) of the Federal Property and Administrative Services Act of 1949;

(3) to require establishment of security plans by all operators of Federal computer

(4) to require mandatory periodic training for all persons involved in management,
use, or operation of Federal computer systems that contain sensitive information.

Sec.3. Establishment of Computer Standards Program.

The Act of March 3, 1901 (15 U.S.C. 271-278h), is amended-

(2)... by inserting... ``Sec.20''

(d) As used in this section-

(1) the term ``computer system''-

(A) means any equipment or interconnected system or subsystems of
equipment that is used in the automatic acquisition, storage, manipula-
tion, management, movement, control, display, switching, interchange,
transmission, or reception, of data or information; and

(B) includes-

(i) computers;

(ii) ancillary equipment;

(iii) software, firmware, and similar procedures;

(iv) services, including support services; and

(iv) related resources as defined by regulations issued by the Ad-
ministrator for General Services . . .

(4) the term `sensitive information' means any information, the loss, misuse,
or unauthorized access to or modification of which could adversely affect the
national interest or the conduct of Federal programs, or the privacy to which
individuals are entitled . . . , but which has not been specifically authorized
under criteria established by an Executive Order or an Act of Congress to be
kept secret in the interest of national defense or foreign policy;

Legislative History [The Legislative History of the Computer Security Act of 1987 [H.
Rept. 100-153(I), p. 24] gives examples of that which should be considered ``sensitive
information:''

. . . information which if modified, destroyed or disclosed in an unauthorized
manner could cause:

Loss of life;

Loss of property or funds by unlawful means;

Violation of personal privacy or civil rights;

Gaining of an unfair commercial advantage;

Loss of advanced technology, useful to a competitor; or

Disclosure of proprietary information entrusted to the government.]

Sec.5. Amendment to Brooks Act.

Section 111(d) of the Federal Property and Administrative Services Act of 1949 (40
U.S.C. 759(d)) is amended to read as follows:

(d)(1) The Secretary of Commerce shall, on the basis of standards and guidelines
developed by the [National Institute of Standards and Technology] . . . promulgate
standards and guidelines pertaining to Federal computer systems, making such
standards compulsory and binding to the extent to which the Secretary determines
necessary to improve the efficiency of operation or security and privacy of Federal
computer systems. . . .

(d)(2) The head of a Federal agency may employ standards for the cost-effective
security and privacy of sensitive information in a Federal computer system within
or under the supervision of that agency that are more stringent than the standards
promulgated by the Secretary of Commerce, if such standards contain, at a mini-
mum, the provisions of those applicable standards made compulsory and binding
by the Secretary of Commerce.

(d)(4) The Administrator shall revise the Federal information resources manage-
ment regulations . . . to be consistent with the standards and guidelines promulgat-
ed by the Secretary of Commerce.

Sec.6. Additional Responsibilities for Computer Systems Security and Privacy.

(a) Identification of Systems That Contain Sensitive Information.- . . . each Feder-
al agency shall identify each Federal computer system, and system under develop-
ment, which is within or under the supervision of that agency and which contains
sensitive information.

(b) Security Plan.- . . . each agency shall, consistent with the standards, guidelines,
policies, and regulations prescribed pursuant to section 111(d) of the Federal Prop-
erty and Administrative Services Act of 1949, establish a plan for the security and
privacy of each Federal computer system identified by that agency pursuant to sub-
section (a) that is commensurate with the risk and magnitude of the harm resulting
from the loss, misuse, or unauthorized access to or modification of the information
contained in such system. . . .

A.6.1 Cross-References and Comments

TABLE A-13. Computer Security Act of 1987-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

Sec.3(2)(d)(1)

X

Sec.3(2)(d)(4)

X

X

X

X

Sec.3(Leg.His.)

X

X

X

Sec.5(d)(1,2,4)

X

Sec.6(a-b)

X

Sec.3(2)(d)(1)

[Security Policy] This Act applies to ``computer systems,'' a range of resources includ-
ing equipment, software, services, and related resources. This implies an increased scope
of system Security Policies with regard to the range of applicable resources.

Sec.3(2)(d)(4)

[Security Policy] By defining the type of applicable information, this Act explicitly in-
creases the scope of the Security Policy-in particular, the systems containing ``sensitive
information'' must provide protection for that information. [MAC, DAC, Marking] Be-
cause the control of ``unauthorized use'' is explicitly called for, authorization features
are required.

Sec.3(Leg.His.)

[Security Policy, Assurance, Fault Tolerance] The considerations for ``loss of life'' great-
ly increases the scope of systems which are applicable under this Act. The inclusion of
computer systems which control machinery or processes also has important implications
for the scope of the Security Policy. In particular, the inclusion of safety-critical systems
is implied, although there is currently a lack of explicit policy statements in this area.

Sec.5(d)(1,2,4)

[Security Policy] The Act contains details relevant to the formulation of individual (agen-
cy) Security Policies. These show that the agencies involved might have to prescribe
and integrate different security policies and standards to meet their unique needs.

Sec.6(a-b)

[Security Policy] All systems identified as containing sensitive information are subject
to Security Policy requirements. An organization (agency) must develop individual secu-
rity plans for computer systems containing ``sensitive information.'' These plans may
provide greater insight into Security Policy needs.

A.7 OMB Circular No. A-127-Financial Management Systems

OMB Circular No. A-127 establishes a program to assure the integrity of Federal
financial management systems (FMSs) by prescribing policies and procedures for
executive departments and agencies. Financial management systems are of interest
primarily because the control of revenue, expenditure, funds, property, and other assets
are often-either partially or totally-implemented via AISs. Therefore, policy related to
FMSs must be effectively enforced on these related AISs.

There are five particular control areas for FMSs called for under this Circular [OMB A-
127, p. 4]: FMS operations, FMS integrity, support for budgets, support for management,
and full financial disclosure. Each of these areas has specific implications for integrity
when considering (possible) automated features of an FMS.

The most demanding and significant implications for AIS integrity fall under the area of
FMS operations. Specific objectives for FMS operations address the areas of usefulness,
timeliness, reliability and completeness, comparability and consistency, and efficiency
and economy. The use of automated systems to help achieve these objectives is explicitly
called for [OMB A-127, p. 4].

Any particular executive department or agency may have unique requirements for one
or more of the preceding control areas or FMS control objectives. The importance of this
Circular is not in calling out specific, detailed requirements, but in recognizing specific
areas in which controls must exist to enforce financial management policies. These areas
must be addressed by AIS integrity policies on automated implementations of FMSs.
This Circular has implications for both system and application-oriented security policies.

The following table contains selected sections of OMB Circular No. A-127. The cross-
reference table and comments appear in the next section.

TABLE A-14. OMB Circular No. A-127-Selected Source Text

1. Purpose. This Circular prescribes policies and procedures to be followed by executive
departments and agencies in developing, operating, evaluating, and reporting on finan-
cial management systems.

2. Background. The Budget and Accounting Procedures Act of 1950, the Federal Manag-
ers' Financial Integrity Act, and related legislation . . . provide that:

-- Establishing and maintaining systems of accounting and reporting is the respon-
sibility of the executive branch.

-- Agency systems shall provide for:

· complete disclosure of the financial results of the activities of the agency,

· adequate financial information for agency management and for formulation
and execution of the budget,

· effective control over revenue, expenditure, funds, property, and other assets.

3. Policy. The financial management system of each agency shall meet the objectives set
forth in Section 6 of this Circular. These objectives are intended to establish a frame-
work for complying with applicable law, appropriate budget and accounting principles
and standards, Treasury reporting requirements, and the best contemporary financial
practice. Systems developed and operated under this Circular shall be the source for fi-
nancial information used in the budget, Treasury financial statements, financial reports
to the Congress, and other financial reports.

Agencies shall establish and maintain a single, integrated financial management system,
which may be supplemented by subsidiary systems. Data needed in this system and oth-
er agency systems shall be entered only once and transferred automatically to appropri-
ate accounts or other parts of the system or systems. New or substantially revised sys-
tems shall be developed on an inter-agency basis and designed to meet the needs of all
participating agencies. Funds shall be expended only for systems that meet the require-
ments of this Circular.

6. Financial Management System Objectives. The following objectives shall be met by
the agency financial management system in complying with applicable law and appropri-
ate guidance of GAO, Treasury, and OMB. . . .

a. Systems operations -- the agency financial management system shall use the
best of acceptably priced, contemporary technology -- including automated data en-
try and edit, data management, data base dictionaries, electronic communications
between systems, flexible report formats, and controlled access to data bases by
personal computers and other means -- to achieve the following objectives.

(1) Usefulness -- financial management data shall be gathered and processed
only where necessary to meet specific internal management needs or external
requirements. Reports shall be tailored to specific user needs and if report us-
ages does not justify cost, reports shall be terminated. Usefulness shall be de-
termined in part through consultation with users as part of the reviews re-
quired by Section 7b of this Circular. (2) Timeliness -- financial manage-
ment data shall be recorded as soon as practicable after the occurrence of the
event, and relevant preliminary data shall be made available to managers by
the fifth working day following the end of the reporting period. Other stand-
ards of timeliness may be established where the agency has inventoried re-
ports and set specific standards, with user participation. Final, corrected data
shall be available in time to meet external reporting requirements.

(3) Reliability and completeness -- financial management information shall
be reasonably complete and accurate, shall be verifiable and ordinarily be
drawn from the official records and systems, and shall be no more detailed
than necessary to meet the needs of management and external requirements.

(4) Comparability and consistency -- financial management data shall be re-
corded and reported in the same manner throughout the agency, using uni-
form definitions. Accounting shall be synchronized with budgeting. Consist-
ency over time shall be maintained. New and revised systems shall adopt
common, existing definitions and classifications.

(5) Efficiency and economy -- the agency financial management system shall
be designed and operated with reasonable total costs and transaction costs, in
accordance with OMB guidelines. Financial systems which are excessively
costly shall be identified and phased out. This shall be accomplished through
installation of effective systems of planning and evaluation, sharing of data,
elimination of overlap and duplication, and use of the best contemporary
technology, including commercially available packages with proven success
in other agencies or the private sector.

b. Systems integrity -- the agency financial management system shall feature rea-
sonable controls designed, operated, and evaluated in accordance with OMB Circu-
lar A-123, Internal Control Systems, and A-71 [rescinded by A-130], Responsibili-
ties for the Administration and Management of Automatic Data Processing Facili-
ties.

c. Support for budgets -- financial management data shall be recorded, stored, and
reported to facilitate budget preparation, analysis, and execution. Data shall be clas-
sified uniformly and that classification, at a minimum, shall be at a level of detail
that directly supports execution of enacted budgets and formulation of proposed
budgets, without excessive aggregation or disaggregation. . . .

d. Support for management -- data shall be recorded and reported in a manner to
facilitate carrying out the responsibilities of both program and administrative man-
agers. The agency financial management system shall provide for a coherent, time-
ly, and accurate financial management data base. It should be supplemented as nec-
essary to meet agency management and Executive Office requirements for adminis-
trative data, such as the Financial and Administrative Management Information
System 1. . . .

e. Full financial disclosure -- financial management data shall be recorded, and re-
ported as specifically required by OMB or Treasury, to provide for full financial
disclosure and accountability in accordance with appropriate budget and account-
ing principles and standards. . . .

A.7.1 Cross-References and Comments

TABLE A-15. OMB Circular No. A-127-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

3

X

X

X

X

6(a)

X

X

X

X

X

X

6(a)(1)

X

X

6(a)(2)

X

X

X

6(a)(3)

X

X

X

6(a)(4)

X

6(a)(5)

X

X

6(b)

X

X

6(c)

X

6(d)

X

X

X

6(e)

X

X

X

3

[Security Policy, Accountability] AIS portions of financial management systems must
comply with applicable law, budget and accounting principles and standards, Treasury
reporting requirements, and the best contemporary financial practice. A specific adminis-
trative policy is cited in regard to data handling and security controls. [Assurance, Fault
Tolerance] The single point-of-entry requirement for input of data to the system, specify-
ing automatic transfer of data to required locations, implies rigorous administrative and
reliability features.

6(a)

[Security Policy] The use of AISs to implement financial management systems is explic-
itly called for. Controlled access to data bases is required. [MAC, DAC, Marking] Pro-
viding controlled access implies that these control objectives will be affected. [Accounta-
bility] This is implied when access control is required. [Assurance] Particular automated
features called for implies the need for assurance measures with rigor defined by accept-
able risk and reasonable cost as well as the need for a thorough risk analysis.

6(a)(1)

[Security Policy] Financial management data shall be gathered and processed only
where necessary to meet specific internal management needs or external requirements.
[Accountability] Reports are tailored to specific user needs.

6(a)(2)

[Security Policy, Accountability] Financial management data shall be recorded as soon
as possible and made available in a timely manner. Specific standards of timeliness may
be established. This implies the need for internal timing attributes and control policies re-
lated to timing. [Assurance] Corrected data shall be available in time to meet external re-
porting requirements.

6(a)(3)

[Security Policy] Financial management information shall be reasonably complete and
accurate. This implies specifications for completeness and accuracy that can be moni-
tored and reacted to when the specified attributes or attribute values do not meet speci-
fied thresholds. [Accountability] Further, it implies identified responsibility for all ac-
tions taken on the specified information. Accountability is also implied by the verifica-
tion requirement. [Assurance] That information should be verifiable implies reconciling
transactions with starting and ending totals, dual-entry accounting, or external ``safety
paper'' (e.g., checks, withdrawal slips, and/or deposit slips).

6(a)(4)

[Security Policy] Uniform system definitions (process and data) for related systems are
required. Consistency of financial management data over time is required. Synchronized
functions (e.g., accounting and budgeting) are required.

6(a)(5)

[Security Policy, Assurance] Operational costs must be reasonable and in accordance
with OMB guidelines. Effective planning and evaluation, sharing of data, elimination of
duplication, and the use of the best contemporary technology is required. This implies
that a thorough risk analysis must be performed to ascertain protection requirements.

6(b)

[Security Policy, Assurance] AIS portions of financial management systems must feature
reasonable controls designed, operated, and evaluated in accordance with OMB policy.
Again, the implication for a thorough risk analysis for protection controls is established
by the use of the term ``reasonable.''

6(c)

[Security Policy] Uniform system of data categorization is required. The budget process
shall be supported. Excessive aggregation or disaggregation is not acceptable. This is an
application-specific security policy issue.

6(d)

[Security Policy, Accountability, Assurance] Data shall be recorded and reported in a
manner to facilitate carrying out the responsibilities of managers. The financial manage-
ment system shall be coherent, timely, and accurate.

6(e)

[Security Policy, Accountability] Financial management data shall be recorded. Reports
shall provide full financial disclosure and accountability in accordance with appropriate
budget and accounting principles and standards. [Assurance] Accuracy and completeness
of data being disclosed has implications for assurance.

A.8 OMB Circular No. A-130-Management of Federal Information Re-
sources

OMB Circular No. A-130 establishes requirements for effective and efficient
management of federal information resources. This Circular requires all agency
information systems to provide a level of security commensurate with the sensitivity of
the information, the risk of its unauthorized access, and the harm that could result from
improper access. It also requires all agencies to establish security programs to safeguard
the sensitive information that they process [Russell 1991, p. 282]. As such, it sets forth
policy regarding information management within Federal agencies that bear directly on
the protection issues of confidentiality, integrity, and availability. That these issues are
intended to be within the scope of this Circular is explicitly stated in Appendix IV [p.
52749]:

Security of information systems means both the protection of information while it is
within the systems and also the assurance that the systems do exactly what they are sup-
posed to do and nothing more. Information system security entails management controls
to ensure the integrity of operations including such matters as proper access to the infor-
mation in the systems and proper handling of input and output. In this sense, security of
information is first and foremost a management issue and only secondly a technical prob-
lem of computer security. . . . Protecting personal, proprietary, and other sensitive data
from unauthorized access or misuse; detecting and preventing computer related fraud
and abuse; and assuring continuity of operations of major information systems in the
event of emergency related disruptions are increasingly serious policy issues. . . .

The Paperwork Reduction Act of 1980 establishes a broad mandate for efficient,
effective, and economical performance of information activities by agencies. Circular
No. A-130 implements OMB authority under the 1980 Act with respect to general
information policy, records management, privacy, and Federal automatic data
processing and telecommunications. In addition, it also implements sections of the
Privacy Act of 1974 as well as other Federal Laws and Executive policy statements.

Circular No. A-130 revises and consolidates policy and procedures in five previous OMB
directives, which were rescinded through this Circular. One reason for issuing this
Circular was OMB's determination that it was important to distinguish the statement of
policies from the procedures for implementing those policies. As a result, the main body
of the Circular is a statement of basic considerations and assumptions, policies, and
responsibility assignments. Appendices I, II, and III to the Circular consist of procedures
for implementing various policies. These Appendices have the same prescriptive force
as the Circular itself, and hence, were included in the extraction of Selected Source Text,
below. Appendix IV to the Circular is an explanatory document, and was used in our
analysis of the Source Text.

Appendix III of this Circular, together with OMB Circular No. A-123 (Internal Control
Systems), provide the evaluation and reporting requirements for the systems integrity
objective contained in OMB Circular No. A-127 (Financial Management Systems).

Due to a similar treatment of the subject, this Circular [App.III, Sec.(2)(c)] appears to be
the source of the definition of ``sensitive information'' used in The Computer Security
Act of 1987. Significantly, the Circular [App.III, manner which has particular
significance for policy related to safety-critical systems.

This Circular is undergoing revision with a version available for public comment
expected in the near future. Although the exact changes to be incorporated in revision
have not been determined, the available information indicates that the major focus of
change will be on policy regarding public access to agency information holdings and the
dissemination of electronic information products to Federal depository libraries. Also
incorporated will be changes called for by legislation passed since the 1985 publication
of this Circular. OMB plans call for work on the revised Circular to continue through
1992 [OMB 1991, p. 9026].

The following table contains selected sections of OMB Circular No. A-130. The cross-
reference table and comments appear in the next section.

TABLE A-16. OMB Circular No. A-130-Selected Source Text

7. Basic Considerations and Assumptions:

b. Government information is a valuable national resource. It provides citizens
with knowledge of their government, society, and economy-past, present, and fu-
ture; is a means to ensure the accountability of government; is vital to the healthy
performance of the economy; is an essential tool for managing the government's
operations; and is itself a commodity often with economic value in the market-
place.

c. The free flow of information from the government to its citizens and vice versa
is essential to a democratic society. It is also essential that the government mini-
mize the Federal paperwork burden on the public, minimize the cost of its informa-
tion activities, and maximize the usefulness of government information.

d. In order to minimize the cost and maximize the usefulness of government infor-
mation activities, the expected public and private benefits derived from govern-
ment information, insofar as they are calculable, should exceed the public and pri-
vate costs of the information.

f. The use of up-to-date information technology offers opportunities to improve the
management of government programs, and access to, and dissemination of, govern-
ment information. . . .

8. Policies

a. Information Management. Agencies shall:

(1) Create or collect only that information necessary for the proper performance of
agency functions and that has practical utility, and only after planning for its
processing, transmission, dissemination, use, storage, and disposition; (2) Seek to
satisfy new information needs through legally authorized inter-agency or intergov-
ernmental sharing of information, or through commercial sources, where appropri-
ate, before creating or collecting new information;

(3) Limit the collection of individually identifiable information and proprietary in-
formation to that which is legally authorized and necessary for the proper perform-
ance of agency functions;

(4) Maintain and protect individually identifiable information and proprietary infor-
mation in a manner that precludes:

(a) Unwarranted intrusion upon personal privacy (see Appendix I); and

(b) Violation of confidentiality;

(5) Provide individuals with access to, and the ability to amend errors in, systems
of records, consistent with the Privacy Act;

(6) Provide public access to government information, consistent with the Freedom
of Information Act.

(7) Ensure that agency personnel are trained to safeguard information resources.

(8) Disseminate information, as required by law, describing agency organization,
activities, programs, meetings, systems of records, and other information holdings,
and how the public may gain access to agency information resources;

(9) Disseminate such information products and services as are:

(a) Specifically required by law; or

(b) Necessary for the proper performance of agency functions, . . .

(10) Disseminate significant new, or terminate significant existing, information
products and services only after providing adequate notice to the public;

(11) Disseminate such government information products and services:

(a) In a manner that ensures . . . the public . . . have a reasonable ability to
acquire the information;

(b) In a manner most cost effective for the government, . . .

(c) So as to recover costs of disseminating the products or services . . .

(12) Establish procedures for:

(a) Reviewing periodically the continued need for and manner of dissemina-
tion of the agency's information products or services; and

(b) Ensuring that government publications are made available to depository
libraries as required by law.

b. Information Systems and Information Technology Management. Agencies shall:

(1) Establish multi-year strategic planning processes for acquiring and operating in-
formation technology that meet program and mission needs, reflect budget con-
straints, and form the bases for their budget requests;

(2) Establish systems of management control that document the requirements that
each major information system is intended to serve; and provide for periodic re-
view of those requirements over the life of the system . . .

(3) Make the official whose program an information system supports responsible
and accountable for the products of that system;

(4) Meet information processing needs through inter-agency sharing and from com-
mercial sources, when it is cost effective, before acquiring new information
processing capacity;

(5) Share available information processing capacity with other agencies to the ex-
tent practicable and legally permissible;

(6) Acquire information technology in a competitive manner that minimizes total
life cycle costs;

(7) Ensure that existing and planned major information systems do not unnecessari-
ly duplicate information systems . . .

(8) Acquire off-the-shelf software . . . unless the cost effectiveness of developing
custom software is clear and has been documented;

(9) Acquire or develop information systems in a manner that facilitates necessary
compatibility;

(10) Assure that information systems operate effectively and accurately;

(11) Establish a level of security for all agency information systems commensurate
with the sensitivity of the information and the risk and magnitude of loss or harm
that could result from improper operation of the information systems (See Appen-
dix III);

(12) Assure that only authorized personnel have access to information systems;

(13) Plan to provide information systems with reasonable continuity of support
should their normal operations be disrupted in an emergency;

(14) Use Federal Information Processing and Telecommunications Standards ex-
cept where it can be demonstrated that the costs of using a standard exceed the
benefits or the standard will impede the agency in accomplishing its mission;

(15) Not require program managers to use specific information technology facili-
ties or services unless it is clear and convincingly documented, subject to periodic
review, that such use is the most cost effective method for meeting program re-
quirements.

(16) Account for the full costs of operating information technology facilities and
recover such costs from government users . . .

(17) Not prescribe Federal information system requirements that unduly restrict the
prerogatives of heads of State and local government units;

(18) Seek opportunities to improve the operation of government programs or to re-
alize savings for the government and the public through the application of up-to-
date information technology to government information activities.

Appendix I to OMB Circular No. A-130-Federal Agency Responsibilities for Maintain-
ing Records About Individuals

4. Reporting Requirements.

b. New and Altered System Reports. . . .

(1) Altered System of Records. . . . The following changes are those for which a
report is required:

(b) A change that expands the types or categories of information maintained.
For example, a personnel file that has been expanded to include medical
records would require a report.

(c) A change that alters the purpose for which the information is used.

Appendix II to OMB Circular No. A-130-Cost Accounting, Cost Recovery, and Inter-
agency Sharing of Information Technology Facilities)

Supplemental Information.

Several commentators believed that requiring full costs to be recovered from all users
within an agency would not be cost effective. OMB disagreed with this viewpoint and
retained the draft Circular's formulation. Viable management of a large information tech-
nological facility requires that managers know the amount of resources devoted to each
user when providing services. Furthermore, effective management of the use of informa-
tion technology requires that the user have responsibility for and control over the re-
sources consumed by use of the facility. . . .

Appendix III to OMB Circular No. A-130-Security of Federal

Automated Information Systems

1. Purpose. This Appendix establishes a minimum set of controls to be included in Fed-
eral automated information systems security programs; assigns responsibilities for the se-
curity of agency automated information systems; and clarifies the relationship between
such agency security programs and internal control systems established in accordance
with OMB Circular A-123, Internal Control Systems. The Appendix revises procedures
formerly contained in Transmittal Memorandum No. 1 to OMB Circular No. A-71, now
rescinded, and incorporates responsibilities from applicable national security directives.

2. Definitions.

c. The term ``sensitive data'' means data that require protection due to the risk and
magnitude of loss or harm that could result from inadvertent or deliberate disclo-
sure, alteration, or destruction of the data. The term includes data whose improper
use or disclosure could adversely affect the ability of an agency to accomplish its
mission, proprietary data, records about individuals requiring protection under the
Privacy Act, and data not releasable under the Freedom of Information Act.

d. The term ``sensitive application'' means an application of information technolo-
gy that requires protection because it processes sensitive data, or because of the
risk and magnitude of loss or harm that could result from improper operation or de-
liberate manipulation of the application.

3. Automated Information Systems Security Programs. Agencies

shall assure an adequate level of security for all agency automated information systems,
whether maintained in-house or commercially. Specifically, agencies shall:

- Assure that automated information systems operate effectively and accurately;

- Assure that there are appropriate technical, personnel, administrative, environ-
mental, and telecommunications safeguards in automated information systems; and

- Assure the continuity of operation of automated information systems that support
critical agency functions.

Agencies shall implement and maintain an automated information systems security
program, including the preparation of policies, standards, and procedures. This pro-
gram will be consistent with government-wide policies, procedures, and standards
issued by the Office of Management and Budget, the Department of Commerce,
the Department of Defense, the General Services Administration, and the Office of
Personnel Management. Agency programs shall incorporate additional require-
ments for securing national security information in accordance with appropriate na-
tional security directives. Agency programs shall, at a minimum, include four pri-
mary elements: applications security, personnel security, information technology in-
stallation security, and security awareness and training.

a. Applications Security.

(1) Management Control Process and Sensitivity Evaluation. Agencies shall
establish a management control process to assure that appropriate administra-
tive, physical, and technical safeguards are incorporated into all new applica-
tions, and into significant modifications to existing applications. Manage-
ment officials who are the primary users of applications should evaluate the
sensitivity of new or existing applications being substantially modified. For
those applications considered sensitive, the management control process
shall, at a minimum, include security specifications and design reviews and
systems tests. . . .

(2) Periodic Review and Re-certification. . . . Audits or reviews shall evalu-
ate the adequacy of implemented safeguards, assure they are functioning
properly, identify vulnerabilities that could heighten threats to sensitive data
or valuable resources, and assist with the implementation of new safeguards
where required. . . .

A.8.1 Cross-References and Comments

TABLE A-17. OMB Circular No. A-130-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

8(a)(1)

X

X

X

8(a)(2)

X

X

X

X

X

8(a)(3)

X

8(a)(4)

X

8(a)(5)

X

X

X

8(a)(6)

X

8(a)(7)

X

X

8(a)(8-11)

X

8(a)(12)

X

X

8(b)(1)

X

8(b)(2)

X

8(b)(3)

X

8(b)(4-5)

X

8(b)(6)

X

8(b)(8)

X

X

8(b)(9)

X

8(b)(11)

X

X

8(b)(12)

X

X

X

X

X

X

8(b)(13)

X

X

X

8(b)(15)

X

X

App.I(4)

X

App.II(Sup.Info.)

X

X

App.III(2)(c)

X

X

X

X

X

App.III(2)(d)

X

X

X

X

X

App.III(3)

X

App.III(3)(a)(1-2)

X

8(a)(1)

[Security Policy] Each phase of the information life cycle (e.g., origin or acquisition
through final disposition). should be considered in formulating the Security Policy. Only
information necessary for proper performance of agency functions, and that has practical
utility shall be created or collected. Practical utility includes characteristics ``pertaining
to the quality of information such as accuracy, adequacy, and reliability.'' In the case of
general purpose statistics or record keeping, practical utility means that ``actual uses can
be demonstrated . . .'' [OMB A-130, p. 52746]. Execution authority is derived from the
required, approved plans for the processing, transmission, dissemination, use, storage,
and disposition of necessary information. The delegation of authority and allocation of
resource responsibilities shall be performed for each aspect of the information life cycle.
[Accountability] This implies that individuals should be held accountable to performing
within the scope of their authority. [Assurance] The documentation of required planning
may be used as an assurance measure.

8(a)(2)

[Security Policy] This implies that the Security Policy must address the protection of
shared information. Sharing should be done under the concept of ``due care'' (i.e., protec-
tion commensurate with the risk and magnitude of loss). [MAC, DAC, Marking] The es-
tablishment of information sharing agreements must include confirmation that the receiv-
ing Agency can mark and protect the shared information as required by the providing
Agency. If such protection is not possible, then the providing Agency must determine
the need to desensitize the information to the degree commensurate with the maximum
protection capabilities of the receiving Agency prior to actual sharing. [Accountability]
The receiving Agency should be accountable for the protection of any shared informa-
tion it receives. The providing Agency is accountable for the sharing of sensitive infor-
mation for which the receiving Agency does not have the capabilities to protect.

8(a)(3)

[Security Policy] The collection of individually identifiable and proprietary information
must be limited to that which is legally authorized and necessary for agency functions.

8(a)(4)

[Security Policy] Confidentiality requirements must be addressed in the Security Policy.

8(a)(5)

[Security Policy] Providing a process for individuals to gain access to personal informa-
tion is required. [Accountability, Assurance] An amendment and error correcting process
for private information must exist.

8(a)(6)

[Security Policy] Providing a process for public access may be required. This process
shall be consistent with Freedom of Information Act requirements and exemptions.

8(a)(7)

[Accountability] This implies that individuals shall be held accountable for adhering to
doctrine and procedures in which they have been trained. [Assurance] Security training
and documentation in support of security training is required. Such documentation
should cover the information life cycle processes, safeguards employed, and individual
responsibilities.

8(a)(8-11)

[Security Policy] Dissemination of information on Agency information life cycle process-
es is required, as required under applicable laws or other relevant policies.

8(a)(12)

[Accountability] Procedures for periodic reviews of information life cycle processes are
required. [Assurance] Assurance of compliance to laws for dissemination is required.

8(b)(1)

[Accountability] Technical protection of information as a part of program and mission
needs must be planned for, taking into account budget constraints. The Paperwork Re-
duction Act requires that OMB: ``promote the use of the technology to improve govern-
mental efficiency and effectiveness. . . .''

8(b)(2)

[Assurance] Information systems requirements documentation is necessary. Periodic re-
views are required.

8(b)(3)

[Accountability] Overall information product accountability is user based. Specific ac-
countability for information products is established at the supported program official.

8(b)(4-5)

[Security Policy] Requirements for the sharing of information are outlined. Specific
Agency policies regarding information sharing should be established.

8(b)(6)

[Assurance] Total life cycle costs must be considered in protection technology acquisi-
tion. This should be coupled to the Agency risk assessment.

8(b)(8)

[Security Policy] The use (in terms of trustedness) of commercial, off-the-shelf software
must be reflected in the Security Policy. [Assurance] ``Trustedness'' implies that process
for evaluation of the vulnerabilities of commercial, off-the-shelf software should be es-
tablished. The evaluated software must be placed under configuration management once
it is accepted.

8(b)(9)

[Assurance] Necessary compatibility is considered because ``compatibility among infor-
mation systems has . . . emerged as a significant information resources management
problem . . .'' [OMB A-130, p. 52749]. Necessary compatibility for integrity protection
is required.

8(b)(11)

[Security Policy, Assurance] Security features must be adequate for protection with re-
gards to the sensitivity of the information and/or application as determined by the Agen-
cy risk assessment.

8(b)(12)

[Security Policy, MAC, DAC, Marking, Accountability, Assurance] Authorized access
to information systems must be assured. This implies an extension of authorized access
to specific information.

8(b)(13)

[Security Policy, Fault Tolerance] Reasonable continuity of support shall be provided
for information systems. [Assurance] Contingencies should not only be planned for but
also routinely exercised whenever practicable.

8(b)(15)

[Security Policy] This implies a thorough risk assessment has been conducted and that
specific protection policy enforcement needs have been identified as being both required
and cost effective. [Assurance] Periodic reviews are required.

App.I(4)

[Accountability] Changes to types or categories of information being maintained, or the
purposes to which information is being put to use, must be reported.

App.II Sup.Info.

[Security Policy] A user has control over assigned resources. [Accountability] A manag-
er must know the amount of resources consumed by each user. A user is responsible for
assigned resources.

App.III(2)(c)

[Security Policy] Defines the type of information applicable under this Circular. Indi-
cates an increased scope of Security Policy-in particular, the systems containing ``sensi-
tive information'' must be protected. [MAC, DAC] Because the control of ``unauthorized
use'' is explicitly called for, authorization features are required. [Marking] ``Sensitive in-
formation'' must be identifiable. [Accountability] Authorization implies the requirement
for accountability for acting within the scope of authority.

App.III(2)(d)

[Security Policy] Defines the type of application applicable under this Circular. The as-
sessment of risk, loss, or harm resulting from improper operation or deliberate manipula-
tion of an application should be applied to all applications, including embedded applica-
tion or control systems, in order to determine their ``sensitivity.'' [MAC, DAC] Because
the control of ``improper operation'' or ``deliberate manipulation'' is explicitly called for,
authorization features are required. [Marking] ``Sensitive applications'' must be identifia-
ble. [Accountability] Authorization implies the requirement for accountability for acting
within the scope of authority.

App.III(3)

[Security Policy] Requires the preparation and maintenance of security policies, stand-
ards, and procedures. Outlines basic considerations and the sources of policy for security
programs.

App.III (3)(a)(1-2)

[Assurance] Agencies shall assure that appropriate safeguards are incorporated into all
new or modified applications. The adequacy of implemented safeguards shall be evaluat-
ed and vulnerabilities identified. Periodic reviews are required.

A.9 OMB Circular No. A-123-Internal Control Systems

OMB Circular No. A-123 directs agency heads and managers to set up management
plans and to take responsibility for eliminating fraud, waste, and abuse in government
programs. The aim of this program is to establish confidence and accountability in the
protection of Federal operations [Russell 1991, p. 279].

Internal controls are of significance primarily because of the increasing use of
automation for both the major applications and the internal control systems of
government programs. The Budget and Accounting Act of 1950 sets forth the
requirement for each department and agency to establish and maintain adequate
systems of internal control. The Federal Managers' Financial Integrity Act amended this
earlier Act, adding requirements for (a) the development of internal accounting and
administrative control standards by the General Accounting Office, (b) annual
evaluations of internal accounting and administrative control systems in accordance
with guidelines established by OMB, and (c) annual statements on the status of the
agency's system of internal controls. AISs which are integral to internal control systems
must adhere to the standards and guidelines prescribed in this Circular.

The following table contains selected sections of OMB Circular No. A-123. The cross-
reference table and comments appear in the next section.

TABLE A-18. OMB Circular No. A-123-Selected Source Text

1. Purpose. This circular prescribes policies and procedures to be followed by executive
departments and agencies in establishing, maintaining, evaluating, improving, and report-
ing on internal controls in their program and administrative activities.

4. Policy. Agencies shall establish and maintain a cost effective system of internal con-
trols to provide reasonable assurance that Government resources are protected against
fraud, waste, mismanagement or misappropriation and that both existing and new pro-
gram and administrative activities are effectively and efficiently managed to achieve the
goals of the agency. The system shall comply with the Integrity Act and the internal con-
trol standards developed by the General Accounting Office and implemented by this cir-
cular. All levels of management shall be involved in ensuring the adequacy of controls.
Internal control does not encompass such matters as statutory development or interpreta-
tion, determination of program need, resource allocation, rule-making, or other discre-
tionary policy-making processes in an agency.

7. Objectives of Internal Control. The objectives of internal control apply to all program
and administrative activities. Internal control systems are to provide management with
reasonable assurance that:

a. Obligations and costs comply with applicable law.

b. Assets are safeguarded against waste, loss, unauthorized use, and misappropria-
tion.

c. Revenues and expenditures applicable to agency operations are recorded and ac-
counted for properly so that accounts and reliable financial and statistical reports
may be prepared and accountability of the assets may be maintained.

d. Programs are efficiently and effectively carried out in accordance with applica-
ble law and management policy.

8. Required Agency Actions. Each agency shall meet the following requirements in a
cost-effective manner.

a. Maintain a current internal control directive assigning management responsibili-
ty for internal controls in accordance with this circular and the [OMB] Internal
Control Guidelines with the following provisions. Provide for coordination on in-
ternal control matters among the designated internal control official, heads of agen-
cy components, program managers and staffs, and the IG [Inspector General] of-
fice or its equivalent. Establish administrative procedures to enforce the intended
functioning of internal controls. . . .

b. Develop a Management Control Plan (MCP) or plans to be updated annually.
The primary purpose of an MCP is to identify component inventory, to show risk
rating of component (high, medium, low), and to provide for necessary evaluations
over a five-year period. Material weaknesses and other areas of management con-
cern may also be monitored through the plan. High risk components and material
weaknesses must be acted upon during the first year of the plan. The plan should
be based upon the schedule of actions in each major component, and identify the
senior managers responsible. Management should utilize the plan for monitoring
progress and ensuring that planned actions are in fact taken. MCP's are intended to
be part of each agency's overall planning process and at a minimum should be
linked to activities under [OMB Circulars] A-127 and A-130. . . .

c. Make risk assessments to identify potential risks in agency operations which re-
quire corrective action or further investigation through internal control evaluations
or other actions. These may follow the vulnerability assessment procedures in the
[OMB] Internal Control Guidelines or may be based on a systematic review build-
ing on management's knowledge, information obtained from management report-
ing systems, previous risk assessments, audits, etc. . . . Risk assessment on new or
substantially revised programs should occur as part of planning for implementation
and the results reflected in the MCP. Risk assessments are to be considered as part
of developing the MCP.

d. Make internal control evaluations using the procedures in the [OMB] Internal
Control Guidelines or alternative reviews to determine whether the internal control
system is effective and is operating in compliance with the Integrity Act and this
circular. These reviews should identify internal controls that need to be strength-
ened or streamlined. The composite of all information that management relies
upon to judge their systems effectiveness must include information on the results
of tests of their operating internal control systems

e. Implement corrective actions identified by agency internal control evaluation ef-
forts on a timely basis. A formal follow-up system should be established that
records and tracks recommendations and projected action dates, and monitors
whether the changes are made as scheduled. The tracking systems should be made
part of broader agency management reporting systems whenever feasible.

A.9.1 Cross-References and Comments

TABLE A-19. OMB Circular No. A-123-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

4

X

X

X

X

X

X

7(a)

X

X

7(b)

X

7(c)

X

8(a)

X

X

X

8(b)

X

X

X

8(c)

X

X

8(d)

X

X

8(e)

X

X

4

[Security Policy, MAC, DAC, Marking] An internal control system shall protect against
fraud, waste, mismanagement, and misappropriation. Implementation of internal control
systems must be in accordance with GAO standards. Efficient and effective management
of program activities implies the implementation of abstractions to bind users with ac-
tions (roles) and actions with appropriate object types (duties). This implies both sys-
tems and application-specific security policies. [Accountability, Assurance] Program and
administrative activities must be effective and efficient. Reasonable assurance is required.

7(a)

[Security Policy] Applicable laws related to obligations and costs must be addressed.
[Accountability] Obligations and costs must be adequately recorded and reported.

7(b)

[Security Policy] AIS resources which represent program assets must be safeguarded
against waste, loss, unauthorized use, and misappropriation.

7(c)

[Accountability] Operational revenue and expenditures must be recorded and reported.

8(a)

[Security Policy] Each agency shall maintain a current directive which implements inter-
nal control policy in accordance with this Circular and OMB guidelines. [Accountabili-
ty] Coordination with other entities is required. [Assurance] Administrative procedures
to enforce internal controls must be established. The implication that some of these pro-
cedures may be implemented (either partially or totally) within AISs requires that all pro-
cedures should be well-documented and that agency personnel must be trained properly
to carry them out.

8(b)

[Security Policy, Accountability] Development and maintenance of a Management Con-
trol Plan is required. Component inventories must be established. Monitoring of weak-
nesses implies features for tracking and reporting. [Assurance] Evaluation and risk rat-
ing of internal controls is required.

8(c)

[Accountability, Assurance] Risk assessments for agency operations is required. Risk as-
sessments may require follow-on, corrective actions.

8(d)

[Accountability] This implies that responsibilities for internal control systems have been
established and that the responsible individuals shall be held accountable for the proper
functioning of those systems. [Assurance] Internal control evaluations are required. Iden-
tification of weaknesses is required. Results of tests must be relied upon for manage-
ment to judge systems' effectiveness.

8(e)

[Accountability, Assurance] Corrective actions must be implemented on a timely basis.
Recording and monitoring of identified corrective actions is required.

A.10 OMB Bulletin No. 90-08-Guidance for Preparation of Security Plans
for Federal Computer Systems that Contain Sensitive Information

This Bulletin provides guidance for computer security planning activities required
under the Computer Security Act of 1987. The Bulletin does not apply to systems that
contain classified information, systems involving intelligence activities, cryptologic
activities related to national security, or direct command and control of military forces.
The Bulletin also does not apply to equipment that (a) is integral to a weapons system,
(b) is used in the direct fulfillment of military or intelligence missions, or (c) to mixed
classified and unclassified systems, if such systems are always operated under rules for
protecting classified information.

Computer security planning is intended to improve protection of information and other
information processing resources. In order to be adequate for the protection of resources,
computer security plans must address the areas of loss, misuse, unauthorized access or
modification, unavailability, and undetected activities. The controls to be addressed by
computer security planning described in this Bulletin address both major applications
and general support systems. These controls are derived from requirements and
guidance in the Computer Security Act of 1987, OMB Circular No. A-130, and applicable
Federal Information Processing Standards (FIPS) and Special Publications produced by
NIST.

The following table contains selected sections of OMB Bulletin No. 90-08. The cross-
reference table and comments appear in the next section.

TABLE A-20. OMB Bulletin No. 90-08-Selected Source Text

1. Purpose. The purpose of this Bulletin is to provide guidance to Federal agencies on
computer security planning activities required by the Computer Security Act of 1987.
This Bulletin supersedes OMB Bulletin No. 88-18, Guidance for Preparation and Sub-
mission of Security Plans for Federal Computer Systems Containing Sensitive Informa-
tion (July 6, 1988).

3. Objectives of the Security Planning Process. The security planning process is de-
signed to reduce the risk and magnitude of harm that could result from the loss, misuses
or unauthorized access to or modification of information in Federal computer systems. .
. .

6. Action Required.

a. Every agency must implement security plans for systems which contain sensi-
tive information, incorporating appropriate advice and comment from NIST/NSA.

b. Every agency must prepare a new computer security plan for each system that
contains sensitive information, if:

(1) the system is new or significantly modified; or

(2) a plan for the system was not previously sent to NIST/NSA for advice
and comment (particular emphasis should be on contractor, State, and local
systems operated on behalf of the agency to perform a Federal function); or

(3) staff members of NIST/NSA advised the agency they were unable to pro-
vide advice and comment on the previous plan for the system.

c. Every agency must establish a process to ensure that independent advice and
comment on each plan developed in accordance with Section 6.b, above, is provid-
ed. Such advice and comment should be provided prior to developing a new sys-
tem or significantly modifying an existing system.

d. Every agency must ensure that security plans incorporate appropriate internal
control corrective actions identified pursuant to OMB Circular No. A-123.

e. Every agency must prepare materials as described in Section 8, meet with
OMB, NIST, and NSA staff as described in Section 7, and work with NIST and
NSA to improve agency computer security.

7. Assistance Visits.

a. Agencies will be scheduled for visits by OMB, NIST, and NSA staff.

b. Among the items to be discussed will be:

(1) The completeness of identification of sensitive computer systems;

(2) The quality, scope, and thoroughness of security plans;

(3) Any internal control weaknesses identified pursuant to OMB Circular
No. A-123 related to computer systems, and plans for addressing those weak-
nesses;

(4) For agencies subject to OMB Bulletin No. 89-17, ``Federal Information
Systems and Technology Planning'' their response to that Bulletin;

(5) Material available in accordance with Section 8, below.

c. Agencies should also be prepared to discuss the approach that is being taken to
ensure that computer security plans for new or modified computer systems are pre-
pared and reviewed.

8. Material for Meetings. Agencies should, at a minimum, have the following informa-
tion available:

a. agency-wide computer security policies and a summary of agency computer se-
curity procedures, standards, and requirements;

b. agency assignment of responsibilities for implementation and operation of the
security program;

c. the agency management plan for ensuring implementation of system computer
security plans that includes a description of:

(1) the involvement of agency management,

(2) how computer security plans are being integrated into information re-
sources management plans,

(3) the approach for ensuring that funds, personnel and equipment are
planned for and budgeted, and

(4) the implementation schedule;

d. the method used to identify the agency's sensitive systems;

e. any know agency needs for guidance or assistance.

Appendix A-Instructions for Preparing System Security Plans

I. System Identification

This section of the plan contains basic identifying information about the system.

C. System Category - Categorize each system as either a major application, or as a
general support system, in line with the primary management responsibility for the
system.

Major application. These are systems that perform clearly defined functions
for which there are readily identifiable security considerations and needs.
Such a system might actually comprise many individual application pro-
grams and hardware, software, and telecommunications components.

General support system. These consist of hardware and software that provide
general ADP or network support for a variety of users and applications. Indi-
vidual applications may be less easily distinguishable than in the previous
category, but such applications may contain sensitive information. Even if
none of the individual applications are sensitive, however, the support sys-
tem itself may be considered sensitive if overall, the aggregate of applica-
tions and support provided are critical to the mission of the agency.

II. Sensitivity of Information Handled

This section should provide a description of the types of information handled by the sys-
tem and thus provide the basis for the system's security requirements. It should contain
the following information:

A. Applicable Laws or Regulations Affecting the System . . .

B. General Description of Information Sensitivity - The purpose of this section is
to indicate the type and relative importance of protection needed for the identified
system. A system may need protection for one or more of the following reasons:

Confidentiality - The system contains information that requires protection
from unauthorized disclosure. Examples: timed dissemination (e.g., crop re-
port data), personal data (covered by Privacy Act), proprietary business infor-
mation.

Integrity - The system contains information which must be protected from au-
thorized, unanticipated or unintentional modification, including the detection
of such activities. Examples: systems critical to safety or life support, finan-
cial transaction systems.

Availability - The system contains information or provides services which
must be available on a timely basis to meet mission requirements or to avoid
substantial losses. Examples: air traffic control, economic indicators, or hurri-
cane forecasting.

III. System Security Measures

C. Security Control Measures - Two sets of controls are discussed on subsequent
pages - one for Major Applications and the other for General Support Systems . . .

E. Security Controls Measures for Major Applications

1. Management Controls - overall management controls of the application
system.

a. Assignment of Security Responsibility - Responsibility for the securi-
ty of the application should be assigned.

b. Personnel Screening - Personnel security policies and procedures
should be in place and working to limit access to and processing with-
in the application system to those with a need for such access. Where
appropriate, the duties of those with access should be separated. Addi-
tionally, requirements such as screening individuals with access to the
application as well as those participating in the design, development,
operation, or maintenance of it may be used.

2. Development/Implementation Controls - procedures to assure protection is
built into the system, especially during system development.

a. Security Specification - Appropriate technical, administrative, physi-
cal, and personnel security requirements should be specified for the ap-
plication. . . .

b. Design Review and Testing . . .

c. Certification - Prior to the application being put into operation, and
agency official should certify that the application meets all applicable
Federal policies, regulations, and standards, and that the protection
measures appear adequate. . . .

3. Operational Controls - day-to-day procedures and mechanisms to protect
operational application systems (or planned applications when they become
operational). . . .

a. Physical & Environmental Protection . . .

b. Production, I/O Controls - Controls over the proper handling,
processing, storage, and disposal of input and output data and media,
as well as access controls (such as labeling and distribution proce-
dures) on the data and media. . . .

c. Emergency, Backup, and Contingency Planning . . .

d. Audit and Variance Detection - Controls which allow management
to conduct an independent review or records and activities to test the
adequacy of controls, and to detect and react to departures from estab-
lished policies, rules, and procedures. Variance detection for an applica-
tion checks for anomalies in such things as the numbers and types of
transactions, volume and dollar thresholds, and other deviations from
standard activity profiles.

e. Application Software Maintenance Controls - Controls used to moni-
tor the installation of the updates to application software to ensure that
the software functions as expected and that an historical record is main-
tained of application system changes. Such controls also help to ensure
that only authorized software is allowed on the systems. These controls
may include software configuration policy that grants managerial ap-
proval to modifications, then documents the changes. They may also in-
clude some products used for ``virus'' protection.

f. Documentation . . .

4. Security Awareness and Training . . .

5. Technical Controls - hardware and software controls used to provide auto-
mated and/or facilitate manual protection. Normally these types of controls
are coordinated with the network and/or data center manager.

a. User Identification and Authentication - Controls used to identify or
verify the eligibility of a station, originator, or individual to access spe-
cific categories of information, to perform an activity, or to verify the
integrity of data that have been stored, transmitted, or otherwise ex-
posed to possible unauthorized modification. Such controls include the
use of passwords, tokens, biometrics or other personal mechanisms to
authenticate identity.

b. Authorization/Access Controls - Hardware or software features that
are designed to permit only authorized access to or within the applica-
tion, to restrict users to authorized transactions and functions, and/or to
detect unauthorized activities (e.g., access control lists).

c. Data Integrity/Validation Controls - Controls used to protect data
from accidental or malicious alteration or destruction, and provide as-
surance to the user that the data meets an expectation about its quality
(e.g., [electronic funds transfer] EFT message authentication). Valida-
tion controls refer to tests and evaluations used to determine compli-
ance with security specification and requirements.

d. Audit Trails and Journaling - Controls that provide a transaction
monitoring capability with a chronological record of application activi-
ties. This enables reconstruction of a transaction from its inception to
final results-including any modification of files.

F. Security Controls Measures for General Support Systems

1. Management Controls - overall management controls of the general sup-
port system.

a. Assignment of Security Responsibility . . .

b. Risk analysis . . .

c. Personnel Screening - Personnel security policies and procedures
should be in place and working to control access to and within the sup-
port system to assure that only those with a need for access have it.
Such policies and procedures may include requirements for screening
individuals involved in the operation, management, security, design,
programming, or maintenance of the system.

2. Acquisition/Development/Installation Controls - procedures to assure that
protection is built into the system.

a. Acquisition Specifications - Appropriate technical, administrative,
physical, and personnel security requirements are to be included in
specifications for the acquisition or operation of information technolo-
gy installations, equipment, software, and related services.

b. Accreditation/Certification . . .

3. Operational Controls - day-to-day procedures and mechanisms to protect
operational systems.

a. Physical & Environmental Protection . . .

b. Production, I/O Controls - Controls over the handling, processing,
storage, and disposal of input and output from the support system (e.g.,
controlled or locked output boxes, tape or data screening, etc.).

c. Emergency, Backup, and Contingency Planning . . .

d. Audit and Variance Detection . . .

e. Hardware and System Software Maintenance Controls . . .

f. Documentation . . .

4. Security Awareness and Training . . .

5. Technical Controls - hardware and software controls to protect the general
support systems from unauthorized access or misuse, to facilitate detection
of security violations, and to support security requirements for associated ap-
plications.

a. User Identification and Authentication - Controls used to verify the
identity of a station, originator, or individual prior to allowing access
to the system, or specific categories of information within the system. .
. .

b. Authorization/Access Controls - Hardware or software features used
to detect and/or permit only authorized access to or within the system
(e.g., the use of access lists). Includes controls to restrict access to the
operating system, limits on access to programming resources, and con-
trols to support security policies of associated applications.

c. Integrity Controls - Controls used to protect the operating system, ap-
plications and information in the system from accidental or malicious
alteration or destruction, and provide assurance to users that data has
not been altered (e.g., message authentication). . . .

d. Audit Trail Mechanisms . . .

e. Confidentiality Controls . . .

A.10.1 Cross-References and Comments

TABLE A-21. OMB Bulletin No. 90-08-Cross-References

Section

Security Policy

MAC

DAC

Marking

Accountability

Assurance

Fault Tolerance

App.A(I)(C)

X

App.A(II)(A-B)

X

App.A(III)(E)(1-5)

X

X

X

X

X

X

X

App.A(III)(F)(1-5)

X

X

X

X

X

X

X

App.A(I)(C)

[Security Policy] In general, any particular AIS may provide (partial or total) automa-
tion of a major application while at the same time serving as a general support system.
For example, a logistics DBMS [data base management system] might be considered to
be a major application, and hence represents the automation of a major service provided
by a component. At the same time, the AIS(s) on which the DBMS resides may provide
various applications which support the functioning of that component itself, such as a
payroll or other management system. At a minimum, the operation system of AIS can
be considered as providing general support. Thus, such an AIS would be called upon to
support (possibly) diverse protection policies. The Security Policy must represent an inte-
gration of protection policies associated with both the major applications and the general
support systems provided by the AIS.

App.A

(II)(A-B)

[Security Policy] The general scope of the type of information to be protected under sys-
tem security policies is defined. The availability are explicitly included. Other control ob-
jectives are affected by these concerns. Notably, fault tolerance and assurance for safety-
critical systems are implied.

App.A

(III)(E)(1-5)

[Security Policy, MAC, DAC, Marking, Accountability, Assurance, Fault Tolerance]
This section outlines a variety of computer security controls (e.g., management, develop-
ment, operational, and technical) which apply to major application subsystems. In gener-
al, control systems extend beyond the boundaries of automated systems. However, in
many cases, support for or enforcement of necessary controls can be generalized and in-
tegrated into an AIS via automated mechanisms. Significantly, these controls are analo-
gous to those traditionally associated with, and provided by, operating systems-yet con-
trol requirements may be unique on an application-by-application basis. This may imply
an increased functionality over current AIS security kernel designs to allow for the en-
forcement of multiple, independent security policies. All control objectives are affected.

App.A

(III)(F)(1-5)

[Security Policy, MAC, DAC, Marking, Accountability, Assurance, Fault Tolerance]
This section outlines a variety of computer security controls which are associated with
the traditional notion of a system. These controls essentially apply to the enforcement of
a system-wide security policy. However, under the Computer Security Act of 1987, sen-
sitive information must now be taken into account. Also, the requirements associated
with major applications must also be incorporated. Hence, all control objectives are af-
fected.

A.11 [OMB] Internal Control Guidelines

The Federal Managers' Financial Integrity Act requires sets forth requirements for
internal accounting and administrative controls within Executive agencies, and requires
that OMB establish-in consultation with the Comptroller General of the United States-
guidelines for the evaluation of these controls. This document embodies the guidelines
required to be developed by OMB under this Act.

The following table contains selected sections of the Guidelines. The cross-reference
table and comments appear in the next section. Some of the numbering below does not
occur in the original source text-it is included to aid in the clarity of cross-referenced
comments. Because of the comprehensive nature of these guidelines, only brief examples
related to AIS security will be highlighted and commented upon. The Guidelines should
be consulted for required details.

TABLE A-22. [OMB] Internal Control Guidelines-Selected Source Text

Chapter IV - Vulnerability Assessments

Analysis of General Control Environment

Several factors determine the general control environment, including the following . . . :

· ADP [Automated Data Processing] Consideration - When utilized, an awareness of
the strengths and exposures inherent in a system that uses ADP and the existence
of appropriate controls. . . .

Chapter V - Internal Control Reviews

Identification of the Event Cycles

Event cycles are the processes used to initiate and perform related activities, create the
necessary documentation, and gather and report related data. In other words, an event cy-
cle is a series of steps taken to get something done. Each program and administrative
function performed within an agency or agency component contains one or more event
cycles. For example, an entitlement program could contain the following event cycles:
information gathering and verification, eligibility determination, information processing
and record keeping, payment, and monitoring. The event cycles for an administrative
function could include payroll, procurement of supplies and materials, correspondence
handling, etc. (Appendices B and B-1 present event cycles commonly found in Federal
Government agencies. The General Accounting Office, professional associations, and pri-
vate organizations also publish lists of common event cycles). . . .

Evaluation of the Internal Controls within the Event Cycle

. . . The manner in which this is done is to:

· Ascertain the control objective for the event cycle. . .

· Examine the documentation and ascertain whether appropriate internal control tech-
niques are in place to enable the control objective to be met in an efficient and ef-
fective manner. Internal control techniques are the processes or documents that en-
able the control objective to be achieved. . . .

· Identify whether there are any internal control techniques that are excessive, . . .

Glossary

Assessable Unit - A program or administrative function or subdivision thereof
which is to be the subject of a vulnerability assessment.

Control Objective - A desired goal or condition for a specific event cycle that re-
flects the application of the overall objectives of internal control to that specific cy-
cle.

Event Cycle - The processes used to initiate and perform related activities, create
the necessary documentation, and gather and report related data.

Inherent Risk - The inherent potential for waste, loss, unauthorized use, or misap-
propriation due to the nature of an activity itself.

Internal Control - The steps that an agency takes to provide reasonable assurance
that obligations and costs are in compliance with applicable law; funds, property,
and other assets are safeguarded against waste, loss, unauthorized use, or misappro-
priation; and revenues and expenditures applicable to agency operations are proper-
ly recorded and accounted for to permit the preparation of accounts and reliable fi-
nancial and statistical reports and to maintain accountability over the assets.

Internal Control System - The sum of the organization's methods and measures
used to achieve the objectives of internal control.

Internal Control Technique - A process or document that is being relied on to effi-
ciently and effectively accomplish a control objective and thus help safeguard an
activity from waste, loss, unauthorized use, or misappropriation.

Appendix B - Common Event Cycles and Suggested Control Objectives in Federal Agen-
cies

This appendix presents a list of event cycles commonly found in Federal agencies and
agency components. Also included are certain types of assets that are highly susceptible
to loss and for which controls are vital, e.g., cash, materials and supplies. Finally, the
list provides suggested control objectives for each event cycle/type of asset. . . .

[In addition to the AIS-specific event cycle examples listed below, other common event
cycles address such areas as Operations, Internal Management and Administration, and
Assets and Liabilities. We have included source text dealing with Information Process-
ing and Reporting because these event cycles are directly related to all aspects of auto-
mated processing. However, in general, many of the other common event cycles and sug-
gested control objectives cited in this section will need to be considered in formulating
AIS Security Policy.]

III. Information Processing and Reporting Cycles

A. Information Collection

The primary internal control objectives normally associated with information
collection are the following:

(1) Information collected is meaningful and useful.

(2) Information collected is reliable.

(3) Information is arranged in an orderly fashion.

(4) Information is maintained on a current basis.

B. Records Maintenance

The primary internal control objectives normally associated with records
maintenance are the following:

(1) Records are readily available.

(2) Records are adequately protected.

(3) Only necessary records are retained.

C. Automatic Data Processing

The primary internal control objectives normally associated with automatic
data processing are the following:

(1) Proper authorization of transaction inputs, adequate edit checks, and nec-
essary safeguards of sensitive input forms to insure accurate, proper, com-
plete and timely entry of information.

(2) Data is safeguarded to prevent unauthorized access, improper changes, or
loss.

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close