2. ESTABLISHING AN EMERGENCY MANAGEMENT PROGRAM

Although the April 1999 CIP Plan contained a comprehensive blueprint and milestones for an effective, centrally managed Department emergency management program, such a program has not been fully implemented. Many of the critical emergency management program elements relating to indications and warnings, incident collection, reporting and analysis, and response and contingency planning were neither established nor operating. Although the CIP Task Force was responsible for developing and implementing the CIP Plan, including the emergency management program, the Task Force ceased operating during calendar year 2000 and had no further involvement in implementation activities. As a result, the Department has less than adequate assurance that it can effectively respond to computer attacks and security incidents.

A. Department Efforts to Establish an Emergency Management Program for the Protection of Critical Infrastructure Assets

The April 1999 CIP Plan established the critical elements for an effective emergency management program and tasked the CIP Task Force (CIPTF) with its implementation. The CIPTF had members in 9 law enforcement entities, 5 litigating divisions, and 12 other entities. See Appendix 10 for Department entities that had CIPTF members. The Department's emergency management program, as envisioned in the CIP Plan, was to incorporate the following three elements.

• Indications and Warnings: The purpose of this element was to establish an effective and secure mechanism for: a) receiving threat indication and warning information concerning the critical infrastructure of the Department and the nation from the intelligence community and law enforcement agencies, and b) disseminating this information in a timely manner to appropriate Department components.
  
  As envisioned in the CIP Plan, the emergency management program would establish effective liaisons with the Department's SEPS, the FBI's NIPC, and the FBI's Strategic Information Operations Center (SIOC). The IMSS would ensure the existence of secure, effective, and timely communication channels for passing threat information from internal and external organizations to Department components at both headquarters and field locations charged with the protection of the Department's critical infrastructure assets.²⁸ In our judgment, although part of the NIPC has been transferred to the DHS, an effective liaison capacity is still needed.

• Incident Collection, Reporting, and Analysis: This element was to define and establish an effective and secure mechanism for collecting, reporting, and analyzing incident information about actual and potential attacks on the Department's critical infrastructure assets.²⁹ The established method should have ensured that information generated from computer security incidents was received from Department components and disseminated throughout the Department and to other intelligence and law enforcement agencies, as appropriate, in a timely manner.
  
  Incident data would be provided to the NIPC as part of the National Critical Infrastructure Indications and Warnings System and the Department's Computer Security Laboratory to establish new requirements for a research and development program. The incident data would also be used to support budget and resource justifications.

• Response and Contingency Plans: This element was to define and establish sound response and contingency plans to ensure that the Department's critical infrastructure assets could be restored to the minimum operational effectiveness necessary to support the Department's missions, should these critical infrastructure assets be subjected to successful attack.
  
  Response plans identify actions for responding to a significant infrastructure attack while the attack is underway. Contingency plans identify actions required to rebuild or restore an infrastructure after it has been damaged. The CIP Plan requires that response and contingency plans should be prepared, reviewed, and approved by Department authorities, and tested by an exercise on a periodic basis to ensure that the plans can be effectively implemented.

The CIP Plan also established several intermediate milestones for implementing the three essential elements of the Department emergency management program. Full implementation of the program was to occur no later than September 28, 1999.

B. Implementation of the Emergency Management Program

Although the CIP Plan contained a comprehensive blueprint and milestones for an effective, centrally managed Department emergency management program, such a program was never fully established. Officials of the IMSS indicated that the CIP Task Force, tasked with implementing the emergency management program, last met during calendar year 2000 and was no longer in existence. In response to our inquiries, those IMSS officials could not provide an explanation as to why no further effort was made to implement the plan.

Officials of the IMSS also stated that although the emergency management program as envisioned in the CIP Plan had not been implemented, most of the elements of an effective emergency management program were nevertheless in place and operating throughout the various Department components. However, in evaluating the Department's response capabilities to computer security incidents, we found that many of the four critical emergency management program elements relating to 1) indications and warnings, 2) incident collection, reporting and analysis, 3) response plans and 4) contingency planning were neither established nor operating. Our specific observations follow.

(1) Indications and Warnings

