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.¹⁷

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:

• entity-wide security program planning and management that provides a framework and continuing cycle of activity for managing risk, developing security policies, assigning responsibilities, and monitoring the adequacy of the entity's computer-related controls;

• access controls that limit or detect access to computer resources (data, programs, equipment, and facilities), thereby protecting these resources against unauthorized modification, loss, and disclosure;

• application software development and change controls that prevent unauthorized programs or modifications to an existing program from being implemented;

• system software controls that limit and monitor access to the powerful programs and sensitive files that (1) control the computer hardware, and (2) secure applications supported by the system;

• segregation of duties that are policies, procedures, and an organizational structure established so that one individual cannot control key aspects of computer-related operations and thereby conduct unauthorized actions or gain unauthorized access to assets or records; and

• service continuity controls to ensure that when unexpected events occur, critical operations continue without interruption or are promptly resumed, and critical and sensitive data are protected.

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:

• facilitating risk assessments,
• coordinating the development of and distributing security policies and procedures,
• routinely monitoring compliance with these policies,
• promoting security awareness among system users,
• providing reports to senior management on policy and control evaluation results and giving advice to senior management on security policy-related issues; and
• representing the entity in the security community.

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:

• job descriptions that include the education, experience, and expertise needed;
• periodic reassessment of the adequacy of employees' skills;
• annual training requirements and professional development programs to help make certain employees' skills, especially technical skills, are adequate and current; and
• monitoring employee training and professional development accomplishments.

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.

• By obtaining direct access to data files, an individual could make unauthorized changes for personal gain or obtain sensitive information. For example, a person could (1) alter the address of a payee and thereby direct a disbursement to himself or herself, (2) alter inventory quantities to conceal a theft of assets, (3) inadvertently or purposefully change a receivable balance, or (4) obtain confidential information about business transactions or individuals.

• By obtaining access to application programs used to process transactions, an individual could make unauthorized changes to these programs or introduce malicious programs, which in turn could be used to access data files, resulting in situations similar to those described above, or to process unauthorized transactions. For example, a person could alter a payroll or payables program to inappropriately generate a check for himself or herself.

• By obtaining access to computer facilities and equipment, an individual could (1) obtain access to terminals or telecommunications equipment that provide input into the computer, (2) obtain access to confidential or sensitive information on magnetic or printed media, (3) substitute unauthorized data or programs, or (4) steal or inflict malicious damage on computer equipment and software.

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:

• granting and discontinuing access authorizations,
• controlling passkeys,
• controlling entry during and after normal business hours,
• controlling the deposit and withdrawal of tapes and other storage media to and from the library,
• handling emergencies,
• controlling reentry after emergencies; and
• establishing compensatory controls when restricting physical access is not feasible, as is often the case with telecommunications lines.

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,

• a knowledgeable programmer could surreptitiously modify program code to provide a means of bypassing controls to gain access to sensitive data;
• the wrong version of a program could be implemented, thereby perpetuating outdated or erroneous processing that is assumed to have been updated; or
• a virus could be introduced, inadvertently or on purpose, that disrupts processing.

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:

• operating system,
• system utilities,
• program library,
• file maintenance,
• security,
• data communications systems; and
• database management systems.

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.

• Application users should not have access to operating system or application software.
• Programmers should not be responsible for moving programs into production or have access to production libraries or data.
• Access to operating system documentation should be restricted to authorized systems programming personnel.
• Access to application system documentation should be restricted to authorized applications programming personnel.
• Access to production software libraries should be restricted to library management personnel.
• Persons other than computer operators should not set up or operate the production computer.
• Only users, not computer staff, should be responsible for transaction origination or correction and for initiating changes to application files.
• Computer operators should not have access to program libraries or data files.

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.

• Data entry and verification of data,
• Data entry and its reconciliation to output,
• Input of transactions for incompatible processing functions (e.g., input of vendor invoices and purchasing and receiving information); and
• Data entry and supervisory authorization functions (e.g., authorizing a rejected transaction to continue processing that exceeds some limit requiring a supervisor's review and approval).

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:

• routinely duplicating or backing up data files, computer programs, and critical documents with off-site storage;
• installing environmental controls, such as fire suppression systems or backup power supplies;
• arranging for remote backup facilities that can be used if the entity's usual facilities are damaged beyond use; and
• ensuring that staff and other users of the system understand their responsibilities in case of emergencies.

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.

17. The areas from the FISCAM selected for inclusion in this report have been paraphrased.