The Department has developed a computer security Incident Response Plan that provides standard reporting procedures that all Department components are required to follow. In December 2003, at the direction of the Chief Information Security Officer, DOJCERT developed an Incident Response Plan template to standardize procedures Department-wide for responding to and handling computer security incidents. Each of the nine Department components we reviewed has developed an Incident Response Plan that conforms to the DOJCERT template. The following is a summary discussion of:

• Reporting procedures that the nine components have established for reporting and responding to computer security incidents;

• Determining the type of data lost; and

• Defining sensitive information, PII, and reportable loss.

In addition, we identify best practices, recent developments, and future plans. Detailed discussions of the above areas for each component are included in Appendices I through IX.

Reporting and Responding to Computer Security Incidents

Written Procedures

All of the nine components the OIG reviewed have official written procedures for their employees to follow when reporting computer security incidents. All nine components have developed their own component-specific Incident Response Plans that follow the DOJCERT Incident Response Plan template. The Incident Response Plans are the primary written guidance for the components’ IT staff response to and reporting of computer security incidents involving sensitive information, including PII, to DOJCERT.

DOJCERT updates the Incident Response Plan template as needed, but at least annually, to reflect new statutory or OMB requirements or emerging computer security threats. In November 2006, DOJCERT revised its Incident Response Plan template to require for the first time that the components add language that identifies loss of PII as a distinct type of reportable incident and that defines the category and timeframe (1 hour) for reporting these data loss incidents.

As of April 2007, seven of the nine components we reviewed had updated Incident Response Plans that conformed to the November 2006 DOJCERT template revision: the BOP, the Criminal Division, the DEA, EOUSA, the FBI, JMD, and the Tax Division. The remaining two components, ATF and the USMS, had not yet submitted their revised Incident Response Plans to DOJCERT for approval.

The DOJCERT template provides instructions for reporting computer security incidents to DOJCERT, but it does not dictate the internal reporting requirements within each component. Therefore, to supplement the DOJCERT template, each component has developed additional policies, memorandums, or practices for its employees that provide more detailed reporting and incident response procedures. These supplemental policies provide further tools to help components respond to computer security incidents or identify when data loss may have occurred. For example, components have policies that tell their employees how to identify reportable computer security incidents and how to contact internal IT staff to report such incidents. While all nine components reviewed have multiple policies, two of the components have policies that provide contradictory or faulty chain-of-command reporting procedures. ATF staff has received contradictory instructions on which office is the primary point of contact for reporting computer security incidents. The USMS policy instructs employees to report computer security incidents to staff titles and internal departments that either no longer exist or are inaccurate. Appendix XI identifies the policies that each component developed and relies on for guidance related to computer security incidents.

Four of the nine components have developed separate procedures for staff to follow if an incident is reported after normal business hours. One component’s procedures were the same 24 hours a day. The remaining four components have no specific written procedures covering such incidents.³⁵ We found that at least 19 percent of the incidents reported between December 2005 and November 2006 occurred after hours (6:00 p.m. to 6:00 a.m.).

Between December 1, 2005, and November 30, 2006, the 9 components the OIG reviewed reported 1,501 computer security incidents to DOJCERT. During this same period, all 40 Department components reported 2,162 incidents. (See Table 1 for the number of incidents reported by each of the nine components reviewed.)

Of the 1,501 incidents reported by the 9 components in this review, 19 incidents involved the actual loss of PII and an additional 228 incidents involved the potential loss of PII. The number of PII incidents could be underreported because until July 2006 there was no requirement to identify and report whether incidents involved the loss of PII.³⁶ Prior to July 2006, the components’ internal records may have indicated whether incidents involved the loss of PII, but the components were not required to report this detail to DOJCERT. According to the Archer Database, 5 actual losses of PII and 43 potential losses of PII were reported during the 8 months between the December 1, 2005, start of our review period and July 12, 2006, when the reporting requirement went into effect.

The 1,501 incidents also included 57 incidents involving classified information.³⁷ The remaining 1,215 incidents involved spam, computer viruses, or other types of incidents that did not involve either PII or classified information. Table 2 gives the breakdown of the types of incidents reported by the nine components.

Compliance with Reporting Procedures