The IMSS did not ensure that this element of the emergency management program was fully implemented. According to JMD officials, communication channels were established for passing threat information from internal and external organizations to Department components at both headquarters and field locations charged with protecting the Department's critical infrastructure assets. Specifically, the DOJCERT is the Department's central point for receiving and disseminating indications and warnings.³⁰ Within the DOJCERT, a contractor operates the Department's-Information Sharing and Analysis Center and provides a departmentwide mechanism for sharing vulnerabilities to better prepare the Department for responding to cyber attacks. Additionally, the DOJCERT has implemented an intranet web page that includes a search capability for previously distributed indication and warning bulletins, and an Internet web page for information purposes.

Although communication channels were established for passing threat information, the IMSS did not determine whether the channels were secure, effective, and provided timely information as required by the CIP Plan. Additionally, the IMSS did not verify whether effective liaisons with the FBI's NIPC or the SIOC were established and ongoing. See Finding 3 for more details concerning liaisons not being adequately identified. Unless all indication and warning elements are in place, the Department does not have the assurance that communication channels for sharing vulnerabilities are secure and that components are receiving timely information to better equip them to respond to computer security incidents.

(2) Incident Collection, Reporting, and Analysis

The IMSS did not ensure that this element of the emergency management program was fully implemented. Although detailed procedures for components to follow when reporting computer security incidents were developed, the IMSS did not verify that these procedures were implemented and being followed, nor did the IMSS ensure that security incident data was being collected and analyzed.

The JMD CSS developed the June 27, 2002, Standards, Guidelines, and Standard Operating Procedures for the DOJCERT (Department Manual TP-001). This directive was developed in response to an increase in computer attacks and contains detailed procedures for effective handling and reporting of computer security incidents. Department Manual TP-001 identifies and defines the following nine computer security incident categories.

• System Compromise: An unauthorized user gains system privileges on Department computers.

• Information Compromise: A weakness in a Department system is exploited that allows unauthorized access to password files, protected or restricted data, system resources, and software/code but does not gain system privileges.

• Unauthorized Access: A valid Department account is used without permission of the owner.

• Denial of Service: Department resources are unavailable for use by an authorized user.

• Misuse: An authorized user violates federal law or regulations and/or Department policies regarding proper use of computer resources, installs unauthorized or unlicensed software, or accesses resources or privileges that are greater than those assigned.

• Hostile Probes: One or more systems are used to scan targeted Department systems or networks with the intent to conduct or to gather information for unauthorized or illegal activities.

• Malicious Software: Software developed with the intent to run on and cause harm to Department computers.

• Intrusions: Access by unauthorized individuals to Department systems that bypasses authentication mechanisms, exploits vulnerabilities in system services, eavesdrops, or monitors networks.

• Theft: Unauthorized removal of Department information and computer equipment.

Because incidents may have many possible consequences ranging from slight to catastrophic, Department Manual TP-001 outlines five priorities to consider when evaluating and dealing with computer security incidents.

• Priority 1: Protect human life and people's safety.

• Priority 2: Protect National Security Information (NSI) data.

• Priority 3: Protect SBU data.

• Priority 4: Prevent system damage.

• Priority 5: Minimize disruption of computing resources.

The Department Manual TP-001 also contains detailed reporting requirements for components to follow in reporting computer security incidents. For incidents involving SBU systems, components are required to provide the DOJCERT a verbal report within one working day after an incident has occurred. Within five working days, a written preliminary incident report, containing as much information as possible, is to be submitted. Within ten working days of the resolution of an incident, a written formal report is to be submitted, and in cases where incident resolution is expected to take more than 30 days, a status report is to be submitted to the DOJCERT every 10 days. For incidents involving NSI, components follow the same reporting requirements with the exception that the reports are provided to the Department Security Officer rather than to the DOJCERT.

Although detailed procedures were developed by the CSS for components to follow in reporting computer security incidents, the IMSS could not substantiate whether the procedures were implemented and were being followed. According to IMSS staff, tabulated summaries on the number and type of incidents are reported each month. However, the IMSS could not provide tabulated summaries regarding the nature, frequency, category, and remediation of prior Department computer security incidents or possible trends and potential systemic weaknesses based on analyses of prior incidents. In addition, the IMSS did not verify whether additional procedures for collecting and analyzing incidents as required by the CIP Plan were developed and in place. We asked the IMSS for an explanation why no verification of additional procedures occurred but the IMSS officials provided no response. Although there is no specific requirement that the IMSS maintain documentation for these activities, absent such documentation, the Department does not have the assurance that additional procedures for collecting and analyzing incidents as required by the CIP Plan were developed and in place.

