Review of the United States Marshals Service's Prisoner Tracking System
Report No. 04-29
August 2004
Office of the Inspector General
The general controls guidelines used for this audit were obtained from Chapter 3, "Evaluating and Testing General Controls," of the GAO's FISCAM. The information below represents only those sections from the FISCAM that serve as the basis for the vulnerabilities identified during our review of the Prisoner Tracking System.17 3.0 OVERVIEW General controls are the structure, policies, and procedures that apply to an entity's overall computer operations. They create the environment in which application systems and controls operate. During a financial statement audit, the auditor will focus on general controls that normally pertain to an entity's major computer facilities and systems supporting a number of different applications, such as major data processing installations or local area networks. If general controls are weak, they severely diminish the reliability of controls associated with individual applications. For this reason, general controls are usually evaluated separately from and prior to evaluating application controls. There are six major categories of general controls that the auditor should consider. These are:
3.1 ENTITY-WIDE SECURITY PROGRAM PLANNING AND MANAGEMENT (SP) An entity-wide program for security planning and management is the foundation of an entity's security control structure and a reflection of senior management's commitment to addressing security risks. The program should establish a framework and continuing cycle of activity for assessing risk, developing and implementing effective security procedures, and monitoring the effectiveness of these procedures. Without a well-designed program, security controls may be inadequate; responsibilities may be unclear, misunderstood, and improperly implemented; and controls may be inconsistently applied. Such conditions may lead to insufficient protection of sensitive or critical resources and disproportionately high expenditures for controls over low-risk resources.
Senior management should establish a structure to implement the security program throughout the entity. The structure generally consists of a core of personnel who are designated as security managers. These personnel play a key role in developing, communicating, and monitoring compliance with security policies and reporting on these activities to senior management. The security management function also serves as a focal point for others who plan a role in evaluating the appropriateness and effectiveness of computer-related controls on a day-to-day basis. These include program managers who rely on the entity's computer systems, system administrators, and system users. SP-3.1: A security management structure has been established The effectiveness of the security program is affected by the way in which responsibility for overseeing its implementation is assigned. Generally, such responsibility is assigned to a central security program office. Responsibilities of the central security program office may include:
SP-3.2: Information security responsibilities are clearly assigned OMB Circular A-130, Appendix III, requires that the rules of the system and application "shall clearly delineate responsibilities and expected behavior of all individuals with access . . . and shall be clear about the consequences of behavior not consistent with the rules." Security-related responsibilities of offices and individuals throughout the entity that should be clearly defined include those of (1) information resource owners and users, (2) information resources management and data processing personnel, (3) senior management, and (4) security administrators. Further, responsibilities for individual employee accountability regarding the use and disclosure of information resources should be established."
Policies related to personnel actions, such as hiring and termination, and employee expertise are important factors for information security. If personnel policies are not adequate, an entity runs the risk of (1) hiring unqualified or untrustworthy individuals, (2) providing terminated employees opportunities to sabotage or otherwise impair entity operations or assets, (3) failing to detect continuing unauthorized employee actions, (4) lowering employee morale, which may in turn diminish employee compliance with controls, and (5) allowing staff expertise to decline. SP-4.2: Employees have adequate training and expertise Management should ensure that employees - including data owners, system users, data processing personnel, and security management personnel - have the expertise to carry out their information security responsibilities. To accomplish this, the security program should include:
3.2 ACCESS CONTROLS (AC) Access controls should provide reasonable assurance that computer resources (data files, application programs, and computer-related facilities and equipment) are protected against unauthorized modification, disclosure, loss, or impairment. Such controls include physical controls, such as keeping computers in locked rooms to limit physical access, and logical controls, such as security software programs designed to prevent or detect unauthorized access to sensitive files. Inadequate access controls diminish the reliability of computerized data and increase the risk of destruction or inappropriate disclosure of data. The following examples illustrate the potential consequences of such vulnerabilities.
An entity should institute policies and procedures for authorizing access to information resources and documenting such authorizations. These policies and procedures should cover user access needed for routine operations, emergency access, and the sharing and disposition of data with individuals or groups outside the entity. AC-2.1: Resource owners have identified authorized users and their access authorized The computer resource owner should identify the specific user or class of users that are authorized to obtain direct access to each resource for which he or she is responsible. This process can be simplified by developing standard profiles, which describe access needs for groups of users with similar duties, such as accounts payable clerks. Access may be permitted at a file, record, or field level. Files are composed of records, typically one for each item or transaction. Individual records are composed of fields that contain specific data elements relating to each record. Access authorizations should be documented on standard forms, maintained on file, approved by senior managers, and securely transferred to security managers. Owners should periodically review access authorization listings and determine whether they remain appropriate. Listings of authorized users and their specific access needs and any modifications should be approved by an appropriate senior manager and directly communicated in writing by the resource owner to the security management function. It is equally important to notify the security management function immediately when an employee is terminated or, for some other reason, is no longer authorized access to information resources.
The entity should have a cost-effective process for protecting data files, application programs, and hardware through a combination of physical and logical security controls. Physical security involves restricting physical access to computer resources, usually by limiting access to the buildings and rooms where they are housed, or by installing locks on computer terminals. However, physical controls alone cannot ensure that programs and data are protected. For this reason, it is important to establish logical security controls that protect the integrity and confidentiality of sensitive files. The security function should be responsible for implementing and maintaining both physical and logical controls based upon authorizations provided by the owners of the resources. AC-3.1: Adequate physical security controls have been implemented Physical security controls restrict physical access to computer resources and protect them from intentional or unintentional loss or impairment. In evaluating the effectiveness of physical security controls, the auditor should consider the effectiveness of the entity's policies and practices for:
3.3 APPLICATION SOFTWARE DEVELOPMENT AND CHANGE CONTROL (CC) Application software is designed to support a specific operation, such as payroll or loan accounting. Typically several applications may operate under one set of operating system software. Controls over operating system software are discussed in Section 3.4. Establishing controls over the modifications of application software programs helps to ensure that only authorized programs and authorized modifications are implemented. This is accomplished by instituting policies, procedures, and techniques that help make sure all programs and program modifications are properly authorized, tested, and approved; and that access to and distribution of programs is carefully controlled. Without proper controls, there is a risk that security features could be inadvertently or deliberately omitted or "turned off" or that processing irregularities or malicious code could be introduced. For example,
The processing features built into application software should be authorized by the managers responsible for the agency program or operations that the application supports. This is because these are the managers responsible for seeing that software supporting their operations meets their needs and produces reliable data and that the operations are carried out in accordance with applicable laws, regulations, and management policies. For example, the processing features associated with loan accounting software should be authorized by the loan program managers. Such user or owner authorization is needed when new systems are being developed, as well as when operational systems are being modified. Authorization is the first step in implementing the features or the changes that have been decided on by the users, and the entity should have a process for obtaining, documenting, and communicating such authorizations as part of its system development life cycle (SDLC) methodology. If authorization procedures have not been developed or are not followed, an individual might be able to initiate program changes that result in erroneous processing or weakened access controls or edits built into the software. CC-1.2: Authorizations for software modifications are documented and maintained Policies and procedures should be in place that detail who can authorize a modification and how these authorizations are to be documented. Generally the application users have the primary responsibility for authorizing systems changes. However, users should be required to discuss their proposed changes with systems developers to confirm that the change is feasible and cost effective. For this reason, an entity may require a senior systems developer to co-authorize a change. The use of standardized change request forms helps ensure that requests are clearly communicated and that approvals are documented. Authorization documentation should be maintained for at least as long as a system is in operation in case questions arise regarding why or when system modifications were made. Authorization documents may be maintained in either paper or electronic form as long as their integrity is protected. 3.4 SYSTEM SOFTWARE (SS) System software is a set of programs designed to operate and control the processing activities of computer equipment. Generally, one set of system software is used to support and control a variety of applications that may run on the same computer hardware. System software helps control and coordinate the input, processing, output, and data storage associated with all of the applications that run on a system. Some system software can change data and program code on files without leaving an audit trail. The following are examples of system software:
Controls over access to and modification of system software are essential in providing reasonable assurance that operating system-based security controls are not compromised and that the system will not be impaired. Inadequate controls in this area could lead to unauthorized individuals using system software to circumvent security controls to read, modify, or delete critical or sensitive information and programs; authorized users of the system gaining unauthorized privileges to conduct unauthorized actions; and/or systems software being used to circumvent edits and other controls built into application programs. Such weaknesses seriously diminish the reliability of information produced by all of the applications supported by the computer system and increase the risk of fraud and sabotage. System software programmers are often more technically qualified than other data processing personnel and, thus, have a greater ability to perform unauthorized actions if controls in this area are weak.
Modifications to system software should be controlled so that only authorized and properly tested changes are implemented. If system software is not adequately controlled and tested, system parameters may be inadequate to prevent unauthorized changes to application programs or data. Furthermore, software malfunctions during processing runs could result in inaccurate or incomplete financial data. Controls should provide that all changes are tested and approved and that only approved system software is implemented. SS-3.2: Installation of system software is documented and reviewed When possible, the installation of system software changes and new versions or products should be scheduled to minimize the impact on data processing operations, and an advance notice should be provided to system software users. The actual installation should be logged to establish an audit trail and reviewed by data center management. The migration of system software from the testing environment to the production environment should be done, after approval, by an independent library control group. Outdated versions of system software should be removed from the production environment to preclude their future use. Some changes may be made specifically to correct security or integrity vulnerabilities, while using outdated versions allows the entity's data and systems to remain exposed to these vulnerabilities. All vendor-supplied system software should be supported by the vendor. Vendors often release new versions of system software products and may discontinue support of earlier versions. Enhancements and corrections made to subsequent versions of system software will not be available to entities that forgo acquiring the latest version. All system software should have current and complete documentation. Inadequate documentation will hinder maintenance activities, particularly during emergency situations when in-house systems programmers are attempting to restart a failed system and vendor assistance is not readily available. 3.5 SEGREGATION OF DUTIES (SD) Work responsibilities should be segregated so that one individual does not control all critical stages of a process. For example, while users may authorize program changes, programmers should not be allowed to do so because they are not the owners of the system and do not have the responsibility to see that the system meets user needs. Similarly, one computer programmer should not be allowed to independently write, test, and approve program changes. Often, segregation of duties is achieved by splitting responsibilities between two or more organizational groups. Dividing duties among two or more individuals or groups diminishes the likelihood that errors and wrongful acts will go undetected because the activities of one group or individual will serve as a check on the activities of the other.
The first steps in determining if duties are appropriately segregated are to analyze the entity's operations, identify incompatible duties, and assign these duties to different organizational units or individuals. Federal internal control standards specify that key duties and responsibilities for authorizing, processing, recording, and reviewing transactions should be separated. This concept can also be applied to the authorization, testing, and review of computer program changes. Segregating duties begins by establishing independent organizational groups with defined functions, such as a payroll unit responsible for preparing payroll transaction input and a data processing unit responsible for processing input prepared by other units. Functions and related tasks performed by each unit should be documented for the unit and in staff job descriptions and should be clearly communicated to personnel assigned the responsibilities. SD-1.1: Incompatible duties have been identified and policies implemented to segregate these duties Management should have analyzed operations and identified incompatible duties that are then segregated through policies and organizational divisions. Although incompatible duties may vary from one entity to another, the following functions are generally performed by different individuals: Information Systems (IS) management, systems design, application programming, systems programming, quality assurance/testing, library management/change management, computer operations, production control and scheduling, data security, data administration, and network administration. The following include examples of restrictions that are generally addressed in policies about segregating duties and are achieved through organizational divisions and access controls.
Some steps involved in processing a transaction also need to be separated among different individuals. For example, the following combinations of functions should not be performed by a single individual.
Organizations with limited resources to segregate duties should have compensating controls, such as supervisory review of transactions performed.
Control over personnel activities requires formal operating procedures and active supervision and review of these activities. This is especially relevant for computer operators. Inadequacies in this area could allow mistakes to occur and go undetected, and facilitate unauthorized use of the computer. SD-3.1: Formal procedures guide personnel in performing their duties Detailed, written instructions should exist and be followed to guide personnel in performing their duties. These instructions are especially important for computer operators. For example, computer operator instruction manuals should provide guidance on system startup and shut down procedures, emergency procedures, system and job status reporting, and operator prohibited activities. Application-specific manuals (commonly called "run" manuals) should provide additional instructions for operators specific to each application, such as instructions on job setup, console and error messages, job checkpoints, and restart and recovery steps after system failures. Operators should be prevented from overriding file label or equipment error messages. SD-3.2: Active supervision and review are provided for all personnel Supervision and review of personnel activities help make certain that these activities are performed in accordance with prescribed procedures, that mistakes are corrected, and that the computer is used only for authorized purposes. To aid in this oversight, all computer operator activities on the computer system should be recorded on an automated history log, which serves as an audit trail. Supervisors should routinely review this history log and investigate any abnormalities. 3.6 SERVICE CONTINUITY (SC) Losing the capability to process, retrieve, and protect information maintained electronically can significantly affect an agency's ability to accomplish its mission. For this reason, an agency should have (1) procedures in place to protect information resources and minimize the risk of unplanned interruptions and (2) a plan to recover critical operations should interruptions occur. These plans should consider the activities performed at general support facilities, such as data processing centers and telecommunications facilities, as well as the activities performed by users of specific applications. To determine whether recovery plans will work as intended, they should be tested periodically in disaster simulation exercises. To mitigate service interruptions, it is essential that the related controls be understood and supported by management and staff throughout the organization. Senior management commitment is especially important to ensure that adequate resources are devoted to emergency planning, training, and related testing. In addition, all staff with service continuity responsibilities, such as staff responsible for backing up files, should be fully aware of the risks of not fulfilling these duties.
At most entities, the continuity of certain automated operations is more important than others, and it is not cost-effective to provide the same level of continuity for all operations. For this reason, it is important that management analyze data and operations to determine which are the most critical and what resources are needed to recover and support them. This is the first step in determining which resources merit the greatest protection and what contingency plans need to be made. SC-1.2: Resources supporting critical operations are identified Once critical data and operations have been determined, the minimum resources needed to support them should be identified and their role analyzed. The resources considered include computer resources, such as computer hardware, software, and data files; computer supplies, including paper stock and preprinted forms; telecommunications services; and any other resources that are necessary to the operation, such as people, office facilities and supplies, and noncomputerized records. For example, an analysis should be performed to identify the maximum number of disk drives needed at one time and the specific requirements for telecommunications lines and devices. Because essential resources are likely to be held or managed by a variety of groups within an organization, it is important that program and information security (IS) support staff work together to identify the resources for critical operations. There are a number of steps that an organization should take to prevent or minimize the damage to automated operations that can occur from unexpected events. These can be categorized as follows:
Taking such steps, especially implementing thorough backup procedures and installing environmental controls, are generally inexpensive ways to prevent relatively minor problems from becoming costly disasters. In particular, an entity should maintain an ability to restore data files, which may be impossible to recreate if lost. In addition, effective maintenance, problem management, and change management for hardware equipment will help prevent unexpected interruptions. SC-2.1: Data and program backup procedures have been implemented Routinely copying data files and software and securely storing these files at a remote location are usually the most cost-effective actions that an entity can take to mitigate service interruptions. Although equipment can often be readily replaced, the cost could be significant, and reconstructing computerized data files and replacing software can be extremely costly and time-consuming. Sometimes, reconstruction of data files may be virtually impossible. In addition to the direct costs of reconstructing files and obtaining software, the related service interruptions could lead to significant financial losses. A program should be in place for regularly backing up computer files, including master files, transaction files, application programs, systems software, and database software, and storing these backup copies securely at an off-site location. Although choosing a backup storage location is a matter of judgment, the backup location should be far enough away from the primary location that it will not be impaired by the same events, such as fires, storms, and electrical power outages. In addition, it should be protected from unauthorized access and from environmental hazards, such as fires and power outages. SC-2.3: Staff have been trained to respond to emergencies Staff should be trained in and aware of their responsibilities in preventing, mitigating, and responding to emergency situations. For example, data center staff should receive periodic training in emergency fire, water, and alarm incident procedures as well as their responsibilities in starting up and running an alternate data processing site. Also, if outside users are critical to the entity's operations, they should be informed of the steps they may have to take as a result of an emergency. Generally, information on emergency procedures and responsibilities can be provided through training sessions and by distributing written policies and procedures. Training sessions should be held at least once a year and whenever changes to emergency plans are made. Also, if staff could be required to relocate or significantly alter their commuting routine in order to operate an alternate site in an emergency, it is advisable for an entity to incorporate into the contingency plan steps for arranging lodging and meals or any other facilities or services that may be needed to accommodate the essential human resources.
Testing contingency plans is essential to determine whether they will function as intended in an emergency situation. According to OMB, federal managers have reported that testing revealed important weaknesses in their plans, such as backup facilities that could not adequately replicate critical operations as anticipated. Through the testing process, these plans were substantially improved. The most useful tests involve simulating a disaster situation to test overall service continuity. Such a test would include testing whether the alternative data processing site will function as intended and whether critical computer data and programs recovered from off-site storage are accessible and current. In executing the plan, managers will be able to identify weaknesses and make changes accordingly. Moreover, tests will assess how well employees have been trained to carry out their roles and responsibilities in a disaster situation. SC-4.1: The plan is periodically tested The frequency of contingency plan testing will vary depending on the criticality of the entity's operations. Generally, contingency plans for very critical functions should be fully tested about once every year or two, whenever significant changes to the plan have been made, or when significant turnover of key people has occurred. It is important for top management to assess the risk of contingency plan problems and develop and document a policy on the frequency and extent of such testing. Footnotes |