IT security staff and other staff with related duties we interviewed in all nine components stated that their staff generally followed procedures established for reporting computer security incidents through their chain of command up to component headquarters. In this review, we did not test to verify those statements. However, in reviewing the information the FBI provided to us and the information we analyzed from the Archer Database, we noticed a discrepancy between the number of lost electronic devices that had been reported within the FBI and the number of lost electronic devices that the FBI had reported to DOJCERT. Therefore, we asked the FBI some additional questions to determine whether they were following their reporting procedures. We found that the FBI was not always following the procedures required in the DOJCERT Incident Response Plan template or its own required procedures.

Within the FBI, computer security incidents are reported to two separate offices, but only one of those offices is required to report incidents to DOJCERT. The FBI’s Security Policy Manual requires staff to report computer security incidents to the FBI’s Security Compliance Unit. The FBI’s four Incident Response Plans require staff to report computer security incidents to the FBI’s Enterprise Security Operations Center.³⁸ Only the Enterprise Security Operations Center reports computer security incidents to DOJCERT.

We found that the FBI is not in full compliance with DOJCERT’s requirement that all lost or stolen electronic devices be reported.³⁹ In reviewing the information the FBI provided, and in our analysis of information from the Archer Database, we noticed a discrepancy between the number of lost electronic devices that had been reported to the FBI’s Security Compliance Unit and the number of lost electronic devices that had been reported to the Enterprise Security Operations Center and to DOJCERT. For the period from December 2005 through November 2006, FBI employees reported 35 lost or stolen laptops to the Security Compliance Unit, but only 7 lost or stolen laptops were reported to the Enterprise Security Operations Center.⁴⁰ The underreporting of incidents to the Enterprise Security Operations Center caused an underreporting of incidents to DOJCERT and US-CERT. Table 3 below shows the number of lost or stolen FBI laptops that were reported.

In addition to not reporting all incidents of lost electronic devices to DOJCERT, we found the FBI was underreporting classified computer security incidents to both SEPS and DOJCERT. The Department’s Security Program Operating Manual (SPOM) requires that all 40 Department components report classified computer security incidents, including those involving losses of classified information, to SEPS. A t least 72 classified computer security incidents that were reported to the Security Compliance Unit by FBI employees between December 2005 and November 2006 were not reported to either SEPS or DOJCERT as required. FBI policy does not require the Security Compliance Unit to report any computer security incident to any entity outside the FBI, including SEPS. FBI policy only requires the Enterprise Security Operations Center to report computer security incidents to DOJCERT. For additional details on FBI compliance with reporting procedures, see Appendix VI.

Timeliness of Reporting All Computer Security Incidents

We found that the components were not always timely in reporting all occurrences of computer security incidents, especially those involving PII, to DOJCERT. Further, DOJCERT was not always timely in reporting all occurrences of computer security incidents, especially those involving PII, to US-CERT.

Timeliness of Components’ Reporting Computer Security Incidents Overall. Between December 2005 and November 2006, 66 percent of the computer security incidents were reported in a timely manner by the nine components overall. However, only one of the nine components reported nearly all of its computer security incidents within specified timeframes. We analyzed data from DOJCERT’s Archer Database to determine the amount of time that elapsed between the occurrence of a potential or actual computer security incident and the time the incident was reported to DOJCERT. The timeframes are defined in the DOJCERT Incident Response Plan template and the components’ Incident Response Plans and vary for the seven categories of computer security incidents the plans address.⁴¹

Between December 2005 and November 2006, the Tax Division made timely reports for 95 percent of its reported computer security incidents. The other eight components reported between 37 percent and 84 percent of their security incidents on a timely basis. Table 4 shows the timeliness in reporting to DOJCERT by category of incident for all components.⁴²

Timeliness of Components’ Reporting of PII Incidents. The 9 components in this review reported 199 potential or actual losses of PII to DOJCERT between July 12, 2006, and November 30, 2006. Only 15 percent of those incidents were reported within 1 hour to DOJCERT, and none of the PII incidents were reported to US-CERT within 1 hour of discovery or detection. Table 5 provides data on the nine components’ timeliness in reporting actual and potential PII incidents to DOJCERT.

Although OMB requires that all potential or actual losses of PII be reported within 1 hour to US-CERT, the median time for the nine components to report such incidents to DOJCERT was slightly over 12 hours.⁴³ Chart 2 shows the components’ timeliness in reporting PII incidents to DOJCERT within the first 24 hours after occurrence. The components reported 66 PII incidents (36 percent) to DOJCERT more than 24 hours after occurrence.

Chart 2: Components’ Timeliness in Reporting PII Incidents to DOJCERT Within the First 24 Hours After Occurrence

[Image Not Available Electronically]

Source: Archer Database