Absent the documentation described above, the IMSS will have little assurance that it is developing effective countermeasures from prior attacks and providing this knowledge to components to enhance response capabilities.

(3) Response Plans

We determined that the IMSS did not fully implement this element of the emergency management program. Although requirements had been established for developing, implementing, and testing incident response procedures, the IMSS did not verify whether the procedures were in place and operating.

Department Manual TP-001 requires each Department component to: a) develop, implement, and maintain internal incident response procedures, and b) identify an appropriate individual responsible for reporting incidents to the DOJCERT. The Manual also provides the minimum level of procedures for component incident response programs and specifies that the response procedures should be documented by each component and submitted to the DOJCERT to be kept on file.

In addition to developing Department Manual TP-001, JMD CSS also developed the June 17, 2002, DOJCERT Procedures Manual, which outlines CSS Service Center and DOJCERT procedures for responding to Department computer security incidents.³¹ In responding to an incident, the CSS Service Center assigns a number to the incident and completes an incident report form that is forwarded to an incident manager then to the DOJCERT program manager for investigation and resolution.³²

Upon notification of the incident, the DOJCERT Program Manager performs an initial assessment by: a) reviewing the incident report to determine the severity of the problem; b) locating sources and organizing steps for solutions; c) determining who should be notified and involved in working the solution; d) determining whether a Security Alert needs to be broadcast;³³ and e) determining whether the FBI, NIPC, Federal Computer Incident Response Center (FedCIRC) or SEPS need to be notified.³⁴ After completing the initial assessment, the Program Manager then initiates the solution identified during the assessment process and updates the ticket management system with information about the implemented solution and the incident response process.

Although detailed response procedures for computer security incidents had been established, the IMSS had not ensured that the procedures were implemented and being followed. Specifically, the IMSS did not verify whether components had developed, implemented, and maintained internal incident response procedures and whether components had identified appropriate individuals responsible for reporting incidents to the DOJCERT. Although there is no specific requirement that the IMSS maintain documentation for these activities, absent such documentation the Department does not have assurance that response procedures are effective.

In May 2003, we sought any changes in these procedures. Information and Management Security Staff indicated that they were able to provide summary information on computer incidents, but as of June 6, 2003, no documentation had been provided.

In a 2002 review of the FBI's Automated Case Support System pursuant to the GISRA, OIG auditors determined that the FBI is not following the incident response requirements outlined in Department Manual TP-001.³⁵ Specifically, personnel had not been formally trained to identify and handle incidents and the incident response procedures had not been centralized or implemented across the FBI. This condition occurred because the FBI had not yet developed incident response procedures that meet the requirements of the DOJCERT or trained employees in the incident response procedures and requirements. As a result, the FBI increased its risk of having incidents occur without its knowledge or proper follow-up. Had the IMSS verified implementation of the DOJCERT requirement, such lapses in complying with incident response requirements could have been avoided.

Additionally, although the CIP Plan requires periodic testing of response plans, such testing had not been conducted. Information Management and Security Staff officials maintained that response plans were in fact tested during the last major incident involving a computer worm; however, a response during a single actual incident does not constitute complete testing of the response plans because some aspects of the plan may not be involved in the response to a single live incident.³⁶ The IMSS officials added that testing was also unnecessary because they frequently received component warnings from the DOJCERT. They reasoned they could only receive such warnings if the response plans were working. We disagree with this reasoning because a single incident may test some aspects of a response plan while a complete test would check all aspects of the response plans. Testing of response plans is crucial to identifying weaknesses prior to the occurrence of an actual incident.

(4) Contingency Plans

We determined that the IMSS did not fully implement this element of the emergency management program. Although requirements had been established requiring components to develop and periodically test contingency plans, we found that the majority had not done so.

On July 12, 2001, the JMD Information Management and Security Office issued the Department Order 2640.2D, requiring components to develop contingency plans for: a) continuing missions in the event IT systems become unavailable, and b) recovering IT systems in event of loss or failure. In complying with the Department Order, components must ensure that contingency plans:

• identify the priorities of the system for restoration, taking into consideration the system's role in fulfilling the Department mission and interdependency requirements;

• determine the maximum amount of elapsed time permissible between an adverse event and putting the system's contingency plan into operation;

• determine the maximum amount of data and system settings that can be lost between the service interruption event and the last back-up (this measure determines system back-up policies); and

• identify interdependencies with other Department of Justice, state, or local agency systems that could affect contingency operations.

