13 May 1992 DRAFT IDA DOCUMENT D-967 INTEGRITY-ORIENTED CONTROL OBJECTIVES: PROPOSED REVISIONS TO THE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA (TCSEC), DoD 5200.28-STD Terry Mayfield John M. Boone Steven R. Welke August 1991 This document is still subject to modification or withdrawal and therefore may not be referenced in any publication. It also should not be duplicated. Prepared for National Security Agency INSTITUTE FOR DEFENSE ANALYSES 1801 N. Beauregard Street, Alexandria, Virginia 22311 DRAFT 1. INTRODUCTION 1.1 PURPOSE This document proposes new and revised versions of the control objectives contained in the Trusted Computer System Evaluation Criteria (TCSEC), DoD 5200.28-STD [TCSEC 1985, pp. 57-63]. These modifications extend the existing control objective statements to encompass the promotion and preservation of data and systems integrity. They are intended to be used as a strawman to foster further research and debate aimed at developing a new or revised set of product evaluation criteria that addresses integrity as well as confidentiality. 1.2 BACKGROUND Control objectives are the fundamental computer security requirements as they apply to general purpose automated information systems (AISs). As such, they serve as guidance to the development of more specific evaluation criteria. Evaluation criteria, in turn, are intended to ``... (a) provide users with a yardstick with which to assess the degree of trust that can be placed in computer systems for processing classified or other sensitive information; (b) provide guidance to manufacturers as to what to build into their new widely-available trusted commercial products in order to satisfy trust requirements for sensitive applications; and (c) provide a basis for specifying security requirements in acquisition specifications'' [TCSEC 1985, p. v]. Given the rather far reaching implications of evaluation criteria, it is vital that such criteria be built upon a clear and complete foundation. The modified control objectives presented in this document represent only one step towards that foundation. This step, directed towards enhancing the set of control objectives to address the needs of integrity, begins the enabling for the development of new criteria. However, the proposed control objectives are not intended to be adopted without further research and debate to derive the best possible foundation for further development work. 1.3 SCOPE This document extends the integrity framework developed in [Mayfield 1991] and takes another step in developing and evolving product criteria that include integrity. The document only addresses control objectives; specific criteria addressing integrity concerns remain as future work. The document is complementary to other ongoing research work in the topic of integrity, e.g., the electronic forum for the development of new formal models of integrity in preparation for The Computer Security Foundations Workshop IV which was held in Franconia, New Hampshire, 18-20 June 1991. The document assumes that the control objectives for confidentiality, as contained in the TCSEC, are adequate for that purpose. Through the study of relevant policies, we have come to believe that the control objectives need to extend to applications running on a vendor's system product in order to adequately address boundaries of responsibility and criteria for implementing protection controls. However, this study concentrates primarily on control objectives from a systems perspective-the issues involved with extending the control objectives to applications cannot be explored in depth until a systems perspective has been established. We do not make use of a particular formal model of integrity, but rather use some of the concepts developed and modeled by various model authors to arrive at our specific version of each control objective. We have purposefully tried to not depart radically from the TCSEC. Our thinking was that it would be much more beneficial to show minimal changes while increasing support to various integrity policies than to try and "reinvent the wheel." To some, these changes may still seem too radical, to others they will be insufficient. We hope that in both cases our proposals serve to enhance the debate. The major policy documents, with respect to integrity in AISs, are listed in Table 1.1. These documents are addressed individually in separate sections in Appendix A. Each individual section devoted to a particular document contains (a) a brief overview of the document, (b) a listing of selected source text from the document, (c) a cross-reference from the source text to affected integrity control objectives, and (d) a commentary section. The commentary section is, in essence, a set of interpretive notes about control aspects of the source text. We developed them to partially confirm, from a policy point of view, what we had discovered in [Mayfield 1991] through an analysis of various integrity-supporting mechanisms about possible objectives for control. These government documents provide policy and guidance for controlling and protecting information. Their contents can be interpreted in at least three distinct ways: (1) having direct applicability to the certification of an Agency's system as part of the process of obtaining an accreditation for system operations, (2) having direct applicability to general application subsystems as evaluated subsystem products, and (3) having applicability across a wide range of applications wherein the protection mechanisms might generally provided by the underlying computer system (i.e., hardware, operating system, and communications subsystems). While our control objectives are directed at the third interpretation, the reader will find that we did not similarly confine our commentary notes on the selected policy text contained in Appendix A. Our intention in the latter was to take a much broader system perspective and then selectively use the material in supporting the specific wording of our control objective proposals. TABLE 1.1. List of Policy Documents POLICY DOCUMENT TITLE FEDERAL LAWS Public Law 92-579 The Privacy Act of 1974 Public Law 101-508 Computer Matching and Privacy Protection Amendments of 1990 Public Law 96-511 The Paperwork Reduction Act of 1980 Public Law 97-255 Federal Manager's Financial Integrity Act of 1982 Public Law 97-86 DoD Authorization Act of 1982 Public Law 100-235 Computer Security Act of 1987 EXECUTIVE/LEGISLATIVE OMB Circular No. A-127 Financial Management Systems OMB Circular No. A-130 Management of Federal Information Resources OMB Circular No. A-123 Internal Control Systems OMB Bulletin No. 90-08 Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information OMB IC Guidelines Internal Control Guidelines GAO Title II GAO Policy and Procedures Manual for Guidance of Federal Agencies-Title 2 - Accounting DEPARTMENT OF DEFENSE DoD Directive 5010.38 Internal Management Control Program DoD Directive 5200.28 Security Requirements for Automated Information Systems DoD Directive 7740.1 DoD Information Resource Management Program DoD Guideline 7740.1-G ADP Internal Control Guideline DoD Directive 7750.5 Management and Control of Information Requirements 2. PROPOSED CONTROL OBJECTIVES The proposed control objective revisions contain the following major elements: (1) an introduction to the control objective, (2) the original and revised control objectives, and (3) a discussion of issues and rationale for revising the control objective. The discussion and supporting rationale are intended to be useful whether the original control objectives are to be modified as we propose, or entirely new control objectives are to be developed. When broadening the scope of the TCSEC to include integrity, we must consider the effect upon the existing control objectives. There are two basic considerations: (1) whether integrity policies call for additional technical features to be included in the control statements, and (2) whether the existing abstractions currently associated with the statements of control are adequate, given the increased scope of protection. Each factor could have a subsequent effect on the control objective. The requirement for additional technical features would compel a modification to the control objective itself and is reflected in the proposed revisions. Generalizing control abstractions would require a change in the interpretation of the statements of control. These interpretation changes are noted in the discussion section of each affected revision. As stated in the TCSEC [1985, p. 71], ``There is a large body of policy laid down in the form of Regulations, Directives, Office of Management and Budget (OMB) Circulars, Presidential Executive Orders, and Laws that form the basis for the handling and processing of Federal information in general and classified information specifically.'' We follow the TCSEC's example and illustrate the relationship of pertinent integrity policy to product evaluation criteria using excerpts from Federal laws and Executive, Legislative, and Department of Defense (DoD) policy documents. The set of policy statements and guidance that are related to integrity in automated information systems (AISs) are discussed in Appendix A. The security policy to be specified for a given system should be derivable from this set of policies in conjunction with those already cited in the TCSEC. The policy statements of interest originate from one of three sources: the Federal or Executive branches of government, or the DoD. Federal law addressing issues of integrity in information processing is best interpreted not only by examining the Acts of Congress but also their legislative histories, which aids one in understanding the establishment or modification of law. The Executive branch of government, in implementing the laws passed by Congress, issues directives and broad guidance to departments and agencies. The most significant of these OMB (policy) Circulars are summarized with respect to their effect on integrity. The General Accounting Office (GAO) is tasked by Congress to provide auditing and accountability services to the Legislative Branch of Government. In providing such services GAO issues related guidelines and standards for the Federal government. These guidelines and standards are cited as references in various policy statements included in our study, and hence are relevant to those policies of interest. The DoD has the responsibility for interpreting and implementing the policy issuances from higher authority. This is done via DoD Directives, regulations, manuals and other guidance formats. Each of these DoD policy issuances must be interpreted and implemented by the DoD Components and Agencies. 2.1 SECURITY POLICY In general, a security policy states what protection controls should be provided in the administration or operational management of a set of valued resources. A security policy may define the protection requirements in terms of perceived threats, risks, and/ or goals of an organization. Security policy from the highest levels of Government (e.g., Laws and Executive Orders) is put into force through its promulgation in subordinate Agency or Component implementation directives. Each subsequent level refines the implementation detail for protection. When these implementation details are carried out, the policy is enforced. As the general policy statements are refined, the resulting statements of specific requirements serve to drive product specifications for the design and operation of policy enforcement mechanisms. Thus, ``a given system can only be said to be secure with respect to its enforcement of some specific policy'' [TCSEC 1985, p. 59]. 2.1.1 Original and Revised Security Policy Control Objectives Original A statement of intent with regard to control over access to and dissemination of information, to be known as the security policy, must be precisely defined and implemented for each system that is used to process sensitive information. The security policy must accurately reflect the laws, regulations, and general policies from which it is derived [TCSEC 1985, p. 59]. Revised A set of statements of intent with regard to controls over computing resources and information processing including origination, acquisition, access, use, maintenance, dissemination, and disposal of information within computer systems, to be known collectively as the security policy, must be precisely defined and implemented for each system that is used to process classified and sensitive information. The security policy must accurately reflect the laws, regulations, and general policies from which it is derived. 2.1.2 Discussion Automated information system security policy is a set of statements indicating the protection controls that should be focused on computing resources and on how information within computer systems is originated, acquired, accessed, used, maintained, disseminated, or disposed. The current Security Policy control objective is limited by the breadth and scope of the laws, regulations, and general policies from which it is drawn, i.e., non-disclosure of classified and other sensitive information. To extend the breadth and scope of the TCSEC Security Policy control objective to integrity, one must first examine the regulations, policies, and/or laws that might be applicable. Although existing policy [DoD 5200.28-D] states that safeguards for the preservation of systems and data integrity shall be in place in DoD computers, implementing regulations and manuals do not precisely define the means for providing these safeguards. This is in contrast to the uniform system for safeguarding national security information as prescribed by Executive Order 12356 [EO 12356], which specifically assigns responsibility to promulgate implementing regulations for confidentiality protection. This assignment of responsibility has led to well-defined regulations for protection against unauthorized disclosure, (e.g., [DoD 5200.1-R]). There appear to be no Executive Orders of equivalent weight and specificity for the direct establishment of regulations for integrity, and thus regulations applicable to system or data integrity are not as specific and well-defined. There are Federal laws and policies which both directly and indirectly address integrity issues. We assert both as being applicable to integrity protection. They address, in an overlapping fashion, requirements for automated information security, information and internal management, and internal controls. These laws and policies are individually summarized in Appendix A. In addition to current TCSEC policy guidance on confidentiality, the integrity requirements and guidelines provided by these laws and policies should be used to shape the detailed security policy into a clear specification of what must be done to preserve and promote both confidentiality and integrity. The essence of these laws and policies with respect to information security pertains to the definitions of sensitive government information and sensitive applications, and the protection of sensitive information from loss, misuse, unauthorized access, or modification. Specific to integrity, these laws and policies require that information must be protected from unauthorized, unanticipated or unintentional modification including the detection of such activities. Personnel, life support, safety critical and financial transaction systems are cited as sensitivity examples. The laws and policies define restrictions on the collection, use, and maintenance of information in Federal AISs, including timeliness, accuracy, and completeness, and relevance to the agencies needs. They require appropriate safeguards and individual accountability. The essence of the laws and policies with respect to information and internal management pertains to the definition of information and computer resources as assets that must be managed, and to the establishment of management controls. These management controls include internal management control procedures, general supervision, input/output and procedural controls for information processing operations, system administration, information resource management, training, responsibility assignments, resource allocation, and vulnerability assessments. The essence of laws and policies with respect to internal controls pertains to individual competence, authorization, and accountability; data and application validation; data completeness, accuracy, and timeliness; and auditability and other procedures to maintain and to periodically determine the extent of conformance with legal and ethical standards. Several Federal laws, along with their implementing policies, mandate action to preserve and promote data and systems integrity and considerably broaden the scope of protection requirements over those requirements for confidentiality. The proposed revision reflects these broader protection requirements by modifying the original TCSEC version to allow a comprehensive coverage of controls. This modification preserves the intent of the original objective with respect to control for confidentiality and allows for the incorporation of additional controls for integrity. The modification pluralizes the ``statement of intent'' and the term ``control'' to recognize a wider variety of protection intents and controls and then collectively terms them ``the security policy.'' Further, it removes the more narrowly focused words ``access to and dissemination of information'' from the original objective statement and replaces those words with the phrase ``information processing including origination, acquisition, access, use, maintenance, dissemination, and disposition of information within computer systems.'' Each of these elements should have a precise statement of enforcement requirements with the collective statement resulting in a consistent and complete security policy. 2.2 MANDATORY CONTROL Mandatory security is based on laws or regulations which establish the rules that must be enforced and the designations of attributes to be used by these rules. Thus, it is often referred to as ``rule-based'' security. In the TCSEC, mandatory security refers to the enforcement of a set of access control rules that constrains an individual's access to information on the basis of a comparison of attributes that designate an individual's clearance and/or authorization to the information, the classification and/or sensitivity designation of the information, and the form of access being mediated. In general, system enforcement of mandatory policies either requires or can be satisfied by systems that implement a partial ordering or mathematical lattice of such designations [TCSEC 1985, p. 60]. 2.2.1 Original and Revised Mandatory Security Control Objectives Original Security policies defined for systems that are used to process classified or other specifically categorized sensitive information must include provisions for the enforcement of mandatory access control rules. That is, they must include a set of rules for controlling access based directly on a comparison of the individual's clearance or authorization for the information and the classification or sensitivity designation of the information being sought and indirectly on considerations of physical and other environmental factors of control. The mandatory access control rules must accurately reflect the laws, regulations, and general policies from which they are derived. Revised Security policies defined for systems that are used to process classified or other specifically categorized sensitive information must include provisions for the enforcement of mandatory access control rules. That is, they must include a set of rules for controlling access based directly on (1) a comparison of the individual`s clearance or authorization for the information and the classification or sensitivity designation of the information being sought, and/or (2) a comparison of the duty to be performed with the duties mapped in the individual's current role, and indirectly on (3) considerations of physical and other environmental factors of control. The mandatory access control rules must accurately reflect the laws, regulations, and general policies from which they are derived. 2.2.2 Discussion Integrity protection requires that user actions be constrained by mandatory controls beyond the traditional specification of a sensitivity label and a formal authorization that form a ``confidentiality'' lattice. These additional constraints will be described in this discussion. It is Federal law that any information which could adversely affect the national interest must be protected from loss, misuse, unauthorized access, and unauthorized modification [CSA 1987]. It is also Federal law that ``internal accounting and administrative controls... shall provide reasonable assurances that [resources] are safeguarded against waste, loss, unauthorized use, or misappropriation'' [FMFIA 1982]. Federal and DoD policy reflect these protection requirements in their implementing directives. For example, it is Federal policy that resources must be ``protected against fraud, waste, mismanagement or misappropriation'' [OMB A-123, p. 1]. Separation of duties is a mandatory policy that has been implemented, particularly in the commercial sector, to address fraud, misuse, etc. Separation of duties also is cited explicitly as an internal control standard [GAO 1983] and is required in several Federal and DoD policies. DoD's directive on its internal management control program, [DoD 5010.38-D], in discussing dependencies for internal control, provides rationale for this mandatory policy. ``Internal control depends largely on the elimination of opportunities to conceal errors or irregularities. This, in turn, depends on the assignment of work in such a fashion that no one individual controls all phases of an activity or transaction'' [DoD 5010.38-D, Encl.3]. From this requirement to separate duties or phases of an activity, we derive the need for implementing the concept of roles. To separate duties, attributes must be identified that will allow duties to be categorized into different sets. We define a duty to be an operation on an object, class of objects, or defined system resource; it provides the binding for objects and operations. Each set of duties is mapped to a role. Thus, a role is an encapsulation that defines which duties (i.e., manual or automated operations on particular objects, classes of objects, or system resources) a user possessing the designation of that role is allowed to perform (invoke). In essence, a role conveys a ``privilege'' to perform a set of duties; it provides the binding for users, operation, and objects. Roles aggregate users, duties aggregate objects and their operations. Where separation is required, two roles may have partially but not totally overlapping duties; no single role can encompass all of the duties required to complete a sensitive activity or transaction. Roles may be assigned as expressly permitted or denied, or they may be enabled by a sequence of events performed by another role. Once the duties are divided between different roles, the system or role administrator must ensure that a single individual is not given multiple roles that would effectively allow that individual to perform all duties required to process a sensitive transaction. For example, if duties A, B, and C are required to perform a particular transaction, the system might assign duties A and B to role 1 and duty C to role 2 to achieve separation of duties. But, in order to maintain the separation, the system or role administrator must ensure that the same individual is not assigned to both role 1 and role 2. Roles must be registered in the system for all operations on objects, classes of objects, and system resources. Newly created operations cannot be invoked without the intervention of a system or human administrator to register the operation's associated roles. Roles assigned to individuals must relate to roles assigned to operations according to mandatory rules, (e.g., separation of duties must be enforced). These role designations can provide partial ordering and dominance relations necessary for the mechanics of a lattice. DoD policy constrains the concept of separation of duties even further by requiring ``authorized [resource] access and [transaction] execution'' [DoD 5010.38-D, Encl.3]. From this mandatory policy requirement, we derive the joining together of the (authorized) individual, in a specific role, executing a specified duty (i.e., operation), on a specific resource (i.e., data object). By combining access to data with separation of duties, the computer system must implement user-program-data bindings to control which users can invoke which programs on particular data items. A model for achieving user-program-data bindings is given in [Clark 1987, 1989]. Our approach is to use roles and duties as the bindings. Lee [1988] discusses an alternative approach using roles in a lattice to implement the Clark and Wilson model. Mandatory controls address more than access control, they also address information flow. Where the integrity issue of ``contamination'' of high quality information with low quality information from low quality sources is a mandatory concern, the ability to attribute subjects and objects with a designated quality grade will be required. Biba [1977], in his integrity model, introduced the term integrity grade to designate gradations of quality for subjects and objects. In essence, an integrity grade is a determination of a subject or object's quality with respect to a defined standard. In this respect, such a grade can be thought of as analogous to a classification or a sensitivity label in the DoD scheme. These integrity designations also would provide partial ordering and dominance relations necessary for the mechanics of a lattice structure. DoD requirements for integrity grades for subjects are derivable from the statement that ``managers and employees shall have personal and professional integrity and shall maintain a level of competence that allows them to accomplish their assigned duties...'' [DoD 5010.38-D, Encl.3]. This ``competency'' requirement implies some specific standard of quality associated with an individual (e.g., a level of professional maturity). It further implies that individuals not meeting a certain level of quality should not be allowed to perform certain duties, because they may lack competence to successfully accomplish such duties. Thus, we derive a mandatory requirement to characterize individuals, in conjunction with their role specification, with a level of quality that reflects their ability to carry out specified duties (e.g., apprentice, journeyman, master, supervisor). Integrity grades for objects are not always directly derivable from formal standards or policy, but often can be derived from experience. Here, we are concerned with attributes of information that indicate the information's ``maturity'' (e.g., initial, preliminary, and final versions) that convey a degree of effort placed into developing the information and the results of that effort to a subjective or objective standard. In this case, the idea of maturity recognizes that earlier versions of information may not have as high a ``quality'' as later versions. Similar attributes, some with specific standards such as precision, accuracy, etc., can be addressed under the rubric of information quality. Where contamination is an issue, a specific set of information flow rules must be established. For example, a rule based on the competency of individuals might state that information entered by an expert cannot be modified by a novice. A rule based on the maturity of information (e.g., unedited version vs. final product version) might state that the ``quality'' of the information increases only by progressing the information through specific events (e.g., editing and formal review). It is through this event progression that the effort put into the information's development is seen to produce measurable results (e.g., edited and approved versions). As a further requirement, the information maturity rule might state that a proper sequence of such events must be followed. To be enforceable, these potential mandatory quality rules will require some form of integrity grade designation implementation. The standards for such integrity designation requirements have not been developed for widespread use, and attributing subjects and objects with gradation designations may not be as straightforward for integrity policies as was the case for confidentiality policies. The additional comparisons added to the mandatory controls are seen to be vital in preserving the integrity of systems and data. With these comparisons, we recognize that there are at least two levels of mandatory control. The first level provides a reference monitor which is invoked to meet the requirements of preventing disclosures of classified information and/or preventing contamination of high quality information with low quality information. Notice that although the same wording used in the original control objective has been used in (1), it is interpreted to imply the extension of integrity grades to prevent contamination. The second level provides mandatory indirection between a user and system resources to enforce separation of duty as well as control of object execution, modification, or manipulation. This second level of mandatory control extends the notion of a reference monitor provided by the first level, and provides more discrete control by binding the user authorization to a particular action upon a particular object. 2.3 DISCRETIONARY CONTROL The concept of discretionary control extends from the principle of ownership, providing for user-controlled sharing that promotes the maximum efficiency of system data and resource administration while retaining protection effectiveness. Efficiency is gained by reducing central system administration and effectiveness is maintained by bounding an individual's discretion. Thus, discretionary control is the administration of data and resources by individuals who are provided with a set of explicit and/or implicit privileges to operate on sets of those data and resources, and with the ability to grant or deny (at their discretion) privileges for the data and resources under their control to other individuals. Because it is related to explicitly identifying individuals, this form of control often is termed identity-based control. The original Discretionary Security control objective was derived from DoD confidentiality policy requiring each individual, in addition to being cleared for access, to also have been determined by a competent authority to have a need-to-know for particular items of information for the performance of that individual's job. The concepts and mechanisms developed originally to implement controlled sharing were employed to enforce need-to-know. 2.3.1 Original and Revised Discretionary Security Control Objectives Original Security policies defined for systems that are used to process classified or other sensitive information must include provisions for the enforcement of discretionary access control rules. That is, they must include a consistent set of rules for controlling and limiting access based on identified individuals who have been determined to have a need-to- know for the information [TCSEC 1985, p. 61]. Revised Security policies defined for systems that are used to process classified or other sensitive information must include provisions for the enforcement of discretionary control rules. That is, they must include a consistent set of rules for controlling and limiting (1) access based on identified individuals who have been determined to have a need-to-know for the information, and (2) execution of duties based on identified roles and individuals who have been determined to have a need-to-perform those duties. 2.3.2 Discussion The wording of the existing control objective reflects its original focus. The term ``need- to-know'' is relevant only to confidentiality, and has no essential bearing in terms of integrity policies. It can be argued that beyond this single instance, the wording of the existing control objective is general enough to apply to integrity protection. However, although the term ``access'' is currently interpreted in the general sense for AIS security [NCSC 1988, p. 3], in many regulations its meaning is strictly limited to confidentiality. Examples of more narrow usage can be found in [DoD 5200.1-R] and the Privacy Act of 1974 [PA 1974]. Still, if the over-specificity of its terms were its only deficiency, the existing control objective could serve the purposes of integrity with relatively minor changes. The restricted scope of the existing control objective also results in a more fundamental flaw when considering integrity protection at a purely functional level. Because integrity protection is concerned with the flow of information into an object, ``proper'' modifications can only be defined in terms of the particular code segment (e.g., program) which performs a modification. In particular, the code which manipulates an object must do so by adhering to the object's format, at a minimum. Because functional concerns require the binding of particular code to a particular object or class of objects for integrity protection, it follows that ``privileges'' should not allow a less restrictive binding. The generality implied by ``controlling and limiting access to... information,'' is simply insufficient to convey the required degree of protection. This concept is expressed through the definition of a duty, as discussed in Section 2.2.2, under Mandatory Control. One needs to consider the differences between the basic concerns of confidentiality and integrity to understand why this additional degree of control is required. Confidentiality protection is concerned with preventing the unauthorized flow of information from one object to another. This flow is characterized essentially by one class of operation performed by a system (i.e., ``read''). In terms of information flow, each and every ``read'' operation can be considered equivalent. Such a simplification is not possible for integrity protection. The inward-directed information flow is, similar to confidentiality, characterized by a single class of operation (i.e., ``write''). However, in contrast to the apparent equivalence of all read operations, write operations are distinguished by the context in which they are performed. For example, two programs, each performing a series of write operations upon an object, may produce entirely different effects in terms of the object's integrity. In this regard a ``write'' privilege, in giving a user the right to modify an object in a very general manner, does not provide the correct level of abstraction in specifying privileges in terms of integrity protection. A relationship between mandatory and discretionary controls has been assumed in the preceding discussion: the rules specifying what is allowable under mandatory controls are expressed at the same level of abstraction at which discretionary controls are applied. For instance, the Bell-La Padula model definition of allowable operations for both mandatory and discretionary controls are equivalent sets (i.e., read, write, and execute operations) [Bell 1975]. It should not be assumed that this equivalence relation must always be present. It is possible for discretionary controls to exist in the absence of mandatory controls. In such a case, an equivalence relation is neither possible nor necessary. The converse case, where mandatory controls exist in the absence of discretionary controls, is not explicitly excluded by the original TCSEC control objectives, although it is excluded in the actual Criteria. However, it is likely that this converse case may be more acceptable in practice for integrity protection than for confidentiality protection, and subsequent evaluation criteria should address such a possibility. In addition, we assert that whenever both mandatory and discretionary protection is provided by a system, there must be an equivalence relation between mandatory and discretionary control abstractions. A consequence of this relationship is the complementary role in which mandatory and discretionary controls provide comprehensive protection. If ``privileges'' are expressed using identical abstractions, mandatory controls can enforce the context in which a privilege is valid, while discretionary controls imply the permission to exercise the privilege, given a valid context. One way of looking at this relationship is that mandatory controls specify what is potentially allowed, while discretionary controls specify what is intentionally allowed. The two sets of controls are complementary in that access is dependent upon passing both mandatory and discretionary tests. This complementing property can only exist if the operational classes at both the mandatory and discretionary levels are equivalent, as discussed above. We assume that such a complementing property between mandatory and discretionary controls for integrity protection would be desirable, as has been the case for confidentiality protection. We have discussed under the Mandatory Control (Section 2.2.2) the basic abstractions, defined as roles and duties, which capture the necessary elements for integrity protection. Bacic [1989], in addressing integrity as set forth in the Clark and Wilson Model [Clark 1987], suggests that discretionary controls for integrity are user-defined execution controls. Bacic notes that these discretionary controls operate at the user level, provide access only to executable objects, and are confined to a set of duties (i.e., the role) for an individual as prescribed by mandatory controls. Bacic's discretionary execution controls (DECs) complement his mandatory execution controls (MECs) and can be viewed as a logical extension of discretionary access controls. They relate a user to a set of processes (e.g., a program) that fulfills a set of duties which can only execute on particular sets of data objects. We find that integrity protection can be provided only by addressing discretionary concerns at these (more complex) levels of specification and abstraction. However implemented, execution controls essentially define roles. As such, the proposed control objective addresses the appropriate relationship between roles and duties for discretionary integrity protection with the term ``need-to-perform.'' In addition to proposing changes to the existing control objective, we need to examine the traditional abstractions associated with discretionary controls, in order to interpret the subject in the context of integrity protection. The distinguishing feature of existing discretionary controls is the capability they provide to allow an individual to control access to resources, based on a ``principle of ownership.'' An ``owner'' (often the creator) of a resource possesses a set of privileges over that resource, of which each may be granted explicitly to other users. In some implementations, the ``grant'' privilege itself may be conveyed to other users, either for singular privileges or for the entire set of privileges inherent to the owner. The principle of ownership must be generalized for integrity protection to embody role administration. The administrator of a set of resources should not have the privileges that the analogous ``owner'' of property has; rather, ownership should be considered a special case of administration. The definitions for sensitive data and sensitive application found in [OMB A-130, p. 52742] imply that an individual creating, using, or maintaining sensitive resources should have strictly limited administrative rights to those resources. For example, a user creating an object associated with sensitive information or a sensitive application should not necessarily have the ability to destroy that object at the user's discretion. Therefore, an AIS should support the ability to restrict the set of default privileges associated with the administration of resources, on a per- application basis. Additionally, an AIS should support the ability to designate individuals (other than the creator) as having discretionary administrative control over a particular resource or set of resources. Similarly, an administrator of a set of resources should not, in general, be able to grant privileges to other entities simply because he possesses such privileges. In other cases, it may be appropriate for an administrative user to grant certain privileges to other users which are unavailable to the administrator. This issue is related to a broader area of concern: the control over propagation of privileges. A user receiving access to a resource via discretionary controls should not, in general, be able to arbitrarily pass that privilege on to other entities, nor to amplify the privilege in any way. Therefore, an AIS should support measures to arbitrarily define which discretionary privileges are ``grantable'' and provide a means to prevent the (undesired) propagation of privileges, on a case-by- case basis (i.e., per application). These discretionary issues must be addressed through use of the same abstraction(s) in which mandatory controls are expressed (i.e., roles). The role-implementing features of a system must therefore address three different areas of functionality. The first area is the definition of roles with respect to a set of processing resources. This set of resources can be described as the domain to which the defined roles are applicable. The definition of roles within a domain is an administrative function associated with mandatory policies. Also, this definition must include the specification of which users are authorized to operate within the defined domain. The second area which must be addressed is the discretionary administration of the system-defined roles. Conceptually, this area implements the ``ownership'' of roles, under which domain-specific roles can be allocated or assigned. The third area which must be provided by the system is the binding of a subject (i.e., a user-process pair) to only those actions defined by its operational role. Note that together these three areas of functionality provide an equivalence set between mandatory and discretionary controls to provide complementary protection mechanisms. The mandatory specification defines which resources, roles, and individuals are available, and who has discretionary control over the assignment of roles. The ``owner'' or role administrator of the domain assigns roles and resources to individuals. For a user to operate within a role, that user must be specified through the mandatory definition as being allowed to operate within that domain, and be assigned a role and resources by the ``owner'' of the domain. Clark and Wilson [Clark 1987, 1989] provide a set of extended access controls which address some of the deficiencies associated with the traditional notion of discretionary controls in providing integrity protection. In their model, access control is specified (via ``triples'') in terms of controlling accesses by identifiable segments of code (i.e., the ``transformation procedure'' or TP) to specified objects. This additional restriction is similar to the type enforcement mechanisms of certain programming languages, although it is applied at the system level. Thus, this feature of the model can be considered to involve a finer specificity of control than contained in traditional DAC. However, the notion of ``discretion'' in [Clark 1989] is distinct in that there is no explicit mechanism by which (non-administrative) users can transfer privileges to others. Although the concept of ``triples'' is identity based, triples are not discretionary but are, in fact, mandatory. This is not to say that extensions to the Clark and Wilson model could not address discretion access controls, however. The set of all triples which apply to particular user- object pairs is conceptually similar to our notion of a role definition.1 One can hypothesize a privilege-granting TP in which the object acted upon is the specification of privileges (i.e., a set of triples) for some other object. The triple specifying such a privilege-granting TP would give the specified user the ability to control access to particular objects under that user's administration, similar to the ability of owners to alter an access control list in ---------------------------- 1. Roles, for different implementations, might also be interpreted as either the set of triples associated with a single object or those associated with a single user. ---------------------------- more traditional models. Thus, any particular subject may be an ``administrator'' with respect to an arbitrary set of objects. This administrative user need not be privileged with respect to the system, nor to other resources outside a particular administrative domain. It may also be possible to construct arbitrary, discretionary control domains (e.g., hierarchical, independent, or overlapping), while retaining the beneficial extensions offered in the original Clark and Wilson model. The proposed control objective revision recognizes that discretionary controls in support of data and systems integrity require extensions to traditional access control. Specifically, they require the ability of the user to specify-and the system to test for-the identity and authorization of an individual and that individual's role, as well as specific duties within the role that specify the functionality associated with the access. In essence, the integrity revision constrains discretionary control to user operations on executable objects. The term ``need-to-perform'' is intended to capture this essence of discretionary control with respect to integrity, as discussed in the previous review of [Bacic 1989]. Such controls necessarily would be further constrained by mandatory controls. 2.4 MARKING CONTROL Marking is the concept of designating or providing information attributes, (e.g., classification or sensitivity), each having a specified range of values, that can be used in rule-based mechanisms to implement mandatory security policies. A clear implication of mandatory controls is that the system must assure that the mandatory security designations cannot be arbitrarily changed since such changes could permit individuals to access information in unauthorized ways. Marking control is necessary to ensure accurate and consistent internal rule-based decision making and also necessary to ensure that, when the information is transformed to an external representation, the marking conveys how the information is to be handled in the external world. Since these attribute values, or labels, are key to decision making, it is important that they remain essentially stable. Labels should be created and maintained by the system, or installed and maintained by specified systems administrators, and only changed in a well-defined manner so that a label continues to be consistent with the sensitivity of the information that the label represents. 2.4.1 Original and Revised Marking Control Objectives Original Systems that are designed to enforce mandatory security policy must store and preserve the integrity of classification or other sensitivity labels for all information. Labels exported from the system must be accurate representations of the corresponding internal sensitivity labels being exported [TCSEC 1985, p. 61]. Revised Systems that are designed to enforce mandatory security policy must store and preserve the integrity of classification, other sensitivity, or integrity labels for all information. The labeling must be sufficient to implement rule-based checking of mandatory linkages between subjects, data, and operations upon the data as required by the mandatory control objective. Labels exported from the system must be accurate representations of the corresponding internal labels being exported. 2.4.2 Discussion Identification of attributes used in mandatory rule-based decisions are key to marking requirements. Many of these attributes may be developed in the context of an application rather than at the operating system level. It is important that the overall protection system maintain the integrity of any labels required by the marking policy even if the labels are developed at the application level. The marking policy and specific marking requirements for handling classified information to prevent unauthorized disclosure are well covered in the TCSEC. Numerous policy documents are cited in the TCSEC with clear confidentiality marking requirements. There are no similar ``clear'' statements in policy to convey the marking requirements for integrity. Given the integrity constraints described under the proposed mandatory control objective, we can now derive marking requirements for integrity. From the mandatory requirement for separation of duties, we derived the need to identify within the system a set of roles, each with a unique set of duties. Roles themselves can be used as marking designations, as can the duties they encapsulate. Each duty is mapped to specific system operations on objects and resources. At some level of abstraction, separated duties may be identified as either ``enabling'' or ``completing'' functions [Guttman 1991], and the same individual should not have the ability to perform both in the same role. This constraint may imply the requirement that certain objects carry an ``enabled'' label. From the mandatory requirement to join together an individual, in a specific role, executing a specified program on a specific data set, we derived the need to effectively implement user-program-data bindings. Here, the options may be to use some variation of Clark and Wilson ``triples'' [Clark 1987]. Variations could include labeling each system operation with the set of roles established for manipulating the specified data set (e.g., use of abstract data types (ADTs)), with each individual user or process being linked to a specified set of ADTs. This set of rules acts as an access control list (ACL) such that each individual user or process gains access only to specified operations. For finer granularity, the set of roles also could be used as labels on individual data items with the user or process gaining access to a specified operation on the specified date item only if the user or process role matched a role on the data item's list of roles. To prevent the contamination of high quality information with low quality information, we derive a requirement to mark subjects (in conjunction with the use of roles) and objects with a level of quality, or integrity grade. For subjects, the integrity grade should reflect an individual's ability to carry out specified duties (e.g., apprentice, journeyman, master, supervisor). For objects, the integrity grade should reflect the data's quality (e.g., initial draft, preliminary strawman, final prototype, final finished product). Such terms again indicate a level of quality, maturity, or competence against some objective or subjective standard. The marking changes extend labeling to integrity attributes of information and require labels to support the mandatory integrity linkages (i.e., separation of duties, user program data bindings, and integrity grades) made in the mandatory control objective. 2.5 ACCOUNTABILITY CONTROL The concept of holding an individual accountable for his actions is fundamental to policy enforcement. Accountability can be defined, traditionally, as ``the property that enables activities on a system to be traced to individuals who may then be held responsible for their actions'' [NCSC 1988, p. 4]. The concept requires the ability to continuously identify individuals with their actions and with those of their surrogates within the system. To be effective, mandatory and discretionary security policies are dependent upon a system's ability to adequately identify, authenticate, maintain individuation, and account for those individuals to which access controls are applied. The ability to record and review the (system-related) actions of individuals provides (1) a deterrent to malicious actions, (2) a means to detect malicious actions or attempts, and (3) the ability to undertake preventive measures when attacks are detected. Thus, the concept further requires that a history of an individual's actions and the system's reactions be continuously maintained and protected from unauthorized manipulation for real-time or subsequent use in auditing analyses. 2.5.1 Original and Revised Accountability Control Objectives Original Systems that are used to process or handle classified or other sensitive information must assure individual accountability whenever either a mandatory or discretionary security policy is invoked. Furthermore, to assure accountability, the capability must exist for an authorized and competent agent to access and evaluate accountability information by a secure means, within a reasonable amount of time, and without undue difficulty [TCSEC 1985, p. 62]. Revised Systems that are used to process or handle classified or other sensitive information must assure individual accountability whenever either a mandatory or discretionary security policy is invoked. Systems must assure that the accountability for individual performance of duties can be determined through an independent consistency check between internal representations of information within the system and the external information being represented. Systems must maintain the required degree of logical consistency for duplicate, identically derived, and/or corresponding internal instances of the same information throughout the existence of such information on the system. Furthermore, to assure individual accountability, the capability must exist for an authorized and competent agent to access and evaluate accountability information by a secure means, within a reasonable amount of time, and without undue difficulty. 2.5.2 Discussion It is the policy of the U.S. Government that agencies ``shall establish and maintain a cost- effective system of internal controls to provide reasonable assurance that Government resources are protected against fraud, waste, mismanagement, or misappropriation...'' [OMB A-123, p. 1]. DoD policy requires that each DoD component maintain accountability over their assets and that they implement a comprehensive system for internal management control that provides reasonable assurance: obligations and costs comply with applicable law; assets are safeguarded against waste, loss, unauthorized use, and misappropriation; revenues and expenditures applicable to DoD operations are recorded and accounted for properly [DoD 5010.38-D, pp. 1-2]. AIS internal control is defined within DoD guidelines as ``the steps taken... and all the methods and techniques used to safeguard AIS resources and provide reasonable assurance of the accuracy and reliability of computer-based input, processing and output; ensure the adherence to applicable laws, regulations and policies; and promote the effectiveness, efficiency and economy of AIS operations and systems'' [DoD 7740.1- G, p. 1-4]. The DoD guidelines include the following specific forms of application control: authorized transactions, valid transactions, complete information, accurate information, timely information, secure system and data, and auditable system. Accountability is fundamental to internal control and, as such, is a vital aspect of promoting and preserving systems and data integrity. Internal control adds another dimension to accountability, the application dimension. The TCSEC's original control objective appears sufficiently general to include the specific requirements for integrity with respect to user activity on a system. However, there is no stipulation for the assignment of responsibility for actions which need to be performed and yet are not properly carried out. This ``deficiency'' of action may affect, most characteristically, the internal and external consistency of the information maintained by a system. In many applications, the concept of accountability may require the synchronized comparison of internal information states with the external world the information represents. As a result of this increase in scope for accountability, additional functionality will be required of systems conforming to this new control requirement. It would no longer be enough for a system to passively monitor and record user access activity, and provide the means to adequately review user access activity information. Instead, a system would need to be able to enforce authorized actions with respect to ``valid'' objects, where an object's validity is determined through some measure of its internal and external consistency. This implies that a system would need to (1) define, specify, and enforce valid state transitions for objects, or (2) dynamically validate an object's state. Both of these notions are presented by Clark and Wilson in [Clark 1987]. In their notation, an Integrity Verification Procedure (IVP) performs a dynamic check to determine whether objects controlled under the system's integrity policy conform to its specification, and a TP guarantees valid state-to-state transitions for controlled objects. Thus, an IVP may verify that an object accurately reflects the current status of an inventory item (external consistency), and a TP may guarantee that all copies of a particular object are updated concurrently (internal consistency). Individuals are directly linked to the execution of a TP or an IVP on a specific set of data. The proposed changes to this control objective reflect an extension to traditional scope of accountability. This revision is driven by internal management control policy requirements which outline the need for application controls including the proper correspondence between external information and the representation of that information on a system (i.e., data). In essence, this correspondence cannot occur without the proper recording of this external information and adequate reviewing procedures to verify that system data is accurate. These procedures are at least partially external to the system, and thus are best described as ``accountability'' control. Additionally, the individual's or system's initiation, use, and maintenance of duplicate or redundant data raise integrity issues with respect to accuracy, timeliness, and the effect of those attributes on the internal (logical) representations of information. The procedures to properly constrain these actions are policy driven and are, therefore, subject to accountability controls. 2.6 ASSURANCE CONTROL OBJECTIVE The concept of assurance is concerned with the measures taken to guarantee that the implementation of protection features is correct and that it properly enforces security policies. A consideration for ``proper enforcement'' is whether the protection features accomplish what they are designed to do, but nothing else (i.e., there are no unspecified features implemented). The TCSEC defines two types of required assurance: life cycle and operational. Life-cycle assurance deals with the management of system design, development, and maintenance. In essence, lifecycle assurance provides confidence that a system's protection features are themselves protected from attack throughout the lifetime of the system. Life-cycle assurance includes the control of design changes and the effect changes may have in enforcement of the defined security policies. Operational assurance ``focuses on features and system architecture used to ensure that the security policy is uncircumventably enforced during system operation'' [TCSEC 1985, p. 63]. 2.6.1 Original and Revised Assurance Control Objectives Original Systems that are used to process or handle classified or other sensitive information must be designed to guarantee correct and accurate interpretation of the security policy and must not distort the intent of that policy. Assurance must be provided that correct implementation and operation of the policy exists throughout the system's life-cycle [TCSEC 1985, p. 63]. Revised Systems that are used to pro cess or handle classified or other sensitive information must be designed to guarantee correct and accurate interpretation of the security policies and must not distort the intent of those policies. Assurance must be provided that correct implementation and operation of the policy exists throughout the system's life-cycle. Application subsystems used to process or handle classified or other sensitive information must be designed, implemented, controlled, and operated in a manner which provides assurance that the goals of both application-specific security policies and system-wide security policies are met without circumvention. 2.6.2 Discussion Although this control objective is sufficiently general to include the specific requirements for integrity, it should be noted that integrity requirements may have a different emphasis than confidentiality requirements. Because integrity dependencies are more likely to be domain specific as opposed to system wide, the development and introduction of any new application dealing with a particular (sensitive) data set will need to be tightly controlled. The ``correct implementation and operation'' concerns most likely will be interpretable primarily in the domain of the application. Thus, assurance control needs to be extended from the current systems domain to each specific application domain resident on the system. The proposed assurance control objective recognizes that there exists the possibility of multiple, application-specific security policies which may apply only to particular subsets of resources within the system. Software residing within a particular application domain should only extend the degree of control over resources, and should in no manner nullify the degree of control required for all system resources or for resources within a different application domain. Assurance must be provided that application and system software meets the security policy objectives for both the system and the application. The ``adequacy'' of this assurance must be determined strictly in terms of the sensitivity of the application and resources within that domain. 2.7 FAULT TOLERANCE CONTROL The concept of fault tolerance extends from the need to continue operations in the presence of faults. As there are no guarantees of the absence of some form of fault, risk reduction becomes the focus of this control. Tolerance is established through a robust ability to detect and correct faults, and through a risk analysis that enables the setting of thresholds to maintain an acceptable degree of processing robustness in degraded operational modes. Increasing complexity of systems yields an increase in the number of potential failure points and places a greater demand for fault tolerant system implementations. Electronic parts fail, waveforms get scrambled, magnetic properties of media deteriorate, etc. With more complex computers being incorporated into more complex commercial and military aircraft flight control systems, industrial controllers, space applications, banking systems, etc., erroneous computer performance can be devastating to financial records, environmental safety, national security, and even human life. Therefore, when faced with potential failures in complex systems, fault tolerance plays an important part in maintaining data and systems integrity. 2.7.1 Original and Revised Fault Tolerance Control Objectives Original [There is no original control objective for fault tolerance contained in the TCSEC.] Revised Systems that support safety or mission-critical applications must provide measures to promote continued safe or correct operation, within defined tolerances, in the presence of integrity failures. Systems must include provisions for detecting integrity failures, even if those failures cannot be corrected, and provisions for correcting integrity failures when possible. System designs must include provisions for identifying and classifying potential integrity failures, determining the likelihood of such failures, and possible outcomes of such failures. 2.7.2 Discussion Fault tolerance essentially involves two parts. The first part is the detection of errors. Detection is necessary for a system to determine when a failure has occurred. Detecting errors that are corrected by the system is as essential as detecting failures that cannot be corrected, since such failures may indicate a potential degradation of system performance, or may indicate that the system is approaching a threshold at which errors are no longer correctable. The second part of fault tolerance is the attempted correction of errors. In addition to simply detecting incorrect data, it is possible to use methods to correct errors in the data. The simplest approach to error detection would be to provide a certain number of redundant copies of the data, possibly by different channels, and then to compare these when determining whether the data integrity has been violated. This approach can be extended to error correction if it is possible to tell which of the redundant copies of the data has not been altered. Various error correction methods give varying probabilities of retrieving the original, unaltered data. Applying the concept of fault tolerance is commonly associated with redundant processing. Redundancy in computer systems is a risk-reducing concept that involves the duplication of hardware, software, information, time, or other resources to detect the failure of a single duplicate component and to continue to obtain correct results despite the failure [Johnson 1989]. The same processing is performed by more than one process, and the results are compared to ensure that they match. The need for redundancy varies depending on the application. Redundant processing is commonly used in the implementation of critical systems in which a need for high reliability exists. In some situations, it is sufficient to shut down a system when a failure occurs and is detected. This solution is not very efficient, but it may be the safest solution and at least it eliminates incorrect operations by the system. In many other situations, however, it is more important that the system continue to operate, even if the performance is degraded. For example, it may be more important for communications to continue during a time of war, even if many of the transmissions have to be ignored due to static, jamming, etc. In addition, it is important to ensure that safety or mission-critical applications that are time sensitive are guaranteed to execute within their time limitations. For example, an order to ``attack at dawn'' is not useful if it is not delivered until the next afternoon. Systems that support safety or mission-critical applications must not only preserve integrity to the extent possible, but also must continue to operate in a safe or correct manner in the presence of integrity failures that result from unavoidable situations, such as physical failures of equipment or media. Fault tolerance requirements define what is meant by safe or correct operation, and the level of redundancy will vary depending on these requirements. The system must detect when a failure has occurred before it can take any action. Once a failure is detected, there may be enough redundancy for correct operation to continue or it may be necessary to take action to correct the failure. REFERENCE LIST [1] Bacic 1989 - Bacic, E.M. 1989. Process Execution Controls as a Method for Ensuring Integrity. In Report of the Invitational Workshop on Data Integrity, January 25-27, 1989, Gaithersburg, Maryland, B.2-1B.2-8. Gaithersburg, MD: National Institute of Stan- dards and Technology. NIST Special Publication 500-168. [2] Bell 1975 - Bell, D. and L. La Padula. 1975. Secure Computer System: Unified Exposi- tion and Multics Interpretation. Bedford, MA: MITRE Corporation. MITRE Technical Report 2997. [3] Biba 1977 - Biba, K.J. 1977. Integrity Considerations for Secure Computer Systems. Bedford, MA: MITRE Corporation. MITRE Technical Report 3135. [4] Clark 1987 - Clark, D.D. and D.R. Wilson. 1987. A Comparison of Commercial and Military Computer Security Policies. Proceedings of the IEEE Symposium on Security and Privacy, April 27-29, Oakland, California, 184-194. Washington, D.C.: IEEE Com- puter Society Press. [5] Clark 1989 - Clark, D.D. and D.R. Wilson. 1989. Evolution of a Model for Computer In- tegrity. In Report of the Invitational Workshop on Data Integrity, January 25-27, 1989, Gaithersburg, Maryland, A.2-1A.2-13. Gaithersburg, MD: National Institute of Stan- dards and Technology. [6] CMPPA 1990 - U.S. Congress. Computer Matching and Privacy Protection Amend- ments of 1990. Public Law 101-508. November 5, 1990. Washington, D.C.: U.S. Gov- ernment Printing Service. [7] CSA 1987 - U.S. Congress. House. Computer Security Act of 1987. Public Law 100- 235. January 8, 1988. H. R. 145. Washington, D.C.: U.S. Government Printing Service. [8] DoD 5200.1-R - Department of Defense. 1986. Information Security Program Regula- tion. DoD Regulation 5200.1-R. Washington, D.C.: U.S. Government Printing Office. [9] DoD 5200.28-D - Department of Defense. 1988. Security Requirements for Automated Information Systems (AISs). DoD Directive 5200.28-D. Washington, D.C.: U.S. Govern- ment Printing Office. [10] DoD 5200.28-M - Department of Defense. 1973. ADP Security Manual. DoD Manual 5200.28-M. Washington, D.C.: U.S. Government Printing Office. [11] DoD 5010.38-D - Department of Defense. 14 April 1987. Internal Management Control Program. DoD Directive 5010.38-D. Washington, D.C.: U.S. Government Printing Of- fice. [12] DoD 7740.1-D - Department of Defense. 20 June 1983. DoD Information Resources Management Program. DoD Directive 7740.1-D. Washington, D.C.: U.S. Government Printing Office. [13] DoD 7740.1-G - Department of Defense. Office of the Assistant Secretary of Defense (Comptroller). July 1988. ADP Internal Control Guideline. DoD Guideline 7740.1-G. Washington, D.C.: U.S. Government Printing Office. [14] DoD 7750.5-D - Department of Defense. 7 August 1986. Management and Control of In- formation Requirements. DoD Directive 7750.1-D. Washington, D.C.: U.S. Government Printing Office. [15] DoDAA 1982 - U.S. Congress. Senate. Department of Defense Authorization Act, 1982. Public Law 97-86. December 1, 1981. S. 815. Washington, D.C.: U.S. Government Printing Service. [16] EO 12356 - The White House. 2 April 1982. National Security Information. Executive Order 12356. Washington, D.C.: U.S. Government Printing Office. [17] FMFIA 1982 - U.S. Congress. House. Federal Managers' Financial Integrity Act of 1982. Public Law 97-255. September 8, 1982. H. R. 1526. Washington, D.C.: U.S. Gov- ernment Printing Service. [18] GAO 1983 - Government Accounting Office. 1 June 1983. Office of the Comptroller. Standards for Internal Control in the Federal Government. Washington, D.C.: U.S. Gov- ernment Printing Office. [19] GAO Title 2 - Government Accounting Office. August 1987 (Revised May 1988). Of- fice of Policy. GAO Policy and Procedures Manual for Guidance of Federal Agencies- Title 2, Accounting. Washington, D.C.: U.S. Government Printing Office. [20] Guttman 1991 - Guttman, Joshua. 4 March 1991. Private communication with authors. [21] H. Rept. 100-153(I) - U.S. Congress. House. Committee on Science, Space, and Technol- ogy. Legislative History of the Computer Security Act of 1987. June 11, 1987. House Report No. 100-153(I). Washington, D.C.: U.S. Government Printing Service. [22] Johnson 1989 - Johnson, Barry W. 1989. Design and Analysis of Fault-Tolerant Digital Systems. Reading, MA: Addison-Wesley. [23] Lee 1988 - Lee, Theodore M.P. 1988. Using Mandatory Integrity to Enforce ``Commer- cial'' Security. In Proceedings of the IEEE Symposium on Security and Privacy, April 18-21, 1988, Oakland, California, 140-146. Washington, D.C.: IEEE Computer Society Press. [24] Mayfield 1991 - Mayfield, Terry, J. Eric Roskos, John M. Boone, Stephen R. Welke, and Catherine W. McDonald. 1991. Integrity in Automated Information Systems. Alex- andria, VA: Institute for Defense Analyses. IDA Paper P-2316. [25] NCSC 1988 - National Computer Security Center (NCSC). 1988. Glossary of Computer Security Terms. Washington, D.C.: U.S. Government Printing Office. [26] OMB 1991 - Office of Management and Budget. 4 March 1991. ``Advance Notice of Plans for Revision of OMB Circular A-130,'' in the Federal Register, Vol. 56, No. 42., pp. 9026-9028. Washington D.C.: U.S. Government Printing Office. [27] OMB ICG - Office of Management and Budget. December 1982. Internal Control Guide- lines: Guidelines for the Evaluation and Improvement of and Reporting on Internal Con- trol Systems in the Federal Government. Washington, D.C.: U.S. Government Printing Office. [28] OMB 90-08 - Office of Management and Budget. 9 July 1990. Guidance for Preparation of Security Plans for Federal Computer Systems That Contain Sensitive Information. OMB Bulletin No. 90-08. Washington, D.C.: U.S. Government Printing Service. [29] OMB A-123 - Office of Management and Budget. 4 August 1986. OMB Circular No. A- 123, Revised. Internal Control Systems. Washington, D.C.: U.S. Government Printing Service. [30] OMB A-127 - Office of Management and Budget. 19 December 1984. OMB Circular No. A-127. Financial Management Systems. Washington, D.C.: U.S. Government Print- ing Service. [31] OMB A-130 - Office of Management and Budget. 12 December 1985. OMB Circular No. A-130. Management of Federal Information, in the Federal Register, Vol. 50, No. 247. Washington D.C.: U.S. Government Printing Office. [32] PA 1974 - U.S. Congress. Senate. Privacy Act of 1974. Public Law 92-579. S. 3418. Washington, D.C.: U.S. Government Printing Service. [33] PRA 1980 - U.S. Congress. House. Paperwork Reduction Act of 1980. Public Law 96- 511. December 11, 1980. H. R. 6410. Washington, D.C.: U.S. Government Printing Ser- vice. [34] Russell 1991 - Russell, Deborah and G. T. Gangemi Sr. 1991. Computer Security Ba- sics. Sebastopol, CA: O'Reilly & Associates, Inc. [35] TCSEC 1985 - Department of Defense. 1985. DoD Trusted Computer System Evalua- tion Criteria. DoD Standard 5200.28-STD. Washington, D.C.: U.S. Government Printing Office. ACRONYMS ADP Automated Data Processing ADT Abstract Data Type AIS Automated Information System DAA Designated Approval Authority DAC Discretionary Access Control DBMS Data Base Management System DEC Discretionary Execution Control DoD Department of Defense EFT Electronic Funds Transfer EPL Evaluated Products List FIPS Federal Information Processing Standard FMS Financial Management System GAO General Accounting Office IC Internal Control IDA Institute for Defense Analyses IG Inspector General IMC Internal Management Control IRM Information Retrieval Management (Program) IVP Integrity Verification Procedure MCP Management Control Plan MEC Mandatory Execution Control OMB Office of Management of Budget NCSC National Computer Security Center NIST National Institute of Standards and Technology NSA National Security Agency TCSEC Trusted Computer System Evaluation Criteria TP Transformation Procedure USC United States Code APPENDIX A A. SOURCE TEXT AND CROSS-REFERENCES This Appendix contains a subsection for each policy document used in our formulation of integrity-related control objectives. Each subsection is arranged in identical fashion. First, a brief overview of the policy document is provided. This overview concentrates on the AIS-integrity relevant aspects of the document rather than providing a comprehensive summary. The overview is followed by a listing of ``Selected Source Text'' (i.e., material quoted directly from the original document). Following the Selected Source Text is a ``Cross-Reference'' section. The Cross-Reference section contains a table indicating which statements from the Selected Source Text have affected our formulation of (proposed) changes to the current TCSEC control objectives. In the table, statement numbers from the Selected Source Text material are cross-referenced to each current control objective by marking an ``X'' in the appropriate row-column intersection. Each row is associated with a single section or statement from the Selected Source Text while each column is associated with a single control objective. The meaning associated for each ``X'' in the table (indicating a cross-reference) is that the associated statement from the Source Text either (a) has implications for modifying the original control objective, or (b) has implications for interpreting the proposed control objective. Specific implications considered include the following: · a new topic; · a new viewpoint; · suggests specific mechanisms, policies, or controls; · demands interpretation; · demands modification; and · touches, influences, or constrains control. Following the table is a list of comments (one for each ``X'' in the table) which provides details for the implications of particular policy statements upon each control objective. These comments represent notes made in analyzing the policy documents, and in determining the adequacy of the original control objectives in light of the increased scope of AIS security policy. The comments in this section are ``informal'' in the sense that they were not written to stand independently, outside the context of the included source text and related comments. In general, the comments do not attempt to address each issue comprehensively, and some issues may not receive equal treatment in different comments. Some entries cross-referenced under the Security Policy heading are not further specified under MAC, DAC, or Marking headings. These additional headings are left blank whenever the security policy implications might be considered organization or application specific and do not clearly indicate specific MAC, DAC, or Marking ramifications, or particular technical implementations. We have found that the topic of accountability should be generalized from its current focus on ``user accountability'' as stated in the existing control objective. From the policy documents we have studied, an expansion of the concept of accountability to include user, organization, and general accountability concepts with respect to both applications and systems would be useful. Our comments under specific Accountability cross- references indicate such an expanded approach. Such an approach represents the concept of a ``total sense'' of accountability (i.e., its most general meaning). As such, some accountability features may in fact be external to a system. The exact placement and nature of mechanisms is neither predetermined nor explicitly considered in our comments. In addition, we have assumed a similar generalization in addressing the topic of assurance. In particular, we have found policy statements which address assurance (i.e., the ``trustedness'') of controls extending to (a) entities external to the traditional bounds of AISs, and/or (b) to areas outside the traditional scope of protection mechanisms (e.g., application sub-systems). Some material provided in the ``Selected Source Text'' does not have a cross-reference. Such material was included if it provided valuable background, context, or general information which might aid in understanding either the source text itself or related comments. Additionally, in some instances the selected source text is formatted and/or numbered slightly differently from the original; this was intended to clarify the presentation of this material-care was taken not to misrepresent the intent or meaning of the original material. A.1 Privacy Act of 1974-Public Law 93-579 Public Law 93-579 requires the U.S. government to safeguard personal data processed by federal agency computer systems. This Act also requires the government to provide ways for individuals to find out what personal information is being recorded and to correct inaccurate information. The Act spells out physical security procedures, information management practices, and computer and network controls. This act also mandated the creation of the Privacy Protection Study Commission [Russell 1991, p. 287]. This Act extends the responsibility for management and protection of information resources to the area of privacy. The Act notes that the increasing use of computer and information technology has greatly magnified the potential harm to individuals that can occur from any collection, maintenance, use, or dissemination of personal information. The Act requires the Federal agencies to issue appropriate administrative orders, provide personnel sanctions, and establish appropriate technical and physical safeguards to ensure the security of the information system and the confidentiality of the data. The Act further requires that the information is as timely, complete, accurate, and relevant to its intended use as possible, and that ``adequate safeguards'' to prevent misuse are provided. Also required are administrative actions to keep account of the employees, other individuals and organizations having access to the system or file, and the disclosures and uses made of the information. The Act requires that Federal agencies establish rules of conduct with regard to the ethical and legal obligations in developing and operating a computerized data system and in handling personal data, and take action to instruct all employees of such obligations. As ``privacy'' is used in the Act, information management responsibility includes the proper collection, maintenance, use, and dissemination of any information which can be associated with a particular individual. The Act specifies that punitive actions can be levied against the Government for failure to uphold these responsibilities. We conclude that other factors which must be considered include (1) the moral obligation of government officials to maintain the constitutional rights of its citizens, (2) the adverse affect on government functioning in the absence of accurate information, and (3) the penalties associated with adverse public opinion which are likely to result from any breach of privacy as defined in the Act. The following table contains selected sections of Public Law 93-579. The cross-reference table and comments appear in the next section. TABLE A-2. Privacy Act of 1974-Selected Source Text Sec. 2(a) The Congress finds that- (1) the privacy of an individual is directly affected by the collection, maintenance, use, and dissemination of personal information by Federal agencies; (2) the increasing use of computers and sophisticated information technology, while es- sential to the efficient operations of the Government, has greatly magnified the harm to individual privacy that can occur from any collection, maintenance, use, or dissemina- tion of personal information; (3) the opportunities for an individual to secure employment, insurance, and credit, and his right to due process, and other legal protections are endangered by the misuse of cer- tain information systems; (4) the right to privacy is a personal and fundamental right protected by the Constitution of the United States; and (5) in order to protect the privacy of individuals identified in information systems main- tained by Federal agencies, it is necessary and proper for the Congress to regulate the collection, maintenance, use, and dissemination of information by such agencies. Sec. 2(b) The purpose of this Act is to provide certain safeguards for an individual against an invasion of personal privacy by requiring Federal agencies, except as otherwise provided by law, to- (1) permit an individual to determine what records pertaining to him are collected, main- tained, used, or disseminated by such agencies; (2) permit an individual to prevent records pertaining to him obtained by such agencies for a particular purpose from being used or made available for another purpose without his consent; (3) permit an individual to gain access to information pertaining to him in Federal agen- cy records, to have a copy made of all or any portion thereof, and to correct or amend such records; (4) collect, maintain, use, or disseminate any record of identifiable personal information in a manner that assures that such action is for a necessary and lawful purpose, that the information is current and accurate for its intended use, and that adequate safeguards are provided to prevent misuse of such information; (5) permit exemptions from the requirements with respect to records provided in this Act only in those cases where there is an important public policy need for such exemp- tion as has been determined by specific statutory authority; and (6) be subject to civil suit for any damages which occur as a result of willful or inten- tional action which violates any individual's rights under this Act. A.1.1 Cross-References and Comments TABLE A-3. Privacy Act of 1974-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance Sec.2(b)(1) X X Sec.2(b)(2) X X Sec.2(b)(3) X X X Sec.2(b)(4) X X X X X X Sec.2(b)(5) X X Sec.2(b)(6) X Sec.2(b)(1) [Security Policy] The type(s) of information about a particular individual, represented as records which are stored and processed by an agency, must be releasable to that individ- ual. [Accountability] An agency is accountable for the accurate and timely response to individuals requesting the types of privacy information collected, maintained, used, or disseminated by that agency. Sec.2(b)(2) [Security Policy] The capability for an individual to restrict subsequent, additional uses of personal information which was collected for a particular use is implied. [Accountabil- ity] An appropriate history of the actual uses of personal information must be main- tained. Sec.2(b)(3) [Security Policy] Individuals have to right to obtain copies of personal information held by an agency. A process to correct or amend personal information must exist. [Accounta- bility] All corrections and amendments of individual records should be auditable. [Assur- ance] Appropriate controls on the correction and amendments process should exist. These controls should include the validation of source data used in modifying a record. Sec.2(b)(4) [Security Policy] Safeguards must exist to prevent misuse of information. Federal agen- cies are constrained to necessary and lawful purposes in collecting, maintaining, using, or disseminating personal information. In addition to disclosure, privacy concerns in- clude the acquisition, storage, and manipulation of information relating to individuals. [MAC, DAC] Collection, maintenance, use, and dissemination of personal information are subject to mandatory controls. [Marking] Information associated with a particular in- dividual must be appropriately marked. [Accountability] The actual use of information must be audited whenever such use does not comply with standing policies. [Assurance] Information must be current and accurate with respect to its intended use. Sec.2(b)(5) [Security Policy] The capability to permit exemptions via override of normal controls is required. Such exemptions may remain subject to other mandatory controls. For in- stance, certain records about individuals held by the Internal Revenue Service may not, under normal operating procedures, be accessed by the Federal Bureau of Investigation (FBI); these records may become releasable to the FBI during the course of an investiga- tion, but only after a valid warrant has been issued. [Accountability] Exemptions to nor- mal operating policies may require auditing. The exemption categories listed by this Act may each have unique auditing requirements. Sec.2(b)(6) [Accountability] An agency is held accountable for all its uses of personal information. Individuals having administrative control over personal information must be held ac- countable for their actions with respect to uses of that information. A.2 Computer Matching and Privacy Protection Amendments of 1990- Public Law 101-508 Public Law 101-508 provides protection against privacy violations due to information matching policies of the Federal government [Russell 1991, p. 288]. This Act amends 5 USC 552a, the codified version of the Privacy Act of 1974. It sets forth requirements for the independent verification of information about individuals produced by ``matching programs,'' i.e., through automated techniques. The Act requires that such information be verified before any adverse action-such as the denial of payment under a Federal benefit program-is carried out. The essence of this law with respect to integrity-related control objectives is to impose procedural controls on the modification of data. Also specified in this Act are the notification requirements of an agency to an individual who is subject to adverse action. The following table contains selected sections of Public Law 101-508. The cross-reference table and comments appear in the next section. TABLE A-4. Computer Matching and Privacy Protection Amendments of 1990-Selected Source Text Sec. 7201. Computer Matching of Federal Benefits Information and Privacy Protection. (b) Verification Requirements Amendment.-- (1) Subsection (p) of section 552a of title 5, United States Code, is amended to read as follows: (p) Verification and Opportunity to Contest Findings.-- (1) In order to protect any individual whose records are used in a matching pro- gram, no recipient agency, non-Federal agency, or source agency may suspend, ter- minate, reduce, or make a final denial of any financial assistance or payment un- der a Federal benefit program to such individual, or take other adverse action against such individual, as a result of information produced by such matching pro- gram, until-- (A) (i) the agency has independently verified the information; or (ii) the Data Integrity Board of the agency, or in the case of a non-Federal agency the Data Integrity Board of the source agency, determines in accordance with guidance issued by the Director of the Office of Management and Budg- et that-- (I) the information is limited to identification and amount of bene- fits paid by the source agency under a Federal benefit program; and (II) there is a high degree of confidence that the information provided to the re- cipient agency is accurate; (B) the individual receives a notice from the agency containing a statement of its findings and informing the individual of the opportunity to contest such findings; and (C) (i) the expiration of any time period established for the program by stat- ute or regulation for the individual to respond to that notice; or... (2) Independent verification referred to in paragraph (1) requires investigation and confirmation of specific information relating to an individual that is used as a ba- sis for an adverse action against the individual, including where applicable investi- gation and confirmation of-- (A) the amount of any asset or income involved; (B) whether such individual actually has or had access to such asset or in- come for such individual's own use; and (C) the period or periods when the individual actually had such asset or in- come. (3) Notwithstanding paragraph (1), an agency may take any appropriate action oth- erwise prohibited by such paragraph if the agency determines that the public health or public safety may be adversely affected or significantly threatened during any notice period required by such paragraph. A.2.1 Cross-References and Comments TABLE A-5. Computer Matching and Privacy Protection Amendments of 1990-Cross- References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance (p)(1) X (p)(1)(A) X (p)(1)(B-C) X X (p)(2)(A-C) X (p)(3) X (p)(1) [Security Policy] One may not directly modify data based on the results of automated ``matching programs.'' Procedural controls and control information are required to verify information which forms the basis of an adverse action throughout the process of carry- ing out the adverse action against an individual. May apply to application-specific securi- ty policies, with some applications having unique requirements. (p)(1)(A) [Assurance] The information which forms the basis of an adverse action must either (i) be independently verified or (ii) be limited in scope, with a high degree of confidence in its accuracy. (p)(1)(B-C) [Marking] The capability to enable or disable transactions conferring benefits is implied. Transaction of adverse action requires marking to indicate expiration of a grace period and/or an individual's possible response (i.e., a pending challenge to decision). Transac- tion of adverse action requires marking that individual has received notice. [Accountabil- ity] Procedural controls must exist to ensure that no adverse action proceeds without first meeting verification and/or control information requirements. The system must be able to record and collate appropriate historical information related to benefits transac- tions. The system must keep account of the initiation, length, and expiration of the grace period. (p)(2)(A-C) [Assurance] Independent verification requires investigation and confirmation of specific information which forms the basis of an adverse action. (p)(3) [Security Policy] Stated requirements are subject to exemption when considering addi- tional policies (i.e., public health and public safety policies). A.3 Paperwork Reduction Act of 1980-Public Law 96-511 Public Law 96-511 promotes the use of efficient office systems (e.g., electronic mail, document storage, and electronic imaging systems) under the management of OMB [Russell 1991, p. 279]. This Act simultaneously encourages the automation of information services and adds responsibilities for the use of automation. Under this Act, automation must be used to improve both services provided by, and management of, Federal Agencies. Additionally, such automation must be cost effective (maximizing usefulness of information while minimizing costs to collect, maintain, use, and disseminate information) and supportive of ``uniform'' Federal information policies. The following table contains selected sections of Public Law 96-511. The cross-reference table and comments appear in the next section. TABLE A-6. Paperwork Reduction Act of 1980-Selected Source Text Sec.2.(a) Chapter 35 of title 44, United States Code, is amended to read as follows: 3501. Purpose The purpose of this chapter is- (1) to minimize the Federal paperwork burden for individuals, small business, State and local governments, and other persons; (2) to minimize the cost to the Federal Government of collecting, maintaining, us- ing, and disseminating information; (3) to maximize the usefulness of information collected by the Federal Govern- ment; (4) to coordinate, integrate and, to the extent practicable and appropriate, make uni- form Federal information policies and practices; (5) to ensure that automatic data processing and telecommunications technologies are acquired and used by the Federal Government in a manner which improves service delivery and program management, increases productivity, reduces waste and fraud, and, wherever practicable and appropriate, reduces the information processing burden for the Federal Government and for persons who provide infor- mation to the Federal Government; and (6) to ensure that the collection, maintenance, use and dissemination of informa- tion by the Federal Government is consistent with applicable laws relating to confi- dentiality, including section 552a of title 5, United States Code, known as the Pri- vacy Act. 3506. Federal agency responsibilities (a) Each agency shall be responsible for carrying out its information management activities in an efficient, effective, and economical manner, and for complying with the information policies, principles, standards, and guidelines prescribed by the Director. A.3.1 Cross-References and Comments TABLE A-7. Paperwork Reduction Act of 1980-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance 3501(4) X 3506(a) X X 3501(4) [Security Policy] The essence of this law affects Security Policy in that its purpose is to coordinate, integrate, and make uniform Federal information policies and practices. One integration framework might include the information life cycle (e.g., origin or acquisi- tion through final disposition). Factors to consider include cost effectiveness and risk re- duction relating to information processing activities. Cost effectiveness is a function of the cost of controls versus the degree of acceptable risk. 3506(a) [Security Policy] Information management must be efficient, effective, and economical. Minimizing the paperwork burden and associated costs of collecting, maintain, using, and disseminating information are required. Automated systems are required to improve service delivery, program management, productivity, and to reduce waste, fraud, and in- formation processing burden. Confidentiality policies must also be enforced. Information which is not useful should not be collected. Maximizing the usefulness of collected in- formation is required. Information that is no longer useful should not be maintained. Sys- tems are required to enforce integrated policies. This implies a significant effort must be undertaken to address the overall system security policy, and in particular the issue where different component policies might produce conflicts. [Accountability] Compli- ance with multiple policies, standards, and guidelines is required. A.4 Department of Defense Authorization Act of 1982-Public Law 97-86 The Warner Amendment to Public Law 97-86 exempts certain types of DoD procurements from the Automatic Data Processing Equipment Act (Public Law 89-306, also know as the Brooks Act). The exempted procurements includes those in which the function, operation, or use of a particular piece of equipment or a service involves one or more categories related to national security or military interests [Russell 1991, p. 280]. The following table contains selected sections of Public Law 97-86. The cross-reference table and comments appear in the next section. TABLE A-8. DoD Authorization Act of 1982-Selected Source Text Sec. 908.(a)(1) Chapter 137 of title 10, United States Code, is amended by adding at the end thereof the following new section: 2315. Law inapplicable to the procurement of automatic data processing equipment and services for certain defense purposes (a) Section 111 of the Federal Property and Administrative Services Act of 1949 (40 U.S.C. 795) is not applicable to the procurement by the Department of Defense of auto- matic data processing equipment or services if the function, operation, or use of the equipment or services- (1) involves intelligence activities; (2) involves cryptologic activities related to national security; (3) involves the command and control of military forces; (4) involves equipment that is an integral part of a weapon or weapons system; or (5) subject to subsection (b), is critical to the direct fulfillment of military or intel- ligence missions. (b) Subsection (a)(5) does not include procurement of automatic data processing equip- ment or services to be used for routine administrative and business applications (includ- ing payroll, finance, logistics, and personnel management applications)... A.4.1 Cross-References and Comments TABLE A-9. DoD Authorization Act of 1982-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance 2315(a)(1-5) X 2315(b) X 2315(a)(1-5) [Security Policy] This Act excludes certain systems, during acquisition, from the applica- tion of specific aspects of Federal law. The exclusions named in this Act, relating to the procurement of automatic data processing (ADP) equipment or services, extend to most of all the other Acts applying to Federal systems. Most of these exclusion categories re- late to systems requiring secrecy and integrity protection. Simply having authorization to be exempt does not make it a good practice to avoid a thorough analysis of a system's protection needs. Each acquisition should address its protection needs through the formu- lation and analysis of a systems security policy that will enable a more informed deci- sion regarding invocation of this Act. 2315(b) [Security Policy] Explicitly precludes from ``mission critical'' exemption many DoD auto mated systems relating to routine administrative and business applications. There- fore, many systems used within the DoD are subject to Federal laws. A.5 Federal Managers' Financial Integrity Act of 1982-Public Law 97-255 This Act extends security policies into the realm of internal controls. Systems of internal control are of interest when considering integrity in AISs because (a) primary applications, which are the focus of traditional internal controls, are being automated to greater degrees, and (b) internal control systems themselves are being automated to greater degrees. Internal controls are usually associated with assets having ``value.'' Information within Federal AISs is readily termed a valuable asset according to [OMB A-130]. This Act requires adherence to the Comptroller General's (GAO) Standards for Internal Control in the Federal Government [GAO 1983], which are incorporated into [GAO Title 2, App.II]. The following table contains selected sections of Public Law 97-255. The cross-reference table and comments appear in the next section. TABLE A-10. Federal Managers' Financial Integrity Act of 1982-Selected Source Text Sec. 2. Section 113 of the Accounting and Auditing Act of 1950 (31 U.S.C. 66a) is amended by adding at the end thereof the following new subsection: (d)(1)(A) To ensure compliance with the requirements of subsection (a)(3) of this section, internal accounting and administrative controls of each executive agency shall be established in accordance with standards prescribed by the Comptroller General, and shall provide reasonable assurance that- (i) obligations and costs are in compliance with applicable law; (ii) funds, property, and other assets are safeguarded against waste, loss, un- authorized use, or misappropriation; and (iii) revenues and expenditures applicable to agency operations are properly recorded and accounted for to permit the preparation of accounts and reliable financial and statistical reports and to maintain accountability over the assets. (B) The standards prescribed by the Comptroller General under this paragraph shall include standards to ensure the prompt resolution of all audit findings.... (3)... the head of each executive agency shall... prepare a statement- (A) that the agency's systems of internal accounting and administrative con- trol fully comply with the requirements of paragraph (1); or (B) that such systems do not fully comply with such requirements. (5) The statements and reports required by this subsection... shall also be made available to the public, except that, in the case of any such statement or report con- taining information which is- (A) specifically prohibited from disclosure by any provision of law; or (B) specifically required by Executive order to be kept secret in the interest of national defense or the conduct of foreign affairs, such information shall be deleted prior to the report or statement being made available to the public. A.5.1 Cross-References and Comments TABLE A-11. Federal Managers' Financial Integrity Act of 1982-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance (d)(1)(A)(i-iii) X X X X X X (d)(1)(B) X (d)(3) X (d)(5) X X X X X (d)(1)(A)(i-iii) [Security Policy] Legal compliance related to organizational obligations and costs (e.g., contracts, logistics, funds transfer, services, etc.) must be considered in the formulation of Security Policy. Security policy must address waste, loss, unauthorized use, and mis- appropriation in terms of both AIS assets as well as other assets, whenever these non- AIS assets are either represented within or controlled via AISs. [MAC, DAC, Marking] Because the control of ``unauthorized use'' is explicitly called for, authorization features are required. [Accountability] Costs and obligations must be internally accounted for within an organization to the level of a responsible individual acting within the scope of his authority. [Assurance] Reasonable assurance is required. (d)(1)(B) [Accountability] Prompt resolution of audit findings requires specific features for AIS systems. These may include audit reduction tools, real-time alerts, etc. (d)(3) [Assurance] The head of each executive agency is required to produce a report on the state of that agency's internal control system. (d)(5) [Security Policy] Mandated disclosure of information is also subject to restrictions of na- tional security and other (confidentiality) policies. [MAC, DAC, Marking] The overlap- ping of confidentiality and integrity policy coverage has implications for MAC policy with regard to information sanitation and downgrading of classified or sensitive informa- tion. There are also implications for DAC policy with regard to the designated individu- als performing these types of operations. [Accountability] Auditing of all downgrading and sanitation activity shall be performed. A.6 Computer Security Act of 1987-Public Law 100-235 Public Law 100-235 expands the definition of computer security protection and clarifies the role of the (NBS now the National Institute of Standards and Technology) [Russell 1991, p. 283]. A primary function of this Act is to prescribe authority and assign responsibilities for developing security standards and guidelines for Federal computer systems. This Act has broadens the scope of applicability for security policies in three areas: the range of resources, the type(s) of information, and the types of systems. Significantly, this Act also increases types of computers under consideration as well as the scope of information which must be protected. The Act defines computer systems broadly and includes support services as an area which must be considered. This can be interpreted to mean that effective controls must exist over AIS support systems and personnel, as well as those individuals who operate the primary applications. The traditional scope of information protection was increased as well. Previously, explicit protection policy applied only to ``classified'' and ``specifically categorized sensitive'' information. This Act applies to a more encompassing term, ``sensitive information,'' which is defined in detail below. The following table contains selected sections of Public Law 100-235. The cross-reference table and comments appear in the next section. TABLE A-12. Computer Security Act of 1987-Selected Source Text Sec.2. Purpose. (a) In General.-The Congress declares that improving the security and privacy of sensi- tive information in Federal computer systems is in the public interest, and hereby creates a means for establishing minimum acceptable security practices for such systems, with- out limiting the scope of security measures already planned or in use. (b) Specific Purposes.-The purposes of this Act are- (1) by amending the Act of March 3, 1901, to assign to the National Bureau of Standards responsibility for developing standards and guidelines for Federal com- puter systems, including responsibility for developing standards and guidelines needed to assure the cost-effective security and privacy of sensitive information in Federal computer systems, drawing on the technical advice and assistance (includ- ing work products) of the National Security Agency, where appropriate; (2) to provide for promulgation of such standards and guidelines by amending sec- tion 111(d) of the Federal Property and Administrative Services Act of 1949; (3) to require establishment of security plans by all operators of Federal computer (4) to require mandatory periodic training for all persons involved in management, use, or operation of Federal computer systems that contain sensitive information. Sec.3. Establishment of Computer Standards Program. The Act of March 3, 1901 (15 U.S.C. 271-278h), is amended- (2)... by inserting... ``Sec.20'' (d) As used in this section- (1) the term ``computer system''- (A) means any equipment or interconnected system or subsystems of equipment that is used in the automatic acquisition, storage, manipula- tion, management, movement, control, display, switching, interchange, transmission, or reception, of data or information; and (B) includes- (i) computers; (ii) ancillary equipment; (iii) software, firmware, and similar procedures; (iv) services, including support services; and (iv) related resources as defined by regulations issued by the Ad- ministrator for General Services . . . (4) the term `sensitive information' means any information, the loss, misuse, or unauthorized access to or modification of which could adversely affect the national interest or the conduct of Federal programs, or the privacy to which individuals are entitled . . . , but which has not been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept secret in the interest of national defense or foreign policy; Legislative History [The Legislative History of the Computer Security Act of 1987 [H. Rept. 100-153(I), p. 24] gives examples of that which should be considered ``sensitive information:'' . . . information which if modified, destroyed or disclosed in an unauthorized manner could cause: Loss of life; Loss of property or funds by unlawful means; Violation of personal privacy or civil rights; Gaining of an unfair commercial advantage; Loss of advanced technology, useful to a competitor; or Disclosure of proprietary information entrusted to the government.] Sec.5. Amendment to Brooks Act. Section 111(d) of the Federal Property and Administrative Services Act of 1949 (40 U.S.C. 759(d)) is amended to read as follows: (d)(1) The Secretary of Commerce shall, on the basis of standards and guidelines developed by the [National Institute of Standards and Technology] . . . promulgate standards and guidelines pertaining to Federal computer systems, making such standards compulsory and binding to the extent to which the Secretary determines necessary to improve the efficiency of operation or security and privacy of Federal computer systems. . . . (d)(2) The head of a Federal agency may employ standards for the cost-effective security and privacy of sensitive information in a Federal computer system within or under the supervision of that agency that are more stringent than the standards promulgated by the Secretary of Commerce, if such standards contain, at a mini- mum, the provisions of those applicable standards made compulsory and binding by the Secretary of Commerce. (d)(4) The Administrator shall revise the Federal information resources manage- ment regulations . . . to be consistent with the standards and guidelines promulgat- ed by the Secretary of Commerce. Sec.6. Additional Responsibilities for Computer Systems Security and Privacy. (a) Identification of Systems That Contain Sensitive Information.- . . . each Feder- al agency shall identify each Federal computer system, and system under develop- ment, which is within or under the supervision of that agency and which contains sensitive information. (b) Security Plan.- . . . each agency shall, consistent with the standards, guidelines, policies, and regulations prescribed pursuant to section 111(d) of the Federal Prop- erty and Administrative Services Act of 1949, establish a plan for the security and privacy of each Federal computer system identified by that agency pursuant to sub- section (a) that is commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information contained in such system. . . . A.6.1 Cross-References and Comments TABLE A-13. Computer Security Act of 1987-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance Sec.3(2)(d)(1) X Sec.3(2)(d)(4) X X X X Sec.3(Leg.His.) X X X Sec.5(d)(1,2,4) X Sec.6(a-b) X Sec.3(2)(d)(1) [Security Policy] This Act applies to ``computer systems,'' a range of resources includ- ing equipment, software, services, and related resources. This implies an increased scope of system Security Policies with regard to the range of applicable resources. Sec.3(2)(d)(4) [Security Policy] By defining the type of applicable information, this Act explicitly in- creases the scope of the Security Policy-in particular, the systems containing ``sensitive information'' must provide protection for that information. [MAC, DAC, Marking] Be- cause the control of ``unauthorized use'' is explicitly called for, authorization features are required. Sec.3(Leg.His.) [Security Policy, Assurance, Fault Tolerance] The considerations for ``loss of life'' great- ly increases the scope of systems which are applicable under this Act. The inclusion of computer systems which control machinery or processes also has important implications for the scope of the Security Policy. In particular, the inclusion of safety-critical systems is implied, although there is currently a lack of explicit policy statements in this area. Sec.5(d)(1,2,4) [Security Policy] The Act contains details relevant to the formulation of individual (agen- cy) Security Policies. These show that the agencies involved might have to prescribe and integrate different security policies and standards to meet their unique needs. Sec.6(a-b) [Security Policy] All systems identified as containing sensitive information are subject to Security Policy requirements. An organization (agency) must develop individual secu- rity plans for computer systems containing ``sensitive information.'' These plans may provide greater insight into Security Policy needs. A.7 OMB Circular No. A-127-Financial Management Systems OMB Circular No. A-127 establishes a program to assure the integrity of Federal financial management systems (FMSs) by prescribing policies and procedures for executive departments and agencies. Financial management systems are of interest primarily because the control of revenue, expenditure, funds, property, and other assets are often-either partially or totally-implemented via AISs. Therefore, policy related to FMSs must be effectively enforced on these related AISs. There are five particular control areas for FMSs called for under this Circular [OMB A- 127, p. 4]: FMS operations, FMS integrity, support for budgets, support for management, and full financial disclosure. Each of these areas has specific implications for integrity when considering (possible) automated features of an FMS. The most demanding and significant implications for AIS integrity fall under the area of FMS operations. Specific objectives for FMS operations address the areas of usefulness, timeliness, reliability and completeness, comparability and consistency, and efficiency and economy. The use of automated systems to help achieve these objectives is explicitly called for [OMB A-127, p. 4]. Any particular executive department or agency may have unique requirements for one or more of the preceding control areas or FMS control objectives. The importance of this Circular is not in calling out specific, detailed requirements, but in recognizing specific areas in which controls must exist to enforce financial management policies. These areas must be addressed by AIS integrity policies on automated implementations of FMSs. This Circular has implications for both system and application-oriented security policies. The following table contains selected sections of OMB Circular No. A-127. The cross- reference table and comments appear in the next section. TABLE A-14. OMB Circular No. A-127-Selected Source Text 1. Purpose. This Circular prescribes policies and procedures to be followed by executive departments and agencies in developing, operating, evaluating, and reporting on finan- cial management systems. 2. Background. The Budget and Accounting Procedures Act of 1950, the Federal Manag- ers' Financial Integrity Act, and related legislation . . . provide that: -- Establishing and maintaining systems of accounting and reporting is the respon- sibility of the executive branch. -- Agency systems shall provide for: · complete disclosure of the financial results of the activities of the agency, · adequate financial information for agency management and for formulation and execution of the budget, · effective control over revenue, expenditure, funds, property, and other assets. 3. Policy. The financial management system of each agency shall meet the objectives set forth in Section 6 of this Circular. These objectives are intended to establish a frame- work for complying with applicable law, appropriate budget and accounting principles and standards, Treasury reporting requirements, and the best contemporary financial practice. Systems developed and operated under this Circular shall be the source for fi- nancial information used in the budget, Treasury financial statements, financial reports to the Congress, and other financial reports. Agencies shall establish and maintain a single, integrated financial management system, which may be supplemented by subsidiary systems. Data needed in this system and oth- er agency systems shall be entered only once and transferred automatically to appropri- ate accounts or other parts of the system or systems. New or substantially revised sys- tems shall be developed on an inter-agency basis and designed to meet the needs of all participating agencies. Funds shall be expended only for systems that meet the require- ments of this Circular. 6. Financial Management System Objectives. The following objectives shall be met by the agency financial management system in complying with applicable law and appropri- ate guidance of GAO, Treasury, and OMB. . . . a. Systems operations -- the agency financial management system shall use the best of acceptably priced, contemporary technology -- including automated data en- try and edit, data management, data base dictionaries, electronic communications between systems, flexible report formats, and controlled access to data bases by personal computers and other means -- to achieve the following objectives. (1) Usefulness -- financial management data shall be gathered and processed only where necessary to meet specific internal management needs or external requirements. Reports shall be tailored to specific user needs and if report us- ages does not justify cost, reports shall be terminated. Usefulness shall be de- termined in part through consultation with users as part of the reviews re- quired by Section 7b of this Circular. (2) Timeliness -- financial manage- ment data shall be recorded as soon as practicable after the occurrence of the event, and relevant preliminary data shall be made available to managers by the fifth working day following the end of the reporting period. Other stand- ards of timeliness may be established where the agency has inventoried re- ports and set specific standards, with user participation. Final, corrected data shall be available in time to meet external reporting requirements. (3) Reliability and completeness -- financial management information shall be reasonably complete and accurate, shall be verifiable and ordinarily be drawn from the official records and systems, and shall be no more detailed than necessary to meet the needs of management and external requirements. (4) Comparability and consistency -- financial management data shall be re- corded and reported in the same manner throughout the agency, using uni- form definitions. Accounting shall be synchronized with budgeting. Consist- ency over time shall be maintained. New and revised systems shall adopt common, existing definitions and classifications. (5) Efficiency and economy -- the agency financial management system shall be designed and operated with reasonable total costs and transaction costs, in accordance with OMB guidelines. Financial systems which are excessively costly shall be identified and phased out. This shall be accomplished through installation of effective systems of planning and evaluation, sharing of data, elimination of overlap and duplication, and use of the best contemporary technology, including commercially available packages with proven success in other agencies or the private sector. b. Systems integrity -- the agency financial management system shall feature rea- sonable controls designed, operated, and evaluated in accordance with OMB Circu- lar A-123, Internal Control Systems, and A-71 [rescinded by A-130], Responsibili- ties for the Administration and Management of Automatic Data Processing Facili- ties. c. Support for budgets -- financial management data shall be recorded, stored, and reported to facilitate budget preparation, analysis, and execution. Data shall be clas- sified uniformly and that classification, at a minimum, shall be at a level of detail that directly supports execution of enacted budgets and formulation of proposed budgets, without excessive aggregation or disaggregation. . . . d. Support for management -- data shall be recorded and reported in a manner to facilitate carrying out the responsibilities of both program and administrative man- agers. The agency financial management system shall provide for a coherent, time- ly, and accurate financial management data base. It should be supplemented as nec- essary to meet agency management and Executive Office requirements for adminis- trative data, such as the Financial and Administrative Management Information System 1. . . . e. Full financial disclosure -- financial management data shall be recorded, and re- ported as specifically required by OMB or Treasury, to provide for full financial disclosure and accountability in accordance with appropriate budget and account- ing principles and standards. . . . A.7.1 Cross-References and Comments TABLE A-15. OMB Circular No. A-127-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance 3 X X X X 6(a) X X X X X X 6(a)(1) X X 6(a)(2) X X X 6(a)(3) X X X 6(a)(4) X 6(a)(5) X X 6(b) X X 6(c) X 6(d) X X X 6(e) X X X 3 [Security Policy, Accountability] AIS portions of financial management systems must comply with applicable law, budget and accounting principles and standards, Treasury reporting requirements, and the best contemporary financial practice. A specific adminis- trative policy is cited in regard to data handling and security controls. [Assurance, Fault Tolerance] The single point-of-entry requirement for input of data to the system, specify- ing automatic transfer of data to required locations, implies rigorous administrative and reliability features. 6(a) [Security Policy] The use of AISs to implement financial management systems is explic- itly called for. Controlled access to data bases is required. [MAC, DAC, Marking] Pro- viding controlled access implies that these control objectives will be affected. [Accounta- bility] This is implied when access control is required. [Assurance] Particular automated features called for implies the need for assurance measures with rigor defined by accept- able risk and reasonable cost as well as the need for a thorough risk analysis. 6(a)(1) [Security Policy] Financial management data shall be gathered and processed only where necessary to meet specific internal management needs or external requirements. [Accountability] Reports are tailored to specific user needs. 6(a)(2) [Security Policy, Accountability] Financial management data shall be recorded as soon as possible and made available in a timely manner. Specific standards of timeliness may be established. This implies the need for internal timing attributes and control policies re- lated to timing. [Assurance] Corrected data shall be available in time to meet external re- porting requirements. 6(a)(3) [Security Policy] Financial management information shall be reasonably complete and accurate. This implies specifications for completeness and accuracy that can be moni- tored and reacted to when the specified attributes or attribute values do not meet speci- fied thresholds. [Accountability] Further, it implies identified responsibility for all ac- tions taken on the specified information. Accountability is also implied by the verifica- tion requirement. [Assurance] That information should be verifiable implies reconciling transactions with starting and ending totals, dual-entry accounting, or external ``safety paper'' (e.g., checks, withdrawal slips, and/or deposit slips). 6(a)(4) [Security Policy] Uniform system definitions (process and data) for related systems are required. Consistency of financial management data over time is required. Synchronized functions (e.g., accounting and budgeting) are required. 6(a)(5) [Security Policy, Assurance] Operational costs must be reasonable and in accordance with OMB guidelines. Effective planning and evaluation, sharing of data, elimination of duplication, and the use of the best contemporary technology is required. This implies that a thorough risk analysis must be performed to ascertain protection requirements. 6(b) [Security Policy, Assurance] AIS portions of financial management systems must feature reasonable controls designed, operated, and evaluated in accordance with OMB policy. Again, the implication for a thorough risk analysis for protection controls is established by the use of the term ``reasonable.'' 6(c) [Security Policy] Uniform system of data categorization is required. The budget process shall be supported. Excessive aggregation or disaggregation is not acceptable. This is an application-specific security policy issue. 6(d) [Security Policy, Accountability, Assurance] Data shall be recorded and reported in a manner to facilitate carrying out the responsibilities of managers. The financial manage- ment system shall be coherent, timely, and accurate. 6(e) [Security Policy, Accountability] Financial management data shall be recorded. Reports shall provide full financial disclosure and accountability in accordance with appropriate budget and accounting principles and standards. [Assurance] Accuracy and completeness of data being disclosed has implications for assurance. A.8 OMB Circular No. A-130-Management of Federal Information Re- sources OMB Circular No. A-130 establishes requirements for effective and efficient management of federal information resources. This Circular requires all agency information systems to provide a level of security commensurate with the sensitivity of the information, the risk of its unauthorized access, and the harm that could result from improper access. It also requires all agencies to establish security programs to safeguard the sensitive information that they process [Russell 1991, p. 282]. As such, it sets forth policy regarding information management within Federal agencies that bear directly on the protection issues of confidentiality, integrity, and availability. That these issues are intended to be within the scope of this Circular is explicitly stated in Appendix IV [p. 52749]: Security of information systems means both the protection of information while it is within the systems and also the assurance that the systems do exactly what they are sup- posed to do and nothing more. Information system security entails management controls to ensure the integrity of operations including such matters as proper access to the infor- mation in the systems and proper handling of input and output. In this sense, security of information is first and foremost a management issue and only secondly a technical prob- lem of computer security. . . . Protecting personal, proprietary, and other sensitive data from unauthorized access or misuse; detecting and preventing computer related fraud and abuse; and assuring continuity of operations of major information systems in the event of emergency related disruptions are increasingly serious policy issues. . . . The Paperwork Reduction Act of 1980 establishes a broad mandate for efficient, effective, and economical performance of information activities by agencies. Circular No. A-130 implements OMB authority under the 1980 Act with respect to general information policy, records management, privacy, and Federal automatic data processing and telecommunications. In addition, it also implements sections of the Privacy Act of 1974 as well as other Federal Laws and Executive policy statements. Circular No. A-130 revises and consolidates policy and procedures in five previous OMB directives, which were rescinded through this Circular. One reason for issuing this Circular was OMB's determination that it was important to distinguish the statement of policies from the procedures for implementing those policies. As a result, the main body of the Circular is a statement of basic considerations and assumptions, policies, and responsibility assignments. Appendices I, II, and III to the Circular consist of procedures for implementing various policies. These Appendices have the same prescriptive force as the Circular itself, and hence, were included in the extraction of Selected Source Text, below. Appendix IV to the Circular is an explanatory document, and was used in our analysis of the Source Text. Appendix III of this Circular, together with OMB Circular No. A-123 (Internal Control Systems), provide the evaluation and reporting requirements for the systems integrity objective contained in OMB Circular No. A-127 (Financial Management Systems). Due to a similar treatment of the subject, this Circular [App.III, Sec.(2)(c)] appears to be the source of the definition of ``sensitive information'' used in The Computer Security Act of 1987. Significantly, the Circular [App.III, manner which has particular significance for policy related to safety-critical systems. This Circular is undergoing revision with a version available for public comment expected in the near future. Although the exact changes to be incorporated in revision have not been determined, the available information indicates that the major focus of change will be on policy regarding public access to agency information holdings and the dissemination of electronic information products to Federal depository libraries. Also incorporated will be changes called for by legislation passed since the 1985 publication of this Circular. OMB plans call for work on the revised Circular to continue through 1992 [OMB 1991, p. 9026]. The following table contains selected sections of OMB Circular No. A-130. The cross- reference table and comments appear in the next section. TABLE A-16. OMB Circular No. A-130-Selected Source Text 7. Basic Considerations and Assumptions: b. Government information is a valuable national resource. It provides citizens with knowledge of their government, society, and economy-past, present, and fu- ture; is a means to ensure the accountability of government; is vital to the healthy performance of the economy; is an essential tool for managing the government's operations; and is itself a commodity often with economic value in the market- place. c. The free flow of information from the government to its citizens and vice versa is essential to a democratic society. It is also essential that the government mini- mize the Federal paperwork burden on the public, minimize the cost of its informa- tion activities, and maximize the usefulness of government information. d. In order to minimize the cost and maximize the usefulness of government infor- mation activities, the expected public and private benefits derived from govern- ment information, insofar as they are calculable, should exceed the public and pri- vate costs of the information. f. The use of up-to-date information technology offers opportunities to improve the management of government programs, and access to, and dissemination of, govern- ment information. . . . 8. Policies a. Information Management. Agencies shall: (1) Create or collect only that information necessary for the proper performance of agency functions and that has practical utility, and only after planning for its processing, transmission, dissemination, use, storage, and disposition; (2) Seek to satisfy new information needs through legally authorized inter-agency or intergov- ernmental sharing of information, or through commercial sources, where appropri- ate, before creating or collecting new information; (3) Limit the collection of individually identifiable information and proprietary in- formation to that which is legally authorized and necessary for the proper perform- ance of agency functions; (4) Maintain and protect individually identifiable information and proprietary infor- mation in a manner that precludes: (a) Unwarranted intrusion upon personal privacy (see Appendix I); and (b) Violation of confidentiality; (5) Provide individuals with access to, and the ability to amend errors in, systems of records, consistent with the Privacy Act; (6) Provide public access to government information, consistent with the Freedom of Information Act. (7) Ensure that agency personnel are trained to safeguard information resources. (8) Disseminate information, as required by law, describing agency organization, activities, programs, meetings, systems of records, and other information holdings, and how the public may gain access to agency information resources; (9) Disseminate such information products and services as are: (a) Specifically required by law; or (b) Necessary for the proper performance of agency functions, . . . (10) Disseminate significant new, or terminate significant existing, information products and services only after providing adequate notice to the public; (11) Disseminate such government information products and services: (a) In a manner that ensures . . . the public . . . have a reasonable ability to acquire the information; (b) In a manner most cost effective for the government, . . . (c) So as to recover costs of disseminating the products or services . . . (12) Establish procedures for: (a) Reviewing periodically the continued need for and manner of dissemina- tion of the agency's information products or services; and (b) Ensuring that government publications are made available to depository libraries as required by law. b. Information Systems and Information Technology Management. Agencies shall: (1) Establish multi-year strategic planning processes for acquiring and operating in- formation technology that meet program and mission needs, reflect budget con- straints, and form the bases for their budget requests; (2) Establish systems of management control that document the requirements that each major information system is intended to serve; and provide for periodic re- view of those requirements over the life of the system . . . (3) Make the official whose program an information system supports responsible and accountable for the products of that system; (4) Meet information processing needs through inter-agency sharing and from com- mercial sources, when it is cost effective, before acquiring new information processing capacity; (5) Share available information processing capacity with other agencies to the ex- tent practicable and legally permissible; (6) Acquire information technology in a competitive manner that minimizes total life cycle costs; (7) Ensure that existing and planned major information systems do not unnecessari- ly duplicate information systems . . . (8) Acquire off-the-shelf software . . . unless the cost effectiveness of developing custom software is clear and has been documented; (9) Acquire or develop information systems in a manner that facilitates necessary compatibility; (10) Assure that information systems operate effectively and accurately; (11) Establish a level of security for all agency information systems commensurate with the sensitivity of the information and the risk and magnitude of loss or harm that could result from improper operation of the information systems (See Appen- dix III); (12) Assure that only authorized personnel have access to information systems; (13) Plan to provide information systems with reasonable continuity of support should their normal operations be disrupted in an emergency; (14) Use Federal Information Processing and Telecommunications Standards ex- cept where it can be demonstrated that the costs of using a standard exceed the benefits or the standard will impede the agency in accomplishing its mission; (15) Not require program managers to use specific information technology facili- ties or services unless it is clear and convincingly documented, subject to periodic review, that such use is the most cost effective method for meeting program re- quirements. (16) Account for the full costs of operating information technology facilities and recover such costs from government users . . . (17) Not prescribe Federal information system requirements that unduly restrict the prerogatives of heads of State and local government units; (18) Seek opportunities to improve the operation of government programs or to re- alize savings for the government and the public through the application of up-to- date information technology to government information activities. Appendix I to OMB Circular No. A-130-Federal Agency Responsibilities for Maintain- ing Records About Individuals 4. Reporting Requirements. b. New and Altered System Reports. . . . (1) Altered System of Records. . . . The following changes are those for which a report is required: (b) A change that expands the types or categories of information maintained. For example, a personnel file that has been expanded to include medical records would require a report. (c) A change that alters the purpose for which the information is used. Appendix II to OMB Circular No. A-130-Cost Accounting, Cost Recovery, and Inter- agency Sharing of Information Technology Facilities) Supplemental Information. Several commentators believed that requiring full costs to be recovered from all users within an agency would not be cost effective. OMB disagreed with this viewpoint and retained the draft Circular's formulation. Viable management of a large information tech- nological facility requires that managers know the amount of resources devoted to each user when providing services. Furthermore, effective management of the use of informa- tion technology requires that the user have responsibility for and control over the re- sources consumed by use of the facility. . . . Appendix III to OMB Circular No. A-130-Security of Federal Automated Information Systems 1. Purpose. This Appendix establishes a minimum set of controls to be included in Fed- eral automated information systems security programs; assigns responsibilities for the se- curity of agency automated information systems; and clarifies the relationship between such agency security programs and internal control systems established in accordance with OMB Circular A-123, Internal Control Systems. The Appendix revises procedures formerly contained in Transmittal Memorandum No. 1 to OMB Circular No. A-71, now rescinded, and incorporates responsibilities from applicable national security directives. 2. Definitions. c. The term ``sensitive data'' means data that require protection due to the risk and magnitude of loss or harm that could result from inadvertent or deliberate disclo- sure, alteration, or destruction of the data. The term includes data whose improper use or disclosure could adversely affect the ability of an agency to accomplish its mission, proprietary data, records about individuals requiring protection under the Privacy Act, and data not releasable under the Freedom of Information Act. d. The term ``sensitive application'' means an application of information technolo- gy that requires protection because it processes sensitive data, or because of the risk and magnitude of loss or harm that could result from improper operation or de- liberate manipulation of the application. 3. Automated Information Systems Security Programs. Agencies shall assure an adequate level of security for all agency automated information systems, whether maintained in-house or commercially. Specifically, agencies shall: - Assure that automated information systems operate effectively and accurately; - Assure that there are appropriate technical, personnel, administrative, environ- mental, and telecommunications safeguards in automated information systems; and - Assure the continuity of operation of automated information systems that support critical agency functions. Agencies shall implement and maintain an automated information systems security program, including the preparation of policies, standards, and procedures. This pro- gram will be consistent with government-wide policies, procedures, and standards issued by the Office of Management and Budget, the Department of Commerce, the Department of Defense, the General Services Administration, and the Office of Personnel Management. Agency programs shall incorporate additional require- ments for securing national security information in accordance with appropriate na- tional security directives. Agency programs shall, at a minimum, include four pri- mary elements: applications security, personnel security, information technology in- stallation security, and security awareness and training. a. Applications Security. (1) Management Control Process and Sensitivity Evaluation. Agencies shall establish a management control process to assure that appropriate administra- tive, physical, and technical safeguards are incorporated into all new applica- tions, and into significant modifications to existing applications. Manage- ment officials who are the primary users of applications should evaluate the sensitivity of new or existing applications being substantially modified. For those applications considered sensitive, the management control process shall, at a minimum, include security specifications and design reviews and systems tests. . . . (2) Periodic Review and Re-certification. . . . Audits or reviews shall evalu- ate the adequacy of implemented safeguards, assure they are functioning properly, identify vulnerabilities that could heighten threats to sensitive data or valuable resources, and assist with the implementation of new safeguards where required. . . . A.8.1 Cross-References and Comments TABLE A-17. OMB Circular No. A-130-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance 8(a)(1) X X X 8(a)(2) X X X X X 8(a)(3) X 8(a)(4) X 8(a)(5) X X X 8(a)(6) X 8(a)(7) X X 8(a)(8-11) X 8(a)(12) X X 8(b)(1) X 8(b)(2) X 8(b)(3) X 8(b)(4-5) X 8(b)(6) X 8(b)(8) X X 8(b)(9) X 8(b)(11) X X 8(b)(12) X X X X X X 8(b)(13) X X X 8(b)(15) X X App.I(4) X App.II(Sup.Info.) X X App.III(2)(c) X X X X X App.III(2)(d) X X X X X App.III(3) X App.III(3)(a)(1-2) X 8(a)(1) [Security Policy] Each phase of the information life cycle (e.g., origin or acquisition through final disposition). should be considered in formulating the Security Policy. Only information necessary for proper performance of agency functions, and that has practical utility shall be created or collected. Practical utility includes characteristics ``pertaining to the quality of information such as accuracy, adequacy, and reliability.'' In the case of general purpose statistics or record keeping, practical utility means that ``actual uses can be demonstrated . . .'' [OMB A-130, p. 52746]. Execution authority is derived from the required, approved plans for the processing, transmission, dissemination, use, storage, and disposition of necessary information. The delegation of authority and allocation of resource responsibilities shall be performed for each aspect of the information life cycle. [Accountability] This implies that individuals should be held accountable to performing within the scope of their authority. [Assurance] The documentation of required planning may be used as an assurance measure. 8(a)(2) [Security Policy] This implies that the Security Policy must address the protection of shared information. Sharing should be done under the concept of ``due care'' (i.e., protec- tion commensurate with the risk and magnitude of loss). [MAC, DAC, Marking] The es- tablishment of information sharing agreements must include confirmation that the receiv- ing Agency can mark and protect the shared information as required by the providing Agency. If such protection is not possible, then the providing Agency must determine the need to desensitize the information to the degree commensurate with the maximum protection capabilities of the receiving Agency prior to actual sharing. [Accountability] The receiving Agency should be accountable for the protection of any shared informa- tion it receives. The providing Agency is accountable for the sharing of sensitive infor- mation for which the receiving Agency does not have the capabilities to protect. 8(a)(3) [Security Policy] The collection of individually identifiable and proprietary information must be limited to that which is legally authorized and necessary for agency functions. 8(a)(4) [Security Policy] Confidentiality requirements must be addressed in the Security Policy. 8(a)(5) [Security Policy] Providing a process for individuals to gain access to personal informa- tion is required. [Accountability, Assurance] An amendment and error correcting process for private information must exist. 8(a)(6) [Security Policy] Providing a process for public access may be required. This process shall be consistent with Freedom of Information Act requirements and exemptions. 8(a)(7) [Accountability] This implies that individuals shall be held accountable for adhering to doctrine and procedures in which they have been trained. [Assurance] Security training and documentation in support of security training is required. Such documentation should cover the information life cycle processes, safeguards employed, and individual responsibilities. 8(a)(8-11) [Security Policy] Dissemination of information on Agency information life cycle process- es is required, as required under applicable laws or other relevant policies. 8(a)(12) [Accountability] Procedures for periodic reviews of information life cycle processes are required. [Assurance] Assurance of compliance to laws for dissemination is required. 8(b)(1) [Accountability] Technical protection of information as a part of program and mission needs must be planned for, taking into account budget constraints. The Paperwork Re- duction Act requires that OMB: ``promote the use of the technology to improve govern- mental efficiency and effectiveness. . . .'' 8(b)(2) [Assurance] Information systems requirements documentation is necessary. Periodic re- views are required. 8(b)(3) [Accountability] Overall information product accountability is user based. Specific ac- countability for information products is established at the supported program official. 8(b)(4-5) [Security Policy] Requirements for the sharing of information are outlined. Specific Agency policies regarding information sharing should be established. 8(b)(6) [Assurance] Total life cycle costs must be considered in protection technology acquisi- tion. This should be coupled to the Agency risk assessment. 8(b)(8) [Security Policy] The use (in terms of trustedness) of commercial, off-the-shelf software must be reflected in the Security Policy. [Assurance] ``Trustedness'' implies that process for evaluation of the vulnerabilities of commercial, off-the-shelf software should be es- tablished. The evaluated software must be placed under configuration management once it is accepted. 8(b)(9) [Assurance] Necessary compatibility is considered because ``compatibility among infor- mation systems has . . . emerged as a significant information resources management problem . . .'' [OMB A-130, p. 52749]. Necessary compatibility for integrity protection is required. 8(b)(11) [Security Policy, Assurance] Security features must be adequate for protection with re- gards to the sensitivity of the information and/or application as determined by the Agen- cy risk assessment. 8(b)(12) [Security Policy, MAC, DAC, Marking, Accountability, Assurance] Authorized access to information systems must be assured. This implies an extension of authorized access to specific information. 8(b)(13) [Security Policy, Fault Tolerance] Reasonable continuity of support shall be provided for information systems. [Assurance] Contingencies should not only be planned for but also routinely exercised whenever practicable. 8(b)(15) [Security Policy] This implies a thorough risk assessment has been conducted and that specific protection policy enforcement needs have been identified as being both required and cost effective. [Assurance] Periodic reviews are required. App.I(4) [Accountability] Changes to types or categories of information being maintained, or the purposes to which information is being put to use, must be reported. App.II Sup.Info. [Security Policy] A user has control over assigned resources. [Accountability] A manag- er must know the amount of resources consumed by each user. A user is responsible for assigned resources. App.III(2)(c) [Security Policy] Defines the type of information applicable under this Circular. Indi- cates an increased scope of Security Policy-in particular, the systems containing ``sensi- tive information'' must be protected. [MAC, DAC] Because the control of ``unauthorized use'' is explicitly called for, authorization features are required. [Marking] ``Sensitive in- formation'' must be identifiable. [Accountability] Authorization implies the requirement for accountability for acting within the scope of authority. App.III(2)(d) [Security Policy] Defines the type of application applicable under this Circular. The as- sessment of risk, loss, or harm resulting from improper operation or deliberate manipula- tion of an application should be applied to all applications, including embedded applica- tion or control systems, in order to determine their ``sensitivity.'' [MAC, DAC] Because the control of ``improper operation'' or ``deliberate manipulation'' is explicitly called for, authorization features are required. [Marking] ``Sensitive applications'' must be identifia- ble. [Accountability] Authorization implies the requirement for accountability for acting within the scope of authority. App.III(3) [Security Policy] Requires the preparation and maintenance of security policies, stand- ards, and procedures. Outlines basic considerations and the sources of policy for security programs. App.III (3)(a)(1-2) [Assurance] Agencies shall assure that appropriate safeguards are incorporated into all new or modified applications. The adequacy of implemented safeguards shall be evaluat- ed and vulnerabilities identified. Periodic reviews are required. A.9 OMB Circular No. A-123-Internal Control Systems OMB Circular No. A-123 directs agency heads and managers to set up management plans and to take responsibility for eliminating fraud, waste, and abuse in government programs. The aim of this program is to establish confidence and accountability in the protection of Federal operations [Russell 1991, p. 279]. Internal controls are of significance primarily because of the increasing use of automation for both the major applications and the internal control systems of government programs. The Budget and Accounting Act of 1950 sets forth the requirement for each department and agency to establish and maintain adequate systems of internal control. The Federal Managers' Financial Integrity Act amended this earlier Act, adding requirements for (a) the development of internal accounting and administrative control standards by the General Accounting Office, (b) annual evaluations of internal accounting and administrative control systems in accordance with guidelines established by OMB, and (c) annual statements on the status of the agency's system of internal controls. AISs which are integral to internal control systems must adhere to the standards and guidelines prescribed in this Circular. The following table contains selected sections of OMB Circular No. A-123. The cross- reference table and comments appear in the next section. TABLE A-18. OMB Circular No. A-123-Selected Source Text 1. Purpose. This circular prescribes policies and procedures to be followed by executive departments and agencies in establishing, maintaining, evaluating, improving, and report- ing on internal controls in their program and administrative activities. 4. Policy. Agencies shall establish and maintain a cost effective system of internal con- trols to provide reasonable assurance that Government resources are protected against fraud, waste, mismanagement or misappropriation and that both existing and new pro- gram and administrative activities are effectively and efficiently managed to achieve the goals of the agency. The system shall comply with the Integrity Act and the internal con- trol standards developed by the General Accounting Office and implemented by this cir- cular. All levels of management shall be involved in ensuring the adequacy of controls. Internal control does not encompass such matters as statutory development or interpreta- tion, determination of program need, resource allocation, rule-making, or other discre- tionary policy-making processes in an agency. 7. Objectives of Internal Control. The objectives of internal control apply to all program and administrative activities. Internal control systems are to provide management with reasonable assurance that: a. Obligations and costs comply with applicable law. b. Assets are safeguarded against waste, loss, unauthorized use, and misappropria- tion. c. Revenues and expenditures applicable to agency operations are recorded and ac- counted for properly so that accounts and reliable financial and statistical reports may be prepared and accountability of the assets may be maintained. d. Programs are efficiently and effectively carried out in accordance with applica- ble law and management policy. 8. Required Agency Actions. Each agency shall meet the following requirements in a cost-effective manner. a. Maintain a current internal control directive assigning management responsibili- ty for internal controls in accordance with this circular and the [OMB] Internal Control Guidelines with the following provisions. Provide for coordination on in- ternal control matters among the designated internal control official, heads of agen- cy components, program managers and staffs, and the IG [Inspector General] of- fice or its equivalent. Establish administrative procedures to enforce the intended functioning of internal controls. . . . b. Develop a Management Control Plan (MCP) or plans to be updated annually. The primary purpose of an MCP is to identify component inventory, to show risk rating of component (high, medium, low), and to provide for necessary evaluations over a five-year period. Material weaknesses and other areas of management con- cern may also be monitored through the plan. High risk components and material weaknesses must be acted upon during the first year of the plan. The plan should be based upon the schedule of actions in each major component, and identify the senior managers responsible. Management should utilize the plan for monitoring progress and ensuring that planned actions are in fact taken. MCP's are intended to be part of each agency's overall planning process and at a minimum should be linked to activities under [OMB Circulars] A-127 and A-130. . . . c. Make risk assessments to identify potential risks in agency operations which re- quire corrective action or further investigation through internal control evaluations or other actions. These may follow the vulnerability assessment procedures in the [OMB] Internal Control Guidelines or may be based on a systematic review build- ing on management's knowledge, information obtained from management report- ing systems, previous risk assessments, audits, etc. . . . Risk assessment on new or substantially revised programs should occur as part of planning for implementation and the results reflected in the MCP. Risk assessments are to be considered as part of developing the MCP. d. Make internal control evaluations using the procedures in the [OMB] Internal Control Guidelines or alternative reviews to determine whether the internal control system is effective and is operating in compliance with the Integrity Act and this circular. These reviews should identify internal controls that need to be strength- ened or streamlined. The composite of all information that management relies upon to judge their systems effectiveness must include information on the results of tests of their operating internal control systems e. Implement corrective actions identified by agency internal control evaluation ef- forts on a timely basis. A formal follow-up system should be established that records and tracks recommendations and projected action dates, and monitors whether the changes are made as scheduled. The tracking systems should be made part of broader agency management reporting systems whenever feasible. A.9.1 Cross-References and Comments TABLE A-19. OMB Circular No. A-123-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance 4 X X X X X X 7(a) X X 7(b) X 7(c) X 8(a) X X X 8(b) X X X 8(c) X X 8(d) X X 8(e) X X 4 [Security Policy, MAC, DAC, Marking] An internal control system shall protect against fraud, waste, mismanagement, and misappropriation. Implementation of internal control systems must be in accordance with GAO standards. Efficient and effective management of program activities implies the implementation of abstractions to bind users with ac- tions (roles) and actions with appropriate object types (duties). This implies both sys- tems and application-specific security policies. [Accountability, Assurance] Program and administrative activities must be effective and efficient. Reasonable assurance is required. 7(a) [Security Policy] Applicable laws related to obligations and costs must be addressed. [Accountability] Obligations and costs must be adequately recorded and reported. 7(b) [Security Policy] AIS resources which represent program assets must be safeguarded against waste, loss, unauthorized use, and misappropriation. 7(c) [Accountability] Operational revenue and expenditures must be recorded and reported. 8(a) [Security Policy] Each agency shall maintain a current directive which implements inter- nal control policy in accordance with this Circular and OMB guidelines. [Accountabili- ty] Coordination with other entities is required. [Assurance] Administrative procedures to enforce internal controls must be established. The implication that some of these pro- cedures may be implemented (either partially or totally) within AISs requires that all pro- cedures should be well-documented and that agency personnel must be trained properly to carry them out. 8(b) [Security Policy, Accountability] Development and maintenance of a Management Con- trol Plan is required. Component inventories must be established. Monitoring of weak- nesses implies features for tracking and reporting. [Assurance] Evaluation and risk rat- ing of internal controls is required. 8(c) [Accountability, Assurance] Risk assessments for agency operations is required. Risk as- sessments may require follow-on, corrective actions. 8(d) [Accountability] This implies that responsibilities for internal control systems have been established and that the responsible individuals shall be held accountable for the proper functioning of those systems. [Assurance] Internal control evaluations are required. Iden- tification of weaknesses is required. Results of tests must be relied upon for manage- ment to judge systems' effectiveness. 8(e) [Accountability, Assurance] Corrective actions must be implemented on a timely basis. Recording and monitoring of identified corrective actions is required. A.10 OMB Bulletin No. 90-08-Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information This Bulletin provides guidance for computer security planning activities required under the Computer Security Act of 1987. The Bulletin does not apply to systems that contain classified information, systems involving intelligence activities, cryptologic activities related to national security, or direct command and control of military forces. The Bulletin also does not apply to equipment that (a) is integral to a weapons system, (b) is used in the direct fulfillment of military or intelligence missions, or (c) to mixed classified and unclassified systems, if such systems are always operated under rules for protecting classified information. Computer security planning is intended to improve protection of information and other information processing resources. In order to be adequate for the protection of resources, computer security plans must address the areas of loss, misuse, unauthorized access or modification, unavailability, and undetected activities. The controls to be addressed by computer security planning described in this Bulletin address both major applications and general support systems. These controls are derived from requirements and guidance in the Computer Security Act of 1987, OMB Circular No. A-130, and applicable Federal Information Processing Standards (FIPS) and Special Publications produced by NIST. The following table contains selected sections of OMB Bulletin No. 90-08. The cross- reference table and comments appear in the next section. TABLE A-20. OMB Bulletin No. 90-08-Selected Source Text 1. Purpose. The purpose of this Bulletin is to provide guidance to Federal agencies on computer security planning activities required by the Computer Security Act of 1987. This Bulletin supersedes OMB Bulletin No. 88-18, Guidance for Preparation and Sub- mission of Security Plans for Federal Computer Systems Containing Sensitive Informa- tion (July 6, 1988). 3. Objectives of the Security Planning Process. The security planning process is de- signed to reduce the risk and magnitude of harm that could result from the loss, misuses or unauthorized access to or modification of information in Federal computer systems. . . . 6. Action Required. a. Every agency must implement security plans for systems which contain sensi- tive information, incorporating appropriate advice and comment from NIST/NSA. b. Every agency must prepare a new computer security plan for each system that contains sensitive information, if: (1) the system is new or significantly modified; or (2) a plan for the system was not previously sent to NIST/NSA for advice and comment (particular emphasis should be on contractor, State, and local systems operated on behalf of the agency to perform a Federal function); or (3) staff members of NIST/NSA advised the agency they were unable to pro- vide advice and comment on the previous plan for the system. c. Every agency must establish a process to ensure that independent advice and comment on each plan developed in accordance with Section 6.b, above, is provid- ed. Such advice and comment should be provided prior to developing a new sys- tem or significantly modifying an existing system. d. Every agency must ensure that security plans incorporate appropriate internal control corrective actions identified pursuant to OMB Circular No. A-123. e. Every agency must prepare materials as described in Section 8, meet with OMB, NIST, and NSA staff as described in Section 7, and work with NIST and NSA to improve agency computer security. 7. Assistance Visits. a. Agencies will be scheduled for visits by OMB, NIST, and NSA staff. b. Among the items to be discussed will be: (1) The completeness of identification of sensitive computer systems; (2) The quality, scope, and thoroughness of security plans; (3) Any internal control weaknesses identified pursuant to OMB Circular No. A-123 related to computer systems, and plans for addressing those weak- nesses; (4) For agencies subject to OMB Bulletin No. 89-17, ``Federal Information Systems and Technology Planning'' their response to that Bulletin; (5) Material available in accordance with Section 8, below. c. Agencies should also be prepared to discuss the approach that is being taken to ensure that computer security plans for new or modified computer systems are pre- pared and reviewed. 8. Material for Meetings. Agencies should, at a minimum, have the following informa- tion available: a. agency-wide computer security policies and a summary of agency computer se- curity procedures, standards, and requirements; b. agency assignment of responsibilities for implementation and operation of the security program; c. the agency management plan for ensuring implementation of system computer security plans that includes a description of: (1) the involvement of agency management, (2) how computer security plans are being integrated into information re- sources management plans, (3) the approach for ensuring that funds, personnel and equipment are planned for and budgeted, and (4) the implementation schedule; d. the method used to identify the agency's sensitive systems; e. any know agency needs for guidance or assistance. Appendix A-Instructions for Preparing System Security Plans I. System Identification This section of the plan contains basic identifying information about the system. C. System Category - Categorize each system as either a major application, or as a general support system, in line with the primary management responsibility for the system. Major application. These are systems that perform clearly defined functions for which there are readily identifiable security considerations and needs. Such a system might actually comprise many individual application pro- grams and hardware, software, and telecommunications components. General support system. These consist of hardware and software that provide general ADP or network support for a variety of users and applications. Indi- vidual applications may be less easily distinguishable than in the previous category, but such applications may contain sensitive information. Even if none of the individual applications are sensitive, however, the support sys- tem itself may be considered sensitive if overall, the aggregate of applica- tions and support provided are critical to the mission of the agency. II. Sensitivity of Information Handled This section should provide a description of the types of information handled by the sys- tem and thus provide the basis for the system's security requirements. It should contain the following information: A. Applicable Laws or Regulations Affecting the System . . . B. General Description of Information Sensitivity - The purpose of this section is to indicate the type and relative importance of protection needed for the identified system. A system may need protection for one or more of the following reasons: Confidentiality - The system contains information that requires protection from unauthorized disclosure. Examples: timed dissemination (e.g., crop re- port data), personal data (covered by Privacy Act), proprietary business infor- mation. Integrity - The system contains information which must be protected from au- thorized, unanticipated or unintentional modification, including the detection of such activities. Examples: systems critical to safety or life support, finan- cial transaction systems. Availability - The system contains information or provides services which must be available on a timely basis to meet mission requirements or to avoid substantial losses. Examples: air traffic control, economic indicators, or hurri- cane forecasting. III. System Security Measures C. Security Control Measures - Two sets of controls are discussed on subsequent pages - one for Major Applications and the other for General Support Systems . . . E. Security Controls Measures for Major Applications 1. Management Controls - overall management controls of the application system. a. Assignment of Security Responsibility - Responsibility for the securi- ty of the application should be assigned. b. Personnel Screening - Personnel security policies and procedures should be in place and working to limit access to and processing with- in the application system to those with a need for such access. Where appropriate, the duties of those with access should be separated. Addi- tionally, requirements such as screening individuals with access to the application as well as those participating in the design, development, operation, or maintenance of it may be used. 2. Development/Implementation Controls - procedures to assure protection is built into the system, especially during system development. a. Security Specification - Appropriate technical, administrative, physi- cal, and personnel security requirements should be specified for the ap- plication. . . . b. Design Review and Testing . . . c. Certification - Prior to the application being put into operation, and agency official should certify that the application meets all applicable Federal policies, regulations, and standards, and that the protection measures appear adequate. . . . 3. Operational Controls - day-to-day procedures and mechanisms to protect operational application systems (or planned applications when they become operational). . . . a. Physical & Environmental Protection . . . b. Production, I/O Controls - Controls over the proper handling, processing, storage, and disposal of input and output data and media, as well as access controls (such as labeling and distribution proce- dures) on the data and media. . . . c. Emergency, Backup, and Contingency Planning . . . d. Audit and Variance Detection - Controls which allow management to conduct an independent review or records and activities to test the adequacy of controls, and to detect and react to departures from estab- lished policies, rules, and procedures. Variance detection for an applica- tion checks for anomalies in such things as the numbers and types of transactions, volume and dollar thresholds, and other deviations from standard activity profiles. e. Application Software Maintenance Controls - Controls used to moni- tor the installation of the updates to application software to ensure that the software functions as expected and that an historical record is main- tained of application system changes. Such controls also help to ensure that only authorized software is allowed on the systems. These controls may include software configuration policy that grants managerial ap- proval to modifications, then documents the changes. They may also in- clude some products used for ``virus'' protection. f. Documentation . . . 4. Security Awareness and Training . . . 5. Technical Controls - hardware and software controls used to provide auto- mated and/or facilitate manual protection. Normally these types of controls are coordinated with the network and/or data center manager. a. User Identification and Authentication - Controls used to identify or verify the eligibility of a station, originator, or individual to access spe- cific categories of information, to perform an activity, or to verify the integrity of data that have been stored, transmitted, or otherwise ex- posed to possible unauthorized modification. Such controls include the use of passwords, tokens, biometrics or other personal mechanisms to authenticate identity. b. Authorization/Access Controls - Hardware or software features that are designed to permit only authorized access to or within the applica- tion, to restrict users to authorized transactions and functions, and/or to detect unauthorized activities (e.g., access control lists). c. Data Integrity/Validation Controls - Controls used to protect data from accidental or malicious alteration or destruction, and provide as- surance to the user that the data meets an expectation about its quality (e.g., [electronic funds transfer] EFT message authentication). Valida- tion controls refer to tests and evaluations used to determine compli- ance with security specification and requirements. d. Audit Trails and Journaling - Controls that provide a transaction monitoring capability with a chronological record of application activi- ties. This enables reconstruction of a transaction from its inception to final results-including any modification of files. F. Security Controls Measures for General Support Systems 1. Management Controls - overall management controls of the general sup- port system. a. Assignment of Security Responsibility . . . b. Risk analysis . . . c. Personnel Screening - Personnel security policies and procedures should be in place and working to control access to and within the sup- port system to assure that only those with a need for access have it. Such policies and procedures may include requirements for screening individuals involved in the operation, management, security, design, programming, or maintenance of the system. 2. Acquisition/Development/Installation Controls - procedures to assure that protection is built into the system. a. Acquisition Specifications - Appropriate technical, administrative, physical, and personnel security requirements are to be included in specifications for the acquisition or operation of information technolo- gy installations, equipment, software, and related services. b. Accreditation/Certification . . . 3. Operational Controls - day-to-day procedures and mechanisms to protect operational systems. a. Physical & Environmental Protection . . . b. Production, I/O Controls - Controls over the handling, processing, storage, and disposal of input and output from the support system (e.g., controlled or locked output boxes, tape or data screening, etc.). c. Emergency, Backup, and Contingency Planning . . . d. Audit and Variance Detection . . . e. Hardware and System Software Maintenance Controls . . . f. Documentation . . . 4. Security Awareness and Training . . . 5. Technical Controls - hardware and software controls to protect the general support systems from unauthorized access or misuse, to facilitate detection of security violations, and to support security requirements for associated ap- plications. a. User Identification and Authentication - Controls used to verify the identity of a station, originator, or individual prior to allowing access to the system, or specific categories of information within the system. . . . b. Authorization/Access Controls - Hardware or software features used to detect and/or permit only authorized access to or within the system (e.g., the use of access lists). Includes controls to restrict access to the operating system, limits on access to programming resources, and con- trols to support security policies of associated applications. c. Integrity Controls - Controls used to protect the operating system, ap- plications and information in the system from accidental or malicious alteration or destruction, and provide assurance to users that data has not been altered (e.g., message authentication). . . . d. Audit Trail Mechanisms . . . e. Confidentiality Controls . . . A.10.1 Cross-References and Comments TABLE A-21. OMB Bulletin No. 90-08-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance App.A(I)(C) X App.A(II)(A-B) X App.A(III)(E)(1-5) X X X X X X X App.A(III)(F)(1-5) X X X X X X X App.A(I)(C) [Security Policy] In general, any particular AIS may provide (partial or total) automa- tion of a major application while at the same time serving as a general support system. For example, a logistics DBMS [data base management system] might be considered to be a major application, and hence represents the automation of a major service provided by a component. At the same time, the AIS(s) on which the DBMS resides may provide various applications which support the functioning of that component itself, such as a payroll or other management system. At a minimum, the operation system of AIS can be considered as providing general support. Thus, such an AIS would be called upon to support (possibly) diverse protection policies. The Security Policy must represent an inte- gration of protection policies associated with both the major applications and the general support systems provided by the AIS. App.A (II)(A-B) [Security Policy] The general scope of the type of information to be protected under sys- tem security policies is defined. The availability are explicitly included. Other control ob- jectives are affected by these concerns. Notably, fault tolerance and assurance for safety- critical systems are implied. App.A (III)(E)(1-5) [Security Policy, MAC, DAC, Marking, Accountability, Assurance, Fault Tolerance] This section outlines a variety of computer security controls (e.g., management, develop- ment, operational, and technical) which apply to major application subsystems. In gener- al, control systems extend beyond the boundaries of automated systems. However, in many cases, support for or enforcement of necessary controls can be generalized and in- tegrated into an AIS via automated mechanisms. Significantly, these controls are analo- gous to those traditionally associated with, and provided by, operating systems-yet con- trol requirements may be unique on an application-by-application basis. This may imply an increased functionality over current AIS security kernel designs to allow for the en- forcement of multiple, independent security policies. All control objectives are affected. App.A (III)(F)(1-5) [Security Policy, MAC, DAC, Marking, Accountability, Assurance, Fault Tolerance] This section outlines a variety of computer security controls which are associated with the traditional notion of a system. These controls essentially apply to the enforcement of a system-wide security policy. However, under the Computer Security Act of 1987, sen- sitive information must now be taken into account. Also, the requirements associated with major applications must also be incorporated. Hence, all control objectives are af- fected. A.11 [OMB] Internal Control Guidelines The Federal Managers' Financial Integrity Act requires sets forth requirements for internal accounting and administrative controls within Executive agencies, and requires that OMB establish-in consultation with the Comptroller General of the United States- guidelines for the evaluation of these controls. This document embodies the guidelines required to be developed by OMB under this Act. The following table contains selected sections of the Guidelines. The cross-reference table and comments appear in the next section. Some of the numbering below does not occur in the original source text-it is included to aid in the clarity of cross-referenced comments. Because of the comprehensive nature of these guidelines, only brief examples related to AIS security will be highlighted and commented upon. The Guidelines should be consulted for required details. TABLE A-22. [OMB] Internal Control Guidelines-Selected Source Text Chapter IV - Vulnerability Assessments Analysis of General Control Environment Several factors determine the general control environment, including the following . . . : · ADP [Automated Data Processing] Consideration - When utilized, an awareness of the strengths and exposures inherent in a system that uses ADP and the existence of appropriate controls. . . . Chapter V - Internal Control Reviews Identification of the Event Cycles Event cycles are the processes used to initiate and perform related activities, create the necessary documentation, and gather and report related data. In other words, an event cy- cle is a series of steps taken to get something done. Each program and administrative function performed within an agency or agency component contains one or more event cycles. For example, an entitlement program could contain the following event cycles: information gathering and verification, eligibility determination, information processing and record keeping, payment, and monitoring. The event cycles for an administrative function could include payroll, procurement of supplies and materials, correspondence handling, etc. (Appendices B and B-1 present event cycles commonly found in Federal Government agencies. The General Accounting Office, professional associations, and pri- vate organizations also publish lists of common event cycles). . . . Evaluation of the Internal Controls within the Event Cycle . . . The manner in which this is done is to: · Ascertain the control objective for the event cycle. . . · Examine the documentation and ascertain whether appropriate internal control tech- niques are in place to enable the control objective to be met in an efficient and ef- fective manner. Internal control techniques are the processes or documents that en- able the control objective to be achieved. . . . · Identify whether there are any internal control techniques that are excessive, . . . Glossary Assessable Unit - A program or administrative function or subdivision thereof which is to be the subject of a vulnerability assessment. Control Objective - A desired goal or condition for a specific event cycle that re- flects the application of the overall objectives of internal control to that specific cy- cle. Event Cycle - The processes used to initiate and perform related activities, create the necessary documentation, and gather and report related data. Inherent Risk - The inherent potential for waste, loss, unauthorized use, or misap- propriation due to the nature of an activity itself. Internal Control - The steps that an agency takes to provide reasonable assurance that obligations and costs are in compliance with applicable law; funds, property, and other assets are safeguarded against waste, loss, unauthorized use, or misappro- priation; and revenues and expenditures applicable to agency operations are proper- ly recorded and accounted for to permit the preparation of accounts and reliable fi- nancial and statistical reports and to maintain accountability over the assets. Internal Control System - The sum of the organization's methods and measures used to achieve the objectives of internal control. Internal Control Technique - A process or document that is being relied on to effi- ciently and effectively accomplish a control objective and thus help safeguard an activity from waste, loss, unauthorized use, or misappropriation. Appendix B - Common Event Cycles and Suggested Control Objectives in Federal Agen- cies This appendix presents a list of event cycles commonly found in Federal agencies and agency components. Also included are certain types of assets that are highly susceptible to loss and for which controls are vital, e.g., cash, materials and supplies. Finally, the list provides suggested control objectives for each event cycle/type of asset. . . . [In addition to the AIS-specific event cycle examples listed below, other common event cycles address such areas as Operations, Internal Management and Administration, and Assets and Liabilities. We have included source text dealing with Information Process- ing and Reporting because these event cycles are directly related to all aspects of auto- mated processing. However, in general, many of the other common event cycles and sug- gested control objectives cited in this section will need to be considered in formulating AIS Security Policy.] III. Information Processing and Reporting Cycles A. Information Collection The primary internal control objectives normally associated with information collection are the following: (1) Information collected is meaningful and useful. (2) Information collected is reliable. (3) Information is arranged in an orderly fashion. (4) Information is maintained on a current basis. B. Records Maintenance The primary internal control objectives normally associated with records maintenance are the following: (1) Records are readily available. (2) Records are adequately protected. (3) Only necessary records are retained. C. Automatic Data Processing The primary internal control objectives normally associated with automatic data processing are the following: (1) Proper authorization of transaction inputs, adequate edit checks, and nec- essary safeguards of sensitive input forms to insure accurate, proper, com- plete and timely entry of information. (2) Data is safeguarded to prevent unauthorized access, improper changes, or loss. (3) Appropriate controls exist to detect unauthorized use of the system. (4) Outputs produced accurately, completely and timely. A.11.1 Cross-References and Comments TABLE A-23. [OMB] Internal Control Guidelines-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance Chapter V X App.B(III)(A)(1-4) X X App.B(III)(B)(1-3) X X X App.B(III)(C)(1-4) X Chapter V [Security Policy] The protection requirements of each event cycle in the internal control environment shall be specified, and such specifications shall be generally reflected in the overall Security Policy. App.B (III)(A)(1-4) [Accountability] Collected information must be maintained on a current basis and ar- ranged in an orderly fashion. [Assurance] Collected information must be meaningful, useful, and reliable. App.B (III)(B)(1-3) [Security Policy] Only necessary records can be retained. Records must be available and adequately protected. [Accountability] Each Agency shall establish responsibilities for record administration. The accountable individuals shall ensure that records acquisition, maintenance, and disposition conform to applicable laws and policy. [Assurance] Period- ic review of records administration shall be conducted. App.B(III)(C) [Security Policy] An outline of internal control objectives normally associated with auto- mated systems is presented. These internal control objectives should be reflected in each Agency and should be enforceable through Security Policy implementation mechanisms. A.12 GAO Policy and Procedures Manual for Guidance of Federal Agen- cies-Title 2 - Accounting The Federal Managers' Financial Integrity Act requires sets forth requirements for internal accounting and administrative controls within Executive agencies, and requires that OMB establish-in consultation with the Comptroller General of the GAO-guidelines for the evaluation of these controls. This document embodies the GAO guidelines and standards required under this Act. The following table contains selected sections of the Manual. The cross-reference table and comments appear in the next section. Some of the numbering below does not occur in the original source text-it is included to aid in the clarity of cross-referenced comments. Because of the comprehensive nature of these guidelines, only brief examples related to AIS security will be highlighted and commented upon. The Manual should be consulted for required details. TABLE A-24. GAO Policy and Procedures Manual, Title 2 - Accounting-Selected Source Text Appendix II-[Comptroller General's] Standards for Internal Control in the Federal Gov- ernment The internal control standards define the minimum level of quality acceptable for inter- nal control systems in operation and constitute the criteria against which systems are to be evaluated. These internal control standards apply to all operations and administrative functions but are not intended to limit or interfere with duly granted authority related to development of legislation, rule-making, or other discretionary policy-making in an agen- cy. A. General Standards 1. Reasonable Assurance. Internal control systems are to provide reasonable assur- ance that the objectives of the systems will be accomplished. 2. Supportive Attitude. Managers and employees are to maintain and demonstrate a positive and supportive attitude toward internal controls at all times. 3. Competent Personnel. Managers and employees are to have personal and profes- sional integrity and are to maintain a level of competence that allows them to ac- complish their assigned duties, as well as understand the importance of developing and implementing good internal controls. 4. Control Objectives. Internal controls objectives are to be identified or developed for each agency activity and are to be logical, applicable, and reasonably complete. 5. Control Techniques. Internal control techniques are to be effective and efficient in accomplishing their internal control objectives. B. Specific Standards 1. Documentation. Internal control systems and all transactions and other signifi- cant events are to be clearly documented, and the documentation is to be readily available for examination. 2. Recording of Transactions and Events. Transactions and other significant events are to be promptly recorded and properly classified. 3. Execution of Transactions and Events. Transactions and other significant events are to be authorized and executed only by persons acting within the scope of their authority. 4. Separation of Duties. Key duties and responsibilities in authorizing, processing, recording, and reviewing transactions should be separated among individuals. 5. Supervision. Qualified and continuous supervision is to be provided to ensure that internal control objectives are achieved. 6. Access to and Accountability for Resources. Access to resources and records is to be limited to authorized individuals, and accountability for the custody and use of resources is to be assigned and maintained. Periodic comparison shall be made of the resources with the recorded accountability to determine whether the two agree. The frequency of the comparison shall be a function of the vulnerability of the asset. C. Audit Resolution Standard Prompt Resolution of Audit Findings. Managers are to (1) promptly evaluate findings and recommendations reported by auditors, (2) determine proper actions in response to audit findings and recommen- dations, and (3) complete, within established time frames, all actions that correct or otherwise resolve the matters brought to management's attention. D. Explanation of General Standards 4. Control Objectives This standard requires that objectives be tailored to an agency's operations. All operations of an agency can generally be grouped into one or more cate- gories called cycles. Cycles comprise all specific activities (such as identify- ing, classifying, recording, and reporting information) required to process a particular transaction or event. . . . Agency management cycles cover the overall policy and planning, organization, data processing, and audit func- tions. . . . 5. Control Techniques Internal control techniques are the mechanisms by which control objectives are achieved. Techniques include, but are not limited to, such things as spe- cific policies, procedures, plans of organization (including separation of du- ties), and physical arrangements (such as locks and fire alarms). This stand- ard requires that internal control techniques continually provide a high de- gree of assurance that the internal control objectives are being achieved. . . . E. Explanation of Specific Standards 1. Documentation This standard requires written evidence of (1) an agency's internal control ob- jectives and techniques and accountability systems and (2) all pertinent as- pects of transactions and other significant events of an agency. Also, the doc- umentation must be available as well as easily accessible for examination. . . 2. Recording of Transactions and Events Transactions must be promptly recorded if pertinent information is to main- tain its relevance and value to management in controlling operations and making decisions. This standard applies to (1) the entire process or life cycle of a transaction or event and includes the initiation and authorization, (2) all aspects of the transaction while in process, and (3) its final classification in summary records. Proper classification of transactions and events is the or- ganization and format of information on summary records from which re- ports are statements are prepared. 3. Execution of Transactions and Events This standard deals with management's decision to exchange, transfer, use, or commit resources for specified purpose under specific conditions. It is the principal means of assuring that only valid transactions and other events are entered into. Authorization should be clearly communicated to managers and employees and should include the specific conditions and terms under which authorizations are to be made. Conforming to the terms of an authorization means that employees are carrying out their assigned duties in accordance with directives and within the limitations established by management. 4. Separation of Duties To reduce the risk of error, waste, or wrongful acts or to reduce the risk of them going undetected, no one individual should control all key aspects of a transaction or event. Rather, duties and responsibilities should be assigned systematically to a number of individuals to ensure that effective checks and balances exits. Key duties include authorizing, approving, and recording transactions; issuing and receiving assets; making payments; and reviewing or auditing transactions. Collusion, however, can reduce or destroy the effec- tiveness of this internal control standard. 5. Supervision This standard requires supervisors to continuously review and approve the as- signed work of their staff. . . . 6. Access To and Accountability For Resources The basic concept behind restrict- ing access to resources is to help reduce the risk of unauthorized use, loss to the Government, and to help achieve the directives of management. However, restrict- ing access to resources depends upon the vulnerability of the resource and the per- ceived risk of loss, both of which should be periodically assessed. . . . Appendix III-Accounting System Standards A. Introduction . . . The standards contained in this appendix apply to all manual and/or automated systems of accounting and related internal controls that are operating or are under development or major revision, in all departments, agencies, or instrumentalities in the executive branch . . . B. Accounting System Structure and Operation . . . Within each department or agency, the account structure (general ledger and subsidiary accounts), definitions, and data elements must be standardized to ensure consistency, uniformity, and efficiency in accounting treatment, classification, and reporting. Furthermore, the procedures for capturing, classifying, communicating, processing, and storing data and transactions must be uniform (or translatable among the various subsystems or segments of the system, as necessary). . . . De- partment or agency accounting systems must include reasonable safeguards and controls to ensure data integrity and to protect against the loss of the system's abili- ty to function. . . . Agencies must periodically review their accounting systems to ensure that the system, along with its controls and security features, continues to perform as intended, meet user needs, and conform to applicable laws and account- ing standards. . . . 1. Structure of the Accounting System. . . . the systems must be structured in a way that ensures the proper gather- ing, recording, storing, processing, communicating, and consistent reporting [of information] . . . Accounting information is most useful when organized by project or pro- gram, responsibility center, activity, object class of expenditure, organization- al unit, appropriation, etc. Systems should be capable of responding to re- quirements for information along these various dimensions. . . . 2. Accounting Processing and Procedures a. Support for Transactions A fundamental requirement for any viable accounting system is that the financial transactions for which the system must account be ade- quately supported with pertinent documents and source records. These transactions, and any subsequent adjustments, should be authorized and executed in accordance with management criteria by personnel acting within the scope of their authority. . . . These transactions should be re- corded in the accounts promptly and accurately . . . Thus, information should be captured in the accounting records simultaneously with or immediately following the event that gave rise to the transaction. All transactions, including those which are computer-generated and computer-processed, must be referenced to individual source records. Referencing must be done in a manner that enables tracing or replicat- ing a transaction from its source to the resulting record or report, and from the resulting record or report to the source, or by tracing indirect- ly . . . In the case of computer-generated transactions, verification of amounts recorded or reported requires (a) reviews of systems documentation, such as edit routines and decision criteria in program listings, to gain an understanding of the events which generate transactions, and (b) ref- erence to master files, data base records, detailed listings of computer media work files, or input transactions which trigger the computer-gen- erated transactions. b. Reconciliation General ledger balances must be reconciled with subsidiary accounts and records, either manually or by the computer, in a timely manner. Regularly scheduled reconciliation . . . helps to substantiate and main- tain the accuracy of account postings and balances . . . c. Transaction Processing/Production Control Agency accounting systems, whether automated or manual, must con- tain internal controls which operate to prevent, detect, and correct er- rors and irregularities which may occur anywhere in the chain of events from transaction authorization to issuance of reports. The con- trols can be generally thought of as covering the functions of transac- tion authorization and approval, data preparation and validation, input, communications, processing, storage, output, error resolution and re-en- try of data, and file or data base quality maintenance. . . . In automated systems, controls are usually classified as ``general'' or ``application-specific'' controls. General controls are those that affect the agency's data processing operations across-the-board . . . Applica- tion-specific controls are those related to a particular activity or subsys- tem, such as requirements that payroll transactions can be entered only at certain terminals. Typically, application controls are considered in terms of input, processing, and output. Input controls should detect unauthorized, incomplete, duplicate, or otherwise erroneous transactions and ensure they are controlled until corrected. Processing controls should provide reasonable assurance that all transactions have been processed and that the application processing was correct, using correct file data, operator procedures, and process- ing logic. Output controls provide reasonable assurance that the output is complete, correct, and distributed only to authorized users. Closely related to controls over input, processing, and output are con- trols over data communication and data storage and retrieval. Data com- munication controls help ensure that the integrity and confidentiality of messages (data) transmitted by communication lines . . . are main- tained. In addition, data storage and retrieval controls help to ensure that the files are protected from loss, destruction, and unauthorized changes, and that only the correct and latest version of data and pro- gram files are used during processing. . . . While the particular procedures and records used to effect these con- trols are left to each agency, agency systems (whether automated or manual) should include internal controls, where appropriate, that pre- vent or detect the following kinds of situation: -- failure to record a transaction, -- incorrect or incomplete recording of a transaction, -- duplicate recording of a transaction, -- loss of a transaction document in handling, -- incorrect entry of data at a terminal, -- processing of unauthorized or incorrect data, -- directly changing account/master file/data base records without an authorized transaction, -- use of a superseded or test version of a program rather that the current production version, -- use of a wrong file or record in processing, -- unauthorized file maintenance transactions (which have a finan- cial impact), -- use of an incorrect value in internal tables, -- incorrect default value, -- input of incorrect program parameters, -- unauthorized use of programs which bypass normal program controls and edits, -- incorrect or incomplete processing logic, -- abnormal interruption of the application processing run, -- destruction of part or all of a file during processing, -- data base errors, -- out-of-balance conditions, and -- data errors caused during data transfer between interfacing sys- tems. Since most transactions . . . can be heavily automated . . . initial and periodic testing of the adequacy and accuracy of the transaction processing software is necessary . . . d. Error Handling Systems must provide procedures for control over errors to ensure that, once errors are detected, (1) corrections are made in a timely manner and re-entered into the appropriate processing cycle, (2) corrections are made only once, and (3) the correction itself is validated. The disposition of erroneous transactions depends on the type of trans- action, the data item in error, or other control considerations. The possi- bilities include (1) the entire transaction is rejected and returned to its originator for correction and re-submission, or (2) the transaction is held in a suspense file . . . Procedures should be established for periodi- cally analyzing reasons for errors and rejected transactions by type and source so that management may ensure that appropriate corrective ac- tion is taken. e. Control Over Output Output distribution should be controlled to ensure that only properly au- thorized personnel receive reports or other output. Prior to distribution, output should be checked for such things as completeness, agreement of control totals, proper labeling, and appropriate number of copies. If feasible, a cross-check with output from related programs should be done. . . . f. Verifying File Data The correctness or integrity of file data depends on the quality of the original file and the quality of subsequent processing affecting that file. Since data quality can deteriorate over time, systems should provide maintenance procedures to help ensure the continuing quality of files. Methods for maintaining file quality include the scanning of file con- tents by a computer program which reviews data items against criteria similar to those used during validation of input data. . . . g. System Security and Integrity To help ensure continued and authorized processing and protection of information, systems must include procedures and controls which pro- tect hardware, software, data, and documentation from physical dam- age . . . and from unauthorized access whether inadvertent or deliber- ate. . . . The integrity and confidentiality of the system's data and software must also be protected from accidental or malicious modification, de- struction, or unauthorized disclosure. . . . Therefore, controls over per- sonnel selection, placement, job rotation, and vacation requirements for critical or sensitive positions are important. In addition, the agency must ensure continuing availability of information processing by pro- viding backup, recovery, and retention procedures encompassing hard- ware, personnel, supplies, software, data, and vital documentation. . . . 3. Accounting System Maintenance Agency accounting systems are dynamic. They are subject to changing re- quirements throughout their useful lives due to changes in related technolo- gy, agency programs, funding, personnel, etc. Reaction to changing require- ments as well as the activities which carry out day-to-day operations can be termed system maintenance. Management should have sufficient involvement to ensure that despite such changes, the system's stability is maintained. Sta- bility of the system, in one context, exists when the computer software has been debugged and performs as intended. In a second context, it is main- tained when successful application of management policies and procedures for control of changes in application software, improved compilers, changes in hardware, and training . . . operate to protect against communication prob- lems, data entry failures, and user negligence. . . . Procedures for controlling changes should require rigorous analysis of re- quested changes. Formally approved and documented change procedures help to protect against fraudulent or otherwise unauthorized changes . . . 4. Accounting System Reviews and Evaluations Another consequence of the dynamic nature of accounting systems is the need for periodic reviews and tests of their operations. These are critical to ensure that the system and its controls and security features continue to meet user needs, perform as intended, and conform with applicable accounting standards. . . . Tests should be designed to disclose whether valid transactions are processed properly and whether the system rejects invalid transactions. The tests should cover the entire flow of transactions from initial authorization through processing, posting to the accounts, and reporting. . . . Agencies will need to exercise judgment in determining which tests would be appropriate for their systems. Also, agencies may adopt evaluation poli- cies which provide for more comprehensive evaluations on some cyclical ba- sis. . . . A.12.1 Cross-References and Comments TABLE A-25. GAO Policy and Procedures Manual, Title 2 - Accounting-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance II-A(1-5) X X X X X II-B(1-6) X X X X X X II-C X II-D(4-5) X X X X X II-E(1) X II-E(2) X II-E(3) X X X X II-E(4) X X X X II-E(5) X II-E(6) X X X X X X III-B X X X X X III-B(1) X III-B(2)(a) X X X III-B(2)(b) X X III-B(2)(c) X X X III-B(2)(d) X X X III-B(2)(e) X X X III-B(2)(f) X X X III-B(2)(g) X X X X III-B(3) X III-B(4) X II-A(1-5) [Security Policy] These general standards for internal control should be reflected in the security policy. In particular, specific control objectives are to be identified and enforc- ing control techniques are to be applied. Logical, applicable, and reasonably complete control objectives must be identified or developed. Internal control techniques are to be effective and efficient. [MAC, DAC, Marking] A key aspect of these standards is the re- quirement for competence in performing assigned duties. Personnel should be identified with levels of competence that reflect the expectations one has for their performance and accountability. This implies that system support must exist to provide separation of levels of competency. Implementation of the abstractions of ``roles'' and ``duties'' may suffice in providing such support. [Assurance] Internal controls are designed to provide assurance for the proper operations of the system. Reasonable assurance should be de- fined in terms of cost effectiveness. II-B(1-6) [Security Policy] These specific standards for internal control should be reflected in the security policy. In particular (a) the requirements for transaction or event-execution au- thorization, (b) controls to ensure that individuals are only acting within the scope of their authority, (c) separation of duties and responsibilities among individuals, and (d) the requirement for qualified and continuous supervision-should be incorporated into the security policy. [MAC, DAC, Marking] In order to separate the key duties and responsi- bilities of individuals, those duties must be identified and bound to objects upon which transactions can be authorized, processed, recorded, or reviewed. These identifying mark- ings should be sufficient to ensure the intent of separation is enforced. The implementa- tion of ``roles'' and ``duties'' via typing mechanisms may suffice in providing such sup- port. [Accountability] The recording of specified actions for which individuals are to be held accountable should be accomplished on a continuous basis. The recorded account shall be periodically reconciled and shall be compared to the external entities that the ac- count represents. The periodicity of such comparison shall be a function of the vulnera- bility of the external entities. [Assurance] Documentation of sensitive events is required to provide assurance that all such events have been identified, and to assure that proper controls exist and can be properly applied before, during, and/or after the execution of such events. II-C [Accountability] The need to evaluate audit data and act on the evaluation findings promptly is specified and the requirement to set time bounds on resolving audit issues is established. II-D(4-5) [Security Policy, MAC, DAC, Marking] An agency must be able to (a) identi- fy and group related activities into specific categories, and (b) specify control objectives for the (event) cycles characterized by those categories. Control techniques must be im- plemented to realize the control objectives. Implementation of the abstractions of ``roles'' and ``duties'' enable a system to group related activities and resources, and also provide support for policy enforcement. [Assurance] A high degree of assurance that control objectives are being met is required. II-E(1) [Assurance] The existence of sensitive information or sensitive applications must be de- termined and documented. Documentation is to be readily available. II-E(2) [Accountability] Transactions and other significant events must be promptly recorded and classified. II-E(3) [Security Policy, MAC, DAC, Marking] It is implied that system support must exist to provide separation of areas of authority. Implementation of the abstractions of ``roles'' and ``duties'' provides such support. II-E(4) [Security Policy, MAC, DAC, Marking] Key duties and responsibilities must be separat- ed among individuals. The systematic assignment of duties and responsibilities is re- quired. The implementation of the abstractions of ``roles'' and ``duties'' provides support for separating mechanisms for authorizing, processing, recording, and reviewing of trans- actions in a systematic manner. II-E(5) [Assurance] Qualified and continuous supervision is to be provided. II-E(6) [Security Policy, MAC, DAC, Marking] Access to resources is to be limited to author- ized individuals. Implementation of the abstractions of ``roles'' and ``duties'' provides support for constraining authorization as well as constraining access. [Accountability] Accountability for the custody and use of resources is to be assigned and maintained. [Assurance] Periodic verification of recorded accountability with reality must be made. III-B [Security Policy, MAC, DAC, Marking] Standardization of definitions and data elements is required. Implementation of the abstractions of ``roles'' and ``duties'' provides stand- ardization capabilities. Control procedures must be uniform. [Assurance] Reasonable safeguards and periodic reviews are required. III-B(1) [Assurance] Structure of the system must ensure proper and consistent controls are possi- ble. Implementation of the abstractions of ``roles'' and ``duties'' provides one approach to such structuring. III-B(2)(a) [Security Policy] Transactions should be authorized and executed in accordance with management criteria. Transactions should be recorded promptly and accurately. [Ac- countability, Assurance] Referencing and tracing requirements are outlined. These re- quirements imply that where automated transactions replace the source documents or ``safety paper,'' concepts such as digital signatures, non-repudiation, assured service, fault tolerance, error control, etc., must be considered. Verification of recorded values is required. III-B(2)(b) [Accountability, Assurance] Balances must be reconciled with subsidiary accounts and records. Accuracy must be substantiated and maintained. III-B(2)(c) [Security Policy] The requirement to address application-specific security policy con- cerns is cited. A large number of representative situations in which controls are required are cited. Preventive and/or detective controls are required for these situations. [Assur- ance, Fault Tolerance] Controls to ensure fault detection and/or fault tolerant input, processing, and output are required. Reasonable assurance that input, processing, and output events are adequately controlled is required. Reliable communication and reliable file storage are required. III-B(2)(d) [Security Policy] The security policy must address how transaction errors are to be han- dled. In particular, it must address whether errors abort the transaction completely or whether fault detective and/or fault tolerant mechanisms can or should be employed. Er- rors should be detected as close as possible or practicable to their injection into the sys- tem, and must be resolved in a timely manner. [Assurance, Fault Tolerance] Error correc- tion must take place only once and the correction itself must be validated. III-B(2)(e) [Security Policy] Output should be distributed only to authorized personnel. [Marking] Output media should be properly labeled to reflect sensitivity, distribution restrictions, copy numbers, etc. [Assurance] Verification of output is required, if feasible. III-B(2)(f) [Security Policy] Appropriate standards of quality must be specified against which quali- ty attributes of data can be assessed. Timing aspects with respect to data quality must be addressed in the security policy. For example, the frequency of updates, allowable lag time from input to processing, and the serialization of data and events must be ad- dressed. [Marking] Time sensitivities must be represented in the system as an attribute of data objects. [Assurance] Maintenance procedures to help ensure the continuing quali- ty of files is required. Conformance to quality standards must be ensured. This implies verification of internal values and attributes with external facts via periodic reviews and reconciliation. III-B(2)(g) [Security Policy, MAC, DAC, Marking] A system's data and software must be protected from accidental or malicious modification, destruction, and unauthorized disclosure. Con- trols over personnel and job assignment are required. Issues such as rotation of duties, authorization overrides, and temporary authorization must be considered. Implementa- tion of the abstractions of ``roles'' and ``duties'' provides support for such features. III-B(3) [Assurance] A well-disciplined configuration management and version control system is required. Procedures for controlling changes to systems require rigorous analysis and documented and formally-approved change procedures. III-B(4) [Assurance] Periodic reviews are required. These reviews are directed towards determin- ing whether a system and its controls and security features meet user needs, perform as intended, and conforms to standards. Functional testing of control features must extend to application subsystems. Control objective testability is implied. A.13 DoD Directive 5010.38-Internal Management Control Program This directive establishes the DoD program for Internal Management Control (IMC), incorporating guidance under 31 U.S.C. 3512 (also referred to as PL 97-255, Federal Managers' Financial Integrity Act of 1982); OMB Circular A-123 (Internal Control System); OMB Guidelines for the Evaluation and Improvement of and Reporting on Internal Control Systems in the Federal Government; and GAO Standards for Internal Control in the Federal Government. This Directive provides policy, prescribes procedures, and assigns responsibilities. DoD internal management control (IMC) is ``the plan of organization, methods, and procedures adopted by management to provide reasonable assurance that the objectives of [FMFIA 1982] are met'' [DoD 5010.38-D, Encl.2(7)]. IMC is intended to safeguard resources, assure the accuracy and reliability of information, assure adherence to applicable laws, regulations, and policies, and promote operational economy and efficiency. IMC systems are not separate from, but are integral to, systems used to operate programs and functions. As such, IMC within the DoD is equivalent to the more prevalent term ``internal controls.'' The following table contains selected sections of DoD Directive 5010.38. The cross- reference table and comments appear in the next section. TABLE A-26. DoD Directive 5010.38-Selected Source Text A. Re-issuance and Purpose 1. This Directive reissues [DoD 5010.38-D of July 16, 1984] to: a. Establish the DoD program for Internal Management Control (IMC). b. Incorporate guidance under references [FMFIA 1982], [OMB A-123], . . . , and [GAO 1983]. c. Provide policy, prescribe procedures, and assign responsibilities. D. Policy 1. Each DoD Component shall implement a comprehensive system for IMC that provides reasonable assurance that: a. Obligations and costs comply with applicable law. b. Assets are safeguarded against waste, loss, unauthorized use, and misap- propriation. c. Revenues and expenditures applicable to DoD operations are recorded and accounted for properly to permit the preparation of accounts and reliable fi- nancial and statistical reports, and to maintain accountability over the assets. d. Programs and administrative functions are efficiently and effectively car- ried out in accordance with applicable law and management policy. e. IMC systems emphasize prevention of waste, fraud mismanagement, and timely correction of specific weakness. Enclosure 2. Definitions 5. Event Cycle. A series of steps taken to get something done. Any program or function performed within an organization contains such processes used to start and perform related activities, create necessary documentation, and gather and re- port related data. 15. Material Weakness. Specific instances of noncompliance with the FMFIA of sufficient importance to be reported to the next higher level of management. Such weakness significantly impairs the fulfillment of a DoD Component's mission; de- prives the public of needed services; violates statutory of regulatory requirements; significantly weakens safeguards against fraud, waste, or mismanagement of funds, property. or other assets; or results in a conflict or interest. (See enclosure 4 for further information.) Enclosure 4. Guidance in Applying the Definition of Material Weakness B. Discussion of Material Weakness Definition . . . 1. A material weakness in DoD's system of internal management controls may be due to lack of an applicable control, or more frequently, inadequate compliance with existing controls. These controls deal with all program and administrative functions; they are not limited to financial or accounting mat- ters. . . . 2. In addition to the basic characteristics of a material weakness described in sections A. and B., above, the final determination to categorize an internal control weakness as material results from management judgment about the relative impact of the weakness. For example, scoring each of the following considerations as ``significant'' or ``insignificant'' might help a manager in de- termining whether the absence of or noncompliance with a control is a mate- rial weakness. a. Actual or potential loss or resources. b. Sensitivity of the resources involved. c. Magnitude of funds, property, or other resources involved. d. Frequency of actual and/or potential loss. e. Current or probable media interest (adverse publicity). f. Current or probable Congressional interest (adverse publicity). g. Unreliable information causing unsound management decisions. h. Diminished credibility or reputation of management. i. Impaired fulfillment of essential mission. j. Violation of statutory or regulatory requirements. k. Impact on information security. l. Deprived the public of needed Government services. A.13.1 Cross-References and Comments TABLE A-27. DoD Directive 5010.38-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance D(1)(a-e) X Encl.4(B)(1) X Encl.4(B)(2)(a-l) X D(1)(a-e) [Security Policy] Policies and guidance stipulated under [FMFIA 1982], [OMB A-123], and [GAO 1983, GAO Title 2, App.II] are promulgated to DoD components. Encl.4(B)(1) [Security Policy] This broadens the scope of controls to include all programs and admin- istrative functions. Encl.4(B)(2)(a-l) [Security Policy] All of these categories have some effect on the degree of integrity which needs to be provided by information systems which are directly involved with pri- mary functions, or support those functions. Some of these include ways in which the ``value'' of information can be determined in non-monetary ways. Material weakness, such as those cited, provide specific effects of system failure or non-compliance with policy. The controls implementing a policy should be examined for specific weaknesses that might be presented should a control failure occur in an event cycle. ``Material weak- ness'' was previously defined in Encl.2(15) of the Selected Source Text. A.14 DoD Directive 5200.28-Security Requirements for Automated Informa- tion Systems This Directive establishes uniform policy for protecting classified data that is stored, processed, used, communicated, displayed, or disseminated via AISs. In addition, this Directive provides for the application of access and distribution controls for classified data beyond those required by security classification. A stated objective of this Directive is to establish that the reliability, integrity, and operation of AISs are enhanced by the imposition of controls which satisfy classification requirements. Significantly, this Directive states that increased AIS reliability and integrity features are necessary for (a) the dependable enforcement of confidentiality policy for classified information, and (b) the prevention of unauthorized manipulation of computers and peripherals. The following table contains selected sections of DoD Directive 5200.28. The cross- reference table and comments appear in the next section. TABLE A-28. DoD Directive 5200.28-Selected Source Text D. Policy It is DoD policy that: 1. Classified information and sensitive unclassified information shall be safeguard- ed at all times while in AISs. Safeguards shall be applied so that such information is accessed only by authorized persons, is used only for its intended purpose, re- tains its content integrity, and is marked properly as required. When classified in- formation is involved, the information security requirements in [DoD 5200.1-R] shall be met. 2. Unclassified information while in AISs shall be safeguarded against tampering, loss, and destruction and shall be available when needed. . . . Suggested safe- guards for unclassified information are in OMB Circular No. A-130, and include applicable . . . controls. 3. The safeguarding of information and AIS resources (against sabotage, tamper- ing, denial of service, espionage, fraud, misappropriation, misuse, or release to un- authorized persons) shall be accomplished through the continuous employment of safeguards . . . . 4. The mix of safeguards selected . . . shall ensure the AIS meets the minimum re- quirements as set forth in enclosure 3 [see below]. . . . 5. Computer security features of commercially produced products and Government- developed or -derived products shall be evaluated (as requested) for designation as trusted computer products for inclusion on the Evaluated Products List (EPL). Evaluated products shall be designated as meeting security criteria maintained by the National Computer Security Center (NCSC) . . . described in DoD 5200.28- STD [TCSEC 1985]. Enclosure 3. Minimum Security Requirements A. Minimum Security Requirements. The following minimum requirements shall be met through automated or manual means in a cost-effective manner and integrated fashion: 1. Accountability.There shall be in place safeguards to ensure each person having access to an AIS may be held accountable for his or her actions on the AIS. There shall be an audit trail providing a documented history of AIS use. The audit trail shall be of sufficient detail to reconstruct events in determining the cause or magni- tude of compromise should a security violation or malfunction occur. To fulfill this requirement, the manual and/or automated audit trail shall document the fol- lowing: a. The identity of each person and device having access to the AIS. b. The time of the access. c. User activity sufficient to ensure user actions are controlled and open to scrutiny. d. Activities that might modify, bypass, or negate safeguards controlled by the AIS. e. Security relevant actions associated with periods processing or the chang- ing of security levels or categories of information. DAAs [Designated Approval Authorities] shall cause a review to be made of audit trails associated with the AIS(s) over which the DAAs have cognizance to determine an adequate retention period for the audit information. The deci- sion to require an audit trail of user access to a stand-alone, single-user AIS (e.g., personal computer (PC), memory typewriter, drafting machine) should be left to the discretion of the DAA. 2. Access. There shall be in place and access control policy for each AIS. It shall include features and/or procedures to enforce the access control policy of the infor- mation within the AIS. The identity of each user authorized access to the AIS shall be established positively before authorizing access. 3. Security Awareness and Training. There shall be in place a security training and awareness program with training for the security needs of all persons accessing the AIS. The program shall ensure that all persons responsible for the AIS and/or in- formation, therein, and all persons who access the AIS are aware of proper opera- tional and security-related procedures and risks. 4. Physical Controls. AIS hardware, software, and documentation, and all classi- fied and sensitive unclassified data handled by the AIS shall be protected to pre- vent unauthorized (intentional or unintentional) disclosure, destruction, or modifica- tion (i.e., data integrity shall be maintained). The level of control and protection shall be commensurate with the maximum sensitivity of the information and shall provide the most restrictive control measures required by the data to be handled. This includes having personnel, physical, administrative, and configuration con- trols. Additionally, protection against denial of service of AIS resources (e.g., hard- ware, software, firmware, and information) shall be consistent with the sensitivity of the information handled by the AIS. Unclassified hardware, software, or docu- mentation of an AIS shall be protected if access to such hardware, software, or documentation reveals classified information, or access provides information that may be used to eliminate, circumvent, or otherwise render ineffective the security safeguards for classified information. Software development and related activities (e.g., systems analysis) shall be controlled by physical controls (e.g., two-person control) and protected when it is determined that the software shall be used for handling classified or sensitive unclassified data. 5. Marking. Classified and sensitive unclassified output shall be marked to accu- rately reflect the sensitivity of the information. Requirements for security classifica- tion and applicable marking for classified information are set forth in [DoD 5200.1- R]. The marking may be automated (i.e., the AIS has a feature that produces the markings) or may be done manually. Automated markings on output must not be relied on to be accurate, unless the security features and assurances of the AIS meet the requirements for a minimum security class B1 as specified in DoD 5200.28-STD [TCSEC 1985]. If B1 is not met, but automated controls are used, all output shall be protected at the highest classification level of the information handled by the AIS until manually reviewed by an authorized person to ensure that the output was marked accurately with the classification and caveats. All me- dia (and containers) shall be marked and protected commensurate with the require- ments for the highest security classification level and most restrictive category of the information ever stored until the media are declassified (e.g., degaussed or erased) using a DoD-approved methodology set forth in the DoD AIS Security Manual [DoD 5200.28-M], on unless the information is declassified or downgrad- ed in accordance with [DoD 5200.1-R]. 6. Least Privilege. The AIS shall function so that each user has access to all of the information to which the user is entitled (by virtue of clearance, formal access ap- proval), but to no more. In the case of ``need-to-know'' for classified information, access must be essential for accomplishment of lawful and authorized Government purposes. 7. Data Continuity. Each file or data collection in the AIS shall have an identifia- ble source throughout its life cycle. Its accessibility, maintenance, movement, and disposition shall be governed by security clearance, formal access approval, and need-to-know. 8. Data Integrity. There shall be safeguards in place to detect and minimize inad- vertent modification or destruction of data, and detect and prevent malicious de- struction or modification of data. 9. Contingency Planning. Contingency plans shall be developed and tested in ac- cordance with OMB Circular No. A-130 [OMB A-130] to ensure that AIS security controls function reliably and, if not, that adequate backup functions are in place to ensure that security functions are maintained continuously during interrupted service. If data is modified or destroyed, procedures must be in place to recover. 10. Accreditation. Each AIS shall be accredited to operate in accordance with a DAA-approved set of security safeguards. 11. Risk Management. There should be in place a risk management program to de- termine how much protection is required, how much exists, and the most economi- cal way of providing the needed protection. A.14.1 Cross-References and Comments TABLE A-29. DoD Directive 5200.28-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance D(1) X X D(2) X X X D(3) X X X D(4) X X X X X D(5) X Encl.3(A)(1-11) X D(1) [Security Policy] Classified information must only be used for its intended purpose and must retain its content integrity. Hence, arbitrary operations outside the scope of an indi- vidual's authority on instances of classified data should not be allowed. [Marking] This further implies that the information must be identified in terms of state attributes which allow judgement to be made as to the retention of content integrity. D(2) [Security Policy] In general, unclassified information is to be considered an asset and should be protected from tampering, loss, and destruction. [Assurance, Fault Tolerance] Information shall be available when needed. D(3) [Security Policy] AIS resources, including classified and unclassified systems and infor- mation, must be protected from unauthorized modifications. The prevention of fraud im- plies that controls shall exist to limit actions of authorized users. [Assurance, Fault Toler- ance] Protection of systems and information must be continuous. D(4) [Security Policy] The minimum requirements for data integrity includes safeguards to de- tect and minimize erroneous modifications, and to detect and prevent malicious modifica- tions. A risk reduction policy is called for in minimizing possible damage. [MAC, DAC, Marking] Prevention of malicious modifications implies controls on authorization. [Ac- countability] The detection of erroneous and malicious modifications is called for. D(5) [Assurance] Trusted systems shall be used in the protection of information. Encl.3(A)(1-11) [Security Policy] The minimum security requirements for AISs are specified. A.15 DoD Directive 7740.1-DoD Information Resources Management Pro- gram This Directive implements the policies stated in Public Law 96-511, Paperwork Reduction Act of 1980 and establishes the DoD Information Resources Management (IRM) Program. IRM is defined as ``the policy, action, or procedure concerning information (both automated and non-automated) that management establishes to serve the overall current and future needs of the organization. IRM policy and procedures address such areas as availability, timeliness, accuracy, integrity, privacy, security, auditability, ownership, use, and cost-effectiveness of information'' [DoD 7740.1-D, Encl.2(3)]. A list of DoD policy issuances related to these functions is included in DoD Directive 7740.1 [Encl.1]. However, because this Directive was issued in 1983, some of these policy issuances are either dated or have been superseded. This Directive applies to DoD information management activities including such areas as information technology, data elements, information collection, privacy of records, information security, statistical activities, forms, reports, and records. The following table contains selected sections of DoD Directive 7740.1, used for cross- referencing the source material and the affected control objectives. The cross-reference table and comments appear in the next section. TABLE A-30. DoD Directive 7740.1-Selected Source Text A. Purpose This Directive: 1. Establishes the DoD Information Resources Management (IRM) Program to pro- mote coordinated and integrated information management functions and imple- ments [PRA 1980]. B. Applicability and Scope 2. Its provisions cover the information management activities of information tech- nology, data elements, information collection, privacy of records, information secu- rity, statistical activities, forms, reports, and records. . . . 3. Its provisions cover the management of information within the Department of Defense, as well as information provided to and received from government agen- cies and information received from the public. D. Policy It is the policy of the Department of Defense to implement IRM aggressively in ways that enhance mission performance through the effective, economic acquisi- tion and use of information. E. Procedures In achieving the above policy, it is necessary that efforts be directed toward proce- dures that are designed to: 1. Support DoD operations and decision making with information that sufficiently meets the need in terms of availability, accuracy, timeliness, and general quality. 2. Provide for the economic and effective acquisition of information resources em- phasizing maximum practicable competition and lowest total overall cost consist- ent with mission requirements. 3. Structure information systems in ways that encourage horizontal, as well as ver- tical, sharing of information within the Department of Defense, with other govern- ment agencies, and with allied nations, consistent with security and privacy require- ments. 4. Ensure that information planning becomes an integral part of the management process at all levels. 5. Require user responsibility and accountability in the development of effective in- formation systems. 6. Manage information, information technology, and information systems using a disciplined approach from inception through acquisition and use until discontinu- ance. 7. Use regular reviews and evaluations to identify opportunities for improvement, to increase the usefulness of information, to reduce the cost of information activi- ties, and, in general, to further DoD IRM Program goals and objectives. 8. Create a broad awareness of IRM concepts and practices and provide necessary training. 9. Organize and integrate information management functions to accomplish mis- sion goals. 10. Collect information that is non-duplicative and that supports essential needs in a cost-effective manner. 11. Establish and maintain effective working relationships within the Department of Defense and with Congress and the federal central management agencies, such as the Office of Management and Budget (OMB), the General Services Administra- tion (GSA), and the General Accounting Office, with respect to IRM matters. 12. Encourage users and information managers to plan effectively for the sustaina- bility and readiness of information resources in both peacetime and wartime condi- tions. A.15.1 Cross-References and Comments TABLE A-31. DoD Directive 7740.1-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance D X E(1) X X X X E(3) X X X X X E(5) X X E(6) X X E(7) X X E(8) X X E(10) X X E(12) X X D [Security Policy] Information acquisition and use must be effective, economic, and must serve to enhance mission performance. E(1) [Security Policy] Operations and decision making must be supported by information sys- tems. Requirements for information accuracy, timeliness, and quality imply the need to implement system features that control these attributes in accordance with specified poli- cy. [Marking] The control of these attributes may require marking of data objects to sup- port implementation. [Assurance] The effectiveness of the control features in maintain- ing these attributes within specifications shall be assessed. [Fault Tolerance] The require- ment for information availability implies fault tolerant features. E(3) [Security Policy] The Security Policy must address the horizontal and vertical sharing of information. [MAC, DAC] The requirement for both vertical and horizontal sharing of information implies the need for access control features. The simultaneous sharing of in- formation between vertical and horizontal DoD components may require a more rigor- ous specification of authorization, as is represented by the abstractions of ``roles'' and ``duties.'' [Marking] The establishment of information sharing agreements must include confirmation that the receiving DoD component can mark and protect the shared infor- mation as required by the providing component. If such protection is not possible, then the providing component must determine the need to desensitize the information to the degree commensurate with the maximum protection capabilities of the receiving compo- nent prior to actual sharing. [Accountability] The receiving component should be ac- countable for the protection of any shared information it receives. The providing compo- nent is accountable for the sharing of sensitive information for which the receiving com- ponent does not have the capabilities to protect. E(5) [Security Policy] Information systems which are developed by DoD components must be effective relative to specific mission requirements. [Accountability] Individuals in- volved in the development (and maintenance) of information systems are to be held ac- countable for the effectiveness of those systems. E(6) [Security Policy] Systems, information technology, and information must be managed with discipline throughout their respective life cycles. [Assurance] Measures must be im- plemented to assure that proper controls exist throughout the life cycle of all informa- tion resources. E(7) [Security Policy, Assurance] Continuous improvement in information life cycle manage- ment is required. Review and evaluation processes must be integrated into life cycle management to enable the identification of improvement opportunities. Review and eval- uation processes are essential to ensure that overall goals and objectives associated with information systems are being met. E(8) [Security Policy] Security training must be integrated into information life cycle manage- ment. [Assurance] Training is an essential assurance measure. E(10) [Security Policy] Specific component policies regarding information sharing and elimina- tion of duplication should be established. [Assurance] Cost effectiveness can only be de- termined by weighing the benefits of sharing data against the associated risks and the costs incurred in countering those risks. This implies that a thorough risk analysis must be performed. E(12) [Security Policy] Plans for the sustainability and readiness of information resources are required. [Assurance] Contingencies should not only be planned for but also routinely exercised whenever practicable. A.16 DoD 7740.1-G-DoD ADP Internal Control Guideline This Guideline incorporates the provisions of the Federal Managers' Financial Integrity Act and OMB Circulars A-123, A-127, and A-130, and provides guidance on implementing DoD Directives 5010.38, 7740.1, and 5200.28. It incorporates the ``Model Framework for Management Control over Automated Information Systems,'' developed by the President's Council on Management Improvement and the President's Council on Integrity and Efficiency. This document provides guidance for implementing an AIS internal control program and is issued under the authority of DoD Directive 7740.1, DoD Information Resources Management Program. The Guideline [DoD 7740.1-G, p. 1-4] provides the following definition of AIS internal control for the Department of Defense: The steps taken within each DoD program and administrative function consisting of the plan of organization and all of the methods and techniques used to safeguard AIS re- sources 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. The Guideline provides general guidance which can be tailored to meet the specific requirements under the Internal Management Control Program, a mandatory program for all DoD Components. However, compliance to the program under this Guideline must be comprehensive, addressing all relevant sections. This document is intended to (1) assist managers, users, and developers in conducting risk assessments, (2) provide a framework for management control efforts, and (3) serve as a reference for AIS control techniques. Table 3.1 of the Guideline contains a set of 55 system control requirements cross-referenced with the most important of the policy documents. This table is reproduced in Appendix B of this document. The following table contains selected sections of the Guideline. Because of its comprehensive nature, only a small portion of the Guideline is included. The Guideline should be consulted for required details. The cross-reference table and comments appear in the next section. TABLE A-32. DoD Guideline 7740.1-G-Selected Source Text Chapter 1 Introduction A. Background 1. The Department of Defense (DoD) depends increasingly on automated informa- tion systems (AISs). . . . These systems are vulnerable to fraud, waste, and abuse. A few examples include: · unauthorized access and disclosure of classified, privacy, and proprietary records and/or data, · diversion of payments to unauthorized parties, · use of computers for personal matters, and · disruption and loss of computerized records and/or transactions. D. Objectives of the Guideline There are six (6) basic objectives: 1. Assist AIS managers and users in understanding their responsibilities and re- quirements to develop AIS internal management controls as required by OMB Cir- cular A-123 and by the current DoD Directive 5010.38, DoD Directive 7740.1, and DoD Directive 5200.28 . . . 2. Provide a vehicle for the education and training of managers so they may have a working understanding of AIS internal management controls. 3. Notify components of a requirement for a 5-year Management Control Plan (MCP) to be developed annually. 4. Delineate responsibilities for managers in either monitoring large AIS systems and assets or conducting internal control reviews and alternative review, such as in- ternal audits, inspections, investigations, studies, and computer security reviews. 5. Help to ensure that internal controls receive appropriate attention, emphasis, and resources in the automated information system life cycle, to include development, modification, operation and records management concerns. 6. Show managers how to protect their operations by providing AIS internal con- trol techniques and procedures for conducting risk assessments. Chapter 2 - System Controls Conceptual Framework A. Introduction 1. This chapter presents a conceptual framework for instituting and maintaining in- formation system controls. The control framework consists of three elements: a. Control requirements - the terms used to explain why controls are needed and/or what their implementation is expected to achieve. b. Selection and use of control techniques - the definition, selection, and use of control techniques to satisfy the requirements specified. c. Areas of control - the terms used to describe how and where control tech- niques are applied to satisfy basic control requirements. 3. Most control-related activities have traditionally centered on internal control re- views, risk assessments, and audits of existing automated systems and processes. While these types of review are needed, they do not necessarily ensure that ade- quate management controls are built into current and future systems. . . . 4. Fundamentally, automated information systems are developed to support manag- ers to effectively fulfill their responsibilities. In the Federal Government, automat- ed information systems perform a wide range of functions that include: making benefit payments; collecting receivables; and recording and accounting for obliga- tions, costs, revenues, and expenses. In many cases, these kinds of functions are al- most completely dependent on automated information systems, thereby creating many new concerns and risks for management. . . . 5. To address these concerns, managers who operate or use ADP systems should take actions to eliminate or at least reduce the risks to acceptable levels. All such actions taken to reduce risks are referred to as ``control techniques'' or, more com- monly, ``controls.'' The underlying requirement of control over an automated infor- mation system is to provide reasonable assurance that the information processed by the system is reliable and properly safeguarded. 6. Management oversees and effects the development, implementation, and use of automated information systems through a variety of mechanisms, including stand- ards, budget and procurement review and authorization, and personnel hiring prac- tices. While existing mechanisms have worked with varying success to ensure that systems support an organization's mission, they have not always provided reasona- ble assurance that a system is safe. Systems may improve accuracy, increase pro- ductivity, or speed service but at the same time be subject to fraud, waste, and abuse. B. System Control Requirements 1. Control requirements are established to address a known vulnerability or pro- mote reliability or security of a system. They can be based on management experi- ence, vulnerability assessments, other reviews, and/or common sense. Regardless of why established, control requirements should be as specific as possible and stat- ed in clear, understandable terms. 2. Four categories of control requirements surfaced in an analysis of the provisions of the system control directives . . . These are application controls, general con- trols, administrative controls, and required system functions. While the ongoing discussion deals with these four categories of control requirements, it should be recognized here that the operational implementation of a controls program will in- volve a refining of these requirements into sub-requirements or control objectives. [See Appendix B of this document]. 3. The first category, application controls, are those that help assure that informa- tion processed is authorized, valid, complete, accurate, and timely. It also contains requirements that ensure that the system is secure and that an audit trail exists. 4. Compliance with the requirements for application controls has proved the most elusive for management to meet. Requirement terminology varies among the many directives, but the intent is the same in all. 5. Three principles are important to note: a. How information should be handled, once its sensitivity and/or classifica- tion has been determined, is fairly well established by the regulating agency. b. The determination of the classification levels for systems and data is a management responsibility of the sponsoring agency. c. Once the classification levels are determined by management, the determi- nations should be systematically applied, and management should be aware of any exceptions. 6. What the third principle means is that sensitive data in a computer data base should have the same classification as they are given in a hard copy publication. Most processes (accounting or otherwise) consist of both manual and automated portions. Reviews of the process should assess the totality of the process compo- nents affected, not just a portion of the affected components. Further, management must be aware that increases in security are almost always accompanied by increas- es in cost, although some security measures can be implemented with little effort. Management must be aware of situations when resources are insufficient to pro- vide the level of protection required, because it is management that must accept the risk of loss and/or disclosure. Because of the terminology and technical com- plexities of automated processes, the evidence suggests that managers often dele- gate these critical decisions to their program and/or technical staff. It is of para- mount importance that managers fully understand the need for controls, the re- source implications of controls, and the risks associated with inadequate controls. These are management's responsibilities and cannot be delegated. 7. The second category, general controls such as cost-benefit analysis and certifica- tion, are quantifiable and require a product to be created for management review and/or acceptance. These tools are essential to good management in the develop- ment and operation of systems by facility managers, users, systems analysts, and computer programmers. Another essential tool which should be applied by all man- agers and users is agency record and disposition schedules. 8. The third category, administrative controls such as supportive attitudes or com- petent personnel, are generally difficult to quantify and have not resulted in the past in tangible work products within automated information systems. 9. Many of the requirements have become standard operation procedures in some Federal Agencies, with considerable guidance provided on how they should be met. 10. The last category of control requirements, required systems functions, consists of mandated features that must be designed and built into a system, such as a par- ticular access capability. C. Selection and Use of Control Techniques 1. Control techniques are procedures used to meet control requirements. Control techniques employed might be preventive, detective, corrective, or a combination of the three . . . 2. The selection of a control technique should, in most cases, be a group decision to ensure that it is feasible for the entire system, is understood by all affected, and comprehensively meets the organization's control requirements. . . . 3. Further, the control selected must be cost-effective. . . . Controls that require manpower, such as integrity reviews of transactions, can be costly and require a cost-benefits analysis. This analysis becomes part of the controls documentation. Decisions on some controls may also require detailed knowledge of controls al- ready in place. This is especially true of routine controls, such as access controls. The composition of current access controls may greatly affect the design of any ad- ditional access controls being contemplated for a particular system. 4. The installation of controls must be accompanied by an effort to provide assur- ance that the control operates as initially intended. Testing is needed before the control is implemented, as well as later, to be sure it still fulfills the control re- quirement. Ongoing reviews might be a part of a management initiative. . . . 5. The controls selected and implemented must have certain characteristics to en- sure that they are effective. They must be: a. Clear in purpose - If not understood, controls may not be used and if they do not have a clear purpose or address a known vulnerability, they are of lit- tle or no value. b. Coordinated - Developed in partnership by personnel knowledgeable about the application, process, computer systems, and control techniques. It is unlikely that effective, feasible controls can be selected and implemented unilaterally by, for example, a user, a system analyst, a programmer, or an auditor. c. Cost-effective - The cost of the control should not, in general, exceed the expected benefits. Stated another way, there should be reasonable assurance that the system is protected from a known risk. If total assurance of control were possible, it would probably be prohibitively expensive. . . . d. Documented - The documentation process should be simple, understanda- ble, clearly link risks to controls, and provide management with assurance that all reasonable controls are in place. Without some form of documenta- tion, there is no assurance that all known vulnerabilities are addressed or that controls are in place. e. Tested and reviewed - There must be assurance that the controls function as originally intended. This assurance is needed when the systems first be- comes operational and also during ongoing operation. Initial controls testing should normally be done when all other aspects of the system are tested. On- going testing and review might be done as part of a general system review, and internal control review, an audit, or other management initiative. f. Manageable - Management must have the means to change, delete, evalu- ate cost, upgrade, or review the system of controls under its purview. D. Areas of Control 1. Automated information systems typically encompass data files, computer pro- grams, and equipment, all of which may affect controls in some way. Part of the problem in dealing with controls is the wide variability in how systems are de- fined. If there was uniformity in definitions, then control techniques could be ap- plied, evaluated, and cataloged more easily. 2. The five control areas listed below are the basic control requirements. . . . a. Input - includes the records (also referred to as either manual data or trans- actions) to be processed by the system, and the associated processes from origination to the computer. b. Output - includes the records and reports produced by the system, and the associated manual processes from the computer to the user. c. Processing - includes all computer processing to receive the input and store and/or otherwise manipulate the input to produce output. d. Storage - includes all computer program code and/or instructions and data files. e. Communications - includes the transmission of data and/or information ei- ther between sites or between peripherals at a site. 3. Viewing a system in its pieces makes it easier to set specific control require- ments and select control techniques. It is important to retain a system's perspec- tive, to avoid over-control, and to deal with system-wide issues. The following sys- tem-wide control issues need to be considered: a. Control techniques in one control area may lessen the need for controls in another control area; for instance, tight controls over data files may negate the need for some communication controls. b. Some aspects of a system may require special system-wide attention; e.g., a highly sensitive sub-file may require tight controls during inputting, stor- age, or outputting. 4. This perspective should be the responsibility of individuals or a group that is in- volved in all aspects of the system. A user group or a controls specialist assigned to the project might be assigned controls responsibility. 5. In general, the framework proposes that control techniques be applied to de- fined control areas to fulfill control requirements . . . A.16.1 Cross-References and Comments TABLE A-33. DoD Guideline 7740.1-G-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance Chap.2(B)(1) X Chap.2(B)(2) X Chap.2(B)(3) X X X X X Chap.2(B)(5) X X Chap.2(B)(5)(c) X X Chap.2(B)(6) X X X Chap.2(B)(8) X X X X Chap.2(B)(9) X Chap.2(B)(10) X X X Chap.2(C)(1) X Chap.2(C)(2) X Chap.2(C)(3) X Chap.2(C)(4) X Chap.2(C)(5)(a-f) X Chap.2(D)(1) X Chap.2(D)(2)(a-e) X Chap.2(D)(3)(a-b) X Chap.2(D)(4) X Chap.2(B)(1) [Security Policy] A security policy serves as the set of basic requirement statements which must address vulnerabilities and promote security, reliability, and safety. Specific control requirements must be developed for each appropriate facet (i.e., security, reliabil- ity, safety, and known vulnerabilities) and must be clearly stated. Chap.2(B)(2) [Security Policy] Control requirements must address each of the four cited categories. Of these, application controls and required systems functions are of paramount concern in terms of (a) specification of intent, (b) specification of explicit constraints, and (c) specification of control area. Chap.2(B)(3) [Security Policy] Application-specific control requirements must address the authorization, validity, completeness, accuracy, and timeliness of information processing. [MAC, DAC, Marking] Requirements for authorization imply access control features. [Accountability] Auditing of access controls for accountability is required by authorization requirements. Chap.2(B)(5) [Security Policy] The protection of information may have mandatory control compo- nents imposed by law, an external regulatory agency, and/or a higher authority within an organization. The security policy must reflect this imposed requirement. [MAC] The ap- plication of the security policy must ensure that the mandatory access control compo- nent is consistent with the specification in the policy requirement. Chap.2(B)(5)(c) [Accountability] Audit and/or other accountability features are required to keep manage- ment aware of exceptions to established policies. [Assurance] Systematic application of controls implies that the totality of controls, including those resident in AISs, must be considered in determining the scope of protection. Assurance techniques can be used to make management aware of any exceptions in the systematic application of controls. Chap.2(B)(6) [Security Policy] Management must be aware of the cost-benefit tradeoffs in providing protection and control features. This implies a thorough and comprehensive risk assess- ment process. [Marking] Information within AISs must be marked with attributes which reflect the same categorization (and implying the same controls) as those associated with external hard copies of that information. [Assurance] Reviews must consider the totality of process components. Chap.2(B)(8) [Security Policy] The issue of identifying competency of personnel, albeit difficult, is one that is significant for integrity. In identifying competency levels, the initial proce- dure should be to objectively separate specific duties into roles, to which individuals can be assigned. Thus, role and duty specifications form an objective basis of competency, while actual assignment of roles can be based on management's subjective opinion. [MAC, DAC] The mandatory and discretionary aspects of the use of roles and duties, coupled with data object attributes, serve as a basis for object access or process execu- tion, enabling enforcement of competency-related policies. [Marking] Attributes of both subjects and objects must be available either through system-enforced marking or as an inherent part of a subject or object to enable such controls. Chap.2(B)(9) [Security Policy] Many standard operating procedures that contain acceptable controls in manual environments will not necessarily be acceptable in an automated environment. As more functionality becomes integrated into computer systems, new controls for stand- ard automated operating procedures will be required. This will result in a much richer set of security policy and ensuing controls the those conceived for confidentiality. Chap.2(B)(10) [Security Policy, Assurance, Fault Tolerance] Required systems functions must be con- sidered in formulating the security policy. This implies assurance and fault tolerance fea- tures for some applications. The mandatory aspects of a security policy which must be enforced by system-provided mechanisms must be identified and determined to be a con- sistent (i.e., non-conflicting) set of requirements. Where conflicts arise, alternatives to system-provided mechanisms must be employed until the conflicts are resolved. In em- ploying these alternative controls, the intent of the initial requirements set must be met. Chap.2(C)(1) [Security Policy] Prevention, detection, and correction are all valid techniques for ad- dressing threats to protected resources. An appropriate choice of mechanisms employing a particular type of technique, or a combination of techniques, must be made for protect- ed resources. Chap.2(C)(2) [Assurance] The feasibility, understandability, and comprehensiveness of selected con- trol techniques must be considered. This implies ``economy of mechanism'' to enforce overlapping aspects of controls. Chap.2(C)(3) [Assurance] Risk assessments, the notion of ``due care,'' the notion of ``economy of mechanism,'' and engineering trade-offs are implied by the requirement for cost-effective- ness. Chap.2(C)(4) [Assurance] An effort (e.g., testing) must be made to ensure selected control techniques operate as intended. The degree of effort should reflect the sensitivity of the information or application in which the controls are intended to protect. Facility management proce- dures for installing and maintaining controls will be required. Chap.2 (C)(5)(a-f) [Assurance] A variety of Assurance features are listed to ensure the effectiveness of se- lected control techniques. Chap.2(D)(1) [Security Policy] The security policy must address, in clear and precise terms, the scope of resources which are applicable. Uniform terms should be used where possible. Chap.2 (D)(2)(a-e) [Security Policy] The Security Policy must address each of the five control areas which are applicable (input, output, processing, storage, and communications). Chap.2 (D)(3)(a-b) [Assurance] Assurance issues are raised by the integration of different controls and the dependence of controls upon other controls. System design should address these issues. Chap.2(D)(4) [Assurance] Responsibility should be assigned to address system-wide controls. A.17 DoD Directive 7750.5-Management and Control of Information Re- quirements This Directive implements the policies stated in DoD Directive 7740.1, DOD Information Resources Management Program and Public Law 96-511, Paperwork Reduction Act of 1980. Specifically, this Directive specifies administrative policies related to information requirements. This Directive applies to all internal, interagency, and public reporting DoD information requirements. All information systems and techniques for collecting, recording, maintaining, and disseminating information are included under its provision unless exempted under Public Law 96-511. The following table contains selected sections of DoD Directive 7750.5. The cross- reference table and comments appear in the next section. TABLE A-34. DoD Directive 7750.5-Selected Source Text A. Purpose 1. This Directive prescribes policies for the management and control of informa- tion requirements. It also implements those policies in [DoD 7740.1-D] and [PRA 1980] concerning the licensing of reporting requirements internal and external to the Department of Defense and the development of an Information Collection Budget. . . . D. Policy 1. Ensuring that sufficient information is available to achieve military effective- ness and management efficiency is a basic command and management responsibili- ty. As a fundamental policy, however, the burden associated with the collection and reporting of this information must be controlled and minimized. The manage- ment of reports internally prescribed by the DoD component must include provi- sions for setting annual goals, consistent with critical mission needs, to reduce the number or frequency or reports. 2. The central ingredient in information management is the user's responsibility and accountability for assuring that information requirements are valid, accurate, and essential to the mission of the user's organization. a. These requirements should be examined to avoid both duplication and un- necessary generation of data. Because the creation or collection of informa- tion requires the allocation of scarce resources, the user must first ascertain that the required data are not already available from other sources. b. Statistical sampling techniques and information technology should be em- phasized as approaches for minimizing reporting workloads. c. In the development and operational life cycle of an automated information system, care shall be taken to assure that information needs are clearly identi- fied and that reports to be generated by the automated system represent cost effective use of resources, as required by DoD Directive 7920.1 [Life Cycle Management of Automated Information Systems] A.17.1 Cross-References and Comments TABLE A-35. DoD Directive 7750.5-Cross-References Section Security Policy MAC DAC Marking Accountability Assurance Fault Tolerance D(1) X D(2) X X D(2)(a) X X D(2)(b) X D(2)(c) X X D(1) [Security Policy] The sufficiency of information resources to achieve military effective- ness and management efficiency must be addressed. In addition to the concept of suffi- ciency, the burden associated with collecting and reporting information must be control- led and minimized. D(2) [Security Policy, Accountability] This policy statement supports the position that individ- uals are ultimately responsible for the information processing resources under their ad- ministration. Information processing resources and activities must be valid, accurate, and essential to the mission needs of the DoD component. This implies similar quality at- tributes for the operational aspects (e.g., data and processing properties) of the informa- tion resources which are used to fulfill component information requirements. D(2)(a) [Security Policy] The control of duplication and unnecessary generation of data is re- quired. [Accountability] The user must ascertain that required information is not availa- ble by other means. D(2)(b) [Accountability] The minimization of reporting workload is required. The use of infor- mation technology to achieve this goal is explicitly mentioned. D(2)(c) [Security Policy, Accountability] The information needs of the DoD component must be identified and supporting AISs must be capable of meeting those needs. Reports generat- ed by AISs must be cost effective. APPENDIX B B. POLICY CROSS-REFERENCE The table appearing in this Appendix is a reproduction of Table 3.1 from the Department of Defense ADP Internal Control Guideline [DoD 7740.1-G]. This table ``provides a listing of 55 control requirements cross-referenced to the major control objectives . . .'' [DoD 7740.1-G, p. 3-6]. Although this table does not provide cross-references for all of the policy statements used in this document, it does include the following: · OMB Circular No. A-123, Internal Control Systems [OMB A-123]; · Internal Control Guidelines [OMB ICG]; · OMB Circular No. A-127, Financial Management Systems [OMB A-127]; · OMB Circular No. A-130, Management of Federal Information Resources [OMB A- 130]; · GAO Policy and Procedures Manual for Guidance of Federal Agencies-Title 2 - Ac- counting [GAO Title II]; · Privacy Act of 1974 [PA 1974]; · Federal Managers' Financial Integrity Act of 1982 [FMFIA 1982]; · DoD Directive 5010.38, Internal Management Control Program [DoD 5010.38-D]; · DoD Directive 7740.1, DoD Information Resources Management Program [DoD 7740.1- D]. A set of 55 control requirements applying to the internal control of DoD components were derived from these seven documents. The table cross-references each control objective with the particular document(s) from which it was derived. The table contains a brief statement of each control requirement, while the full wording appears in a list following the table (also reproduced from [DoD 7740.1-G]). Four categories of requirements are cited: Application Controls, General Controls, Administrative Controls, and Required Systems Functions. Especially significant when considering integrity in AISs are those requirements listed under Application Controls and Required Systems Functions. TABLE B-36. Summary of Control Requirements [DoD 7740.1-G] Summary table of control objectives cross-referenced to the major control directives. Line No.- Requirements A-123 OMB IC A-127 A-130 GAO Title II FMFIA Privacy Act DoD IMCP DoD IRMP APPLICATION CONTROLS 1. Transactions are authorized X X X X X 2. Transactions are valid X X X X X 3. Information is complete X X X X X X X 4. Information is accurate X X X X X X X X 5. Information is timely X X X X X X X 6. System and data are secure X X X X 7. System is auditable X X GENERAL CONTROLS 8. System controls exist X X 9. 5-yr. system plan developed X X X X 10. Contingency/disaster plan X X X 11. Vulnerability assessment X X X X 12. Cost/benefit analysis X X 13. Reasonable assurance X X X X X X X 14. Control objectives defined X X X X 15. Control techniques selected X X X X 16. Security reqs. adequacy X 17. Security specs. exist X X X 18. Security specs. adequacy X 19. System design approved X X 20. Controls documented X X X 21. System documentation exists X 22. System contingency plan X X 23. Controls tested X X 24. System test conducted X 25. Test results documented X X 26. System certified X 27. Controls review performed X X X X X 28. Periodic reviews X X X X X 29. Periodic risk assessments X X X 30. Corrective action/ audit X X X X 31. Internal controls report X X X X 32. Accounting systems report X X X 33. Annual report to President X X X X X X ADMIN. CONTROLS 34. Org. responsibility fixed X X X 35. Separation of duty exists X X X X 36. Supervision is provided X X X X 37. Supportive attitude exists X X X X 38. Personnel are competent X X X X 39. Security training program X X 40. Written policies/ procedures X X X X X 41. Personnel security policies X X 42. Ind. responsibilities fixed X X X X X X 43. Accountability assigned X X X X X X X 44. Record retention procedures X X 45. Release of information X X X REQ. SYSTEM FUNCTIONS 46. System is efficient X X X 47. System operation economical X X 48. System is effective X X X 49. System supports management X X X 50. System supports budget X X X 51. Comparability/ consistency X X 52. Information useful/ relevant X X X X X 53. System provides disclosure X X X 54. Individual access allowed X X X 55. Network compatibility X B.1 Requirements List The following list of requirements correspond with the summaries appearing in the first column of the preceding table. Application Controls 1. Transactions are authorized - the information entered into the system must be author- ized by management for entry. 2. Transactions are valid - the information system must process only data that represent legitimate events. 3. Information is complete - all valid data, and only those data, are to be processed by the information system. 4. Information is accurate - data must be free from error during all phases of processing, within defined levels of tolerance. 5. Information is timely - data must reflect the correct cycle, version, or period for the processing being performed. Financial management data shall be recorded as soon as practical after the occurrence of the event, and relevant preliminary data shall be made available promptly to managers after the end of the reporting period. 6. System and data are secure - the data files, computer program, and equipment must be secure from unauthorized and accidental changes, unauthorized disclosure and use, and physical destruction. Detective and corrective controls may also apply depending on the sensitivity and/or classification of the data. 7. System is auditable - an information trail must exist that establishes individual ac- countability for transactions and permits an analysis of breakdowns in the system and other anomalies. General Controls 8. System controls exist - for each information system, the controls system should en- sure that appropriate safeguards are incorporated into the systems, tested before imple- mentation, and tested periodically after implementation. 9. Five-year system plan developed - a plan featuring specific milestones with obligation and outlay estimates for every system of the agency (both current and under develop- ment). 10. Contingency plan and/or disaster recovery plan exists - agencies shall develop, main- tain, and test disaster recovery and continuity of operations plans for their data center(s). The plan's objective is to provide reasonable continuity of data processing support if nor- mal operations are prevented. 11. Vulnerability assessment conducted - a review of the susceptibility of a program or function to waste, loss, unauthorized use, or misappropriation. Includes both vulnerabili- ty assessments or their equivalents, such as an audit. 12. Cost-benefit analysis exists - a review to determine and compare the benefits of the proposed system against the cost of developing and operating the current system. Only those proposals where the expected benefits exceed the estimated costs by 10 percent should be considered for development, unless otherwise specifically required by statute. 13. Reasonable assurance applied - reasonable assurance equates to a satisfactory level of confidence, based on management's judgment of the cost-benefits of the controls ver- sus the recognized risks. (Practically, it is recognized that it is not cost-effective to attain 100 percent assurance.) 14. Control objectives defined - goals established to address a known vulnerability or promote reliability or security of a system. 15. Control techniques selected - methods to satisfy one or more control objectives by preventing, detecting, and/or correcting undesired events. More commonly referred to as "controls." 16. Adequacy of security requirements determined - agencies administrative, physical, and personnel security requirements are included in specifications for the acquisition or operation of facilities, equipment, or software. 17. Security specifications exist - internal control and security objectives must be stated as design specifications and approved by management before development (program- ming) of the application system can begin. 18. Adequacy of security specifications determined - proof that the design specifications satisfy control objectives must be presented to management to authorize computer pro- gram development and/or modification (programming). 19. System design approved - before development (programming) of the system is au- thorized, management must be assured that the system design satisfies the user's require- ments and incorporates the control requirements. The design review must be document- ed and be available for examination. 20. Controls documented - internal control systems, including all transactions and signifi- cant events, are to be clearly documented and be readily available for examination. 21. System documentation exists - documentation that must reflect the current state of the system as it is being operated. The documentation must be sufficient to ensure effec- tive operation by users and system maintenance by programmers. 22. System contingency plan exists - plans must be developed, documented, and tested to ensure that users of the system can continue to perform essential functions in the event their information technology support is interrupted. The plan should also be con- sistent with the agency-wide disaster recovery plan. 23. Controls tested - before a new or modified system is placed into production status, the controls should be tested to prove that the controls operate as intended. The test re- sults should be documented and sent to management for approval to implement the sys- tem. 24. System test conducted - before implementation of the system is authorized, evidence that the system operates as intended must be presented to management. This evidence must also include the results of controls testing. The test results must be documented and available for examination. 25. Test results documented - the documentation should demonstrate that the control and functionality requirements operate as intended. 26. System certified prior to implementation - before a system can be implemented, an agency official shall certify that the system meets all applicable Federal policies, regula- tions, and standards, as well as state that test results demonstrate that installed controls are adequate for examination. 27. Controls review performed - periodically, the controls of each system must be tested to determine if the controls still function as intended. The results of these tests must be documented and available for examination. 28. Periodic reviews and re-certifications are conducted at least every 3 years, agencies shall review applications and re-certify the adequacy of the safeguards. The re-certifica- tions shall be documented and be available for review. 29. Periodic risk assessments are conducted - agencies shall conduct periodic risk assess- ments at each data center to provide a measure of the relative vulnerabilities and threats to the data center so that security resources can be effectively distributed to minimize po- tential loss. 30. Corrective action taken; audit findings resolved promptly - managers are to promptly evaluate audit findings and recommendations, determine proper corrective actions, and complete those actions. 31. Annual report on internal controls prepared - yearly, each agency must determine proper if its systems of internal controls are in compliance with the Comptroller Gener- al's standards. 32. Annual report on accounting systems prepared - yearly, each agency must determine if its accounting systems are in compliance with the Comptroller General's standards. 33. Annual reports to President sent - the head of each agency must sign both annual re- ports and transmit them to both the President and Congress. Administrative Controls 34. Organizational responsibility is affixed - the assignment of responsibilities for plan- ning, directing and controlling the controls evaluation process for the agency and/or seg- ment is specified. The programs and functions conducted in each of the components have also been specified. The programs and functions conducted in each of the compo- nents have also been specified. 35. Separation of duties exists - key duties and responsibilities in authorizing, process- ing, recording, and reviewing transactions should be separated among individuals. 36. Supervision is provided - qualified and continuous supervision is to be provided to ensure that control requirements are met. 37. Supportive attitudes exist - managers and employees are to maintain and demon- strate a positive and supportive attitude toward controls at all times. 38. Personnel are competent - manager and employees are to have personnel and profes- sional integrity and are to maintain a level of competence that allow them to accomplish their assigned duties, as well as understand the importance of developing and implement- ing good controls. 39. Security training program exists - agencies shall establish a security awareness and training program so that agency and contractor personnel involved with information sys- tems are aware of their security responsibilities and know how to fulfill them. 40. Written policies and procedures exist - each agency shall establish administrative procedures to enforce the intended functioning of controls, including provisions that per- formance appraisals reflect execution of control-related responsibilities. 41. Personnel security policies exist - each agency should establish and manage person- nel security procedures, including requirements for screening agency and contractor per- sonnel designing, developing, operating, maintaining, or using the system. The level of screening depends on the sensitivity and/or classification of the system data. 42. Individual responsibilities are affixed - assignments or responsibility should be made for internal controls, accounting systems, and data center security on an 43. Custody and/ or accountability assigned - the official whose function is supported by an information system is responsible and accountable for the products of the information system is re- sponsible and accountable for the products of the information system. 44. Record disposition procedures exist - each agency must establish approved records disposition schedules which identify permanent data files and ensure their transfer to the National Archives and Record Administration. 45. Release of information provided for - each agency must have procedures in place so that information can be extracted from systems to meet requests made under the Privacy Act and Freedom of Information Act. Required System Functions 46. An analysis of the ratio of outputs to inputs evaluated against an acceptable standard. 47. System operation is economical - uneconomical systems must be identified and phased out. 48. System is effective - periodically, each system should be reviewed to determine if the system still meets organizational needs. 49. System supports management - data shall be recorded and reported in a manner to fa- cilitate carrying out the responsibilities of both program and administrative managers. 50. System supports budget - financial management data shall be recorded, stored, and reported to facilitate budget preparation, analysis, and execution. 51. Comparability and/or consistency provided for - financial management data shall be recorded and reported in the same manner throughout the agency, using uniform defini- tions that are synchronized with budgeting and used consistently for each reporting peri- od. 52. Information is useful and/or relevant - data capture and reports shall be tailored to specific user needs, and if usage does not justify costs, data or reports shall be terminat- ed. 53. System provides full disclosure - data shall be recorded and reported to provide us- ers of the data with complete information about the subject of the report per OMB, Treasury, and Privacy Act standards. 54. Individual access allowed - systems must be able to extract any data contained in the data base about individuals to meet requests to see the data by that individual or his/her representative when required by the Privacy Act. 55. Network compatibility exists - any systems developed or acquired must be interoper- able with any existing system that will be linked to the new system.