| Return to the USDOJ/OIG Home Page |
Select Application Controls Review of the Federal Bureau of Prisons's Sentry Database System
Report No. 03-25
July 2003
Office of the Inspector General
| 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:
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 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 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.
We recommend the BOP Director ensure that BOP management:
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 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.
We recommend the BOP Director ensure that BOP management:
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. 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.
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.
We recommend the BOP Director ensure that BOP management:
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.
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.
We recommend the BOP Director ensure that BOP management:
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.
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.
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.
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.