Cobell v. Norton

394 F. Supp. 2d 164 (2005)

Elouise Pepion COBELL, et al., on her own behalf and on behalf of all those similarly situated, Plaintiffs,
v.
Gale NORTON, Secretary of the Interior, et al., Defendants.

No. CIV.A. 96-1285(RCL).

United States District Court, District of Columbia.

October 20, 2005.

MEMORANDUM OPINION

LAMBERTH, District Judge.

This matter comes before the Court on the plaintiffs' Motion [2926] for Preliminary Injunction, which alleges that the Department of the Interior has insufficient computer security to adequately safeguard the electronically stored Individual Indian Trust Data of which it is a custodian. The Court has considered the plaintiffs' motion, the defendants' opposition, and the plaintiffs' reply, along with the documentary and testimonial evidence adduced at the fifty-nine day evidentiary hearing the Court conducted to resolve this motion. The Court concludes that the plaintiffs' motion will be granted.

BACKGROUND

This is not the first time this Court has addressed the security posture of Interior's information technology ("IT") systems. Interior's numerous and complicated IT systems house and provide access to a massive volume of Individual Indian Trust Data ("IITD") stored in electronic form, which data is essential both to the day-to-day management of the trust and to completion of the full and accurate accounting of the trust that has been mandated by this Court. In light of evidence that Interior's IT security was seriously deficient, the Court has found it necessary to disconnect Interior's IT systems from the Internet more than once before and has granted various other forms of relief to protect electronic IITD.

A. Factual and Procedural History

As early as April 4, 2000, the Court noted problems with Interior's ability to secure electronic trust data. The Court was "alarmed and disturbed," for example, "by the revelation that the [Bureau of Indian Affairs ("BIA")] has no security plan for the preservation of [Indian trust] data." Tr. (Hrng., Apr. 4, 2000), at 11. The Special Master was thus assigned the task of investigating the extent of Interior's IT security problems. During the pendency of the Special Master's initial inquiry, in February, 2001, the D.C. Circuit affirmed this Court's finding that Interior, one of the federal government's trustee-delegates for the Individual Indian Money Trust ("IIM Trust"), breached its fiduciary duty to provide the trust beneficiaries with a full and accurate accounting of their trust assets. See Cobell v. Norton ("Cobell VI"), 240 F.3d 1081 (D.C.Cir.2001). As relevant here, the Court of Appeals noted that "the federal government will be unable to provide an adequate accounting without computer systems, staffing, and document retention policies that are adequate for the task," and remanded the case to this Court for further proceedings. Cobell VI, 240 F.3d at 1109.

On November 14, 2001, the Special Master filed a 154-page report with the Court in which he observed that IITD was housed on Interior IT systems that had "no firewalls, no staff currently trained/capable of building and maintaining firewall devices, no hardware/software solution for monitoring network activity including but not limited to hacking, virus, and worm notification...."^[1] Report and Recommendation of the Special Master Regarding the Security of Trust Data at the Department of the Interior, at 141 (Nov. 14, 2001). The Special Master also noted Interior's "serious lack of wide area networking and security personnel in general," and that "[t]he BIA is also far behind the other bureaus in Interior regarding staffing of messaging systems and infrastructure support." Id.

On December 5, 2001, in response to this report, the Court entered a temporary restraining order requiring "that defendants shall immediately disconnect from the Internet all information technology systems that house or provide access to individual Indian trust data [and] that defendants shall immediately disconnect from the Internet all computers within the custody and control of the Department of the Interior, its employees and contractors, that have access to individual Indian trust data." Temporary Restraining Order [1036], issued Dec. 5, 2001, at 2.^[2] At Interior's request, the Court entered a consent order on December 17, 2001, which authorized Interior to reconnect IT systems to the Internet upon presenting evidence of increased security to the Special Master and gaining his approval. See Consent Order [1063], issued Dec. 17, 2001. Specifically, the Consent Order provided that

the Special Master shall verify compliance with this Consent Order and may conduct interviews with Interior personnel or contractors or conduct site visits wherever information technology systems or individual Indian trust data is housed or accessed.

Consent Order [1063] at 7. Pursuant to this directive, the Special Master hired first IBM, and then in March 2002 the Security Assurance Group ("SAG"), to provide independent evaluations of IT security at various Interior sites and to conduct external penetration testing of Interior's IT systems. External penetration testing, which requires simulating an attempt to gain access to an IT system by an outside "hacker," was governed by rules of engagement agreed to by the Special Master and Interior.

On behalf of the Special Master, SAG performed security assessments and penetration testing of Interior's IT systems between March 2002 and July 2003, finding numerous vulnerabilities that called into question Interior's IT security-related certifications to the Court. For example, despite the Bureau of Land Management's ("BLM") August 11, 2003 certification its intrusion detection system ("IDS") is "monitored by network security personnel on a daily basis," BLM Cert. (Aug. 11, 2003), at 34; SAG's earlier penetration testing of BLM, conducted between February 10, 2003 and March 26, 2003, showed that "throughout all Phases of the testing ... no effort was made by BLM administrators to restrict, block, or deny access from the source of the attacks. SAG believes that none of SAG's activities were detected at any time." Internet Assessment of DOI/BLM Networks (Mar. 27, 2003), at 1.

SAG also found serious vulnerabilities in the Minerals Management Service's ("MMS") IT systems, see generally Assessment of Minerals Management Service — Camarillo Revisit (Mar. 26, 2003), which Interior later informed the Court had not been corrected. See Defs.' Comments on IT Security Repts. Filed by the Special Master in Accordance with this Court's January 21, 2004 Order (Feb. 12, 2004), at 4 n. 7. Similar vulnerabilities were identified in IT systems at the Bureau of Reclamation ("BOR"). See Assessment of Bureau of Reclamation — Sacramento Revisit (Mar. 24, 2003). In assessing IT security at one Office of Surface Mining ("OSM") branch office, SAG found that "the Intrusion Detection System had not been monitored or reviewed by anyone for approximately forty-five days and that an additional system was connected to the Internet for twenty-six days with no Intrusion Detection System implemented at all." Cobell v. Norton ("Cobell XI"), 310 F. Supp. 2d 77, 82 (D.D.C.2004) (citing Assessment of Office of Surface Mining — Pittsburgh Revisit (June, 2003)).

The Consent Order procedure for reconnection worked well for nearly two years, and the Special Master eventually approved some ninety-five percent of Interior's systems for reconnection. See Cobell XI, 310 F.Supp.2d at 82. However, an April 2003 incident concerning the "unplugging" of a network cable at the Office of Surface Mining "at the exact time the agency was aware the Special Master's contractor was performing penetration testing on that system" escalated over the course of the late spring and early summer, resulting in the breakdown of the relationship between Interior and the Special Master. See id. at 82; see also Cobell v. Norton ("Cobell IX"), 274 F. Supp. 2d 111, 114-24 (D.D.C.2003) (detailing the events surrounding this breakdown).

On June 26, 2003, after it had become clear that the Consent-Order process had failed, the plaintiffs moved for a temporary restraining order to require Interior to disconnect IT systems housing or accessing IITD from the Internet. The Court held a hearing and subsequently entered the TRO the following day, June 27, 2003. See TRO [2118] (June 27, 2003). Noting that "the parties continue to be at an impasse as to the manner in which the Consent Order should be implemented ... [and that] the Court has no confidence that this impasse will be resolved," the Court issued a preliminary injunction on July 28, 2003 staying the Consent Order requiring that Interior "immediately disconnect from the Internet all Information Technology Systems within [its] custody or control ... until such time as the Court approves their reconnection to the Internet." Cobell IX, 274 F.Supp.2d at 133-135. The Court allowed Interior IT systems connected to the Internet as of the date the preliminary injunction was issued to remain connected if they "impact[ed] life or property," or if Interior certified to Court that the connected systems either did not house or access Individual Indian Trust data or were secure from unauthorized access from the Internet. See id. at 135-36. In light of Interior's objection to continuing oversight by the Special Master, see id. at 123-24, the Court decided to make the necessary determinations regarding reconnection of Interior's systems itself. See id. at 133. Interior appealed.

During the pendency of Interior's appeal from the July 28, 2003 preliminary injunction, after reviewing Interior's certifications for Internet-connected IT systems submitted on August 11, 2003 in accordance with the July 28, 2003 preliminary injunction and finding them to be both procedurally and substantively defective, the Court, on March 15, 2004, entered a preliminary injunction that required Interior to disconnect (or to keep disconnected) from the Internet Interior's IT systems at certain bureaus and offices, including the BIA, regardless of whether or not they housed or accessed Individual Indian Trust Data. See Cobell XI, 310 F.Supp.2d at 96-97. The March 15, 2004 preliminary injunction superseded and replaced the Court's June 28, 2003 preliminary injunction. See Preliminary Injunction Order [2531], issued Mar. 15, 2004, at 1. Interior systems essential to protecting against fires or other threats to life or property, as well as IT systems at Interior's National Parks Service ("NPS"), Office of Policy Management and Budget ("OPMB"), and United States Geological Survey ("USGS") were exempted from disconnection. See Cobell XI, 310 F.Supp.2d at 100-01. Finally, the March 15, 2004 preliminary injunction provided that reconnection would be possible upon Court approval of a reconnection plan to be submitted by the Secretary of the Interior. See id. at 101. Again, Interior appealed.

The D.C. Circuit consolidated Interior's appeals and vacated this Court's March 2004 preliminary injunction in an opinion issued December 3, 2004. See Cobell v. Norton ("Cobell XII"), 391 F.3d 251 (D.C.Cir.2004). Interior argued on appeal that the issuance of the IT security related preliminary injunction was illegitimate because Cobell VI restricted this Court's remedial authority to established breaches of fiduciary duty and held only that Interior had breached its duty to render an accounting of the IIM trust. See Cobell XII, 391 F.3d at 257. The Court of Appeals, however, explained that Cobell VI "did not limit the district court's authority to exercise its discretion as a court of equity in fashioning a remedy to right a century-old wrong or to enforce a consent decree[,]" and that "maintaining adequate computer systems, along with staff and document retention policies, is critical to the completion of an adequate accounting." Id. Thus, the Court concluded, equitable relief to ensure the security of electronic IITD was well within this Court's authority.

In response to Interior's argument that this Court's jurisdiction is limited to typical Administrative Procedure Act-style review of Interior's actions, the Court of Appeals explained that this Court "retains substantial latitude, much more so than in the typical agency case, to fashion an equitable remedy because the underlying lawsuit is both an Indian case and a trust case in which the trustees have egregiously breached their fiduciary duties." Id. at 257-58. Additionally, rejecting Interior's argument that this Court's IT security related injunctions violated separation of powers principles by essentially "taking over" the Department, the Court of Appeals reasoned that "the injunction ... requires the Secretary to develop IT security programs" and does not "include particular tasks for Interior to perform based on policies developed by the district court." Id. at 258. Indeed, "[t]he injunction does no more than to ensure that the Secretary is `tak[ing] reasonable steps toward the discharge of the federal government's fiduciary obligations to IIM trust beneficiaries....'" Id.

The Court of Appeals vacated and remanded the IT security injunction on procedural rather than substantive grounds, holding that this Court had erred first in declining to consider Interior's August 11, 2003 certifications regarding IT security and second in issuing the preliminary injunction without holding an evidentiary hearing. See Cobell XII, 391 F.3d. at 258-62. In the wake of the decision of the Court of Appeals, the plaintiffs requested that the Court hold an emergency status conference to determine how to proceed in addressing Interior's Indian trust-related IT security issues going forward. See Pls.' Request [2776] for Emergency Status Conference Regarding the Security of Electronic Trust Records (Dec. 3, 2004); Pl's Renewed Request [2804] for Emergency Status Conference Regarding the Security of Electronic Trust Records (Jan. 4, 2005).

On April 8, 2005, while the plaintiffs' requests were pending, Interior filed with the Court a Notice [2924] to the Court Regarding Inspector General's "Notice of Potential Findings and Recommendation" with Respect to Information Technology Systems ("Defs.' Notice"), which recounted the results of a recent penetration test of BLM's IT systems conducted by a contractor hired by Interior's Inspector General ("IG"). Specifically, the IG's Notification explained that:

Given the poor state of network security at [BLM] and the weak access controls we encountered on many systems, it is safe to say that we could have easily compromised the confidentiality, integrity, and availability of the identified Indian Trust data residing on those systems. However, due to the various court orders protecting Indian Trust data, the [Inspector General] carried out no further testing that could have jeopardized [BLM] Indian Trust systems. No information was collected, no data was manipulated, and no system was actually compromised.

See Defs.' Notice at 2. Four days later, the plaintiffs filed a motion for a temporary restraining order to disconnect Interior's IT systems housing or accessing IITD from the Internet, along with the present motion for a preliminary injunction to the same effect. The Court held a hearing on the plaintiffs' TRO motion on April 20, 2005, at which the motion was taken under advisement and preparations were made to conduct an evidentiary hearing regarding the plaintiffs' accompanying motion for preliminary injunction. It is from the evidence presented at that fifty-nine day evidentiary hearing that the Court herein makes findings of fact and conclusions of law.

B. Statutory and Regulatory Framework

The statutory and regulatory requirements reviewed herein are not at issue on the present motion, but they provide the only available baseline standard for government IT security against which to measure Interior's accomplishments in that arena. Title III of the 2002 E-Government Act, Pub.L. No. 107-347, is the Federal Information Security Management Act ("FISMA"). FISMA permanently reauthorized the IT security requirements set out in the Government Information Security Reform Act ("GISRA"), which expired of its own terms in November 2002. The 2002 version of FISMA enacted in the E-Government Act replaced the earlier version of FISMA enacted as part of the Homeland Security Act, Pub.L. No. 107-296.

i. FISMA Requirements

FISMA requires that government agencies submit annual IT security reports to the OMB, the House Committees on Government Reform and Science, the Senate Committees on Government Affairs and Commerce, Science, and Transportation, the authorization and appropriation committees of each individual congressional agency, and the General Accounting Office ("GAO"). See 44 U.S.C.A. § 3544(c)(1) (Supp.2005). Each agency's annual report must include information about risk assessments, security policies and procedures, individual system security plans, IT security training, annual testing and evaluation of IT security, remediation processes, IT security incident reporting processes, and continuity of operations planning. See 44 U.S.C.A. §§ 3544(c)(1), 3544(b)(1)-(8) (Supp.2005).

Aside from the reporting requirement, FISMA requires that agencies "develop, document, and implement an agencywide information security program ... to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source[.]" 44 U.S.C.A. § 3544(b) (Supp.2005). This agencywide IT security program must be approved by the agency's director, see 44 U.S.C.A. §§ 3543(a)(5), 3544(b) (Supp.2005), and must include "periodic assessments of the risk and magnitude of the harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of the information and information systems that support the operations and assets of the agency." 44 U.S.C.A. § 3544(b)(1) (Supp.2005). The IT security policies and procedures set forth in the agency's program must, among other things, be "based on the risk assessments" that FISMA requires be conducted, 44 U.S.C.A. § 3544(b)(2)(A) (Supp.2005), and "ensure compliance with `information security standards promulgated under section 11331 of title 40' and any other applicable requirements[.]" 44 U.S.C.A. §§ 3544(b)(2)(D)(iii), 3544(b)(2)(D)(iv) (Supp.2005).

FISMA places primary responsibility for "developing and overseeing the implementation of policies, principles, standards, and guidelines on information security" on the Director of OMB, who must report to Congress annually regarding executive agencies' compliance with FISMA's directives. See 44 U.S.C.A. § 3543(a)(1) (Supp.2005). OMB's principal IT security policy is set forth in OMB Circular A-130. Appendix III to OMB Circular A-130 requires the certification and accreditation ("C & A") of agencies' IT systems, meaning that each agency is required to implement "a minimum set of security controls to be included in Federal automated information security programs," and to "[e]nsure that a management official authorizes in writing the use of [an IT system] based on implementation of its security plan." OMB Circ. A-130, App. III. OMB requires C & A for all "general support systems," which are defined as:

information resources under the same direct management control which shares common functionality. A system normally includes hardware, software, information, data, applications, communications, and people. A system can be, for example, a local area network (LAN) including smart terminals that supports a branch office, an agency-wide backbone, a communications network, a departmental data processing center including its operating system and utilities, a tactical radio network, or a shared information processing service organization (IPSO).

OMB Circ. A-130, App. III. C & A is also required for all "major applications." Id. A "major application" is:

an application that requires special attention to security due to the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information in the application. Note: All Federal applications require some level of protection. Certain applications, because of the information in them, however, require special management oversight and should be treated as major. Adequate security for other applications should be provided by security of the systems in which they operate.

Id. The terms "information system" and "IT system" will be used interchangeably herein to mean both "general support systems" and "major applications." OMB Circular A-130, Appendix III specifies that C & A is necessary to the provision of "adequate" security for IT systems, which OMB defines as "security commensurate with the risk and magnitude of the harm from the loss, misuse, or unauthorized access to or modification of information. This includes assuring that systems and applications used by the agency operate effectively and provide appropriate confidentiality, integrity, and availability [of data], through the use of cost-effective management, personnel, operational, and technical controls." OMB Circ. A-130, App. III.

Additionally, FISMA requires agency compliance with the Department of Commerce's National Institute of Standards and Technology's ("NIST") "standards and guidelines pertaining to Federal Information Systems," including "information security standards that ... provide minimum information security requirements" that "shall be compulsory and binding" on federal agencies. 40 U.S.C.A. §§ 11331(a)(1), 11331(b)(2)(A)-(B) (2000); see 44 U.S.C.A. § 3544(b)(2)(D)(ii) (Supp.2005) (requiring agency IT security plans to comply with NIST guidance). NIST's relevant IT security guidelines are reflected in NIST Special Publication 800-18, which establishes specific requirements for agencies' system security plans ("SSP"), NIST Special Publication 800-30, which establishes a methodology for assessing and managing IT security risks as required by FISMA, and NIST Special Publication 800-37, which establishes the requirements for C & A of IT systems. NIST Special Publications 800-34, 800-47, 800-50, 800-61, and 800-70 provide guidance on IT security contingency planning, securing information system interconnections, IT security awareness and training, IT security incident response planning, and IT security configuration checklists, respectively. Also relevant is NIST's Federal Information Processing Standards Publication 199 ("FIPS 199"), which NIST advises agencies to rely upon for guidance in determining the sensitivity of data and systems implicated by IT security problems, which is an essential step in completing FISMA-mandated risk assessments.

ii. Certification and Accreditation

NIST Special Publication 800-37, then, implements the C & A requirements of FISMA as specified in OMB Circular A-130, Appendix III. NIST defines IT security accreditation as "the official management decision given by a senior agency official to authorize operation of an information system and to explicitly accept the risk to agency operations, agency assets, or individuals based on the implementation of an agreed-upon set of security controls." Ron Ross, Marianne Swanson, et al., Information Security: Guide for the Security Certification and Accreditation of Federal Information Systems, NIST Special Publication 800-37, at 1 (May 2004), United States Department of Commerce, National Institute of Standards and Technology, available at http:// csrc.nist.gov /publications/nistpu bs/800-37/SP800-37-final.pdf [hereinafter "NIST SP 800-37"]. Security certification is defined as

a comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. The results of a security certification are used to reassess the risks and update the system security plan, thus providing the factual basis for an authorizing official to render a security accreditation decision.

NIST SP 800-37, at 1.^[3] It should be noted that "the level of effort for security certification and accreditation (expressed in terms of degree of rigor and formality) should be scalable to the FIPS 199 security category of the information system." Id. at 25. That is, the higher the risk rating assigned to the IT system under FIPS 199, the more comprehensive and penetrating the C & A process must be in order to be considered adequate under NIST standards.

The C & A process is divided into four phases: (1) the initiation phase, designed to "ensure that the authorizing official and the senior agency information officer are in agreement with the contents of the system security plan, including the system's documented security requirements, before the certification agent begins the assessment of the security controls in the information system"; (2) the security certification phase, designed to "determine the extent to which the security controls in the information system are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system" and to "address[ ] specific actions taken or planned to correct deficiencies in the security controls and to reduce or eliminate known vulnerabilities in the information system"; (3) the security accreditation phase, designed to "determine if the remaining known vulnerabilities in the information system (after the implementation of an agreed-upon set of security controls) pose an acceptable level of risk to agency operations, agency assets, or individuals" and resulting in either the granting of authorization to operate ("ATO") the system, the granting of an interim authorization to operate ("IATO") the system, or a denial of authorization to operate; and (4) the continuous monitoring phase, which "provide[s] oversight and monitoring of the security controls in the information system on an ongoing basis and ... inform[s] the authorizing official when changes occur that may impact the security of the system." See NIST SP 800-37, at 2.

For the purposes of the C & A process, an "authorizing official" is defined as "a senior management official or executive with the authority to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations, agency assets, or individuals." NIST SP 800-37, at 13. Interior usually designates an executive at the Assistant-Secretary level as the authorizing official for C & A of IT systems. See Pls.' Ex. 395 ("Department of the Interior (DOI) Information Technology (IT) Security Program: DOI Certification and Accreditation (C & A) Guide, Version 1.1", July 10, 2003) ("Pls.' Ex. 395"), at 19.^[4] However, the authorizing official may delegate his or her responsibilities in the C & A process to a representative, see NIST SP 800-37, at 13, who Interior calls the "designated authorizing agent" ("DAA"). See Pls.' Ex. 395, at 19. A "certification agent" is defined as "an individual, group, or organization responsible for conducting a security certification." NIST SP 800-37, at 15. NIST cautions that ":[t]o preserve the impartial and unbiased nature of the security certification, the certification agent should be in a position that is independent from the persons directly responsible for the development of the information system and the day-to-day operation of the system." Id. In the main, Interior has chosen to designate as the certification official the Chief Information Officer ("CIO") of the Bureau within which the system subject to C & A operates. See Pls.' Ex. 395, at 20.

The initiation phase of the C & A process is concerned principally with reviewing system risk assessments and finalizing the SSP. Primary responsibility for the tasks that must be completed in the initiation phase of the C & A process is placed on the Information System Owner ("ISO"), or the "agency official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system." NIST SP 800-37, at 14. Much of the preparation undertaken during this phase relies on a previously completed risk assessment and SSP for the relevant system. See id. at 26-27. During the initiation phase, the ISO is responsible for "reviewing the system security plan and confirming that the contents of the plan are consistent with an initial assessment of risk [,]" id. at 27; confirming that the FIPS 199 "security category of the information system has been determined and documented" in the SSP, id. at 28; and confirming identification and documentation in the SSP or risk assessment of the system's potential threats, known flaws and weaknesses, extant security controls, and risk to agency operations, agency assets, and individuals, id. at 29-31. After completing these tasks, the ISO must inform the "senior agency security officer, authorizing official, certification agent, user representatives, and other interested agency officials" of the need to C & A the system. Id. at 32.

Once informed of the need to begin the C & A process for a system, the authorizing official or DAA must coordinate with the senior agency information security officer ("SAISO"), the ISO, and the certification agent to "[d]etermine the level of effort and resources required" for the C & A of the relevant system. See NIST SP 800-37, at 32. Then, the DAA, SAISO, and certification agent "[r]eview the FIPS 199 security categorization" of the system to determine whether "the assigned impact values ... are consistent with [the] agency's actual mission requirements[,]" id. at 33, and review the SSP to determine whether it will actually produce the risks documented in the system's risk assessment. See id. The ISO next modifies the SSP as needed on the basis of the results of these reviews, and revised SSP is reviewed by the DAA and SAISO to determine if it presents acceptable risk. See id. at 34-35.

The certification phase of the C & A process, which is conducted primarily by the certification agent and the ISO, is designed to test the adequacy of the security controls present on a system and to document the results of that testing for use by the DAA. See NIST SP 800-37, at 35. The principal activities during this phase are the performance of a system security test ("SST") of the system and the creation of a plan of actions and milestones ("POA & M") document when vulnerabilities are detected during the SST.

An SST can include the use of an automated vulnerability scanning tool, which "is used to scan a group of hosts or a network for known vulnerability services (e.g. systems allowing anonymous File Transfer Protocol [FTP] sendmail relaying)." Gary Stoneburner, Alice Goguen, & Alexis Feringa, Risk Management Guide for Information Technology Systems, NIST Special Publication 800-30, at 17 (July 2002), United States Department of Commerce, National Institute of Standards and Technology, available at http:// csrc.nist.gov /publications/nistpu bs/800-30/sp800-30.pdf [hereinafter "NIST SP 800-30"]. Another SST methodology is a security test and evaluation (ST & E), which "test[s] the effectiveness of the security controls of an [individual] IT system as they have been applied in an operational environment." NIST SP 800-30, at 17. Or, an SST can involve penetration testing, which "test[s] the IT system from the viewpoint of a threat-source and ... identif[ies] potential failures in the IT system protection schemes." Id. A certification agent may choose one or a combination of these SST methods. A POA & M "describes actions taken or planned by the information system owner to correct deficiencies in the security controls and to address remaining vulnerabilities in the information system (i.e. reduce, eliminate, or accept the vulnerabilities)." Id. at 39. A POA & M "identifies: (i) the tasks needing to be accomplished; (ii) the resources required to accomplish the elements of the plan; (iii) any milestones in meeting the tasks; and (iv) scheduled completion dates for the milestones." Id.

In the certification phase, the certification agent works with the ISO to gather any documentation required to conduct a thorough SST, see id. at 36, selects or designs an appropriate methodology for conducting the SST, and then performs the SST itself. See id. at 36-37. The certification agent then prepares the SST report and transmits it to the ISO. See id. at 37-38. The ISO must update the SSP to account for the risks identified in and modifications to the system's security controls undertaken as a result of the SST report, and prepare the POA & M based on the results of the SST. See id. at 38-39. When these tasks are completed, the ISO assembles for delivery to the DAA the "final security accreditation package," which must include the SST report, the POA & M document, and the updated SSP. See id. at 39. These are the documents on which the DAA relies in making his or her accreditation decision in the next phase of the C & A process.

The DAA has primary responsibility for completing the necessary tasks in the security accreditation phase of the C & A process. This phase involves assessment of the IT security risks identified for the subject system, and either acceptance of those risks or denial of accreditation on the basis of unacceptable levels of risk. The DAA determines the level of risk from the security accreditation package provided by the ISO, and decides whether "the risk to agency operations, agency assets, or individuals" posed by continuing to operate the system is acceptable. See NIST SP 800-37, at 40-41. "If, after assessing the results of the security certification, the [DAA] deems that the agency-level risk is acceptable, an [ATO] is issued. The information system is accredited without any restrictions or limitations on its operation." Id. at 41. "If, after assessing the results of the security certification, the [DAA] deems that the agency-level risk is unacceptable, but there is an important mission-related need to place the information system into operation, an [IATO] may be issued." Id. NIST describes the consequences of an IATO:

The interim authorization to operate is a limited authorization under specific terms and conditions including corrective actions to be taken by the [ISO] and a required timeframe for completion of those actions. A detailed [POA & M] should be submitted by the [ISO] and approved by the [DAA] prior to the [IATO] taking effect. The information system is not accredited during the period of limited authorization to operate. The [ISO] is responsible for completing the corrective actions identified in the [POA & M] and resubmitting an updated security accreditation package upon completion of those actions.

Id. (emphasis in original). If the DAA determines that the agency-level risk of operating a system is unacceptable and decides not to issue an IATO, accreditation is denied and "the information system is not authorized for operation." Id.

After the accreditation decision is made, the DAA prepares for inclusion in the final accreditation package a letter documenting his or her determination, including "the rationale for the decision, the terms and conditions for information system operation, and required corrective actions, if appropriate." NIST SP 800-37, at 41-42. This letter and the other documents that comprise the final accreditation package are then transmitted to the ISO and other interested agency officials and made available to "auditors and oversight agencies," such as OMB. Id. at 42. Finally, the ISO updates the SSP again based on the DAA's assessment of the risk of operating the system. Id. at 42-43.

iii. Security Monitoring After Certification and Accreditation

NIST explains:

[s]ecurity accreditation is part of a dynamic, ongoing risk management process. An information system is authorized for operation at a specific point in time reflecting the current security state of the system. The inevitable changes to the information system (including hardware, firmware, software and people) and the potential impact those changes may have on agency operations, agency assets, or individuals, require a structured and disciplined process capable of monitoring the effectiveness of the security controls in the information system on an ongoing basis.

NIST SP 800-37, at 9-10. In light of this policy, NIST makes clear that the purpose of the continuous monitoring phase of the C & A process "is to provide oversight and monitoring of the security controls in the information system on an ongoing basis and to inform the [DAA] when changes occur that may impact the security of the system." Id. at 43. Certain kinds of changes to an IT system, as well as federal or agency policies, may require that systems undergo repeated C & A. See id. The ISO has primary responsibility for the tasks required during the continuous monitoring phase.

The ISO is required to document any "proposed or actual changes to the information system (including hardware, software, firmware, and surrounding environment)[,]" analyze such changes to determine their impact on system security, and update both the SSP and POA & M accordingly. See NIST SP 800-37, at 43-44, 46. In addition, the ISO is responsible for selecting and testing, on a continuous basis, a set of security controls that exist on the relevant IT system. See id. at 44-45. The set of security controls selected for continuous monitoring should be a representative sampling of controls in operation on the system, but may also include certain controls "considered more critical ... because of the potential impact on the information system if those controls were subverted or found to be ineffective." Id. at 45. Such decisions should be based on "the agency's priorities and the importance of the information system to the agency." Id. at 44. Finally, the ISO must provide to the DAA and SAISO periodic system security status reports "address [ing] vulnerabilities in the information system discovered during the security certification, security impact analysis, and security control monitoring...." Id. at 47. The frequency of these reports is at the discretion of the agency, but they should be submitted "at appropriate intervals to transmit significant security-related information about the system." Id.

OMB requires that an agency's IT systems undergo C & A at least every three years. See OMB Circ. A-130, App. III. While agencies may require re-C & A more regularly, see NIST SP 800-37, at 5, Interior has no standing policy to that effect. NIST requires that subsequent C & A "should begin, as in the original security accreditation, with the Initiation Phase," and proceed, again, through the entire process. See id. at 47. In addition, re-C & A is required whenever an IT system undergoes a "significant change," see OMB Circ. A-130, App. III, examples of which may include but are not limited to:

(i) installation of a new or upgraded operating system, middleware component, or application; (ii) modifications to system ports, protocols, or services; (iii) installation of a new or upgraded hardware platform or firmware component; or (iv) modifications to cryptographic modules or services. Changes in laws, directives, policies, or regulations, while not always directly related to the information system, can also potentially affect the security of the system and trigger a reaccreditation action.

Id. at 5 n. 10.

FISMA also requires that "[e]ach year each agency shall have performed an independent evaluation of the information security programs and practices of that agency to determine the effectiveness of such programs and practices." 44 U.S.C.A. § 3545(a)(1) (Supp.2005). For agencies that have Inspectors General, such as Interior, the "annual evaluation required by [FISMA] shall be performed by the Inspector General or by an independent external auditor, as determined by the Inspector General of the Agency[.]" 44 U.S.C.A. § 3545(b)(1) (Supp.2005). These annual evaluations are independent of the C & A process, and must include both "testing of the effectiveness of information security policies, procedures, and practices of a representative subset of the agency's information systems" and "an assessment of compliance with ... [FISMA] ... [and] related information security policies, procedures, standards, and guidelines...." 44 U.S.C.A. §§ 3545(a)(2)(A), 3545(a)(2)(B)(i)-(ii) (Supp.2005). The results of these annual IG evaluations are submitted to the Director of OMB for use in OMB's annual FISMA-required report to Congress. See 44 U.S.C.A. § 3545(e)(1) (Supp.2005).

The IG's annual FISMA review of IT security is not necessarily as detailed as the C & A process. OMB explains that "[t]he necessary depth and breadth of an annual FISMA review depends on several factors such as: 1) the acceptable level of risk and magnitude of harm to the system or information; 2) the extent to which system configurations and settings are documented and continuously monitored; 3) the extent to which patch management is employed for the system; 4) the relative comprehensiveness of the most recent past review; and 5) the vintage of the most recent in-depth testing and evaluation as part of system certification and final accreditation." OMB Mem. 03-19 (August 6, 2004), at 7. Thus, for systems that have undergone full C & A within the past year "and received final (not interim) authority to operate, [have] documented configuration settings, employ[ ] automated scanning tools ...; and [have] an effective patch management capability, a simple maintenance review using NIST's self assessment tool may meet the FISMA ... requirement." Id. For systems that do not satisfy some or all of these criteria, the IG's "annual testing and evaluation must be far more comprehensive" to comply with FISMA. See id.

iv. IT Security Risk Assessment

As Interior's system-level and agency-level IT security risk assessment practices became one focal point of the evidentiary hearing on the present motion, the Court will give a brief overview of the relevant requirements in this connection.

NIST notes that "assessment of risk" is an important activity in "an agency's information security program that directly support[ s] security accreditation and [is] required by FISMA and OMB ...." NIST SP 800-37, at 4. "Risk assessments influence the development of the security controls for information systems and generate much of the information needed for the associated system security plans." Id. While the rigor and formality of risk assessments may vary among agencies and depending on the FIPS 199 classification of the IT system in question, "[a]t a minimum, documentation should be produced that describes the process employed and the results obtained." Id. at 5.

FISMA requires that NIST develop "standards to be used by all agencies to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to a range of risk levels," as well as "guidelines recommending the types of information and information systems to be included in each such category." 15 U.S.C.A. § 278g-3(b)(1)(A)-(B) (Supp.2005); see also 44 U.S.C.A. § 3543(a)(8)(B) (Supp.2005) (incorporating this requirement of the National Institute of Standards and Technology Act into FISMA by reference). Accordingly, FIPS 199:

establishes security categories for both information and information systems ... based on the potential impact on an organization should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.

FIPS 199 (Feb.2004), at 1. The security categorization of a system is a function of the security categorization of the data on that system, FIPS 199, at 4-5, and the data and system security categorizations, in turn, "are used in conjunction with vulnerability and threat information in assessing the risk to an organization" of continuing that system in operation. See FIPS 199, at 1.

FIPS 199 categorizes information (as opposed to information systems) "according to its information type ... [or] a specific category of information (e.g. privacy, medical, proprietary, financial, investigative, contractor sensitive, security management) defined by an organization or, in some instances, by a specific law." FIPS 199, at 1 n. 1 (emphasis in original). Security categorizations for information are assigned on the basis of "the potential impact on organizations or individuals should there be a breach of security" that adversely affects one or more of FISMA's three "security objectives." Id. at 2. These security objectives are: (1) confidentiality, compromise of which results in "unauthorized disclosure of information"; (2) integrity, compromise of which results in "unauthorized modification or destruction of information"; and (3) availability, compromise of results in "disruption of access to or use of information or an information system." Id. The security categorization process requires that, for a particular information type, a rating of low, moderate, or high risk be assigned for each of the security objectives depending on the likely consequences of their compromise. Id. at 3.

If a loss of confidentiality, integrity, or availability of a specific information type would cause "limited adverse effect on organization operations, organization assets, or individuals," that information type should receive a rating of "low risk" for the specific security objective being evaluated; if a loss of confidentiality, integrity, or availability would cause "a serious adverse effect," the information type should receive a "moderate risk rating" for the security objective at issue; and the information type should be rated "high risk" for the relevant objective if a loss of confidentiality, integrity, or availability would have "a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals." FIPS 199, at 2-3. If, for example, the impact rating for financial information on a given system is moderate for confidentiality, but high for both integrity and availability, then the security categorization ("SC") for the financial information should be represented thus:

SC (financial information) = {(confidentiality, moderate), (integrity, high), (availability, high)}. See id. at 3 (presenting other examples).

Assigning a security categorization to an information system requires analysis of "the security categories of all information types resident on that system. For an information system, the potential impact values assigned to the respective security objectives ... shall be the highest value (i.e. high water mark) from among those security categories that have been determined for each type of information resident on the information system." FIPS 199, at 4. To reuse the example set forth above, if the information system containing the financial information contains only one other information type, say individual medical records, then the security categorization for this second information type must be taken into consideration. The medical information has the security categorization:

SC (medical information) = {(confidentiality, high), (integrity, low), (availability, low)}. When considered alongside the security categorization for the financial information, FIPS 199 requires that the information system receive the following security categorization:

SC (information system) = {(confidentiality, high), (integrity, high), (availability, high)}. See id. at 4 (giving other examples). The security categorizations of information and information systems, again, are relevant to risk assessments, which are a central part of FISMA's overall information security regime.

NIST Special Publication 800-30 sets forth a nine-step process for system-level risk assessments, which are generally completed prior to or during the initiation phase of the C & A process. See NIST SP 800-30, at 8.^[5] First, the IT system's characteristics, including its "criticality," or importance to the agency and the sensitivity of both the system and the data it houses. Id. at 4. Then, potential threat sources (e.g., malicious hackers, environmental dangers, etc.)^[6] and the system vulnerabilities that threat-sources may be able to exploit must be identified, along with the security controls operating on the system that may neutralize either vulnerabilities or threat sources. See id. at 12-20. A "threat" is a conceptual outgrowth of a threat-source/vulnerability pair — the potential that a given threat-source may be able to exploit a given vulnerability is the actual "threat." See id. at 12. This notion of a "threat" is not to be confused with the likelihood of exploitation, which is a separate concept — the potential for exploitation of a vulnerability is either a positive value or zero, because "a threat-source does not present a risk when there is no vulnerability that can be exploited." Id. at 12. Thus, a threat exists when a threat-source can be paired with a vulnerability exploitable by that threat-source, without regard to the likelihood that the vulnerability would actually be exploited.

Assessing the likelihood of exploitation is a distinct step in risk assessment. See NIST SP 800-30, at 21. The "overall likelihood rating" for a threat-source/vulnerability pair depends on consideration of "[t]hreat-source motivation and capability[,]" as well as the "[n]ature of the vulnerability [and the] [e]xistence and effectiveness of current [security] controls." Id. The likelihood of exploitation of a given vulnerability will be low if "[t]he threat-source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised"; the likelihood rating will be medium if "[t]he threat-source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability"; and the likelihood rating will be high if "[t]he threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective." Id.

The likelihood rating for a particular threat-source/vulnerability pair is combined with the impact of exploitation to arrive at a measurement of the risk presented by the threat-source/vulnerability pair. See NIST SP 800-30, at 24. The impact of a threat-source/vulnerability pair is classified as "low" in magnitude if "[e]xercise of the vulnerability (1) may result in the loss of some tangible assets or resources or (2) may noticeably affect an organization's mission, reputation, or interest." Id. at 23. The magnitude of the impact is "medium" if "[e]xercise of the vulnerability (1) may result in the costly loss of tangible assets or resources; (2) may violate, harm, or impede an organization's mission, reputation, or interest; or (3) may result in human injury." Id. Impact magnitude is high if "[e]xercise of the vulnerability (1) may result in highly costly loss of major tangible assets or resources; (2) may significantly violate, harm, or impede an organization's mission, reputation, or interest; or (3) may result in human death or serious injury." Id. Note that any potential for human injury requires an impact rating of at least medium.

Determining the magnitude of the impact requires consideration of the nature of the vulnerability in relation to FISMA's three security objectives: confidentiality, integrity, and availability of information and information systems, and the effects on agency operations, agency assets, and individuals of the compromise of one or more of these objectives. See id. at 22. The nature of a given vulnerability may reveal a potential impact on the security objectives with respect to data housed on an IT system, the IT system itself, or both. Evaluating the nature of the risk in relation to the FIPS 199 security categorization of either the system or the information it houses will often determine the magnitude of the impact of a given threat-source/vulnerability pair. Recall that assigning security categorizations to information and information systems requires assessing the potential impact of their compromise on organizational operations, organizational assets, or individuals, FIPS 199, at 2-3, which are some of the factors to be considered in system-level risk-magnitude analysis. See id. at 21.

For example, if a financial institution utilizes an IT system that houses financial data, several kinds of threat-source/vulnerability pairs may exist. Weak passwords for employee-level system access may pose a threat to the confidentiality of the financial information, but not to the integrity or availability of that information or to the system itself if the level of access that an unauthorized user might obtain by "cracking" one of these weak passwords does not allow alteration of the data or manipulation of the operations of the system. If, however, the FIPS 199 security categorization for the financial data is "high" for confidentiality, then the potential impact of this threat-source/vulnerability pair might be high. Or, a vulnerability in an internet-based application running on the system may allow a hacker to gain control over the entire system such that he or she could fully compromise its availability. If, however, the financial information housed on that system is encrypted, and the encryption key is not itself stored on the system, then the hacker will not be able to threaten the confidentiality or integrity of the financial data, despite total control over the system. In this case, the impact-magnitude should be determined with reference to the FIPS 199 security categorization of the financial information with respect to availability, and that of the information system with respect to all three security objectives. Finally, if weak password protection could allow an unauthorized user to gain sufficient user privileges on the system to alter the financial information and manipulate system controls, then the threat-source/vulnerability pair potentially impacts the confidentiality, integrity, and availability of both the financial information and the system itself. Each of the FIPS 199 security categories for both the financial information and the information system must be considered to assign an impact-magnitude in this example.

The likelihood rating for the threat-source vulnerability pair must be combined with the impact-magnitude as determined above to determine the threat-source/vulnerability pair's level of risk to the IT system. See NIST SP 800-30, at 24. For example, if the likelihood of a threat-source exploiting a given vulnerability is low, but the magnitude of the impact is high if the vulnerability is in fact exploited, an overall risk rating of "medium" may be assigned to the threat-source/vulnerability pair. A "risk-level matrix" should be developed to reflect the rating for "mission risk" for each threat-source/vulnerability pair, see id. at 24-25, and senior management should take certain actions depending on the resulting risk ratings. For high risk items, a system may only be accredited and continue in operation if corrective actions are taken as soon as possible; for medium risk items, a plan for corrective actions must be developed "within a reasonable period of time"; and for low risk items, corrective actions may be taken or the risk may simply be accepted. See id. at 25. Recommended corrective actions should be included with the results of the risk assessment in the official report for senior management. See id. at 26.

"Residual risk" is the aggregate of the risk-levels of threat-source/vulnerability pairs that remain after an organization completes any risk mitigation activities undertaken on the basis of recommendations made in the initial risk assessment report. See NIST SP 800-30, at 40. Risks might be mitigated by implementing new or enhanced IT security controls that eliminate system vulnerabilities (e.g., software patches that ameliorate program weaknesses), "reduce the capacity and motivation of a threat-source" (e.g., physical restrictions on employee access to a computer workstation that accesses sensitive information or systems), or reduce the impact magnitude of an item (e.g., modification of "the relationship between an IT system and the organization's mission" or assets). See id. at 39-40. If such controls are implemented, then risk should be reassessed after their implementation to determine residual risk. The residual risk will be identical to the risk reflected in the initial risk assessment report if no corrective actions are taken or insufficient time has elapsed for remedial efforts to be completed before the DAA reviews the risk assessment for accreditation purposes.^[7]

A DAA's decision to accredit an IT system must be based on analysis of that system's residual risk — he or she must consider the agency-level risk posed by accrediting and continuing in operation the particular IT system in light of its residual risks. Upon completion of this residual risk analysis, the DAA will either "sign a statement accepting any residual risk and authorizing the operation of the ... IT system[,]" or, "[i]f the residual risk has not been reduced to an acceptable level," the DAA will not accredit the system and "the risk management cycle must be repeated to identify a way of lowering the residual risk to an acceptable level." Id. at 40.

v. Interconnecting IT Systems

NIST Special Publication 800-47 "provides guidance for planning, establishing, maintaining, and terminating interconnections between information technology (IT) systems that are owned and operated by different organizations." Joan Hash, Tim Grance, et al., Security Guide for Interconnecting Information Technology Systems: Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-47, at ES-1 (Aug.2002), United States Department of Commerce, National Institute of Standards and Technology, available at http://csrc.nist.gov /publications/nistpu bs/800-47/sp800-47.pdf [hereinafter "NIST SP 800-47"] (marked for identification as Pls.' Ex. 118). NIST SP 800-47 offers guidance for four "phases" in the life cycle of an IT system interconnection: planning, implementation, maintenance, and termination. See NIST SP 800-47, at ES-1. Because the majority of Interior's IT system interconnections with which the Court is concerned for present purposes have already been planned and implemented, and are currently functioning as parts of Interior's IT infrastructure, NIST's guidance on maintenance of IT systems interconnections will be emphasized here.

NIST defines an IT system interconnection as "the direct connection of two or more IT systems for the purpose of sharing data and other information resources." NIST SP 800-47, at 2-1. IT system interconnections may be beneficial for a number of reasons, including their capacity to reduce operating costs, increase the functionality of the connected systems, increase the efficiency of system and organizational operations, and provide centralized access to data. See id. "Organizations can connect their IT systems using a dedicated line that is owned by one of the organizations or is leased from a third party," or they may "connect systems over a public network (e.g., the Internet), using a virtual private network (VPN)[,]" which NIST defines as "a data network that enables two or more parties to communicate securely across a public network by creating a private connection, or `tunnel,' between them." Id. NIST cautions, however, that transmitting data between IT systems across a VPN interconnection increases the risk that the data "can be intercepted by unauthorized parties," which "necessitat[es] the use of authentication and data encryption to ensure data confidentiality and integrity." Id. Thus, "[t]he decision to pass data over a public network should be based on an assessment of the associated risks" conducted in accordance with NIST SP 800-30. See id. at 2-2.

NIST explains that there may be "varying levels of system interconnection" defined by access limitations that may be imposed "dependent on [an organization's] mission and its security needs." NIST SP 800-47, at 2-2. Organizations implementing IT system interconnections may choose, based on mission, needs, risks, and other relevant factors, to create a "limited interconnection, whereby users are restricted to a single application or file location[;] ... [a] broader interconnection, enabling users to access multiple applications or databases[;] ... [or] an interconnection that permits full transparency and access across their respective enterprises." Id. Whatever the level of system access facilitated by an interconnection, "interconnecting IT systems can expose the participating organizations to risk," including "security failures" that may "compromise the connected systems and the data that they store, process, or transmit." Id. Indeed, "if one of the connected systems is compromised, the interconnection could be used as a conduit to compromise the other system and its data[,]" a problem that is exacerbated by the fact that "the participating organizations have little or no control over the operation and management of the other party's system." Id.

In view of these risks, NIST advised that during the planning and implementation phases of the life cycle of an IT system interconnection, the participating organizations create a formal agreement or memorandum of understanding "regarding the management, operation, and use of the interconnection." Id.; see also id. at 3-5-3-6 (discussing the formulation and desired contents of an interconnection agreement); id., Appx. A, at A-1-A-7 (giving more detail on this process, presenting an example agreement). The parties to an IT system interconnection agreement, during the planning phase, should "[i]dentify the sensitivity level of data or information resources that will be made available, exchanged, or passed one-way only across the interconnection" in order to "determin[e] the security controls that should be used to protect the connected systems and data[,]" as well as specifically enumerate "security controls that will be implemented to protect the confidentiality, integrity, and availability of the connected systems and the data that will pass between them." Id. at 3-3. NIST also insists that a critical prerequisite to establishing an IT system interconnection is that the putatively connected systems undergo a full C & A. See id. at 3-2. The very first step of the implementation phase, NIST advises, should involve the participating parties' "implement[ing] appropriate security controls," see id. at 4-2, including firewalls, intrusion detection systems, "mechanisms to record activities occurring across the interconnection" (auditing systems), id., systems for identification and authentication of authorized users, logical access controls that limit the functionality of accessible applications and systems to authorized activities, virus scanning, encryption of data, and physical and environmental security on both ends of the interconnection. See id. at 4-2-4-3.

While an IT system interconnection is operational, participating organizations should "review the security controls for the interconnection at least annually or whenever a significant change occurs to ensure they are operating properly and are providing appropriate levels of protection." NIST SP 800-47, at 5-2. NIST allows that either or both of the participating organizations, or "an independent third party," may conduct these annual security reviews, in accordance with the agreement between the parties. See id. NIST adds that annual security testing should include penetration testing of the connected IT systems, and that "[s]ecurity risks and problems should be corrected or addressed in a timely manner," and that "[c]orrective actions should be documented, and the records should be stored in a secure location." Id. In addition to these annual general security assessments, "[o]ne or both organizations should analyze audit logs at predetermined intervals to detect and track unusual or suspicious activities across the interconnection that might indicate intrusions or internal misuse," and "[a]utomated scanning tools should be used to scan for anomalies, unusual patterns, and known attack signatures." Id. However, NIST advises that a system administrator should manually review audit logs a regular intervals to catch problems that automated scanning tools might overlook. See id.

Within Interior, several types of IT system interconnections are operational, running between Interior's different bureaus and offices, between Interior's bureaus or offices and IT systems maintained by private contractors or Indian Tribes, and between Interior's bureaus and offices and other governmental organizations. Additionally, Interior operates what is referred to as a "network backbone" that is intended to connect all bureau and office IT networks through a single tunnel. Currently, this backbone is called Interior's Virtual Private Exchange ("VPX"), but there are plans to transition over to something called the Enterprise Services Network ("ESN"), which is already in development and, indeed, in use by some bureaus and offices. Both of these major Interior interconnections will be examined more closely herein, as well as some of the other more limited kinds of interconnections listed above. NIST SP 800-47 does not specify whether IT system interconnections between semi-independent elements of a larger organization must conform to these same security standards. However, it will become apparent that operating IT system interconnections even among the sub-parts of a single organization entails risks that must be addressed. NIST's framework is relevant, then, in that it provides the only available governmental guidance on what constitutes good security practice for the operation of IT system interconnections.

FINDINGS OF FACT^[8]

A. Annual FISMA Reporting by Interior's Inspector General

i. Overview

Prior to the enactment of FISMA, Interior's IG had "very little" involvement in IT security testing. See Tr. (Hrng., May 20, 2005 AM Sess.), at 11 (testimony of Earl Devaney, Inspector General of the Department of the Interior). The IG's office "had a unit of auditors in Denver, Colorado who were, by professional training, auditors and more or less self-taught and had gone to courses in IT" who were "performing occasional reviews and audits of the department's information systems[.]" Id. When Inspector General Earl Devaney^[9] took over in August, 1999, see Tr. (Hrng., May 20, 2005 AM Sess.), at 8 (testimony of Devaney), he began a process of "shifting our resources from [the Denver] unit to a more robust unit ... in Washington" so that the IG's office could have "more capacity to implement the FISMA requirements." Tr. (Hrng., May 20, 2005 AM Sess.), at 11 (testimony of Devaney).

Devaney explains that after FISMA took effect, "sometime in 2002," most of the Inspectors General viewed the statute as "sort of an unfunded mandate that IGs do this work without the resources to accompany it[.]" Tr. (Hrng., May 20, 2005 AM Sess.), at 11 (testimony of Devaney). FISMA requires IGs to submit IT security evaluation reports to OMB at the end of each fiscal year ("FY"),^[10] and to conduct the FY 2003 FISMA evaluation, Devaney "tried to ... borrow from other areas in [the IG] program[.]" Id. In part for this reason, the IG's FISMA report for FY 2003 was necessarily more limited in scope, involving reviews of "policies, procedures, [and] training," id at 23, as well as "security practices and general and application controls, [and] ... security ... documents, such as security plans and risk assessments as of July 31, 2003." Pls.' Ex. 14 (Notice of Filing Under Seal of the Department of the Interior's "Report on the Implementation of the Federal Information Security Management Act (FISMA) FY 2003" and the Department of the Interior's Office of the Inspector General's "Annual Evaluation of the Information Security Programs of the Department of the Interior" (Report No. 2003-I-0066, September 2003)) ("Pls.' Ex. 15"), at bates page ("bp.") DEF0043818.

For the FY 2004 and 2005 FISMA reports, Devaney is "using a slug of money that was offered to us by the department, and using some of our own money. I think in terms of percentages, it's probably two-thirds the department's and one third [the IG's]." Tr. (Hrng., May 20, 2005 AM Sess.), at 26 (testimony of Devaney); see also Pls.' Ex. 1 ("Memorandum of Understanding/Intra-Agency Agreement Between the United States Department of the Interior, Office of the Secretary, and the United States Department of the Interior, Office of Inspector General") ("Pls.' Ex. 1"), at 1, bp. DOIITE018000009-DOIITE018000011 (reimbursable support agreement ("RSA")). Devaney explained that this funding from the department "is essentially two-year money, 2004 and 2005. Starting in 2006 and on out from there, I don't see the department giving us any more money, and at that point I'll have the capacity to do [FISMA reporting] myself." Id. at 27. Accordingly, for the FY 2006 and FY 2007 budget proposals, Devaney has been "submitting budgets that are asking for money to do [FISMA] work." Id. Though, "technically speaking," the Secretary of the Interior has some control over the content of the IG's budget requests, "[t]his particular secretary has, to [Devaney's] knowledge, never lowered [the IG's] budget." Id. at 14. These changes in the budgeting and planning for FISMA reporting are necessary, Devaney explained, because "the nature of what we're doing under FISMA has now evolved ... from looking at policies, procedures, training, to actually getting into testing the systems, and that's a highly technical area...." Id. at 23.

Interior's IG has also implemented personnel changes to meet the evolving requirements of FISMA reporting. The majority of the IT security testing for FY 2003 and FY 2004 had been performed a group within the IG's audits department called the National Information System Office ("NISO"). See Tr. (Hrng., May 20, 2005 AM Sess.), at 11, 18 (testimony of Devaney); Tr. (Hrng., May 25, 2005, PM Sess.), at 38 (testimony of Sandy) (giving the group's name). However, Devaney explained, as FISMA reporting "is getting more complicated and bigger,... I felt ... that eventually we were going to have to have a self-contained unit that would do little else but FISMA." Id. at 18. Thus, the IG's office is "transferring some of the people in Denver into this new FISMA unit [that]... would be housed under the CIO's office under ... the management piece of my organization." Id. at 19. The "management piece" of the IG's office Devaney referenced is the Office of Administrative Services and Information Management ("ASIM"), of which the CIO's office is one division. The functions and a number of the staff of the Denver NISO, which had conducted most of the IG's IT testing and was formerly headed by Diann Sandy,^[11] see id. at 24, is currently being transferred to the IG's headquarters in Washington. See id. This new central FISMA unit — called the National Security Management Unit ("NSM") and headed by Roger Mahach, formerly Interior's Departmental Information Technology Security Manager ("DITSM") — should be completely assembled by October 1, 2005. See id. at 20-21. At that time, the Denver audit staff's involvement in FISMA reporting will be phased out. See id. at 21.

Creating the NSM is one piece of Devaney's larger "vision" for the IG's role in Interior's IT security going forward. He elaborated:

The strategic vision is to ... do the work we have been doing, to continue to look at policies, procedures, guidance, look at training, look at the certification, accreditation, all of the paper ... [and] to add to that the penetration testing we're doing, and we're also going to try and draw from our... investigative component, and our audit component, any information with respect to IT systems that they come across in their normal duties, and have [this funneled] into this unit in Washington to make sure that we capture the entire [holistic] picture ... of all our work across the country that has anything to do with IT systems. It's a much more robust and [holistic] approach than we've had before.

Tr. (Hrng., May 20, 2005 AM Sess.), at 48 (testimony of Devaney). Having a FISMA-specialized group, Devaney notes, allows the IG to deploy "a cadre of highly technical people supervised by my CIO," one Michael Wood, who "has a technical background as well." Id. at 22. In addition to the current NSM staff, Devaney has included in his FY 2006 budget proposal a request for funds sufficient to hire at least four additional NSM staff members with technical expertise, so that the IG will have the capacity to conduct the full panoply of IT security testing "in-house." See id. at 29-31. "[M]y goal would always be to be able to do everything in-house... so that we can totally control the situation." Id. at 30. Currently, however, the IG's office has no such internal capacity, and must retain outside contractors to conduct various kinds of IT security evaluations, such as the external penetration testing conducted as part of the IG's FY 2005 FISMA evaluation. See id. at 79 ("Q: And did you believe you were in a position to provide ... an independent [IT security] evaluation [in FY 2004 and FY 2005]? A: I believed that we could hire a contractor to do that for us. Q: Okay. In other words, at that point in time you didn't have the expertise to do it? A: Correct.").

Around the time that the IG's FY 2004 FISMA evaluation report was nearing completion, the IG's NISO prepared a list of the "eight key areas" of consideration for evaluating Interior's compliance with FISMA. See Pls.' Ex. 116 (document entitled "Assignment Workpaper; Subject: Connecting the information relating to the OIG evaluation report, FISMA public law, and DOI Guidance," prepared by Kathryn Saylor (Sept. 14, 2004)) ("NISO Eight Key Areas"); see also Tr. (Hrng., May 25, 2005, PM Sess.), at 73 (testimony of Sandy) (authenticating the document as produced by her NISO staff). These eight areas of consideration will frame the discussion of the IG's findings during its FY 2003, FY 2004, and FY 2005 FISMA evaluations.

First, the agency's development, documentation, and maintenance of risk assessments for IT systems is evaluated. See Pls.' Ex. 116, at bp. DOI_OIG_ IT0027883 (NISO Eight Key Areas); Tr. (Hrng., May 25, 2005, PM Sess.) (testimony of Sandy) (explaining what is considered in this area, including sensitivity ratings assigned to data, assessments of different kinds of threats and vulnerabilities, and the "determination as to whether that system is high, medium or low risk in the areas of confidentiality, availability, and integrity"). Second, the IG considers whether the department has created satisfactory plans that incorporate IT security into the life cycles of systems. See Pls.' Ex. 116 (NISO Eight Key Areas), at bp. DOI_OIG_IT0027884; Tr. (Hrng, May 25, 2005, PM Sess.), at 84-86 (testimony of Sandy) (explaining that this item basically calls for an evaluation of system security plans, including "the management controls, the technical controls, and the operational controls that surround and are used to safeguard the data and information in that system," which should be embodied in some form of written document).

The IG's third principal area of evaluation for FISMA compliance involves determining whether the department has and is correctly maintaining plans for providing adequate information security, see Pls.' Ex. 116 (NISO Eight Key Areas), at bp. DOI_OIG_IT0027884, or the practice of "keeping the [security] plan up to date. In other words, as part of your security plan and the result of your security tests and evaluation, the plans need to be updated. You find possibly a control is not working like you thought; therefore you need to address that to keep that plan in place." Tr. (Hrng., May 25, 2005, PM Sess.), at 86 (testimony of Sandy). Sandy explained that the documentation that must be produced to memorialize the process of updating SSPs "can be an addendum to the actual original security plan or it can just be a brand new security plan for that system," and that SSPs should be reviewed and updated "at least every three years, or sooner if there's been significant changes." Id. Fourth, the IG considers whether Interior is conducting adequate IT security training for employees, contractors, and other individuals whose duties involve IT security responsibilities. See Pls.' Ex. 116 (NISO Eight Key Areas), at bp. DOI_OIG_IT0027884. Sandy made clear that the training requirement "should include everyone"-including private contractors or Indian Tribes — who has IT security responsibilities because they interact in some appreciable way with Interior's IT infrastructure. See Tr (Hrng., May 25, 2005, PM Sess.), at 87 (testimony of Sandy).

The fifth key area for FISMA evaluation involves determining whether Interior is performing appropriate testing and evaluation of security controls for IT systems on an annual basis. See Pls.' Ex. 116 (NISO Eight Key Areas), at bp. DOI_OIG_IT0027885. Sandy explained that this requires looking at "the annual evaluation that should be conducted on your controls to determine whether they are still operating as you intended," which is "testing the individual bureaus [within Interior] do on their own system ... an internal testing and evaluation." Tr. (Hrng., May 25, 2005, PM Sess.), at 96 (testimony of Sandy). Documentation of these annual security evaluations, according to Interior policy, is prepared using the guidance provided in NIST Special Publication 800-26, which governs IT system security self-assessment. See generally Marianne Swanson, Security Self-Assessment Guide for Information Technology Systems, NIST Special Publication 800-26 (Nov.2001), United States Department of Commerce, National Institute of Standards and Technology, available at http://csrc.nist.gov /publications/nistpu bs/ 800-26/sp800-26.pdf, with revised questionnaire incorporating baseline security controls from NIST SP 800-53,^[12] available at http://csrc.nist.gov /publica tions/nistpu bs/800-26/Mapping-of-800-53v1.doc [hereinafter "NIST SP 800-26"]. Sixth, the IG considers the adequacy of Interior's "process for planning, implementing, evaluating and documenting remedial action to address any deficiencies in the information security policies, procedures, and practices of the agency [.]" Pls' Ex. 116 (NISO Eight Key Areas), at bp. DOI_OIG_IT 0027885. This item, Sandy explained, involves review of Interior's implementation and management of the POA & M process. See Tr. (Hrng, May 26, 2005, AM Sess.), at 10-11 (testimony of Sandy).

The seventh key area of FISMA evaluation requires that the IG examine Interior's "procedures for detecting, reporting, and responding to security incidents[,]" including whether Interior is in compliance with the requirement that IT security incidents be reported to the relevant "federal information security incident center." Pls.' Ex. 116 (NISO Eight Key Areas), at bp. DOI_ OIG_IT 0027885. Within Interior, the centralized incident reporting application is known as "DOICIRC," and the general federal IT security incident reporting center, one known as FEDCIRC, is now called U.S. CERT and is operated by the Department of Homeland Security. See Tr. (Hrng., May 26, 2005, AM Sess.), at 20-21 (testimony of Sandy). Eighth and finally, the IG's annual FISMA evaluation requires consideration of Interior's IT security contingency, or "continuity of operations" planning. See Pls.' Ex. 116 (NISO Eight Key Areas), at bp. DOI_OIG_IT0027886. Sandy explained that FISMA requires that Interior have contingency plans for each IT network or system that "identify the critical resources that need to be brought up first in the case of a disaster, whether it's nature or man made, or a system failure." Tr. (Hrng., May 26, 2005, AM Sess.), at 24-25 (testimony of Sandy). Sandy further detailed relevant contingency planning considerations, including questions like "[h]ow do you move it, where to you have a back-up site, can you get that data, can you bring it back up...." Id. at 24 (testimony of Sandy). FISMA also requires that contingency plans be in written form, see id. at 25, and that contingency plans be tested "[a]t least annually." See id. at 27 (testimony of Sandy).

Pre-FISMA IT Security Assessments — Before FISMA's enactment in 2003, IT security for governmental agencies was governed in general by GISRA. Independent evaluations of Interior's compliance with IT security requirements, to the extent that they were conducted at all, were handled by a Diann Sandy's Denver-based team under the IG's audits department. See Tr. (Hrng., May 26, 2005, AM Sess.), at 59-60 (testimony of Sandy) (explaining that her group compiled GISRA evaluation reports that formed the basis of OMB's general GISRA reports to Congress). In OMB's 2002 report to Congress under GISRA, Interior's IT security posture for FYs 2001 and 2002 is described in overview. See Pls.' Ex. 123 (extract from document entitled Office of Management and Budget, FY 2002 Report to Congress on Federal Government Information Security Reform (Rpt. No. A-IN-MOA-0099-2003, May 16, 2003)) ("2002 GISRA Rep."), at bp. DOI_OIG_ IT001676.

For FY 2002, out of 224 total systems identified, Interior had 42 systems that were "assessed for risk and assigned a level of risk," 70 systems with an "up-to-date IT security plan," 49 systems "authorized for processing following certification and accreditation," 175 systems "operating without written authorization," 109 systems with "security control costs integrated into the life cycle of the system," 51 systems for which the "security controls have been tested and evaluated in the last year," 63 "systems with a contingency plan," but only 23 "systems for which contingency plans have been tested [.]" Pls.' Ex. 123 (2002 GISRA Rep.), at bp. DOI_OIG_IT0016766. These numbers showed relative improvement over those reported for FY 2001. See id. OMB noted, however, that the "DOI and the DOI IG report that the lack of a credible DOI IT system inventory casts doubt on the accuracy of various statistics and performance results contained in the DOI FY 2002 GISRA submission." See id. at bp. DOI_OIG_IT0016770.

Additionally, OMB's 2002 GISRA report noted management and policy problems related to Interior's IT security program. For example, OMB observed that "program officials, such as the Assistant Secretaries and Bureau heads, deputies, and assistant directors have not been held accountable for carrying out their [IT security] responsibilities," Pls.' Ex. 123 (2002 GISRA Rep.), at bp. DOI_OIG_IT0016770, and that "all [departmental] policies and guidance were not implemented by the Bureaus[,][a]ll systems were not identified, certified, accredited, and authorized to operate[,] [p]rocedures were not developed to validate whether all Bureaus have effectively implemented federal and DOI IT policies, procedures, standards, and guidelines[,]... [and] procedures were not established to keep DOI IT security policies and guidance up to date." Id. at bp. DOI_OIG_0016773.

OMB's GISRA report to Congress is based on self-reporting by the various governmental agencies that are evaluated; part of Interior's submission to OMB for this purpose is an "IT Security Scorecard" created by the departmental CIO's office. See, e.g., Pls.' Ex. 124 (email from Diann Sandy to Jennifer Schafer, Subject: "DRAFT IT Security Scorecard for June 2003", July 7, 2003), Attachment (document entitled "Department of Interior IT Security Scorecard, June 2003"), at bp. DOI_OIG_IT0016124. Sandy's office took issue with some of the information Interior provided to OMB during the compilation of the 2002 GISRA Report, "primarily with the fact that DOI was acknowledging that systems were certified and accredited when, in fact, there was no defined process at that time." Tr. (Hrng., May 26, 2005, AM Sess.), at 77 (testimony of Sandy). Indeed, in Interior's CIO's response to OMB's draft of the FY 2002 GISRA report, the following comment from the Inspector General's office was included.

Overall, the IG's information is depicted accurately in the Office of Management and Budget's report of the U.S. Department of the Interior, for the Government Information Security Reform Act. However, we have concerns regarding the number of Department of Interior systems authorized to process after certification and accreditation. The Department reported that 49 systems had been authorized to process after a certification and accreditation. We noted in the IG's report that the Department did not have a certification and accreditation process. Further, in OIG reviews of Departmental components of IT systems, rarely were systems certified and accredited and if the systems were identified as certified and accredited, the inappropriate level of management was certifying and accrediting the systems. One of the DOI components had a documented certification and accreditation process, however, the process was broken and not implemented.

Pls.' Ex. 125 (email from Kamela White, OMB, to Stephen King, DOI OCIO, Subject: "Re: DOI Comments on DRAFT FY 2002 GISRA Report and DOI Summary", May 6, 2003), Attachment (email from Stephen King, DOI OCIO, to Kamela White, OMB, Subject: "DOI Comments on DRAFT FY 2002 GISRA Report and DOI Summary", May 2, 2003), at bp. DOI_OIG_IT0023724. While Sandy noted that there had been some improvement in the state of Interior's C & A process from FY 2002 under GISRA to FY 2003 under FISMA, see Tr. (Hrng., May 26, 2005, AM Sess.), at 77 (testimony of Sandy), she would go on to note numerous IT security problems that have existed since the preparation of the IG's FY 2002 GISRA report and remain today.

FY 2003 FISMA Evaluation — The IG's FY 2003 FISMA evaluation was managed by Diann Sandy and conducted primarily by her NISO. See Tr. (Hrng., May 25, 2005, PM Sess.), at 43 (testimony of Sandy). Devaney's consistently increasing focus on his office's FISMA reporting responsibilities is reflected in the broadening scope of the FISMA-related activities his staff has undertaken from year to year. In FY 2003, for example, the IG's office analyzed previously conducted reviews of "security practices and general and application controls over information systems supporting telecommunications, energy and water operations, scientific research and mapping, park operations, and financial operations included in financial statement audits; and ... DOI's management of Web sites [;]" reviewed FY 2003 reports concerning Interior's IT security prepared by the Government Accountability Office ("GAO") and OMB; and examined "[i]nternal reviews performed and documents provided by the DOI ... [CIO] and bureaus and offices." Pls.' Ex. 14, at bp. DEF0043818.

Along with analyzing previous review documents, the FY 2003 IG FISMA evaluation included a first-hand review of "DOI's and bureaus' and offices' security management policies, procedures, and practices documents, such as security plans and risk assessments," and testing of "information system security controls as part of [the IG's] detailed review of general controls over information security at U.S. Geological Survey [("USGS")], National Park Service [("NPS")], Bureau of Reclamation [("BOR")], and DOI Web sites." Id. at bp. DEF0043818-DEF0043819. The IG's actual security testing covered "98 systems including 5 that were operated and maintained by contractors and 405 Web site component systems." Id. at bp. DEF0043819.

In the IG's 2003 FISMA report to OMB, NISO noted numerous areas where Interior's IT Security program was not in compliance with applicable standards. See generally Pls.' Ex. 120 (memorandum from Diann Sandy, Manager, NISO, to CIO, Department of the Interior, Subject: Evaluation of the Department of the Interior's Information Security Program (Report No. 2003- I-0066)) ("2003 FISMA Rep."). As in the FY 2002 GISRA report, the IG noted in 2003 that "DOI has not ensured that all of its security policies have been implemented and integrated," and that "bureau and office senior level management were not always held accountable for ensuring that Federal and DOI policies, procedures, practices, and control techniques were implemented." Pls. Ex. 120 (2003 FISMA Rep.), at bp. DOI_IT0018062-DOI_IT001863; see also Tr. (Hrng., May 26, 2005 PM Sess.), at 56-57 (testimony of Sandy) (discussing these organizational and accountability issues). The IG also observed that:

[a]ll systems operated for or on behalf of the DOI including DOI Commissions such as the Indian Gaming Commission; outsourced Web sites; universities and colleges; state, local, and tribal governments; and hosting of Web sites for organizations such as not-for-profits are not included in information system inventories. For example, in at least three bureaus, information systems personnel did not consider that outsourced Web sites or contractor operated and managed applications used to collect and process DOI information should be included as part of the bureaus' system inventory.

Pls.' Ex. 120 (2003 FISMA Rep.), at bp. DOI_IT0018067. Indeed, this faulty system inventory, Sandy explained, gave rise to "some concerns ... that it was easy for the bureaus to improve their [DOI and OMB] score without improving what they had done from a security management perspective by merely lumping systems together[;] ... merely by reducing the number of systems, the bureau was able to show improvement for conducting the required reviews...." Tr. (Hrng., May 26, 2005, PM Sess.), at 73 (testimony of Sandy). Among other recommendations, the IG advised Interior to "[e]stablish and periodically provide a training program that addresses the requirements needed for any position including program officials and system owners and federal or contractor employees with significant information and information system security responsibilities." Id. at bp. DOI_IT0018071.

In recounting the NISO's activities during the compilation of the IG's FY 2003 FISMA report, Sandy recalled encountering problems with implementation of the Secretary's order that all bureaus and offices with 5,000 or more employees establish a CIO's office, see Tr (Hrng., May 26, 2005, PM Sess.), at 59-60 (testimony of Sandy); Pls.' Ex. 128 (document entitled "A-IN-MOA-0099-2003, Fiscal Year 2003 FISMA"), at bp. DOI_OIG_IT0015686-DOI_OIG_IT0015686 (NISO "found that the CIO positions for at least two bureaus were not filled by the established milestone date"), operation of systems lacking a certification and accreditation or even an IATO, see Tr. (Hrng., May 26, 2005, PM Sess.), at 61 (testimony of Sandy), implementation of an effective IT security training program for Interior personnel and contractors, see id. at 63-64 (testimony of Sandy), and monitoring of contractor access to and management of Interior's IT systems. See id. at 65 (testimony of Sandy). Sandy's NISO team found that bureaus and offices were conducting annual security assessments according to the outdated NIST SP 800-26 self-assessment guidance rather than the new 800-30 independent assessment requirements, see id. at 79-80 (testimony of Sandy), and were implementing "dial-up access to DOI's networks ... without [security] controls being effectively implemented." Id. at 78; see Pls.' Ex. 120 (2003 FISMA Rep.), at bp. DOI_IT0018067.

Other IT security problems uncovered during the IG's FY 2003 FISMA evaluation included inadequate POA & M processes and documentation, see Tr. (Hrng., May 26, 2005, PM Sess.), at 82-83 (testimony of Sandy), managerial acceptance of IT security risks without adequate supporting documentation as required by FISMA, see id. at 84-86 (testimony of Sandy), and acceptance of IT security risks by Interior employees other than the DAA in violation of FISMA and OMB standards, see id. at 85-88 (testimony of Sandy). One particularly troubling instance involved the CIO of BIA signing C & A documentation for BIA's TrustNet system as both the certifying agent and the accrediting authority. See Tr. (Hrng., May 27, 2005, AM Sess.), at 8 (testimony of Sandy).^[13] Sandy testified that this practice both violated FISMA and OMB requirements and involved an inherent conflict of interest, see id. at 9 (testimony of Sandy), and that the problem was reported to the departmental CIO and later corrected. See id. In summary, NISO found that Interior's IT security program was significantly deficient in all of NISO's Eight Key Areas of FISMA evaluation. See Tr. (Hrng., June 1, 2005, AM Sess.), at 4-5 (testimony of Sandy).

FY 2004 FISMA Evaluation — The IG's FISMA evaluation covered more ground in FY 2004, even though the NSM had not yet been completely assembled and most of the work was still being conducted "under the Office of Audits [by] Roger LaRouche and Diann Sandy." Tr. (Hrng., May 20, 2005 AM Sess.), at 48 (testimony of Devaney); Tr. (Hrng., May 25, 2005, PM Sess.), at 44 (testimony of Sandy) (explaining her managing role in the IG's FY 2004 FISMA evaluation). Roger Mahach, who now heads the IG's NSM group, was hired in June 2004, see id. at 43, so that while "he was consulted about his thoughts" on the FY 2004 FISMA evaluation, "the work ... started much earlier in the [fiscal] year, and [was] being rolled up at the end of the [fiscal] year." Id. at 49. In addition to reviewing updated versions of the same kinds of reports and documentation that were considered in FY 2003, the IG "tested controls over 20 of DOI's 157 information systems — 9 major applications and 11 general support systems. These tests included the performance of limited non-intrusive scanning of DOI networks and devices, such as servers and firewalls, which were accessible from the Internet." See Pls.' Ex. 15 (letter from Earl Devaney, Inspector General for the U.S. Department of the Interior, to Joshua Bolton, Director, Office of Management and Budget (Oct. 12, 2004)) ("IG 2004 FISMA Letter"), Enclosure (document entitled "United States Department of the Interior, Office of the Inspector General: Annual Evaluation, DOI Information Security Program (Report No. A-EV-MOA-0006-2004, Oct. 2004)") ("2004 FISMA Rep."), at 1.

The IG's FY 2004 evaluation considered Interior's compliance with FISMA's requirements that "federal agencies ... implement security programs that protect information systems from unauthorized access, use, disclosure, disruption, modification, or destruction," id., including mechanisms designed to: "assess risks and implement policies and procedures to reduce risks; test and evaluate security controls; plan for continuity of operations; maintain subordinate plans for providing information security; plan for security throughout life cycle of systems; plan corrective actions; train employees and contractors; and detect, report, and respond to security incidents." Id. This is a substantially more detailed list of features of a FISMA-compliant IT security plan than was presented in the FY 2003 IG report, see Pls.' Ex. 14, at bp. DEF0043818, underscoring Inspector General Devaney's testimony regarding the evolving and increasingly technical nature of FISMA reporting in general. See Tr. (Hrng., May 20, 2005, AM Sess.), at 23 (testimony of Devaney).

Sandy's NISO team identified many of the same deficiencies in FY 2004 that were observed during the FY 2003 FISMA reporting period. See generally Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 3 (summarizing findings). Interior's self-reporting scorecard for FY 2004 graded the department's IT security program at 67.5 out of 100; see Pls.' Ex. 158 document entitled "Department of the Interior, IT Security Scorecard" (Apr. 30, 2004), at bp. DOI_OIG_ IT0021994; this failing grade, Sandy indicated, was likely more favorable than the grading Interior would receive from OMB, so that failing the self-score card almost guarantees failing the OMB scorecard. See Tr. (Hrng., June 1, 2005, PM Sess.), at 24 (testimony of Sandy). The IG's overall evaluation for 2004 emphasized that "despite sound guidance from the Office of the Chief Information Officer [of Interior], we continue to identify weaknesses in bureau and office implementation of IT security requirements." See Pls.' Ex. 15, Enc. (2004 FISMA Rep.) (cover letter from Devaney to the Secretary of the Interior). The IG elaborated in the statement of results:

We found that DOI has effectively designed its information security management program to meet the requirements of FISMA.... However, despite these efforts, our review of information and actions reported by bureaus indicated that they have not consistently followed DOI guidance in implementing their security programs. In particular, our tests of 20 systems, 19 of which were certified and accredited by the bureaus, identified weaknesses in the conduct of a majority of the system certifications and accreditations. In our opinion, this demonstrates a clear need for qualitative examination by the CIO of reported bureau accomplishments.

Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 3.

Contributing to Interior's poor performance, Sandy explained, were recurring problems such as failures at the Fish and Wildlife Service ("FWS") and NBC to take the risks of interconnections between IT systems into consideration when conducting risk assessments, see id. at 33-34 (testimony of Sandy); Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 4; Pls.' Ex. 160 (document entitled "Finding Outline, Subject(s): DOI guidelines are not clear on 800-30 risk assessment requirements", prepared by Stacey Crouser, NISO (Oct. 12, 2004)) (reporting that "[o]f the 20 systems [NISO] tested, 19 were certified and accredited, but 12 of 19 of the systems certified and accredited (63 percent) did not have risk assessments that followed NIST SP 800-30 guidance"), at bp. DOI_OIG_IT0027586; Pls.' Ex. 162 (document entitled "Assignment Workpaper, Subject: Risk Assessments," prepared by Harriet Thiesen, NISO (Sept. 21, 2005)), at bp. DOI_OIG_IT0029067-DOI_OIG_IT0029068 (discussing absence of consideration of IT system interconnections from risk assessments), failures at BLM to ensure that risk assessment documentation was placed at each physical location of a system, including field offices, see Tr. (Hrng., June 1, 2005, PM Sess.), at 35-36 (testimony of Sandy); Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 4; Pls.' Ex. 162, at bp. DOI_OIG_IT0029067 -DOI_OIG_IT002968, and a department-level failure to ensure uniform IT security policies across all bureaus and offices operating "enclaves," or collections of systems and networks that are interconnected throughout a bureau and that are certified and accredited as a single composite GSS. See Tr. (Hrng., June 1, 2005, PM Sess.), at 36-37 (testimony of Sandy).

In addition, NISO's FY 2004 FISMA investigation found that Interior was not taking the steps necessary to ensure that Interior systems hosted or operated at non-governmental contractor facilities, such as BIA's Indian trust system backbone TrustNet, have the level of security required by FISMA. See Tr. (Hrng., June 1, 2005, PM Sess.), at 40; see also Pls.' Ex. 163 (document entitled "Assignment Workpaper, Subject: Record of Observation — Contractor Operated Services and Facilities," prepared by Stacey Crouser, NISO (Sept. 29, 2004)), at bp. DOI_OIG_IT0028443 -DOI_OIG_IT0028444 (also discussing the same problem with respect to an NBC system operated by a contractor at a remote facility). "Based on a review of [the contract between BIA and the system operator], there are no requirements for [the contractor] to follow NIST, DOI, and OMB guidelines and no requirements for independent audits.... Additionally, there is no requirement for [the contractor] to develop the required certification and accreditation documentation...." Pls.' Ex. 163, at bp. DOI_ OIG_IT0028443. Sandy testified that it is Interior's responsibility to ensure that any contractor with access to or control over any of Interior's information or information systems complies with FISMA requirements for securing those IT assets. See Tr. (Hrng., June 1, 2005, PM Sess.) at 42 (testimony of Sandy). Compounding this problem, Sandy's team found that Interior had not even fully identified all systems that are "outsourced" to be operated and maintained by private contractors as FISMA requires. See Tr. (Hrng., June 1, 2005, PM Sess.), at 43-44 (testimony of Sandy); Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 7 ("DOI had no specific methodology to identify all contractors with access to DOI systems."); Pls.' Ex. 164 (document entitled "Assignment Workpaper, Subject: Contractor Operated Meeting FISMA, OMB, and DOI Policies," prepared by Stacey Crouser, NISO (Aug. 27, 2005)), at bp. DOI_OIG_IT0028422 (noting that "[o]f the 12 systems [ ] [NISO] found that were contractor operated facilities or operations, DOI had only classified 58% of them as contractor operated facilities or operations (7/12 = 58%)").

The NISO reported significant deficiencies in SSPs for Interior systems, including instances of SSPs lacking a complete list of all active security controls on a system, thereby frustrating attempts to evaluate the effectiveness of those controls, and SSPs that failed to identify who the relevant security contact person is for the system. See Tr. (Hrng., June 1, 2005, PM Sess.) at 62-63 (testimony of Sandy) (indicating that roughly 40 percent, or 8 of 19, of the SSPs tested were deficient under NIST standards); id. at 64 (testimony of Sandy) (Many SSPs "didn't do a really good job of identifying who the [IT security] contact was [for the system]. A lot of management information was the same person or different people. You couldn't really tell who was overall responsible for the system, and the security of it."); Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 5-6; Pls.' Ex. 168 document entitled "Finding Outline, Assignment Number: A-EV-MOA-0006-2004, Assignment: Evaluation of DOI's Information Security policies-procedures-practices-and controls, Program Name: Administration and Background, Finding Number: 1.7," prepared by Stacey Crouser, NISO (Oct. 12, 2004), at bp. DOI_OIG_IT0027618. A number of NBC's SSPs were found deficient during this review. See Tr. (Hrng., June 1, 2005, PM Sess.), at 68-73 (testimony of Sandy) (discussing problems identified in NBC's SSPs); Pls.' Ex. 169 (document entitled "Assignment Workpaper, Subject: Summary of NBC System Security Plans," prepared by Stacey Crouser, NISO (Sept. 16, 2004)), at bp. DOI_OIG_IT0028440-DOI_OIG_ IT0028442. For example, the SSP for the NBC Denver Data Center General Support System Enclave, one of two NBC GSSs that supports numerous important applications for various bureaus and offices, had no "real description of the applications supported and who the users are" and did not incorporate completed interconnection agreements for all the other Interior bureaus and third parties who connect to the system as required by NIST SP 800-47. See Pls.' Ex. 169, at bp. DOI_OIG_IT0028440.

Additionally, Sandy's team found that SSP's "were not being updated based on the results of security tests and evaluations and risk assessments," Tr. (Hrng., June 1, 2005, PM Sess.), at 64 (testimony of Sandy), and had, in the main, deficient contingency plans. See id. at 65 (testimony of Sandy). See also Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 5 (noting that while 16 of the 19 C & A'd systems that were evaluated had some form of contingency plan, we found deficiencies in 12 of these [16] plans). For example, the contingency plan for BIA's TrustNet system, the network "backbone" for BIA's Indian Trust systems, "was limited to only technical procedures and did not identify a team for the recovery operations or include the specific steps to recover from a disruption in service. Additionally, the plan did not show the order of priority for recovering critical applications." Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 5.

For its required annual security testing and evaluation, Interior was relying primarily on monthly automated scanning with a tool called "Nessus," and was only setting the scans to test for vulnerabilities enumerated on the FBI/SysAdmin, Audit, Network, Security (SANS) "Top 20" list of IT security weaknesses. See Tr. (Hrng., June 2, 2005, AM Sess.), at 9 (testimony of Sandy); Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 4; see also Tr. (Hrng., June 1, 2005, PM Sess.), at 75-76 (describing the FBI/SANS Top 20 list as "the ones that come from FBI that have been identified as the most critical weaknesses throughout the IT world that ... can allow hackers or crackers to get into systems real easily"). While this level of vulnerability scanning is certainly preferable to nothing at all, Sandy at length detailed the reasons why scanning only for the 20 most serious weaknesses does not result in an adequate representation of the risk that a network might be subject to unauthorized access from the Internet. See Tr. (Hrng., June 1, 2005, PM Sess.), at 75-102 (discussing problems with reliance on the FBI/SANS Top 20 list); see also Pls.' Ex. 172 (document entitled "Assignment Workpaper, Subject: Expanded Scope for Nessus Scans," prepared by Hector DeJesus, NISO (Sept. 10, 2004)), at bp. DOI_OIG_IT0029061-DOI_OIG_ IT0029065 (identifying various "vulnerabilities that are categorized by Nessus as High Risk factors and Medium Risk Factors that are not included in the [FBI/SANS] top twenty scan" on a number of USGS servers); Pls.' Ex. 175 (document entitled "Assignment Workpaper, Subject: USGS and MMS Important Vulnerabilities," prepared by Hector DeJesus, NISO (Aug. 24, 2004)), at bp. DOI_OIG_IT0029025 DOI_OIG_IT0015686-DOI_OIG_IT0029039 (identifying numerous high risk vulnerabilities on USGS networks and one on an MMS network that were not included in the FBI/SANS Top 20 list).

Sandy's team also found numerous deficiencies in bureaus' and offices' POA & M policies and procedures, as it had in FY 2003. See Tr. (Hrng., June 2, 2005, AM Sess.), at 38 (testimony of Sandy); Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 6-7 (finding that while 84 percent of "bureaus recorded known weaknesses in their POA & Ms most of the time[,]" there was nevertheless "a need to ensure that all reported weaknesses are recorded, priorities are assigned to correct all weaknesses, and costs needed to remedy weaknesses are always identified"). At the POA & M program management level, for example, Sandy found that FWS, BIA, and NPS had no POA & M policies or procedures in place; OSM had policies, but not procedures; BLM had policies and procedures that were not being implemented by BLM state offices; and BOR had both policies and procedures for POA & M management in place. See Tr. (Hrng., June 2, 2005, AM Sess.), at 41-42 (testimony of Sandy); Pls.' Ex. 181 (document entitled "Assignment Workpaper, Subject: Bureau POA & M Policies and Procedures," prepared by Stacey Crouser, NISO (Aug. 5, 2004)), at bp. DOI_OIG_IT0027996-DOI_OIG_ IT0027997 (reporting these results).

For example, while BLM's POA & M policies and procedures called for each state office to compile separate POA & M's to be incorporated into the bureau-level POA & M, NISO found that state offices simply were not compiling their individual POA & Ms. See Tr. (Hrng., June 2, 2005, AM Sess.), at 52-65 (testimony of Sandy). NISO focused particularly on the California and Idaho state offices of BLM, which were found to be not in compliance with BLM's POA & M policy. See id. at 61-62 (testimony of Sandy) (discussing both state offices); Tr. (Hrng., June 2, 2005, PM Sess.), at 64-66 (testimony of Sandy) (discussing problems with POA & M policy implementation at BLM's California State Office); Pls.' Ex. 184 (document entitled "Record of Discussion, Subject: POAM at the state offices," prepared by Kathryn Saylor, NISO (Aug. 11, 2004)), at bp. DOI_OIG_IT0028006 (indicating that BLM's Idaho state office has no POA & M process at all, and that on the BLM's California State Office POA & M "the priority column was not filled in therefore, there is no prioritization of weaknesses for correction ... [and][o]nly 2 of the 31 weaknesses had resources identified" for correcting the weakness).^[14] Both these offices connect to BLM's National Information Resource Management Center ("NIRMC"), which in turn supports a number of Indian Trust systems and applications that access IITD. See Tr. (Hrng., July 25, 2005, AM Sess.), at 25-33 (testimony of James Rolfes, Dir., BLM IT Incident Command Center); Tr. (Hrng., June 28, 2005, PM Sess.), at 106-13 (testimony of Ronnie Levine, BLM CIO). More generally, the IG reported that BLM's POA & M for the BLM enclave reflected resource allocation issues, explaining that:

in Bureau of Land Management's POA & M for the BLM Enclave, there were 20 weaknesses reported as high priority. The POA & M identified the resources need to correct only 5 of these high priorities. However, other weaknesses classified as medium in this same system had the resources identified. Consequently, it is difficult for the bureau to ensure that the highest priority weaknesses will be addressed first.

Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 7.

The Indian Trust bureaus and offices fared particularly badly in the 2004 FISMA review. BIA's TrustNet deficiencies were noted above, and NISO also found problems with BIA's POA & M program. See Tr. (Hrng., June 2, 2005, AM Sess.), at 44-49 (testimony of Sandy). Specifically, NISO reported that "BIA doesn't use the POAM process as a tool to track and mitigate the weaknesses identified ... [and] the TrustNet POAM doesn't reflect all of the weaknesses identified and is not kept up-to-date to reflect completed items or to update milestone completion dates of ongoing items." Pls.' Ex. 182 (document entitled "Record of Discussion, Subject: BIA POAM Process," prepared by Kathryn Saylor, NISO (July 21, 2004)), at bp. DOI_OIG_IT0027991 (recording discussion between Saylor, Stacey Crouser of NISO, and Al Foster, BITSM for BIA). In addition, the BIA POA & M did not report any estimated costs for correcting weaknesses, so that BIA had "no ability to plan for correcting [weaknesses] without an estimate of how much it would cost." See Tr. (Hrng, June 2, 2005, AM Sess.), at 47 (testimony of Sandy); see also Pls.' Ex. 182, at bp. DOI_OIG_IT0027991.

IT systems maintained by the Office of the Special Trustee ("OST") were also found to be rife with security deficiencies in a variety of NISO's Eight Key Areas. See Tr. (Hrng., June 2, 2005, PM Sess.), at 48-51 (testimony of Sandy). OST's C & A package documentation received an overall "poor" rating because it "did not include the Renaissance records center[,]" see Pls.' Ex. 196 (document entitled "Assignment Workpaper, Subject: OST FISMA Matrix," prepared by Harriet Thiesen, NISO (Aug. 4, 2004)), at bp. DOI_OIG_IT0028547; its SSP received an overall "poor" rating because it consisted of no more than "the minimal information necessary in order to report that OST has a system security plan[,]" id.; its contingency plan received an overall rating of "poor" because it was incomplete as of the evaluation date and "contains a significant amount of theory and in the auditor's opinion it would be difficult to test and actually use in time of stress[,]" id.; and its ST & E received an overall rating of "poor" because the documentation was incomplete at the time of evaluation. See id. NISO additionally noted that "OST did not take into consideration [its] field offices when performing risk assessments and doing testing such as ST & E, for example. Without taking into consideration their field offices they have not even begun to identify their risks." Id.

Interior's overall IT security training program, while markedly improved from prior years, see Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 7 (noting that Interior policy requires "annual security awareness training[ ] ... [and] training for all levels of personnel involved with IT systems"), also raised concerns, as the IG reported that:

DOI had no documented criteria for excluding employees from the required training and documenting the basis for the exclusions[,]... had not identified all the individuals with significant information security responsibilities [,] ... [and] had not developed and implemented a program that would ensure those individuals with significant security responsibilities received specialized training that related to the duties performed.

Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 8. Thus, the IG recommended that Interior "establish formal criteria for excluding employees from the required annual security awareness training and establish a process for bureaus to document and justify each excluded individual;" and that Interior "establish criteria to assist bureaus in identifying all positions with significant IT security responsibilities[,] and ... develop and implement a program to ensure that individuals ... receive specialized [IT security] training ... [that] relates to the duties performed[.]" Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 10.

First among the IG's recommendations in the 2004 FISMA report, however, was that Interior "institute an oversight process to ensure bureaus and offices effectively implement DOI security program requirements." Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 9. Highlighting NISO's observation that the bureaus had failed to implement departmental IT security policy in every significant area to one degree or another, the IG advised Interior's CIO to ensure that:

reported system certifications and accreditations are adequately performed[,] budget documentation and POA & Ms can be directly correlated through OMB project/system identifiers to ensure funding addresses security weaknesses; ... IT security costs are integrated into each phase of the life cycle of every system; ... weaknesses identified during OIG and other internal or external reviews are included in the applicable POA & Ms at the time the weaknesses are identified and agreed to by the bureau; ... POA & Ms not only reflect prioritization of weaknesses but also identify the resources necessary to address the higher prioritized weaknesses so that the corrections of high priority weaknesses are performed first; ... DOI's specialized training program for certifying and accrediting officials addresses the requirements of (1) security testing and evaluation, (2) developing continuity of operations plans, (3) testing of the continuity plans, and (4) updating continuity plans based on the test results as part of DOI's certification and accreditation process;... and system security plans and contingency plans are developed and updated accordingly to meet DOI and NIST requirements.

Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 9.^[15]

FY 2005 FISMA Evaluation — The trend toward increasingly complex FISMA evaluation has continued in the FY 2005 reporting period. The now-operational NSM, headed by Mahach, is responsible for conducting the majority of the tasks necessary to complete the IG's evaluation. See Tr. (Hrng., May 20, 2005), at 47-49. Devaney characterized the FY 2005 FISMA evaluation, which for the first time includes external penetration testing — that is, simulated external attacks by "hackers" — of Interior's IT systems, as the next logical step. See Tr. (Hrng., May 20, 2005), at 32-33 (testimony of Devaney). "Some IGs have done [penetration testing] several years ago, and I think we're in the place now where the department has told us they're ready to be tested, and we're testing them." Id. at 33. He elaborated, explaining that "the work that we've done in the past in FISMA has been to assess the department's ability to put in place policies, procedures, training[ ], plan of ... actions and milestones, sort of all the paper and the requirements of ... OMB's [circular] A-130, and now we're evolving and moving into the phase where" the department claims that those things "are in place, [and] as Inspector General I want to see if that's true or not." Id.

When asked why the IG's office had not conducted penetration testing in prior FISMA evaluation periods, Devaney gave as one reason his "impression was that if we had done [penetration testing] two years ago, we would have been able to penetrate the systems" — in other words, Interior's IT security program had simply not advanced far enough for penetration testing to be a useful evaluation tool. See Tr. (Hrng., May 20, 2005, AM Sess.), at 34 (testimony of Devaney). Now, however, "[t]he department has made progress, and has told us" that adequate IT security policies and procedures "are in place, and now it's time to test that proposition." Id. Other changes to the IG's FISMA evaluation methodology for FY 2005 include "trying to provide quarterly reports [to the department]" regarding the IG's progress and findings, which "allows the department ... to know about problems ahead of time so that they can have the opportunity to try to fix them, as opposed to waiting until the end and sort of popping out at them and identifying things they've never heard about." Id. at 49.

Interior and the IG's office executed a Memorandum of Understanding ("MOU"), signed by Devaney on February 11, 2004 and by Cason on April 19, 2004, see Tr. (Hrng., May 20, 2005, AM Sess.), at 45 (testimony of Devaney), "establish[ing] an agreement, terms, and conditions whereunder the U.S. Department of the Interior (DOI) Office of Inspector General (OIG) will provide an independent evaluation of the information security program and practices of the Department of the Interior." Pls.' Ex. 1, at 1. The tasks to be performed during this "independent evaluation" are set out in an attachment to the MOU, called the IG's Network Security Monitoring (NSM) Framework ("NSM Framework"), and include "using various methods and tools to scan networks and systems and attempt penetration of the 13 DOI Wide Area Networks [("WAN"s)]." Pls.' Ex. 1, Attch. A, at 1 ("The Department of the Interior: Office of the Inspector General, Network Security Monitoring (NSM) Framework Description"). More specifically, the first item listed under the "Goals and Objectives" of the NSM Framework is:

[p]roviding independent evaluation of the DOI network security by conducting periodic penetration testing of wired and wireless networks and providing: [a]n internal report for remediation[;][a] management report for oversight bodies[;] [and any] necessary training for DOI staff to reproduce the results of the testing and to implement remediation[.]

Id.

The external penetration testing being performed under the NSM Framework includes "background information gathering — network architecture, security posture, surface scans, [and] penetration testing of devices facing the internet." Pls.' Ex. 1, Attch. A, at 1-2. The IG estimates that Interior operates around two thousand internet-facing devices, "although the actual number changes over time." See id. at 2 n. 2. The NSM Framework specifies that external penetration testing of Interior's IT systems must include testing for "bureau traversal and penetration testing of any wireless networks."^[16]Id. at 2. In addition to external penetration testing of Interior's wired and wireless networks, the NSM Framework provides for: (1) internal penetration testing of "selected DOI internal Trust systems and applications"; (2) testing for bureau traversal and testing of Interior's Virtual Private Exchange ("VPX") "Network Backbone" to determine whether, "[if] successful at penetration into a DOI network, further penetration into other bureau and office networks through the DOI Network Backbone may be carried out []"; (3) "training of DOI staff on duplicating the penetration process used to allow reproduction of similar results and to develop and implement necessary remediation"; (4) tracking by the IG of "the remediation implemented for all vulnerabilities found" during the NSM Framework evaluation; (5) identification by the IG of "any information relating to vulnerabilities of DOI systems that may be published or posted on various web sites or newsgroups" on the Internet "on a monthly basis"; and (6) a reporting system whereunder the IG, for each Interior network tested, will provide to the department documentation on the processes and findings of successful penetration tests, internal reports detailing remediation plans as well as vulnerabilities discovered during Internet research, reports on testing results for management and oversight bodies including scorecards "to reflect remediation of vulnerabilities tracked" and briefings for senior departmental managers. See id. at 2-3.

Of all the tasks listed in the NSM Framework, thus far only (1) external penetration testing of the networks of Interior's individual bureaus and offices and (2) some "wireless penetration testing" have actually commenced. See Tr. (Hrng., May 20, 2005 AM Sess.), at 84-85 (testimony of Devaney). Indeed, the NSM Framework provides that the initial phase — limited to external penetration testing of wired and wireless systems and testing for bureau traversal — will be conducted over a twelve to eighteen month period. See Pls.' Ex. 1, Attch. A, at 2. The IG will only begin the other NSM Framework tasks after the initial phase is completed. See id.; Tr. (Hrng., May 20, 2005 AM Sess.), at 85 (testimony of Devaney) ("Q: ... [E]ssentially it was going to be external penetration testing done for the first 12 to 18 months, and thereafter there would be some work done on things such as internal security issues; is that correct? A: Yes."). Devaney explained that the IG's office could not make any representation to the Court regarding the overall state of security of either Interior's IT systems or the IITD housed on those systems until substantial completion of the majority of the NSM Framework tasks set to proceed after the external penetration testing phase. See Tr. (Hrng., May 20, 2005 AM Sess.), at 82-87 (testimony of Devaney).

ii. External Penetration Testing for the IG's FY 2005 FISMA Evaluation^[17]

Inspector General Devaney explained that Associate Deputy Secretary of the Interior James Cason "came [to the IG] and said that he'd like to have some independent [IT security] testing done" sometime in "the late fall of 2003." See Tr. (Hrng., May 20, 2005 AM Sess.), at 35 (testimony of Devaney). Cason informed Devaney "that he was at a point where he wanted to begin to see if the systems would withstand penetration, and asked me if I would be willing to be the independent tester if they gave us some money to do that to hire a contractor." Id. at 36. As Devaney previously testified, his office's staff and budget for FY 2004 and FY 2005 FISMA evaluation was insufficient to support advanced technical testing, see id. at 11-12, but he "wanted to move aggressively into [IT security testing], and this was ... an offer ... allowing me to jump start that program that I was trying desperately to find funds" to implement. Id. at 37.

But despite the early 2004 execution of the MOU, no external penetration testing of Interior's IT systems was performed during the FY 2004 FISMA evaluation. See id. at 46-47 ("Q: ... But so as of October of 2004, when your office had to turn in the annual FISMA evaluation, you had not yet at that point had the benefit of this external penetration testing that began to move forward in fiscal year 2005? A: That would be correct. Q: At that point in time, had you any external penetration testing information to rely on as part of your FISMA evaluation? A: ... [N]o."). Devaney explained that the RSA financing the MOU's provision for penetration testing — at that time, the IG's only source for the funds necessary to hire a contractor to perform external penetration testing — was expressly conditioned on the availability of sufficient funds in the departmental budget. See id. at 46. The availability of the funding provided under the RSA was not resolved until November 2004, over a month after the IG's FY 2004 FISMA evaluation was completed. See id.; Pls.' Ex. 1, at bp. DOI ITE 018 000011 (showing RSA only approved by Interior, the "paying agency," on Nov. 22, 2004 by signature of one B.G. Topper, Budget Officer, Office of the Secretary).

Having obtained the funds necessary to begin the external penetration testing phase of the NSM Framework, the IG's office contracted with two companies, Northrop Grumman Computer Systems ("NGCS") and Internet Security Systems ("ISS"), to conduct the testing. See Pls.' Ex. 3 ("U.S. Department of the Interior, Office of the Inspector General: Rules of Engagement, Information Technology Security Penetration Testing" (Nov. 23, 2004)) ("Pls.' Ex. 3"), at 3. The objective of the IG's penetration testing of Interior's systems is stated as follows:

[T]o conduct a logical access controls evaluation to identify and expose vulnerabilities in the DOI information system infrastructure to evaluate whether systems are vulnerable to unauthorized access and use. Selected applications software, host operating system configuration, and associated network connectivity and access controls currently implemented will also be assessed. The objectives ... are to assess the potential impact of existing logical access controls vulnerabilities on the DOI's systems. [Penetration testing] is not structured as, and is not intended to be, an evaluation of the organizational security posture of the DOI or its components.

Id. at 4-5.

In general, and as understood by Interior and the IG's office, penetration testing is defined as "a type of computer vulnerability testing in which the security of an organization's computer systems is assessed using similar tools and techniques that a potential attacker would use. Penetration testing is useful in evaluating whether critical systems, related applications and data are vulnerable to unauthorized access and disclosure." Pls.' Ex. 3, at 5. Pursuant to the Rules of Engagement ("ROE") agreed upon by the department, the IG's office, and the contractors, NGCS and ISS would conduct penetration testing of networks at BIA, BLM, BOR, NBC, MMS, NPS, OSM, and USGS. See id. at 3. The ROE specifies that the contractors will be testing "blind" — that is, in a manner designed to "simulat[e] the scenario of an outsider with limited or no knowledge of DOI's IT environment." Id. at 5. As such, prior to actually attempting to gain access to any Interior IT system, the contractor must engage in what the ROE terms the "Discovery Phase," during which "[i]nformation acquired from public Internet sources, automated exploration, and probing techniques will be used to examine DOI IT assets that might be `at risk' due to public knowledge." Id. at 6.^[18]

Though penetration testing "include[s] procedures to simulate external threats," Pls.' Ex. 3, at 6, the ROE explicitly prohibits NGCS and ISS from conducting any sort of "destructive or otherwise intrusive testing," in order "to ensure that the regular business function of DOI operations is unaffected." Id. at 5-6. This restriction dictates that the results of the IG's penetration testing under this ROE "cannot be inferred to be similar to those of an attacker." Id. at 5. Outside attackers with malicious intent may make "deliberate efforts to alter, destroy, or make unavailable systems and data," or "perform tests and investigative routines where the outcomes are unknown." Id. NGCS and ISS, of course, were prohibited under the ROE from taking any action that could modify or change "critical files or data" or otherwise "disable users or deny service." Id. at 8. Despite these restrictions, the ROE makes clear that the goal of the contractors' penetration efforts should be "to gain some level of use privilege access, `Admin', or `root' account privilege on systems that support network operations or business applications." Id. at 7-8. "Admin" or "root" level privileges allow a user to control, to differing degrees, the system to which he or she has access. In some cases, what is called "administrator privilege" or "superuser status" may be obtained, which may allow a user to entirely control a system or network, to alter or destroy data housed or accessed by the system or network, to disable the system or network altogether, or to alter the rules governing the functioning of the system or network. See Tr. (Hrng., May 3, 2005, AM Sess.), at 75-77 (testimony of Miles, discussing the nature of "administrator privileges").

The timeframe for penetration testing under the ROE extends from November 2004 to September 2005, and the tests are conducted primarily at ISS's laboratories in Herndon, Virginia and Atlanta, Georgia. See Pls.' Ex. 3, at 7-8. When testing of the systems of a specific bureau or office is completed, the ROE requires that the contractors provide both a management report, which is a "high-level summary of findings along with a graphical representation of the number and severity of vulnerabilities," and a technical report, "detail [ing] the results ... of each test and ... includ[ing] penetration results, data and information obtained, and recommendations for remediation." Id. at 11. In the technical report, the contractor must provide "[c]harts and narrative [to] articulate the level of effort for a successful penetration, the likelihood for exploitation of a given vulnerability and its impact." Id.

Nowhere in the ROE is there mention of this case or the Individual Indian Trust Data housed on or accessed by the Interior systems set to be tested. See id., passim. Inspector General Devaney noted that during his conversation with Associate Deputy Secretary Cason that resulted in the development of the IG's penetration testing program for FY 2005, there was no "specific discussion about Indian trust, although ... clearly Mr. Cason is engaged in the department's oversight of [the trust] issue and I assumed ... that this was a major concern." Tr. (Hrng., May 20, 2005 AM Sess.), at 81 (testimony of Devaney). Indeed, Devaney expressly denied any specific focus on securing Indian trust data in his office's FISMA evaluations. Rather, he explained, during the FY 2005 penetration testing:

we were going to work our way through [Interior's] systems. We were going to penetrate and see what we found, and for those systems that housed trust data, my assumption was that if we got in, we might encounter it. But the testing was not, in my mind, specifically being done to identify ... weaknesses in systems relative [ ]strictly to trust data.

Id. at 42. Devaney also informed the Court that testing the extent of bureau traversal, either through bureau-to-bureau interconnections or Interior's so-called "network backbone," was not a primary focus of the IG's efforts. See id. at 68-69. While he noted that "the interconnectivity [between Interior's bureaus and offices] is a major concern," he said that "the focus" of the FY 2005 penetration testing "was to get into the individual bureau networks." See id. at 68.

Bureau of Land Management — External penetration testing of IT systems at the Bureau of Land Management was conducted between February 21 and March 11, 2005 by Scott Miles, a principal security consultant for ISS. See Pls.' Ex. 7 ("United States Department of the Interior, Office of Inspector General: Memorandum from Earl Devaney to Kathleen Clarke, Director, Bureau of Land Management, Subject: IT Security Penetration Testing — Notification of Potential Finding and Recommendation") (Apr. 6, 2005) ("Devaney BLM Memo.") ("Pls.' Ex. 7"), at bp. OIG WDC 0001 000003 (Attachment entitled "United States Department of Interior, Office of Inspector General: Memorandum from Michael F. Wood, Assistant Inspector General for Administrative Services and Information Management to W. Hord Tipton, Chief Information Officer, Department of the Interior, and Ronnie Levine, Chief Information Officer, Bureau of Land Management; Subject: OIG Report `NSM-EV-BLM-0020-2005- Penetration Testing' External Penetration Testing of Bureau of Land Management") (hereinafter "Wood BLM Memo"); Tr. (Hrng., May 3, 2005, AM Sess.), at 26-27, 32-33 (testimony of Miles, describing his job title, responsibilities, and qualifications. Though the IG's contractor was "provided ... with sensitive information [about BLM systems] that would not normally be available to an outside entity" by the departmental CIO's office, "the OIG chose not to utilize the information and conducted its testing to best resemble a real Internet based) Pls.' Ex. 7, at bp. OIG WDC 0001 000003 (Wood BLM Memo). Consistent with Devaney's assertion that the IG's penetration testing effort was not focused in any way on testing the security of IITD on Interior IT systems, the IG's office did not provide Miles with any information concerning the nature of IITD or whether any IITD was housed on or accessed by IT systems at BLM. See Tr. (Hrng., May 3, 2005, AM Sess.), at 42-45 (testimony of Miles). Also consistent with Devaney's definition of the scope of the evaluation, Miles did not attempt to test the accessibility of the networks of other Interior bureaus or offices once he had penetrated BLM's network, see Tr. (Hrng., May 3, 2005, PM Sess., at 100), except for testing the accessibility of "three offline networks we were given" by the IG's office. Tr. (Hrng., May 17, 2005, AM Sess.), at 31.

In a high-level summary, the IG's office reported that the external penetration "testing of BLM revealed a number of issues that place the BLM network at a fairly high risk of unauthorized access from the Internet" and that the IG's contractor "was able to penetrate BLM's internal networks from the Internet and masquerade as [an authorized user] to discover and establish connections to servers or systems purporting to contain Indian Trust Data." Pls. Ex. 7, at bp. OIG WDC 0001 000004 (BLM Wood Memo.). The IG's office reported finding numerous "critical vulnerabilities" in both BLM's network architecture and web-based applications, see id., and recommended a variety of corrective actions, including "[l]imit[ing] access to sensitive Indian Trust systems and networks to only those with legitimate need" and "[f]urther isolat [ing] and separat[ing] Indian Trust systems and [using] additional security monitoring tools to detect and prevent unauthorized access" to Indian Trust data. See id. at bp. OIG WDC 0001 000005.

The IG advised that "if BLM cannot meet these recommendations by April 15, 2005 BLM should disconnect any existing network access to their Indian trust systems." Pls.' Ex. 7, at bp. OIG WDC 0001 000012 (attachment entitled "Office of the Inspector General: Notice of Potential Finding and Recommendation") (hereinafter "BLM NPFR"). BLM "eliminated all external Internet access to BLM web servers with the exception of mail servers and those web servers necessary to support the preservation of life and safety, especially fire fighting mission activities... on the evening of April 8, 2005." Defs.' Opp. to Pls.' Mot., Ex. 2 (Declaration of Ronnie Levine, Chief Information Officer of BLM ("Levine Decl.")), at ¶ 5. Miles testified that this course of action was appropriate given the nature of the vulnerabilities discovered during the penetration testing. See Tr. Hrng., May 3, 2005 PM Sess, at 69 (testimony of Miles); see also Pls.' Ex. 53 (Email from Scott Miles to Dan Ingvaldson, ISS Atlanta; Brad MacKenzie, ISS Atlanta; Subject: "FW: Land Management agency shuts Web site over security fears" (Apr. 19, 2005)) (commenting, in response to an earlier email to Miles containing a news article about the BLM Internet disconnection, that "this is probably the perfect response from [BLM] given the types of issues they had").

More specifically, Miles exploited a number of different kinds of vulnerabilities to gain access to BLM's systems from the Internet,^[19] including a weakness that allowed him to access an Internet-facing BLM system using a piece of information he had obtained during his earlier penetration testing of USGS. See Tr. (Hrng., May 3, 2005, AM Sess.), at 68-71 (testimony of Miles); see also Pls.' Ex. 7, bp. OIG WDC 0001 000008 (BLM NPFR); id. at bp. OIG WDC 0001 000018 (Attachment entitled "Internet Security Systems: Management Report for External Penetration Testing, for DOI Office of Inspector General," noting Sites assessed in this report: DOI Bureau of Land Management) (hereinafter "ISS BLM Mgt. Rep."); id. at bp. OIG WDC 0001 000088-000089 (ISS BLM Tech. Rep., giving greater detail, noting that existence of weakness was "a matter of policy," but that such policy "does increase the potential for unauthorized access of BLM resources"). And, Miles was not the first to discover this particular weakness in BLM's IT security — Inspector General Devaney testified that his office "had informed USGS that they should ... remedy that situation" and remove the information that allowed Miles into BLM. See Tr. (Hrng., May 20, 2005, AM Sess.), at 69 (testimony of Devaney). Devaney further observed that "the fact that the computer consultant company, the hacker, if you will, used that [information] to get into BLM was ... a sign that my recommendations weren't being followed." Id.

This particular means of penetration allowed Miles to access a database that contained a list partially entitled "Indian Trust Systems," which identified other "systems at BLM and whether they did or did not contain information related to the Indian trust data." Tr. (Hrng., May 3, 2005, PM Sess.), at 18-19 (testimony of Miles); see Pls.' Ex. 7, at bp. OIG WDC 0001 000004 (Wood BLM Memo.), OIG WDC 0001 000008-000011 (BLM NPFR) (presenting screen shots), OIG WDC 0001 000088-000089 (ISS BLM Tech. Rep.) (presenting screen shots). From this point, Miles was able to "successfully discover and probe three systems identified by BLM as housing Indian Trust data." Pls.' Ex. 7, at bp. OIG WDC 0001 000001 (Devaney BLM Memo.), see id. at bp. OIG WDC 0001 000008-000011 (detailing systems probed and the methods of access), id. at bp. OIG WDC 0001 000020-000021 (ISS BLM Mgt. Rep.) (explaining the penetration of one of these systems in detail); id. at bp. OIG WDC 0001 000106 (ISS BLM Tech. Rep.) (noting the problem, observing that "[w]hile none of these [Indian Trust] systems are accessible directly from the Internet, the ability to reach these and other internal BLM systems directly from systems compromised from the Internet puts them at increased risk"). These findings prompted the Inspector General to inform the director of BLM that "it is safe to say that we could have easily compromised the confidentiality, integrity, and availability of the identified Indian Trust data residing" on BLM systems. See Pls.' Ex. 7, at bp. OIG WDC 0001 000001 (Devaney BLM Memo.).

Once Miles had penetrated into BLM's network from the Internet, he was able to gain "administrator privileges" on at least two BLM systems. See Tr. (Hrng., May 3, 2005, PM Sess.), at 49 (testimony of Miles); id. at 75-77; see also Pls.' Ex. 7, at bp. OIG WDC 0001 000088-000102 (ISS BLM Tech. Rep.) (detailing the steps taken after initial penetration from the Internet to affect additional penetration of BLM systems). "Administrator privileges" on a database, Miles explained, is "the ability to manage the data ... to do anything to that data, read, write, delete, change, modify." Id. at 75-76. Administrator privileges also allows a user to disable what are called "audit controls," or the mechanisms by which user activity on a system is recorded. See id. at 76; see also Tr. (Hrng., May 6, 2005 AM Sess.), at 54-55 (testimony of Philip Brass, senior security consultant for ISS who performed penetration testing on NBC) (explaining that the ability to disable or delete what are called "audit logs" or "audit trails" allows a user to "remove the traces" of operations or transactions he or she performs on a system). One of the systems Miles accessed with elevated privileges allowed him to gain control of a ZANTAZ email server, see Tr. (Hrng., May 3, 2005, AM Sess.), at 48-49, 61, 69 (testimony of Miles); Pls.' Ex. 7, at bp. OIG WDC 0001 000100 (ISS BLM Tech. Rep.) (identifying compromised server by name); Pls.' Ex. 9 ("BLM NIRMC Lotus Domino, Response to OIG Security Audit Penetration Testing Results" (Mar. 18, 2005)), at bp. DOI IT E0037353 (identifying this same server as a ZANTAZ server). This at least demonstrates the vulnerability of BLM's version of Interior's email archiving system, which was implemented specifically to facilitate discovery of information material to this litigation. With administrative privileges on a ZANTAZ server, Miles could have deleted, modified, or otherwise affected email that should be archived. See Tr. (Hrng., May 3, 2005, PM Sess.), at 49-50, 61 (testimony of Miles).

Another BLM system to which Miles gained access is the National Integrated Land System ("NILS"). See Tr. (Hrng., May 3, 2005 PM Sess.), at 103-08 (testimony of Miles); Pls.' Ex. 7, at bp. OIG WDC 0001 000020 (ISS BLM Mgt. Rep.) (specifying that NILS was accessed); id. at bp. OIG WDC 0001 000094-000098 (ISS BLM Tech. Rep.) (detailing the penetration of NILS); Pls.' Ex. 77 (Email from Roger Mahach to Scott Miles (Mar. 23, 2005); Attachment entitled United Stated Department of the Interior, Bureau of Land Management, Land & Resources Project Office [("L & RPO")]: National Integrated Land System, System Security Plan (L & RPO Doc. No. NILS-NILS-SSP-V2.XX-XXX-XX/03/03, June 3, 2003)) (hereinafter "2003 NILS SSP"), at bp. DOI_IT_0010966 (identifying the system). The 2003 NILS SSP specifies that:

The primary purpose of the NILS system is to automate BLM cadastral surveying and land management business rules. The system model will be useable by and available to the general surveying community.... NILS [consists] of two environments: a transactional side in which cadastral data and land resource management data is captured, analyzed, edited and committed to permanent records. The publication side, Land Survey Information System, will provide maps, reports and [Geographic Information System] information to public and government customers.

Pls. Ex. 77, at bp. DOI_IT_0010971 (2003 NILS SSP). During the penetration testing period but before completion of the deliverable ISS report, Miles sent a status report to Roger Mahach in the IG's office documenting his penetration of the NILS system. See Pls.' Ex. 74 (Email from Scott Miles to Roger Mahach; Subject: DOI Status-3/1 (Mar. 1, 2005)), at bp. DOI_IT_ 0011180.

Roger Mahach, head of the IG's NSM group and former DITSM for Interior, testified that he was initially very concerned about Miles' penetration of NILS because he thought it "may have been a trust system."^[20]See Tr. (Hrng., May 23, 2005, AM Sess.), at 44-45 (testimony of Mahach); Pls.' Ex. 75 (Email from Roger Mahach to Scott Miles; Subject: BLM (Mar. 4, 2005)), at bp. DOI_IT_0010958 (referencing Miles' penetration of NILS, commenting that "[w]e need to get more info on this system as it [could] represent a very high risk target for BLM and DOI"); Tr. (Hrng., May 4, 2005, PM Sess.), at 30-31 (testimony of Miles) (recalling this exchange with Mahach). Mahach himself could not testify to the nature of the data contained on the NILS system, other than that it contained "some kind of cadastral survey" data, see Tr. (Hrng., May 23, 2005, AM Sess.), at 52-53 (testimony of Mahach), but he indicated that he "had a conversation with the BLM folks" about the NILS system and "[t]hey mentioned that they did not have trust data on there." See id. at 52. Indeed, in part because the IG's office did not ask ISS to verify that they had, in fact, accessed IITD, see Tr. (Hrng., May 3, 2005, PM Sess.), at 21 (testimony of Miles), the question whether BLM"s NILS system houses Indian trust data remains unsettled.

The more important ISS finding, however, was that penetration into the NILS system allowed "full penetration" throughout the BLM network. See Tr. (Hrng., May 3, 2005 PM Sess.), at 101 (testimony of Miles); see also Pls.' Ex. 7, at bp. OIG WDC 0001 000057-000058 (ISS BLM Tech. Rep.) (discussing access to NILS as one of two paths to "full penetration of the BLM environment"); id. at bp. OIG WDC 0001 000088-000106 (ISS BLM Tech. Rep.) (detailing methods of additional penetration from NILS system). Miles explains that full penetration "means gaining access to systems in the BLM network to basically provide the same type of access that you would have if you were physically inside the building or inside the internal BLM network." Tr. (Hrng., May 3, 2005, PM Sess.), at 101 (testimony of Miles). For example, "full penetration" allowed Miles to access BLM's internal IT security vulnerability reports, see id. at 106; Pls.' Ex. 7, at bp. OIG WDC 0001 000091 (ISS BLM Tech. Rep.) (providing screen shot); had Miles been a malicious hacker attempting to compromise BLM resources, access to such a report might provide a "road map" for further penetration. See Tr. (Hrng., May 3, 2005, PM Sess.), at 106-07. More generally, because BLM systems undoubtedly house and access IITD, as will be discussed more fully below, "full penetration" of BLM's network necessarily includes penetration of Indian trust systems and the potential compromise of Indian trust data.

The IG's BLM NPFR indicates that while ISS was "detected twice by BLM when Internet-based scanning was being conducted," Pls.' Ex. 7, at bp. OIG WDC 0001 000004 (BLM NPFR); Tr. (Hrng., May 3, 2005, AM Sess.), at 72-73 (testimony of Miles) (discussing this early "blocking"); "none of [ISS's] hacking activities within the BLM were observed or blocked." Pls.' Ex. 7, at bp. OIG WDC 0001 000004 (BLM NPFR); Tr. (Hrng., May 3, 2005, PM Sess.), at 62-63. During his penetration of BLM's systems, Miles noted the presence of several kinds of security controls that he found to be in keeping with the "best practices" of the IT security community. See Tr. (Hrng., May 18, 2005, PM Sess.), at 75-78 (testimony of Miles). But despite these controls, Miles characterized BLM's IT security, at least for the penetrable systems, as "poor" overall. See Tr. (Hrng., May 3, 2005, PM Sess.), at 22 (testimony of Miles).

ISS assigns risk ratings of "high," "medium," or "low" to each vulnerability identified during the course of penetration testing according to the methodology set out in NIST SP 800-30 — that is, "based on the potential impact of the vulnerability combined with the likelihood that the vulnerability could be exploited." Pls.' Ex. 7, at bp. OIG WDC 0001 000022 (ISS BLM Mgt. Rep.); see Tr. (Hrng., May 18, 2005, PM Sess.), at 62-63 (testimony of Miles) (explaining his use of this risk calculation); see e.g., Pls.' Ex. 7, at bp. OIG WDC 0001 000019-000021 (ISS BLM Mgt. Rep.); id. at bp. OIG WDC 0001 000054-000073 (ISS BLM Tech. Rep.) (assigning risk ratings to vulnerabilities found in BLM systems). Upon completion of penetration testing of a particular bureau or office, ISS makes "an overall assessment given all of the vulnerabilities ... found, ... how severe they are, [and] the controls ... in place" to give the overall network a risk rating of "high," "medium," or "low." See Tr. (Hrng., May 31, 2005, PM Sess.), at 63 (testimony of Miles). Overall, Miles concluded that BLM's network was at "a high risk of unauthorized access from the Internet." See Tr. (Hrng., May 24, 2005 PM Sess.), at 55 (testimony of Miles).

Bureau of Indian Affairs — The Bureau of Indian Affairs, which is not currently connected to the Internet, was subjected to penetration testing by ISS's Scott Miles on December 20, 2004. See Tr. (Hrng., May 4, 2004, PM Sess.), at 48-50 (testimony of Miles) (discussing BIA penetration testing). Although the penetration test of BIA was conducted "`blind' mode," ISS reported that

because the BIA networks tested are not currently connected to the Internet, the penetration test was performed in cooperation with BIA. All testing was performed on-site in BIA facilities. Network access was provided outside of the network, where the network would be connected to the Internet, were Internet access allowed. This testing scenario simulates what an individual would see if Internet access were in place. ... ISS was only provided with a work space in the BIA data center, a network port to plug into, and an IP address to use for the testing system. ... Only those management and security coordinators required to set up the required access at BIA were aware of the text. No other personnel were informed of testing in order to more closely mimic real attack activity and to evaluate response mechanisms.

Pls.' Ex. 10 ("Internet Security Systems, Management Report for External Penetration Test for DOI Office of the Inspector General: Sites assessed in this report: Bureau of Indian Affairs" (Dec.2004)) ("ISS BIA Mgt. Rep."), at bp. OIG WDC 0006 000005-000006. ISS conducted its on-site testing at the BIA's Herndon, Virginia facility. See Tr. (Hrng., May 4, 2005 PM Sess.), at 50 (testimony of Miles).

Prior to this actual on-site penetration testing, Miles performed what he characterized as "a fairly simple test just to identify if certain network ranges that we were provided were accessible from the Internet." Tr. (Hrng., May 4, 2005, PM Sess.), at 45; see also Pls.' Ex. 10A ("Internet Security Systems, BIA/OST Access Test" (Dec. 8, 2004)) ("ISS BIA Access Test Rep."). Miles "performed `ping sweeps' of all possible IP addresses in the BIA and OST networks identified" to identify "devices by determining if they respond to standard Internet Protocol requests. Both `ICMP' and `TCP' ping requests were sent to each address." Pls.' Ex. 10A, at bp. OIG WDC 007 000002 (ISS BIA Access Test Rep.). No devices connected to any BIA network within the tested IP address ranges responded to any ping request; one OST device responded, but appeared to have no active or accessible data or services, and thus presented little or no risk to internal OST systems. See id.; Tr. (Hrng., May 4, 2005 PM Sess.), at 45-46 (testimony of Miles) ("We found that there was one address that appeared to be active, ... in other words, it looked like it referred to a device that was actually running, but we couldn't identify anything ... like[] web servers or mail ... on the device.").

Miles conducted penetration testing of BIA networks at the BIA Herndon facility by way of a simulated Internet connection — he was physically plugged into the network in a manner that "was designed to [show] what would be there if their networks at that facility were connected to the Internet." Tr. (Hrng., May 4, 2005, PM Sess.), at 62. Discussing the purpose of subjecting an offline network to penetration testing, Miles explained that his "understanding is that [BIA] had been developing... security controls ... that would protect the systems if they were connected to the Internet. This was a test of that design that they had architected to see if it would indeed provide the protection." Id. at 63. ISS summarized the results of the testing as follows:

The network ranges tested consisted of 3 network ranges covering almost 66,000 possible devices. A total of 4 active devices were found, allowing connections on 9 different active services. Of the 9 services found, however, all but two immediately disconnect before allowing any type of interaction. Of the 4 active device addresses, two were found to have some degree of vulnerability. If this environment were accessible from the Internet, it would be an extremely small footprint for such a large organization.

Pls.' Ex. 10, at bp. OIG WDC 0006 000007 (ISS BIA Mgt. Rep.). Miles noted that the active devices that he identified "appeared to be firewalls and mail servers," but that he "wasn't able to get access to them." Tr. (Hrng., May 4, 2005, PM Sess.), at 57 (testimony of Miles).

ISS identified five low-risk and one medium-risk vulnerability that would exist regarding these devices if the BIA network was connected to the Internet. See Pls.' Ex. 11 ("Internet Security Systems, Technical Report for External Penetration Test for DOI Office of the Inspector General: Sites assessed in this report: Bureau of Indian Affairs" (Dec.2004)) ("ISS BIA Tech. Rep."), at bp. OIG WDC 0005 000009-000011 (summarizing the nature and impact of these vulnerabilities). "None of the vulnerabilities resulted in penetration," though "[s]ix instances of [four] different vulnerabilities could be exploited to perform denial of service or obtain non-sensitive information [.]" Id. at bp. OIG WDC 0005 000010 (ISS BIA Tech. Rep.). There is no evidence that any of the vulnerable devices ISS identified during its testing of BIA's network house or access Indian Trust data, and Miles testified that the subject of IITD was not raised during his debriefing with BIA officials and members of the IG's office after ISS's testing of BIA systems was completed. See Tr. (Hrng., May 4, 2005, PM Sess.), at 33-34 (testimony of Miles).

Principally, the problems involved the availability of certain information about the functioning of the network and its devices that might assist an attacker in penetrating the system from the Internet. See Pls.' Ex. 11, at bp. OIG WDC 0005 000020-0000000023 (ISS BIA Tech. Rep.) (presenting detailed descriptions and analysis of the identified vulnerabilities). Overall, Miles concluded that "if [BIA] had actually plugged in what I was testing to the Internet, which was the way I understood the architecture to be, then [there] would be a low risk of penetration from the Internet." Tr. (Hrng., May 4, 2005, PM Sess.), at 50 (testimony of Miles). The comprehensiveness of ISS's evaluation in this regard, however, has not been satisfactorily established.

As Miles testified, ISS only tested systems at BIA's Herndon facility and did not evaluate the security of any separate systems that might be operated at other BIA locations. See Tr. (Hrng., May 4, 2005, AM Sess), at 21-22 (testimony of Miles); Tr. (Hrng., May 4, 2005, PM Sess.), at 49 (testimony of Miles). Therefore, any vulnerabilities that might exist if BIA systems housed at other facilities were connected to the Internet would not have been identified by ISS. Additionally, at the BIA facility in Herndon, Miles observed "a server room with quite a few servers in it," which led him to assume that "there's a lot of other systems there" beyond those that he tested. See Tr. (Hrng., May 4, 2005 PM Sess.), at 61-62 (testimony of Miles). But Miles's assumption that he was testing everything "that would be there if their network at that facility were connected to the Internet," id. at 62, was based on the representations of BIA officials rather than any independent testing by ISS of what would be visible if BIA connected its network to the Internet. See id. at 49 ("Q: Did you have any direct communications with BIA's officials during the testing? A: We had a conversation before testing started to make sure I understood where ... I was being connected on the network, and that that would be an adequate representation of ... what you would see if that were connected to the Internet."). Finally, Miles was not asked to evaluate the security of BIA's legacy systems that house or access IITD, such as the Land and Resource Information System ("LRIS") and the Integrated Records Management System ("IRMS"). See Tr. (Hrng., May 18, 2005, AM Sess.), at 18 (testimony of Miles); Tr. (Hrng., May 19, 2005, AM Sess.), at 9 (testimony of Miles).

Bureau of Reclamation — ISS's Scott Miles conducted penetration testing against the Bureau of Reclamation's network between January 17, 2005 and February 3, 2005. See Pls.' Ex. 12 ("Internet Security Systems, Management Report for External Penetration Test for DOI Office of the Inspector General: Sites assessed in this report: U.S. Bureau of Reclamation" (Feb.2005)) ("ISS BOR Mgt. Rep."), at bp. OIG WDC 0002 000005. Based on the identification of several vulnerabilities with "medium" and "high" risk-ratings, ISS concluded that BOR's network was at "medium/high" risk of unauthorized access from the Internet. See Tr. (Hrng., May 4, 2005, PM Sess.), at 66 (testimony of Miles); Pls.' Ex. 12, at bp. OIG WDC 0006 000002 (ISS BOR Mgt. Rep.). Consistent with the IG's express intention that the penetration testing not be focused primarily on Indian trust concerns, Miles was not informed whether any IITD was housed or on accessed by the BOR systems he was to test, nor was he instructed to attempt to access IITD. See Tr. (Hrng., May 4, 2005 PM Sess.), at 67 (testimony of Miles). Indeed, Miles testified that he would not likely recognize IITD even if he came across it during testing, as he had been given no information about the subject. See id. at 75 (testimony of Miles).

ISS summarized the results of the BOR penetration test as follows:

Some significant vulnerabilities were found that allow penetration into Reclamation networks or allow unauthorized access to information. The environment exhibits a number of good security practices and controls that can help mitigate the effect of vulnerabilities, but it is still at a significant risk of system compromise or access to unauthorized data as a result of the issues identified.

Pls.' Ex. 12, at bp. OIG WDC 0002 000006 (ISS BOR Mgt. Rep.). Miles recalled that he "was able to penetrate ... one specific system at Reclamation, and from there [was] able to get to some other systems, some of which may have been on what we would call the internal Reclamation network." Tr. (Hrng., May 4, 2005 PM Sess., at 70); see also Pls.' Ex. 12, at bp. OIG WDC 0002 000006. (ISS BOR Mgt. Rep.) (explaining that penetration of BOR's internal network was accomplished through a "single remotely-exploitable vulnerability").

This particular vulnerability, classified by ISS as "high risk," see Pls.' Ex. 13 ("Internet Security Systems, Technical Report for External Penetration Testing for DOI Office of the Inspector General: Sites assessed in this report: U.S. Bureau of Reclamation" (Feb.2005)) ("ISS BOR Tech. Rep."), at bp. OIG WDC 0003 000026-000027 (detailing the nature of the specific vulnerability), is a web-application based vulnerability similar to high and medium risk vulnerabilities in BLM systems identified by ISS during penetration testing. See Tr. (Hrng., May 4, 2005, PM Sess.), at 73-75 (characterizing the vulnerability). Other web-application based vulnerabilities were identified that are identical to vulnerabilities ISS found in BLM's network. See id. at 77-80 (testimony of Miles) (describing vulnerabilities, noting similarity to BLM test results); Pls.' Ex. 13, at bp. OIG WDC 0003 000028-000030, 000031-000032 (ISS BOR Tech. Rep.) (describing vulnerabilities in more detail). The risk-classification of these web-application related vulnerabilities varied, of course, between BLM and BOR depending on their ease of exploitation and impact, for example, on sensitive data or operations that their exploitation might expose. In the BOR network environment, these vulnerabilities were all given a "medium" risk rating. See Pls.' Ex. 13 at bp. OIG WDC 0003 000028-000030, 000031-000032 (ISS BOR Tech. Rep.).

Once Miles penetrated into the internal BLM network from the Internet, he discovered other vulnerabilities that allowed him to elevate his user privileges on at least one system to "super user" status, which is the equivalent of "administrator privileges" in that it allows the holder to alter and delete data, modify system configurations, and disable audit logging within the system. See Tr. (Hrng., May 4, 2005, PM Sess.), at 71-72 (testimony of Miles); Pls.' Ex. 12, at bp. OIG WDC 0002 000008 (ISS BOR Mgt. Rep.); Pls' Ex. 13, at bp. OIG WDC 0003 000027-000028, 000031-000032 (ISS BOR Tech. Rep.) (detailing these vulnerabilities). Miles did not attempt to determine whether his access and elevated privileges on the BOR internal network could be leveraged to gain access to the networks of other Interior bureaus and offices, see Tr. (Hrng., May 4, 2005, PM Sess.), at 73-74 (testimony of Miles), and there is no evidence that any of the internal BOR systems Miles penetrated housed or accessed IITD. In fact, the only specific data-type Miles could recall noticing he had obtained during the BOR testing was something "related to water levels and things like that that were pooled and presented on the Internet web site." Id. at 73.

ISS also commented in its official report that:

All of the Internet-accessible systems were configured with obvious attention paid to security. Only a handful of systems such as web and mail services are accessible from the Internet and are well [secured] against known vulnerabilities. The two web servers that were compromised ... exhibited a number of good security practices such as up to date security patches, security monitoring software, and strong password policies that eliminate many common vulnerabilities and reduced the impact of identified vulnerabilities.

Pls.' Ex. 13, at bp. OIG WDC 0002 000006 (ISS BOR Tech. Rep.). However, while "[m]any security tools were observed on compromised systems during the assessment," none prevented penetration or "result[ed] in immediate detection of unauthorized access." Id. at bp. OIG WDC 0002 000007. Indeed, though ISS compromised "the first system" on "the first day of testing" BOR did not detect unauthorized probing until seven days after testing began, did not detect unauthorized access to a BOR system until nine days after testing began, and did not institute a countermeasure until ten days after the start of testing. See id. On the tenth day after ISS began penetration testing, BOR blocked "the primary testing network ... from all access to reclamation networks." Id.

This is at least a slight improvement over the performance of BLM's IT security systems, which ISS reported had not once either detected or countered any of their hacking activities. The security profile of BOR is similar to BLM in that primary points of weakness are the implementation of web-applications and methods for detecting and blocking unauthorized access.

Minerals Management Service — External penetration testing of IT systems at MMS was conducted by Scott Miles, and was completed before May 17, 2005. See Tr. (Hrng., May 17, 2005, PM Sess.), at 87 (testimony of Miles) (explaining that he had completed testing of MMS and was presently preparing his deliverable report). Miles identified three vulnerabilities during his testing that are similar to the web-application related vulnerabilities he identified while testing BLM and BOR. See id. at 90-91 (testimony of Miles) (explaining the nature of the vulnerabilities identified during testing of MMS). Miles characterized these vulnerabilities as medium risk because they were either difficult to exploit or not useful for gaining access to sensitive applications and data. See id. at 90-94 (testimony of Miles).

As was the case with the other penetration tests he conducted for Interior's Inspector General, Miles was given only a range of network addresses for MMS and was not informed of what specific networks, applications, or information-types he might encounter during the testing. See id. at 95-96 (testimony of Miles). Miles was not able to penetrate into the MMS network from the Internet using these few vulnerabilities, see Tr. (Hrng., May 18, 2005, PM Sess.), at 47 (testimony of Miles) ("I'm able to say that given the network ranges that we tested, which are those defined as owned by MMS, that we weren't able to penetrate into those systems, meaning we weren't able to gain ... unauthorized access to data or systems in those network ranges."); id. at 58 (testimony of Miles) ("In the case of MMS, we weren't able to penetrate into any systems."), and as a result did not attempt and was not able to identify whether any IITD was housed on or accessed by the systems he was testing or whether any other Interior bureaus or offices are accessible from inside the MMS network. See Tr. (Hrng, May 17, 2005, PM Sess.), at 96-97 (testimony of Miles); Tr. (Hrng., May 18, 2005, PM Sess.), at 50 (testimony of Miles).

During the course of his penetration testing of the MMS network ranges provided by the IG's office, Miles identified and performed some external penetration testing on a network that "appeared to have some data related to MMS," and that he discovered was actually owned by a non-governmental entity rather than MMS. See Tr. (Hrng., May 17, 2005, AM Sess.), at 26-27 (testimony of Miles). Miles explained that once he had "gain[ed] some information about the [third-party] system,... we posed the question" to the IG's office "that, if they did want us to continue, that they would have to get authorization" from the non-governmental entity. See id. at 28 (testimony of Miles). Miles needed such authorization because "if we're testing systems that we don't have authorization to test, then we're potentially breaking the law." Id. at 27 (testimony of Miles). The IG's office did not obtain the required authorization, and Miles thus discontinued testing of the non-governmental entity's systems. Id. at 29 (testimony of Miles). Before the testing was halted, however, Miles had already gained enough information about the third party system to determine both that it housed some sort of MMS data and that "[t]here were some vulnerabilities" in the Internet facing parts of the system. See id. at 28.

One of the MMS systems housed on this non-governmental entity's systems is the Minerals Revenue Management Support System ("MRMSS") major application. MRMSS "is comprised of several different sub-systems," including the MRM Financial System ("MFS"), the Data Warehouse ("DW"), and the Royalty In Kind ("RIK") Program system. See Pls.' Ex. 58 (extract from the "DOI Asset Valuation Guide" entitled "DOI System Inventory Form" for MRMSS) ("MRMSS SIF"), at bp. CA02_000268. MFS "accounts for all Federal and Indian minerals rents, royalties, bonuses and their distribution/disbursement to the Treasury, States ..., and Indians." Id. The DW "provides a repository of historical financial and production information used by internal users, BLM and other agencies as well as State and Tribal entities." Id. The RIK system contains a variety of software programs designed to implement "the generation, collection, distribution, and verification of revenue[,]" id. at bp. CA02_000269, incident to the process by which MMS "takes ownership of the commodity at the facility measuring point nearest the point of production and then sells the product on the open market" to generate revenue to satisfy royalty disbursement obligations. See id. at CA02_000268. In short, MRMSS is comprised of sub-systems that house and/or access IITD on a regular basis. The DOI system inventory form also shows that MFS, DW, and RIK are physically located at facilities owned by the non-governmental entity, operating on networks owned and operated by the non-governmental entity, and protected by security controls and monitoring implemented by the non-governmental entity. See id. at bp. CA02_000270.

A private contractor prepared a Residual Risk Report ("RRR") documenting the results of an ST & E of MRMSS dated April 18, 2005. See generally Pls. Ex. 57 (document entitled "Residual Risk Report for the U.S. Department of the Interior, Minerals Management Service: Minerals Revenue Management Support System (MRMSS) (Major Application)" (Apr. 18, 2005)) (MRMSS RRR). As Miles confirmed, the date of the report indicates that the contractor was conducting this risk assessment of MRMSS at the same time that Miles was performing his external penetration testing of MMS systems. See Tr. (Hrng., May 18, 2005, AM Sess.) at 43 (testimony of Miles). The MRMSS RRR identifies a number of high-risk vulnerabilities in MFS, the DW, and the RIK system. See Pls.' Ex. 57 (MRMSS RRR), at bp. DOI_IT_E0013078-DOI_IT_E0013081 (listing high risk vulnerabilities identified in the "servers supporting the MFS application"); id. at bp. DOI_IT_E0013091-DOI_IT_E0013097, DOI_IT_ E0013109-DOI_IT_E0013111 (listing and describing high-risk vulnerabilities identified in different kinds of "servers supporting the DW application"); id. at bp. DOI_IT_E0013115-DOI_IT_E0013121, DOI_IT_E0013127-DOI_IT_ E0013130, DOI_IT_E0013134-DOI_IT_E0013135 (listing and describing numerous high-risk vulnerabilities identified in different types of servers supporting the RIK applications).

As Miles was prevented from testing the MMS systems housed on the non-governmental entity's networks, he necessarily did not identify the vulnerabilities in the MRMSS systems described in the MRMSS RRR. Because MRMSS houses/accesses IITD, Miles's penetration test of MMS and his conclusion that MMS systems are at a low risk of unauthorized access from the Internet have little bearing on the current state of security for IITD on MMS systems. Miles testified that he did not encounter any systems similarly hosted on the networks of non-governmental entities during his penetration testing of BLM or BOR, but also that he was not specifically instructed to search for such systems. See Tr. (Hrng., May 18, 2005, AM Sess.), at 19-20 (testimony of Miles). Miles was not specifically instructed to attempt to identify any MMS systems hosted by third-party networks, either — he testified that he located the third-party hosted MMS systems by chance. See id. at 20 (testimony of Miles).

National Business Center — External penetration testing of the National Business Center was conducted by ISS senior security consultant Philip Brass between March 7, 2005 and April 15, 2005. See Pls.' Ex. 16 (Memorandum from Earl Devaney, Inspector General of the Department of the Interior, to P. Lynn Scarlett, Assistant Secretary of the Interior for Policy, Management and Budget; Subject: IT Security Penetration Testing — Notice of Potential Finding and Recommendation (Apr. 19, 2005)) ("IG NBC NPFR Memo"), at bp. OIG WDC 0004 000004 (attachment entitled: "United States Department of the Interior, Office of the Inspector General: Notice of Potential Finding and Recommendations" ("NBC NPFR")); Tr. (Hrng., May 6, 2005, AM Sess.), at 13, 17-18 (testimony of Brass). As with Miles, Brass was not given any information about IITD or whether NBC systems housed or accessed IITD, and he was not directed to attempt to access IITD during his testing of NBC systems. See Tr. (Hrng., May 6, 2005, AM Sess.), at 30-35 (testimony of Brass). Brass was asked to test the connectivity between NBC networks and the so-called "offline bureaus," see Tr. (Hrng., May 6, 2005), at 31 (testimony of Brass), and he found that he could not access those bureaus during his penetration testing of NBC. See id. at 128 (testimony of Brass) (explaining that he was instructed to test for access through a set of IP addresses for what the IG's office called the "offline bureaus," but that "I wasn't able to talk to any of them"). Brass was not specifically instructed to evaluate whether he could leverage his access to NBC systems to access the networks of other Interior bureaus and offices that are not disconnected from the Internet but whose systems might house or access Indian Trust data. See id. at 31.

The IG's office summarized the results of ISS's testing of NBC as follows:

[W]e were able to obtain unauthorized access to networks, applications and electronic records for the National Business Center ... includ[ing] access to records for the Department [of Interior] and other federal customers using NBC's services. We used this access to move about freely within some of NBC's most sensitive networks and applications containing financial and Privacy Act data .... Our work did not add, delete, or modify any NBC data and found in Indian Trust Data.

Pls.' Ex. 16, at bp. OIG WDC 0004 000001 (IG's NBC NPFR Memo). The IG's conclusion that no IITD was found during the testing is questionable, however, as Brass testified that because of the limited information he was provided prior to testing, he likely would not have known whether or not some system he accessed contained IITD or was a Trust system. See Tr. (Hrng., May 6, 2005), at 31, 126-27 (testimony of Brass). For the penetration testing of NBC, Brass opted not to employ automated scanning tools to attempt to identify network vulnerabilities from the Internet. See Tr. (Hrng., May 9, 2005, AM Sess.), at 38 (testimony of Brass). In an earlier draft of the NPFR that Brass prepared for the IG's office, he explained that "[b]y limiting the use of easily-detected automated tools, and focusing on already-identified high-risk vulnerabilities, ISS proposed that significant ingress could be achieved, without alerting NBC network security operations." Pls.' Ex. 26 (document entitled "Notice of Findings, NBC Penetration Test") ("Pls.' Ex. 26"), at p. 2 (no actual page numbers on document); see also Tr. (Hrng., May 9, 2005, AM Sess.), at 31 (testimony of Brass) (identifying Pls.' Ex. 26 as "my draft of the Notice of Findings that I most recently provided to the Inspector General's Office"). Indeed, Brass noted that NBC had successfully detected his initial "automated porch scans," which is "a very simple way of ... knocking on doors and seeing if anything answers. And what I found was that within a very short period of time, this was detected and I was blocked from access." Tr. (Hrng., May 6, 2005, AM Sess.), at 59 (testimony of Brass).

Brass acquired information about the nature of at least one of NBC's web applications from open sources rather than scanning. See Pls.' Ex. 16, at bp. OIG WDC 0004 000008; Pls.' Ex. 26, at p. 2 (indicating that relevant information was obtained from publicly available web sites). Brass explained that this information allowed him to identify a vulnerability that might allow penetration into NBC's systems from the Internet and to exploit that vulnerability without being detected by NBC's security monitoring programs. See Tr. (Hrng., May 9, 2005, AM Sess.), at 38-43 (testimony of Brass). Brass described this style of penetration testing as "manual," or the "slow and low" approach. See id. at 40, 45 (testimony of Brass). Brass observed that "manual" style penetration testing "has its ... pros and cons. It's not nearly as comprehensive [as automated scanning], but ... you're much sneakier, must less liable to be detected." Id. at 40 (testimony of Brass). This "slow and low" penetration method allowed Brass to remain undetected and to move freely around the NBC networks for approximately seven weeks. See id. at 38-39 (testimony of Brass); see also id. at 105 (testimony of Brass) (explaining that his conversations with Interior officials confirmed that he had not been detected, and that any detection should have resulted in the generation of incident reports; to his knowledge no such reports were generated).

The vulnerability that Brass exploited to initially penetrate into NBC systems from the Internet is very similar to the web-application related vulnerabilities that Miles exploited during his testing of BLM and BOR. See Pls.' Ex. 16, at bp. OIG WDC 0004 000005, 000008-000009 (NBC NPFR) (describing this vulnerability in detail). Once inside NBC's internal network, Brass identified additional vulnerabilities related to the implementation of applications residing on and the architecture of NBC's networks that allowed him to penetrate a variety of sensitive systems and elevate his access to the highest possible level of privilege. See Pls.' Ex. 16, at bp. OIG WDC 0004 000011 (NBC NPFR). "The end result was a successful exploit that granted nearly full control of the ... server to us." Id. (NBC NPFR). The NBC web application and database server to which unauthorized access was initially gained, Brass testified, was "a meeting place for different parts of many government agencies that do the same kind of service work that NBC does ... [where] they all ... get together and share information .... There's also a functionality on this web application that allows users to log on ...." Tr. (Hrng., May 6, 2005, AM Sess.), at 69 (testimony of Brass).

The National Security Agency, the Department of Justice, the Nuclear Regulatory Commission, the Department of State, the Centers for Disease Control, the Bureau of Public Debt, the United States Army, and other non-Interior governmental agencies, as well as Interior's MMS, BLM, and access and use this particular NBC service system. See Tr. (Hrng., May 6, 2005, AM Sess.), at 68-69 (testimony of Brass); Pls.' Ex. 20 (document entitled "Appendix A: [System] Users"), passim. (indicating users of this NBC service also include the Federal Trade Commission; the General Services Administration; the Securities and Exchange Commission; the U.S. Census Bureau; the Departments of Veterans Affairs, Treasury, Transportation, Labor, Agriculture, and Homeland Security; the U.S. Navy; the Office of Personnel Management; the Internal Revenue Service; the National Institute of Standards and Technology; the Office of Management and Budget; the Social Security Administration; the Environmental Protection Agency; the Federal Deposit Insurance Corporation; and the Bureau of Alcohol, Tobacco, and Firearms). Brass accessed the database connected to the web application and obtained user log-in information for the web application, but found that none of that information allowed him to access the application as a registered user. See id. at 70; Pls.' Ex. 16, at bp. OIG WDC 0004 000010 (NBC NPFR). Thus, he was unable to determine exactly what kind of data was accessible through the web application. See Tr. (Hrng., May 6, 2005, AM Sess.) at 70-71 (testimony of Brass).

This initial NBC system, Brass discovered, was linked to another database server in a manner that created a vulnerability that allowed him to retrieve information from the "remote" database. See id. at bp. OIG WDC 0004 000010 (NBC NPFR). Brass developed a method of elevating his user privileges on the remote to the highest level and essentially control the remote database server entirely. See id., at bp. OIG WDC 0004 000011 (NBC NPFR). This control allowed Brass to access a number of different web applications and database servers which, in turn, appeared to access numerous other systems. See Tr. (Hrng., May 6, 2005, AM Sess.), at 92-96 (testimony of Brass) (describing this process in detail); Pls.' Ex. 16, at bp. OIG WDC 0004 000010-000016 (NBC NPFR) (detailing the methods of exploitation and the nature of the systems accessed); Pls.' Ex. 18, at p. 1 (document entitled "Status Update" bearing no internal or Bates page numbers) (explaining, during the course of penetration, how and to what additional access had been gained); see also Tr (Hrng., May 6, 2005 AM Sess.), at 39-40 (testimony of Brass) (identifying Pls.' Ex. 18 as one of Brass's status reports transmitted to the IG's office during the course of Brass's penetration testing of NBC).

Contrary to the IG's conclusion, one system that Brass obtained the ability to access through his penetration of NBC's network, which the Court will, for security purposes, refer to as "NBC System A," may house or access Individual Indian Trust data. See Tr. (Hrng., May 9, 2005, PM Sess.), at 50-57 (testimony of Brass); Pls.' Ex. 27 (document entitled "NBC Project Plan," comprised of Brass's notes taken during communications with IG's office on Mar. 23, 2005) (identifying NBC System A as having been accessed, listing as an objective of further testing "if possible ... [r]etrieve maximum data from servers" listed below, including NBC System A); see also Tr. (Hrng., May 9, 2005, PM Sess.), at 22-23 (testimony of Brass) (identifying and authenticating Pls.' Ex. 27 as Brass's personal notes). The nature and extent of Brass's access to this system was disputed by NBC officials, as was the question whether NBC System A is an Indian Trust system. The facts surrounding this matter will be taken up again later in this opinion.

Brass's penetration of NBC's systems allowed him to access a number of sensitive databases. See Tr. (Hrng., May 6, 2005, AM Sess.), at 93 (testimony of Brass); Pls.' Ex. 16, at bp. OIG WDC 0004 000013-000014 (NBC NPFR) (giving detailed descriptions and listing systems accessed); Pls' Ex. 18, at p. 1 ("Status Update") (listing systems by name). For example, Brass was able to assemble dossiers containing private, personal information — including home addresses, social security numbers, financial information, and in one case a list of recent bank card charges — about several high-ranking Interior officials for the IG's office to use in presenting ISS's findings to the department and to NBC. See Tr. (Hrng., May 6, 2005, AM Sess.), at 41-43 (testimony of Brass) (explaining that these dossiers were assembled for "effect," to get NBC's attention by showing "the kind of data this guy is getting already"); Pls.' Ex. 18, at pp. 3-7 ("Status Update") (displaying the dossiers); see also Tr. (Hrng., May 9, 2005, AM Sess.), at 49-50 (testimony of Brass) (detailing the way in which financial and bank card information was obtained); Pls.' Ex. 16, at bp. OIG WDC 0004 000011 (NBC NPFR) (same). Brass verified with Interior employees that he was collecting actual, rather than "dummy," bank card numbers, see Tr. (Hrng., May 9, 2005, AM Sess.), at 49-50 (testimony of Brass); Pls.' Ex. 16, at bp. OIG WDC 0004 000011 (NBC NPFR), and explained that he had, in fact, gained access to similar information for over 72,000 Interior employees as well as an unknown (but large) number of employees of other government agencies that use NBC's services. See Tr. (Hrng., May 6, 2005, AM Sess.), at 61; Tr (Hrng., May 9, 2005, AM Sess.), at 62 (testimony of Brass).

Late in the testing period, Brass discovered a way to move from the NBC network into the network of a government agency that uses NBC's services. See Tr. (Hrng., May 9, 2005, AM Sess.), at 68-70 (testimony of Brass); Pls' Ex. 16, at bp. OIG WDC 0004 000014-000016 (NBC NPFR) (describing the mechanism of traversal into the non-Interior network). Brass was able to use the access he gained to the other agency's network to view databases that may contain sensitive data. See Tr. (Hrng., May 9, 2005, AM Sess.), at 69 (testimony of Brass) ("Furthermore, that [other agency's] database was linked to several other databases that ... were probably ... part of the same [agency's] facility. So we had the ability... to extend our reach into [the other agency's] web of database links which is possibly ... a significantly large set of linked databases."); Pls.' Ex. 16, at bp. OIG WDC 0004 000015 (NBC NPFR) (listing likely accessible databases in other agency).

Overall, Brass concluded that NBC's network was at "pretty high-risk posture" for unauthorized access from the Internet. See Tr. (Hrng., May 9, 2005, PM Sess.), at 86 (testimony of Brass). Though Brass's particular "slow and low" strategy for initially penetrating NBC's network from the Internet did not give him sufficient information to make an overall assessment of the perimeter security of NBC's Internet-facing systems, see Tr (Hrng., May 9, 2005, AM Sess.), at 40 (testimony of Brass) (describing manual penetration as "not nearly as comprehensive" as automated scanning tools for assessing perimeter security); id. at 72 (testimony of Brass) ("Q: ... [Y]ou have a narrow but deep penetration that does not allow you to make any judgment about the security of anything else other than what you penetrated? A: Yes."), after penetration he discovered that NBC "had no [web] application level protections in place." Id. at 41 (testimony of Brass); see also id. at 42 (testimony of Brass) (qualifying his statement to apply to "web application" level protections as opposed to "database application protections and things like that," about whose security he did not make an overall assessment). Brass defined web-application level protections as:

protections that have been tuned to the available applications, are cognizant of the structure of the applications, protections that are tuned to the particular parameters that should be sent to an application, and that will react to parameters that are outside of certain specifications ....

Id. at 41. It was web-application level protections rather than network perimeter controls or other protections for other kinds of internal, non Internet facing applications, Brass explained, that were the principal "area of assessment" for his penetration testing of NBC. Id. Thus, the vulnerabilities identified in NBC networks, like those at BLM and BOR, have to do with the implementation of web-applications, the architecture of the networks, and the expertise of Interior's IT personnel.

Brass also testified, however, that a number of the kinds of security controls he encountered while inside the NBC network were consistent with "a very fundamental computer security... principle ... called defense-in-depth," which advises that security controls be active at each "layer" of an IT system, including at the perimeter of the network, the web-application level, the internal application/database level, and around links between databases or systems both within a single network and between different networks. See Tr. (Hrng., May 9, 2005, PM Sess.), at 78-79. Furthermore, Brass agreed, the most severe vulnerabilities that contributed to the ease and scope of his unauthorized access could be effectively mitigated by eliminating a few technical flaws in NBC's web application implementation and network architecture. See id. at 81-84.

Aside from technical problems, Brass more principally attributed NBC's overall lack of web-application security controls to "a lack of education among ... the people who develop web applications." See Tr. (Hrng., May 9, 2005, AM Sess.), at 73 (testimony of Brass); see also Tr (Hrng., May 9, 2005, PM Sess.), at 6 (characterizing increased "education on the web application side" as "crucial" to NBC's IT security going forward). This kind of systemic problem with the education of NBC IT personnel and the comprehensiveness of NBC's own IT security review processes, Brass observed, means that "[i]t's very likely that the rest of NBC has problems." See Tr. (Hrng., May 9, 2005, AM Sess.), at 72-73 (testimony of Brass). Where systemic problems in an organization's IT security policy can be identified as the root cause of vulnerabilities, Brass continued, those vulnerabilities are "generally repeated throughout the enterprise ... [i]n my experience." Id. at 73 (testimony of Brass). Brass elaborated:

[T]hese kinds of vulnerabilities are at an intermediate level; they are behavioral based. A person writes a program the same way every time, they haven't been taught how to do it securely and, therefore, a lot of different applications may be vulnerable.... A person configures a database link over and over on many different servers, and because they practice the same behavior, the vulnerability is likely to be more widely distributed than just the narrow ... focus that this penetration test took.

Tr. (Hrng., May 9, 2005, PM Sess.), at 94-95 (testimony of Brass).

For this reason, the first recommendation in the NBC NPFR includes the suggestion that NBC implement "ongoing programs for developer education in web application security." Pls.' Ex. 16, at bp. OIG WDC 0004 000017 (NBC NPFR). In its response to the IG's NBC NPFR, NBC concurred with this recommendation, and indicated that it would take the following steps in response:

[1.] A Web Application Security Bulletin has been developed to provide guidance to web developers regarding best practices to protect applications from [certain kinds of] attacks. NBC's CIO will issue this bulletin by May 6, 2005. This bulletin provides URLs for various papers and web sites dedicated to web application security. This is the first of periodic bulletins that will be issued to increase awareness of web application vulnerabilities and mitigation techniques. The initial bulletin provides guidance to NBC web application developers to review their code and implement appropriate application development best practices.

. . . . .

[2.] A security training plan will be developed that is based on job roles. This training plan will include enhancement of NBC's annual security training, formal classroom based training, on-line training, and attendance at conferences that include security components. Developers are being encouraged to use language and technology specific publications such as books and journals as a means to learn about security vulnerabilities and best practices for mitigating or removing them....

[3.] "In-service" training sessions will be scheduled periodically to increase awareness and information sharing.

Pls.' Ex. 33 (Memorandum from P. Lynn Scarlett to Earl Devaney; Subject: "Notification of Potential Finding and Recommendation: Confidentiality, Integrity, and Availability of Sensitive Financial and Privacy Data Managed by the National Business Center is at Risk" (May 5, 2005)) ("NBC NPFR Memo."), Attachment A (document entitled "NBC Response to Draft NPFR Recommendations") ("NBC NPFR Response"), at bp. DOI_NBC_0000004. The schedule of tasks attached to the NBC NPFR Response shows that NBC began developing these additional training programs on May 4, 2005. See Pls' Ex. 33 (NBC NPFR Memo.), Attachment 2 (document entitled "NBC Remediation Tasks and Schedule in Response to the OIG's DRAFT NPFR") ("NBC Remed. Sched."), at bp. DOI_NBC_ 0000014.

In addition to inadequate training of NBC's web application development staff, Brass also noted that the typical automated scanning tools that NBC uses to evaluate the state of network perimeter security are inadequate to detect more sophisticated vulnerabilities like the ones he exploited. See Tr. (Hrng., May 6, 2005, AM Sess.), at 57-58; Tr. (Hrng., May 9, 2005, PM Sess., at 108-09 (testimony of Brass)) (noting that NBC's automated scanning tools were likely not configured to detect the particular kind of vulnerability that he exploited). Further, Brass attributed the ease with which he moved from one system to another inside the NBC network to "a lack of in-depth database auditing that would have revealed that some of these databases that were linked together ... were in violation of acceptable security policies. They weren't looked at ...." Tr. (Hrng., May 9, 2005 PM Sess.), at 6 (testimony of Brass). These observations resulted in the IG's recommendation that NBC perform a "network assessment and full penetration test, including web assessments of all publicly available NBC web applications ...." Pls.' Ex. 16, at bp. OIG WDC 0004 000017 (NBC NPFR); see also Tr. (Hrng., May 9, 2005, PM Sess.), at 110-12 (testimony of Brass) (noting the need for both penetration testing and a general IT security assessment in order to get a "full comprehensive" picture of NBC's IT security posture). Simply removing the vulnerabilities that allowed for this particular instance of penetration, Brass insisted, would not be sufficient to ensure the future security of NBC's networks in light of the systemic problems with the overall implementation of NBC's IT systems that were identified by Brass and the IG's office. See Tr. (Hrng., May 9, 2005, PM Sess.), at 95 (testimony of Brass).

NBC concurred with this recommendation, and responded that "NBC is preparing a Statement of Work to contract with an external entity to perform a variety of penetration tests to independently verify the security of NBC systems and applications." Pls.' Ex. 33 (NBC NPFR Response), Attch. A (NBC NPFR Response), at bp. DOI_NBC_0000006. NBC's remediation task schedule includes an estimated completion date of June 3, 2005 for preparation of this Statement of Work ("SOW"), but does not include an entry or an estimated completion date for the actual independent security assessment. See Pls.'s Ex. 33 (NBC NPFR Memo.), Attch. C (NBC Remed. Sched.), at bp. DOI_NBC_0000013; id., passim.; see also id. at bp. DOI_NBC_0000015 (specifying as an individual remediation task "[n]otify the OIG when penetration testing and full network assessment will be carried out"). The IG also recommended that NBC "reevaluate relevant Certification & Accreditation decisions made for this portion of their network and systems in light of these new findings." Pls.' Ex. 16, at bp. OIG WDC 0004 000006 (NBC NPFR). NBC concurred, and represented in response that the process of reevaluating the relevant C & A decisions began May 23, 2005, with a completion date yet to be determined. See Pls.' Ex. 33 (NBC NPFR Memo.), Attch. C (NBC Remed. Sched.), at bp. DOI_NBC_0000015.

NBC quibbled with the IG's general conclusion that ISS had accessed "sensitive private networks" at NBC, see Pls.' Ex. 16, at bp. OIG WDC 0004 00005 (NBC NPFR), and insisted that "[u]pon review of the actual access `footprint,' we have determined that the OIG was able to gain access to data residing in the databases located within NBC's internal systems." Pls.' Ex. 33 (NBC NPFR Memo.), at bp. DOI_NBC_0000002. Brass disagreed with NBC's response, explaining that he "believe[s] that whoever wrote it might not have been informed about the full extent of my access" to the sensitive application. Tr. (Hrng., May 6, 2005), at 118 (testimony of Brass). He continued, "I had access to the networks that were visible from the [compromised] servers. If those are the sensitive private networks of NBC, which I believe they probably were, then I had access to NBC's sensitive private networks." Id. at 118-19 (testimony of Brass).

Indeed, the only area of the IG's NPFR with which NBC took serious issue was the stated conclusion that Brass obtained access to one specific sensitive application that sits on an NBC network. See Pls.' Ex. 16, at bp. OIG WDC 0004 000001, 000004 (NBC NPFR) (asserting that unauthorized access to the sensitive application was obtained during the penetration testing); Pls.' Ex. 33 (NBC NPFR Memo.), at bp. DOI_NBC_0000001 (asserting that "[i]t is critical to clarify the statement that OIG obtained access to" the sensitive application; arguing that Brass had actually accessed not the application itself but "data that may have originated" in the application but that was housed in a separated database and is used "solely for reporting purposes and not for ... data processing"); see also id. at bp. DOI_NBC_0000002 (asking the IG to clarify the statement of impact based on NBC's assertion that Brass accessed reporting data only). Brass admitted that NBC's argument in this regard "is probably strictly speaking true," but explained that because he "basically owned" the reporting data for the sensitive application, he exercised sufficient control over the data in the system to conclude that it "was not a safe system." See Tr. (Hrng., May 6, 2005), at 120-21 (testimony of Brass). Brass noted that NBC's response likely did not take into consideration Brass's degree of control over the data in asking the IG to modify its findings to reflect a less-severe problem. See id. at 121 (testimony of Brass). Brass admitted, however, that certainty about his methods and degree of access was necessary for NBC's personnel to successfully mitigate whatever vulnerabilities exist in the sensitive application. See Tr. (Hrng., May 9, 2005, PM Sess.), at 80.

General Findings — The foregoing detailed account of the external penetration testing undertaken by Interior's Inspector General as a part of the IG's FY 2005 FISMA evaluation illustrates not only the complexity of Interior's interconnected web of IT networks and systems, but also several general characteristics of Interior's current IT security posture. While the ISS consultants were careful to note that external penetration testing is necessarily narrow in scope, and that as a result it is difficult to make general statements about the overall security of IT systems on the basis of penetration testing results, and while any individual vulnerabilities identified and exploited during the penetration testing are likely to be quickly mitigated by the bureaus, at least three general conclusions are indicated for the Interior overall. First, from the similar nature of the vulnerabilities identified during the testing of BLM, BOR, MMS, and NBC, it is apparent that Interior's IT personnel in general lack sufficient training or skill in the secure implementation of web applications. To be sure, the federal government in general is becoming increasingly dependent on the Internet as the most efficient means of providing services to its numerous clients, but it appears that Interior's policies and planning have lagged behind the expansion of the department's Internet presence.

Second, similarities in vulnerabilities identified after initial penetration was achieved indicate insufficient focus on securing Interior's networks inside their perimeters. Notably, external penetration testing is essentially intended to evaluate network perimeter security, or security against unauthorized access from the Internet in general. However, as both Miles and Brass demonstrated, once an external attacker penetrates into a network from the Internet, he or she more or less resembles a network user. While the access is unauthorized at this point, it is access to the network nonetheless, and any additional penetration that occurs simulates both the threat posed by an external attacker who manages to gain some level of system-user access and the threat posed by an authorized system user who may, intentionally or unintentionally, leverage his or her existing access on the network in a manner that compromises security. Of course, external penetration testing is not a comprehensive means of identifying external and internal threats to network security — the threats that are simulated are targeted by the tester and the vulnerabilities identified are limited to those that the tester locates along his chosen path of penetration.

iii. Other IT Security Evaluations by the IG's Office

Apart from the overarching FISMA-mandated review of Interior's IT security, the IG's office conducted detailed evaluations of two discreet IT-related subjects. First, spanning the end of FY 2004 and early FY 2005, Sandy's Denver-based NISO (which was responsible for the IG's FISMA evaluations before the transition to Mahach's NSM group in Washington) conducted a detailed review of Interior's implementation of wireless networking technologies. In FY 2005, that same group conducted a detailed review of Interior's POA & M program. Both reviews were managed, principally, by Diann Sandy.

Wireless Technology Evaluation — Sandy's NISO team conducted its evaluation of Interior's management of wireless IT networking technologies between October 2003 and April 2004. See Defs.' Ex. 2 (document entitled "U.S. Department of the Interior, Office of Inspector General, Evaluation Report: Department of the Interior's Use of Wireless Technologies, Report No. A-IN-MOA-0004-2004" (Dec. 6, 2004)) ("NISO Wireless Rep."), at 2; Tr. (Hrng., June 6, 2005, AM Sess.), at 72 (testimony of Sandy) (confirming NISO's role in the evaluation and the time frame). "Primarily for this report," Sandy explained, "we were taking about the 802.11 wireless network," which is technology "you see advertised in any office supply company today[,]" and gives users "the ability to have your laptop in one location and then wirelessly connect to a router to connect [to] the Internet, or other networks, or whatever it's connected to." Tr. (Hrng., June 6, 2005, AM Sess.), at 68-69 (testimony of Sandy). This specific type of wireless technology had been in use at Interior "at least four years before [NISO] began our study." See id. at 72 (testimony of Sandy).

NISO's final wireless evaluation report provides a summary of the benefits and risks of deploying wireless networking technologies in an organization like Interior:

While wireless networks and associated wireless communication technology hold great promise for efficiency, ease of use, mobility, and cost-effectiveness, they also introduce increased risks to the confidentiality, integrity, and availability [of] the Department of the Interior's (DOI) information resources. Sensitive data can now reside on wireless devices, such as cellular telephones, [Personal Digital Assistants ("PDA")], and laptops. Left unsecured, wireless networks and devices are an open door to one of our most valuable assets — information. This information, because of the way it travels, can be easily intercepted, allowing misuse of information and/or unauthorized access to DOI's wired networks. Furthermore, due to the complexity and lack of fully understanding the risks of wireless networks, organizations may administer their wireless networks poorly. They may fail to use security boundary devices, such as firewalls, to segregate wireless and wired networks, or fail to implement security features, such as encryption, within the wireless equipment to safeguard data that is transmitted wirelessly.... DOI has installed numerous WLANs that interconnect to DOI's traditional wired networks. Therefore, this potentially increases the risk to data that may be secured and controlled on the wired networks.

Defs.' Ex. 2 (NISO Wireless Rep.), at 2. Sandy elaborated on the ways in which wireless network capability can provide a "back door" into wired networks, explaining that with "wired network[s], you .. know where your boundaries are," as well as "those legitimate, agreed-upon interconnection activities that you have" with other organizations. Tr. (Hrng., June 6, 2005, PM Sess.), at 39 (testimony of Sandy). But "[i]n the wireless world," she continued, "your perimeter is expanded even further, but you may not know that somebody is attached to your network because you can literally install a wireless LAN and connect it to the wired network. And unless everyone is watching every little node that's connecting in, they might not even know that a wireless device is there." Id. at 39-40 (testimony of Sandy). This is even more problematic, according to Sandy, because wireless access to wired networks often bypasses security controls that operate on the wired network, and because in Interior's case, "we were showing very minimal configuration ... from the wireless access point to the wired network ... we were finding [that] there was nothing there." Id. at 51 (testimony of Sandy).

Before evaluating the security of Interior's wireless networking technology, NISO requested that Interior's CIO and all bureau and office heads provide copies of "policies and procedures related to wireless networking and wireless communication devices[,]" a description of the "[t]opology of wireless network and access points identifying all firewalls between the wired and wireless networks[;]" inventories of "wireless and handheld devices (including Palm, Bluetooth, and BlackBerry or similar devices)[;]" the name of each IT security "contact at each wireless location[;]" copies of all "[r]isk assessments relating to wireless communications and wireless communication devices[;]" and lists of all "security and encryption software used to protect the wireless network and communication devices." Pls.' Ex. 238 (memorandum from Diann Sandy to Chief Information Officer, Department of the Interior, and Heads of Bureaus and Offices, Subject: "Evaluation of Department of the Interior Wireless Networking and Wireless Communication Devices (Assignment No. A-IN-MOA-0004-2004)" (Oct. 8, 2003)), at bp. OIGIT_0014719; see Tr. (Hrng., June 6, 2005, PM Sess.), at 24 (testimony of Sandy). Sandy explained that the response to this request was slim — she received very few policies and procedures, some topology descriptions but very little information about firewalls because, for the most part, Interior did not have any on its wireless networks at that time, some inventories from some of the bureaus, one or perhaps two wireless-related risk assessments, both from BOR, of which one listed the date of Sandy's request as the date of creation, and only very limited lists of active security and encryption software in use for wireless networks because, at that time, there practically was none. See Tr. (Hrng., June 6, 2005, PM Sess.), at 24-26 (testimony of Sandy). A number of bureaus provided NISO with no information related to their wireless capabilities. See id. at 31 (testimony of Sandy). When asked whether she was surprised that Interior had "virtually no policies and procedures related to wireless[,]" Sandy responded: "Honestly, no." See id. at 26.

NISO was concerned to test the accuracy of the wireless network and device inventories that some bureaus had submitted in response to Sandy's request, see Tr. (Hrng., June 6, 2005, PM Sess.), at 28 (testimony of Sandy), so conducted a program of "what is called war driving." Id. (testimony of Sandy). Sandy's team physically drove to "106 sites within Department of Interior that included Denver; Boise, Idaho; Sacramento, California, including San Francisco, ... Golden Gate for National Park Service; ... [the] Washington, D.C. area; and up and down the eastern seaboard here a little bit, up to Baltimore and ... down to Laurel to identify what ... devices we had." Id. at 28-29; see Defs.' Ex. 2 (NISO Wireless Rep.), at 2 (listing also Minneapolis and St. Paul, MN; noting that "[a]ll DOI major organizations," including BLM, BOR, BIA, NBC, NPS, MMS, OSM, FWS, and USGS, "were included in the evaluation"). To detect signals emitted by wireless networking devices, NISO used "a Yellow Jacket, and then we also use[d] the Kensington, a little $20 device that has red, green, [and] yellow to let you know if you're getting close to an 802.11 device or not." Id. at 31.

Through this process of war driving, Sandy's team identified "at least 700 wireless local area networks (WLAN) and wireless devices such as wireless-enabled laptops and wireless-adapted cards." Pls.' Ex. 239 (document entitled "Conclusion related to DOI's inventory of Wireless devices"), at bp. OIGDS_0000001; Pls.' Ex. 48 (email from Michael Wood, DOI OIG, to Valerie Banner, DOI OIG, Subject: "Wireless Report" (Sept. 22, 2004)), Attachment (document entitled "U.S. Department of the Interior, Office of Inspector General, Evaluation Report: Department of the Interior's Use of Wireless Technologies") ("NISO Draft Wireless Rep."), at bp. DOI_OIG_ IT0000082;^[21]see also Tr. (Hrng., June 6, 2005, PM Sess.), at 40-41 (testimony of Sandy) (authenticating Pls.' Ex. 48 as a draft of the final wireless report); id., at 32-33 (testimony of Sandy) (authenticating Pls.' Ex. 239; affirming as correct the findings reported in Pls.' Ex. 239, noting that the 700 number is a combination of both WLANs and individual wireless-enabled devices that NISO identified). This finding was startling in light of the wireless device inventories NISO received from the bureaus, as "MMS, BOR, FWS, and NPS did not provide ... inventories of wireless-enabled laptops, and BOR, MMS, and NPS did not provide ... inventories of wireless adapter cards." Pls.' Ex. 239, at bp. OIGDS_0000001; see also id., at bp. OIGDS_0000002 (presenting a table of inventories submitted to NISO by the bureaus and offices, divided by device-type; noting "NI" (no inventory) from several bureaus in several categories). Additionally, NISO found "additional wireless network access points that were not reported ... on the original inventory." Id., at bp. OIGDS_0000001.

Sandy testified that NISO found wireless networking devices in use at a number of Interior's bureaus and offices during the evaluation:

I believe we found [N]PS had some capability because of the new laptops they had received. [US]GS had it installed and were actively using it. BOR also had some. BLM had some. Fish and Wildlife. MMS and Indian Affairs, there was wireless capability within their environment, more not because of what ... devices... their own employees had, but what contractors were able to bring into the facilities, and they had wireless enabled. Their laptops were enabled to accept 802.11 wireless transmission. So we also identified that that was a problem that was occurring, especially at MMS and Indian Affairs.

Tr. (Hrng., June 6, 2005, AM Sess.), at 73 (testimony of Sandy). She clarified that the wireless devices identified as operating within the BIA and MMS environments were attached to the laptops of contractors rather than to any of Interior's equipment, and she could not determine whether those contractors' devices enabled wireless access to Interior systems. See Tr. (Hrng., June 6, 2005, PM Sess.), at 29 (testimony of Sandy). But Sandy did underscore the risk involved in allowing contractors to use wireless-enabled laptops that "could be potentially connecting to DOI networks" or might "contain DOI data" that could be transferred wirelessly. See id. at 48 (testimony of Sandy).

Sandy also reiterated the conclusion reflected in NISO's workpapers — that Interior's inventory of wireless network connection points and wireless-enabled devices was incomplete at the time of the evaluation, and likely remains incomplete today. See id. at 33-34 (testimony of Sandy); see also id. at 74 (testimony of Sandy) (explaining that any current inventory Interior may have is only improved insofar as it reflects the networks and devices NISO identified during its evaluation). NISO's draft wireless report indicates that "DOI initiated an inventory of wireless network access points and related devices during our review." Defs.' Ex. 2 (NISO Wireless Rep.), at 5. But because "the inventory will not include all wireless devices ... such as wireless enabled laptops, wireless adaptor cards, wireless enabled PDAs, or BlackBerrys," which Interior decided not to require to be included, the inventory will be incomplete. See id. Without a complete wireless device inventory, "DOI simply cannot effectively manage risks to its networks [,]" id., because "[t]he devices that are not included in the inventory list still have the potential to allow access to unauthorized users to circumvent wired network security," id. at 6, and "accurate inventories are necessary to ensure that all devices can consistently be updated to reduce security vulnerabilities." Id. at 14. Indeed, "[a] complete inventory is the first requirement for adequately managing the Department's wireless network technology." Id., at 5.

Aside from the incomplete inventory, NISO found several other security-related issues related to the use of wireless network technology at Interior. To avoid disclosing potentially sensitive information, the Court presents NISO's specific findings in this regard in summary fashion only. Regarding the security of wireless networks and devices that were found to be operating at Interior, NISO observed that the range of wireless signals was not controlled, potentially allowing for those signals to be intercepted and appropriated by unauthorized users at some distance from physical Interior facilities, see Defs.' Ex. 2 (NISO Wireless Rep.), at 8-9 ("Without knowing the distance of its wireless network signals, DOI is unaware of the increased opportunity for accidental associate with overlaying wireless networks. Accidental association of wireless networks provides unauthorized users the opportunity to gain access to DOI's wireless networks and potentially its wired networks and its data."); that security controls that had been implemented on Interior's wireless networks were not adequate or consistently implemented across all Interior wireless networks, see id. at 9 (noting that "DOI should always install its wireless networks with strong security controls to (1) avoid having its wireless networks easily identified, (2) prevent unauthorized access and use of its wireless networks and information, and (3) protect the connected wired networks"); that identified wireless network security controls were usually not up to industry standards for strength, see id. at 10 (noting that "[t]he majority of DOI's wireless networks were set up with WEP [which encrypts data transmissions], ... [but] WEP is not recognized throughout the wireless industry as an adequate protection for sensitive information"); that insufficient controls were in place to protect wired networks against unauthorized access from interconnected wireless networks, see id. at 10-11; that individual mobile wireless-enabled devices were not properly configured to secure sensitive information and wireless networks from unauthorized access, see id. at 11 (noting that, for example, "wireless-enabled laptops were not always set up with personal firewalls or with sensitive files encrypted"); and that physical security was inadequate in locations with operating wireless networks. See id. at 11.

Sandy described several examples of this last problem, lack of physical security at wireless network locations.

The worst example of lack of physical control was at ... Fish & Wildlife, where the wireless access router, the point that the wireless data is now transferred to the wireless network, was out in the open. And they have a little button you can push and it sets them to default, which means there's no WEP, there's no encryption, they're reset to zero. They're broadcasting who they are, where they are, and they basically have no security on it just by pushing that button to make them reset to default.... Another [example] ... was ... [at] Bureau of Land Management, where ... that same type of device was in a telecommunications area ... [and] everyone in the IRM shop had access to ... that room.... And it was our opinion that 20 people in the Bureau of Land Management's IRM division really do not need access to a telecommunications closet. It's usually limited to those people who are really managing and wiring and dealing with the teleco[m] devices ....

Tr. (Hrng., June 6, 2005, PM Sess.), at 48-49 (testimony of Sandy). Sandy gave other examples, including an incident that occurred at a BOR location during NISO's war driving program:

We usually had a big sport `ute' or a minivan, we had our devices attached to the top of the roof, and we would go park in [Interior's] parking lot with our devices up. We would be getting out the car and walking around, and ... a lot of times, ... we were not in a government vehicle, we were in a rental car. We didn't have our [Interior] IDs on, ... and we were in the parking lot of ... CVACS and Reclamation for two hours.... Now, CVACS is a power marketing and SCADA control facility that connects to the State of California and to the Western Power Administration, and ... nobody noticed us or paid any attention to us while we were in the parking lot with the car running. And ... we were out running around with our Blackberry device.... Nobody asked us what we were doing.... In one case we went into a ... parking garage.... [T]he guard wanted to see inside of our glove compartment ... [while] right there in clear sight was the carry box ... where we had our computers and our devices.... It was probably about 36 inches long, about 18 inches high, and about 24 inches wide.... He opened the sliding door of the minivan, and the guard noted how clean the inside of our vehicle was and said hello to the guy [sitting] behind [the carry box], and never once asked what was inside that box or ... why would we bring something like that into their parking garage.

Id. at 53-54 (testimony of Sandy). NISO advised that these sorts of lapses in physical security controls at wireless network locations provide "unauthorized individuals ... the opportunity to easily compromise wireless network access points by[,]" for example, "simply pushing a button and changing access and security controls to an unsecured mode." Defs.' Ex. 2 (NISO Wireless Rep.), at 11.

These technical problems, NISO determined, were symptomatic of more basic problems at the IT security management level. For one thing, NISO noted that "wireless networks were implemented because they were perceived to be easier to install and less expensive than wired networks[,]" and, as such, "were implemented with little planning and research." Defs.' Ex. 2 (NISO Wireless Rep.), at 6. Examples of necessary pre-implementation planning that NISO was able to observe had not been done include the development of "[s]tandard data types" that are too sensitive or are otherwise inappropriate for wireless transmission; feasibility planning; and studies of wireless network signal strength and potential reach. See id. NISO also determined that "DOI has not established specialized training requirements for personnel who are responsible for planning, installing, implementing, controlling, and securing wireless technologies," and that "DOI [annual] security awareness training ... did not provide users information regarding the proper use and protection of wireless devices ...." Id. Finally, NISO reported that Interior had failed to adequately assess the risks associated with the use of wireless networking technologies prior to their implementation — which follows from the observation that Interior had no written department-level policies or procedures of any kind regarding wireless until seven months into NISO's investigation, and thus nearly four years after wireless networks and devices first began to be used at Interior. See id. at 3; Tr. (Hrng., June 6, 2005, PM Sess.), at 72-73 (testimony of Sandy). More specifically, NISO indicates that:

While DOI has no specific requirement to assess the risks of wireless technologies prior to their implementation, DOI does have general guidelines requiring that risks be determined as part of certifying and accrediting information technology (IT) systems. We found, however, that risks related to wireless technologies were not always assessed before, or even after, system implementation. Furthermore, the risk assessments that were performed did not always include risks related to wireless technologies (such as the risk of information being intercepted). For example, BOR certified and accredited one of its general support systems without considering the impact of wireless technologies that were connected to that system. It was only after our review was initiated that BOR performed a risk assessment of the implementation of wireless technology.

Defs.' Ex. 2 (NISO Wireless Rep.), at 7. NISO also noted, in reporting what were identified as "best practices" from both the wireless industry and governmental guidance, that "[b]ecause of the unique security requirements of wireless technologies, risks should be assessed continually to ensure that new threats and vulnerabilities do not degrade implemented security controls." See id. at 13-14. NISO made other recommendations for improvements in Interior's wireless networking technology security program in each of the problem areas identified. See id. at 13. In addition, Sandy explained that vulnerabilities associated with wireless technologies should be on the POA & M for the system, bureau, or office employing the wireless system; she found during NISO's investigation, however, that this was rarely if ever done. See Tr. (Hrng., June 6, 2005, PM Sess.), at 67 (testimony of Sandy).

POA & M Program Review — One of NISO's final projects before the IG's transfer of IT security authority to NSM is completed has been to conduct a review of Interior's POA & M program separate from the IG's annual FISMA review. See Tr. (Hrng., June 3, 2005, PM Sess.), at 6 (testimony of Sandy). NISO's POA & M study was begun September 15, 2004 (early in FY 2005), and the final report was not completed at the time of trial. See Pls.' Ex. 227 (document entitled "U.S. Department of the Interior, Office of Inspector General, Draft Evaluation Report: The Department of the Interior's Process to Manage Information Technology Security Weaknesses" (Apr.2005)) ("POA & M Draft Rep."), at bp. OIGDS_0000951; Tr. (Hrng., June 3, 2005, PM Sess.), at 81 (testimony of Sandy); see also id. at 80 (testimony of Sandy) (authenticating Pls.' Ex. 227).^[22] The separate POA & M review, Sandy explained, was undertaken because the IG's office "had been reporting problems with the POA & M all along, and we had not really done in-depth testing, i.e., verified that corrective actions were in fact" being taken. Id. (testimony of Sandy) She continued, noting that the IG had "reported in the GISRA and the FISMA reports that all known weaknesses were not being reported [and placed on the POA & Ms], and we determined that we needed to get a better understanding of why that was not occurring. And if in fact ... weaknesses were not being corrected, this would raise our level of concern about what's going on overall in the DOI [IT] security management program." Id. (testimony of Sandy).

The NISO team's draft report explains that:

OMB policy requires that a POA & M be prepared for each system and program where information technology (IT) weaknesses have been found. A POA & M should identify each weakness including the related corrective actions, the scheduled completion date for correcting each weakness, and the status for correcting each weakness. The Department of the Interior's ... bureaus and offices ... prepare POA & Ms for each of their systems and programs where security weaknesses have been identified. The Department, using the bureaus' data, prepares a POA & M for the Department that is submitted to OMB. In the Department's September 15, 2004 POA & M, the Department reported that it had 157 IT systems and 13 programs, that there were 2,243 IT security weaknesses, and that 883 of these weaknesses were corrected.

Pls.' Ex. 227 (Draft POA & M Rep.), at bp. OIGDS_0000951. The report also notes that the IG's office has reported deficiencies in Interior's overall POA & M process in three prior FISMA reports to OMB, and that in the FY 2004 FISMA report concluded that Interior's POA & M process was deficient because "all weaknesses were not recorded, priorities were not assigned to correct all weaknesses, and costs needed to remedy weaknesses were not always identified." Id. In general, NISO's draft report concludes that "the Department's POA & M could not be used to effectively manage the Department's IT security weakness remediation process. The POA & M was incomplete, inaccurate, and misleading." Id. at bp. OIGDS_0000953. The root cause of these POA & M deficiencies, NISO determined, is that "the Department's Office of the CIO has not provided effective leadership by establishing a process to ensure the Department's POA & M was an effective management tool." Id. at bp. OIGDS_0000948.

Sandy's team examined Interior's POA & M program as a whole, reviewing "the DOI POA & M in its entirety; in other words, the whole 16 inches[] ... the 2000 weaknesses reported [and] the 2400 corrective actions." Tr. (Hrng., June 3, 2005, PM Sess.), at 8 (testimony of Sandy). NISO "conducted interviews with the [bureau] CIOs, the BITSMs, [and] the bureau POA & M coordinators." Id. at 6 (testimony of Sandy). Sandy explained that NISO also targeted various bureau POA & Ms for closer scrutiny, focusing on determining whether "reportedly corrective actions [were] really done." Id. at 9 (testimony of Sandy); see Pls.' Ex. 227 (Draft POA & M Rep.), at bp. OIGDS_0000952 (NISO "judgmentally selected 133 weaknesses in 20 IT systems and one security program. These systems and program were owned by the Office of the Secretary, the Assistant Secretary of Indian Affairs, the Bureau of Land Management, the Bureau of Reclamation, the [United States] Geological Survey, the Minerals Management Service, and the National Park Service."); see also id., Appendix 3, at bp. OIGDS_000964 (presenting a table of the specific systems and numbers of weaknesses tested).

On Interior's department-level POA & M, according to Sandy's calculations, Interior's bureaus and offices listed 173 total systems and reported "about 1,997 weaknesses with 2,674 milestone tasks. This results in approximately 12 weaknesses per system and approximately 1.3 milestone tasks for correcting a weakness." Pls.' Ex. 218 (document entitled "Total Numbers Identified in System POA & M"), at bp. OIGIT_0015726; see also Tr. (Hrng., June 3, 2005, PM Sess.), at 21 (testimony of Sandy) (authenticating Pls.' Ex. 218 as a workpaper she prepared in the process of conducting NISO's POA & M review). The nearly one to one ratio of corrective action milestones to identified weaknesses, Sandy explained, is problematic because it represents corrective action processes as "[a] four or five months' time frame [for corrective actions] with no incremental steps[,]" Tr. (Hrng., June 3, 2005, PM Session), at 8 (testimony of Sandy), which is not "really a true picture of how you would go through a process to correct a weakness[.]" Id., at 46 (testimony of Sandy).

Upon review, NISO discovered that "not all known weaknesses were included in the Department's POA & M." Pls.' Ex. 227 (Draft POA & M Rep.), at bp. OIGDS_0000953. This condition results from failures in bureau-level POA & M compilation. See id. (explaining that "[a]t least one bureau indicated that unless a weakness was determined to be `material' it would not be reported [;] ... [and that] [b]ureau personnel involved in the process stated weakness were not reported when (1) identified through day-to-day operations, (2) could be corrected within short time frames, or (3) security risks were accepted"). A weakness might not be reported on a POA & M if a bureau DAA (or the DAA's delegate) chooses to accept the risk of that weakness. See Pls.' Ex. 68 (email from Eddie Saffarinia, CIO of Interior's OIG, to Michael Wood. OIG, Subject: "Fw: Notification of Potential Finding and Recommendation for IG POA & M Review" (Apr. 6, 2005)), Attachment 1 (document entitled Notification of Potential Finding and Recommendation: Verification of DOI's POA & M Process of Correcting Weaknesses of Information Systems, Assignment Number: A-EV-MOA-0001-2005) ("NISO POA & M Draft NPFR 1"), at bp. DOI_OIG_IT0005023 ("DOI's POA & M procedures allow for security weaknesses to be corrected through acceptance of the associated security risk by the DAA."); see also Tr. (Hrng., June 3, 2005, PM Sess.), at 34 (testimony of Sandy) (authenticating Pls.' Ex. 68 at an email with four of NISO's POA & M review NPFRs attached). Sandy explained that NISO was "having concerns ... that ... risk was being accepted by someone other than the DAA, and there was no documentation, there was not adequate justification." Tr. (Hrng., June 3, 2005, PM Sess.), at 36 (testimony of Sandy).

Indeed, NISO reported that "tests of 19 completed actions to correct security weaknesses by accepting the security risk[] disclosed that 8 or 42 percent of these corrected weaknesses were insufficient to ensure that the accrediting officials made informed decisions to accept the risks." Pls.' Ex. 68, Attch. 1 (NISO POA & M NPFR 1), at bp. DOI_OIG_IT0005023. Problems NISO identified with these risk acceptance corrections included: inadequate documentation to support the risk acceptance decision; documentation that did not include "the specifics of the risk if the weakness was not corrected, other compensating controls that could reduce the risk to an acceptable level, or signatures of the individuals and their position titles who accepted the risk;" documentation to support risk acceptance decisions that was dated after NISO's request to review the documents; and acceptance of risks by officials other than the DAA or the DAA's formal delegate. See id. Explaining the implications of this finding, Sandy testified that "we were concerned that systems may be accredited without DAA's having a complete understanding of the risks they were accepting. The DAA may believe that a system has a certain level of security when in fact it may not be operating at that level." Tr. (Hrng., June 3, 2005, PM Sess.), at 36 (testimony of Sandy). Again, NISO attributed the existence of this problem to inadequate policy leadership from the departmental CIO and to a lack of oversight by bureau and office CIOs and BITSMs of the weakness correction process. See Pls.' Ex. 68, Attch. 1 (NISO POA & M NPFR 1), at bp. DOI_OIG_IT0005024.

NISO's second general observation about Interior's POA & M process is that "[a]bout half of the corrected weaknesses we tested were not corrected." Pls.' Ex. 227 (NISO Draft POA & M Rep.), at bp. OIGDS_0000953. Specifically, NISO "examined 133 weaknesses reported as corrected and found that 64 of these weaknesses were not corrected" because "corrective actions were either not performed or were not sufficient to correct weaknesses." Id. As examples, NISO lists:

[c]orrective actions [that] required the purchase of computer equipment, but [for which] the equipment had not been ordered[;] [c]orrective actions [that] required that contingency plans be developed, tested, and updated, but [for which] the plans were nonexistent, were still in draft, or had not been updated [;] [c]orrective actions [that] required that a new IT system be implemented, but [for which] the system had not been implemented[; and] [c]orrective actions [that] required the issuance of policies, but [for which] the policies issued did not adequately address the weakness.

Id. NISO examined 15 weaknesses reported by the Office of the Secretary, and found that 12 of them had not, in fact, been corrected. See id., Appx. 3, at bp. OIGDS_0000964. Similarly, 8 of 16 weaknesses reported corrected by the Office of the Assistant Secretary of Indian Affairs^[23] were found not to be corrected; 5 of 20 weaknesses reported corrected by BLM were found not corrected;^[24] 6 of 17 weaknesses reported corrected by BOR were found not corrected; 21 of 40 weaknesses reported corrected by USGS were found not corrected; 8 of 16 weaknesses reported corrected by MMS were found not corrected; and 4 of 9 weaknesses reported corrected by NPS were not corrected. See id.

Sandy emphasized the problems found with respect to the practice of correcting weaknesses through the issuance of policies, observing that "DOI has a tendency to consider the issuance of a policy [as] being something [that has been] implemented. [NISO has] a basic disagreement with that because issuing a policy does not mean it's been implemented. It has to have some time to get in effect and moved and [to] make sure that it's implemented." Tr. (Hrng., June 3, 2005, PM Sess.), at 38 (testimony of Sandy). In fact, NISO earlier drafted an NPFR on the very issue of correcting weaknesses through policy issuance, noting that "of 22 security weaknesses that were supposed to be corrected by policies, we found problems with 10 or 45 percent of these corrective actions." Pls.' Ex. 68, Attachment 2 (document entitled "Notification of Potential Finding and Recommendation: Verification of DOI's POA & M Process of Correcting Weaknesses of Information Systems, Assignment Number A-EV-MOA-0001-2005") ("NISO POA & M NPFR 2"), at bp. DOI_OIG_IT0005025.

NISO described as problematic supposedly corrective policies that "had been issued prior to the reporting of the weakness in the POA & M, thus indicating that the weakness was not corrected by issuance of the policy but continued because the policy had not been implemented;" policies that "had not been distributed for implementation until months after the reported date of completed corrective actions;" and policies that "did not always specifically address the identified security weakness." Id. POA & Ms that report weaknesses as having been corrected, then, often overstated the state of progress in correcting the weakness. Id. at bp. DOI_OIG_IT0005025 -DOI_OIG_IT0005026. Further, where policies by themselves do not actually correct the weakness, the weaknesses should not be reported as corrected on the POA & M upon mere issuance of the policy because "DOI's POA & M corrective action procedures require that for weaknesses to be considered corrected, the corrective action is to be implemented, tested, and the reported completion date is the date that the corrective action was validated." Id. at bp. DOI_OIG _IT0005025. NISO noted that this problem is caused by a lack of implementation of corrective policies, and recommended that "DOI and bureaus and offices establish as part of their respective POA & M processes verification procedures to ensure that security weaknesses are corrected by the implementation of policy or procedures." Id. at bp. DOI_OIG_IT0005026 (emphasis added).

Other weaknesses NISO identified in Interior's POA & M program included inadequate descriptions of both weaknesses and corrective actions, and a failure to prioritize weaknesses within the departmental-level POA & M. See Pls.' Ex. 227 (NISO Draft POA & M Rep.), at bp. OIGDS_0000954. Expanding on NISO's general conclusion that the identified deficiencies in the POA & M process were the results of inadequate leadership from the departmental CIO, the draft report observes:

The Department's Office of the CIO had issued some policies and procedures regarding the POA & M process. However, the Office did not oversee the process to ensure the Department's POA & M was accurate, timely, and resulted in safeguarding IT resources. The Office of the CIO did not ensure that the current process included an adequate quality assurance and verification methodology and did not ensure that responsible officials were held accountable.

Id. With respect to the absence of a department-level quality assurance process for the POA & M program, NISO specifically noted that "the Department had not taken steps to ensure that IT security weaknesses were adequately described in the POA & M and that the planned actions would correct the weaknesses." Id. In addition, "the Department has not implemented a verification process to ensure that weaknesses reported as corrected had in fact been corrected," and "the Department had not established appropriate accountability for reporting accurate and reliable information to in the bureau [s'] POA & M[,]" as NISO observed that the "Department's POA & M guidance states that the [CIO's office] will validate the completion of corrective actions ... [and] that the OIG is responsible for validating POA & M information ... [when] [n]one of these organizations should be responsible for the accuracy of the bureaus' POA & M data." Id., at bp. OIGDS_0000955. Instead, NISO recommends that "accountability should be established through a certification process where appropriate bureau officials certify that POA & M information is accurate." Id.

NISO concludes the draft POA & M evaluation report with an observation about the importance of the POA & M process to the sufficiency of Interior's overall IT security program.

If it is true that the POA & M is the Department's tool to manage IT security weaknesses, then the department is relying on information that we found to be inaccurate, incomplete, and untimely. Without reliable information in the POA & M, the Department cannot identify systemic problems and monitor corrective actions. Also, management may make inappropriate decisions regarding the Department's information security program. Therefore, the Department cannot ensure that the most significant weaknesses are corrected first and that its systems and data are adequately safeguarded.... If the Department does not correct its process, it will continue to provide inaccurate and incomplete information to OMB and Congress. Further, if the Department does not take immediate action, it is our opinion that the Department should report this condition as a significant deficiency in its fiscal year 2005 FISMA report. OMB defines significant deficiency as a systemic weakness that if it remains uncorrected poses a significant risk to the security of IT systems and programs.

Pls.' Ex. 227 (NISO draft POA & M Rep.), at bp. OIGDS_0000956-OIGDS_0000957. Sandy concurred with the report's conclusion that the problems identified in the POA & M program represent a systemic problem in the department's IT security program resulting, in the main, from a lack of effective leadership at the departmental level, and that this systemic problem constitutes a "significant deficiency" within the meaning of OMB standards. See Tr. (Hrng., June 3, 2005, PM Sess.), at 82 (testimony of Sandy); Tr. (Hrng., June 2, 2005, AM Sess.), at 90 (testimony of Sandy) ("Q: ... [Y]our [POA & M] study was just a very small sampling. A: Correct. Q: and you identified specific issues within that small sampling. A: Correct. Q: But it was reflective of a whole departmental-wide problem. A: Right. That's why we said it was a significant deficiency ... [because regardless of whether] we selected 6 systems or 20 systems ... an error rate of 50 percent, that is too high."). She also placed the POA & M deficiencies in the context of the C & A process as a whole, explaining that

if we can't even get weaknesses corrected, it really doesn't make any difference whether you've go the rest of this done, because ... if the DAA is relying on [a notation in a POA & M] that a weakness is corrected, that to me is a terrible problem. If the corrected weakness in fact is not corrected, the the DAA believes that that system is operating at this [more secure] level. He may or may not know all of the weaknesses, but he's got a lot of weaknesses identified, [and] when you say I've corrected something and it's not in fact been corrected, you're really making a terrible [accreditation] decision. You have no foundation for your [accreditation] decision, because the information you've been provided is wrong.

Id. at 75. Sandy summarized the nature of the POA & M problem, explaining that "it's not just that POA & M Item Number One on System Number Y needs to be fixed. There was a problem in the process, which started with the DOI's process and then trickled down to the bureaus.... So that was part of our concern, the difference between correcting a condition and correcting the cause." Tr. (Hrng., June 7, 2005, PM Sess.), at 69-70 (testimony of Sandy).

iv. Departmental Responses to IG IT Security Findings

Ms. Sandy stressed that the departmental responses to the IG's FY 2004 FISMA report, Wireless Technology Evaluation, and POA & M Program Review, usually expressed through Interior's departmental CIO Hord Tipton, were nearly identical, and similar enough in nature and tone to establish a clear pattern. See Tr. (Hrng., June 6, 2005, PM Sess.), at 64 (testimony of Sandy). This pattern is also apparent in the department-level response to the results of ISS's penetration testing.

FY 2004 FISMA Evaluation — Sandy explained that the departmental CIO's office should place the IG's FY 2004 FISMA findings on the department-level POA & M as weaknesses to be corrected. See Tr. (Hrng., June 3, 2005, AM Sess.), at 81 (testimony of Sandy). In her dealings with the CIO's office, however, Sandy has noted that the CIO "is of the opinion that [FISMA findings] need ... to be put ... on that specific POA & M for that specific bureau." Id. Apparently in anticipation a hearing like this one, Joel Hurford, Interior's new DITSM, alerted others in the departmental CIO's office and the Office of the Secretary that "[w]e will need to inventory the FISMA 2004 findings (as best we can) to account for them in our POA & M. I do expect that we will close most due to lack of specificity and substantiation." Pls.' Ex. 215 (email from Joel Hurford, DOI OCIO DITSM, to Steve Matthews, DOI Office of the Secretary, Subject: "Seeking Cobell Supporting Documentation (Tue, Jan. 4)" (Dec. 28, 2004)) ("Hurford FISMA Email"), at bp. OIGDS_0002588.

Sandy interpreted Hurford's criticism of the FY 2004 FISMA findings as lacking "specificity and substantiation" to be an expression of "his prime concern," which is "being able to marry any information coming out of an IG report into a specific POA & M, meaning a specific system POA & M." Tr. (Hrng., June 3, 2005, PM Sess.), at 80 (testimony of Sandy). Sandy testified that "closing" a POA & M entry, in the context of Hurford's statement, means "marking them as completed or corrected." Id. at 83 (testimony of Sandy). Of course, closing a POA & M entry for lack of specificity or substantiation when the problem has, in fact, been identified and verified in an independent IG evaluation, as Sandy noted, amounts to listing a weakness as corrected when it really has not been. See id. (testimony of Sandy). When asked whether Hurford's statement indicated that the departmental CIO intended to ignore the IG's FY 2004 FISMA findings and recommendations, Sandy responded: "It appears to me that the answer would be yes." See Tr. (Hrng., June 7, 2005, PM Sess.), at 67-68 (testimony of Sandy). Sandy also indicated that the IG received similar responses from Interior's CIO on other occasions: "[T]his lack of specificity and substantiation ... you will see this on the POA & M 2005 response to the NFRs; you will see this in response to the wireless as well." Tr. (Hrng., June 3, 2005, AM Sess.), at 81 (testimony of Sandy).

In addition to these specificity objections, the departmental CIO's office negotiated with the IG's office to change from "poor" to "satisfactory" the IG's response to OMB's FISMA evaluation question C.1, which asks for an "Assessment of the Certification and Accreditation Process." See Tr. (Hrng., June 3, 2005, AM Sess.), at 45-46 (testimony of Sandy) (recalling the specific meeting where this alteration was negotiated and agreed upon); see also Pls.' Ex. 72 (document entitled "2004 FISMA Report, Agency: Department of the Interior, Submitted by: OIG" (undated draft)), at bp. DOI_OIG_IT0009848 (displaying a draft of the IG's FY 2004 response to OMB's FISMA evaluation question C.1; rating Interior's C & A process as "poor" and commenting that "DOI has established a good C & A process ... [but] not all components have fully implemented DOI"s process"); Pls.' Ex. 15 (2004 FISMA Rep.), at 21 (displaying the IG's finalized FY 2004 response to OMB's FISMA evaluation question C.1; rating Interior's C & A process as "satisfactory"); see also Tr. (Hrng., June 3, 2005, AM Sess.), at 47-48 (testimony of Sandy) (clarifying that the OMB FISMA questionnaire actually has two questions numbered "C.1," one of which addresses POA & Ms and the other C & As).

The IG's response to the C & A evaluation question was changed, Sandy confirmed, on the basis of "the fact that the [departmental] CIO has gone on record and stated to [the IG's office] that he is going to have this independent contractor review all certification and accreditations." Tr. (Hrng., June 3, 2005, AM Sess.), at 46 (testimony of Sandy); see also Pls.' Ex. 212 (document entitled "Assignment Workpaper, Assignment: Evaluation of DOI's Information Security policies-procedures-practices-and controls, Subject: Review of C & A for Systems Selected," prepared by Stacey Crouser, NISO (Aug. 31, 2004)), at bp. DOI_OIG_IT0028425 (noting under the "conclusion" heading: "Update 9-23-04: Based on subsequent information — specifically, the quality assurance initiative that is being implemented by the DOI CIO, the rating reported in the OMB template for question C.[1] will be reported as satisfactory"); Pls.' Ex. 14 (2004 FISMA Rep.), at 21 ("DOI recognizes that there are issues in [the C & A] area and, as a result, recently initiated a quality assurance process that entails the detailed evaluation by independent contractors of certification and accreditation documents submitted by bureaus to ensure all DOI requirements are met. Our rating of satisfactory in this area, in part, is based on the implementation of this new initiative by DOI, the effectiveness of which has not yet been evaluated.").

While Sandy testified that she had no personal knowledge of the status of the departmental CIO's C & A documentation quality assurance program, see Tr. (Hrng., June 3, 2005, AM Sess.), at 53 (testimony of Sandy), the IG's office is in the process of evaluating the efficacy of the CIO's efforts. See Pls.' Ex. 73 (email from Hord Tipton, DOI CIO, to DOI Bureau CIOs, DOI Deputy CIOs, Subject: "FISMA FY 2005 Second Quarter IT Security Update" (May 11, 2005)) ("FY 2005 Q2 FISMA Update"), at bp. DOI_OIG_IT0002283. This evaluation is being conducted by Mahach's NSM group, but Mahach could not testify in detail about either the status of the IG's evaluation or the sufficiency of the departmental CIO's quality assurance process generally. See Tr. (Hrng., May 23, 2005, PM Sess.), at 114-16 (testimony of Mahach) (indicating that his team's work on this evaluation has "kind of been sidelined"). He did, however, indicate that preliminary findings were mixed: while the CIO's quality assurance review appears to have been successful in that it has resulted in the de-accreditation of "13 or 14" previously certified and accredited Interior systems, see id. at 112-13 (testimony of Mahach), there have also been problems with some of the departmental CIO's "system counts [.]" See id. at 115 (testimony of Mahach). The IG's second FY 2005 quarterly FISMA update to the department elaborates, explaining that during its evaluation of the department's C & A quality assurance program, "`we noticed discrepancies in system counts between bureaus Plan of Actions & Milestones, the DOI Certification and Accreditation database of record known as Command Center, and lists used in the quality assurance process." Pls.' Ex. 73 (FY 2005 Q2 FISMA Update), at bp. DOI_OIG_IT0002283. Mahach also noted that the CIO's quality assessment process would not be reviewing C & A documentation for Interior systems or systems housing or accessing Interior data that are owned or maintained by private contractors or Indian tribes. See Tr. (Hrng., May 24, 2005, PM Sess.), at 81-84 (testimony of Mahach). The final evaluation report, Mahach said, likely would not be available until after the completion of the trial. See Tr. (Hrng., May 23, 2005, PM Sess.), at 117 (testimony of Mahach).

Wireless Technology Evaluation — Tipton issued a response to the IG's wireless technology evaluation in February 2005. See generally Pls.' Ex. 240 (memorandum from W. Hord Tipton, DOI CIO, to Inspector General, Subject: "Response to Wireless Technology Evaluation Report (A-IN-MOA-0004-2004, December 2004)" (Feb. 14, 2005)) ("CIO Wireless Resp."); Tr. (Hrng., June 6, 2005, PM Sess.), at 34-35 (testimony of Sandy). Tipton opened his response to the IG's wireless report by praising NISO "impressive effort in ... evaluating activities at 106 sites across the United States[,]" and thanking the IG's office for "drawing attention to implementation issues observed." Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_IT0032701. However, Tipton continued, "the report has a number of flaws that impede my ability to confirm and support the recommendations listed." Id. Generally, Tipton explained that he "agree [d] with many of the recommendations provided in the report," but that "many of them were already implemented prior to the completion of field work and are represented in the 802.11xx Wireless Security Technical Implementation Guide, February 27, 2004." Id., at bp. DOI_IT0032702. The CIO's Security Technical Implementation Guide ("STIG") for wireless technologies, Sandy explained, "identif[ied] control techniques that DOI believed that its wireless ... local area networks should have in place." Tr. (Hrng., June 6, 2005, PM Sess.), at 34 (testimony of Sandy); see generally Pls.' Ex. 240 (draft letter from Hord Tipton, DOI CIO, to Solicitor, Inspector General, Heads of Bureaus and Offices, Bureau/Office Chief Information Officers, Subject: Guidelines for Use of Wireless Network Technology) ("Draft CIO Wireless Policy"), Enclosure (draft document entitled "Department of the Interior, Office of Cyber-Security, 802.11xx Wireless Security Technical Implementation Guide, Version 1.0" (Jan. 6, 2004)) ("Draft CIO Wireless STIG"); Pls.' Ex. 42 (document entitled "Department of the Interior, Office of Cyber-Security: 802.11xx Wireless Security Technical Implementation Guide, Version 1.0" (Apr.2004)) ("CIO Wireless STIG").

Tipton's response also explained that "DOI issued a moratorium [on wireless technologies] in April 2004[,]" Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_IT0032703, which remains in effect today, and that "DOI has drafted a Wireless Strategic Plan that ... creates a context of technology strategy by which the tactical decisions of the STIG are better framed for implementation[,] [and that] is scheduled for final approval in April 2005." Id., at bp. DOI_IT0032702. Indeed, the draft letter attached to the draft STIG announces, as the "policy" transmitted, that "DOI does not authorize the use of any 802.11xx" technology. See Pls.' Ex. 240 (Draft CIO Wireless Policy), at bp. OIGIT_0015013; see also Tr. (Hrng., June 6, 2005, PM Sess.), at 34 (testimony of Sandy) (discussing the issuance of the departmental moratorium on wireless technology use, and the issuance of the wireless STIG).

Among Tipton's complaints was the assertion that the "[l]ack of specific detail across 106 sites impedes my ability to confirm the observations and trace the performance issue to a root cause." Id. Sandy explained that Tipton's response indicated his desire "to know which systems were being impacted by the wireless[,]" while the IG's office was more concerned about drawing Tipton's attention to the larger, systemic problem indicated by the lack of effective management and implementation of security policies prior to large-scale deployment of wireless networking at Interior. See Tr. (Hrng., June 6, 2005, PM Sess.), at 63. Indeed, Tipton's next objection underscores this difference in focus, as he complains that a "[l]ack of coordination and notification of findings over the course of a 15 month report prevents me from immediately concluding the conditions identified as part of the report." Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_IT0032701. Tipton also demanded greater specificity so that his recommendations for remedial action could be "specific to the nature of the weakness observed" rather than "summary in nature." Id.

Sandy interpreted these demands as "request[s] that the report clearly articulate; i.e. label, condition, cause, criteria, and effect" but noted that "in fact the report contained that information." Tr. (Hrng., June 6, 2005, PM Sess.), at 64. When Sandy briefed Tipton orally on the results of the wireless evaluation in November 2004, the focus of his questioning was the same: "where were the actual wireless devices connected on which network? That's what I recall [being] the biggest discussion." Id. at 59-60 (testimony of Sandy). Sandy responded to Tipton's November 2004 question by emphasizing:

again, I sound[ed] like a broken record — it's not just those. You need to know how many more there are and where they are and fix that problem, not just fix the ones that I've identified in the report. Because again, that's correcting the condition, not correcting the cause.

Id. at 60 (testimony of Sandy). The IG's office also noted that "[t]he issue raised in our report is the lack of overall management of the growth of wireless technology in the Department, as we found during our site visits, not problems with wireless technologies at the individual sites we surveyed." Pls.' Ex. 243 (draft memorandum from Roger LaRouche, DOI Assistant Inspector General for Audits, to W. Hord Tipton, DOI CIO, Subject: Office of Inspector General Comments on the Response from the Office of the Chief Information Officer on the Evaluation Report on the Department of the Interior's Use of Wireless Technologies (Report No. A-IN-MOA-0004-2004)) ("IG's Draft Wireless Reply"), at bp. OIGDS_0000390; see also Tr. (Hrng., June 6, 2005, PM Sess.), at 75 (testimony of Sandy) (authenticating Pls.' Ex. 244, affirming that it is "relatively similar to what we've actually provided to Mr. Tipton"). "We presented the examples[,]" the IG continued "to demonstrate that bureaus and offices moved forward with wireless technologies on their own without sufficient guidance and oversight from the Department." Id. at bp. OIGDS_0000390-OIGDS_0000391.

Tipton's specific criticisms of the wireless report's recommendations demonstrate another problem with the departmental-level approach to solving IT security problems — mistaking the issuance of policies for the implementation of policies. Regarding the IG's charge that Interior has not adequately managed the implementation of wireless technologies from the beginning and corresponding recommendation that the CIO's office establish a strategic wireless plan, Tipton argued that:

[t]his guidance is already captured in the 802.11xx STIG. The finding indicates a pervasive case of mismanagement, but no condition, criteria, cause, or effect [were] provided to gauge the urgency of 700 wireless components in an organization of 80,000 staff and 2,400 operating locations. Supporting details must be provided or the weakness/recommendation more appropriately limited in scope.

Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_IT0032072. Tipton also noted that Interior was in the process of drafting a new plan to account for wireless technologies to be issued in April 2005. See id. Sandy first noted that the CIO's wireless STIG, issued in February 2004, was not being implemented by the bureaus and offices, "[b]ecause we were actually out on he road, still testing for 802.11 configurations in April [2004], ... [and] we were still not seeing bureau responsiveness to the implementation guide." Tr. (Hrng., June 6, 2005, PM Sess.), at 3; (testimony of Sandy). Sandy explained that this bureau noncompliance was likely due to the nature of the STIG, which is:

a guide, not a plan. It just says, this is what you should have. [A] technical implementation guide is really just that. It doesn't say how or when or why you should use it, it just says, if you have it, this is what you should do. So there's a difference between what that ... technical implementation guide is versus what a strategic plan is. [A strategic plan] is defining a better concept of how you should use these emerging technologies, how they're going to improve your overall ability to provide IT support to accomplish the DOI mission. So that's what we were looking for, not the how-tos but the whys.

Id. at 66-67 (testimony of Sandy). The official IG reply to Tipton's response to the wireless report also emphasized that the February 2004 STIG "outlines security standards for DOI's 802.11 series of wireless technologies [but] does not provide clear information on when and how these technologies should be used." Pls.' Ex. 243 (IG's Draft Wireless Reply), at bp. OIGDS_0000392. Sandy observed that the CIO's reliance on the STIG as a curative policy should have come with the recognition that "with the STIG you have to actually go out and test once in a while and see what's going on," to ensure proper implementation. See Tr. Hrng., June 6, 2005, PM Sess., at 67 (testimony of Sandy).

In response to the IG's finding that Interior's inventories of wireless networks and devices were incomplete, and the corresponding recommendation that Interior establish an approval process for new wireless initiatives and compile an accurate inventory of wireless devices, Tipton declared that there were:

[n]o supporting details indicating which of the 700 identified devices were outside the supplied inventory. Without that, there is not appropriate evidence that the existing processes are insufficient. While we agree with both recommendations, DOI had already implemented such solutions at the time of review. DOI issued a moratorium in April 2004 that further strengthened the rigor by which wireless networks are established.... Several bureaus have requested wireless LAN implementation. One bureau demonstrated such mature procedures that I delegated future approval of wireless use to them. Criteria for approval include compliance with the STIG.

Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_IT0032703. Since the issuance of his response, however, Tipton has found the bureaus' responses to his demands for complete wireless inventories to be "a pain point." See Tr. (Hrng., July 27, 2005, AM Sess.), at 20 (testimony of Tipton). This is because "[i]t took a while to get the bureaus to realize that they need to go out and to polish and to refine their [wireless] inventory to reconcile it." Id. at 20-21 (testimony of Tipton). "It took over a year to get where I am now," Tipton explained, see id. at 21, but now "I have a wireless inventory." Id. at 20. But even this newer inventory may not be complete, he confessed, noting that "I'm ... trying to raise the confidence level that the inventory is accurate and will meet scrutiny and audit testing." Id.

The IG's reply noted that, indeed, "the April 8, 2004 memorandum represented official policy because it clearly articulated that the use of wireless technology was not authorized." Pls.' Ex. 243 (IG's Draft Wireless Reply), at bp. OIGDS_0000392. However, the IG's office continues, "we do not believe that issuance of the April 2004 memorandum implements a formal approval process for authorizing existing or new wireless network pilot projects or that it constitutes an accurate inventory of wireless networks and devices." Id., at bp. OIGDS_0000393. Despite Tipton's representations to the contrary, the IG noted:

While the April 2004 memorandum is a step in the right direction [], it does not contain sufficient procedures to establish a formal process for authorizing wireless network devices. For example, [Tipton] stated that several bureaus have requested wireless LAN implementations and that one bureau demonstrated such mature procedures that you delegated future approval of wireless projects to them. However, [Tipton] did not demonstrate the process used to determine the sufficiency of the bureau's approval process or how the Department would monitor bureau actions. In regard to the inventory, the [CIO response] does not indicate that an inventory had been compiled or verified, or present a plan for doing so. Also, at our November exit conference, the CIO agreed that the April 2004 memorandum had not resulted in an accurate inventory of all wireless network devices and that U.S. Fish and Wildlife had not provided [the CIO's office] with any inventory information.

Id. Tipton's responses, and the rejoinders from the IG's office, were similar for the other findings and recommendations in the IG's wireless evaluation report. See, e.g., Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_ IT0032703 (responding to the IG's finding that Interior's "wireless capabilities" are not "known or controlled" with a call for "supporting details of quantity and quality"); Pls.' Ex. 243 (IG's Draft Wireless Reply), at bp. OIGDS_0000393-OIGDS_ 0000394 (countering that the IG's recommendation was not intended to result in remediation of specific instances but rather programmatic change to Interior's security awareness training).

Sandy explained that Interior's belief that its policy issuance corrected the wireless problems in and of itself was typical of the way in which IT security matters are addressed at the departmental level. "This, again, is where I believe that the CIO's office believes ... the issuance of a guideline, policy or document, equates to implementation, which the IG, me, or most of us in the Office of Audits do[ ] not agree with that statement.... [J]ust ... the issuance of the policy is not an implementation." Tr. (Hrng., June 6, 2005, PM Sess.), at 65 (testimony of Sandy). Indeed, Roger Mahach testified that the CIO's wireless moratorium, to this day, has not been implemented throughout Interior's bureaus and offices. See Tr. (Hrng., June 10, 2005, PM Sess.), at 57 (testimony of Mahach) ("Q: Do you believe that that policy of no wireless is being followed throughout the department? A: I do not. Q: And what's your basis for that? A: I've seen it."). At the time of trial, because the CIO's office had issued no further policies or guidance on wireless technology, and indeed had provided IG with no documents subsequent to the filing of Tipton's formal response memorandum; the IG's position was that Interior was not in compliance with the recommendations in the wireless evaluation report. See id. at 46, 77 (testimony of Sandy); id. at 81 (testimony of Sandy) ("Q: In your opinion, did the CIO's office adequately address the needs you identified in your report? A: The needs to whom, to the use of? Q: Right. Exactly. Addressing the risk inherent to using wireless technology[?] A: No, I don't believe they had."). Indeed, to fully address the wireless technology related risks identified in the IG's report, Sandy explained, would require a comprehensive review of wireless technology issues throughout Interior. See id. at 81 (testimony of Sandy). The task essential to such a programmatic review, however, have not yet been undertaken. See id. (testimony of Sandy).

POA & M Program Evaluation — Interior's office of the CIO responded to Sandy's POA & M program evaluation NPFRs 1 and 2 in a memorandum dated March 31, 2005, and to NPFRs 3 and 4 in a memorandum dated April 1, 2005. See Pls.' Ex. 221 (memorandum from W. Hord Tipton, DOI CIO, to Diann Sandy, OIG NISO, Subject: "Response to Potential Notification of Findings and Recommendations for the DOI POA & M Process (A-EV-MOA-0001-2005)" (Mar. 31, 2005); memorandum from W. Hord Tipton, DOI CIO, to Curtis Crider, OIG Office of Audits, and Diann Sandy, OIG NISO, Subject: "Response to Potential Notification of Findings and Recommendations for Plan of Action & Milestones Process (A-EV-MOA-0001-2005)" (Apr. 1, 2005)) ("CIO POA & M Resp."). Sandy explained that the CIO's responses were generally similar, in that they demanded greater specificity in identifying individual weaknesses and sounded very much like the CIO's responses to the IG's wireless evaluation report and the CIO's position regarding the IG's FY 2004 FISMA findings. See Tr. (Hrng., June 3, 2005, PM Sess.), at 50-53 (testimony of Sandy).

Some examples of the CIO's responses to the IG's POA & M NPFRs bear out this generalization. In response to POA & M NPFR 1, where NISO noted having observed insufficient documentation for weaknesses that were corrected by accepting the risk, the CIO complained that:

[t]he stated weakness is ambiguous with regard to the performance issue. You indicated a lack of performance with regard to the acceptance of risk, but what about the acceptance of risk is insufficient[?] ... The [NPFR] provided high level statistics that (8 of 19) accepted risks `were insufficient' with regard to approval. Additional specifics are required for each instance of insufficiency to validate the nature of the risk, the approval procedures observed, and the sufficiency of those procedures.

Pls.' Ex. 221 (CIO POA & M Resp.), at bp. OIGDS_002039. Regarding POA & M NPFR 2, where the IG identified problems associated with marking weaknesses as corrected after issuance of a supposedly curative policy alone, the CIO responded, again, that:

[t]he stated weakness is ambiguous with regard to the performance issue. You indicate a lack of performance with regard to the provision of policies or procedures, but what about the process is insufficient[?] From the remainder of the [NPFR], it appears that you are concerned with `Lack of implementation.' ... The [NPFR] provided high level statistics that (10 of 22) weaknesses resolved by policy/procedures `had problems.' Additional specifics are required for each instance of insufficiency to validate the nature of the original finding and the degree by which the finding has been resolved.

Id., at bp. OIGDS_0002040. In response to POA & M NPFR 4, in which the IG reported that the departmental POA & M program lacked appropriate mechanisms to ensure that information reported by the bureaus and incorporated into the departmental POA & M is complete, accurate, and reliable, the CIO lodged a remarkably similar complaint:

While the description and recommendations of this [NPFR] are relevant and of priority interest for Department resolution, the specific observations of missing findings or incomplete resolutions must be identified to the Department for validation.... [W]ithout knowing the specific instances, the Department cannot confirm this finding as valid. Please provide specific examples of findings, systems, and deficiencies with management.

Id., at bp. OIGDS0002046.

Sandy elaborated on the pattern of the CIO's responses to the IG's various evaluation reports, observing that:

I had resistance from [the CIO] primarily on the fact that he wanted specific bureaus identified and specific systems, and what we had found in the past is, based on our wireless, is that rather than change their process, they go out and bash a bureau, and while other bureaus really should be bashed... what was missing was that the department was failing to see that it was their processes that were allowing the bureaus to not do it the right way.... So there's where we got a lot of ... disagreement ... [the CIO] wanted the ammunition to basically go to [a bureau] to fix that specific weakness and we wanted him to fix the process from his own procedural guidance, which is not terrible, but it needs improvement, and to then build into that process of verification and certification. So we wanted [the CIO] to fix DOI's process first rather than go attack the bureaus or fix the bureaus.

Tr. (Hrng., June 2, 2005, AM Sess.), at 89-90 (testimony of Sandy). She recalled that the IG's recognition of this attitude within the departmental CIO's office accounts for the fact that "we opted not to present the [2005 POA & M NPFRs] in that fashion. We did not go and say `BIA's [Fee to Trust system ("FTT")], this is the specific weakness' because what we were leery of was the department would go to ... Indian Affairs and say `I need you to correct that weakness on Fee to Trust that Diann Sandy and her team identified' rather than fix the process.'" Id. at 90 (testimony of Sandy).

Sandy and others from the IG's office later met with representatives of Interior's CIO's office to discuss the CIO's responses to the POA & M program NPFRs. See Tr. (Hrng., June 3, 2005, PM Sess.), at 53 (testimony of Sandy). "I indicated to Mr. Tipton," Sandy testified, recalling her attempts to communicate the problem highlighted by the nature of the CIO's responses, that:

your POA & M guidance is part of the problem, and so you need to have some accountability in this process, not just identifying that Bureau of Indian Affairs doesn't have their 11 systems identified in the POA & M. What are you doing about it? ... I stated to [Tipton], ... if you're only going to correct the weaknesses that I have identified that were not corrected, you haven't solved the problem. You've only solved those particular weakness issues.... Because I only looked at 133 of the ... 765 or 725 [weaknesses] that were actually reported as corrected.... There's potentially 600 more [weaknesses] out there that are not corrected that have in fact been reported as corrected. So what are you going to do about those other 600? ... Going out there and whipping BIA and mak[ing] sure they get their 11 systems on the POA & M, making sure that they have in fact corrected the weaknesses is not solving the problem, it's only going to solve those minor little issues. What about the overall? ... I clearly conveyed to Mr. Tipton that this is not about each weakness, it's about the overall POA & M process.

Id. at 55-57 (testimony of Sandy). Indeed, Sandy emphasized this very issue in a draft reply to the CIO's response to the POA & M NPFRs, though the draft was never finalized and delivered to Interior's CIO. See Pls.' Ex. 222 (email from "Diann," no recipient listed, Subject: "POA & M) (Apr. 9, 2005) ("Draft POA & M Reply"); see also id. at 63-64 (testimony of Sandy) (authenticating and discussing Pls.' Ex. 222, noting that she prepared it because "we needed to have something in writing so we could support why we were disagreeing with their disagreement, and where the information was coming from to disagree with them"). The draft reply summarizes the IG's concerns about the strategy of the CIO indicated by the POA & M NPFR responses:

[T]he OCIO wants the specific POA & M reported corrected security weaknesses that we considered insufficient. With this type of attitude of the OCIO, the OCIO is failing to grasp that a finding is not about the condition but rather the cause. We clearly stated the cause as a lack of DOI processes that would ensure that the condition would not continue to exist. The OCIO's response and demand for specifics of each reportedly corrected weakness for their verification and validation indicates that their methodology is not of a change in management process but a reaction to fix only individual items.... It is my opinion that until the DOI CIO and the OCIO staff take on and fulfill their roles and responsibilities as required under the Clinger Cohen and the Federal Information Security [Management] Acts, that no consensus will ever be reached regarding these NPFRs or any other NPFRs or the draft report.

Pls.' Ex. 222 ("Draft POA & M Reply"), at bp. OIGDS_0002069-OIGDS_0002070.

Despite Sandy's generally negative assessment of the CIO's responses to IG findings, she was pleased when the CIO's office provided her with a draft version of a "memorandum to the bureaus and offices about verifying the weaknesses that had been reported as corrected[ ]" on the POA & Ms. See Tr. (Hrng., June 3, 2005, PM Sess.), at 58 (testimony of Sandy). Although this was not precisely what the IG had recommended, "at least it does look like they're trying to do something[] ... to have [bureaus and offices] at least go back and review reported weaknesses from fiscal year 2004 up and through the third quarter of 2005, and have the CIO certify that, yes, the corrective actions have been taken." Id. (testimony of Sandy). But she did not know, at the time of trial, what progress this draft had made toward being finalized. Id. at 58-59 (testimony of Sandy).

On April 11, 2005, Inspector General Devaney issued a memorandum to Interior's office of the CIO to comment on the CIO's recent responses to the various IG reports just discussed. See Pls.' Ex. 324 (memorandum from Earl E. Devaney, DOI IG, to W. Hord Tipton, DOI CIO, Subject: "Response to Recent Memoranda" (Apr. 11, 2005)) ("Devaney Reply Memo."), at bp. DOI_IT0032699-DOI_ IT0032700. "Overall," Devaney observed,

the defensive and demanding tone of your memoranda suggest a wholesale lack of understanding regarding our respective roles. While you are responsible for DOI programs operated with appropriated funds, the OIG is charged with evaluating such programs and operations to ensure that the Secretary, Congress, and the tax payers that programs and activities are in compliance with laws and regulations and free from fraud, waste, and abuse. Your demand for certain methods, approaches and information from the OIG are utterly inappropriate. The OIG has statutory authority to critique your work; you have no commensurate authority to critique the work of the OIG.

Pls.' Ex. 324 (Devaney Reply Memo.), at bp. DOI_IT0032699. Regarding the CIO's criticisms of the IG's wireless evaluation report, one of which had to do with the failure of the IG's office to issue NPFRs during the process of completing the evaluation and compiling the final report, see Pls.' Ex. 242 (CIO Wireless Resp.), at bp. DOI_IT0032701 ("Lack of coordination and notification of findings over the course of a 15 month report prevents [the CIO] from immediately concluding the conditions identified as part of the report."), Devaney explained that "NPFRs are issued as a courtesy, with the hope that the Department, its bureaus and offices would either clarify the findings by providing meaningful and useful information, or correct the identified problem before the audit or evaluation was completed." Pls.' Ex. 324 (Devaney Reply Memo.), at bp. DOI_IT0032699 (emphasis in original).

Devaney also addresses the CIO's memorandum concerning the IG's first NPFRs issued during the FY 2005 evaluation of Interior's POA & M program. While the memorandum "purported to respond to the first NPFR," Devaney said, it actually "launched into a critique of the NPFR and demanded that the OIG provide specific information regarding its findings." Pls.' Ex. 324 (Devaney Reply Memo.), at bp. DOI_IT0032700. He continued and mentioned the same problem with the CIO's responses that Sandy was so careful to emphasize — the failure of departmental level officials to understand the IG's recommendations regarding systemic, department-wide problems:

Since the OIG is under no obligation ... to issue NPFRs, it follows that the OIG is under no obligation to provide specific information regarding the NPFR. Nonetheless, communication between you and OCIO and bureau IT staff would supply the information you seek. This, however, would not resolve your fundamental failure to grasp the purpose of the NPFR. Although the NPFR cites specific findings and instances in which the findings occurred, the OIG is not recommending that these specific instances be corrected. Rather, the OIG is recommending that processes and controls be implemented to prevent the recurrence of such findings and instances.

Id. With respect to the CIO's consistent demands for more information in response to each of the IG reports under consideration here, Devaney asserted that "the OIG will continue to conduct independent, fair, and thorough investigations, audits, evaluations, and assessments using all applicable professional and legal standards," but that his Office "will not yield a speck of its statutory independence to the demands of an entity which is subject to its oversight authority and responsibility." Id. at bp. DOI_IT0032699-DOI_IT0032700. Mahach, who contributed to the drafting of Devaney's memorandum, recalled that the impetus for its issuance was the tension between the IG's office and the CIO's office created when the CIO's office, once again, either could not or did not want to recognize that the problems represented in the IG's FY 2005 POA & M evaluation NPFRs represented systemic, department-wide issues. See Tr. (Hrng., May 19, 2005, PM Sess.), at 85-88 (testimony of Mahach).

Indeed, Roger Mahach recalled yet another, earlier example of this same attitudinal problem with the departmental CIO's office. Mahach emailed the CIO in June 2003 to notify him that "we have a major problem in the" Office of the Secretary ("OS"), resulting from what seemed to Mahach to be "a total abdication of security responsibility by the OS system owners," who had completed some IT security documentation improperly. See Pls.' Ex. 306 (email from Roger Mahach, DOI DITSM, to Hord Tipton, DOI CIO, Subject: "Lack of OS IT Security Officer," (June 12, 2003)), at bp. DOI_CIO_0024759; see also Tr. (Hrng., June 13, 2005, PM Sess.), at 44-47 (testimony of Mahach) (authenticating and discussing Pls.' Ex. 306 and the incident involved). When he raised the documentation problem with the OS IT staff, Mahach reported that the general responses were: "OCIO should do this for me[;][i]t's not my problem it's the bureaus[;][or][w]e are migrating to a new system and why waste any money" correcting the documentation problems. See Pls.' Ex. 306, at bp. DOI_CIO_0024759-DOI_CIO_0024760. "The OS needs to lead by example and we are failing to do so[,][and] there is a large part of the OS that is not being managed by anyone[,]" Mahach complained, "this is a serious issue and is going to haunt us if we do not address this immediately. It['s] been ignored for far too long." Id. at bp. DOI_CIO_0024760.

Tipton's reply to Mahach's email is telling. Despite Mahach's emphasis on the lackluster IT management apparatus at the OS, the departmental CIO responded that "this is a generic indictment. Are you saying that every single [piece of documentation] stinks? If not, give me the gory details on the ones that do. We will fix it!" Pls.' Ex. 306 email from Hord Tipton, DOI CIO, to Roger Mahach, DOI DITSM, Subject: "Re: Lack of OS IT Security Officer" (June 12, 2003) at bp. DOI_CIO_0024759. Mahach again attempted to focus Tipton's attention on the management problem, see Pls.' Ex. 306 (email from Roger Mahach, DOI DITSM, to Hord Tipton, DOI CIO, Subject: "Re: Lack of OS IT Security Officer" (June 12, 2003)), at bp. DOI_CIO_0024758-DOI_CIO_0024759, but Tipton continued to focus on the individual instances of the documentation problem that Mahach had identified. See Tr. (Hrng., June 13, 2005, PM Sess.), at 49-50 (testimony of Mahach). The failure of the department-level senior IT management to recognize that particular instances of a problem may represent an underlying, more widespread issue explains why, in early 2004, Mahach thought that IT security at the OS remained, at least, the worst of all Interior's bureaus and offices. See id. at 46 (testimony of Mahach). Mahach recalled an early 2004 discussion with Diann Sandy in which the issue of IT security at OS was raised: "I think I may have even said there was none." Id. (testimony of Mahach). The problems that members of the IG's office have encountered in attempting to work with Interior's office of the CIO are evident, once again, in the CIO's responses to ISS's penetration testing results.

FY 2005 External Penetration Testing — Two examples from the evidence suffice to underscore the persistence of Interior's previously noted patterns of managerial short-sightedness. Rolfes testified that BLM disconnected its Trust systems from its Internet accessible networks in the wake of ISS's findings. See Tr. (Hrng., July 25, 2005, AM Sess.), at 30 (testimony of Rolfes). He explained that BLM retained a contractor who performed penetration testing on the connected portion of the network, with encouraging results. See id. at 17-21 (testimony of Rolfes). However, two problems became apparent during the course of the hearing. First, BLM has no plan to reconnect its trust systems to its principal networks in a secure fashion. See id. at 30-31 (testimony of Rolfes). The penetration testing, of course, could not evaluate the security posture of BLM systems with the Trust systems connected; thus the testing results cannot ensure that the vulnerabilities that exposed BLM's trust systems to unauthorized access from the Internet, and there was no evidence to indicate that any testing of the systems against internal threats has been undertaken. Further, and consistent with Interior's pattern, BLM's internal document for tracking the status of vulnerabilities identified by ISS shows a number of vulnerabilities as "fully mitigated" for the sole reason that the system suffering from the vulnerability is currently disconnected from the Internet, and not because the technical issues giving rise to the vulnerabilities have been resolved. See generally Defs.' Ex. 72 (BLM's vulnerability tracking chart); Tr. (Hrng., July 25, 2005, AM Sess.), at 44-47 (testimony of Rolfes). No evidence was produced concerning whether these vulnerabilities would actually be mitigated prior to reconnection, or even that BLM has a workable plan to reconnect its networks securely to the Internet.

The second example was inadvertently provided by Tipton, who was taken by surprise in the midst of a lengthy statement concerning the vigor with which his office has been attacking the problems identified by ISS across all bureaus and offices. See Tr. (Hrng., July 7, 2005, AM Sess.), at 61-65 (testimony of Tipton). He explained that Interior could be sure that, for example, BOR had not been penetrated by hackers prior to ISS's penetration testing because of Interior's department-wide implementation of a fundamental IT security feature. See id. at 65 (testimony of Tipton). He was taken by surprise, however, when confronted with evidence that this security feature is simply missing from one of NBC's two principal networks, which support a number of Interior's trust applications to one degree or another. See id. at 65-66 (testimony of Tipton). He was "concerned," he admitted, when informed that other evidence showed that the missing security feature had been listed as missing, and as a priority for implementation, on the NBC POA & M for a number of years. See id. at 66 (testimony of Tipton). The security feature in question, apparently had simply been overlooked.

More generally, despite the wealth of evidence that Interior s POA & M process is fundamentally deficient, Tipton's response to ISS's findings was typical: "I told [BLM] to get [the specific vulnerabilities] fixed the same as I told USGS, BOR, and the others to get theirs fixed. To get the vulnerabilities on their POA & Ms and get them scheduled as quickly as they can. Sort out the important ones and tell us when they're going to be finished." Tr. (Hrng., July 27, 2005, PM Sess.), at 21 (testimony of Tipton). Tipton's focus is on patching the individual vulnerabilities, despite both Miles' and Brass's emphasis on the fact that the identified vulnerabilities are symptomatic of systemic problems of network-level and application-level architecture and security implementation. ISS's final penetration testing report for NBC warned: "given the nature of potential web application weaknesses discussed in the attached detailed technical report, NBC and the department should not rely solely on corrective action taken in response to the limited scope of testing reported here." Pls.' Ex. 651 (Memorandum from Michael Wood, OIG NSM Group, to Hord Tipton, DOI CIO (July 13, 2005)), Attachment (ISS Final NBC External Penetration Testing Report), at bp. HT_ 7000006. The evidence and testimony indicate, however, that the departmental CIO's office is either unwilling or unable to expand its focus beyond corrective action targeted to the specific vulnerabilities identified.

B. Interior's IT Security Program

The IG's FY 2003 FISMA report noted that Interior had made significant progress in creating an adequate IT security program, especially in light of "almost 20 years of neglecting information system security requirements." See Pls.' Ex. 120 (2003 FISMA Rep.), at bp. DOI_IT0018059. The report continues:

during fiscal year 2003 DOI has undergone monumental change to improve its information security program. These changes[] serve as a springboard for the DOI to ensure that all information and information systems and assets are cost-effectively secure. The Secretary, the Deputy Secretary, the Assistant Deputy Secretary, and the Assistant Secretary for Policy, Management, and Budget have demonstrated strong support in addressing DOI's information security weaknesses.

Id. at bp. DOI_IT0018059-DOI_IT0018060. This new management-level commitment to IT security issues is demonstrated by the Secretary's formal declaration setting IT security as a high priority for Interior; the "[i]ssuance of a Secretarial Order requiring all bureaus and offices to standardize functions within their offices of chief information officer and requiring bureaus with more than 5,000 employees to have [a] senior executive level stand-alone chief information officer[;]" the implementation of a departmental requirement that all bureau and office senior management level personnel be evaluated annually on their efforts to institutionalize Interior's commitment to IT security; and Interior's having initiated or completed implementation of more than half the recommendations included in the IG's FY 2002 GISRA evaluation report. See id. at bp. DOI_IT0018060.

The IG's office also noted the great efforts and accomplishments made by the department-level CIO, who "fulfill[ed] senior management's support" for IT security by "develop[ing] policies, guidance, and practices and design[ing] a methodology to report on bureaus' and offices' improvement progress in safeguarding information systems and in meeting FISMA requirements." Pls.' Ex. 120 (2003 FISMA Rep.), at bp. DOI_IT0018060. As of the end of FY 2003, Interior's CIO had issued policies and guidance in areas that include asset valuation, C & A processes, the creation, maintenance, and securitization of so-called systems "enclaves," security control-self testing in accordance with NIST SP 800-26, network perimeter configuration, conducting privacy assessments on IT systems, and incident response. See id., at bp. DOI_IT0018060-DOI_ 0018061. In addition, the CIO completed "an inventory of information systems operated and maintained by DOI for certification and accreditation purposes[;]" and deployed "the computer-based Interior Validation and Assessment Tool (IVAT), which is based on NIST SP 800-26" and automates the security control assessment portion of the C & A process. See id., at bp. DOI_IT0018061.

The IG also noted Interior's advances in IT security training for its personnel, which had been almost non-existent in previous years. See Pls.' Ex. 120 (2003 FISMA Rep.), at bp. DOI_ IT0018061. New FY 2003 training initiatives included:

[e]nd-user information technology (IT) system security awareness based on Defense Information System Agency computer-based training [for] almost all DOI's employees, contractors, and volunteers who have access to DOI's information systems[;][r]eview courses for IT specialists in preparation for Certified Information System Security Professional examination[;][c]ourses on DOI's certification and accreditation process[;] DOI Executive Information Security Training Session attended by DOI's Assistant Deputy Secretary and CIO and bureaus' and offices' chief information officer staffs[;][and] SANS Global Information Assurance Certification Security Leadership training attended by DOI and bureaus' and office[s'] chief information officer staffs.

Id. Other departmental actions the IG found laudable include increased IT security focus in its capital asset planning process, implementation of SANS/FBI Top 20 vulnerability scanning against Interior's Internet-facing devices, implementation of a semi-annual review requirement for bureaus' and offices IT security programs, imposition on bureaus and offices of a monthly reporting requirement designed to track their progress in implementing FISMA requirements, and the creation of a scorecard-based reporting process for briefing Interior's senior management on the department's progress in implementing the overall IT security program. See id. at bp. OIG_IT0018061-OIG_IT0018062.

In FY 2004, the IG again made note of Interior's progress, although not in as much detail. See Pls.' Ex. 15 (2004 FISMA Rep.), at 3. This is likely because the FY 2003 FISMA review showed that so much progress had been made from such a humble beginning that the progress made in FY 2004 simply seemed less dramatic. Nevertheless, the IG did observe that "DOI has effectively designed its information security management program to meet the requirements of FISMA and continued to improve security over its information systems." Id. Improvements in IT security management practices at Interior that the IG found notable in FY 2004 included imposition of a requirement that "bureaus and offices ... record all systems (major and minor) in the Department Enterprise Architecture Repository System[,]" improvement of Interior's overall inventory of major applications and GSSs, enforcement of NIST SP 800-26 security control reviews for all major applications and GSSs, and creation of a "process for the certification and accreditation of DOI's systems that generally met [OMB] and NIST requirements and [provision of] applicable training on this process." Id. at 26.

Furthermore, FY 2004 saw Interior begin to monitor bureau and office progress in the C & A process and undertake to assess the quality of the documentation produced during C & A; create the "DOI Computer Incident Response Center for bureaus to report information security incidents and for reporting DOI incidents to United States Computer Emergency Readiness Team (US-CERT)[;]" and develop, for the first time, departmental "minimum security configuration standards" for some of the common technologies in use throughout Interior. See Pls.' Ex. 15 (2004 FISMA Rep.), at 26. There can be no doubt that Interior has made substantial progress in implementing a comprehensive departmental IT security program in a very short time — it was only three years ago that Diann Sandy described Interior's C & A process as either nonexistent or, in the case of the one C & A policy she found, "broken and not implemented." See Pls.' Ex. 125 (email from Kamela White, OMB, to Stephen King, DOI OCIO, Subject: "Re: DOI Comments on DRAFT FY 2002 GISRA Report and DOI Summary", May 6, 2003), Attachment (email from Stephen King, DOI OCIO, to Kamela White, OMB, Subject: "DOI Comments on DRAFT FY 2002 GISRA Report and DOI Summary", May 2, 2003), at bp. DOI_OIG_IT0023724.

Unfortunately, as the evidence has demonstrated, severe and sometimes catastrophic problems remain. Certification and accreditation documents have been found to be incomplete, or sometimes missing entirely, resulting in the decertification of systems. The most critical IT security process, the departmental POA & M program, is currently broken, resulting in uncertainty both as to the nature and number of weaknesses in IT systems, and as to whether and to what extent known weaknesses have been corrected. Interior has not implemented a coherent policy to ensure that wireless networking devices do not compromise the security of wired networks. Interior has not even begun to fulfill its responsibility to ensure that its systems and data housed on private contractor networks are adequately secure in accordance with OMB and NIST requirements. System inventories are incomplete, IT security training is inadequate, and mission-critical systems lack essential, fundamental technical controls.

i. Security from Internet-Based Threats

Departmental CIO Tipton admitted that Interior has a systemic problem with both web-application and network perimeter security, as revealed by ISS's stunningly successful penetration tests. See Tr. (Hrng., July 26, 2005, PM Sess.), at 63-64 (testimony of Tipton) (explaining that "[web] application security is vitally important"); Tr. (Hrng., July 27, 2005, AM Sess.), at 46-47 (testimony of Tipton) ("Q: Is it fair to say that, based on everything you saw, through the pen testing, that you had a systemic problem with network perimeter security? A: We had all indications that there was a systemic problem.... Q: `Systemic' meaning its serious enough to affect the whole system. Is that what you understand it to mean? A: Yes.... Yes it becomes serious."). Perhaps most importantly, department-level IT managers seem incapable of ensuring the implementation of IT security policies on the one hand, and recognizing fundamental, systemic flaws in those policies on the other. Tipton himself testified that he often finds that his IT security policies have not been fully implemented by Interior's bureaus and offices, and wondered why that seems unusual. See Tr. (Hrng., July 26, 2005, PM Sess.), at 62 (testimony of Tipton) ("Q: And that's something you find quite often, that you put out a policy and you discover people don't implement that policy? A: Isn't that true with the rest of the world? Nothing unusual about that.").

The IG pointed out in a 2003 report that "[t]he Department of the Interior ... needs to take charge of its Web presence... to: ... [c]ontrol the current unmanaged growth of Web sites; ... [r]educe security risks; ... [and][c]omply with Federal requirements such as those governing privacy [.]" Pls.' Ex. 126 (document entitled "U.S. Department of the Interior, Office of Inspector General, Evaluation Report: Moving to a Customer-Centered Web Presence" (Report No. 2003-I-0051, June 2003)), at bp. DOI_OIG_IT0016456. Almost clairvoyantly, the 2003 report observed that:

DOI does not have adequate security to safeguard its Web presence and its networks. We ascribed this condition to the lack of uniform Web security policies, procedures, and controls and the lack of standard configuration management. This increases DOI's security risks. For example, we found that: ... [i]ndividuals could identify network devices from the Internet ... increas[ing] the ability of individuals to compromise these devices and obtain unauthorized access to DOI's networks[;] ... Web sites maintained by or for third parties did not have adequate security safeguards[,][as] DOI has no specific policy or control technique for outsourcing or hosting Web sites [;] ... DOI was posting sensitive information on its Web servers [;] ... Numerous types of Web server software with various versions and updates were operating throughout DOI[,] ... increas[ing] the risk to DOI networks because known vulnerabilities in older versions of the software may not have been mitigated.

Id. at bp. DOI_OIG_IT0016461-DOI_OIG_IT0016462. As ISS's penetration test results show and Tipton admits, most of these Web-presence problems remain, to this day, unresolved. See Tr. (Hrng., July 27, 2005, AM Sess.), at 10-15 (recalling having read the IG's Web presence report, explaining that "we continue to plug away" at mitigation of Web-related problems).

Indeed, Tipton was taken aback by the degree of weakness in Interior's Internet related IT security that the ISS penetration testing revealed, as he made clear in an email to his Web applications and Web presence manager, Thomas McClay:

The IG penetration testing is demonstrating that web services are our major security threat and the bureaus are just not dealing with this problem in a consistent manner. Most don't even know they have a problem! As more and more business is conducted over the web, this problem becomes larger and the imperative for enterprise management is unavoidable. We are finding many web applications improperly developed and maintained. Until we get a handle on this, it keep[s] us in an insecure state internally.

Pls.' Ex. 642 (string of emails including email from Hord Tipton, DOI CIO, to Thomas McClay, DOI CIO's Office, Subject: "Re: READ AHEAD BRIEF FOR WEB FUNDING ISSUES MEETING" (Apr. 17, 2005)), at bp. DOI_CIO_0033364. "I said it pretty straight, didn't I[,]" Tipton observed. Tr. (Hrng, July 27, 2005, AM Sess.), at 11 (testimony of Tipton). Daud Santosa, Tipton's Chief Technology Officer ("CTO"), observed that many of the problems identified by ISS have to do with the current lack of "layering" of security controls in the architecture of the networks supporting the vulnerable web applications:

The issues are not only the web services. Most of the current applications were not developed with the best practices of layering architecture. We do need to develop the policy of which information that can be placed in the [network demilitarized zones ("DMZ")]. In addition, any `self service' applications must follow the layering architecture that I have been promoting over and over again. In order to validate [its] architecture, we need to have the infrastructure ... developed passed on the right layering architecture.... We do currently have a lot of projects that need the portal solution such as IMARS, OS Portal (Web consolidation), Trust DMZ, etc. We need to consider looking at across the department any funding that [is] available to start building this infrastructure so that we can start migrating the current web applications into it. Without the availability of the target infrastructure we will not be able to migrate the applications into it.

Id. (email from Daud Santosa, DOI CTO, to Hord Tipton, DOI CIO, Subject: "Re: READ AHEAD BRIEF FOR WEB FUNDING ISSUES MEETING" (Apr. 17, 2005)), at bp. DOI_CIO_IT0033363. Tipton explained that he has asked Santosa "to develop ... a layered security approach with patterns across the board for all of the Interior web applications," but acknowledged that "[i]t's a big project [,][i]t's taking some money, and we are making incremental progress on it ... we are not there yet." Tr. (Hrng., July 27, 2005, AM Sess.), at 13 (testimony of Tipton).

ii. Certification & Accreditation of Interior's IT Systems

The IG's FY 2002 GISRA evaluation report to OMB indicates that of Interior's 224 identified systems, 19 were "authorized for processing following certification and accreditation" in FY 2001. See Pls.' Ex. 123 (2002 GISRA Rep.), at bp. DOI_OIG_IT0016766. In FY 2002, that number rose to 49 of 224 systems, or roughly 22 percent, that had been certified and accredited in accordance with OMB guidance. See id. The IG's FY 2003 FISMA evaluation report, however, noted that "[o]f the 167 DOI-inventoried information systems, 6 percent were certified and accredited." See Pls.' Ex. 123 (2003 FISMA Rep.), at bp. DOI_IT0018067. As of March 2004, Tipton indicated, Interior had certified and accredited 21 percent of 158 identified systems. See Pls.' Ex. 658 (collection of documents), at bp. DOI_IT0068211 (memorandum from Hord Tipton, DOI CIO, to Directors of Bureaus and Offices, Subject: "Certification & Accreditation Update" (May 3, 2004)) ("2004 CIO C & A Memo. 1"); see also Tr. (Hrng., July 28, 2005, AM Sess.), at 77 (testimony of Tipton).

Tipton's May 2004 C & A guidance explains that OMB had "signaled that, in support of the President's Management Agenda, federal agencies must have 80% of their systems fully accredited by July 2004." Pls.' Ex. 584, at bp. DOI_IT0068211 (2004 CIO C & A Memo. 1). Interior "will be able to meet Executive requirements as well as changes to national policy on C & A activities [,]" Tipton instructed, "by accelerating its accreditation of legacy information technology (IT) systems." Id. More specifically, Tipton advised the bureaus and offices:

Given DOI's improved operational security posture, DOI's Chief Information Officers (CIO)s, who act as bureau certifiers, are in an excellent position to make accrediting recommendations to their respective DAAs for a large base of legacy IT systems. Certifiers should begin by identifying those systems that have been secured through the IATO methodology and use the existing Plans of Actions & Milestones (POA & M) process to identify, prioritize, manage, and track the work that remains. Certifiers must work closely with their DAAs to help DAAs understand the risks that remain, their remediation schedule, any residual risks that will need to be accepted and the life cycle resources, both human and capital, that will be required to grant the legacy system full accreditation. Once the system risk is understood and funding commitments are made, DAAs should consider granting full accreditation to all legacy MA and GSS as soon as possible.

Id. at bp. DOI_IT0068212. Mahach, who was still Interior's DITSM at the time, testified that the CIO's office implemented this "rush" C & A schedule primarily so that Interior could represent to OMB and Congress that all of its high-impact IT systems had been certified and accredited by the end of FY 2004. See Tr. (Hrng., June 13, 2005, PM Sess.), at 77-78 (testimony of Mahach). Cason explained that the C & A process for Indian trust systems was originally scheduled for completion by December 31, 2005. See Tr. (Hrng., July 19, 2005, AM Sess.), at 70 (testimony of Cason); Pls.' Ex. 587 (extract from document entitled "Status Report to the Court Number Thirteen" (May 1, 2003)), at 11 ("Interior's Indian trust IT systems, i.e., those systems identified as supporting trust business processes, are scheduled to achieve C & A compliance by December 31, 2005."). This process was accelerated by some eighteen months, Cason recalled, because Interior wanted to both better its OMB IT security scorecard results for FY 2004 and comply as fully as possible with the Consent Order entered in this case in December 2001. See Tr. (Hrng., July 19, 2005, AM Sess.), at 71 (testimony of Cason). Tipton observed, "I'm not sure we made it in 2004. I think we had 83 percent. I guess we did make it." Tr. (Hrng., July 28, 2005, AM Sess.), at 79 (testimony of Tipton).

Mahach noted that a number of meetings were conducted with bureau and office CIOs concerning the accelerated C & A process, and stated "I don't recall a single meeting where any CIO said they would not meet that [July 31, 2004] date." Tr. (Hrng., June 13, 2005, PM Sess.), at 79 (testimony of Mahach). Unfortunately, Interior would soon discover that many of the C & A packages generated by the bureaus and offices in order to comply with the newly imposed deadline were inadequate. See id. at 79 (testimony of Mahach) (indicating that "the CIO's office in their quality assurance reviews found some Certification & Accreditations that were lacking"). Nevertheless, it was the CIO's promise to implement that quality assurance process that motivated the IG to rate Interior's C & A process as "satisfactory" in the FY 2004 FISMA report, despite observing that "12 of the 19 systems [that were reviewed and that were certified and accredited] did not have risk assessments that fully met NIST SP 800-30 guidance, only 16 of the 19 systems had contingency plans, and only 10 of those plans had been tested." See Pls.' Ex. 15 (2004 FISMA Rep.), at 21.

On July 23, 2004, Tipton, "concerned about the quality and adequacy of C & As being completed to meet DOI's goals[,]" see Pls.' Ex. 204 (document entitled "Assignment Workpaper, Subject: DOI CIO Comments on C & A," prepared by Diann Sandy, NISO (July 23, 2004)), at bp. DOI_OIG_IT0028297, emailed the following guidance to a substantial number of the IT staffs of the bureaus and offices:

[P]reliminary reviews of the C/A products indicates a significant disparity in the interpretation of the guidance provided May 3, 2004 on certifying and accrediting our systems. Please review the guidance; and assure that you have not simply converted an IATO into an accreditation. The IATO is a strong starting point, but on it[s] face in many cases is not sufficient for an accreditation. The reviews show some of you are accrediting without contingency plans and incomplete risk analyses; several have not done the final vulnerability scanning and control checks as part of the Security Test and evaluation, some do not even have a System Security Plan. Some of you are trying to certify subject to technical feasibility and available funding. This is unacceptable.... The only thing worse than not getting the accreditations completed on time is not doing appropriate accreditations!

Id., Attachment, at bp. DOI_OIG_IT0028298-DOI_OIG_IT0028299 (email from Hord Tipton, DOI CIO, to a number of bureau and office IT staff, Subject: "Re: Certification and Accreditation of Interior Systems" (July 23, 2004)). Sandy explained that the IG's office found these inadequacies in the C & A documentation during FISMA review activities, see Tr. (Hrng., June 2, 2005, PM Sess.), at 81 (testimony of Sandy), as Interior's CIO-directed C & A quality assurance program was not yet in existence.

Despite Tipton's guidance, the C & A packages submitted by several of Interior's bureaus and offices were found to be substantially inadequate upon review in early 2005, requiring that the systems for which the documentation was compiled to be returned to IATO status until the problems could be resolved. See Tr. (Hrng., July 13, 2005, PM Sess.), at 79-84 (testimony of Mahach); Tr. (Hrng., July 28, 2005, PM Sess.), at 10-15 (testimony of Tipton). At BIA for example, twelve systems had defective C & A documentation that required that the systems be returned to IATO status. See Pls.' Ex. 313 (memorandum from Hord Tipton, DOI CIO, to David Anderson, Assistant Secretary of Indian Affairs, Subject "Re-Accreditation of Bureau of Indian Affairs Information Systems" (Jan. 26, 2005)) ("CIO's BIA C & A Mem."), at bp. OIGMWE_ 0000898. Tipton explained in a memorandum on the subject that:

twenty-four C & A packages from BIA were reviewed in September 2004. These reviews identified various discrepancies with the standards established in Department guidelines.... While BIA C & A packages are substantially complete, some discrepancies rise to a standard of concern to remove them as a basis for valid accreditation decisions. Recent detailed review of required actions indicate most discrepancies can be resolved within 30 days of this memo. But the integrity of the Department C & A program requires appropriate oversight and status until those issues are addressed.... I recommend that you remand the accreditation status of the following twelve systems to interim authority to operate (IATO) with a 45-day expiry:... DOCSTAR[,] [FTT,] GLAD[,] GPRO GSS [,] KEYFILE[,] PROTRAC[,] LRIS[,] MAD[,] NADCAP[,] NIMS[,] NIOGEMS[,] RDRS[.]

Id. A number of the BIA systems that had to be de-accredited, including LRIS and NIMS, house or access Indian trust data. Each of the decertified BIA systems is a Trust system. See Tr. (Hrng., June 17, 2005, PM Sess.), at 35 (testimony of Brian Burns, BIA CIO). Mahach was surprised that BIA had done such a poor job with the C & A documentation for its Indian Trust systems, because "in many ways the Trust systems kind of took over all the security program ... it was almost as if they were doing everything for the Trust systems.... So I was very surprised." Tr. (Hrng., June 13, 2005, PM Sess.), at 90 (testimony of Mahach). These BIA systems have been since re-certified and accredited. See Tr. (Hrng., June 17, 2005, PM Sess.), at 37-38 (testimony of Burns).

Tipton issued a similar memorandum de-accrediting BLM's Automated Fluid Minerals Support System ("AFMSS") due to "discrepancies" in the C & A documentation uncovered in the CIO's quality assurance review. See Pls.' Ex. 314 (memorandum from Hord Tipton, DOI CIO, to Rebecca Watson, Assistant Secretary of Land and Minerals Management, Subject: "Re-Accreditation of Bureau of Land Management Information System" (Jan. 27, 2005)), at bp. OIGIT_ 00156445. After the decertification of AFMSS, BLM's CIO Ronnie Levine decertified 11 other systems within BLM's Minerals, Realty, and Resource Protection division. See Tr. (Hrng., June 27, 2005, PM Sess.), at 58-67 (testimony of Levine); Pls.' Ex. 390 (Memorandum from Ronnie Levine to Thomas Lonnie, Subject: "Recission of Certifications for the Land and Resources Project Office [("LRPO")] IT Programs" (Jan. 25, 2005)) (rescinding these certifications "given the circumstances" of the discrepancies identified in the C & A documentation for AFMSS); see also Tr. (Hrng., June 27, 2005, PM Sess.), at 70 (testimony of Levine) (indicating that AFMSS is the LRPO's IT portfolio).

However, the quality assurance review program does not involve examination of validity of the representations made in the bureaus' and offices' C & A documentation. Rather, Mahach explained, "they have a qualitative check sheet that they review the documentation against the grading criteria, and they evaluate it based on that." Tr. (Hrng., May 24, 2005, PM Sess.), at 81 (testimony of Mahach). Cason explained that the contractors conducting the C & A package review were only asked to "look at the adequacy of the documentation and make sure that all of the pieces were there and that they were there in reasonable detail and quality." Tr. (Hrng., July 20, 2005, AM Sess.), at 47 (testimony of Cason). In other words, the statements in the documents are taken at face value; the documentation is reviewed for internal consistency and completeness, rather than accuracy. The actual representations made in the documents are not evaluated for accuracy. What's more, C & A packages that are identified as defective are remanded for revision to the bureau or office where they were prepared. There is no mechanism to address problems in the bureau or office C & A process that discrepancies in the written product might evince, or even to determine the nature of such process-problems. The Court finds this quality assurance process shallow, unlikely to identify the root problems that contribute to deficient C & A packages, and, at best, incomplete.

iii. Security from Internal Threats; Contractors, Tribes and Other Third Parties Accessing Interior's IT Systems

Mahach testified that the greatest threats to IT security arise internally — that is, from individuals who already have some level of access to Interior's systems, such as employees, contractors, or Indian Tribes, who might use that access to gain control of Interior's various assets. See Tr. (Hrng., May 19, 2005, AM Sess.), at 49-50 (testimony of Mahach); see also OMB Circular A-130, Appx. III (noting that often the greatest threats to the security of IT systems come from "authorized individuals"). Phil Brass also indicated that internal threats are more serious than external threats. Brass explained:

[E]mployees represent a significant risk ... if they're not properly vetted and put in positions [relative] to the amount of trust they should be accorded. [I]t is ... very common practice to present to the Internet a hardened network with few services, and what you might consider to be a small attack surface.... [Intranets] almost universally do not have hardening done. There's no reduction of surface area. Most of the machines are fully exposed with maybe certain networks defined so that the networks themselves have limited access between networks, but within networks they tend to be very open and not well locked down because of the expertise involved in locking down every single computer in an organization.... Once you get on to one inside computer; it's frequently the case that it's not difficult to get on to others.

Tr. (Hrng., May 6, 2005), at 96-97 (testimony of Brass). Or, as he also characterized the internal/external network security distinction, "[h]ard crunchy outside, soft creamy inside, that's the network of today." Id. at 78 (testimony of Brass). The ease with which Brass was able to move from server to server once he had penetrated the Internet-facing perimeter of NBC's network illustrates the "soft creamy" character of that network's internal architecture. The lack of emphasis on securing Interior networks against internal threats demonstrated even by the admittedly narrow and limited results of ISS's penetration testing is cause for concern.

Mahach recommended security testing to evaluate internal threats, "for the sensitive systems ... maybe once a month." Tr. (Hrng., June 10, 2005, PM Sess.), at 70-71 (testimony of Mahach). Mahach clarified that "it doesn't have to be a full penetration test [each month, but] the sensitive systems would benefit from closer scrutiny." Id. at 71 (testimony of Mahach). Full penetration testing to evaluate internal threats, he emphasized, should be performed at least "once or twice a year," but preferably "every quarter." Id. (testimony of Mahach). Penetration testing against internal threats is among the tasks listed in the NSM framework developed for the IG's FISMA evaluations from FY 2005 going forward; it is not currently underway, and there are presently no concrete plans for implementation. See Tr. (Hrng., May 24, 2005, PM Sess.), at 54-56 (testimony of Mahach) (indicating that the internal penetration testing specified in the IG's rules of engagement for FY 2005 FISMA testing has not begun). Indeed, Mahach explained that the majority of the tasks set to be performed by ISS, including testing for vulnerabilities to internal threats, were made optional rather than mandatory and made contingent on the availability of funds in future IG budgets. See id., at 48-51 (testimony of Mahach).

But to truly secure Interior's IT systems, internal threats must be evaluated and mitigated, which requires, at the very least, a more comprehensive testing program. See Tr. (Hrng., June 10, 2005, PM Sess.), at 85-86 (testimony of Mahach). Among other things highlighted by the IG's evaluations over the last three years, Mahach emphasized that either Interior or the IG should conduct a separate test of Interior's password security, "which means that if there is a password file associated with a sensitive system, you would retrieve that password file and you would run it through certain tools to see if it complies with security policies, and if there's any weak passwords or vulnerabilities in that area." Id. at 85 (testimony of Mahach). Additionally, as was underscored by NISO's wireless evaluation report, physical security surrounding Interior's IT assets needs more testing. Mahach explained that "I would do them in two ways .... The first is what would be known as a red team, which is with no knowledge, and you try to break into the facility.... And trying to get in that way and see how far you could go.... And then almost immediately after that you would do a physical security assessment, where we would agree [with the Bureau or office] that, say, on Wednesday we would be coming there, but we would start the red team on Monday, so that if we got anywhere, we could have that information on Wednesday." Id. at 85-86 (testimony of Mahach). For sensitive systems, Mahach advised that this kind of physical security assessment be performed annually. See id. at 86-87 (testimony of Mahach). The concern with internal threats is not an idle one, as Mahach explained his personal familiarity with at least two incidents of computer fraud by Interior employees in 2004, which resulted in theft of substantial sums of money. See Tr. (Hrng., May 19, 2005, AM Sess.), at 51-54 (testimony of Mahach); see also Pls.' Ex. 61 (email from Roger Mahach, OIG NSM, to Roger Montoya, Asst. IG, Investigations (Jan. 4, 2005)) (detailing these incidents).

Unfortunately, Cason explained that he is "not aware of any testing that [Interior has] done of contractor systems ... [or] of tribal systems" that house or access IITD. Tr. (Hrng., July 18, 2005, PM Sess.), at 25-26, 29 (testimony of Cason). Of course, Cason's lack of awareness does not show that, in fact, no security testing of third party systems has been performed. But it does tend to support the proposition that securing third-party systems that access Interior's IT assets is not a priority within the departmental IT security program. This lack of priority exists despite repeated urging by NISO and the IG. The departmental attitude, at least as displayed by Cason, seems to be that security for IITD on third party systems is not one of "the things that make the biggest difference." Id. at 29 (testimony of Cason). Indeed, Interior currently does not even have a comprehensive inventory of third-party systems that access Interior's data or systems. See id. at 27 (testimony of Cason). This complete lack of security awareness and policy regarding third-party system access poses grave risks to the confidentiality, integrity, and availability of IITD on Interior's IT systems, and thus is of grave concern to the Court.

Related to the issue of third-party access to systems or data housed on Interior's IT networks are security concerns that arise when Interior's applications and other systems are hosted on networks maintained and secured by third parties. It is beyond peradventure that FISMA requires Interior to provide an equal level of security for its IT assets, even when they are housed on systems or networks owned by private contractors or Indian tribes. See Tr. (Hrng., May 24, 2005, PM Sess.), at 88 (testimony of Mahach); Tr. (Hrng., July 28, 2005, AM Sess.), at 59-60 (testimony of Tipton). It is similarly well established that Interior, at present, has not incorporated evaluation of third-party systems housing Interior IT assets into its overall IT security program. See, e.g., Tr. (Hrng., July 18, 2005, PM Sess.), at 25-29 (testimony of Cason). For example, contractor and tribal systems were not included in the scope of the IG's FY 2005 external penetration testing program. See id. (testimony of Mahach) ("Q:... [A]re you doing any pen testing, the OIG's office, either [as] part of the NSM task or any other parts of the OIG office doing any pen testing of contractors, tribes, or other agents that are maintaining computer systems on behalf of the federal government? A: I don't believe we are, sir.").

Nor are Interior's procedures for contracting for these IT hosting services consistent with best practices for IT security. OMB noted in its FY 2002 GISRA report that Interior "did not ensure that program officials included the appropriate language in contracts for IT operations and software development and maintenance." Pls.' Ex. 123 (2002 GISRA Rep.), at bp. DOI_OIG_IT0016773. Tipton testified that he saw this report and was aware of this problem in 2002. See Tr. (Hrng., July 28, 2005, AM Sess.), at 51 (testimony of Tipton) (conceding he's known of this problem since late 2002 or early 2003); Pls.' Ex. 655 (string of emails including email from Roger Mahach, DOI DITSM, to Delia Emmerich, DOI OS, copy to Hord Tipton, DOI CIO, Subject: "IT Security in Contracts" (Jan. 22, 2003)), at 2-3 ("DOI has been found to have inadequate IT Security language in its contracts as well as inadequate procedures for reviewing outsourced services."), id. (email from Roger Mahach, DOI DITSM, to Debra Sonderman, DOI CIO's Office, copy to Hord Tipton, DOI CIO, Subject: "Re: IT Security in Contracts" (Jan. 23, 2003)), at 1 ("The findings were in the IG's annual review of the DOI IT Security program, REPORT NO. 2002-I-0049, September 2002."). Today, Interior's contracts with third parties related to hosting Interior IT systems, and establishing interconnections between Interior and contractor systems, continue to lack language that imposes security requirements and testing procedures on third parties. Tipton acknowledge that, despite being notified of the contractor problem nearly three years ago, Interior has "a number of things to work out with contractors to get in compliance with what we would look at as a perfect C & A." Tr. (Hrng., July 28, 2005, AM Sess.), at 49 (testimony of Tipton). Mahach explained that, over a period of years, the departmental CIO developed a policy requiring bureaus and offices to take responsibility for assessing the security of contractors' systems, which was issued in late 2004. See Tr. (Hrng., June 13, 2005, AM Sess.), at 30-33 (testimony of Mahach). However, Mahach was unwilling to say that the bureaus and offices are currently complying with the policy, and again emphasized that, regardless of what the bureaus and offices might have done, there had been no security testing of contractor systems conducted at the departmental level. See id. at 34-35 (testimony of Mahach).

Finally, the Court finds that Interior does not have specific, effective policies or procedures for securing Interior's IITD or other IT assets that are housed on or accessed by systems maintained by Indian tribes. It is beyond dispute that Interior knows it is responsible for the security of IT systems, electronic data, and especially Indian trust data, housed, maintained, or otherwise accessed by Indian tribes under contracts, compacts, or other cooperative agreements. See Pls.' Ex. 656 (Memorandum from Hart Rossman to John Leshy, DOI Solicitor's Office (Nov. 28, 2000)), at 7. Substantial amounts of IITD as well as some of Interior's Trust systems are housed on tribal systems. See Tr. (Hrng., July 28, 2005, AM Sess.), at 59-61 (testimony of Tipton). And, Interior's own Solicitor's Office has made clear that:

[T]he Secretary cannot contract or compact away [to Indian tribes] responsibilities which are inherently federal; those vested in him by Congress and determined by federal courts not to be delegable. As discussed above, the Self-Determination Act anticipates the continued exercise of federal trust responsibility in the context of tribal contracting and compacting; the Cobell Court has made clear that accurate recordkeeping is a key element of this trust responsibility. While the exact nature of the Secretary's trust management responsibilities is not pellucid, it is apparent that discharge of his obligations to serve both tribes and individual Indians could be severely hampered if he did not require adherence to consistent, nation-wide standards and procedures with respect to trust records.

Id. Interior is also clearly aware that FISMA requires that tribal systems housing or accessing Interior's IT assets must be included in IT security evaluations. See Pls.' Ex. 384 (Memorandum from Erich Hart, Associate General Counsel, to Roger LaRouche, AIG for Audits, Subject: "Scope of Annual Federal Information Security Management Act Information Technology Security Evaluation" (Nov. 22, 2004)) (answering in the affirmative the question "[w]hether [FISMA] requires the Office of Inspector General to include the [IT] systems used by tribes to operate DOI programs under Indian Self-Determination and Education Assistance Act annual funding agreements or contracts, during its annual evaluation of [Interior's] IT security program").

Despite Tipton's testimony that Interior is responsible for the security of Interior's IT assets housed on third-party systems in general, see Tipton Dep. at 238; see also Tr. (Hrng., July 28, 2005, AM Sess.), at 61 (testimony of Tipton), the departmental CIO's office continues to take the position that FISMA does not apply to Interior's IT assets housed on tribal systems. See Tr. (Hrng., July 28, 2005, AM Sess.), at 69-70 (testimony of Tipton). Brian Burns, BIA's CIO, echoed this position: "I've been told" that ensuring adequate security for IITD housed on or accessed by tribal IT systems "is no[t] our responsibility at this point in time.... [T]hat is the responsibility of the tribe or the ... entity that" has the IITD. Tr. (Hrng., June 16, 2005, AM Sess.), at 51 (testimony of Burns). Tipton explained the rationale for this position in an email to Joel Hurford: "It will be a nightmare if we can't demonstrate we have no responsibility for things in [tribal] computer systems." Pls.' Ex. 657 (email from Hord Tipton to Joel Hurford, Subject "Potential Meeting on 638 Contracts" (Dec. 20, 2004)). Tipton, like Cason, admitted that he is unaware of any security testing of tribal systems housing IITD or trust systems performed by Interior. See Tr. (Hrng., July 28, 2005, AM Sess.), at 70 (testimony of Tipton).

iv. Security of Individual Indian Trust Data on Interior's IT Systems

All of the security processes detailed above threaten, directly or indirectly, the confidentiality, integrity, and availability of individual Indian Trust data. As Cason explained, IITD in one form or another permeates Interior's IT environment fairly completely, see Tr. (Hrng., July 18, 2005, PM Sess.), at 79-81 (testimony of Cason), and Interior has made no effort to segregate IITD onto a more secure network, see Tr. (Hrng., July 19, 2005, AM Sess.), at 68 (testimony of Cason), because the resources that such an effort would require are simply not available. See Tr. (Hrng., July 18, 2005, PM Sess.), at 75-77 (testimony of Cason). Interconnections Between Interior's IT Systems — The pervasive presence of IITD in varying forms, amounts, and sensitivity levels in virtually every Interior bureau or office, combined with the operation of Interior's network "backbone" (the virtual private exchange or "VPX"), means that vulnerabilities in the security of any one bureau or office threaten the security of IITD throughout Interior. To be sure, security tests have been performed on the VPX, and some improvements have been made, see Tr. (Hrng., July 7, 2005, AM Sess.), at 29-39 (testimony of Stuart Mitchell, Interior's Enterprise Services Network ("ESN") manager, which now manages the newer version of Interior's network "backbone") (describing the creation of a security policy for the VPX, as well as security testing performed on the VPX in June, 2003), but problems remain. The VPX simply creates another set of access points that must be secured. See id. at 29-30 (testimony of Mitchell) ("the VPX `provided a known pathway to exchange information between bureaus, a network connection pathway'"). What's more, the VPX magnifies internal as well as external threats, as it allows transmission of data and access to systems from bureau to bureau without accessing the Internet. See id. at 30 (testimony of Mitchell). An Interior employee with access to the MMS network only, for example, might be able to access BLM systems through the VPX, depending on the circumstances.

The Court finds that Interior's use of a network "backbone" means that IT security vulnerabilities present on any system at any Interior bureau that increase the potential for unauthorized access to that system create a substantial risk of unauthorized access to any other system attached to any of Interior's networks. "The current DOI network infrastructure has a junction point called the virtual private exchange [("VPX")] through which all bureaus communicate with each other and to Departmental systems .... As a result of this `open' architecture, any DOI bureau can be used as an entry point into any other bureau, including NBC's [sensitive] systems and Indian trust data." Pls.' Ex. 231 (Memorandum from Dominic Nessi, CIO of NPS, to Interior's Director and Deputy Director for External Affairs, Subject: "December — Monthly Information Technology Update" (1/7/2003)), at bp. DOI_IT0057678 (also indicating that, as of the time of this memo, NPS was connected to the VPX). Because the existence of the VPX requires bureaus to defend not only against external penetration attempts but also threats posed by possible unauthorized access to other, less secure bureaus' systems, "other bureaus have always balked about" having a network backbone. See Tr. (Hrng., June 6, 2005, AM Sess.), at 42 (testimony of Sandy).

To be sure, the "old" VPX has been upgraded, and additional firewall devices have been placed around all points of access to the "backbone." See Tr. (Hrng., July 7, 2005, AM Sess.), at 34-37 (testimony of Mitchell) (describing the additional firewalls). Indeed, Interior's network backbone is now integrated into an existing system run by a private contractor. See id. at 38-39 (testimony of Mitchell). It is unclear whether Interior takes any active role in securing the backbone now that its maintenance has been contracted out. At least, it seems that the so-called "disconnected bureaus," BIA, OST, the Solicitor's Office, and the Office of Hearings and Appeals ("OHA"), are not allowed to connect to this interface.

In addition to moving management of its network backbone offsite, Interior is in the initial phases of developing the ESN, which will be a "single [,] consolidated wide-area network for the entire department." Id. at 40 (testimony of Mitchell). The ESN is run by Interior's newly established Enterprise Services Center ("ESC"), one component of which is the Network Operations Security Center ("NOSC"). See id. at 39-41 (testimony of Mitchell). The NOSC is intended, among other things, to monitor all connections from Interior's networks to the Internet. See id. at 41 (testimony of Mitchell). The ESN is meant to provide additional security for the contractor-maintained VPX, to consolidate Interior's internet points of presence ("POPs") from thirty-three to five, and to provide centralized security monitoring services for connections from bureau and office networks to the internet. See id. at 42-45 (testimony of Mitchell). ESN, on completion, is designed to effectuate a "full consolidation of the bureau networks into ESN management, meaning that [the private contractor currently managing the VPX] will manage all of the wide-area network routers for all of the bureaus throughout the department." Tr. (Hrng., July 7, 2005, PM Sess.), at 24 (testimony of Mitchell).

The intranet portion of the ESN program, under which it is intended that, eventually, the department will control and manage all routers providing for connectivity between Interior's individual bureau and office networks, remains incomplete. See Tr. (July 7, 2005, PM Sess.), at 24-25 (testimony of Mitchell). And thus far, only BLM receives the internet security portion of ESN's program package. Delays in completion of both these phases are the result of problems implementing the complicated architecture called for by the objectives of the ESN project. See Tr. (Hrng., July 7, 2005, AM Sess.) at 45-47 (testimony of Mitchell); Tr.(Hrng., July 7, 2005, PM Sess.), at 25-26 (testimony of Mitchell). While the ESN has been subjected to at least one external penetration test with positive results, see Tr. (Hrng., July 7, 2005, AM Sess.), at 49 (testimony of Mitchell), the security posture of the system with all bureaus and offices connected is presently unknown.

The Court is also concerned about third-party management of the ESN, given the above-described systemic problems with contractor access to and management of Interior's IT systems that continue to plague the department's IT security program. Importantly, even with the implementation of ESN, there are now and will likely continue to be other, independent connections running from bureau to bureau and from bureaus to outside contractors, including at least one independent connection between MMS and a private contractor that manages a major MMS application that houses or accesses sensitive Indian Trust data. See Tr. (Hrng., July 7, 2005, PM Sess.), at 72 (testimony of Mitchell). No evidence was presented to demonstrate that Interior presently secures, or has any policy or plan for securing, these independent connections. Thus, the Court finds on the weight of the evidence that even after full implementation of the ESN, interconnections between Interior's bureaus, offices, and contractors will continue to present a significant risk that unauthorized access to any of Interior's networks or systems could allow traversal and unauthorized access other Interior networks or systems.

Additionally, Tipton testified that there remains confusion within the ESN project about what constitutes an Indian Trust system. See Tr. (Hrng., July 26, 2005, PM Sess.), at 51-53 (testimony of Tipton); Pls.' Ex. 640 (email from Ellen Erickson, USGS BITSM, to Joel Hurford, DOI DITSM, Subject: "ESN Security" (May 11, 2005)), at pg. 3 (reporting on proceedings at recent CTO council meeting: "[f]rom the discussion during this teleconference and the discussion recently at a meeting between USGS and DOI representatives, it seems that the ESN team is operating under a different definition of Trust than we are.... I was not left with the impression that the ESN team understands the issue that was being raised.... The architecture will have to allow for the isolation of Trust hosts from all bureaus that house them. We need to use the same definition of Trust bureau and Trust system for ESN that we are using for the Court."). This is quite troubling, as one principal goal of the ESN program is to provide a segregated, secure network to house Interior's Trust Systems. See id. at 53 (testimony of Tipton); see e.g., Tr. (Hrng., July 7, 2005, PM Sess.), at 19-21 (testimony of Mitchell) (discussing a part of the ESN architecture called the "Trust/Non-Trust Bridge"). Without a single, coherent definition of "Trust system," of course, it will be impossible for Interior to accomplish any meaningful segregation of that data or to design any kind of targeted security programs aimed at fortifying trust systems. Indeed, on this evidence the Court cannot be sure that the current ESN implementation efforts are properly identifying and addressing Trust data and systems rather than leaving large areas of sensitive Trust-related IT infrastructure unincorporated.

Identification/Protection of Electronic Indian Trust Data — Interior demonstrates a stunning lack of management and oversight of IITD in the context of the departmental IT security program. Numerous examples were evidenced during this hearing, one of which is the apparent lack of any standard, department-wide definition of trust data. Without a coherent understanding of what constitutes trust data for the purposes of Interior's fiduciary obligations, it is of course very difficult to identify those IT systems that should be treated as "trust systems," because they house or access IITD, for the purposes of setting priorities within Interior's IT security program. This fundamental confusion may be a cause of Interior's continuing inability to carry out what seems to be the most immediate, commonsense step to security electronic trust data — namely segregating IITD on secure servers separate from Interior's accessible IT networks and systems.

Mahach testified that segregating IITD is not merely a desirable step in Interior's efforts to security IT systems, but an absolutely necessary one. See Tr. (May 12, 2005, PM Sess.), at 34-35 (testimony of Mahach). When the Court asked Mahach why IITD had still not been segregated from Interior's vulnerable systems, he prefaced his response by stating: "Well, sir, I think firstly that from a security perspective, that is the only way to do it. You have to segregate and isolate." Id. (testimony of Mahach). Mahach could not say why segregation had not yet been accomplished. See id. at 35 (testimony of Mahach). Tipton, however, provided some illumination, explaining that although the importance of segregating IITD has been emphasized by this Court and others for more than four years, Interior's IT security planners have discussed segregation "only in concept.... I'm just not aware that we've actually put it down into a formalized, written plan." Tr. (Hrng., July 26, 2005, PM Sess.), at 55 (testimony of Tipton). Of course, the ESN is intended to provide additional security for Trust servers, see Tr. (Hrng., July 27, 2005, AM Sess.), at 77-78 (testimony of Tipton), but the basic problem of identifying which systems and data should receive additional protection remains. Tipton confessed that segregating IITD from other Interior systems would help clarify the confusion over what constitutes Trust data. See id. at 55-56 (testimony of Tipton). Of course, this is fallacious reasoning, since Interior cannot possibly segregate IITD without an understanding of what constitutes IITD. Perhaps, then, the problem is beyond Interior's capacity to solve.

Interior's data-sensitivity rating for IITD is also convoluted, and not well communicated to, or understood by, the bureaus and offices. Interior categorizes its data-types into "high," "medium," and "low" risk classifications, represented graphically as a pyramid with "high" risk data-types occupying the top. See Tr. (Hrng., July 19, 2005, AM Sess.), at 23 (testimony of Cason). In this "high risk" upper category, Interior has placed, among other things, IITD, because Interior "as a department, made a decision to place the Indian systems in the high category, not because we had made a firm determination that they represented high risk but to give them priority within the department.... We were moving them along because of our court environment to make sure they got the highest priority done." Id. (testimony of Cason). Though initially the Court was hopeful that the placement of IITD at the pinnacle of the data sensitivity pyramid indicated that Interior was finally beginning to take its fiduciary duties seriously, Cason made sure to clarify that "[i]t wasn't because of a specific evaluation that found [IITD] to be high risk, it was placed [atop the pyramid] because of the litigation environment that we're in, we wanted to make sure that they were accorded priority in our considerations for security." Id. at 24-25 (testimony of Cason). Perhaps this "qualified" classification explains the uniform failure among the bureau, office, and departmental officials to take the potential negative effects on individual Indian Trust beneficiaries of IT security weaknesses into consideration when conducting risk assessments and setting priorities in Interior's IT security program. Cason could not recall ever having mentioned the impact of Interior's IT security deficiencies during any of his frequent meetings with Secretary Norton. See Tr. (Hrng., July 20, 2005, AM Sess.), at 64-65 (testimony of Cason). Indeed, though Mahach attended the vast majority of IT security related meetings in his position as Interior's DITSM, he did not recall a single discussion regarding the impact of Interior's IT security problems on the individual Indians. Not one.

ISS's external penetration testing of BLM, NBC, and MMS showed that unauthorized access to IITD could be had directly in some cases. See, e.g., Tr. (Hrng., May 23, 2005, AM Sess.), at 38-40 (testimony of Mahach) (explaining that his concern over the BLM penetration testing results was heightened by the news that the NILS system, which he recalled to be a trust system, had been accessed); Tr. (Hrng., July 18, 2005, PM Sess.), at 80 (testimony of Cason) (explaining that IITD in BLM systems is in the form of cadastral survey data, which is accessed by the NILS system)^[25]; Tr. (Hrng., July 26, 2005, PM Sess.), at 43-44 (explaining that the IITD in BLM is not stored in the NILS system, but rather in "30 or 40 [other] servers in BLM," and that cadastral survey data is Trust data); id. at 76-77 (testimony of Tipton) (accepting ISS's conclusion that Miles could have accessed trust data on the servers he identified during his penetration of BLM). Also within BLM, Interior's CIO quality assurance review showed sufficient deficiencies in the C & A documentation for AFMSS, a Trust system, to require revocation of its C & A. See Tr. (Hrng., June 27, 2005, AM Sess.), at 53-55 (testimony of Levine, BLM CIO) (discussing AFMSS's failure in the C & A quality assurance review); Tr. (Hrng., June 27, 2005, PM Sess.), at 85-86 (testimony of Levine) (explaining AFMSS is a trust system). AFMSS was recertified in February, 2005. See Tr. (Hrng., June 27, 2005, PM Sess.) at 97. This, of course, is a positive step. However, the evidence suggesting a fundamental, systemic problem in Interior's C & A process, which is uncontested, significantly erodes the Court's confidence that AFMSS is adequately secure even after re-accreditation. There is evidence to support this specific concern as well.

During Tipton's C & A push in mid-2004, Gary Stuckey, the C & A project manager for AFMSS expressed concerns that the "declaration of AFMSS as having a ... `high security' categorization has serious impact on the accreditation, especially in light of the EXTREMELY tight schedule[ ] mandated by DOI." Pls.' Ex. 351 (Stuckey email). The concern was based on the fact that the "high" system sensitivity rating was imposed by Interior based on AFMSS's status as a Trust system rather than on an evaluation of data sensitivity under FIPS 199 guidelines. See id. (Stuckey email). "[T]he high categorization under FIPS publication 199 would require a complete revision of the security self-assessment, system security plan, and all other security documents." Id. (Stuckey email). Scott MacPherson, transmitting Stuckey's concerns to Joel Hurford, explained that:

We fully concur that under previous DOI directions, that AFMSS would be considered as a legacy high-risk system due to processing Individual Indian Trust data as defined in the Cobell v. Norton body of literature.... However, Gary Stuckey... was asked for clarification from your office as to differentiating between what the Department of Interior defines as legacy, that is high-risk[,] systems, and what FIPS/NIST defines as high-security systems. AFMSS would appear to not fit the definition of FIPS/NIST as a high-security categorization, as it does not have any potential result for loss of human life or have any catastrophic impact if it becomes inoperable....

Id. (email from Scott MacPherson to Joel Hurford). Hurford responded by advising MacPherson that he "agree[s] that a FIPS 199 security categorization must apply to your decision to treat AFMSS as a high, moderate, or low-impact system.... DOI may call Trust systems high-risk for non-FIPS 199 criteria, but in the interest of expediency, you should protect systems commensurate with the security categories of FIPS 199." Id. (email from Joel Hurford to Scott MacPherson). Hurford continued:

Thus, while you may be of high interest, visibility, or any other adjective, you are only compelled to apply security controls commensurate with FIPS 199-determined level of impact. You may determine that the loss of AFMSS due to confidentiality, availability, or integrity breaches may result in: 1. continued essential missions limited by serious impact to mission effectiveness; 2. significant but not major financial impact to organizations and individuals; and 3. not foreseeable impact [to] health and safety.... Under such circumstances, a moderate system category and associated controls would be applicable.

Id.

Of course, this reasoning does not take into account the special impacts that a breach of the confidentiality, integrity, or availability of IITD would have on both individual Indian trust beneficiaries and Interior. Interior's fiduciary obligations require it to secure and maintain trust data, such that any loss of trust data carries the additional potential impact of legal liability for breach of fiduciary duty. Intuitively, then, Interior ought to incorporate these additional impacts into its data sensitivity classifications; the departmental policy of treating Trust data and Trust systems as "high risk" by definition seemed to do this. At least for AFMSS, however, it seems that this sensible policy has been disregarded, so that the Court has no assurance that the special status of Trust data is incorporated into even the newly re-approved C & A documents for AFMSS. Further, Cason's testimony, detailed above, that Interior regards the "high security" classification of IITD to be a classification in policy only would support expanding the position that Tipton's office has taken regarding AFMSS to any number of other Trust systems. Indeed, Burns testified to a similar "re-classification" of systems housing or accessing IITD within BIA. See Tr. (Hrng., June 16, 2005, PM Sess.), at 67-76 (testimony of Burns).

The Court is thus concerned that Interior may be presently failing to incorporate its fiduciary obligations to preserve IITD into its IT security policy generally, and into its C & A program specifically. To be sure, certification and accreditation is the standard with which Interior must comply to adhere to OMB's guidance for complying with FISMA. However, the Court cannot accept certification and accreditation alone as sufficient to show that Interior's IT systems are presently adequately secure to comply with Interior's fiduciary obligations as Trustee-delegate for the IIM trust.

More generally, Cason verified that NBC, BOR, MMS, and BLM all contain varying amounts of IITD. See Tr. (Hrng., July 18, 2005, PM Sess.), at 78-84 (testimony of Cason). To avoid the possibility of further compromising the security of these data on Interior's systems, the Court will not describe in detail the networks and applications housing or accessing IITD, or their locations within Interior's overall system architecture. However, the Court finds substantial evidence supporting the proposition that the IT security weaknesses discussed above threaten IITD on a number of networks and systems. See, e.g., Tr. (Hrng., July 28, 2005, AM Sess.), at 20-21 (testimony of Tipton) (noting the continuing absence of a critical security feature from a major NBC network, despite the absence of the feature having been an item on the departmental POA & M for a number of years); Tr. (Hrng., July 27, 2005, AM Sess.), at 65-66 (testimony of Tipton) (same); Tr. (Hrng., July 18, 2005, PM Sess.), at 82-83 (testimony of Cason) (discussing systems housed on NBC networks that house or access IITD); Tr. (Hrng., July 28, 2005, AM Sess.), at 32-33 (testimony of Tipton) (discussing MMS systems housing or accessing sensitive IITD); id. at 36-37 (testimony of Tipton) (discussing Interior's failure to verify security of IITD on MMS systems maintained by third-party contractors, which systems were not subject to ISS's penetration testing). See generally Tr. (Hrng., June 29, 2005, AM Sess.; June 29, 2005, PM Sess.; June 30, 2005, AM Sess.; June 30, 2005, PM Sess.) (testimony of Brown, MMS CIO) (detailing MMS system architecture, security features, and IITD content); Tr. (July 7, 2005, PM Sess.; July 8, 2005, AM Sess.) (testimony of Eckholm, MMS Deputy CIO) (same); Tr. (Hrng., July 12, 2005, AM Sess.; July 12, 2005, PM Sess.; July 13, 2005, AM Sess.; July 13, 2005, PM Sess.) (testimony of Smith, MMS MRM Manager) (same, specifically regarding MRMSS); Tr. (Hrng., July 26, 2005, PM Sess.), at 42-43 (testimony of Tipton) (explaining that MRMSS is a Trust system that interconnects with financial systems at BLM and from which data is transferred to BIA to process royalty payments for trust beneficiaries).

IT Security in the Bureau of Indian Affairs — As ISS's recent penetration testing confirmed, BIA has been, and remains, disconnected from the Internet, mitigating concerns about exposure of sensitive trust systems to Internet based threats. See Tr. (Hrng., June 16, 2005, PM Sess.), at 29-30 (testimony of Burns) (noting that all BIA PC's are disconnected from the Internet except for "the 100 administrative PCs and... the 100 fire PC's that were authorized" by the Court to remain connected). Nevertheless, the state of IT security at BIA requires a moment of consideration for two reasons. First, evidence has been produced showing that BIA has conducted very little, if any, security testing of its IT systems against the kinds of internal threats discussed above. Second, some of the problems identified in BIA's IT security program further underscore the pattern of department-level management and oversight deficiencies that have become themes of the present evidentiary hearing. Two examples the Court found particularly troubling relate to BIA's conversion of its legacy trust systems to the Trust Assets Accounting Management System ("TAAMS") and BIA's response to Tipton's mid-2004 C & A push.

As early as 1999, then-Secretary of Interior Bruce Babbit assured the Court that the conversion of BIA's legacy Trust systems, including LRIS and others, was a ship that had sailed. Stunningly, however, Burns testified that conversion has still not been completed as of the time of this trial six years later. See Tr. (Hrng., June 16, 2005, PM Sess.), at 55, 104-05 (testimony of Burns). Of the two principle TAAMS components or "modules," only one, TAAMS-title, has actually been implemented, replacing the LRIS system. See id. at 55 (testimony of Burns). Other modules, including the so-called "TAAMS-realty," which is designed to replace several of BIA's legacy systems including IRMS, MAD, GLAD, and others, remains in the testing phase. See id. at 55, 104-05 (testimony of Burns). Burns explained that he has been protesting to the department for at least three^[26] years that continuing to operate BIA's legacy systems puts IITD at risk, see id. at 101-04 (testimony of Burns), but that Interior has repeatedly failed to dedicate sufficient funding and personnel to complete the transition. See id. at 101-02 (testimony of Burns). What's more, Burns regards conversion to TAAMS as merely an interim solution; he explained that yet another conversion to a more comprehensive and secure trust-management system will be necessary to adequately secure IITD. See id. at 102-03 (testimony of Burns). "[W]e need to get off these [legacy] systems as quickly as we can." Id. at 102 (testimony of Burns). Burns explained, however, that in its current state of implementation, full conversion to TAAMS will still take another year or more. See id. at 112 (testimony of Burns). The Court is at a loss to understand why, in the face of repeated admonitions from a number of sources, Interior has failed to prioritize and complete the conversion of BIA's legacy systems to TAAMS. All Tipton was able to contribute was the generalization that "the TAAMS system was attempted to launch and really didn't get off the launch pad in the fashion that [the department] wanted." Tr. (Hrng., July 27, 2005, PM Sess.), at 73 (testimony of Tipton). However, the Court finds this problem again indicative of an overall failure of departmental IT-management to place the proper emphasis on compliance with Interior's fiduciary obligations in implementing the department's overall IT security program.^[27]

On a related subject, Burns explained that Tipton's push for certification and accreditation of Interior's IT systems in mid-2004 forced Burns to accredit a number of BIA's legacy systems as having sufficient security to warrant full-ATO status, despite the continued presence of numerous high-risk vulnerabilities on those systems, most of which house or access IITD. See Tr. (Hrng., June 16, 2005, PM Sess.), at 119-122 (testimony of Burns). Burns' considered the CIO's memorandum pushing for certification and accreditation of all systems by July, 2004, to authorize issuance of ATO's on the basis of the mere identification of risk, rather than after informed decisions to accept risks and continue to operate the system as is required by NIST guidance and standing Interior policy. See id. at 123-25 (testimony of Burns); see also Tr. (Hrng., June 17, 2005, AM Sess.), at 5-9 (testimony of Burns) (describing Tipton's directive as a significant shift in departmental C & A policy). Of course, as Burns admitted, when ATO's are issued on the basis of identification, rather than acceptance, of risks, the system is allowed to operate and "the risks are still there." Tr. (Hrng., June 17, 2005, AM Sess.), at 13 (testimony of Burns).

The rushed certification and accreditation of BIA's legacy trust systems, and the corresponding decline in the quality of the documents produced during the C & A process, was reflected in the results of the January, 2005, quality assessment review of Interior's C & A packages conducted by Tipton's contractor. As discussed above, the C & A packages of a dozen or so trust systems at BIA were remanded to the bureau after "discrepancies" were identified in the documentation. See Tr. (Hrng., June 17, 2005, AM Sess.), at 70-71 (testimony of Burns). Burns explained that generally, in the C & A process, "[w]e've been pressured to get them done as quickly as we can, so in doing that, clearly you're not going to have the best product possible by being on short deadlines. The key was, I guess to put it bluntly, we shot for adequacy versus perfection, because that's all we could do within the constraints we had in terms of time [and] budget.... It puts us in a predicament; ... you're damned if you do, damned if you don't. You've got to get it done as accurately as you can within the constraints we're given." Tr. (Hrng., June 17, 2005, PM Sess.), at 66-67 (testimony of Burns). Burns's concerns about the C & A push requiring a sacrifice in accuracy, of course, conflict with Tipton's directive, issued shortly after he shortened the timeframe for completing C & A packages, that the accuracy should not be sacrificed in order to meet the deadline. Apparently, these instructions were not fully and clearly communicated to Interior's bureaus and offices. BIA's legacy systems, though certified and accredited, cannot realistically be said to be adequately secure on the basis of the kind of rational cost-benefit analysis that is supposed to take place in the risk evaluation and acceptance phase of the C & A process.

v. Ongoing Problems

These continuing IT security management "challenges," as Jim Cason insisted on phrasing it, see Tr. (Hrng., July 18, 2005, AM Sess.), at 73 (testimony of Cason), contributed to Interior's disappointing showing in a July 2005 GAO report on the state of governmental IT security. See generally Pls.' Ex. 581 (document entitled "United States Government Accountability Office Report to Congressional Committees, Information Security: Weaknesses Persist at Federal Agencies Despite Progress Made in Implementing Related Statutory Requirements" (Report No. GAO-05-552, July 2005)) ("2005 GAO IT Rep."). The GAO reported that Interior had weaknesses in all five areas of evaluation: access controls, software change controls, segregation of duties, continuity of operations, and agency-wide security programs. See id. at 9. While Jim Cason urged that Interior's "challenges" are no different from those at numerous other government agencies that GAO found lacking in each area, see Tr. (Hrng., July 18, 2005, AM Sess.), at 75-76 (testimony of Cason) ("I would agree that GAO found that ..., like the other 24 agencies here, we have challenges that we have to overcome."); see also Pls.' Ex. 581 (2005 GAO IT Rep.), at 9 (listing as weak in each area, among others, the Departments of Commerce, Defense, Agriculture, Homeland Security, Justice, Labor, Transportation, and Veterans Affairs), he conceded that Interior is the only agency in the GAO report that has the kind of fiduciary duties that Interior does as Trustee-delegate for the IIM trust. See id. at 78 (testimony of Cason) ("Q: And with respect to the various departments here, as you look down that list [in the GAO report], do you see any of these departments[] ... that have trust responsibilities similar to those the Department of Interior has? A: As far as I know, no on has the same responsibilities we do.").

Interior's IT security program remains to this day, as Mahach opined, a disorganized and broken management structure that is not in compliance with governing statutes and regulations, Interior's fiduciary duties to individual Indian trust beneficiaries, or even the department's own IT policies. See Tr. (Hrng., June 13, 2005, PM Sess.), at 100 (testimony of Mahach). "Until the DOI senior management team understands what they are signing on Accreditations and truly uses the POA[&]M to make budget decisions[,]" NPS CIO Dominic Nessi recently explained, "this is all basically a paper exercise." Pls.' Ex. 322 (email from Dominic Nessi, NPS CIO, to Sherry Barnett, DOI OS, Subject: "Re: Notification of Potential Finding and Recommendations for IG POA & M review" (Apr. 8, 2005)), at bp. DOI_JC_E0006910; see also Tr. (Hrng., June 13, 2005, PM Sess.), at 108 (testimony of Mahach) (explaining that these management shortcomings are currently some of the IG's principal concerns). He concluded, in accordance with the evaluation in the IG's third quarterly FY 2005 FISMA report to the departmental CIO, that Interior was not in compliance with the basic requirements of FISMA as of March 31, 2005 or as of the time of trial. See Tr. (Hrng., May 23, 2005, PM Sess.), at 120 (testimony of Mahach).

Interior is keen to emphasize, however, that it has "invested more than $100 million in its [IT] security program over the past 3 years." Pls.' Ex. 15 (IG 2004 FISMA Letter); see also Defs.' Opp., Ex. 1 (Decl. of W. Hord Tipton, DOI CIO), at ¶ 5 ("Since December 2001, Interior has devoted substantial resources to IT security. These resources include the investment of more than $100 million in its IT security program ...."). Sandy's NISO "went out and tried to support that number" after learning that Interior's CIO wanted to emphasize it in the FY 2004 FISMA report to OMB, which required "going with the Department of Interior's budget office to get all the information." See Tr. (Hrng., June 2, 2005, PM Sess.), at 92 (testimony of Sandy). Sandy agreed that the $100 million figure was an accurate combination of Interior's IT security budgets for FYs 2004, 2005, and 2006, which had already been either finalized or submitted to Congress for approval prior to the completion of the IG's 2004 FISMA report. See id. at 92-93 (testimony of Sandy) (explaining that "the budged process is about two years ahead of reality").

However, Interior's relatively large financial commitment to IT security means nothing if those resources are not properly allocated. Sandy noted during her FY 2004 FISMA investigation that there exists

a disparity of the funding. In other words, without adequate risk analysis and risk assessment and understanding your [security] control environment, you could be spending money on security controls that aren't really benefiting the organization or the data, and vice versa. Without having ... good knowledge, you could be not spending enough. If you don't have a good assurance [of] what your system's risks are, what is the importance of the data, if you're not sure of that, then you many not have any controls in place, which increases your risk to the data.... So it's a big circle, and ... there may be some [bureaus and offices that are] not spending enough money and others that may be spending too much, but there's no real foundation for one way or the other, because there's not adequate risk assessments and interconnections and understanding their whole environment as opposed to the parts.

See Tr. (Hrng., June 1, 2005, PM Sess.), at 38 (testimony of Sandy); see also Pls.' Ex. 162 (document entitled "Assignment Workpaper, Subject: Risk Assessments," prepared by Harriet Thiesen, NISO (Sept. 24, 2004)), at bp. DOI_OIG_IT0029067 (commenting on IG's findings of inadequate risk assessments at several bureaus that "[w]ithout identifying and understanding all the risks, the Department cannot know whether or not the controls that are in place are adequate to protect systems and mitigate risks or that the cost of the existing controls was justified ... [s]ome bureaus are not spending enough money on security and others are probably spending too much").

Interior's overwhelming lack of comprehensive risk assessments for its IT systems, complete system inventories, and budgetary analysis on the POA & M's for its IT systems make it nearly impossible for the department to allocate its $100 million IT security investment in a manner that gives priority to systems with the most dangerous weaknesses and de-prioritizes weaknesses that do not threaten the confidentiality, integrity, or availability of Interior's information or information systems. Interior's real problem is its failure to implement the basic processes necessary to secure complex IT systems, not necessarily insufficient funding, though that likely has been a problem in the past. This distinction is amply demonstrated by the results of NISO's FY 2004 FISMA investigation on behalf of the IG's office — so many deficiencies remained that had been brought to Interior's attention in previous years that Sandy was left to wonder what, exactly, the department had been spending that $100 million on. See Tr. (Hrng., June 2, 2005, PM Sess.), at 94 (testimony of Sandy).

Others in the IG's office shared this sentiment, as Mike Wood, the IG's CIO, commented to Sandy in an email concerning the results of the IG's penetration testing of NBC that "between what NISO [is] finding in your work this year and what NSM is finding the Department seems to have some significant problems. Doesn't seem like the $100 million has done the job." Pls.' Ex. 207 (email from Michael Wood, CIO of DOI's OIG, to Diann Sandy, NISO, Subject: "Re: NBC report to External Clients" (May 7, 2005)), at bp. DOI_IT0016402. Indeed, the IG's 2004 FISMA report noted that "[a]lthough bureaus implemented security controls in all systems we reviewed, they lack assurance that controls implemented were the most effective for mitigating any related risk or that the cost of the security control was justified because all risks to systems and information were not identified or evaluated." Pls.' Ex. 15, Enc. (2004 FISMA Rep.), at 4.

The Court is cognizant of the fact that it is generally considered impossible to create a perfectly secure IT environment. See, e.g., Tr. (Hrng., June 10, 2005, PM Sess.), at 75 (testimony of Mahach) ("[Y]ou're never going to be 100 percent. There's just never going to be 100 percent. It's not a zero sum or binary event. You have to come up with a process where you're comfortable with the risk that you could represent to this Court and to the plaintiffs."). However, Interior's fiduciary obligation to preserve IITD requires that IT security take a prominent position among the department's priorities. Tipton, however, testified that the newest general scanning data for Interior's systems showed at least 2,500 but as many as 6,000 vulnerabilities (with the actual number varying according to the error rate of the scans) among the networks of Interior's bureaus and offices. See Tr. (Hrng., July 27, 2005, AM Sess.), at 60-61 (testimony of Tipton). This number of vulnerabilities is worrisome, not only because of the serious deficiencies in Interior's POA & M program that makes documented remediation of vulnerabilities nearly impossible, but also more generally because, in the first three quarters of this year alone, Interior recorded some "350 million" attempts to break into Interior's IT systems in one form or another. See Tr. (Hrng., July 20, 2005, AM Sess.), at 37 (testimony of Cason); see also Pls.' Ex. 39 (Cason Decl.), Attachment 4 (Memorandum by Hord Tipton, DOI CIO (Oct. 9, 2002)) ("All too frequently there are malicious exploits that penetrate our networks."). Even if Interior's departmental POA & M program was not broken, it would nevertheless rely on self-reporting by bureaus and offices concerning the remediation of vulnerabilities, which Mahach testified was an ongoing source of serious problems for Interior's IT security program. See Tr. (Hrng., May 23, 2005, AM Sess.), at 87-88 (testimony of Mahach). He agreed that, time and again, bureaus and offices "have indicated [that] something is one way and you find it a different way, and they indicate ... that a problem has been solved, when it still hasn't been corrected[.]" Id. at 88. The Court has also noted the problems inherent in an IT security program that relies primarily on bureau and office self reporting to gather data about the state of security throughout the department.

As Mahach explained in an email to his colleagues in the IG's office, "[i]f DOI gets shut down, this could be a good time to do a top-to-bottom review" of several areas with documented IT security weaknesses. Pls.' Ex. 318 (email from Roger Mahach to Michael Wood and Eddie Saffarinia (Apr. 13, 2005)). As of the time of his testimony, Mahach maintained that Interior's IT security management program was simply "broken." See id.; Tr. (Hrng., June 13, 2005, PM Sess.), at 100.

The Court also notes the great progress that Interior's Inspector General has made in the IT security arena. Establishing the NSM group and incorporating external penetration testing into the IG's annual FISMA evaluations represent significant steps in the right direction. However, the IG's efforts also demonstrate a failure to appreciate the significance of Interior's fiduciary obligations regarding the Indian Trust. The IG's failure to place special emphasis on scrutinizing Interior's efforts to provide adequate security for IITD housed on or accessed by Interior's IT systems, demonstrated in part by the scope limitations placed on ISS's external penetration testing, is problematic to say the least. The lack of IG scrutiny of IITD security, along with the corresponding failure of Interior to emphasize IITD in designing and implementing IT security policies, is a serious deficiency in Interior's overall IT security program with respect to Interior's fiduciary obligations.

In general however, the Court is mindful of Interior's other, non-trust related obligations and the implications of those obligations for the department's IT security policy. Certainly, Interior has a variety of non-Indian customers to serve, and a massive amount of non-Indian Trust related data and IT infrastructure to secure. Interior, understandably, must apply whatever resources it can marshal in the IT security arena in a fairly even way, so that they do not overemphasize some areas of IT security at the expense of others. However, Interior's fiduciary obligations as Trustee-Delegate for the IIM trust differentiate its IT security position from that of other federal agencies. While all Interior IT systems generally should be expected to conform to industry and government standards for adequate IT security, its systems housing or accessing Trust Data must meet a higher standard. Any weaknesses in Trust systems identified during the IG's penetration testing, then, show both that the relevant system or network is not likely up to generally applicable security standards and, necessarily, that the relevant network or system does not meet the even higher fiduciary standard.

CONCLUSIONS OF LAW

The Court's conclusions of law are based on the facts found from the entirety of the evidentiary record produced during this hearing, of which the examples discussed above comprise about a fifth. On the basis of these findings of fact, the Court concludes that the plaintiffs have carried the requisite burden to establish the necessity and propriety of preliminary injunctive relief. At the technical level, the plaintiffs have produced overwhelming evidence documenting Interior's systemically deficient implementation of its Internet presence, web-applications, and wireless networking technology. Larger systemic problems related to general network architecture and the continued operation of legacy systems have also been established. The numerous interconnections between the IT systems of Interior's bureaus and offices, and between Interior's IT systems and those of private contractors and Indian tribes, substantially increase both the number of access points that might be exploited by a malicious attacker and the number of networks and systems that can be engaged by such an individual once unauthorized access has been gained. These technical problems demonstrate both a failure to build Interior's IT infrastructure with an emphasis on security, and a persistent failure to introduce adequate security features into Interior's extant IT environment.

With respect to Interior's IT security program in general, the plaintiffs have demonstrated that Interior's IT security testing practices are presently insufficient to secure IT systems against external threats, for example, of unauthorized access to Interior data and systems hosted or maintained by private contractors. In addition, Interior has not yet undertaken any comprehensive testing of the security of its IT systems against internal threats of unauthorized access by individuals who already have some level of access to those systems. Numerous experts from both Interior and ISS testified that Interior's IT systems, in their current security posture, are at a significant risk of unauthorized access from the Internet, and the plaintiffs cited examples of internal penetrations of Interior's systems. The sheer volume of unauthorized access attempts, numbering in the hundreds of millions, combined with Interior's failure to deploy throughout its IT environment certain security features that allow unauthorized access to be tracked and documented, show that the risk of unauthorized access is substantial. Moreover, the plaintiffs have established that Interior's POA & M process, through which IT security vulnerabilities are tracked and mitigated, is simply broken. There is substantial evidence that Interior's incident reporting processes are fundamentally deficient, and that many of Interior's systems are operating without contingency plans for recovery of operational capacity in the event of catastrophic loss of functionality.

At the management level, the evidence establishes that Interior has failed to prioritize security for electronic IITD in its IT security program. Despite years of advice, admonitions, warnings, and corrective actions by, OMB, GAO, Congress, this Court, and others, Interior has not segregated IITD onto secure servers separate from its general network environment, and Interior has not implemented the secure systems for processing IITD that were promised years ago. Of course, Interior has not secured its general IT environment sufficiently to render these additional layers of protection for IITD unnecessary. Furthermore, the plaintiffs have established a pattern of short-sightedness by the departmental IT security management staff, whose focus on patching the "holes" in existing IT systems has blinded it to the presence of more fundamental systemic problems inherent in the structure of Interior's IT environment. The plaintiffs have shown fundamental deficiencies in Interior's basic IT security programs and practices, such as the C & A and POA & M processes, that indicate a need to restructure the IT security program itself rather than to implement "fixes" for the discreet symptoms that evidence the systemic problems. One such problem that is particularly troubling in this context is the persistent failure of the bureaus and offices to implement departmental IT security policies, and the corresponding failure of the departmental CIO's office to ensure that the Interior's subdivisions comply with those policies. Interior's reliance on bureau and office self-reporting to evaluate and report on the state of IT security only magnifies this lack of centralized leadership.

The evidence shows that IITD is suffused in varying forms and amounts throughout Interior's network environment, and that nearly every part of that environment can be accessed from nearly every other part. ISS's penetration testing revealed IITD exposed to unauthorized access, and Interior's subsequent remedial efforts have not fully ameliorated that exposure, not to mention the structural and programmatic failures that made ISS's success possible in the first place. While ISS and the IG's staff informed Interior that the FY 2005 FISMA evaluation findings illustrate systemic problems that threaten Interior's IT assets, Interior management chose to focus on closing the specific vulnerabilities exploited by ISS, often placing them in a broken POA & M system in which there are no guarantees of actual remediation. Rather than revising and reissuing ineffectual IT security policies, Interior management chose to download patches. These latest remediation efforts, once again, treat the symptoms rather than the disease. IITD remains exposed to unauthorized access from the Internet through vulnerabilities that were not identified by ISS's penetration testing, but that likely exist due to systemic problems that ISS emphasized in its final reports to Interior. IITD remains exposed to unauthorized access from internal sources on legacy systems certified and accredited pursuant to questionable cost-benefit analysis, which never considered the potential impact to individual Indian trust beneficiaries of continuing to operate those systems, from threats Interior has never taken the time to evaluate. IITD sits on networks maintained by contractors and tribes to whom Interior has fully delegated its statutorily imposed duty to ensure adequate security, and whose efforts in that regard Interior has not evaluated. In many of its systems, Interior lacks the basic mechanisms to track attempts at unauthorized access, much less prevent them. There is no question that these problems, in the aggregate, demonstrate that the confidentiality, integrity, and availability of IITD on Interior's IT systems are presently at substantial and imminent risk of compromise.

It is also undeniable that Interior has made strides in the IT security arena. The Court is aware that, when IT security became an issue in this litigation some years ago, Interior was forced to begin from square one. Many of the individuals who testified in this evidentiary hearing are competent, conscientious, and well-intentioned. Interior's progress in a period of five years is laudable. However, the Court's duty in this matter is not to ignore continuing risks to IITD in light of the substantial progress that has been made. The evidence clearly shows that IITD is, at present, not adequately secure. While Interior contends that budgetary and personnel constraints, suffered universally among federal agencies, are to blame for the IT security failures highlighted by the plaintiffs, this view is not supported by the evidence. Rather, the evidence indicates that Interior has not properly emphasized IITD in its IT security efforts. Perhaps this is simply due to the number and magnitude of obstacles that the department's IT program has had to contend with. The Court takes Interior's progress in IT security as an indicator that the relief granted herein will possibly be short-term, and the Court looks forward to the day when Interior can satisfy the Court that its systems are secure enough to comply with Interior's fiduciary obligations to preserve Trust records against corruption and loss.

A. Preliminary Injunction Standard

"To prevail" on a motion for a preliminary injunction, "the moving party must demonstrate (1) a substantial likelihood of success on the merits, (2) that it would suffer irreparable harm without injunctive relief, (3) that an injunction would not substantially harm other interested parties, and (4) that issuance of the injunction is in the public interest." Cobell XII, 391 F.3d at 258. The Court will address each of these factors in turn.

i. Likelihood of Success on the Merits

This lawsuit is an equitable action for an accounting of the IIM trust. The Court of Appeals has already affirmed this Court's finding that Interior has a statutorily-imposed fiduciary obligation to provide such an accounting, and that the plaintiffs, as IIM trust beneficiaries, have a corresponding vested right to that accounting. See Cobell VI, 240 F.3d at 1102-04. The plaintiffs have also succeeded on their claim that Interior breached this duty. See id. at 1105-06. The Court of Appeals has made clear that "the federal government will be unable to provide an adequate accounting without computer systems, staffing, and document retention policies that are adequate for the task." Id. at 1106. The plaintiffs, having already succeeded in the initial phases of this litigation, have certainly demonstrated a substantial likelihood of success on the merits, as the Court of Appeals has confirmed. See id. at 259.

This Court's structural injunction requiring Interior to provide the plaintiffs with a full accounting of the IIM Trust since its inception more than a century ago is currently on appeal. Even if the historical accounting injunction is vacated, however, "[i]t is undisputable that the Secretary has current and prospective trust management duties that necessitate maintaining secure IT systems in order to render accurate accountings now and in the future." Cobell XII, 391 F.3d at 256-57 (citing Cobell VI, 240 F.3d at 1103). The Court does not understand Interior to contest on appeal its obligations to render accountings of the current and future balances of IIM accounts. Instead, Interior merely contests the authority of this Court to enforce those accounting obligations, and particularly Interior's historical accounting obligation, through injunctive relief.

The results of such a challenge are, however, of no moment for the matter presently under consideration. Even if Interior prevails on one or more of its objections to the form of relief that this Court has granted, there can be no doubt that (1) the Indian beneficiaries will continue to have a right to an adequate accounting of their trust assets from Interior; and (2) that right will be enforceable by relief from this Court in some form. The Court of Appeals has concluded that Interior's accounting duties are at least judicially enforceable, see Cobell VI, 240 F.3d at 1104 ("Claiming the role of administrator, however, does not absolve the government of its enforceable obligations to the IIM trust beneficiaries."), and has endorsed this Court's application of its "broad equitable powers" to ensure that Interior complies with its fiduciary obligations. See id. at 1108. And aside from Interior's accounting duties, the Court of Appeals has also concluded that "the Secretary, as a fiduciary, is required to maintain and preserve IITD." Cobell XII, 391 F.3d at 254.

ii. Irreparable Injury to the Plaintiffs

Each of the plaintiffs' rights in the IIM trust, including their right to an accounting, depends fundamentally upon the existence and accuracy of Trust documents and records in Interior's custody. Indeed, Interior's ability to carry out the day-to-day tasks of Trust management similarly depends on the proper preservation and maintenance of IITD. Corruption or loss of those documents and records, many of which are irreplaceable, thus constitutes irreparable injury of the most basic and destructive sort to the plaintiffs' interests in this litigation. Moreover, as the Court has emphasized so many times that it barely needs repeating here, many of the Indian beneficiaries depend on their IIM trust income for the basic staples of life. Without complete and accurate IITD, Interior's ability to calculate and process trust payments is jeopardized. The plaintiffs' evidence demonstrates that the current state of IT security at Interior places IITD at imminent risk of corruption or loss; thus irreparable injury to the plaintiffs has also been established.

Interior would no doubt like to argue that the existence of this harm depends on the validity of the Court's structural injunction requiring an accounting of the Trust. Such an argument, however, could not be more ill-founded. Whether or not Interior can be required by injunction to perform a historical accounting of the IIM trust, "Interior's present obligation to administer the trust presents sufficient grounds for finding that Plaintiffs will be irreparably injured." Cobell XII, 391 F.3d at 253 (quoting with approval Cobell XI, 310 F.Supp.2d at 96 n. 27). If Interior cannot secure its IITD, it will not be able to carry out its fiduciary duties going forward. Regardless of any pending challenges to the form that final relief in this case may take, there can be no discharge of Interior's accounting duties, and no final relief at all, if the IITD is not secured. This observation, standing alone, is enough to support the relief granted today.

iii. The Balance of Harms

The imminent harm to the plaintiffs in the absence of relief must be balanced against the inevitable harm to Interior of today's injunction. To be sure, Interior put on evidence of the ways in which the department's operations were disrupted by this Court's last disconnection order. Each departmental and bureau IT professional who testified in this hearing was questioned in this regard, and the answer was always the same: "It was hard." Interior has also made much of the financial functions carried out by NBC and MMS, and the effects that a loss of Internet connectivity would have on the department's ability to service its customers, many of whom are other governmental agencies. The relief granted today is not likely to prove popular in governmental circles. The Court is not, however, in the business of doing the popular thing, or the politically savvy thing. The Court must evaluate the evidence presented, and take the action that is warranted by that evidence.

The Court is tempted by the position that the magnitude of the potential harm to the 500,000 individual Indians for whom the government has assumed the mantle of Trustee outweighs, ab initio, any potential disruption of government function. These Indians cannot protect their trust records themselves (though the records belong to the beneficiaries and not to the government), and thus cannot by self-help prevent the harm of their loss, because Interior holds an information monopoly. Such a conclusion is not necessary, however. The Court concludes that injunctive relief may be fashioned that minimizes the impact of disconnection on Interior's ability to function and service its customers, financially and otherwise. Interior will have the opportunity to demonstrate to the Court that its systems are sufficiently secure to be reconnected; Interior will also have the opportunity to reconnect systems necessary to carry out Interior's financial obligations and other mission critical functions for an abbreviated time on a periodic basis until its systems are ready for full reconnection. These provisions should mitigate the hardship to Interior. As Interior is currently devoting substantial time and resources to IT security, so that today's order, at least, will simply augment and refocus existing initiatives.

The benefits of today's injunction to Interior should also not be gainsaid. Every Interior IT professional who was asked confirmed that there are serious, systemic problems with Interior's IT security program, and Mahach testified that a period of disconnection would provide the IG's office an opportunity to conduct a "top to bottom" review of some of the more vulnerable systems. Tipton himself testified that "it takes catastrophe" to get Interior to focus on the most pressing issues. See Tr. (Hrng., July 27, 2005, AM Sess.), at 16 (testimony of Tipton). "Sometimes it takes eye-opening events ... to actually get the people to pay attention." Id. (testimony of Tipton). Perhaps today's order will help to illuminate the pervasive problems that continue to plague Interior's IT security environment.

Of course, compliance with the Court's order will likely still be difficult. Priorities will likely have to be shuffled, resources will likely have to be redirected, and processes will likely have to be adapted temporarily. There will no doubt be a hasty motion to stay and appeal from today's order. But the Court hopes that Interior will recognize the problems inherent in its IT infrastructure, both technical and managerial, and choose to address those problems rather than merely stall for time and continue to bandage its IT security bullet wounds. After all, Interior is a trustee, and Interior should want to comply with its fiduciary obligations. Interior should want to exercise the degree of care required of a trustee. These fiduciary duties are not going to disappear, regardless of the turning of the political tides. Sooner or later Interior will have to face them.

iv. The Public Interest

Interior carries out a number of functions aside from its management of the IIM trust that are necessary to preserve life and property against destruction, the most notable of which is Interior's role in fire suppression. Disconnection of IT systems that support these functions would, of course, harm the public interest. However, as has been done before, the Court will provide Interior the opportunity to designate which systems require Internet connectivity to carry out these kinds of functions so that those systems may be exempted from the effect of this injunction.

Interior insists that disconnecting its IT systems will do more harm to the Indians' interests than good. This contention is short-sighted. Interior will be able to work around the absence of Internet connectivity in the short term to continue to provide services to the Indians while it secures their IITD. There can be no question that failure to take immediate action in this regard risks the complete destruction of these Indians' trust interests in the long term. IIM trust beneficiaries comprise approximately 1/600th of the population of this country, and thus their interests are a good percentage of the public interest in general. BIA and OST have been disconnected from the Internet for years, yet still manage to carry out their Indian-related missions. Solutions implemented to allow these bureaus to function without access to the Internet should be fairly easily adapted and exported to other bureaus and offices. As far as Interior's other customers are concerned, their interests are similarly best protected if Interior's IT systems are adequately secure. It should not be forgotten that they, too, have sensitive data stored on Interior's networks and systems.

More generally, Interior's fiduciary duties are imposed by statute, an expression of the will of the public through Congress. Every citizen of this country has an interest in seeing his or her government carry out its legal duties. It cannot but be in the public interest to hold government officials accountable to the people who created and whose approval maintains their offices. It is the very essence of the public interest that this government live up to the high standards set out by those who designed it, and that it should protect, as best it can, those who are placed in its charge.

CONCLUSION

The Court of Appeals remanded this matter to this Court with instructions to determine the current state of IT security at the Department of the Interior. Inspector General Devaney testified that he grades Interior's IT security an "F". Roger Mahach testified that he grades it one notch lower than an "F", so he called it a "G". The Court's findings of fact demonstrate that these poor grades are fully justified. For the foregoing reasons, the plaintiffs' motion for a preliminary injunction will be granted.

The preliminary injunction includes a provision allowing plaintiffs to continue to conduct discovery regarding IT security. Interior has again demonstrated that its quarterly reports are insufficient to give the Court and plaintiffs a true picture of what is occurring at Interior. Moreover, the facts established at this evidentiary hearing are clearly contrary to the reports Interior was providing to the Court, including the many improper certifications and accreditation of IT systems in 2004. Additionally, Roger Mahach testified at this evidentiary hearing that he was responsible for preparation of the IT portions of the Secretary's quarterly reports during this time that he was the Department's IT Security Manager (until June 2004) and that he never knew of the Court's criticisms of the reports — when Secretary Norton was held in contempt in 2002 — for only including positive accomplishments and not discussing problems that needed to be addressed and solved. Throughout Mr. Mahach's tenure, his reports contained positive information that would be revealed to any outsider, and generally did not address any negative information or problems. This Court previously expressed its view that Interior's failure to disclose the true status of its trust reform efforts constitutes fraud on the Court. From the three-month evidentiary hearing conducted on IT security, it appears little has changed in terms of truthful reporting.

A separate order shall issue today.

PRELIMINARY INJUNCTION

In accordance with the memorandum opinion issued this date, and upon consideration of the Plaintiffs' Motion [2926] for a Preliminary Injunction, the opposition thereto, the reply brief, the applicable law, and the proceedings at the Evidentiary Hearing conducted by the Court on this matter, it is hereby

ORDERED that the Plaintiffs' Motion [2926] for a Preliminary Injunction is GRANTED; and it is further

ORDERED that the Court hereby enters the following Preliminary Injunction.

I. Definitions

For purposes of this Order only, the following definitions apply:

A. Information Technology System — Any computer, server, equipment, device, network, intranet, enclave, or application, or any subsystem thereof, that is used by Interior or any of its employees, agents, contractors, or other third parties in the electronic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or other information, including without limitation computers, wireless devices (e.g. Blackberrys) and networks, voice over the Internet protocol (VOIP), ancillary equipment, devices, or similar services or protocols, including support services, software, firmware, and related resources.

B. Individual Indian Trust Assets — Lands, natural resources, monies or other assets held in trust by the Federal Government for the benefit of individual Indians or lands, natural resources, or other assets that are or were restricted against alienation for individual Indians.

C. Management — Actions that control, govern, administer, supervise, or regulate the custody, use, or disposition of Individual Indian Trust Assets.

D. Federal Record — This term is defined in 44 U.S.C. § 3301, and includes all documentary materials, regardless of physical form or characteristics, made or received under Federal law or in the transaction of public business and preserved or are appropriate for preservation as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities or because of the informational value in them.

E. Individual Indian Trust Data — Information stored in, or transmitted by or through, any Information Technology System that evidences, embodies, refers to, or relates to — directly or indirectly and generally or specifically — a Federal Record that reflects the existence of Individual Indian Trust Assets, and that at any time either: (1) has been, or is now, used in the Management of Individual Indian Trust Assets; (2) is a title or ownership record; (3) reflects the collection, deposit, and/or disbursement or withdrawal of income or interest — imputed or actual — relating to Individual Indian Trust Assets whether or not such assets are held in a particular account or are identifiable to any particular individual Indian trust beneficiary by name, number, or other specific identifier; (4) reflects a communication with, or on behalf of, an individual Indian trust beneficiary; or (5) has been, or is now: (a) created for, or by, Interior or any bureau, office, agency, agent, or contractor thereof, or for, or by a Tribe in connection with the Management of Individual Indian Trust Assets; (b) provided to, or received by, Interior or any such bureau, office, agency, agent, or contractor thereof, or any Tribe, for use in the Management of Individual Indian Trust Assets, and (c) used or housed by Interior or any such bureau, office, agency, agent, or contractor thereof, or any Tribe, in connection with the government's Management of Individual Indian Trust Assets.

F. House — The storage by electronic means of Individual Indian Trust Data.

G. Access — The ability to gain entry into Information Technology Systems.

II. Substantive Provisions

A. Subject to the exceptions outlined in Section II(C) and II(D), it is hereby ORDERED that Interior defendants forthwith shall disconnect all Information Technology Systems that House or provide Access to Individual Indian Trust Data:

1. from the Internet;

2. from all intranet connections, including but not limited to the VPX, ESN, or any other connection to any other Interior bureau or office;

3. from all other Information Technology Systems; and

4. from any contractors, Tribes, or other third parties

B. It is further ORDERED that within twenty (20) days of this date, Interior defendants must submit declarations to the Court, in compliance with 28 U.S.C. § 1746 and LCvR 5.1(h)(2), identifying any Information Technology Systems that do not House or provide Access to Individual Indian Trust Data and explaining why such Information Technology Systems do not House or provide Access to Individual Indian Trust Data. The plaintiffs, in accordance with their discovery rights reaffirmed in Section II(F), may take discovery regarding the Interior defendants' declarations. The plaintiffs must file any response to Interior's submissions under this section within thirty (30) days of the completion of the plaintiffs' discovery. The Court will consider the parties' submissions, conduct any necessary evidentiary hearing, and order further relief as appropriate.

C. To protect against fires or other such threats to life, property, or national security, it is further ORDERED that:

1. all Information Technology Systems necessary for protection against fires or other such threats to life, property, or national security may remain connected and are exempted from disconnection under Section II(A); and

2. Interior defendants shall, within twenty (20) days of this date, provide declarations, in compliance with 28 U.S.C. § 1746 and LCvR 5.1(h)(2), specifically identifying each and every Information Technology System that remains connected to protect against fires or other such threats to life, property, or national security. The declarants shall attest to: (a) the specific reasons such Information Technology Systems are essential to protect against fires or other such threats to life, property, or national security; (b) the specific connections that are necessary to protect against fires or other such threats to life, property, or national security; and (c) the compensating security controls and measures that defendants have implemented, or plan to implement, to protect Individual Indian Trust Data from loss, destruction, or unauthorized manipulation as a consequence of remaining connected.

3. The plaintiffs shall have twenty (20) days to file any response to Interior defendants' submission.

4. This Court will review Interior defendants' submission and declarations, and the plaintiffs' response thereto, but absent any contrary order from the Court, such systems may remain connected.

D. It is further ORDERED that Interior defendants may reconnect, for specified periods not to exceed five (5) business days per month, any Information Technology System that Houses or provides Access to Individual Indian Trust Data, for the purpose of receiving and distributing trust funds, or for the purpose of conducting other necessary financial transactions.

1. At least five (5) business days before temporarily reconnecting, Interior defendants shall file with this Court and serve upon the plaintiffs' counsel their plan to so reconnect. Said plan shall include proposed Information Technology Systems to be reconnected, connections to be re-established, and security controls and measures to cover such reconnection.

2. This Court will review Interior defendants' plan to temporarily reconnect and any response thereto submitted by the plaintiffs, but absent a contrary order from the Court, Interior defendants may temporarily reconnect their Information Technology Systems that House or provide Access to Individual Indian Trust Data in accordance with the plan submitted under this Section.

E. It is further ORDERED that Interior defendants may, at any time, file with the Court and serve on the plaintiffs a proposal to reconnect, other than temporarily as set forth in Section II(D), any Information Technology System disconnected by this Preliminary Injunction or any prior order of this Court.

1. Interior defendants' proposal must include all of the following: (a) a uniform standard to be used to evaluate the security of all Information Technology Systems which House or provide Access to Individual Indian Trust Data within the custody or control of the United States Department of Interior, its bureaus, offices, agencies, agents, contractors, or any other third party; (b) a detailed process whereby the uniform standard will be applied to each such Information Technology System; (c) a detailed explanation of how such Information Technology System complies with the uniform standard; (d) copies of all documentation relevant to he security of each such Information Technology System; and (e) a plan to provide monitoring and testing on an ongoing basis and quarterly reporting to this Court regarding the security of such Information Technology Systems.

2. The plaintiffs, in accordance with their discovery rights reconfirmed in Section II(F), may take discovery into Interior defendants' proposal. Any response shall be filed within thirty (30) days after the conclusion of plaintiffs' discovery.

3. The Court will conduct any necessary evidentiary hearing and decide whether a proposed Information Technology System may be reconnected and order further relief, as appropriate.

F. It is further ORDERED, in accordance with the Federal Rules of Civil Procedure, that the plaintiffs' discovery rights are reconfirmed.

1. The plaintiffs may take discovery, by deposition or otherwise, regarding the security of Information Technology Systems which may House or provide Access to Individual Indian Trust Data.

2. Consistent with this Court's April 25, 2005 Order, the scope of plaintiffs' discovery requests may include "all relevant reports, risk assessments, memoranda, and other documents, whether prepared by Interior officials or employees, officials or employees of other government agencies, or third parties," related to the security of each and every information technology ("IT") system that houses or accesses or may house or access individual Indian trust data.

3. The parties shall endeavor to agree upon and submit to the Court, within ten (10) days of this date, a proposed protective order to govern disclosure of information and materials related to IT security. In the event that the parties are unable to agree on a proposed protective order, each party must submit a proposed protective order to the Court within ten (10) days of this date.

SO ORDERED.

NOTES

[1] A "firewall" has been defined as:

an approach to security; it helps implement a larger security policy that defines the services and access to be permitted, and it is an implementation of that policy in terms of a network configuration, one or more host systems or routers, and other security measures such as advanced authentication in place of static passwords. The main purpose of a firewall system is to control access to or from a protected network (i.e. a site). It implements a network access policy by forcing connections to pass through the firewall, where they can be evaluated.... The general reasoning behind firewall usage is that without a firewall, a subnet's systems expose themselves to inherently insecure services ... and to probes and attacks from hosts elsewhere on the network. In a firewall-less environment, network security relies totally on host security and all hosts must, in a sense, cooperate to achieve a uniformly high level of security. The larger the subnet, the less manageable it is to maintain all hosts at the same level of security. As mistakes and lapses in security become more common, break-ins occur not as the result of complex attacks, but because of simple errors in configuration and inadequate passwords.

See John P. Wack & Lisa J. Carnahan, Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls, NIST Special Publication 800-10, United States Department of Commerce, National Institute of Standards and Technology, available at http://csrc.nist.gov /publications/nistpu bs/800-10/main.html.

[2] Subsequently, on the defendants' motion, the Court modified the December 5 TRO to allow Interior to "reconnect to the Internet, within 24 hours of notice to the Special Master and plaintiffs' counsel with appropriate documentation, any information technology system that does not house individual Indian trust data and that does not provide access to individual Indian trust data." Order, issued Dec. 8, 2001, at 1.

[3] NIST explains that

Management controls are the safeguards or countermeasures that focus on the management of risk and the management of information system security. Operational controls are the safeguards or countermeasures that primarily are implemented and executed by people (as opposed to systems). Technical controls are the safeguards or countermeasures that are primarily implemented and executed by information systems through mechanisms contained in the hardware, software, or firmware components of the system.

NIST SP 800-37, at 5 n. 9.

[4] Exhibits that consists of documents that are paginated, reference will be made to the document's "internal" page number. In all other cases, including references to exhibits that are comprised of more than one internally paginated document, reference to individual exhibit pages will be to the Bates page numbers generated during Interior's production process. Much of the evidence introduced in this evidentiary hearing contains information of a sensitive nature, public disclosure of which might expose Interior's IT systems to additional security risks. Interior has proposed redactions to a great number of the plaintiffs' exhibits, as well as to transcripts of testimony, many of which the Court has already approved. For the purposes of this Opinion, sensitive IT security information will not be disclosed, even where the defendants' proposed redactions have not yet been approved by the Court.

[5] This form of risk assessment is to be distinguished from the DAA's decision to accept certain risks in accrediting an IT system to continue in operation, which will be discussed below and involves a separate analysis.

[6] A threat-source is defined as "any circumstance or event with the potential to cause harm to an IT system. The common threat-sources can be natural, human, or environmental." NIST SP 800-30, at 13.

[7] This should not often occur, as NIST leaves the timing of a request to begin the C & A process for an IT system to the discretion of the ISO (within the three-year FISMA limitation). See NIST SP 800-37, at 32. There usually should be sufficient time to conduct an initial risk assessment and complete any recommended risk mitigation activities during the initiation phase of the C & A process.

[8] In light of the pending appeal in this case, the Court did not rely on any reports generated by the Special Master, whether or not referenced by the plaintiffs in this evidentiary hearing, in arriving at these findings of fact. Also, the Court has not considered any of the parties' documents submitted after the evidentiary hearing concluded on July 29, 2005.

[9] In the course of his testimony in this hearing, Inspector General Devaney demonstrated that he truly strives for independence from the Secretary in the performance of his duties. The Court regards Devaney's acceptance of the position as a positive step for Interior. Devaney's testimony displayed candor and an absence of bias, giving the Court ample reason to credit it and accord it full weight. While the Court was disappointed to learn that the IG's office did not place greater emphasis on individual Indian Trust related issues, this is most likely attributable to a combination of Devaney's refusal to be told how to do his job, even by the Court, and the predictable budgetary shortfalls suffered by all IG's offices to one degree or another.

[10] Fiscal years run from October 1 to September 30. So, for example, FY 2005 begins on October 1, 2004 and ends September 30, 2005. See Tr. (Hrng., May 20, 2005 AM Sess.), at 47 (testimony of Devaney).

[11] The Court takes Ms. Sandy's decision to retire from Interior as a positive indicator of the credibility of her testimony. She told the Court the same unvarnished truth that she had been telling Interior for years, though the Court, it seems, is more willing to listen.

[12] See generally Ron Ross, Stu Katzke, et al., Recommended Security Controls for Federal Information Systems, NIST Special Publication 800-53 (Feb.2005), United States Department of Commerce, National Institute of Standards and Technology, available at http:// csrc.nist.gov /publications/nistpu bs/800-53/SP800-53.pdf, as updated through May 4, 2005 [hereinafter NIST SP 800-53].

[13] The TrustNet system is defined as "a nationwide private Wide Area Network leased by BIA from" a private contractor, Pls.' Ex. 188 (document entitled "Record of Observation, Purpose: Describe Security Information of the GSS for determining compliance with FISMA," prepared by Stacey Crouser, NISO (July 14, 2005)), at bp. DOI_OIG_IT0012544, and is intended to "provide[ ] BIA with a secure, reliable network that is capable of properly supporting trust assets [and that will] ... provide the security and reliability that is lacking in the current environment." Id., at bp. DOI_OIG_IT0012542. TrustNet's is designed to function as an "interchange between BIA and other agencies (e.g., NBC, OST etc.) [,]" id., as well as a "backbone to the entire Bureau of Indian Affairs IT operation." Id., at bp. DOI_OIG_IT0012546. Problems with TrustNet identified as of July, 2004, included the absence of a "list and description of supported applications" from the SSP, id., at bp. DOI_ OIG_IT0012547, serious deficiencies in the "personnel security section of the SSP," id., the absence of interconnection agreements and rules of behavior from the SSP, id., at bp. DOI_OIG_IT0012548, an untested contingency plan, id., among others.

[14] It is also notable that NISO's review of IT systems in BLM's Idaho State office found that critical security controls were missing, and that network security in general was almost nonexistent. See Tr. (Hrng., June 2, 2005, PM Sess.), at 60-61 (testimony of Sandy); Pls.' Ex. 199 (document entitled "Assignment Workpaper, Subject: BLM Idaho state office record of observation," prepared by Hector DeJesus, NISO (June 28, 2004)), at bp. DOI_OIG_IT0028719-DOI_OIG_IT0028719. Again, the Idaho Office network is interconnected with BLM's NIRMC in Denver. See Pls.' Ex. 199, at bp. DOI_OIG_IT0028719 (indicating that the few security measures present on the Idaho office network are provided by NIRMC).

[15] Though NPS was not addressed specifically in the foregoing discussion, the evidentiary record provides ample support for the finding that, as of the FY 2004 FISMA reporting period, NPS systems were significantly deficient in most of NISO's Eight Key Areas. See Tr. (Hrng., June 6, 2005, AM Sess.), at 13-32 (testimony of Sandy) (discussing problems in NPS systems reported by NISO during 2004 FISMA examination); see generally Pls. Ex. 228 (document entitled U.S. Department of the Interior, Office of Inspector General, Draft Audit Feport: Improvements Needed In Managing Information Technology System Security, National Park Service, (Nov.2003)); cf. Tr. (Hrng., June 6, 2005, AM Sess.), at 13 (testimony of Sandy) (authenticating Pls.' Ex. 228, indicating that conclusions reported in this draft were finalized in early 2004 and represent findings that were incorporated into both the FY 2003 and 2004 FISMA reports). IT security at USGS, another Interior bureau that was not addressed at length in the foregoing, was also found to be substantially lacking as of the IG's FY 2003 FISMA evaluation. See Tr. (Hrng, June 6, 2005, AM Sess.), at 60-68 (testimony of Sandy) (discussing specific IT security problems identified at USGS during the relevant period); Pls.' Ex. 237 (document entitled "U.S. Department of the Interior, Office of Inspector General, [Draft] Audit Report: Improvements Needed in Security Over Information Technology Systems Critical to the Scientific Operations of the U.S. Geological Survey" (Mar., 2003)); see also Tr. (Hrng., June 6, 2005, AM Sess.), at 60-61 (testimony of Sandy) (authenticating Pls.' Ex. 237, indicating that the report was finalized later in March, 2003, and that the results were used in the IG's FY 2003 FISMA report). With respect to USGS, in brief, the IG reported that:

[USGS] senior management needed to place ... more emphasis on IT security and establish a permanent security management program that provides the framework for ensuring appropriate security is practiced throughout [USGS]. Until such a program is effectively implemented that complies with Federal laws and regulations, [USGS's] mission-critical IT systems and data will continue to be vulnerable to unauthorized access, misuse, and disruption of services. Although [USGS] has begun to improve its overall IT security management, much remains to be accomplished.

Pls.' Ex. 237, at bp. DOI_IT0053561. Sandy also confirmed that USGS was, at that time, attached to Interior's network "backbone," the VPX, and that therefore vulnerabilities in USGS IT systems posed risks to the systems of every other Interior bureau. See Tr. (Hrng., June 6, 2005, AM Sess.), at 62 (testimony of Sandy).

[16] "Bureau traversal" in this context means the ability of a user of one bureau's network to access systems on another bureau's or office's network. See Pls.' Ex. 1, Attch. 1, at 2. For example, if an employee of BLM is able to access some IT system on MMS's network, that employee has engaged in "bureau traversal." Bureau traversal is enabled by the existence of network interfaces between the distinct networks of Interior's various bureaus and offices, many of which exist to increase the efficiency of departmental operations by facilitating inter-bureau communication where necessary to accomplish departmental objectives.

[17] To preserve the confidentiality of sensitive IT security related information the disclosure of which might place Interior's IT systems at additional risk, the Court will of necessity describe the results of actual penetration tests in general terms without reference to the nature of specific vulnerabilities and the means by which they may have been exploited. The Court will, however, include citations to the record, including the sealed portions of the record, in support of its findings of fact.

[18] To enhance the similarity between the contractors' penetration testing and the efforts of an actual outside "hacker," the ROE require that

NGCS-ISS will use licensed security software, custom developed utilities, and `freeware' that is publicly available to the hacker community....

NGCS-ISS will use information acquired from public Internet sources, automated exploration and probing techniques, and security scanners to identify and focus on vulnerabilities that lend to the accessibility of the DOI routing and switching infrastructure with respect to gaining unauthorized access to DOI network resources.

Vulnerabilities found in `targets of opportunity' will be evaluated with respect to their value to effect greater depths of penetration. Those found exploitable in that manner will be used to mount intrusion attacks if feasible....

NGCS-ISS may use `stealth' techniques in automated probing tools and may engage the use of social engineering techniques if deemed useful for increasing the capability to engage the targeted hosts.

Pls.' Ex. 3, at 7.

[19] See generally Pls.' Ex. 7, at bp. OIG WDC 0001 000036-000037 (Attachment entitled "Internet Security Systems: Technical Report for External Penetration Testing, for DOI Office of Inspector General, Sites assessed in this report: DOI Bureau of Land Management") (hereinafter "ISS BLM Tech. Rep."). ISS reported that a "total of 12 vulnerability instances resulted in penetration as defined in the Rules of Engagement. Nineteen other medium and low-risk vulnerabilities were exploited to gain access to some type of information resource, but did not result in penetration. Twenty three other medium and low risk vulnerabilities were not exploited." Id. at bp. OIG WDC 0001 000021 (ISS BLM Mgt. Rep.).

[20] The Court found Mr. Mahach's testimony to display a striking level of candor. Coupled with his decision to move from the departmental to the IG side of Interior, Mahach's willingness to tell the whole truth gives the Court great confidence in the accuracy and completeness of his testimony in this proceeding. His conduct in this matter is a credit to his professionalism.

[21] This language was changed in the final version of the report to specify 700 "devices" rather than 700 "networks and devices." See Tr. (Hrng., June 6, 2005, PM Sess.), at 33 (testimony of Sandy). Sandy testified, however, that the change was merely "an attempt to clarify what it was we actually saw or was provided," and affirmed that NISO identified a number of both wireless networks and devices which, when added together, came to a total of approximately 700. See id. (testimony of Sandy) ("Q: There's no question this was a combination of the two, networks and devices? A: Right. That's the way we had originally written it was both, the networks and the devices.").

[22] When Pls.' Ex. 227 was marked for identification, the government interposed an objection on the basis that, as a draft, the document is not reflective of the actual, finalized views of the Inspector General. See Tr. (Hrng., June 3, 2005, PM Sess.), at 80-81. The Court noted the objection, and determined that while the various draft versions of the NISO's POA & M review findings, having not been finally approved by Devaney at the time of trial, would be considered to be only the findings and conclusions of the NISO auditors who conducted the examination and compiled the findings, and not of the Inspector General himself. This conclusion does not, however, affect the Court's view of the factual accuracy of the conditions reported in the findings, but rather only takes into account that those findings have not yet been adopted as the official position of Interior's OIG.

[23] One system for which POA & M entries were evaluated for the Office of the Assistant Secretary of Indian Affairs is the Fee to Trust ("FTT") system, which is a system that houses and/or accesses Indian trust data. See Tr. (Hrng., June 7, 2005, AM Sess.), at 39-40 (testimony of Sandy) (describing the purpose and functions of the FTT system).

[24] One BLM system for which POA & M entries were found deficient was the Denver Enclave GSS, which supports BLM's Trust systems as a "key component[ ] in the processing, storing, and transmitting of all BLM information." Pls.' Ex. 351 (email from Gary Stuckey, BLM C & A Project Manager, Subject: "High Security Classification" (Feb. 2, 2005)) ("Stuckey email") (emphasis added). Stuckey explained that if all Trust systems are required, as a matter of Interior policy, to be regarded as "high risk," then the Denver Enclave GSS would certainly have to be included for its Trust functions. See id.

[25] Cason did testify that "there is at least some speculation about whether cadastral survey information is IITD. Because the framing that we have within the department is that a map in and of itself is not IITD, it's only the use of the map that makes it IITD. And when you take the map from cadastral survey, give it to BLM or BIA, and they actually do something with that map in managing the Trust, then it becomes IITD within BIA." Tr. (Hrng., July 18, 2005, PM Sess.), at 81 (testimony of Cason). The Court finds that insofar as cadastral survey data is required for a number of kinds of land-based Indian trust transactions, not to mention accounting for the value of allotted lands, cadastral survey data related to allotted lands requires the same degree of IT security protection as any other type of IITD. Thus the much debated question whether the penetration of the NILS system was a breach of a "Trust system" was really a non-starter; the significance of this incident for Interior's trust duties is obvious. Indeed, Interior's February 3, 3003 quarterly report to the Court stated: "Cadastral surveys are critical to the success of the trust. Ownership information, distribution of trust assets, and management of trust accounts are related to or are based upon information recorded in a cadastral survey." Most of the confusion among Interior's IT professionals over whether ISS actually accessed Trust systems during the penetration testing of BLM seems to have arisen from the fact that Interior no longer classifies NILS as a Trust system, and the absence of a coherent departmental position on whether or not cadastral survey data is IITD.

[26] Mr. Burns was not at BIA six years ago — he arrived in 2002, three years ago.

[27] Interior admitted in 1999 that these BIA legacy systems, including IRMS were not secure, and they planned to migrate them into TAAMS. Until the eve of this Court's evidentiary hearing, however, this conversion of the IRMS data was delayed, meaning six years of study and no action, even though BIA's own Chief Information Officer had been pressing for this as at least a necessary interim step for the last three years. He estimates it will still take another year before this conversion occurs, leaving all this data insecure for seven years from the time of Interior's admission that it was all insecure.