The Department Order also requires components to: a) test contingency resumption plans annually or as soon as possible after a significant change to the environment that would alter the in-place assessed risk, and b) develop and maintain site plans detailing responses to emergencies for IT facilities.

Although the Department Order required components to develop and test contingency plans as well as site plans detailing responses to emergencies for IT facilities, the IMSS could not provide support that components had done so. We noted the following deficiencies.

• From the January 2001 MEI, the IMSS was able to provide contingency plans for 12 of the 20 critical IT systems. In regard to the other eight systems, IMSS officials explained that: a) for six of the classified systems, the contingency plans were kept with SEPS, b) the contingency plan for one system was being updated, and c) for two systems the plans were no longer relevant since the systems were being reengineered and were not operational.³⁷ Although these explanations as to why the IMSS did not have contingency plans were plausible, the explanations were not supported by any documentation. Absent such documentation, it is not evident that the IMSS was carrying out its assigned oversight responsibilities.
  
  We updated the audit information in key CIP areas in May 2003. From the December 2002 MEI, the IMSS was able to provide contingency plans for only 9 of the 21 critical IT systems. According to IMSS officials, the classified files had been transferred from SEPS to the IMSS. Information Management and Security Staff officials explained that the DEA housed their own contingency plans at various locations. When asked to provide documentation of the IMSS's review of the DEA contingency plans, IMSS officials were not able to provide any. Information Management and Security Staff stated that SEPS maintained very few contingency plans for the FBI. As a result, few FBI files were transferred to the IMSS. We attempted to review the FBI contingency plan but were not provided those plans by IMSS. Additionally, IMSS staff indicated that they were in the process of putting the FBI on a performance plan for the development of contingency plans for its systems without plans.

• Contingency Plans did not contain all elements required by Department Order 2640.2D. We judgmentally selected and reviewed contingency plans for the INS's INSINC System and the Department's CJIS WAN. As demonstrated in the following table, our review disclosed that required elements were not addressed for either contingency plan. This condition occurred, in part, because neither contingency plan showed coordination or approval actions by either the component or IMSS officials.
  
  
  Evaluation of INSINC and CJIS WAN Contingency Plans

  Required Element	INSINC	CJIS WAN
  Identify system priorities for restoration.	Not Addressed	Not Addressed
  Determine maximum amount of elapsed time permissible between an adverse event and putting the contingency plan in operation.	Not Addressed	Not Addressed
  Determine the maximum amount of data and system settings that can be lost between the service interruption event and the last back-up.	Not Addressed	Not Addressed
  Identify interdependencies with other systems.	Addressed	Not Addressed
  Identify system owners, roles, and responsibilities.	Addressed	Addressed

  Source: OIG analysis
  In the 2002 "Summary of the OIG Fiscal Year 2002 Evaluation of the Department of Justice Information Security Program and Practices Pursuant to the Government Information Security Reform Act" report submitted to the OMB, OIG auditors found that the Department had weaknesses in contingency planning. This weakness was identified as a repeat weakness from the 2001 OIG report.

• Contingency plans were not tested annually as required by Department Order 2640.2D. As discussed previously, the Department first established its MEI of 20 computer assets in January 2001. This inventory was revised in December 2002 and the resulting MEI consists of 21 computer assets. Only three of the systems included on the January 2001 MEI had undergone contingency plan testing. One system with a tested contingency plan was dropped from the December 2002 MEI and another with a tested contingency plan was added. IMSS officials could not determine the status of contingency plans testing for any of the remaining eight assets newly added to the MEI as of May 2003. None of the other systems that remained from the January 2001 MEI had tested contingency plans. IMSS officials were unable to determine the status of the newly added assets because they received no response from the components to their queries. IMSS officials explained that testing of contingency plans was expensive and funds were not available; however, they were unable to provide documents showing that funding had been requested and denied. IMSS officials indicated that the Department's Chief Information Officer had intended to issue a memorandum to components stressing the importance of testing contingency plans and providing guidance on how to perform and obtain funding to pay for the tests. As of May 2003, the document had not yet been issued.

C. Overall Causes for and Effect of Not Fully Implementing an Emergency Management Plan

