Review of the United States Marshals Service's Prisoner Tracking System
Report No. 04-29
August 2004
Office of the Inspector General
|
Our review of select general controls designed to protect the PTS's system environment identified weaknesses with the PTS's entity-wide security program planning and management, access controls, application software development and change control, system software, segregation of duties, and service continuity controls. We also identified deficiencies with the PTS's application controls that are used to help ensure the validity of transactions and proper authorization of data. These deficiencies included inadequate authorization controls, completeness controls, accuracy controls, and controls over integrity of processing and data files. Our findings relative to data integrity included deficiencies with the completeness of prisoner records and the accuracy of information contained within the PTS. In our judgment, these findings are major weaknesses in the PTS. We consider the system overall to be at a high risk to the protection of its data from unauthorized use, loss, or modification. These weaknesses occurred because the USMS did not develop or fully enforce its own policies or comply with the Department policies, NIST standards, and OMB guidelines. If not corrected, these weaknesses could impair the USMS's ability to fully protect the integrity, confidentiality, and availability of data contained within the PTS database. 1. SELECT GENERAL CONTROLS General controls are entity-wide access controls used to safeguard a system's environment. Our review of select general controls for the PTS application identified weaknesses in all six of the Federal Information System Controls Audit Manual (FISCAM) general controls areas - entity-wide security program planning and management, access controls, application software development and change control, system software, segregation of duties, and service continuity controls. Entity-wide Security Program Planning and Management Entity-wide security program planning and management allows an organization to establish a security control structure that enables senior management to identify and address security risks. An effective plan requires that an organization:
We confirmed that the USMS adequately assessed risks, documented an entity-wide security program plan, and monitored the security program's effectiveness. However, vulnerabilities were noted as indicated in the following chart:
Establish a Security Management Structure and Clearly Assign Security Responsibilities Security managers are an essential component of an organization's security control structure and are responsible for reporting compliance issues to senior management. Security managers perform specific functions to ensure the effectiveness of security plans established to protect systems that maintain sensitive data. These functions include assessing and managing risks to protect the confidentiality, availability, and integrity of system data. Security managers are also actively involved in addressing threats posed by authorized internal users and unauthorized outsiders attempting to gain access to system data, and implementing logical and physical access controls to prevent breaches in security. Our review of the PTS's entity-wide security program planning and management revealed that no security manager for the PTS application had been formally appointed. This occurred because USMS did not establish a security management structure and clearly assign security responsibilities. The PTS's system security plan, included in the application's certification and accreditation documentation, lists an individual as the "Computer Systems Security Officer (CSSO)." However, when we interviewed the individual designated as the CSSO, we found that he was not actively involved in providing security manager duties for the PTS application and did not know he had been officially appointed. Subsequent interviews with USMS management officials confirmed that the USMS had not officially appointed a security manager to address computer security practices specific to the PTS application. OMB Circular A-130 requires that an entity "assign responsibility for security for each major application to a management official." Furthermore, the guidance recommends that the individual be "assigned the responsibility in writing to assure the application has adequate security." Without the appointment of a security manager for the PTS application, the USMS cannot ensure that the application has adequate security or that security-related tasks are carried out. Such tasks include properly authorizing system access, communicating security policies to the user population, and monitoring risk management activities. Recommendation: We recommend that the USMS:
Implement Effective Security-Related Personnel Policies The USMS did not implement effective security-related personnel policies to assure that employees possess adequate training and expertise. The USMS's Prisoner Services Division (PSD) offers specialized PTS training at a federal government facility in Glynco, Georgia. However, users of the PTS application who perform critical functions such as record creation and record updating were not required by management to attend the specialized training prior to being granted access to the system. OMB Circular A-130 states that users of an application should receive specialized training prior to being granted access, and that the specialized training should focus on their responsibilities and rules of expected behavior for the application. We found that no policy existed that required users to receive specialized training prior to or within a reasonable period after hire, and that the majority of PTS users had never received the specialized training offered by the USMS. Additionally, we determined that USMS personnel functioning as system administrators for the application did not have adequate training and expertise. According to the system administrator position description provided by the USMS, system administrators are responsible for "operating, troubleshooting, repairing, and maintaining IT systems." Additionally, the document states that employees must possess the requisite technical knowledge to sustain the availability of the hardware and software environment. The system administrator must also be competent to maintain operating systems, applications, and data elements. However, we found that some system administrators were unfamiliar with their hardware and software environment and lacked specific knowledge, such as what version of the application was running on their server, what files supported the application, or where the PTS database they were responsible for protecting was located. OMB Circular A-130 requires that an aspect of an entity's information management policy should require that employees, such as system administrators, are trained in skills appropriate to the management and protection of system information and that this training shall be an ongoing part of the information life cycle.8 These deficiencies could negatively impact the USMS's ability to assess risks and provide protection for sensitive PTS data. Recommendations: We recommend that the USMS:
Access Controls 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. Access controls are both logical and physical. These controls are used to ensure that staff duties and responsibilities are implemented in a way that safeguards programs. In order to successfully implement the critical elements of access controls, an organization must:
We found that the USMS successfully classified information resources and investigated apparent security violations. However, vulnerabilities were identified as indicated in the chart below:
Maintain a Current List of Authorized Users and Ensure That Their Access is Authorized We found that the PTS's list of authorized users contained multiple errors and inaccurate information. This resulted because USMS headquarters did not properly maintain a current list of authorized users that was coordinated with information maintained by the DOs. Additionally, the USMS did not regularly review the PTS authorized user list, validate the levels of access authorized to users, or update the user list accordingly. We obtained a consolidated user list for all authorized PTS users from USMS headquarters. Officials at USMS headquarters informed us that system administrators at each DO were responsible for maintaining their respective user list by adding and deleting names. Therefore, we sorted the headquarters list by DO location to produce a list for each of the following sites we visited: Eastern District of Virginia (E/VA) in Alexandria, Virginia; the District Court for the District of Columbia (DC/DC) in Washington, D.C.; the Southern District of New York (S/NY) in New York, New York; the Southern District of Texas (S/TX) in Houston, Texas; Eastern District of Pennsylvania (E/PA) in Philadelphia, Pennsylvania; the Northern District of Illinois (N/IL) in Chicago, Illinois; the Southern District of Florida (S/FL) in Miami, Florida; and the District of Arizona (D/AZ) in Phoenix, Arizona. Our review of the eight DO lists disclosed that: a) the USMS allowed accounts to remain on the application's authorized user list for employees who no longer required access to the PTS; and b) the authorized user list generated by USMS headquarters did not match the authorized user lists maintained at the DOs. The following chart represents specific deficiencies noted during our review of the authorized user list at each site we visited. The "total number of user accounts" column represents the total number of names appearing on the PTS authorized user list obtained from the USMS headquarters for each site visited. The figures in the "number determined invalid or unknown" column represent accounts that could not be confirmed as "valid" by the responsible system administrator. User accounts in this category were determined to be "invalid" if the names had not been removed from the user list although the user had departed the site or was no longer authorized access to the PTS application. User accounts were determined to be "unknown" if the system administrator could not attest to the users' identity or their authority to access the application.
A further review of the authorized user list for each site visited revealed that erroneous or invalid entries appeared on the user list obtained from USMS headquarters. However, the system administrators provided evidence that they were properly maintaining the user list at their site. We surmised that the discrepancies involving erroneous entries and unknown accounts occurred because the consolidated user list generated by USMS headquarters was not incorporating the additions, deletions, and changes made at the DO level. The DO user lists extracted from the HQ consolidated user list contained various column headings such as userID, name, and date of the user's last login. In addition to the deficiencies previously noted, the following deficiencies contributed to rendering accounts "invalid:"
Prior to our departure from each site, the system administrators agreed to remove entries deemed "invalid or unknown users" from their PTS-authorized user list. The above conditions do not comply with the Department's Order 2640.2E, "Information Technology Security," which requires that each user be identified as unique. The Department's Order further 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. Allowing "invalid and unknown" user accounts to remain on the PTS authorized user list could jeopardize the effectiveness of security features designed to restrict the user's access to only that information which is necessary for operations and for which the user has a need to know. The existence of active but invalid accounts could enable an unauthorized user to gain access to sensitive information. For example, accounts represented by an employee's official title or position description, as opposed to a specific userID, are equivalent to generic or "guest" accounts. Guest accounts could allow various members of a DO to share the same userID and password information to gain access to and make changes within a system. Any actions performed by these accounts, detrimental or otherwise, would be difficult to trace back to a specific user. OMB Circular A-130 sets forth personnel controls that strengthen access authorizations, provides for individual accountability, and emphasizes the need to hold users accountable for their actions. Ineffective access authorizations, such as allowing generic accounts to remain on an authorized user list, diminish the reliability of data and subject the system to unauthorized use, loss, or modification. Recommendation: We recommend the USMS:
Establish Physical and Logical Controls to Prevent and Detect Unauthorized Access Physical access controls consist of measures such as locking doors to facilities housing computers that process sensitive information and posting guards at entrance points to those facilities. 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. As discussed previously, we determined that the PTS's access authorizations or logical access controls were weak because USMS headquarters did not properly maintain a current list of authorized users. Physical access controls were adequately enforced at seven of the eight sites visited. However, we encountered an instance where physical access controls were not enforced to prevent or detect unauthorized access. We observed that the locks on the door to a restricted area at one location were not engaged. Adequate physical access controls to the building were provided by armed guards; however, the door to the restricted area housing data terminals and sensitive PTS information was left unlocked and potentially accessible by unauthorized visitors to the building. NIST Special Publication (SP) 800-18, "Guide for Developing Security Plans for Information Technology Systems" explains that physical access controls protect computer resources and "restrict the entry and exit of personnel." By not enforcing adequate physical access controls, the USMS exposed the PTS to the risk that unauthorized individuals could gain access to sensitive information. Additionally, the USMS's ability to protect sensitive printed data or equipment from theft or inadvertent disclosure would be compromised if an unauthorized person entered a restricted facility containing sensitive PTS equipment and data. Recommendation: We recommend that the USMS:
Application Software Development and Change Control Application software development and change control is an essential component of an application's system development life cycle (SDLC). These measures allow managers responsible for seeing that software supporting their operation meets the requirement of the organization and produces reliable data. An entity should institute policies, procedures, and techniques to ensure responsible individuals:
We determined that the USMS adequately tested new software and controlled its software libraries. However, our review disclosed a deficiency as indicated in the chart below:
Authorize Processing Features and Modifications An entity should ensure that its SDLC policies provide a structured approach that identifies who can authorize modifications to the system, and the policies should be distributed to all users. Ultimately, application end users have the primary responsibility for taking part in the design and implementation of processing features and approving subsequent changes made to the application. Although the USMS had a documented SDLC for the PTS that included instructions for requesting changes to the application, many of the PTS users at the DOs we visited were not aware of the policy and were not aware of how to formally request changes to the application. This condition exists because the USMS has not adequately disseminated established change control policies throughout the organization. The Department's Order 2640.2E, Chapter 1, "Security Program Management," directs components to develop a process to integrate security into various stages of a system's life cycle and to ensure that changes to any system are controlled. Ineffective management over modifications to application software could hamper an entity's ability to prevent knowledgeable programmers from covertly changing program code to access sensitive data. Additionally, the entity could risk the likelihood of implementing incorrect or outdated versions of operating system and application software. Failure to establish such controls could allow the introduction of malicious code that could lead to the loss or destruction of sensitive data. Recommendation: We recommend that the USMS:
System Software Often referred to as a "utility," system software is used by programmers to configure a system and manage the input, processing, output, and data storage associated with all of the applications that run on a system. System software operates at a higher level than application software and can thus be used to read, modify, or delete critical or sensitive information and to bypass security controls built into application programs. Moreover, some system software can change data and program code without leaving an audit trail, such as programming software and database management systems (DBMS).9 Weakness in controls over system software could negatively impact the reliability of information produced by applications supported by the computer system. An organization can protect the integrity of system software in the following ways:
Although the USMS effectively limited access to system software and monitored its use, deficiencies were noted in the area indicated in the following chart:
Control System Software Changes The PTS application consists of a database controlled by a DBMS and application programming software. The database is used to store data pertaining to the USMS's prisoner operations and prisoner identifying information. The application's user interface and functionality are modified using a commercial-off-the shelf programming language. We determined that the controls for the PTS's system software changes were deficient. The USMS is using an outdated version of the database management software and programming language to support the PTS application in its production environment. According to the DBMS and application programming software vendor, the company no longer provides technical support for these products and has not done so for over five years. This condition exists because the USMS has not updated and patched these critical components although the vendor has produced three version updates since the release of the version currently used by the USMS. OMB Circular A-130 recommends that entities periodically review security controls and seek ways to improve security such as utilizing technical tools to look for security problems and installing the latest software patches. NIST SP 800-40 specifically addresses procedures for handling security patches. NIST warns that not patching information systems in a timely manner can impact operations and degrade the confidentiality, availability, and integrity of a system's information. The USMS's use of outdated programming and database management software could prevent the USMS from implementing security enhancements such as system security patches designed to protect the PTS application from malicious software. This deficiency also increases the risk that without timely updates, data entered into the PTS could be improperly processed by the application. Recommendation: We recommend that the USMS:
Segregation of Duties Segregation of duties is the practice of dividing the steps in a critical function among different individuals. In a computer processing environment, such a control assists in the prevention of one individual having complete control of the input, processing, and output stages of the information cycle and keeps a single individual from subverting a critical process. Organizations should take steps to ensure that they:
Controls that sustain the proper segregation of duties enable management to maintain control over personnel activities. Additionally, segregation of duties requires the establishment of formal operating procedures as well as active supervision and review of these activities.10 We found that the USMS had adequately established access controls to enforce segregation of duties. However, deficiencies were noted within other control areas affecting segregation of duties as indicated below:
Segregate Incompatible Duties and Establish Related Policies Our review of the PTS disclosed that the USMS had not properly segregated incompatible duties and established related policies to ensure personnel understand their roles and responsibilities. Duties and responsibilities associated with the USMS's PTS system life cycle were not properly segregated among staff. At the USMS's headquarters, only one individual is assigned to code, test, and implement changes to the PTS application. The same individual is authorized to move changes into the production environment and distribute those changes to the 94 DO servers. This condition allows a single individual to have complete control over application programming and change control processes that should be divided among two or more individuals. The Department's Order 2640.2E, Chapter 2, specifies the requirement for segregation of duties. The Order states that system duties should be "defined and documented." OMB Circular A-130 discusses the requirement for personnel security and recommends that an application's security plan incorporate measures for the separation of duties. Furthermore, NIST SP 800-12, "Computer Security Handbook" describes separation of duties as "dividing roles and responsibilities so that a single individual cannot subvert a critical process." Control Personnel Activities Through Formal Operating Procedures and Supervision and Review We found that the USMS has not developed formal policies and procedures to guide PTS users in performing their duties. Although the USMS has published a user manual for the PTS application, the manual falls short of providing formal operating procedures to be followed during critical processes such as the record creation process and subsequent record updates. These processes directly affect the confidentiality, integrity, and availability of the PTS data. Due to the lack of policies and procedures, we found that the record creation process was not standardized at any of the DOs we visited and that this condition exists throughout the USMS.Following our site visits, we conferred with program managers for the PTS application who informed us that USMS headquarters has not provided formal operating policies and procedures to standardize the record creation process nor has it established standards for the collection of source information used to create prisoner records in the PTS. In the absence of formal policies and procedures, USMS headquarters and DOs had not formally established compensating controls such as requiring adequate supervision or review of information once a record is created or updated in the system. We observed that all DOs we visited operated differently with respect to the record creation process. We also found that while some DOs performed minimal supervisory reviews, others did not perform any supervisory reviews because they were not required to do so. Supervisory reviews, performed on a consistent basis, would help to detect the types of completeness and accuracy errors we found during our review of PTS data. Without proper segregation of duties, the USMS increases the risks that erroneous or fraudulent transactions could be processed by the PTS and that computer resources could be damaged or destroyed. Additionally, without the USMS providing adequate controls over personnel activities, mistakes within the PTS could occur and go undetected and expose the application and its data to unauthorized use, loss, or modification. Recommendation: We recommend that the USMS:
Service Continuity Service continuity measures provide for the capability to protect information resources and minimize the risk of unplanned interruptions. Service continuity controls involve ensuring that when unexpected events occur, critical operations continue without interruption or are promptly resumed and the organization's sensitive data are protected. To review the adequacy of its service continuity control, an entity should:
The USMS had developed a contingency plan for the PTS application. However, we found other deficiencies within service continuity controls for the PTS application as indicated below:
Assess the Criticality and Sensitivity of Computerized Operations and Identify Supporting Resources We determined that the USMS successfully assessed the criticality and sensitivity of the PTS. However, we found that the USMS was deficient in identifying supporting resources within the DOs, which according to FISCAM includes human resources. Specifically, the USMS had not implemented a means to identify employees with service continuity responsibilities to users within the DOs, such as making an emergency contact list available to users at each site. Although the USMS maintained emergency contact lists at its headquarters, this deficiency occurred because the USMS did not require the DOs to maintain emergency contact lists to identify supporting resources on-site. Consequently, we found that the majority of the DOs did not maintain lists or make this information available to users. NIST SP 800-34, "Contingency Planning Guide for Information Technology Systems," identifies contact lists as an element of an effective contingency plan and recommends the frequent review of such lists. We also found that the USMS did not distribute its contingency plan, which contains emergency contact information, to supporting resources at the DOs - although execution of the contingency plan requires support from the system administrators assigned to the DOs. NIST SP 800-34 states that copies of contingency plans are typically provided to persons with service continuity responsibilities, such as the system administrators at the DOs. We found that the information regarding emergency notifications was contradictory. The USMS PTS contingency plan identifies the Help Desk as the point-of-contact for service disruptions. The plan also states that the system administrator is responsible for maintaining the PTS servers at each field location and for reporting failures.11 However, the plan presents an emergency response scenario wherein the system administrator would notify the Help Desk if the PTS server in the DO were disabled or unavailable. This scenario implies that system administrators, who are assigned to the DOs, are logically the first responders to users within the DOs and would most likely be contacted in case of emergency. The absence of an emergency contact list to identify individuals at the DOs with service continuity responsibilities could cause users to become confused as to who should be notified in the event of an emergency, especially during non-duty hours. Additionally, without a copy of the USMS contingency plan for the PTS, individuals identified as supporting resources could become confused as to their service continuity roles and responsibilities. In addition to our findings regarding the clear identification of supporting resources, we also found problems with the competence of those individuals involved in emergency response procedures. This occurred because the USMS had not required or provided sufficient training for employees with service continuity responsibilities. NIST SP 800-18 provides guidance for developing security plans for information technology (IT) systems. The guidance states that responsible individuals should be designated as points-of-contact for a system and that the individuals should be knowledgeable about the system. We reviewed the system administrator position description and verified that the system administrators are designated as the primary representative at the DOs for IT functions and are responsible for responding to emergency situations. The position description specifically states that the employee must possess knowledge of IT systems "recovery" methods and practices. However, we found that system administrators, who were expected to assist with service continuity functions, lacked sufficient training to support the restoration of the application and its data files. Many of the system administrators at the sites we visited did not know specific characteristics of the system that would enable them to respond appropriately in case of an emergency. Specifically, system administrators did not know the version of the application running on their server or the location of their PTS database. In the event of an emergency or system abnormality, system administrators who are not properly trained could impede restoration of the data files and software by failing to respond appropriately. Recommendation: We recommend that the USMS:
Take Steps to Prevent and Minimize Potential Damage and Interruption Two aspects of preventing and minimizing damage or interruption of service to users of the PTS application include ensuring that: a) data and program backup procedures have been implemented; and b) staff have been trained to respond to emergencies. Our review disclosed that backup tapes created at three of the DOs we visited were not consistently rotated off-site. This occurred because the USMS did not take steps to prevent and minimize potential damage and interruption by securing backup data away from the processing facility. Additionally, the USMS did not enforce its own guidelines for backup operations. The PTS security plan addresses contingency planning and states that backups should be created nightly and transferred off-site once a month. NIST SP 800-34, "Contingency Planning Guide for Information Technology Systems," addresses backup methods. The guidance requires that backup policies be established and backup data stored off-site. Consequently, the USMS may lose the capability to restore the PTS's application software and data by relying on insufficient preventative measures to mitigate service disruptions if tapes are not properly secured at an off-site location. We also found that the USMS did not effectively ensure that staff had been trained to respond to emergencies, another aspect of minimizing service interruptions. As discussed in the previous section regarding identifying supporting resources, we found that system administrators lacked sufficient knowledge of their system environment to provide support of recovery functions and that copies of the contingency plan that specified emergency roles and responsibilities had not been distributed to the DOs. Therefore, we recommended the USMS provide training for employees involved in emergency response procedures in Recommendation 9. Recommendation: We recommend that the USMS:
Test the Contingency Plan Periodically and Adjust It As Appropriate Although the USMS has developed and documented a contingency plan for the PTS application, it has not tested the plan. The Department's Order 2640.2E, Chapter 1, sets standards for contingency planning. It directs components to develop a contingency plan and test the plan annually. Furthermore, OMB Circular A-130 advises that untested contingency plans "may create a false sense of ability to recover in a timely manner." The USMS places the PTS application and its data at risk by having an untested contingency plan for PTS. This deficiency could prevent the USMS from achieving timely restoration of critical PTS system information and diminish the assurance for continuity of operations in the event of a disaster. Recommendation: We recommend that the USMS:
2. APPLICATION CONTROLS Application controls are the structures, policies, and procedures that apply to application systems. Application controls include both the routines built into the computer program code and the external safeguards provided by users. External safeguards include manual measures performed by the user such as reviewing output reports to determine that the computer processes data accurately. Application controls help make certain that transactions are valid, properly authorized, and completely and accurately processed by the computer during all three phases of a processing cycle - input, processing, and output. At the time of input, data should be authorized, converted to an automated form, and entered into the system. This transaction is expected to be accurate, complete, and occur in a timely manner. For the processing phase, the computer accepts the data entered and files are updated in the system's database. Lastly, in the output phase, files and reports are generated by the system and the results are expected to yield an accurate processing of the data entered into the system. Controls should be in place to ensure that system outputs are controlled and distributed only to authorized persons. To assess the effectiveness of application controls for the PTS, we reviewed authorization, completeness, accuracy, and integrity of processing controls. We identified deficiencies within all of the application control areas. Authorization Controls Authorization controls are designed to ensure the validity of system transactions, and that the transactions performed represent an event that actually occurred during a given period. These controls regulate access to network resources and ensure that data is properly converted to an automated form so it can be processed accurately, completely, and timely. Effective authorization controls should protect the data input process and include the following critical elements:
The USMS effectively used master files to help ensure that all data are processed. However, the following deficiencies were noted as indicated below:
All Data Are Authorized Before Entering the Application System In order to ensure that all data are authorized before entering the application system, the FISCAM recommends that entities should implement measures to: a) control source documents and require authorizing signatures; and b) ensure supervisory reviews of data occur before entering the application system. The guidance acknowledges that paper source documents continue to play an important role during the data collection process. It cautions, however, that source documents should be controlled at the earliest point in the process and the data should be approved for use prior to entering the system. FISCAM also outlines requirements for performing independent or supervisory reviews of data regardless of the source. Our review disclosed deficiencies within both areas designed to ensure the proper authorization of data. Control source documents and require authorizing signatures We found that the USMS had not established controls over source documents, nor provided for their proper authorization. The GAO defines a source document as information that serves as the basis for the entry of data into a computer system. At all sites visited, we experienced difficulty in verifying the validity of the transactions we reviewed on PTS output reports due to the absence of source documents or because of inconsistencies with the collection and authorization of source documents. Therefore, the USMS was not able to attest to the validity of many transactions entered into the PTS or support the actions taken by its employees. This condition occurred because the USMS had not formally established baseline requirements for source documents to provide a reasonable assurance that critical identifying information is collected from a reliable source and is properly authorized. Additionally, the USMS had not implemented effective controls to ensure the proper authorization of data obtained from source documents prior to that data being used in PTS transactions. Because baseline requirements for source documents had not been established by the USMS, we consulted the USMS employees performing record creation duties at the sites visited to determine what documents were used as source documents during the record creation process for the PTS. According to these employees, "key" source documents used to support the record creation process included: the individual custody and detention form (USM-129); FBI fingerprints card (FD-129); intake photo; and medical form (USM-552). However, we found that because the USMS did not require employees to collect these source documents on a consistent basis, some DOs were not creating records based on documentation, but rather on interviews with prisoners. This occurred because the USMS had not formally established baseline requirements for source documents, such as the ones identified by USMS personnel, to provide a reasonable assurance that critical identifying information is collected from a reliable source and is properly authorized. The USMS Cellblock Operations Directive advises employees to interview the prisoner during the initial intake process and collect identifying, arrest, prosecution, and medical information from the prisoner. The directive instructs employees to then enter the information obtained from the prisoner into the PTS to create a prisoner record. Under these conditions, the USMS is basing the reliability of the information collected on the integrity of the prisoner. Furthermore, the directive does not require that information be approved by an authorizing official or verified from other presumably more reliable sources such as court documents or forms completed by arresting officers. OMB Circular A-130 advises federal agencies of the requirement for records management and states that agencies should "create and keep adequate and proper documentation of their activities." OMB also warns that the lack of sufficient record keeping weakens agencies' ability to responsibly perform their missions. OMB emphasizes the importance of record-keeping activities in each stage of a system's life cycle and directs agencies to document their procedures for information collection. By failing to establish standards and controls over source documents and provide for the proper authorization of data, the USMS is jeopardizing the reliability of information collected during the record creation process. The reliability of data that serves as the basis for creating records in the PTS has a direct impact on the confidentiality, availability, and integrity of the data within the PTS. Throughout our review, we also found inconsistencies with the collection of source documents, the authorization of data, and the maintenance of source documents within each prisoner's file folder. We noted that each DO essentially performed data collection, record creation, and file maintenance functions differently. These inconsistent practices resulted in the deficiencies discovered during our assessment of the PTS's data integrity. Specifically, we discovered findings within the PTS's completeness of information and accuracy of information. This occurred because the USMS had not standardized the record creation process throughout the USMS to aid in establishing control over source documents. The GAO's guidance for assessing data reliability emphasizes the need for organizations to establish and adhere to standardized rules for the collection and use of data in computer processing environments. Additionally, adherence to the consistent interpretation of data rules, or the use of standardized processes, contributes to data reliability. The guidance stresses that standardization and consistency are particularly important to systems where data is entered at multiple sites, such as the PTS. The guidance asserts "inconsistent interpretation of data rules can lead to data that, taken as a whole, are unreliable." Failure to establish and enforce standardized procedures during critical processes, such as the record creation process for the PTS, could negatively affect the reliability of data within the PTS and impact the mission of the USMS. We determined that the USMS's cellblock directive and user manual do not provide adequate data rules for employees or set standards for consistency during the record creation process. In the case of the PTS, formal standards would ensure, at a minimum, that each prisoner file folder contains photographs, medical information, and fingerprint cards; and that critical identifying information is collected from a reliable source such as a court document or agent arrest form. These standards could also provide reasonable assurance against the misidentification or mishandling of a prisoner due to inaccurate, unauthorized, or unreliable data. Recommendation: We recommend that the USMS:
Ensure supervisory reviews of data occur before entering the application system We also found that supervisory or independent reviews of source document information were not being performed on a consistent basis prior to the information being entered into the PTS. This was evidenced by the fact that handwritten "Individual Custody and Detention" (USM-129) forms, when used, did not always contain an authorizing signature. We observed that some DOs provided supervisory reviews during the record creation process while others did not. In addition, our review of prisoner file folders for accuracy of information disclosed discrepancies between information on source documents and information on the PTS output reports. We determined that these inaccuracies could have been prevented through the use of compensating controls such as supervisory reviews. This condition existed because the USMS did not require DOs to perform supervisory reviews of source documents and transactions. In the absence of policies and procedures, supervisory reviews serve as a compensating control to ensure the proper authorization of source documents and transactions. OMB Circular A-130 prescribes the use of controls that monitor individual accountability and prevent and detect harm caused by "authorized individuals engaged in improper activities, whether intentional or accidental." Recommendation: We recommend that the USMS:
Restrict Data Entry Terminals to Authorized Users for Authorized Purposes The USMS has not implemented automated controls to trace actions on the system or ensure that data entry terminals are restricted to authorized users for authorized purposes. In our judgment, this weakness exists because the USMS does not maintain sufficient audit trails for the PTS application or require exception reports generated from audit logs. These reports could help identify unauthorized activities such as excessive errors made by an employee, record deletions, or attempts to gain access to resources to which the user is not authorized. The Department's Order 2640.2E, 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. Audit logs provide a measure of assurance to enforce individual user accountability. The USMS has not implemented automated controls to trace the occurrence of unauthorized activities or look for patterns of behavior by users of the PTS application. Therefore, USMS management has reduced its ability to monitor unauthorized attempts by users who have access to sensitive data above their access levels, unauthorized changes or deletions to prisoner records, or activities of users with privileged accounts. These vulnerabilities could impact the integrity of data within the PTS application. Recommendation: We recommend that the USMS:
Completeness Controls 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. Completeness controls in an application provide safeguards for ensuring that:
Our review of the USMS's completeness controls for the PTS disclosed a deficiency as indicated in the following chart:
All Authorized Transactions Are Entered Into and Processed by the Computer In our review of completeness controls, we found that mechanisms built into the PTS application to perform computer sequence checking were inadequate for the PTS environment. This condition exists because the current configuration of the PTS application is restrictive in that the default system configuration confines sequence checking to the information contained in the local database and does not automatically extend the search to other DO databases. The USMS Cellblock Operations Directive dictates that a prisoner will be assigned only one USMS number throughout their history with the agency. This would require that all 94 DO databases be searched to determine if the prisoner being processed has an existing USMS number assigned by another district before a district issued a USMS number. The PTS application's current software configuration is not conducive to automatically facilitate global database searches for prisoners' USMS tracking numbers and name information because the USMS maintains a separate PTS database at each of its 94 DOs. Under the current configuration, PTS users can (by default) search only their local database to determine if a prisoner has been previously assigned a USMS number in their district. The PTS application is not programmed to automatically extend the search to other DO databases. In order to determine if a prisoner has an existing USMS number that was assigned in another district, the PTS user must manually connect to the PTS database where the original USMS number and prisoner information is maintained. In the absence of knowing where the USMS number originated, the PTS user would have to manually perform 93 additional database searches to determine if a USMS number exists for the prisoner in another DO. In its own directive regarding cellblock operations, the USMS advises PTS users to exit the application and go to the Federal Bureau of Prisons's (BOP) SENTRY application to search for the existence of a previously assigned USMS number.13 This workaround solution is impractical because it forces PTS users to seek USMS information outside their own component that should be readily available on USMS systems. Additionally, not all users of the PTS application have access to BOP SENTRY; therefore, those users are restricted from performing the search within SENTRY to check for a pre-existing USMS number before assigning a new USMS number. The current configuration of the PTS application constrains a name search to the local database. This constraint threatens compliance with the USMS's own directives regarding multiple USMS numbers. Additionally, it does not provide adequate assurance to the USMS that multiple USMS numbers will not be assigned to the same individual. Recommendation: We recommend the USMS:
Accuracy Controls 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 well-designed data entry processes, 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. Entities can take steps to strengthen the effectiveness of accuracy controls by making sure that:
We determined that the PTS's data entry design and data validation and editing features were adequate. However, our review identified weaknesses with accuracy controls within the PTS application as indicated below:
Erroneous Data Are Captured, Reported, Investigated, and Corrected Our review of accuracy controls for the PTS application disclosed that erroneous data within the system was not identified, reported, investigated, nor corrected. Information on erroneous data is useful in forming a basis from which management can review and analyze the levels and types of transaction errors and formulate plans for corrective action. However, we found that information on rejected transactions and erroneous data was not analyzed because the USMS management did not require erroneous data to be collected and reported back for investigation and correction. NIST SP 800-12, Chapter 4, "Common Threats," warns that errors and omissions can threaten data and system integrity. It classifies some errors as threats, because users frequently make errors that result in security problems. The guidance recommends that because application programs cannot detect all types of input errors or omissions, erroneous data should be reviewed to determine if errors cause threats to a system or result in vulnerabilities. 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 in PTS data 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 application. Without the USMS effectively implementing measures to strengthen accuracy controls, invalid data may be entered in the system, be processed by the system, and cause production results that are unreliable to the system users. Our review of the PTS output reports for accuracy of the information reflects the existence of errors and omissions that accuracy controls are designed to detect. Recommendation: We recommend that the USMS:
Output Reports Are Reviewed to Help Maintain Data Accuracy and Validity A critical element of accuracy controls includes the review of output reports to help maintain data accuracy and validity. An aspect of enforcing the review of output reports consists of maintaining control over system output production and distribution. We determined that the controls over system output production and distribution for the PTS application were weak because the USMS did not enforce strict controls to prevent the exposure of sensitive PTS output to non-authorized employees. The USMS allows authorized PTS users and non-authorized USMS employees to share the same network printers. This poses a problem with the district office's ability to adequately protect sensitive output production and distribution from non-authorized employees who have physical access to network printers. We also observed that cover pages are not used to safeguard sensitive PTS data from viewing by unauthorized individuals when the output is printed on network printers. Cover pages could serve as a mitigating control to identify the owner of the printed output on shared printers. NIST SP 800-53, "Recommended Security Controls" provides guidance for protecting sensitive information to prevent the unauthorized receipt of paper media. It cautions that entities should provide adequate supervision of personnel and develop detailed procedures to ensure that unauthorized individuals cannot read, copy, alter, or destroy information generated by the information system in printed form. Additionally, the guidance stresses assurances that "Output from the information system is given only to authorized users." The Department's Order 2640.2E, "Access Control," requires that users only have access to information necessary to perform their duties and no more. Moreover, it requires that controls be in place to ensure that users can only access resources critical to the accomplishment of their duties. OMB Circular A-130 also provides requirements for information safeguards. It states that information protected by the Privacy Act of 1974 should be collected, maintained, and protected to prevent disclosure of personal information and intrusion into the privacy of individuals. The Circular holds agencies responsible to see that appropriate information safeguards are instituted and that employees are trained in the protection of privacy. By allowing authorized PTS users to print sensitive PTS output on network printers shared by non-authorized USMS employees, the USMS is neglecting critical physical security measures that protect against unauthorized access. This vulnerability poses a threat to the USMS's ability to comply with federal regulations that require protection of privacy information from unauthorized disclosure. It also undermines the USMS's efforts to effectively enforce appropriate access control and segregation of duties. Recommendation: We recommend the USMS:
Controls Over Integrity of Processing and Data Files Controls over integrity of processing and data files are used to ensure that the current versions of production programs and data files are made available to users during system processing. These controls prevent users from accessing outdated versions of software that may be present in the production environment. Controls over integrity of processing and data files include:
We found that procedures existed to ensure that the current versions of production programs, data files, and computer files are used during processing and that programs check internal file header labels before processing. However, we discovered the following deficiency in the control area indicated below:
Mechanisms Within the Application Protect Against Concurrent File Updates Our review of the PTS application disclosed deficiencies within the controls that prevent concurrent updates of files. According to USMS headquarters, the PTS application is distributed to each of the 94 DOs. USMS headquarters also asserted that system administrators at each site cannot modify the PTS's functionality and that the application should function uniformly. However, we discovered malfunctions with the controls built into the application to prevent concurrent file updates. We performed testing at all DO locations visited, and at four locations we observed that the controls against concurrent updates did not work consistently. PTS users were able to access the same prisoner record and make changes to the database simultaneously. OMB Circular A-130 recommends that entities periodically review security controls and seek ways to improve security such as utilizing technical tools to look for security problems and installing the latest software patches. NIST SP 800-40 specifically addresses procedures for handling security patches and confirms that many organizations fail to keep software updated and patched. It warns that not patching information systems in a timely manner can impact operations and degrade the confidentiality, availability, and integrity of a system's information. Weaknesses with controls that protect against the concurrent update of records within an application threaten the integrity of its data. When multiple users of the application can access the same prisoner record and make changes to the database simultaneously, there is no assurance that the information in the record is correct or that the application has processed the information properly. It appears that this weakness occurred because the USMS did not ensure that all of its DOs received identical versions of the PTS application or that the existing versions were not patched in a timely manner. Specifically, USMS should confirm that the version of the PTS application in production at each site contains the full security controls, including those designed to prevent simultaneous updates to protect the integrity of data. Recommendation: We recommend the USMS:
3. DATA INTEGRITY TESTING The goal of maintaining data integrity is the assurance that information processed by the computer is reasonably complete and accurate and meets the needs of the organization. Completeness and accuracy of information reflect how well data integrity is maintained.
Our review of the factors that contribute to data integrity disclosed deficiencies within the areas indicated below:
Completeness of Information Completeness is achieved when data elements are processed as intended and source documents are maintained to support the results of processing. We evaluated the completeness of prisoner file folders to determine if PTS data were properly authorized and supported by adequate and proper documentation. Our review for completeness of information focused on the existence of key source documents in prisoner records as discussed earlier in the authorization controls section of this report. Records contain all of the data elements and documents used as support for the transactions We found that many of the prisoner file folders reviewed were missing information used to validate data entry transactions and to substantiate the actions taken by USMS personnel. This occurred because the USMS did not establish and implement standards regarding data collection and comply with federal records retention requirements. The chart below details the number of occurrences for source document discrepancies found during the review of 25 records at each site, and the percentages were calculated against the total number of records (200) reviewed at all sites.
OMB Circular A-130 outlines an information management policy that includes records retention requirements and advises agencies to record sufficient information to ensure the management and accountability of its programs. Additionally, the guidance directs agencies to incorporate records management functions into a system's SDLC that include maintaining adequate and proper documentation of agency activities. Furthermore, OMB directs agencies to provide training and guidance to all employees regarding their records management responsibilities, especially with respect to maintaining adequate and proper documentation of program activities to protect the federal government's legal and financial interests. Incomplete prisoner file folders pose a significant risk to the USMS's ability to validate PTS transactions, verify information, and justify the actions of its employees. Recommendation: We recommend the USMS:
Accuracy of Information Information is considered accurate if the results of computer processing reflect the contents of source documents. Accuracy of information can be verified by the periodic spot-checking of system output reports to validate and confirm that the application has processed the data entered into it correctly. Output reports reflect the data obtained from the source documents System output is evidence of the results of the input and processing functions of an application and reflects the effectiveness of such operations. If reviewed, output reports help to maintain the accuracy and validity of data within a system and determine the completeness of processing. The USMS' form 129 (USM-129) is the PTS application's output report resulting from prisoner record creation and subsequent record updates. After performing the analysis for the existence of key source documents used to create and update prisoner records, we reviewed the same prisoner file folders for accuracy of information. This review included the manual inspection of source documents contained in prisoner file folders. The source documents were then compared against the information appearing on the prisoner's USM-129 form (PTS's output report) to determine data accuracy. Our review of output reports produced by the PTS application disclosed discrepancies in the accuracy of information. We found that prisoner identifying information, such as a prisoner's date of birth (DOB) and social security number (SSN), appearing on the PTS output reports did not always match the source documents contained in the prisoner's file folder. Additionally, critical dates, such as a prisoner's custody date, did not always correlate with dates on source documents in the prisoner file folders. Such dates are used by the USMS to calculate expenditures for reimbursements to contract jail facilities. We noted common deficiencies in eight areas. These areas included:
The chart below illustrates the results of our review of the PTS's output reports. The numbers in each column represent the number of inaccuracies found during the review of 25 records at each site. The percentages were calculated against the total number of records (200) reviewed. |
|
Incorrect DOB |
Incorrect SSN |
Misfiled Documents |
Concurrent Jail Days |
Misnumbered File Jackets |
Missing Transactions |
Wrong Dates |
No Supporting Documentation |
|
|---|---|---|---|---|---|---|---|---|
| E/VA | 2 | 1 | 1 | 1 | 0 | 7 | 8 | 18 |
| DC/DC | 1 | 2 | 0 | 1 | 1 | 7 | 10 | 23 |
| S/NY | 0 | 0 | 0 | 0 | 0 | 1 | 8 | 5 |
| E/PA | 0 | 1 | 2 | 0 | 3 | 0 | 2 | 21 |
| S/TX | 4 | 0 | 0 | 0 | 3 | 0 | 12 | 20 |
| N/IL | 1 | 1 | 0 | 0 | 0 | 0 | 7 | 25 |
| S/FL | 0 | 1 | 0 | 0 | 5 | 2 | 7 | 24 |
| D/AZ | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 15 |
| Total: | 9 | 6 | 4 | 2 | 12 | 18 | 55 | 151 |
| Percentage: | 5% | 3% | 2% | 1% | 6% | 9% | 28% | 76% |
|
DOB and SSN information. This information is used to distinguish between prisoners with identical names. We found instances where documents in the prisoners' file folders did not match the DOB or SSN information appearing on the PTS's USM-129 report. Misfiled documents. We discovered documentation pertaining to one USMS prisoner erroneously filed inside another prisoner's file folder. Prisoner file folders contain records of court proceedings such as writs,14 judgment and commitment orders, and warrants that are used to initiate and substantiate updates to prisoner records. A document filed in the wrong prisoner's file folder could delay or prevent the processing of a time-sensitive prisoner action such as a release, movement, or designation to a BOP facility. Concurrent jail days. These represent instances where entries in the chronological prisoner history section of the USM-129 indicated that a prisoner was housed at two different jail facilities on the same dates. USMS uses the number of jail days to calculate monthly obligations to state and local contract jail facilities. Therefore, jail day discrepancies could negatively impact the accurate payment of bills causing the USMS to pay for contract jail services it did not receive. Misnumbered file jackets. At one site visited, we experienced difficulty locating a prisoner's file folder because the USMS number on the file folder did not match the prisoner's USMS number. We also observed what appeared to be a re-constructed file folder because the prisoner's USM-129 showed substantial confinement history, but the file folder had little or no contents and was missing the minimal source documents such as photographs and fingerprint cards. An error of this nature could prevent USMS personnel from locating records in a timely manner or result in the need to "reconstruct" a prisoner file folder for the prisoner in custody. Missing transactions. We identified occurrences where documentation existed in the prisoner's file folder that changed the prisoner's status, but the transaction was not entered into the PTS. Specifically, the prisoner's file folder contained documentation that would trigger an update action such as the receipt of a judgment and commitment order, but the appropriate transaction to update the record was not entered into the PTS (WT-J/C).15 Again, this type of discrepancy could prevent or delay a time-sensitive transaction from being entered into the PTS. Wrong dates. These were identified when comparing the PTS's system output (USM-129 report) with the agent's arrest form source document. Incorrect entries were identified for critical dates - the prisoner's arrest date and USMS custody date. Discrepancies with the prisoner's arrest date and USMS custody date directly affect the credit a prisoner receives for time served and also factor in the calculation for jail days used to reconcile jail bills and other expenditures. No supporting documentation. At all sites visited, we found that prisoners' file folders were missing documents that were needed to substantiate record update actions taken by the USMS personnel. In these instances, we determined that documentation did not exist for many of the status code transactions and the majority of the facility history transactions that chronicled prisoner movements. Specifically, key documents, such as prisoner manifest forms, were not consistently maintained in the prisoner's file folder or filed in the DOs for longer than one year.16 Other supporting documents, such as "requests for designation" or correspondence from the BOP that justified prisoner movements, were also not maintained in the prisoner file folders we reviewed. We found a significant number of errors with respect to the accuracy of information on system output and with the completeness of prisoner file folders records. We attributed the existence of these conditions to the lack of policies and procedures to standardize the intake process, as well as the lack of supervisory review of data before it is entered into the PTS application. Recommendation: We recommend that the USMS:
Footnotes
|