When discussing their timeliness in reporting PII incidents, the nine components’ staff told us there was a lack of clarity as to when the 1-hour reporting timeframe begins and ends. OMB’s July 12, 2006, memorandum requires federal agencies to report computer security incidents to US-CERT within 1 hour of discovery. However, the Department’s November 2006 revision of its Incident Response Plan template requires that PII incidents be reported by the components within 1 hour of discovery or detection to DOJCERT. By allowing 1 hour for reporting to DOJCERT, the incident response plan appears to conflict with the OMB directive that incidents be reported to US-CERT within 1 hour of discovery or detection.

Component staff told us that component employees interpret the OMB requirement to mean that they have 1 hour to report incidents to their component’s IT staffs. We found the components’ IT staffs interpret the OMB requirement to mean that they have 1 hour to report incidents to DOJCERT. DOJCERT interprets the OMB requirement to mean that it has 1 hour from the time it is notified of an incident to report that incident to US-CERT. Therefore, the components may need further clarification from the Department on when the 1-hour window for reporting PII incidents begins and ends, and who must receive the report within 1 hour of discovery or detection – component IT staff, DOJCERT, or US-CERT. Officials from three components remarked that the 1-hour timeframe was impractical and unrealistic.

For our analysis, we assessed the amount of time that that elapsed between an incident’s occurrence and when the component reported the incident to DOJCERT. For those incidents that were reported within 1 hour to DOJCERT, we determined if they were also reported to US-CERT within the same 1-hour period. We also assessed the amount of time that elapsed between when DOJCERT received notice of an incident and when DOJCERT reported that incident to US-CERT.

Because the 1-hour requirement is relatively recent, we also examined whether the components’ timeliness in reporting PII incidents to DOJCERT was improving. To examine this, we compared incidents that occurred between July 12, 2006, and September 20, 2006, with incidents that occurred between September 21, 2006, and November 30, 2006.⁴⁴ We found that the components’ reporting data suggests that their performance improved over time. Only 5 of the 76 potential or actual losses of PII that occurred between July 12, 2006, and September 20, 2006 (7 percent) were reported to DOJCERT within 1 hour of the incidents’ occurrence.⁴⁵ However, between September 21, 2006, and November 30, 2006, 22 of the 106 potential or actual losses of PII (21 percent) were reported to DOJCERT within 1 hour of the incidents’ occurrence.⁴⁶ (See Chart 3.)

Chart 3: Timeliness of Reporting PII Incidents Improved Over Time

Source: Archer Database

Timeliness of DOJCERT’s Reporting of PII Incidents. Between December 2005 and November 2006, DOJCERT reported 61 percent of computer security incidents to US-CERT in a timely manner. However, our analysis also showed that DOJCERT reported only 12 percent of the potential or actual losses of PII to US-CERT within 1 hour of being notified by the components of the incidents.⁴⁷ DOJCERT reported 88 percent of the potential or actual losses of PII to US-CERT more than an hour after being notified by the components.⁴⁸ See Table 6 for data on DOJCERT’s timeliness in reporting PII incidents to US-CERT.

The median time taken by DOJCERT to report potential or actual losses of PII to US-CERT was slightly under 24 hours, with 67 of the incidents being reported more than 24 hours after the components notified DOJCERT that they had occurred. Chart 4 shows DOJCERT’s timeliness in reporting PII incidents to US-CERT within the first 24 hours after receiving notice that the incident had occurred.

Chart 4: DOJCERT’s Timeliness in Reporting PII Incidents to US-CERT Within the First 24 Hours After Receiving Notice

[Image Not Available Electronically]

Source: Archer Database

Ensuring that All Incidents Are Reported

The nine components stated that they cannot ensure that all incidents are reported, but they identified training as their primary method for ensuring that employees are aware of the requirement to report data loss incidents, including those involving PII. This training includes:

• Computer Security Awareness Training – Seven of nine components identified the Department’s annual Computer Security Awareness Training as a way to ensure that all employees are aware of the reporting requirements.⁴⁹ This training consists of a 1-hour online PowerPoint presentation. The fiscal year 2007 Computer Security Awareness Training included, for the first time, a section on data loss reporting procedures, including PII. Additionally, the training defines computer security incidents, reviews the protection of systems information, and explains the consequences of lost or breached sensitive information.