Although the CIP Task Force was charged with developing and implementing the Emergency Management program, the Task Force never did so. Information Management and Security Staff officials stated that the Task Force last met during calendar year 2000 and was no longer in existence. They added that the Task Force's primary responsibility when it did meet was to work on Year 2000 conformity issues.³⁸ According to an IMSS official, once the Year 2000 conformity issues were resolved, the task force no longer convened. In response to our inquiries, IMSS officials could provide no explanation as to why no further effort was made to implement the plan.

Further, the IMSS officials stated that although the emergency management program as envisioned in the CIP Plan had not been implemented, they believed that most of the elements of an effective emergency management program were nevertheless in place and operating throughout the various Department components. We do not agree with this assessment because several of these elements are not adequately operating. Unless a centralized effort is made to verify that the various component parts of the CIP Plan are in place and operating, the Department will have little assurance that it can effectively respond to emergency computer security incidents.

D. Conclusions

Although the CIP Plan contained a comprehensive blueprint and milestones for creating an effective emergency management program by September 1999, such a program was not fully implemented as demonstrated in the following table.

In evaluating the Department's response capabilities to computer security incidents, we found that many critical elements related to indications and warnings, incident collection, reporting and analysis, and response and contingency planning were neither established nor operating. We agree that other elements are operating, but not adequately for a successful emergency management program. Until the critical elements of an effective emergency management program are in place and operating, the Department will have less than adequate assurance that it can effectively respond to attacks to its critical infrastructure technology systems.

E. Recommendations

We recommend that the Assistant Attorney General for Administration:

9. Define standards for secure, timely, and effective communication channels for passing indications and warning information and ensure those standards are implemented and operating.

10. Ensure that effective liaisons are established with the DHS's FedCIRC and the FBI's Strategic Information Operations Center and NIPC.

11. Ensure that components are in compliance with procedures for reporting incidents.

12. Ensure that data regarding departmentwide computer attacks and security incidents are collected and summarized according to the nature, frequency, category, and remediation actions taken and that analyses are performed to identify potential trends and systemic weaknesses.

13. Verify that incident data is provided to: a) the NIPC as part of the National Critical Infrastructure Indications and Warnings System, and b) the budget processes to support and justify future CIP resource expenditures.

14. Verify that components have developed, implemented, and maintained internal incident response procedures and have identified appropriate individuals for reporting incidents to the DOJCERT.

15. Ensure periodic testing of response plans.

16. Develop contingency plans for all critical IT assets.

17. Ensure that documentation is maintained supporting the existence or development of contingency plans for all critical infrastructure assets.

18. Verify that contingency plans address all required elements as identified by Department Order 2640.2D.

19. Obtain appropriate approvals for all contingency plans by component and IMSS officials.

20. Test contingency plans periodically as required by Department Order 2640.2D.

28. The CIP Plan did not contain details as to how the communication channels would operate or how the communication channels would be implemented.
29. An incident is an occurrence that has been assessed as having an adverse effect on the security or performance of an information system.
30. In May 2003, the IMSS name changed to the Information Technology Security Staff (ITSS). The ITSS retained the prior IMSS staff and responsibilities for oversight of the CIP program. The ITSS gained responsibility from JMD Computer Services Staff for managing the DOJCERT.
31. The CSS Service Center was the front-end support for the DOJCERT incident and inquiry response operations. In most cases, the Service Center was the initial point-of-contact or first-level support for the DOJCERT operations staff. Since May 4, 2003, the incident and inquiry response functions have moved to the ITSS.
32. The Program Manager is responsible for directing and managing the personnel and operations of the DOJCERT.
33. A Security Alert should be sent under the threat and warning reporting procedures if the incident has affected or is likely to affect more than one component.
34. Within the DHS, the FedCIRC is the central coordination and analysis facility dealing with computer security-related issues affecting the civilian agencies and departments of the federal government.
35. See "Independent Evaluation Pursuant to the Government Information Security Reform Act Fiscal Year 2002" (Audit Report 03-06).
36. A computer worm is a program that replicates itself and often contains some functionality that interferes with the normal use of a computer or program. Unlike viruses, worms exist as separate entities spreading automatically over networks from one computer to the next.
37. The DEA's EIS consists of a classified and unclassified portion. IMSS possessed a copy of the contingency plan for the unclassified portion but not for the classified portion. This difference results in EIS being counted twice even though there are only 20 systems that comprise the January 2001 MEI. See Appendix 5 for more detail.
38. Year 2000 conformity ensured that Departmental IT system performance and functionality would not be affected by dates prior to, during, and after the year 2000.