Review of the United States Marshals Service's Prisoner Tracking System
Report No. 04-29
Office of the Inspector General
The USMS's response to the audit (Appendix 12) describes the actions taken or plans for implementing our recommendations. In some cases, we made revisions to our final report where appropriate. This appendix summarizes our response and the actions necessary to close the report. In addition to responding to the recommendations the USMS stated in the second paragraph of the cover memorandum "For purposes of accuracy, please note that Page 1 of the report includes dollar figures ascribed to PTS, with Footnote 7 reporting these figures to be derived from budget requests submitted to OMB and JMD. These figures are not consistent with what USMS has submitted through the budget process. We are at OIG's disposal to discuss the figures reported and provide the information we believe to be accurate."
We requested operating cost information for the PTS on two occasions from USMS representatives prior to the issuance of the PTS draft report. On the first occasion, February 24, 2004, we sent a written request to the USMS Planning and Analysis Branch requesting budget information. During our second attempt on February 25, 2004, we sent a request to a USMS IT Services representative who replied that he had "passed the request on to the USMS budget people." We informed the USMS that this information would be used in the draft report and that the request was time sensitive since we were in the final stages of writing the draft report. Because we were not provided with information from either of the USMS contacts, we contacted the Justice Management Division to determine if any historical budget information existed in their files. On March 8, 2004, the Justice Management Division provided the information used in the report. According to JMD's representative, "The official source of the information are exhibit 300 or 53 reports prepared by the component that are on file in our office." Therefore, the OIG did not dispute the accuracy of the information since we were informed that it originated from the USMS.
Because the USMS expressed concern that the costs provided by the JMD were not accurate, we again contacted the USMS on July 12, 2004, to obtain the operating costs the USMS believed to be accurate for PTS. On July 21, 2004, the USMS provided an email containing cost information for which we subsequently requested the supporting documentation such as an exhibit 300 or 53 report. However, the USMS could not provide any supporting budget documentation to substantiate the figures it provided. Therefore, the operating cost information previously provided by JMD will remain in the report as the official and best available data for the PTS.With respect to our recommendations, the USMS frequently disagreed or the corrective action proposed by the USMS was not sufficient to address our recommendations. For these reasons, recommendations 3, 4, 5, 6, 8, 9, 10, 12, 13, 14, 17, and 18 are Unresolved. The status of each recommendation follows:
|1.||Closed. The USMS provided a copy of a signed memorandum dated April 30, 2004, designating an Information Systems Security Officer (ISSO) for the PTS. As a result of the USMS actions, we consider this recommendation closed.|
|2.||Resolved. The USMS states that the future Justice Detainee Information System (JDIS) will include a training module for the PTS application. To close this recommendation, the USMS should provide milestones for its implementation to us with evidence that the training module for PTS is or has been developed.|
Unresolved. The USMS requested additional information pertaining to which system administrators lacked adequate training and expertise regarding their knowledge of the PTS's hardware and software environment. The USMS believed that this finding was noted because the OIG may have interviewed the wrong personnel.
As we stated at our exit conference with the USMS, in planning our site visits, we first contacted each affected district office and requested the following individuals be made available for meetings or interviews: the U.S. Marshal (or designee), system administrator, and criminal clerk. At the Eastern District of Virginia, we were directed to an individual whom we were told was performing system administrator duties. As the interview progressed, however, we learned that the individual was performing some system administrator duties, but that the system administrator responsible for the site was physically located at the District Court for the District of Columbia. While at the Eastern District of Virginia, we gathered the information this individual could provide and subsequently interviewed the responsible system administrator. We did not, however, interview the administrative officer in lieu of the system administrator. Rather, we were initially misdirected and subsequently spoke to the system administrator responsible for the office. When we spoke to the system administrator who represented the site in question, we still found deficiencies with the system administrator's knowledge.
As stated in the final report, the system administrator position description provided by the USMS states that system administrators are responsible for "operating, troubleshooting, repairing, and maintaining IT systems." Additionally, the position description states that employees must possess the requisite technical knowledge to sustain the availability of the hardware and software environment and be competent to maintain operating systems, applications, and data elements. According to the USMS headquarters, system administrators within the district offices are responsible for adding and deleting user names from the PTS authorized user list. However, we found specific problems at the sites indicated below:
When we requested to speak to the system administrator at the Eastern District of Virginia, we were directed to the administrative officer. The administrative officer was performing cursory system administrator duties and he did not know where the PTS database for the district office was located. We subsequently interviewed the system administrator, whom we located at the District Court for the District of Columbia, and found that she did not know how to delete names from the user list, among other things.
The areas identified in the previous chart represent facets of requisite technical knowledge that enable system administrators to effectively sustain the availability of the hardware and software environment and demonstrate competence in maintaining operating systems, applications, and data elements.
In order to resolve and close this recommendation, the USMS should provide documented evidence to us that individuals performing system administrator duties are properly trained in their responsibilities.
Unresolved. The USMS's response asserts that there is no Department or federal security requirement to maintain user lists at both the USMS district offices and at USMS headquarters. The USMS response does not address our recommendation. Our recommendation speaks to the condition that the PTS authorized user list provided by the USMS headquarters contained information that, once verified at the site, possessed multiple inaccuracies. Appendices 5 and 6 of this report contain excerpts from Chapters 3 and 4 of the GAO's FISCAM, which we used as guidance for the development of the audit program followed during the audit. Pages 54 through 55 of the final report provide the specific FISCAM requirement that the computer resource owner should maintain a current list of authorized users and ensure that their access is authorized. We did not recommend that separate lists be maintained. Separate lists exist because the USMS headquarters has delegated the user management responsibility to the district offices (DOs). This does not absolve the USMS headquarters from its responsibility as data owners to maintain a current list of authorized users and ensure that their access is authorized.
Additionally, the Department's Order 2640.2E requires that each authorized user of a system have a unique identifier. In the case of the authorized user list provided by USMS headquarters, entries were found to be outdated and did not reflect a replication of changes, additions, and deletions made at the district offices we visited. Our report details the nature and frequency of errors found during our user list review at each site. In order to resolve and close this recommendation, the USMS should provide evidence to us that the access authorizations for the PTS are reviewed and that USMS headquarters updates its authorized PTS user list in a timely manner to incorporate changes from the DOs.
Unresolved. As we stated at our exit conference, we found that the lock on the door to the office suite containing data terminals, prisoner file folders, printed output reports, and other sensitive information was not engaged at the District Court for the District of Columbia location. During our visit, we were able to gain access to this area from the hallway in a building accessed by the public, and at the time, no one assigned to the district office was present in the area. Although physical security is provided at the entrance to the building, private citizens are unescorted once they enter the building, which presents a serious threat to the protection of sensitive information. We agree that this condition occurred at only one of the eight sites reviewed. However, we found that the means for providing adequate physical security was present and a lock was on the door. Unfortunately, the office failed to exercise due diligence to ensure its use. Additionally, this condition was in sharp contrast to the high levels of security observed at the other seven sites visited. In order to resolve and close this recommendation, the USMS should provide us with documented evidence that existing measures, such as door locks, are used to provide protection against unauthorized access to sensitive areas.
Unresolved. The USMS response states that system change request instructions for the PTS application have been sufficiently disseminated to users of the application. The USMS headquarters informed us prior to our site visits of the systems development life cycle (SDLC) process in place that contains system change request instructions. Although the USMS feels that users have been sufficiently notified of existing policies, our observations proved different. As stated previously, we followed an audit program in which identical questions were asked of individuals representing specific positions within the district office. Specifically, we asked those most familiar with the application, the criminal clerk and the system administrator, how changes were requested to the PTS application. We found at all eight of the locations visited, the Eastern District of Virginia; the District Court for the District of Columbia; the Eastern District of Pennsylvania; the Southern District of New York; the Southern District of Texas; the Northern District of Illinois; the Southern District of Florida; and the District of Arizona, that knowledge of the official change control process for the PTS application was deficient. In most cases, neither the system administrator nor the criminal clerk were aware of the existence of a change request form or how to process a request according to the existing policy.
Also in the USMS's response to recommendation 6, the USMS states that the audit report text does not substantiate the information in the last paragraph of page 12 of the draft report where the discussion of the ineffective management of modifications to application software is expanded to include unauthorized changes made by knowledgeable programmers. On page 16 of our report, we state that, "At the USMS's headquarters, only one individual is assigned to code, test, and implement changes to the PTS application." This example substantiates the audit report text because according to the Department's Order 2640.2E, components are directed to integrate security into various stages of a system's life cycle and to ensure that changes to any system are controlled. Changes to a system include changes requested by users as well as changes made by knowledgeable programmers. We presented this information on page 16 under Segregation of Duties because it represented a good example of failure to segregate duties among staff although it also applies to the ineffective management of modifications to application software. We disagree that this vulnerability should be excluded from the report. In order to resolve and close this recommendation, the USMS should provide documented evidence to us that PTS users are informed of the policies and procedures for requesting changes to the application.
|7.||Resolved. The USMS states that it has taken steps through the development of JDIS to address the problem of PTS's outdated programming software and database management system. In order to close this recommendation, the USMS should provide documented evidence to us that the outdated versions of the PTS's application programming software and database management system have been removed from the production environment and replaced with current versions that are supported by the vendor.|
Unresolved. The USMS provided an attachment to its response to demonstrate that duties have been segregated to minimize functional incompatibility. The attachment lists duties for positions within the USMS such as end users, system administrators, and the information systems security officer as they relate to computer security. While valuable, the information only partially addresses the conditions described on pages 15 through 17 of the report that enumerate problems with procedures that affect critical processes performed by the PTS application's end users and the application programmer.
In this report, we provide the FISCAM guidance under the "Segregation of Duties" section that requires entities not only to segregate incompatible duties, but also to establish related policies. We also provide FISCAM guidance that requires entities to control personnel activities through formal operating procedures and supervision and review. Our recommendation applies to our observations during field site visits that duties were not sufficiently segregated among staff and that sufficient procedural guidance does not exist for the record creation process. Specifically, district office operations allow an end user to create a prisoner record, manipulate that record, and commit changes to information contained in the PTS database with no management oversight or approval prior to the completion of a transaction, or shortly thereafter. This condition creates the situation where a single individual has complete control over the input, processing, and output stages of the information cycle. We also provided the example of the condition existing at USMS headquarters wherein one individual can code, test, and implement software changes thereby having complete control over the PTS's system life cycle.
We have reviewed the information provided as Attachment 2 to the USMS response. The additional procedural steps added to the Cellblock Operations Manual 99-47 address the conditions described in this report pertaining to controlling personnel activities through formal operating procedures. However, none of the information provided ensures that duties affecting the application's life cycle are sufficiently segregated or that supervisory review of data is assigned to anyone at the district office level. In order to resolve and close this recommendation, the USMS should provide to us documented evidence that policies and procedures for segregating duties are developed and enforced to provide assurance that distinct functions are performed by different individuals and that no individual has complete control over the PTS's processing functions.
Unresolved. The USMS contends that system administrators are fully aware of required actions and responsibilities in the event of an emergency situation and the USMS requested that we provide specific examples of where this may not be accurate. We reviewed both the USMS system security plan for the PTS application and the contingency plan for the application in order to gain an understanding of emergency procedures in place to protect the application and minimize service interruptions. We found that emergency procedures and contact information established for the PTS application are contained in the contingency plan for the application; however, the USMS headquarters confirmed that it had not disseminated the contingency plan to the district offices. We found that none of the system administrators at the sites had been provided a copy of the contingency plan containing emergency procedures and contact information. In addition, we found that the USMS has not tested the contingency plan for PTS to actually verify that employees can perform their necessary duties in the event of an emergency. We found the following conditions at the sites indicated in the chart below:
In order to resolve and close this recommendation, the USMS should provide evidence to us that it has tested the contingency plan and disseminated the plan to system administrators to ensure that employees involved in emergency response procedures are identified and trained in their emergency roles and responsibilities.
|9b.||Unresolved. The USMS provided information regarding the location of its contingency plans on the USMS intranet. However, this electronic posting does not provide assurance that in the event of an emergency where access to files located on network servers are not available, that individuals at the site would know who to contact. In order to resolve and close this recommendation, the USMS should provide to us documented evidence that emergency contact lists are maintained on-site.|
|10.||Unresolved. The USMS requested additional information regarding specific sites where backup tapes were not being rotated off-site. We found that this condition existed at the Eastern District of Pennsylvania and the Southern District of New York. The USMS provided a corrective action plan to reinforce backup tape rotation policies at the locations identified. In order to resolve and close this recommendation, the USMS should provide us with documented evidence that PTS's backup tapes are properly rotated and stored at an off-site location.|
|11.||Resolved. The USMS states that the PTS contingency plan will be tested, but does not specify a milestone date for this action. In order to close this recommendation, the USMS should provide us a milestone date for the annual testing of the PTS contingency plan as required by the Department and confirmation of the results of the test once completed.|
|12a.||Unresolved. The USMS states that key source document requirements are already in place and that district office management will be directed to review data collection activities. We agree that modifications made to the Cellblock Operations Manual 99-47 provide guidance to improve data collection procedures. However, the revised Cellblock Operations Manual does not define, specifically, the minimum source documents required during the record creation process, such as two photographs of the inmate to aid the USMS with proper inmate identification and the medical form USM-552 to document health related issues disclosed during the initial interview with the inmate. In order to resolve and close this recommendation, the USMS should provide evidence to us that policies and procedures to establish key source document requirements have been developed.|
|12b.||Unresolved. The USMS states that the record creation process is standardized throughout the USMS and states that the PTS User's Manual and associated policy directives address this condition. However, during our site visits we found that the USMS had not established controls over source documents nor provided for their proper authorization because the USMS had not provided adequate data rules for employees or set standards for consistency during the record creation process. In order to resolve and close this recommendation, the USMS should provide evidence to us that policies and procedures were developed to standardize the record creation process throughout the USMS for the PTS.|
|13.||Unresolved. The USMS's response states that the OIG calls for a supervisor to sign off on a handwritten USM-129/312. This is not an accurate interpretation of our recommendation. We recommended that a "control" be implemented to ensure that transactions are supported by properly authorized source documents, but we did not mandate that supervisors sign off on handwritten USM-129/312s. In the report, we simply presented supervisory authorizations on source documents as an example of a control. We observed at the Eastern District of Virginia that the handwritten USM-129 was used as a form of authorization control and offered this as an example of what worked effectively at one office, but did not suggest this practice as an overall solution. The determination of what specific control would be feasible for implementation throughout the USMS was left to the discretion of the USMS. To resolve and close this recommendation, the USMS should provide us with documented evidence that it has implemented a control to ensure that before information is entered into the system, transactions are supported by properly authorized source documents.|
|14.||Unresolved. The USMS agrees that sufficient auditing is not conducted, but states that this deficiency is not due to the lack of management's requirement to do so. We reviewed the certification and accreditation documentation for the PTS application provided by the USMS in June 2003. On Form 6, Item 14a and b of the Risk Assessment Report for PTS/USMS-ABS dated June 2003, the USMS responded affirmatively that it has defined audit requirements for the PTS application and that the application has the capability to identify the creator of data and processes. In order to resolve and close this recommendation, the USMS should provide documentation to us evidencing that audit trails for the PTS application are maintained and reviewed as required by the Department.|
|15.||Resolved. The USMS states that global database searches will be possible through the upcoming JDIS initiative. In order to close this recommendation, the USMS should provide documented evidence to us indicating that the PTS application has been modified to perform automatic global database searches of all its district office databases.|
|16.||Resolved. The USMS indicates that erroneous data is collected through jail utilization and population projection reports reviewed by the Prisoner Services Division. The USMS does not indicate, however, what types of erroneous data are captured or what actions are taken to correct and investigate such data. Specifically, this audit report refers to the need to collect and review information on erroneous data, such as rejected transactions and input errors or omissions, to determine if errors cause threats to the PTS application or render the system vulnerable to compromise. Our findings indicate that all eight sites visited failed to collect statistics on the frequency of error messages generated by the system. In order to close this recommendation, the USMS should provide to us documented evidence of how erroneous data is collected and reported back to the USMS management for investigation and correction.|
Unresolved. The USMS contends that there is no "unauthorized" employee from which sensitive privacy information should be protected and asserts that a background investigation suffices as authorization to access PTS data. However, an examination of PTS's certification and accreditation documents indicates that the USMS does distinguish between "authorized" and "unauthorized" users.
Specifically, in the PTS/USMS-ABS System Security Plan, Section 1.8, System Interconnection/Information Sharing, the USMS states that "Not all Marshals users are authorized access to PTS, but all users who are authorized to connect to PTS do so through MNET." In the security plan's Section 4. 2, Logical Access Controls, the USMS explicitly states that "Controls exist in the PTS system to authorize and restrict users from performing particular functions." The document further states that "Access rights are granted based on the determination of USMS district management."
In the PTS's system security plan, section 1.10, General Description of Information Sensitivity, the USMS defines the requirement for confidentiality as high and further states that "Inappropriate disclosure of the information of the information could have negative impact on the safety of prisoners in USMS custody and the law enforcement officials assigned to transport and guard them. Furthermore, inappropriate disclosure could place the families of prisoners in USMS custody at risk as well as USMS employees assigned to protect and transport prisoners. All Privacy Act information within PTS must be protected. . . The requirement for confidentiality is HIGH." Protection of system data includes output reports and considering the USMS's own categorization of its requirement for confidentiality as high, USMS's protection of system output must be commensurate with its confidentiality category. In order to resolve and close this recommendation, the USMS should provide to us documented evidence that output reports containing sensitive privacy information are protected from unauthorized persons.
|18.||Unresolved. The USMS requests that additional information be provided regarding instances where the PTS application allowed simultaneous updates of the same record by more than one user. We witnessed this condition at the following locations: the District Court for the District of Columbia; the Eastern District of Pennsylvania; the Southern District of New York; and the District of Arizona. In order to resolve and close this recommendation, the USMS should provide us documented evidence that each installation of the PTS application protects against simultaneous updates of the same record by more than one end-user.|
|19.||Resolved. The USMS agrees with our recommendation that adequate and proper source documents be maintained in prisoner file folders to substantiate employee activities. The USMS submitted a revised Cellblock Operations Manual 99-47 that enumerates in Section C.3, Prisoner Records, specific documents that must be maintained in prisoner files. In order to close this recommendation, the USMS should provide documented evidence to us that an internal review process has been formalized to ensure that adequate and proper source documents be maintained in prisoner file folders to substantiate employee activities.|
|20a.||Resolved. The USMS agrees with our recommendation to implement integrity assurances and quality control measures to require periodic spot-checking and validation of output from the PTS. We have accepted the USMS's proposed resolution to Recommendation 19 that refers to Recommendation 12a. The proposed resolution to Recommendation 12a states that the USMS will include, during its Program Review's internal audits, a review of prisoner's files to compare the contents with reports of the USM-129/312 generated by PTS. In order to close this recommendation, the USMS should provide documented evidence to us that policies and procedures to implement quality control measures require the periodic spot-checking and validation of output from the PTS have been developed.|
|20b.||Resolved. As stated previously, we accept the USMS's proposed resolution to Recommendation 19 that refers to its proposed resolution to Recommendation 12a. The proposed resolution to Recommendation 12a states that output will be checked as a requirement during Program review's internal audits to confirm that processing of information is correct. In order to close this recommendation, the USMS should provide documented evidence to us that policies and procedures have been developed to implement quality control measures to confirm that the correct information is processed in PTS.|