• Standards of Conduct and IT Rules of Behavior – Two components use the Department’s Standards of Conduct, and seven components use their own IT Rules of Behavior as other forms of training to inform all employees of their responsibilities related to computer use, including reporting all computer security incidents or vulnerabilities (as well as losses of sensitive information), accountability for and confidentiality of federally owned information, and reporting any loss or damage to laptops or BlackBerry devices.⁵⁰ All of those components’ employees must read and sign the IT Rules of Behavior.

Two components use additional methods to make employees aware of the requirement to report data loss incidents:

• The Criminal Division displays security tips on computer monitors after employees have entered their passwords and are waiting for the computers to connect to the division’s network.

• The Tax Division posts the reporting requirements for data loss prominently on its intranet to make them readily accessible to employees.

Notification to Affected Parties

The Department does not have a policy to notify affected parties of a loss of PII. According to recent Government Accountability Office testimony, “... existing laws do not require agencies to notify the public when data breaches occur....”⁵¹ However, the Department’s Office of Privacy and Civil Liberties is circulating a draft Department-wide notification policy.

None of the nine components we reviewed had a written policy for notification. Four of the components reviewed offered suggestions for what the component might do if a loss of PII occurred, and three stated that the Department or OMB should develop a Department-wide notification policy so that responses would be standardized and consistent.

Determining the Type of Data Lost

All nine components informed us that when a computer security incident is discovered, the employee who reported the data loss is interviewed to determine what sensitive information the lost device or removable storage media may have contained. For most components, this consists of informal questioning in an attempt to assist the employee in reconstructing what occurred and to identify the information that the device contained. DOJCERT’s Incident Response Plan template and the components’ Incident Response Plans contain a section that provides general guidelines on how to respond to incidents. Three components – ATF, the FBI, and the USMS – have developed a questionnaire for use when interviewing the employee to identify the contents of the lost or compromised sensitive information.

ATF, the Criminal Division, the DEA, the FBI, and the USMS reported that they use computer forensic techniques in certain situations to supplement the employee’s account of what information or files were stored or accessed by the employee. For example, the Criminal Division and the DEA reported that for incidents involving a lost BlackBerry device, the BlackBerry Exchange Server allows them to identify the e-mails that were received and sent the last time the device was used. All components can send a “kill signal” to a BlackBerry device once its loss is known, rendering it useless and the information on it inaccessible.

Defining Sensitive Information, PII, and Reportable Data Loss

The Department has developed a standard definition for sensitive information but has not developed its own definitions for PII and what constitutes a reportable data loss. The Department’s definition for sensitive information in its Security Program Operating Manual (SPOM), which is distributed to the components’ Security Programs Managers, is:

Any information, the loss, misuse, modification of, or unauthorized access to, could affect the national interest, law enforcement activities, the conduct of Federal programs, or the privacy to which individuals are entitled under Section 552a of Title 5, U.S. Code, but that has not been specifically authorized under criteria established by an executive order or an act of Congress to be kept classified in the interest of national defense or foreign policy.⁵²

However, officials in seven of the nine components we reviewed stated that basically all of their information is sensitive. One component official stated, “We’ve lowered it [the definition of sensitive information] to a point where nearly everything is sensitive and that’s a problem.”

The Department has not issued its own definition of PII but instead relies on the definition set forth in OMB Memorandum M-06-19:

[A]ny information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual.

Two components stated that this definition may lead components to over designate information as PII because the OMB definition is too broad and overly vague. One component official stated that even his government e-mail address was considered PII. Another component official voiced concern that the terms PII and sensitive are now interchangeable. Most of the components expressed the opinion that the Department needs to develop its own definition of PII.

In addition, we found no standard Department definition of a reportable data loss. However, the components provided a variety of answers when defining what they considered a reportable data loss. Their responses were generally in line with the causes of data loss described in the DOJCERT Incident Response Plan template, which notes that data loss can be caused by:

• Loss or theft of a laptop, removable storage medium, or portable computing device containing PII or sensitive information;...
• Successful phishing, pharming, or social engineering by a malicious attacker;
• Hacker intrusion through network and system defenses;
• Spyware, viruses, worms, Trojan horses, rootkits, backdoors, keyloggers, or other malicious code installed on a computing device;
• Eavesdropping of communications at public Internet access points, such as cyber cafes or hotels;
• Eavesdropping of wireless communications;...
• Failure to secure unattended documents containing sensitive information or PII; and
• Failure to clean sensitive information or PII from computers or storage devices before they are discarded.⁵³

For more discussion on each component’s definitions of sensitive information, PII, and a reportable data loss, see Appendices I through IX.

Best Practices in Increasing Employee Awareness

