SELECT APPLICATION CONTROLS

SELECT APPLICATION CONTROLS REVIEW OF THE FEDERAL BUREAU OF PRISONS'S SENTRY DATABASE SYSTEM U.S. Department of Justice Office of the Inspector General Audit Division Audit Report 03-25 July 2003 EFTA00122329 SELECT APPLICATION CONTROLS REVIEW OF THE FEDERAL BUREAU OF PRISONS'S SENTRY DATABASE SYSTEM EXECUTIVE SUMMARY SENTRY is the Federal Bureau of Prisons's (BOP) primary mission support database. The system collects, maintains, and tracks critical inmate information, including inmate location, medical history, behavior history, and release data. SENTRY processes over 1 million transactions each day and tracks more than 165,000 inmates. Roughly 85 percent of these inmates are housed within the BOP facilities, with the remaining inmates confined in other government facilities (state or local) or privately operated facilities through contracts with the BOP. As of March 2003, over 24,000 personal computers at approximately 200 facilities could access SENTRY. The purpose of this audit was to assess the application controls for the BOP's SENTRY database to determine whether inmate data entered in SENTRY is valid, properly authorized, and completely and accurately processed.' Our criteria for conducting the review was the Federal Information System Controls Audit Manual (FISCAM). 2 We reviewed the accuracy and timeliness of SENTRY's input, processing, and output controls and judgmentally selected 3 of the BOP's 29 Community Corrections Offices (CCO) to conduct onsite reviews of their operational workflow (Annapolis Junction, Maryland; Philadelphia, Pennsylvania; and Chicago, Illinois). These sites were selected because they process large volumes of inmate data into SENTRY. Our application review of SENTRY identified weaknesses in 4 of the 27 FISCAM control areas that we tested. We do not consider our findings in these areas to be major weaknesses and assessed SENTRY overall at a low risk to the protection of its data from unauthorized use, loss, or As part of our testing of the BOP's Annual Financial Statement for fiscal year 2002, we conducted a general control review of SENTRY's operating environment. General controls are the structure, policies, and procedures that apply to an entity's overall computer operations. If general controls are weak, they diminish the reliability of controls associated with individual applications. Our general control review identified weaknesses in one of the six general control areas that we tested (the system development/change control process). FISCAM was developed by the General Accounting Office (GAO) and describes the computer -related controls that should be considered when assessing the integrity, confidentiality, and availability of computerized data. According to FISCAM, both general and application controls must be effective to help ensure the reliability, appropriate confidentiality, and availability of critical automated information. See Appendix III for a detailed description of the FISCAM application control areas tested. EFTA00122330 modification. 3 Our findings were in the following four areas: • Supervisory reviews (input process), • Secured/restricted terminals (audit logs), • Limited transactions access control, and • Computer matching of transaction data. Specifically, we identified data input errors resulting in incorrect inmate offense/charge codes, incorrect inmate's commitment date, incorrect date of offense, and offense fines not entered into SENTRY. We also found that the BOP did not adequately monitor audit log exception reports. Moreover, our review of SENTRY's access controls disclosed that the combination of authorization profiles and terminal access authority did not function as required because users with limited access profiles were able to process transactions above their level of access when logged onto terminals designated for users with higher authorization. We also tested completeness controls and found that the BOP's SENTRY General Use Manual failed to include a required step while updating inmate information. We concluded that these weaknesses occurred because BOP management did not fully develop, document, or enforce the BOP policies in accordance with current Department of Justice (Department) policies and procedures. If not corrected, these security vulnerabilities could impair the BOP's ability to fully ensure the integrity, confidentiality, and availability of data contained in SENTRY. This report contains recommendations for improving application controls for SENTRY in the Findings and Recommendations section. In general, we recommend that BOP management ensure that: • The BOP's inmate data entry form is updated to reflect current BOP procedures and needs, • The BOP's "SENTRY System Security Guide," requires routine generation and review of exception reports, 3 The National Institute of Standards and Technology (NIST) defines risk as the possibility of harm or loss to any software, information, hardware, administrative, physical, communications, or personnel resource within an automated information system or activity. Additionally, NIST categorizes the information into three basic protection requirements of high, medium, and low in accordance to the system's sensitivity level. Specifically, low risk would be detrimental if the information is compromised causing minor loss and needing only administrative action. EFTA00122331 • Exception reports are provided timely to the Information Security Officer, • SENTRY's workstation controls are properly configured to access only authorized areas of the system, and • The BOP's SENTRY General Use Manual is updated to reflect proper procedures for entering initial records into SENTRY. The details of our work are contained in the Findings and Recommendations section of the report. Our objectives, scope, and methodology appear in Appendix I. iii EFTA00122332 TABLE OF CONTENTS Page BACKGROUND 1 SENTRY Database System Environment 3 FINDINGS AND RECOMMENDATIONS 5 I. Authorization Controls (Input) 5 Supervisory Reviews (Input Process) 6 Recommendations 8 Secured/Restricted Terminals (Audit Logs) 8 Recommendations 9 Limited Transactions (Access Controls) 9 Recommendation 11 II. Completeness Controls (Processing) 11 Computer Matching of Transaction Data 11 Recommendation 12 III. Accuracy Controls (Output) 12 IV. Controls Over Integrity of Processing and Data Files 12 CONCLUSION 13 OTHER REPORTABLE MATTER 15 APPENDICES: I. OBJECTIVES, SCOPE, AND METHODOLOGY 16 II. FEDERAL INFORMATION SYSTEM CONTROL AUDIT MANUAL APPLICATION CONTROL AREAS 17 EFTA00122333 III. APPLICATION CONTROLS REVIEW GUIDELINES 18 IV. SENTRY'S AUTHORIZED USERS LIST 36 V. ABBREVIATIONS 37 VI. DESCRIPTION OF SENTRY DATABASE MODULES 38 VII. APPLICATION CONTROL CRITERIA 41 VIII. THE BOP RESPONSE TO THE DRAFT REPORT 42 IX. OFFICE OF THE INSPECTOR GENERAL, AUDIT DIVISION, ANALYSIS AND SUMMARY OF ACTIONS NECESSARY TO CLOSE THE REPORT 45 EFTA00122334 SELECT APPLICATION CONTROLS REVIEW OF THE FEDERAL BUREAU OF PRISONS'S SENTRY DATABASE SYSTEM BACKGROUND SENTRY, the Federal Bureau of Prisons's (BOP) primary mission support database, processes more than 1 million transactions each day and provides data files to a number of external organizations, including the United States Pardon Attorney, United States Marshals Service (USMS), Federal Bureau of Investigation, and United States Parole Commission. The BOP deployed its SENTRY database in 1978. It currently assists in monitoring and tracking approximately 165,000 federal inmates. The system is designed to automate and assist in the monitoring of inmates consistent with implementation of the Violent Crime Control and Law Enforcement Act of 1994 (VCCLEA), 4 the Prisoner Litigation Reform Act (PLRA),5 and other laws, which may require special treatment of inmates within the BOP prison institutions. All inmate information, which is critical to the safe and orderly operation of BOP facilities, is collected, maintained, and reported within SENTRY. This information includes inmate institution assignment, inmate population, and sentence data. A diagram detailing the various SENTRY modules and a short description of each module follow. 4 The VCCLEA provided for new police offices, funding for prisons, and funding for prevention programs. 5 In April 1996, the PLRA was enacted by Congress as part of the Balanced Budget Down Payment Act, which limits the prospective relief that can be provided for prison conditions as well as terminates the existing orders for prospective relief unless a court finds that prospective relief remains necessary to correct a current or ongoing violation of a federal right. 1 EFTA00122335 SENTRY DATABASE MODULES AND DESCRIPTIONS 6 Inmate Population Monitoring - Tracks inmate movement in every BOP facility or while an inmate is in transit, regardless of location or time of day. --► State Billing - Tracks and reports amounts billable to individual states for inmates serving state sentences in BOP facilities. Financial Responsibility — Records, manages, and monitors court-ordered financial obligations imposed on an inmate. Inmate Discipline - Tracks every report of an infraction of institution rules filed against an inmate. Administrative Remedy - Automatically produces and routes inmate data needed to complete an internal investigation. Central Inmate Monitoring - Identifies inmates within SENTRY who require special handling. Designations - Assigns inmates to specific facilities. Sentence Monitoring - Calculates and tracks all aspects of an inmate's sentence. Source: The BOP's Information Technology Investment Report, March 1998. 6 SENTRY also includes a Property Management Module that tracks BOP's accountable property and automatically computes the depreciation of capitalized property; however it is not directly applicable to the Inmate Population Monitoring Module. 2 EFTA00122336 SENTRY Database System Environment SENTRY resides on a BOP mainframe 7 computer located at the Justice Data Center in Dallas, Texas (JDC-D) operated by the Department of Justice (Department) Justice Management Division's (JMD) Computer Services. Over 24,000 personal computers are in place - at approximately 200 facilities in the Department and BOP - to grant access to SENTRY by way of the BOP's Washington, D.C., Network Control Center (NCC).8 These remote sites include federal correctional facilities, regional offices, Community Corrections Offices (CCO), and other selected offices. The following diagram depicts SENTRY's network configuration: SENTRY Network Configuration SENTRY is housed on a mainframe computer at the )DC-D in Dallas, TX. Justice Data Center - Dallas, TX. DATA MAINFRAME Sprint Federal Telecommunications System (Fit) SENTRY applications are accessed by end-users, Department and BOP facilities through the BOP's NCC. } The Sprint FTS and local exchange carriers provide the communication links to SENTRY. The BOP's NCC Washington, D.C. Sprint Federal Telecommunications .>„ System (FTS) / Et al ;Sai4 SENTRY users Source: The Office of the Inspector General's (01G) analysis of the SENTRY Network Configuration. 7 A mainframe is a large system capable of handling tens of thousands of online terminals. Large-scale mainframes support multiple gigabytes of main memory and terabytes of disk storage. Large mainframes use smaller computers as front-end processors that connect to communications networks. 8 See Appendix IV for a listing of SENTRY's authorized users. 3 EFTA00122337 SENTRY utilizes a client/server application. This is a network architecture in which each computer or process on the network is either a client or a server. Servers are powerful computers or processes dedicated to managing disk drives, printers, or network traffic. Clients are personal computers (PCs) or workstations on which users run applications. Clients rely on servers for resources, such as files, devices, and even processing power. The client part of the program is referred to as the front-end processor and the server part is referred to as the back-end. SENTRY is comprised of approximately 700 program routines written in COBOL,9 which is used to process data to a database management system (DBMS). SENTRY allows concurrent sharing of data among multiple users. The DBMS maintains the indices that are necessary to translate application program data requirements into the information used by the mainframe's operating system to read or write data to SENTRY. The DBMS application used for SENTRY is the Computer Associate's (CA) Integrated Data Management System (IDMS). The IDMS's function is to process transmitted data between SENTRY and the mainframe operating system. The IDMS writes and retrieves data to and from the physical storage area of the mainframe when SENTRY is accessed. SENTRY communications are relayed by way of the BOP's Wide Area Network (WAN) circuits. The SENTRY mainframe is accessed by way of Systems Network Architecture (SNA) gateways, 1° which ensure that all SENTRY circuits include end-to-end encryption. Each BOP facility connects directly to the BOP's NCC via the Sprint Federal Telecommunications System (FTS) network. The Sprint FTS and the local exchange carriers provide the communication links for SENTRY. However, the BOP migrated its data communications to the Justice Consolidated Network (3CN),11 which also is implemented primarily through the Sprint FTS contract. The FTS currently provides intercity telecommunications services for federal government agencies. 9 10 COBOL (Common Business Oriented Language) is a popular high-level programming language used for business applications that runs on large computers. SNAs are IBM's mainframe network standards consisting of a centralized architecture with a host computer controlling many terminals. Enhancements have adapted SNA to today's peer-to-peer communications and distributed computing environment. Gateways perform protocol conversion between different types of networks or applications to facilitate communication between different systems. The OIG previously audited JCN (see OIG Audit Report Number 03-13, "Independent Evaluation Pursuant to the Government Information Security Reform Act," fiscal year 2002, the Justice Consolidated Network, February 2002). 4 EFTA00122338 FINDINGS AND RECOMMENDATIONS Our application review of SENTRY identified weaknesses in 4 of the 27 FISCAM control areas that we tested.12 In our judgment, these are not major weaknesses in SENTRY. We consider the system overall to be at a low risk to the protection of its data from unauthorized use, loss, or modification. Specifically, we found weaknesses in the areas of supervisory reviews (input process), secured/restricted terminals (audit logs), limited transactions for access controls, and computer matching of transaction data. We concluded that these weaknesses occurred because BOP management did not fully develop, document, or enforce the BOP policies in accordance with current Department policies and procedures. If not corrected, these weaknesses could impair the BOP's ability to fully ensure the integrity, confidentiality, and availability of data contained in SENTRY. I. Authorization Controls (Input) Authorization controls involve the process of granting or denying access to a network resource, converting the data to an automated form, and entering the data into the application in an accurate, complete, and timely manner. Testing of authorization controls includes examining the data input process and determining if controls exist for ensuring: • Data are authorized prior to being entered; • Access restrictions exist to prevent unauthorized personnel from obtaining blank source documents to record unauthorized information and insert the document into production with authorized documents; • Supervisory or independent reviews of the source document occurs before its data is entered into the automated system; • Data entry terminals are only accessible to authorized users for authorized purposes; 12 Although we performed a full application review of SENTRY, this audit report does not include an evaluation of SENTRY's general controls. As part of the OIG's Federal Bureau of Prisons Annual Financial Statement for fiscal year 2002, we evaluated the general controls over select SENTRY systems. In that report, weaknesses were identified in the area of application software development/change control, which represents one of General Accounting Office's (GAO) six FISCAM general controls. 5 EFTA00122339 • Users are limited to what transactions they can enter; • Master files are configured to assist with identifying unauthorized transactions; • Exception reports are generated and reviewed before transactions are posted; and • Duties are appropriately segregated among staff. Our audit of the BOP's authorization controls for SENTRY found that authorization controls were in place within the areas of controlled and authorized source documents; 13 unauthorized transactions; and reported exceptions. However, we identified weaknesses with respect to SENTRY's input process, review of audit logs, and access controls. Supervisory Reviews (Input Process) During the input process, a supervisory (or independent) review of the data should occur before it is entered into the automated system. This control is used to ensure that unauthorized transactions are not being entered and that exceptions are reviewed and corrected before transactions are posted. Since SENTRY is used for collecting, maintaining, and reporting inmate information vital to the operation of the BOP facilities, it is critically important to maintain the integrity and quality of the data that lies within it. The BOP's Information Technology Investment Report (Section 2.2), dated March 1998, requires accurate entry of data to help provide assurance that data integrity is being maintained. We performed survey work of the BOP's mandatory procedures for SENTRY's input process at one field office (Chicago, Illinois), and we performed detailed testing at two regional offices (Philadelphia, Pennsylvania; and Annapolis Junction, Maryland). To review for authorization and correct entry into SENTRY, we selected a total of 48 inmate files from the Philadelphia and Annapolis Junction offices. From each case file, we examined the mandatory source documents (the Court's Judgment and Commitment Order (J&C), the USMS Judgment and Individual Custody and Detention Report,14 and the United States Probation Office's pre-sentence investigation report) and compared them to the information 13 Controlled and authorized source document controls are implemented to ensure that access to blank documents is restricted to authorized personnel. 14 This form is referred to as Form USM-129. 6 EFTA00122340 entered into SENTRY. These three source documents are received by the CCO and are used to complete the initial processing of an inmate assignment. 15 We selected a total of 23 case files for review at the BOP's Philadelphia CCO. Two of the 23 case files identified data entry errors. One case file contained an incorrect "offense/charge code" ("391") for "attempt and conspiracy" versus a correct code ("381") for "create, manufacture, distribute or dispense controlled narcotic drug." The second case file revealed an incorrect inmate's commitment date. A source document (J&C) showed a commitment date of "09/19/02," yet the date entered in SENTRY's database was "09/18/02." At the BOP's Annapolis Junction CCO, we reviewed 25 case files. We identified data entry errors for three case files. At this office, we again found an inmate "description of offense" code incorrectly entered. In this case, an incorrect offense code of "381" was entered instead of the code "382" "marijuana charge" as indicated on the source document (PSI report). Additionally, we found a different inmate's record was entered in SENTRY with an incorrect "date of offense." The source document (J&C) contained only the month and year. However, the date entered into SENTRY was "12-31-1999." Lastly, some information contained in an inmate's case file was not entered into SENTRY. The source document (J&C) indicated that the inmate paid offense fines of $500 and assessments fines of $50. However, this information was not entered in the "Felony Assessment & Fines" data fields in SENTRY. The errors identified above were disclosed to the BOP and corrected in the presence of our auditors. While the input errors we identified were relatively minor, they represent a weakness in internal controls because the severity of an input error could result in a more serious outcome. For example, the repercussions of an incorrect offense/charge code could result in transporting an inmate to an inappropriate facility. In our judgment, these errors occurred because: 1) the BOP does not enforce the use of the BOP's form BP-337 as a primary document for inputting data into SENTRY, and 2) the BOP's primary form BP-337 does not identify which source documents are to be used to complete mandatory information into SENTRY. Additionally, the multiple source documents used to complete the BP-337 sometimes contain conflicting information or lack mandatory information. Since the BOP Community Corrections Management 15 The BOP transfers information obtained from the courts, the USMS, or other law enforcement documents to a single document (the Male/Female Inmate Load and Designations Form BP-337). The BOP uses the BP-337 as the source document for entering consolidated data into SENTRY. 7 EFTA00122341 Operational Procedures, Policy Standards (PS) 5100.07, does not require the BP-337 to be completed for all data input into SENTRY from a single source document (or state which source document should be used to complete the various sections of the BP-337), this causes confusion as to which source document to use to obtain the mandatory information. Recommendations: We recommend the BOP Director ensure that BOP management: 1. Enforce the BOP (PS) 5100.07, which states that all CCOs are to use the BP-337 for inputting initial inmate data as the sole source document. 2. Redesign the BP-337 so that mandatory information needed for tracking BOP inmates can be documented. 3. Modify the BP-337 to indicate which source document should be used to complete each field within this form. Secured/Restricted Terminals (Audit Logs) Audit logs (commonly known as audit trails) maintain a record of activity by system or application processes. Audit logs provide a means to help establish several security-related objectives, including individual accountability, reconstruction of events, intrusion detection, and problem identification. Automated controls, such as an audit log that produces exception reports, help to ensure data integrity and can alert management to possible misuses of the system. We found that the BOP end-users and management depend on manual verification of transactions by performing cross-edit checks of source documents to verify data integrity and completeness of transactions entered into SENTRY. Currently, the BOP tracks all of SENTRY's input and output activities through an automated audit log, which contains system data such as the identity of the person and device having access to the database, the date and time of user logon/logoff activities, and data processed. At present, the BOP uses these audit logs for the sole purpose of monitoring SENTRY's operational performance. Although the SENTRY audit logs used to monitor system performance are capable of generating ad hoc exception reports, the BOP does not 8 EFTA00122342 routinely produce these reports from the logs. Additionally, we found that the BOP's "SENTRY System Security Guide," dated June 23, 2000, does not require a periodic review of exception logs. Without requiring a periodic review of audit logs, unauthorized activities can go unnoticed, uninvestigated, or unresolved. Department of Justice Order 2640.2D, Chapter 2, "Security Requirements" (Accountability and Audit Trails), requires that audit logs be maintained and reviewed for activities that could modify, bypass, or negate the system's security safeguards. In our judgment, these weaknesses exist because the BOP failed to implement a process for routinely identifying exceptions using audit logs. Recommendations: We recommend the BOP Director ensure that BOP management: 4. Update the BOP's "SENTRY System Security Guide," dated June 23, 2000, to require the routine generation and review of exception reports; and 5. Provide the Information Security Officer with the exception reports generated from the audit logs in the time period specified by the BOP's "SENTRY System Security Guide." Limited Transactions (Access Controls) Limited transaction controls restrict the access of legitimate users to the specific systems, programs, and files needed to complete work assignments and to prevent unauthorized users from gaining access to computing resources. Limiting transactions include utilizing system access controls and ensuring assigned personnel duties are properly segregated. Access controls are designed to limit or detect access to computer programs, data, and equipment to protect these resources from unauthorized modification, disclosure, loss, or impairment. They also serve as a key control for ensuring that staff duties and responsibilities are implemented in a way that safeguards programs. Logical access controls involve the use of computer hardware and security software programs to prevent or detect unauthorized access by requiring users to input unique user identifications, passwords, or other identifiers that are linked to predetermined access privileges. Additionally, controls are designed to reduce the risk of errors or fraud from occurring and going undetected. 9 EFTA00122343 Policies outlining the supervision and assignment of responsibilities to groups and related individuals should be documented, communicated, and enforced. Such controls keep individuals from subverting a critical process. The BOP's "SENTRY System Security Plan," dated February 25, 2000, requires restricting access to SENTRY through the use of software and hardware profiles. The BOP access controls are intended to implement two lines of defense — one at the application level, the other at the workstation level. The use of a user identification/password requires validation and authentication at the application level. At the workstation level, workstations are configured to identify their location and authorization functional capabilities to SENTRY's system platform. Additionally, each workstation is required to be configured in a manner that limits access to SENTRY according to users' identification and profiles. These limitations are required to restrict access to menus, fields, and records within SENTRY. According to the BOP's Information Technology Investment Report, dated March 31, 1998, some transactions also require SENTRY users to utilize special access codes in addition to their user identification/password. Our review of SENTRY's access controls disclosed that the combination of authorization profiles and terminal access authority did not function as required. Users with limited access profiles were able to process transactions above their level of access when logged onto terminals designated for users with higher authorization. This control weakness was identified when a user was requested to demonstrate the BOP's access controls in place. The user logged onto his assigned workstation and was unable to access inmates' restricted medical records. However, when the same user logged onto a different workstation assigned to another user with higher authorization, the user was granted access to sensitive medical records without proper authorization. Additionally, our audit disclosed that the BOP does not have documentation defining who should have access to sensitive medical records. At the time of our audit, we found that a Community Corrections Trainee was permitted to view an inmate's sensitive medical history records within SENTRY. Duties that are not appropriately segregated significantly increase the risk of releasing private information. For SENTRY workstations that are configured to operate at a high level of security, access controls should be in place to prevent users with lower levels of authorization from accessing restricted data. The failure to ensure that access controls are properly implemented could cause critical mistakes such as modifications of inmates' medical records, transfer records, or release dates. 10 EFTA00122344 Department of Justice Order 2640.2D requires access controls to ensure system users can only access the resources necessary to accomplish their duties and no more. Additionally, OMB Circular A-130 requires agencies to implement the practice of "least privilege," whereby user access to systems is restricted to the minimum level possible. Recommendation: We recommend the BOP Director ensure that BOP management: 6. Enforce the BOP's existing access control policy by properly configuring SENTRY's workstation controls to ensure that users with system authorization are restricted to areas of the system that they have been authorized to access, and no more. II. Completeness Controls (Processing) Completeness controls are designed to ensure that all authorized transactions are processed and completed prior to being entered into the computer. These controls include the use of record counts and control totals, computer sequence checking, computer matching of transaction data with data in a master or suspense file, and checking of reports for transaction data. Our audit of the BOP's completeness controls for SENTRY found controls were in place for record counts and control totals, computer sequence checking, checking reports for transaction data, completeness of data processed in the processing cycle, and completeness of data processed for the total cycle. However, we identified weaknesses with respect to SENTRY's computer matching of transaction data. Computer Matching of Transaction Data The BOP's Community Corrections Management Operational Procedures, Policy Standards 1237.12 requires all systems, whether automated or manual, to quickly, accurately, and reliably provide information. Additionally, it requires that only authorized and accurate information be entered into databases. When incorrect transactions are processed, controls should be in place to ensure that these items are investigated and resolved in a timely manner. 11 EFTA00122345 We tested the BOP's completeness controls for SENTRY and found that the BOP's SENTRY "General Use Manual" (GUM) did not reflect current system settings. The manual provides instructions for inputting initial inmate records into SENTRY. However, when we attempted to simulate the addition of a new inmate into SENTRY (by following instructions indicated in the GUM) we noted that the manual failed to include the required step of updating an inmate identification number screen prior to initiating the addition of an inmate. Recommendation: We recommend the BOP Director ensure that BOP management: 7. Update SENTRY's General Use Manual to reflect proper procedures for entering initial inmate records into SENTRY. III. Accuracy Controls (Output) Accuracy controls are implemented to ensure that data recording is valid and accurate in order to produce reliable results. The implementation of these controls includes procedures that are well designed for data entry, easy to follow data entry screens, limit and reasonableness checks, and validation of override actions for appropriateness and correctness. Without accuracy controls, invalid data may enter the system and produce unreliable results. Our testing of the BOP's SENTRY accuracy controls confirmed that controls were in place for source documents, preformatted screens, key verification, automated entry devices, programmed validation, tests of critical calculations, restricting overriding data validation, controlled rejected transactions, reported of erroneous data, control output, and review of processing reports. IV. Controls Over Integrity of Processing and Data Files Controls over integrity of processing and data files are used to ensure that the current version of production programs and data files is used during system processing. The implementation of these controls includes: (1) executing program routines that can verify the proper version of computer files, (2) protecting against concurrent file updates, and (3) checking for internal file header labels to prevent the system end-user from bypassing system controls. 12 EFTA00122346 The NIST Federal Information Processing Standards Publication 73, Section 3.1.3, states that checking of input data during processing and validation of data that is generated by the application system are essential for assuring data integrity. Errors should be detected and corrected as soon as possible in order to prevent the propagation of invalid data throughout the system and the potential contamination of the system database. We confirmed that controls were in place for SENTRY to check for the appropriate program. BOP end-users are only permitted access to the production environment and are locked into the production software version of SENTRY. Further, we found that record locks were in place within the database disallowing two end-users from updating the same record simultaneously. Finally, we found that SENTRY is not updated through batch processing, therefore, a test to determine whether SENTRY programs can or cannot bypass file header labels did not apply. CONCLUSION Our application review of SENTRY identified weaknesses in 4 of the 27 FISCAM control areas that we tested. We do not consider our findings in these areas to be major weaknesses, and we assessed SENTRY overall at a low risk to the protection of its data from unauthorized use, loss, or modification. 16 Application control weaknesses were identified in the areas of supervisory reviews, audit logs, access controls, and computer matching of transaction data. Specifically, we identified weaknesses in the inputting of incorrect offense/charge codes, incorrect inmate's commitment date, incorrect date of offense, and offense fines not entered into SENTRY. These input errors represent a weakness in internal controls that should be corrected. We also found that the BOP failed to monitor audit log exception reports. Without requiring a periodic review of audit logs, unauthorized activities could go unnoticed, uninvestigated, or unresolved. Moreover, our review of SENTRY's access controls disclosed that the combination of authorization profiles and terminal access authority did not function as required. Users with limited access profiles were able to process transactions above their level of access when logged onto terminals designated for users with higher authorization. We also tested the completeness of controls for SENTRY and found that the BOP's SENTRY GUM failed to include a required step while updating inmate information. 16 Although we performed a full application review of SENTRY, this audit report does not include an evaluation of SENTRY's general controls. As part of the OIG's Federal Bureau of Prisons Annual Financial Statement for fiscal year 2002, we evaluated the general controls over select SENTRY systems. In that report, weaknesses were identified in the area of application software development/change control, which represents one of the six FISCAM general control areas. 13 EFTA00122347 We concluded that these weaknesses occurred because BOP management did not fully develop, document, or enforce the BOP policies in accordance with current Department policies and procedures. If not corrected, these weaknesses could impair the BOP's ability to ensure the integrity, confidentiality, and availability of data contained in SENTRY. 14 EFTA00122348 OTHER REPORTABLE MATTER OMB Circular A-130, Appendix III, Section A 3.b.2 (d), requires that a contingency plan be established and periodically tested to perform the agency function supported by the application in the event of failure of its automated support. GAO's FISCAM recommends the frequency of contingency plan testing should vary depending on the criticality of the entity's operations. Additionally, FISCAM states that generally, contingency plans 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 personnel has occurred. Industry best practices are more stringent and indicate that a new or revised contingency plan should be fully tested and implemented within 90 days of development. 17 Although testing of contingency planning was not part of the FISCAM's application control testing that we performed, 18 we noted during our review that SENTRY's contingency plan was last updated in September of 2002 but was not tested. Prior to the issuance of this report, we confirmed with the BOP that testing of the BOP's SENTRY contingency plan was performed on March 27, 2003, and the plan was in the review process. We suggest that BOP continue to test its contingency plan and update the plan as circumstances warrant. We also contacted the JMD regarding this matter. JMD informed us that the Department's standards (Department of Justice Order 2640.2D) are currently being modified to reflect the industry best practice of the 90-day requirement for testing contingency plans. We agree with JMD in implementing this more stringent requirement. " Department of Justice Order 2640.2D, Chapter 1, "Security Program Management," Section 9(c) requires that contingency plans be tested annually or as soon as possible after a significant change to the environment that would alter the in-place assessed risk. 1B Contingency planning is a FISCAM general control. 15 EFTA00122349 APPENDIX I OBJECTIVES, SCOPE, AND METHODOLOGY Our audit objectives were to review the application controls for the BOP's SENTRY database and determine whether inmate data entered in SENTRY are valid, properly authorized, and completely and accurately processed. 19 In order to meet these objectives, we tested SENTRY application controls using the GAO's FISCAM, which divides the testing of application controls into four major areas: authorization controls (input), completeness controls (processing), accuracy controls (output), and controls over integrity of processing and data files. For testing of SENTRY's application controls, we judgmentally selected 3 of the 29 CCOs to conduct onsite reviews of their operational workflow — Annapolis Junction, Maryland; Philadelphia, Pennsylvania; and Chicago, Illinois. These CCOs were judgmentally selected because they process large volumes of inmate data into SENTRY. Furthermore, we performed reviews of source documents at the three CCO offices to test input, process, output, and data integrity controls. In addition to the testing performed at the selected CCOs, we interviewed approximately 40 BOP officials. These interviews included the BOP managers and officials from the Computer Services Administration, Mainframe Systems Support, Systems Development Branch, Policy and Information Resource Management, Office of Information Systems, and Community Corrections. Additionally, we reviewed application, operation, and end-user manuals; the BOP's and Department information technology management policy and procedures; the BOP's project management guidance; the BOP's organizational structures and federal court cases; and prior GAO and OIG reports specific to SENTRY. Findings identified at the time of fieldwork were communicated to the BOP to initiate corrective action. All audit work was performed in accordance with Government Auditing Standards and were based on the GAO's FISCAM, the BOP's Standard Operating Procedures, and federal laws and regulations governing inmate processing within the BOP facilities. 39 Although we performed an application controls review of SENTRY, this audit report does not include an evaluation of SENTRY's general controls. As part of our testing of the BOP's Annual Financial Statement for fiscal year 2002, we conducted a general control review of SENTRY's operating environment. That general control review identified weaknesses in the area of system development/change control, which represents one of the six FISCAM general control areas. 16 EFTA00122350 APPENDIX II FEDERAL INFORMATION SYSTEM CONTROL AUDIT MANUAL APPLICATION CONTROL AREAS Authorization Controls (Input) VULNERABILITIES Data are authorized 1. Controlled and authorized source documents 2. Supervisory reviews (Input process) 'I Restricted terminals 3. Secured/restricted terminals (Audit logs) 4 4a. Limited transactions (Access controls) 4 4b. Limited transactions (Segregation of duties) Master files/Exception Reporting 5. Unauthorized transactions 6. Retorted exce.tIons Completeness Controls (Processing) Computer processed transactions 7. Record counts and control totals 8. Computer sequence checking 9. Computer matching of transaction data 10. Checking reports for transaction data Reconciliations 11. Completeness of data processed in the processing cycle. 12. Com leteness of data •rocessed for the total c cle. • ccur • cy C. ntr. • ut. Data entry design 13. Source documents 14. Preformatted screens 15. Key verification 16. Automated entry devices Data validation 17. Programmed validation 18. Tests of critical calculations 19. Restricted overriding data validation Erroneous data 20. Controlled rejected transactions 21. Reported erroneous data Output reports 22. Control output 23. Review of . rocessin. retorts Controls over Integrity of Processing and Data Files 24. Current versions of production programs and data files 25. Routine to verify proper version 26. Routine for checking internal file header labels 27. Protection against concurrent file updates 17 EFTA00122351 APPENDIX III APPLICATION CONTROLS REVIEW GUIDELINES GENERAL ACCOUNTING OFFICE FEDERAL INFORMATION SYSTEM CONTROL AUDIT MANUAL The application control guidelines used for this audit were obtained from the GAO's FISCAM. The information below details the sections from the FISCAM used during our review of SENTRY. OVERVIEW Application controls are the structure, policies, and procedures that apply to separate, individual application systems, such as accounts payable, inventory, payroll, grants, or loans. An application system is typically a collection or group of individual computer programs that relate to a common function. In the federal government, some applications may be complex comprehensive systems, involving numerous computer programs and organizational units, such as those associated with benefit payment systems. For the purposes of this document, application controls encompass both the routines contained within the computer program code, and the policies and procedures associated with user activities, such as manual measures performed by the user to determine that data were processed accurately by the computer. Application controls help make certain that transactions are valid, properly authorized, and completely and accurately processed by the computer. They are commonly categorized into three phases of a processing cycle: • Input - data are authorized, converted to an automated form, and entered into the application in an accurate, complete, and timely manner; • Processing - data are properly processed by the computer and files are updated correctly; and • Output - files and reports generated by the application actually occur and accurately reflect the results of processing, and reports are controlled and distributed to the authorized users. 18 EFTA00122352 Some guides provide additional categories of application controls. For example, data origination is a breakout of input it controls to focus on source documents and their need for authorization and proper preparation and control. Also, data storage and retrieval focuses on access to and use of data files and protecting their integrity. Instead of using the phases of a processing cycle, this document uses control categories that better tie in with the Specific Control Evaluation Worksheets (SCE) found in the FISCAM. The SCE is used to document the controls evaluation and is prepared for each significant accounting application. Included on the SCE are columns for recording the control objectives and control techniques being evaluated and accuracy including whether the assertion and related transactions are authorized, complete, valid, and accurate. The control objectives and techniques addressed in this chapter are consistent with other guidance, but our categorization, tying to the SCE, are the following: • Authorization controls - aligns with the financial statement accounting assertion of existence or occurrence. This assertion, in part, concerns the validity of transactions and that they represent economic events that actually occurred during a given period. • Completeness controls - relates to the financial statement accounting assertion on completeness, which deals with whether all valid transactions are recorded and properly classified. • Accuracy controls - relates with the financial statement assertion on valuation or allocation. This assertion deals with whether transactions are recorded at correct amounts. The control category, however, is not limited to financial information, but also addresses the accuracy of other data elements. • Controls over integrity of processing and data files - if deficient, could nullify each of the above control types and allow the occurrence of unauthorized transactions, as well as contribute to incomplete and inaccurate data. AUTHORIZATION CONTROLS Only authorized transactions should be entered into the application system and processed by the computer. Assessing authorization controls involves evaluating the entity's success in performing each of the following critical elements: 19 EFTA00122353 Critical Elements: • All data are authorized before entering the application system. • Restrict data entry terminals to authorized users for authorized purposes. • Master files and exception reporting help ensure all data processed are authorized. Data should be authorized before it is entered into the application system. Federal financial management systems are often characterized as large complex 'legacy' systems and often involve a multitude of documents that flow through various work steps. Paper source documents still play a significant role for originating data that enter application systems in the federal government. These source documents should fall under control measures so that unauthorized transactions are not submitted to and processed by the application. Also, data whether from a source document or not should undergo an independent or supervisory review prior to entering the application. Source documents are controlled and require authorizing signatures. Control over source documents should begin even before data is recorded on the document. Access restrictions over blank source documents should prevent unauthorized personnel from obtaining a blank source document, recording unauthorized information, and inserting the document in the flow with authorized documents and possibly causing a fraudulent or malicious transaction to occur. Use of pre-numbered source documents could help identify unauthorized documents that fall outside the range of authorized numbers for documents being prepared for data entry. Key source documents for an application should require an authorizing signature, and the document should provide space for the signature by an authorized official. For batch application systems - i.e., source documents are processed in batches - the source documents should be collected together and a batch control sheet should be prepared for individual batches. The control sheet should have space for recording the date, a batch control number, the number of documents in the batch, a control total for a key field in the documents, and the identification of the user submitting the batch. Establishing control over batches helps detect unauthorized modifications to 20 EFTA00122354 a document and prevents unauthorized documents from being entered into the application system. The document counts and control totals also help to determine whether all transactions are completely entered and processed by the computer. The following sections are also important to ensuring all transactions are authorized, particularly when the application system is designed such that transactions are entered individually instead of in batches. Supervisory or independent reviews of data occur before entering the application system. Providing supervisory or independent review of data before entering the application system helps prevent the occurrence of unauthorized transactions. A data control unit is effective for this purpose and this function has evolved as technology has advanced. With earlier sy