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