The OIG believes the following procedures or policies used by four of the nine components could be considered as a Best Practice. These components are taking additional steps to either minimize unauthorized access to sensitive information or to educate employees on their reporting responsibilities:

• The Tax Division reinforces employees’ awareness of the 1-hour reporting requirement for loss of PII by posting this information prominently on its intranet.

• The Criminal Division displays a variety of security tips, including procedures for reporting computer security incidents, on computer monitors when employees first log in.

• JMD Personnel staff receives verbal briefings on the procedures for reporting computer security incidents when they are given the equipment necessary to use the Justice Secure Remote Access system and also receive a wallet card summarizing those reporting procedures.

• BOP policy requires that to remove sensitive information from a BOP facility, an employee must obtain written approval from the Chief Executive Officer (CEO) of the facility. When requesting approval, the medium of the sensitive information (e.g., paper documents, electronic files), a description of the equipment being used and the contents, and the purpose for the removal must be documented along with the CEO’s approval.⁵⁴

Recent Developments and Future Plans

The Department frequently updates its guidance on data loss incidents and privacy issues, or changes its policies to address a newly identified need. For example, the Department must comply with the Privacy Act, which regulates the collection, maintenance, use, and dissemination of certain types of personal information maintained by federal agencies.⁵⁵ The Act prohibits the disclosure of such information except with the prior written consent of the individual to whom the information pertains or if the disclosure falls within one of 12 statutory exceptions.⁵⁶ One of these exceptions permits disclosure for a “routine use,” which is defined as “the use of such record for a purpose which is compatible with the purpose for which it was collected.”⁵⁷ Consistent with the Act, the Department and its components have published in the Federal Register its routine uses, “including the categories of users and the purpose of such use[s].”⁵⁸

As part of its response to a data breach, the Department might be required to disclose information protected by the Privacy Act. For example, an official with the Office of Privacy and Civil Liberties observed that the Department of Veterans Affairs, in responding to the May 2006 laptop theft, contacted other federal agencies to determine whether the contact information it had for the affected individuals was correct. In such a case, the Department would need to rely on a routine use to authorize the disclosure. Accordingly, the Office of Privacy and Civil Liberties reviewed the Department’s existing published routine uses and determined that a new routine use to cover this situation was required.

In October 2006, the Department published a notice in the Federal Register describing this new routine use. The routine use would “facilitate an effective response to a confirmed or suspected [data] breach by allowing for disclosure to those individuals affected by the breach, as well as to others who are in a position to assist in the Department's response efforts.” The provision went into effect in December 2006.⁵⁹

In February 2007, the Department’s Office of Privacy and Civil Liberties added a Privacy Resources page to the Department’s intranet. This page provides Department employees with OMB’s definition of PII, guidance and templates for preparing Privacy Impact Assessments, copies of DOJ Orders and Department guidance related to the general protection of privacy, and links to OMB privacy guidance.⁶⁰

The Office of Privacy and Civil Liberties and the Office of the CIO have also drafted a Department-wide policy on notification of affected parties in the event of a data loss incident that could result in identity theft. To ensure that the Department makes notification decisions in a consistent manner, the final determination about whether to notify affected parties in each situation will be made by high-ranking Department officials rather than by component officials. The draft policy calls for the establishment of an Identity Theft Core Management Team, which will convene in the event of a data breach and analyze the situation to determine the risk of identity theft.⁶¹ If the management team determines that there is a risk of identity theft, and that affected individuals should be notified, the policy outlines factors that should be incorporated into the Department’s response, including timing and the contents and methods of notification. Once this policy is finalized, DOJCERT plans to issue an addendum to the DOJCERT Incident Response Plan template explaining the procedures and the components’ roles in relation to them.

DOJCERT told us that later in fiscal year 2007 it plans to release an Incident Response Handbook to provide the components with additional guidance on determining the type of data contained on lost equipment. The handbook will provide guidance to the components on:

• Information-gathering techniques during and following an incident,
• Techniques for determining the type of data included on lost equipment, and
• Methods for identifying the level of residual risk associated with each incident.

35. Two of these components have developed draft procedures but, as of April 2007, those procedures had not yet been issued.

36. OMB Memorandum M-06-19 for Chief Information Officers, Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, Karen S. Evans, July 12, 2006.

37. One of the incidents involving the actual loss of PII also involved classified information. Seventeen of the incidents involving the potential loss of PII also involved classified information.

38. All four of the Incident Response Plans conform to the DOJCERT template.

39. The OIG recently conducted an audit that describes in greater detail the FBI’s processes for identifying and reporting lost or stolen laptop computers. See OIG, The Federal Bureau of Investigation’s Control Over Weapons and Laptop Computers Follow-Up Audit, Audit Report 07-18, February 2007.

40. FBI officials told us that 35 lost or stolen laptops were reported to the Security Compliance Unit. We reviewed data from DOJCERT’s Archer Database and determined that seven lost or stolen laptops had been reported to the Enterprise Security Operations Center and to DOJCERT. We did not verify those reports.

41. See Appendix XII for a detailed description of each category. An additional category is used for training exercises only.

42. Our calculations are based on Categories 1 through 5 and Category 7. We did not include incidents found in Categories 0 and 6 because they had no associated time criteria, nor did we include incidents for which the Archer Database contained no information to indicate when DOJCERT received the report that an incident had occurred.

43. The median refers to the middle number of a group of numbers; that is, half the numbers have values that are greater than the median, and half the numbers have values that are less than the median. For example, the median of 2, 3, 3, 4, 5, 7, and 10 is 4.

44. We chose September 20, 2006, as the cutoff date because it is halfway between July 12, 2006, and November 30, 2006.

45. We could not analyze 10 incidents for timeliness because there was no information in the Archer Database to indicate when DOJCERT received the reports.

46. We could not analyze seven incidents for timeliness because there was no information in the Archer Database to indicate when DOJCERT received the reports.

47. For the 199 potential or actual losses of PII, we compared the date and time the incident was reported to DOJCERT with the date and time the incident was reported to US-CERT, to determine how well DOJCERT was meeting the 1-hour timeframe. We could not analyze 64 of the incidents for timeliness because there was no information in the Archer Database to indicate when the report was submitted to US-CERT.

48. DOJCERT staff report incidents to US-CERT by completing a web-based form. DOJCERT staff also print a copy of each completed form and maintain the paper copies in their records. The date and time the form was printed appears automatically at the bottom of the page. DOJCERT staff type this information into the Archer Database for tracking purposes.

49. The seven components were ATF, the Criminal Division, the DEA, the FBI, JMD, the Tax Division, and the USMS.

50. The two components that identified Standards of Conduct were ATF and the DEA. The seven components that identified IT Rules of Behavior were ATF, the Criminal Division, the DEA, the FBI, JMD, the Tax Division, and the USMS.

51. Testimony of David M. Walker, Comptroller General, Government Accountability Office, Privacy: Preventing and Responding to Improper Disclosures of Personal Information (GAO-06-833T), before the House Committee on Government Reform, June 8, 2006.

52. DOJ Security Programs Operations Manual, May 2005, p. A-7.

53. DOJCERT Incident Response Plan template, version 1.3, § 9.4, November 2006. Social engineering is a collection of techniques, such as phishing and pharming, used to manipulate people into performing actions or divulging confidential information. Phishing is e-mail appearing to come from a legitimate business – a bank, or credit card company – requesting “verification” of information and warning of dire consequence if it is not done. Pharming is a hacker’s attack aiming to redirect a website’s traffic to another (bogus) website.

54. BOP, Information Security, P1237.13, March 31, 2006, Chapter 2, p. 14.

55. 5 U.S.C. § 552a. For a comprehensive overview of the Act’s requirements, see www.usdoj.gov/oip/04_7_1.html.

56. 5 U.S.C. § 552a(b).

57. 5 U.S.C. §§ 552a(b)(3) & (a)(7). An example of a published routine use for Department recordkeeping systems is disclosure to any criminal, civil, or regulatory law enforcement authority (whether federal, state, local, territorial, tribal, or foreign) where the information is relevant to the recipient entity's law enforcement responsibilities.

58. 5 U.S.C. § 552a(e)(4)(D).

59. The Department published a minor modification in the Federal Register in January 2007 to clarify that it is the Department that must confirm or suspect a data breach before disclosure would be permitted.

60. The page defines PII as “information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother's maiden name, biometric records, etc., including any other personal information which is linked or linkable to a specific individual.” This is the definition used in OMB Memorandum M-06-19, July 12, 2006.

61. The Identity Theft Core Management Team will consist of the Associate Attorney General; the Assistant Attorneys General for Administration, the Office of Legal Counsel, and the Office of Legislative Affairs; an Associate Deputy Attorney General; the CIO; the Chief Privacy Officer; the Inspector General; and the Director of the Office of Public Affairs.