Opinion
Civil Action No. 1:96CV01285 (RCL).
December 6, 2001.
REPORT AND RECOMMENDATION OF THE SPECIAL MASTER REGARDING THE SECURITY OF TRUST DATA AT THE DEPARTMENT OF THE INTERIOR
REDACTED VERSION
I. INTRODUCTION
On May 17, 2001, plaintiffs filed a Consolidated Motion for an Emergency Temporary Restraining Order and Motion for a Preliminary Injunction and Motion for Order to Show Cause Why Secretary Norton, Her Employees and Counsel Should Not Be Held In Contempt ("Motion for Emergency TRO"). Plaintiffs' Motion followed the April 2001 publication of Government Executive magazine in which then-Bureau of Indian Affairs ("Bureau" or "BIA") Chief Information Officer ("CIO") Dominic Nessi observed that,
Plaintiffs are alarmed "because individual Indian trust funds and individual Indian trust records — held or created in systems managed and administered by the BIA Office of Information Resources Management ("OIRM") — have been destroyed in violation of this Court's orders or remain at risk of imminent and catastrophic loss and destruction." Motion for Emergency TRO at 1. Plaintiffs specifically asked the Court to order "government officials and their contractors to "cease the destruction of IIM-related trust documents and data forthwith" and to bar "contractors whose security clearance is not complete . . . from accessing confidential trust information, pending completion of the Master's investigation" at which time "permanent relief can be fashioned by the Master and this Court." Id. at 10.
The Motion for Emergency TRO represents plaintiffs' second filing regarding OIRM. On March 30, 2001, plaintiffs filed a Motion for Special Master to Investigate The Office of Information Resource Management For Failing To Implement Adequate Security Measures and the Interior Secretary And Her Employees' And Counsel's Related Representations and Recommend Immediate And Long-Term Corrective Action and Disciplinary Measures, as Appropriate, ("Motion to Investigate"). There, plaintiffs ask the Special Master to: (a) "investigate the failure of the Interior Secretary to implement adequate security measures at OIRM to ensure that all electronic and hard copy IIM-related trust documents and data are protected fully; (b) assess the impact of such failure; (c) assess the veracity . . . regarding the security of OIRM trust documents and data; (d) investigate whether [Interior] willfully attempted to obstruct the Special Master . . . (d) recommend . . . . corrective action and disciplinary measures, as appropriate." Motion to Investigate at 7. Plaintiffs' motion was filed in response to the March 12, 2001 Site Visit Report of the Special Master to The Office of Information Resource Management. In light of the findings and recommendations contained in the instant Report, plaintiffs' Motion to Investigate is denied as moot.
[f]or all practical purposes, we have no security, we have no infrastructure, . . . . Our entire network has no firewalls on it. I don't like running a network that can be breached by a high school kid. I don't like running a program that is out of compliance with federal statutes, especially when I have no ability to put it into compliance.
This was not the first time that Nessi publicly questioned the integrity of BIA's IT Security. In a September 11, 2000 article published in Government Computer News, Nessi — only recently appointed to the position of Chief Information Officer Nessi — remarked that BIA is behind the times and is only now addressing the issues many agencies began work on in the mid and late 1990s insofar as the "top managers wouldn't even know what systems are in existence;" and that "[t]here really is no mentality of security. . . . People trade passwords back and forth. There wasn't proper management for removing people's access to systems after they left. There were no security background checks conducted at all." Nessi further lamented that "[t]he Bureau of Indian Affairs has no idea what it spends on IT," explaining that "[w]e can't expect the Office of Management and Budget or Congress to appropriate funds for a function if an agency doesn't plan properly or document its needs to show how it is going to utilize its funds." Tony Lee Orr, Government Computer News, BIA Suffers High-Tech Growing Pains, (Sept. 11, 2000).
Katherine McIntire Peters, Trail of Troubles, Government Executive, April 1, 2001 at 100.
Government Executive is a monthly business magazine "serving senior executives and managers in the federal government's departments and agencies." About Us, http://www.govexec.com/about.htm (Visited Nov. 9, 2001).
At the request of the Court, the Special Master launched an investigation into the trust data security systems in the custody or control of the Department of the Interior ("Interior" or "DOI"). Toward that end, the Special Master interviewed government employees and private contractors, reviewed relevant statutes and regulations, evaluated reports generated by public agencies and private organizations and pored over thousands of pages of internal memoranda, correspondence and e-mail transmissions. The Special Master also retained the services of an independent firm with an expertise in security systems to conduct penetration tests and assist in the ultimate evaluation of the current state of Interior's Information Technology ("IT") Security.
Although the primary thrust of this report focuses on the safeguarding of data retained on DOI/BIA/OIRM computer systems, it touches briefly on issues impacting other forms of security, namely personnel security, (i.e., "(1) defining the job, normally involving the development of a position description; (2) determining the sensitivity of the position; (3) filling the position, which involves screening applicants and selecting an individual; and (4) training,"), NIST Special Publication 800-12, An Introduction to Computer Security: The NIST Handbook at 109, and physical security, (i.e., "measures taken to protect systems, buildings, and related supporting infrastructure against threats associated with their physical environment."). Id. at 167.
For the purpose of this report, "information technology" will be defined as in the Clinger-Cohen Act, 40 U.S.C. § 1401(3)(A), i.e., "any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by [an] executive agency."
The Special Master's findings and recommendations are as follows:
II. BACKGROUND
In December 1999, the United States District Court for the District of Columbia ordered Interior to correct four breaches of statutory trust duties contained in the American Indian Trust Management Reform Act of 1994. See Cobell v. Babbitt, 91 F. Supp.2d 1, 58 (D.D.C. 1999). The first two breaches implicated the agency's broad policies and procedures regarding trust accounts ("individual Indian monies" or "IIM's") while the remaining two required the Department to establish written policies and procedures for computer and business systems architecture necessary to render an accurate accounting of the IIM trust and establish written policies and procedures for the staffing of trust fund management functions necessary to render an accurate accounting of the IIM trust.Cobell, 91 F. Supp.2d at 43-45.
The Court, on that score, held that,
[a]s impressive as Interior's new computer systems appear to be, these computer systems still depend upon the labor and skill of Interior's employees. Missing and backlogged information must be put into the computer systems. The information contained in and processed by the computer systems must be monitored and verified. Problems arising from the integration of the computer and business systems must be addressed.Cobell, 91 F. Supp.2d at 45 (emphasis added).
The Court stayed its hand from awarding
more extensive prospective relief [based] on defendants' plans (in both substance and timing) to bring themselves into compliance with their trust duties declared today and provided for explicitly by statute. These plans have been represented to the court primarily through the High Level Implementation Plan, but also through the representations made by government witnesses and government counsel.Cobell v. Babbitt, 91 F. Supp.2d at 59.
The Circuit clarified the District Court's holding regarding the federal government's trust responsibilities when it ruled that,
The government's broad duty to provide a complete historical accounting to IIM beneficiaries necessarily imposes substantial subsidiary duties on those government officials with responsibility for ensuring that an accounting can and will take place. In particular, it imposes obligations on those who administer the IIM trust lands and funds to, among other things, maintain and complete existing records, recover missing records where possible, and develop plans and procedures sufficient to ensure that all aspects of the accounting process are carried out. As the district court concluded, this may well include an obligation to develop or obtain computer software capable of tracking and reconciling fund data, hire staff sufficient to execute management duties, and implement specific plans to ensure that all reasonable efforts are made to provide the most complete and accurate historical accounting of IIM trust funds that is possible. The failure to implement a computer system is not itself the breach. Rather it is indicative of appellants' failure to discharge their fiduciary obligations in a reasonably prompt manner. It is the latter which constitutes the breach.Cobell v. Norton, 240 F.3d 1081, 1105 (D.C. Cir. 2001).
It is the thesis of this Report that a fundamental component of Interior's duty to monitor and verify trust information "contained in and processed by the computer systems" necessarily includes an obligation to ensure its integrity. This Report chronicles Interior's compliance with that duty in an effort to underscore the sheer enormity of the dangers to which this trust information is being exposed. The instant furor over the safety of trust data is not the first in this litigation. On November 5, 1999, BIA employees were informed that OIRM was to be moved from its headquarters in Albuquerque, New Mexico to a new facility in Reston, Virginia. See Declaration of Deborah Maddox, at ¶ 15 (March 17, 2000). Relying on the conclusions found in the Inspector General's September 24, 1999 Auditor's Report on the Bureau of Indian Affairs Consolidated Comparative Financial Statement for Fiscal Years 1998 and 1997 and the National Academy of Public Administration's Study of Management and Administration, then-Assistant Secretary for Indian Affairs Kevin Gover decided such a move would "remedy longstanding material weaknesses in the functioning of the office." Declaration of Kevin Gover at ¶ 6 (March 7, 2000), "strengthen the management and effectiveness of OIRM in the performance of its duties." Declaration of Kevin Gover at ¶ 8 (March 14, 2000), and increase BIA's emphasis on information technology." Livingston et al. v. the Department of the Interior, DE-0752-00-0237-I-2, Merit System Protection Board Hearing (August 23, 2000).
Page numbers are not available for the transcript of this proceeding.
BIA officials conceived a four-step process for undertaking the move. According to Nessi, who was then-OIRM Acting Director,
• there would be a transfer of knowledge between the existing OIRM staff and the contractor ISI/PRT through having contractor staff work along side OIRM staff;
• the contractor would take over the operation of the data center in Albuquerque, NM on approximately March 13 and those OIRM personnel who had accepted the transfer would move to Reston, Virginia;
• the relocated OIRM staff would then begin construction and testing of the new data center in Reston; and
• Only after the Reston facility was fully functional and ready would operations cease in Albuquerque and commence in the new Reston facility.
BIA contracted with Interior Systems, Incorporated ("ISI"), who teamed with PRT Group, Incorporated ("PRT") "to handle the IT aspects of the move." Declaration of Dominic Nessi at ¶ 15 (March 20, 2000).
Declaration of Dominic Nessi at ¶ 16 (March 20, 2000). The contract between BIA and PSI/IRT provided that the contractors were to begin work at the Albuquerque facility on February 29, 2000 and the physical relocation was to commence during the first week of March 2000.
See Order No. NBCWOP00371, Contract between ISI and NBC (Feb. 29, 2000).
See Statement of Charles Findlay, Esq., United States Department of Justice, March 7, 2000 Hearing at 26, ("The move has already begun. It began at the beginning of this week. Employees will be leaving the Albuquerque office by the end of this week, and those who are moving to Washington, about 20 out of 60, are to report to work in Reston on Monday. Some have already begun to arrive.")
On March 7, 2000, plaintiffs filed their Motion for a Temporary Restraining Order ("TRO") asking the court to "immediately bar all contractor access to all confidential individual Indian trust data until and unless Defendants and their attorneys demonstrate to the satisfaction of the Special Master that they are in full compliance" with a host of relevant statutes and regulations pertaining to information security. Proposed TRO at 1. Plaintiffs argued that a TRO should be imposed because OIRM contractors were "using temporary workers, who have not received proper security clearance, to review and inventory confidential IIM trust records." Motion for TRO at 2. On March 7, 2000, the Court granted plaintiffs' motion and agreed to schedule a hearing for a preliminary injunction upon review of the papers. March 7, 2000 Hearing at 43.
The Court signed Plaintiffs' Proposed Order with the only change being that instead of the requirement to "demonstrate [compliance] to the satisfaction of the Special Master," defendants would have to demonstrate compliance to the satisfaction of the Court.
On March 8, 2000, defendants filed a Motion for Clarification of Temporary Restraining Order, requesting that the scope of the TRO be limited in its application to the ISI/PRT contractors. Defendants argued that, to bar all contractor access to OIRM "would force the Office to discontinue services" (Motion for Clarification of TRO at 2) because "[w]ithout their support, the Office would be nearly inoperable." Id. at 3. Plaintiffs opposed this motion, arguing instead that all contractors who lacked proper security clearances should be barred from OIRM. See Plaintiffs' Opposition to Defendants' Motion for Modification of TRO at 1. On March 16, 2001, the Court granted defendants' motion.
On April 4, 2000, the Court dissolved the TRO and denied plaintiffs' request for preliminary injunction on the grounds that, acting otherwise risked "harming the very beneficiaries of these trust records who will have critical payments delayed by the disruption of operations that would occur if the preliminary injunction issued," April 4, 2000 Hearing at 12.
III. SYSTEMS HOUSING TRUST DATA
Individual Indian trust information is housed on a number of computer systems and platforms throughout the country. Primary responsibility for maintaining and designing these systems rests with the Office of Information Resources Management ("OIRM") the office charged with the administration of the BIA's "computer systems and the information systems serving Indian Affairs programs such as Social Services, Law Enforcement and some components of the Trust Services systems." Decl. of former Assistant Secretary for Indian Affairs Kevin Gover at ¶ 2 (March 14, 2000).
OIRM's trust-related responsibilities include maintaining the Land Records Information Systems ("LRIS") and the Integrated Records Management System ("IRMS") — together referred to as the "legacy systems." Id. at ¶ 3. The LRIS system has been in continuous operation since 1980 (see LRIS System Security Plan (June 30, 2001) at 5) and is used by BIA Land Titles and Records Offices to "(1) provid[e] full land title service to the administrators and owners of Indian lands and to such other entities as may be authorized by law; and (2) maintain and record title, current and historical ownership of Indian land owners." Id. at 6. It's functions are housed on an IBM XXXXXXXXXXXXXXXXXX mainframe located in Denver, Colorado. Id. at 8. LRIS "is the official record of all lands with which the BIA trust system deals." Id. at 7. It serves as "the accounting basis on which large sums of money are received from non-Indians and paid out to Indians." Id.
A "System Security Plan" is designed to: "(1) provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements; and (2) delineate responsibilities and expected behavior of all individuals who access the system." NIST Special Publication 800-18, Guide to Developing Security Plans for IT Systems, (Dec. 1998) at 2. All 5 system security plans cited in this report were drafted by SeNet.
The IRMS, operational since 1982, "receives information keyed in by IRMS users at Regional Offices, Agencies, and Tribes, as well as files that are uploaded from other BIA systems. The information is used for tracking individuals, leases, and ownership and to calculate and distribute payments in the form of checks or direct deposits to thousands of Indian bank accounts." IRMS System Security Plan (June 30, 2001) at 7.
IRMS consists of six databases — five of which are operated by the Office of Trust Responsibility. IRMS System Security Plan at 6. The five Office of Trust Responsibility databases include the Lease/Range and Lease Distribution databases — which manage payouts for leases of Indian land; the Ownership database — which tracks titles of Indian tribal and trust land; the Individual Indian Monies database — which tracks funds to individual Indians from leases, royalties, permits and other uses of Indian land; and the Oil and Gas database, which manages payouts for leases of Indian owned Oil and Gas producing assets.Id. at 7. IRMS functions are run on a Unisys NX platform located at the BIA's Reston Data Center. IRMS System Security Plan at 6.
The sixth IRMS database is owned by the Office of Tribal Services. IRMS System Security Plan at 6.
Trust data is also housed in the Trust Asset and Accounting Management System ("TAAMS") which runs on an AS/400 platform located in Addison, Texas. See TAAMS System Security Plan, June 30, 2001 at 7. The TAAMS System is operated by Applied Terravision Systems, Inc. ("ATS"), id. at 4, which "owns, operates, and maintains the [Addison, Texas] data center's AS/400 computer." Physical Security Implementation Guidelines TAAMS Data Center, Addison, TX (June 16, 2000) at 3. As of June 30, 2001, TAAMS was touted to be the "system of record" for the Muskogee, Billings, Alaska and Anadarko offices. Id. at 5.
According to Deputy Director of the BIA Office of Economic Development George Gover, the term "system of record" is "a term of records management. . . . That is the system you stand by. That is the official system, official position of what the record should look like." August 14, 2001 Interview of George Gover at 36-37.
When fully implemented, TAAMS is projected to:
manage 56 million acres of trust land, 170,000 tracts of land, 100,000 active land leases, 350,000 owners of land parcels, and 2 million owner interests. The system will serve 3,000 users, with an estimated 1,500 users logging in daily and accessing records concurrently. TAAMS is replacing a number of existing legacy systems such as LRIS, IRMS and RDRS. Unlike these batch-based legacy systems, TAAMS is based on modern database, client/server, and networking technologies, that considerably improve performance, efficiency and reliability.
TAAMS Systems Security Plan at 6.
The systems containing trust data are linked by the BIA Wide Area Network ("BIANET") that connects over 5000 users in sites nationwide to centralized BIA and DOI computing resources and services. By using the BIANET,"
A wide area network (WAN) "is a geographically dispersed telecommunications network. The term distinguishes a broader telecommunication structure from a local area network (LAN). A wide area network may be privately owned or rented, but the term usually connotes the inclusion of public (shared user) networks."
http://searchNetworking.techtarget.com/sDefinition/ O,, sid7_gci212495,00.html
users in the 48
CONUS states and
Alaska can access,
retrieve, and manipulate
information residing on
BIA and DOI
computing resources,
exchange e-mail
messages with DOI
employees, use the
Internet to exchange e-
mail with individuals in
other government and
commercial
organizations, and
browse the Internet for
general information."
BIANET System
Security Plan (June 30,
2001) at 7. The
information transmitted
therein "ranges from
public domain to highly
sensitive."
Id.
Another system linking computers which house trust data is the Reston, Virginia Local Area Network ("Reston LAN") that provides users in the Reston Office access to IT resources, e.g., mail servers, printing, Internet access, and provides nationwide users with access to BIA major applications that are hosted on computer system inside the Reston data center. Transmitted information ranges from non-sensitive to highly sensitive. Reston LAN System Security Plan, (June 30, 2001) at 7-8.
A local area network (LAN) is a group of computers and associated devices that share a common communications line and typically share the resources of a single processor or server within a small geographic area (for example, within an office building). Usually, the server has applications and data storage that are shared in common by multiple computer users. A local area network may serve as few as two or three users (for example, in a home network) or many as thousands of users (for example, in an FDDI network).
http://searchnetworking.techtarget.com/sDefinition/ O,, sid7_gci212495,00.html
IRMS is considered BIA's "major application" housed at the Reston facility. IRMS System Security Plan at 6.
IV. DUTY TO SAFEGUARD TRUST INFORMATION
In the normal course of business, Interior retains a wide range of trust data relating to the plaintiff class of individual Indian account holders and beneficiaries. This data constitutes inherently sensitive business information which must be stored and handled in a secure environment that has been adequately safeguarded from intrusion, alteration or destruction by unauthorized parties. See BIA IT Risk Assessment (January 4, 2000) at 4 ("both because of the distributed nature of its IT resources and user population as well as the sensitive information it maintains on tribes and individual Indians. . . . [t]his information must, by law, be protected from unauthorized access, alteration or destruction."). The duty to protect this sensitive information may be traced to several sources.
A. Common Law
Interior's substantial trust responsibilities toward Native Americans, including the responsibility to safeguard records, is "undeniable" and grounded "in the very nature of the government-Indian relationship,"Cobell v. Norton, 240 F.3d 1081, 1085 (D.C. Cir. 2001) (citing United States v. Mitchell, 463 U.S. 206, 225 (1983)), and in well established common-law fiduciary principles. See Security Exchange Comm. v. Sargent, 229 F.3d 68, 76 (1st Cir. 2000) (recognizing "fiduciary duty to safeguard information relating to" trust); Rippey v. Denver U.S. Nat. Bank, 273 F. Supp. 718, 735 (D.C.Colo. 1967) ("It is generally agreed that a trustee owes a duty to his beneficiaries to exercise such care and skill as a man of ordinary prudence would exercise in safeguarding and preserving his own property."); Rest. 2d Trusts § 173 (Comment C) (trustee should preserve records in a manner that provides trust beneficiaries access "to such information as is reasonably necessary to enable [them] to enforce [their] rights under the trusts or to prevent or redress a breach of trust.").
Indeed, the duty "to furnish to the beneficiary on demand all information regarding the trust and its execution which may be useful to the beneficiary in protecting his rights" Cobell v. Babbitt, 91 F. Supp.2d 1, 42 (D.D.C. 1999) (quoting George T. Bogart, Trusts § 141 (6th ed. 1987)) would be rendered meaningless unless the underlying information were adequately secured. B. Statutory and Regulatory Guidelines
On that score, this jurisdiction has spoken with a clear voice when it held that "[c]ourts `must infer that Congress intended to impose on trustees traditional fiduciary duties unless Congress has unequivocally expressed an intent to the contrary.'" Cobell v. Norton, 240 F.3d 1081, 1099 (D.C. Cir. 2001) (quoting NLRB v. Amax Coal Co., 453 U.S. 322, 329 (1981)).
In addition to the fiduciary obligations imposed by common law, defendants' responsibilities are codified in, and governed by, an exacting set of statutes and policies including:
• The Privacy Act of 1974, 5 U.S.C. § 552a, which, in relevant part, provides that, "[n]o agency shall disclose any record which is contained in a system of records by any means of communication to any person, or to another agency, except pursuant to a written request by, or with the prior written consent of, the individual to whom the record pertains. . . ;"
• The Freedom of Information Act of 1974, 5 U.S.C. § 552, which requires agencies to "make reasonable efforts to search for [requested] records in electronic form or format . . . ;"
• The Paperwork Reduction Act of 1978, 44 U.S.C. § 3501, which attempts to make "uniform federal information resources management policies and practices as a means to improve the productivity, efficiency, and effectiveness of government programs;"
• The Electronic Communications Privacy Act of 1986, 18 U.S.C. § 2701, which criminalizes unauthorized access to electronic communications;
• The Computer Fraud and Abuse Act of 1986, 18 U.S.C. § 1030, which criminalizes unauthorized access to information stored on government computer systems;
• The Computer Security Act of 1987, 40 U.S.C. § 1441(amended by the Clinger-Cohen Act), which requires the government to promulgate standards for computer security, train relevant employees in computer security and establish plans for the security and privacy of computer information. In relevant part, the Act requires that "each federal agency shall provide for the mandatory periodic training in computer security awareness and accepted computer security practice of all employees who are involved with the management, use or operation of each Federal computer system within or under the supervision of that agency," and "establish a plan for the security and privacy of each Federal computer system . . . that is commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of the information contained in such system;"
• The Clinger-Cohen Act, 40 U.S.C. § 1401 (formerly known as the Information Technology Management Reform Act), which directs executive agencies to establish the position of Chief Information Officers and places responsibility for "providing advice and other assistance to the head of the executive agency and other senior management personnel of the executive agency to ensure that information technology is acquired and information resources are managed for the executive agency . . .; developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the executive agency; and promoting the effective and efficient design and operation of all major information resources management processes for the executive agency, including improvements to work processes of the executive agency" on the CIO;
• The Trade Secrets Act, 18 U.S.C. § 1905, which criminalizes unauthorized government disclosure of trade secrets; and
• The Federal Managers' Financial Integrity Act of 1982, 31 U.S.C. § 2512, which directs executive agencies to file reports detailing whether "the accounting system of the agency conforms to the principles, standards, and requirements the Comptroller General prescribes."C. Executive Branch Guidelines
Although the term "trade secrets" is not defined in this statute, courts have generally borrowed the definition from the Uniform Trade Secrets Act to include information that "derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable through proper means by, the public," provided that "the owner thereof has taken reasonable measures to keep such information secret." 18 U.S.C. § 1839(3) (Supp. 1997); see also D.C. Code Ann. § 48-501(4) (1997) (paraphrased definition).
Interior's common-law responsibilities and their statutory counterparts have been underscored in Executive Guidelines and Procedures, including,
• The Office of Management and Budget Circular A-130, Management of Federal Information Resources, (Nov. 28, 2000) and Appendix III to Circular A-130, which establishes policies for the management of Federal information resources. Circular A-130 directs agencies to "plan in an integrated manner for managing information throughout its life cycle" and requires that agencies "[e]nsure that information is protected commensurate with the risk and magnitude of the harm that would result from the loss, misuse, or unauthorized access to or modification of such information," and that agencies "must make security's role explicit in information technology investments and capital programming." The Circular also sets out specific guidelines for agencies to ensure the security of information systems;
• The Office of Management and Budget Circular A-123, Management Accountability and Control, (June 21, 1995), which "provides guidance to Federal managers on improving the accountability and effectiveness of Federal programs and operations by establishing, assessing, correcting, and reporting on management controls";
• The Office of Management and Budget Circular A-127, Financial Management Systems, (July 23, 1993), which "prescribes policies and standards for executive departments and agencies to follow in developing, operating, evaluating, and reporting on financial management systems";
• OMB Bulletin No. 90-08, Guidance for Preparation of Security Plans for Federal Computer Systems that Contain Sensitive Information (July 9, 1990), whose purpose "is to provide guidance to Federal agencies on computer security planning activities required by the Computer Security Act of 1987. This Bulletin supersedes OMB Bulletin No. 88-16, "Guidance for Preparation and Submission of Security Plans for Federal Computer Systems Containing Sensitive Information" (July 6, 1988)";
• February 28, 2000 Memorandum for the Heads of Departments and Agencies from Office of Management and Budget Director Jacob Lew, which directs agencies to plan for IT Security needs, by making "security's role explicit in information technology investments and capital programming";
• National Security Telecommunications and Information Systems Security Committee Publication 1000, National Information Assurance Certification and Accreditation Process (April 2000), which "establishes a standard national process, set of activities, general tasks, and a management structure to certify and accredit systems that will maintain the information assurance (IA) and security posture of a system or site."D. Industry Standards
Finally, executive agencies, such as Interior are directed by guidelines promulgated by the National Institute of Standards and Technology ("NIST") and the Federal Information Processing Standards ("FIPS"). These include:
NIST "works with industry, research, and government organizations to make [information] technology more usable, more secure, more scalable, and more interoperable than it is today." Dr. William O. Mehuron, Information Technology Laboratory: What ITL Doeshttp://www.itl.nist.gov/itl-what _itl_does.html (Last Modified Nov. 15, 2000).
Under the Information Technology Management Reform Act (Public Law 104-106), the Secretary of Commerce approves standards and guidelines that are developed by the National Institute of Standards and Technology (NIST) for Federal computer systems. These standards and guidelines are issued by NIST as Federal Information Processing Standards (FIPS) for use government-wide. NIST develops FIPS when there are compelling Federal government requirements such as for security and interoperability and there are no acceptable industry standards or solutions. General Information, http://www.itl.nist.gov/fipspubs/geninfo.htm (Last Modified Aug. 30, 2001).
• NIST Special Publication 800-10, Keeping Your Site Comfortably Secure: an Introduction to Internet Firewalls (Feb. 1995), which "provide[s] a basis of understanding of how firewalls work and the steps necessary for implementing firewalls." Id. at ix;
• NIST Special Publication 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems (Sept. 1996) which "provides a baseline that organizations can use to establish and review their IT security programs." Id. at 1. In the most recent version of the Information Technology Security Program covering OIRM activities, the Department of the Interior acknowledges that "NIST SP 800-14 provides the foundation for meeting the minimum requirements for the protection of Federal IT systems and hosted data." The Office of the Assistant Secretary Indian Affairs Information Technology Security Program Version 1.1, May 17, 2001 at 4;
• NIST Special Publication 800-12, Introduction to Computer Security: the NIST Handbook (Oct. 1995) which "provides assistance in securing computer-based resources (including hardware, software, and information) by explaining important concepts, cost considerations, and interrelationships of security controls. It illustrates the benefits of security controls, the major techniques or approaches for each control, and important related considerations." Id. at 3;
• NIST Special Publication 800-16, Information Technology Security Training Requirements: A Role and Performance Based Model (April 1998), which provides a framework for IT Security Training that is both "appropriate for today's distributed computing environment and [flexible] for extension to accommodate future technologies and the risk management decisions." Id. at 4;
• NIST Special Publication 800-18, Guide for Developing Security Plans for Information Technology Systems (Dec. 1998), which "show[s] what should be done to enhance or measure an existing computer security program or to aid in the development of a new program." Id. at 2;
• NIST Special Publication 800-27, Engineering Principles for Information Technology Security (A Baseline for Achieving Security) (June 2001), which presents "a list of system-level security principles to be considered in the design, development, and operation of an information system." Id. at 1;
• NIST Special Publication 800-31, Intrusion Detection Systems (Aug. 2001), which is a "primer in intrusion detection, developed for those who need to understand what security goals intrusion detection mechanisms serve, how to select and configure intrusion detection systems for their specific systems and network environments, how to manage the output of intrusion detection systems, and how to integrate intrusion detection functions with the rest of the organizational security infrastructure." Id. at 5;
• FIPS Publication 31, Guidelines for ADP [Automatic Data Processing] Physical Security and Risk Management (June 1974), which "provides a handbook for use by Federal organizations in structuring physical security and risk management programs for their ADP facilities." Id. at 1;
• FIPS Publication 73, Guidelines for Security of Computer Applications (June 1980), which describes "methods and techniques that can reduce the hazards associated with computer applications." Id. at 1;
• FIPS Publication 83, Guideline on User Authentication Techniques for Computer Network Access Control (Sept. 1980), which "provides guidance in the selection and implementation of techniques for authenticating the users of remote terminals in order to safeguard against unauthorized access to computers and computer networks." FIPS Publications, http://www.itl.nist.gov/fipspubs/by-num.htm (Last Modified July 3, 2001);
• FIPS Publication 87, Guidelines for ADP Contingency Planning (March 1981), which "describe for organizational and data processing management, and for managers who obtain data processing services from other activities, what should be considered when developing a contingency plan for an ADP facility." Id. at 1;
• FIPS Publication 102, Guidelines for Computer Security Certification and Accreditation (Sept. 1983), which "describes how to establish and carry out a certification and accreditation program for computer security." Id. at 1;
• FIPS Publication 112, Password Usage (May 1985), which "establishes the basic criteria for the design, implementation and use of a password system in those systems where passwords are used." FIPS Publication 112, http://www.itl.nist.gov/fipspubs/fip112.htm#FORE_SEC (Visited Nov. 7, 2001);
• FIPS Publication 191, Guidelines for the Analysis of Local Area Network Security (Nov. 1994), which "discusses threats and vulnerabilities and considers technical security services and security mechanisms" for Local Area Networks. FIPS Publication 191, http://www.itl.nist.gov/fipspubs/fip191.htm (Visited Nov. 7, 2001).V. REPORTS EVALUATING INTERIOR'S IT SECURITY PROGRAM
To date, there have been at least 30 reports generated by both governmental and private organizations including the Office of the Inspector General ("OIG"), the General Administration Office ("GAO"), a House of Representatives Subcommittee, Arthur Andersen Co. ("Andersen"), SeNet International ("SeNet"), the Special Master and Predictive Systems, Incorporated ("Predictive") which have addressed the state of IT Security at the DOI. A detailed review of these reports, findings, and where applicable, recommendations, is a necessary predicate to evaluating the current state of IT Security and recommending a course of action.
A. Arthur Andersen Co. Reports
The first known reports generated by a private organization addressing Interior's IT Security issues were those published by the public accounting firm of Arthur Andersen Co. The first of these reports — a Report of Independent Public Accountants — was issued on March 23, 1989 to the Bureau of Indian Affairs following an audit of the assets, liabilities and fund balances of the Public Monies of the United States managed by the BIA. On May 11, 1990, Andersen issued a second Report auditing the assets and trust fund balances of the Tribal and Individual Indian Monies Trust Funds controlled by the BIA.
1. Arthur Andersen Co. Reports: Findings
Andersen found that:
Report Date Report Title Problem Page 1989 Report of Independent "Data processing controls throughout the Bureau cannot be 8 Public Accountants relied upon to ensure that data are being properly processed. Data processing is conducted at various locations throughout the Bureau, and, at certain locations, there are inadequate controls over systems and data, inadequate segregation of duties, and deficiencies in controlling systems development." "System errors were found for which no corrective action had 50 been taken." "The NTSC [National Technical Support Center] does not 57 have a current disaster recovery plan." "On Saturday morning February 11, 1989, an outside auditor 59 was able to achieve unauthorized access to the NTSC programming and management areas. The design of the door to the NTSC allowed unauthorized access outside the normal work hours to the programming and management areas. There is an alarm on the door that goes off when the door is opened by unauthorized personnel during the normal workday. However, on the above mentioned date, the alarm did not go off." "Each IMC [Information Management Center] is limited as to 59 the number of people that can be employed. As a result, it is difficult to segregate duties between computer specialists (programmers), computer assistants and operators. During our review of the IMC's, we noted that computer specialists have the ability to access and alter master data files, application systems programs and certain operating system programs." Report Date Report Title Problem Page "The ability of the computer specialists to access and alter the 60 master data files and the application files permits the programmers the ability to compromise the integrity of the data and data processing. A computer specialist has the ability to create a new account, transfer funds to the account and process a check. Further, alterations to IRMS programs could be made to allow the checks to be printed, but not recorded on the check register." "Discussions with computer specialists indicated that minor 61 changes requested by users do not require IMC manager approval to be made. Unauthorized changes to the IRMS programs could be made that may reduce the integrity of the data and the processing." "Discussions with computer specialists indicated that there 62 are no formal testing procedures. In addition, we were made aware that certain testing is performed using actual `live' data in the production mode." "Through discussions with various personnel, we noted the 63 operators, computer assistants and computer specialists all had access to various password files." "A periodic maintenance and inspection contract for the Halon 65 fire control system is not in place." "The daily tape backup library is not adequately fire protected. 65 While most tape libraries are located adjacent to the computer operations room . . . in some instances, there was not fire protection in the tape room itself." 1990 Report of Independent "Data processing controls throughout the Bureau cannot be 9 Public Accountants relied upon to ensure that data is properly processed." "Management indicated [access controls over master data 26 files] is still a problem due to the small number of personnel and the security system available for the hardware." "Presently, the policy of changing passwords every 30 days 26 has been implemented at the NTSC but is not fully effective at the IMCs." 2. Arthur Andersen Co. Reports: RecommendationsThe 1989 Andersen Report recommended that:
1. "a disciplined controllership function [be imposed]: Summary reports of activity and cumulative balances of the Trust Funds . . . be reviewed by management personnel who are familiar with financial reports and generally accepted accounting principles, as they apply to the Trust Funds; Procedures and controls must be developed and then followed to ensure that accounting entries which impact the Trust Funds are properly reviewed. These procedures and controls must be adequate to ensure that all activities at Area and Agency Offices are properly reviewed; The various accounting systems and subledgers used by the Bureau must be reconciled to each other and discrepancies must be resolved. [T]he systems currently being used must be reconciled to ensure the integrity of information currently being processed by the Bureau." Arthur Andersen Co. Report of Independent Public Accountants (March 23, 1989) at vii.
2. "an audit process [be implemented] to verify that controls and procedures are functioning effectively and that recorded balances are accurate: a. An internal audit function should be established to provide an ongoing review of compliance with controls, procedures and regulations. The internal audit group should communicate with upper management or an oversight group to maintain independence from operations and accounting personnel; b. An annual audit by independent public accountants should continue to be performed. The independent annual audit provides an objective view of the organization, its controls and procedures and financial accounting policies." Id. at vii.
3. "Area Offices reflect each Agency Office's results of operations should be analyzed on a monthly basis for trends and unusual fluctuations and reconciled to other sources, as appropriate." Id. at 30.
4. "accounts be established in the general ledger and IRMS systems to track receipts and disbursements activity, similar to the general ledger accounts established for the Tribal Trust Fund." Id. at 30.
5. "in order to ensure a more accurate balance in both IRMS and the Finance System, system errors should be promptly corrected when these errors are discovered." Id. at 50.
6. "a computer programming change be made to reflect proper cut-off on the account statements." Id. at 50-51.
7. "the CV [collection voucher] number log and official report file be reviewed weekly so that such errors can be caught and corrected. On a Bureau-wide level, CV's should be prenumbered and issued by the Central Office-West, and control should be maintained at the Area Office level. This would provide uniformity throughout the Bureau, and more centralized control." Id. at 51.
8. "all Agency Offices implement the IRMS system and train employees on the use of the system." Id. at 52.
9. "the Bureau . . . consider providing teams that assist with the implementation and training of IRMS capabilities." Id. at 52.
10. "upon notification of death, the management code be appropriately changed." Id. at 53.
11. training be provided to IIM clerks "in the various account codes and their meaning." Id. at 53.
12. "the Agency Superintendent assure that all name, address and management code changes were input properly by reviewing a summary of changes report." Id. at 53.
13. "NISC develop and test a workable disaster recovery plan. The disaster recovery plan developed should, at a minimum, address the following issues: Levels of response to several possible disasters; Hardware requirements; Remote processing requirements Telecommunications requirements; Data-entry support; Operating system support; Other systems software; Application systems software; Data file storage and retention; Forms; System operation procedures; User procedures; Staff responsibilities; Plan maintenance." Id. at 57-58.
14. "NTSC consider establishing a full-time ADP internal audit function to help ensure that ADP internal controls are in place and operating effectively. The internal auditor should report to a high level of management that has no routine ADP responsibilities but has authority over NTSC and has a good understanding of ADP operations." Id. at 58
15. "NTSC management implement a procedure to verify that the above mentioned door alarm is operating effectively outside of the normal work hours or provide another means of security to prevent access." Id. at 59.
16. "master data files be password protected. The control of the master data passwords should be placed in the hands of the data owner or a security officer. If access to master data files by IMC personnel is required, the access should be requested from the data owner, i.e., user. In addition, computer specialists should be given access only to test versions of the application programs. The production version should be controlled by password. Access to the production version should be given to the IMC manager, who should have the responsibility of transferring programs to the test area, and back to production after modification, testing and review procedures have been performed. This segregation of duties could be accomplished by placing access passwords on different user packs." Id. at 59-60.
17. "in conjunction with [the] recommendation on the segregation of duties, the IMC manager review and approve all modifications prior to transferring the modified programs back to production." Id. at 60-61.
18. "[a]ll modifications made to programs or data files . . . be approved by the IMC manager prior to being made and then reviewed by the manager after being made and prior to placing them into production." Id. at 61.
19. "a test environment be defined for each system, and that formal testing procedures be put in place. The procedures should be tailored to include small as well as large modifications. At a minimum, testing should be performed in a section of the computer not related to the production section. Formal testing procedures allow a structure for adequate and consistent testing. Testing procedures should include the following: Test all known combinations including realistic volume estimates; Test using user prepared test data; Perform complete and comprehensive testing prior to moving the application into production; Test all interfacing systems to evaluate the integrity of the interface; Develop conversion procedures to assure proper cutoffs and conversion of data files; Test user procedures and other manual procedures; Perform tests only on test files; Establish a standard naming convention for all test programs; Have user and ADP management approve the test results prior to conversion to a new application system." Id. at 61-62.
20. "even more emphasis be placed on ensuring the users are involved in all phases of application modifications, i.e., planning, implementation and testing." Id. at 62-63.
21. "a policy be developed which requires a periodic change of the user passwords. We further recommend the users be instructed to request a password change whenever they believe their password has been compromised." Id. at 63.
22. "the password files be protected to allow only designated personnel to access and modify these passwords. We further recommend the application passwords be controlled by the user departments." Id. at 63-64.
23. "[t]he disaster recovery plan . . . be tested. All phases of the plan, including offsite processing, should be made part of the test. The test should be rehearsed and controlled to maximize the learning value of the employees." Id. at 64.
24. "each IMC obtain a contract that would require a periodic maintenance and evaluation of the Halon system by a qualified contractor." Id. at 65.
25. "fire protection be added to the tape libraries for both on- and off-site storage areas. This protection should include a separate Halon nossle [sic] and fire rated walls, floors and ceilings." Id. at 65.B. Office of the Inspector General Reports
Reports issued by the Department of the Interior's OIG represent the first reports published by the government exposing Interior's IT security deficiencies. Of those made available to the Special Master, nine provided information pertinent to trust data. Those reports analyzed:
1. Whether the Bureau of Indian Affairs National Irrigation Billing System "(1) had been adequately planned by the Bureau, (2) fulfilled the interface requirements of centralized accounting for the Bureau, (3) had effective controls, and (4) could be used to bill for all irrigation projects regardless of billing components." OIG Report No. 94-I-688: National Irrigation Billing System, Bureau of Indian Affairs at 1 (June 1994);
2. "[T]he Statement of Assets and Trust Fund Balances for the Tribal, Individual Indian Monies and Other Special Appropriation Funds managed by the U.S. Department of the Interior Bureau of Indian Affairs Office of Trust Funds Management (`OTFM') as of September 30, 1995." OIG Report No. 97-I-196: U.S. Department of the Interior Bureau of Indian Affairs Tribal, Individual Indian Monies and Other Special Appropriation Funds Managed by the Office of Trust Funds Management at 1 (September 30, 1995);
3. The general controls at the Operations Service Center including "controls for security program development, access, software development and change control, segregation of duties, system software, and service continuity as they relate to the two mainframe computers and to Center operations." OIG Report No. 97-I-771: General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs at 2 (April 1997);
4. The Mineral Management Service's "six major areas: security program development; logical and physical access; software development and change management; separation of duties; system software; and service continuity." OIG Report No. 98-I-336: General Controls Over the Automated Information System, Royalty Management Program, Mineral Management Service at 3 (March 1998);
5. "[T]he actions taken by Bureau management to implement the 13 recommendations made in [the] April 1997 audit report." OIG Report No. 98-I-483: Followup of General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs at 2 (June 1998);
6. The "actions taken by Bureau management to implement the 12 recommendations contained in [the] April 1997 audit report and the 8 recommendations contained in [the] June 1998 audit report and a review of the general controls in place during fiscal year 1998." OIG Report No. 99-I-454: Followup of Recommendations for Improving General Controls Over Automated Information Systems, Bureau of Indian Affairs at 2 (July 1999);
7. "[T]he statements of assets and Trust Funds balances and the statements of changes in Trust Funds balances for Tribal and Other Special Trust Funds and for Individual Indian Monies Trust Funds as of and for the fiscal years ended September 30, 1998, and 1997." OIG Report No. 00-I-434: Independent Auditors Report on the Financial Statements for Fiscal Years 1998 and 1997 for the Office of the Special Trustee for American Indians Tribal and Other Special Trust Funds and Individual Indian Monies Trust Funds Managed by the Office of Trust Funds Management at 5 (May 2000);
8. "[T]he financial statements of the Office of the Special Trustee for American Indians." OIG Report No. 01-I-205: Independent Auditors Report on the Financial Statements for Fiscal Years 1999 and 1998 for the Office of the Special Trustee for American Indians Tribal and Other Special Trust Funds and Individual Indian Monied Trust Funds Managed by the Office of Trust Funds Managements at 2 (January 2001);
9. "[T]he Bureau of Indian Affairs' (BIA) principal financial statements for the fiscal year ended September 30, 2000." OIG Report No. 01-I-385: Independent Auditors Report on the Bureau of Indian Affairs Financial Statements for Fiscal Year 2000 at 2 (May 11, 2001).1. Office of the Inspector General: Findings
Concerns about IT Security at the BIA first surfaced in the June 1994 audit report generated by the OIG. That report, and others that followed, exposed shortcomings relative to breaches in physical security, personnel security and data security:
While the OIG Final Audit Report to the BIA generated on September 27, 1988 references an "ongoing review of automated data processing activities within the Bureau of Indian Affairs," specific mention of IT security did not surface until the 1994 Report.
RACF ("Resource Access Control Facility") reports are reviewed as a form of system auditing. See OIG Report No. 97-I-771 at 5.
Five of the OIG reports discussed above recommended that:
1. the BIA "ensure the Bureau has the ability to efficiently and effectively recover operations in order to reduce both the risk of financial loss and the level of disruption to the Bureau and its Area offices. Recovery from government agencies with compatible systems is a viable option; however, tests of such arrangements should be performed to identify potential compatibility or capacity problems." OIG Report No. 97-I-196, Report of Independent Public Accountants on Internal Control Structure (December 39, 1996) at 37.
2. the BIA "evaluate options to increase the level of security controls implemented. Those controls identified in the observation should be taken into consideration. We also suggest that only those individuals with system administrator designation be allowed to reset passwords." Id. at 38.
3. the BIA "evaluate the cost/benefit of developing a segregated test and production environment on the Unisys. Separate environments will assist in maintaining the integrity of the data and the production application. Procedures should be implemented requiring the review of all application changes by a technical individual other than the programmer. At a minimum, each of the two IIM programmers should review the work of the other and document approval before Data Management places the application into production." Id. at 38.
4. "Because the OTFM is currently in the process of investigating, and later implementing a new IIM system, a computer conversion is again anticipated. Due to the complexity and volume of the information carried on the IIM system, a systems consultant should be considered. A consultant would have the benefit of not having every day tasks to perform for the OTFM and could dedicate time to an initial and ongoing needs analysis, investigating and presenting alternative systems and rating their advantages and disadvantages. The consultant would also be able to assist in the implementation of the system and the training of OTFM personnel. Before another conversion is undertaken, the OTFM should complete a detailed plan noting who will be involved, what each individuals' responsibilities will be, and their corresponding deliverables." Id. at 39.
5. The BIA "ensure that: 1. The automated information system security function is elevated organizationally to at least report directly to the Director, Office of Information Resources Management; is formally provided with authority to implement and enforce a Bureauwide system security program; and is provided staff to perform the required duties, such as providing computer security awareness training and performing periodic risk assessments; 2. A system security program is developed and documented which includes the information required by the Computer Security Act of 1987 and Office of Management and Budget Circular A-130, Appendix III, and that policies and procedures are implemented to keep the system security program current; 3. The Bureau's security personnel perform risk assessments of the Bureau's automated information systems environment and, as appropriate, provide assurance that the necessary changes are implemented to manage the risks identified." OIG Report No. 97-I-771, Audit Report: General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs (April 30, 1997) at 10.
6. the BIA "ensure that personnel security policies and procedures are developed, implemented, and enforced, including those for obtaining appropriate security clearances for personnel in sensitive or critical ADP positions and for informing the security staff, in writing, whenever employees who are system users terminate their employment or are transferred." Id. at 12.
7. the BIA "develop and implement policies to classify Bureau's computer resources in accordance with the results of periodic risk assessments and guidance contained in Office of Management and Budget Circular A-130, Appendix III." Id. at 13.
8. the BIA "ensure that: 1. Sufficient staff are provided to adequately monitor all visitor activities; 2. Funding is provided for adequate maintenance of the computer operating room, such as providing daily housekeeping services, or that fire-producing equipment and supplies are removed from the computer room." Id. at 15.
9. the BIA "ensure that policies are developed and implemented which match personnel files with system users periodically, that user Ids are deleted from the system for users whose employment has been terminated, and that verification and approval are obtained from user supervisors and application owners or managers that the levels of access are appropriate." Id. at 16.
10. the BIA "ensure that a higher priority is given to moving the applications that reside on the UNISYS computer to the IBM computer." Id. at 17.
11. the BIA "ensure that policies and procedures are developed and implemented which clearly identify the individuals responsible and accountable for application development and changes." Id. at 18.
12. the BIA "ensure that staffing at the Center is evaluated and adjusted so that duties for critical system support functions are adequately segregated and fully utilized." Id. at 20.
13. the BIA "ensure that access and activities of the Center's system programmer are controlled and monitored by security staff and that RACF controls are established to protect system resources." Id. at 22.
14. the BIA "ensure that a contingency plan is developed and tested and that funding is provided for acquiring a secure off-site storage facility." Id. at 24.
15. the BIA "1. Ensure that risk assessments are conducted in accordance with guidelines which recommend that risk assessments support the acceptance of risk and the selection of appropriate controls. Specifically, the assessments should address significant risks affecting systems, appropriately identify controls implemented to mitigate those risks, and formalize the acceptance of the residual risk; 2. Formally assign and communicate responsibility to local area network administrators to participate in risk assessments and ensure compliance with the Program's security policy; 3. Determine the risks associated with local area network applications and personal computer databases which contain proprietary and financial data and, based on the results of the risk assessments, establish appropriate security policies and procedures." OIG Report No. 98-I-336, General Controls Over Automated Information Systems, Royalty Management Program, Minerals Management Service (March 24, 1998) at 10.
16. the BIA "1. Evaluate Systems Management Division and contractor ADP positions to determine position sensitivity in relation to risk and ADP factors. Also, assurance should be provided that automated information system work is technically reviewed by persons whose position sensitivity levels are greater than the position sensitivity levels of the employees who are performing the work; 2. Establish controls to ensure that the contractor is fulfilling its contractual obligation of submitting requests for background checks within the specified time frame and that contractor employees who are in probationary status and awaiting security clearances are not performing critical ADP work; 3. Establish controls to ensure that personnel or security files accurately reflect that background checks and periodic followup background check are performed as required." Id. at 14-15.
17. the BIA "establish controls to enforce Program policy which requires employees to sign security awareness statements before access to system resources is approved by the Installation Automated Information System Security Officer." Id. at 17.
18. the BIA "1. Ensure that individual computer resources are classified based on the level of sensitivity associated with each resource; 2. Evaluate controls over resources to ensure that the access controls have been implemented commensurate with the level of risk and sensitivity associated with each resource." Id. at 20.
19. the BIA "implement controls to enforce Program policy that default user Ids and passwords are to be removed from the automated information system when commercial off-the-shelf software is implemented." Id. at 22.
20. the BIA "1. Evaluate the current Program policy which only recommends that passwords contain a mix of letters and numbers for all automated information system components. Implement, if the Program determines that a mix of letters and numbers should be required, the security software option within RACF that would enforce this requirement. If the Program determines that a mix of letters and numbers is not required, the risk should be addressed in the risk assessment; 2. Develop and implement centralized security administration for the local area networks used by the Program's divisions that contain proprietary and financial data." Id. at 25.
21. the BIA "1. Implement controls to ensure that access managers approve all access to their applications in accordance with Program policy; 2. Document procedures which require that users' access levels be reviewed periodically or that employees be recertified to ensure that the levels of access granted are appropriate for the duties assigned to the users." Id. at 27.
22. the BIA "evaluate the need to deviate from the Departmental standard for the number of unsuccessful log-in attempts. If the Program determines that this number should remain at five, Program management should request, from the Department, a waiver from the standard of three attempts." Id. at 29.
23. the BIA "enforce its procedures for authorizing, approving, and testing client server application software before the software is moved into production." Id. at 30.
24. the BIA "1. Implement controls to ensure that application programmers do not have access to the production client/server application data or the capability to update/change these data; 2. Improve detection controls by ensuring that management or the Installation Security Officer reviews server security logs periodically." Id. at 33.
25. the BIA "ensure that the upgraded version of RACF is implemented immediately if the Program is granted a waiver from consolidating its mainframe operations with another mainframe operation." Id. at 35.
26. the BIA "1. Evaluate acquiring system verification and auditing software; 2. Implement the system options to record activities in the SYSLOG during the system initialization process and develop and implement procedures to ensure that periodic reviews of the SYSLOG for unauthorized or inappropriate activities are performed and that unauthorized or inappropriate activities are reported to Program management; 3. Evaluate the available SMF record typed and implement procedures to ensure that critical SMF logs are reviewed periodically and that Program management addresses the problems identified." Id. at 38.
27. the BIA "update the disaster recovery plans to include all mission-critical systems." Id. at 40.
28. the BIA "develop and implement written policies and procedures defining appropriate system security, physical access, documentation standards, password controls and disaster recovery plans including, but not limited to the following: a) System generated security reports are periodically run and reviewed for unusual activity; b) Immediate revocation of access upon termination, retirement or transfer of an employee (should be part of employee check out procedure); c) Periodic review of issued cards and access levels for staff changes; d) Granting access only to those individuals whose job function requires access on a routine basis; e) Documentation that discloses trust system user codes and passwords be in a secured location at all times; f) Passwords be periodically changed; g) Every user code be readily identified to a specific user; h) A full test of the disaster recovery plan should be performed as soon as possible." OIG Report No. 01-I-434, Independent Auditors Report on the Financial Statements for Fiscal Years 1998 and 1997 for the Office of the Special Trustee for American Indians Tribal and Other Special Trust Funds and Individual Monies Trust Funds Managed by the Office of Trust Funds Management (May 22, 2000) at 56.
29. the BIA "establish and implement policies and procedures to ensure that physical inventories of property, plant, and equipment are accurate and complete; acquisitions and disposals are timely and accurately recorded; adequate supporting documentation is maintained; completed construction projects are timely transferred to the appropriate accounts; depreciation expense is timely and accurately recorded; and errors in the Fixed Asset Subsystem are timely identified and corrected." OIG Report No. 01-I-385, Independent Auditors Report on the Bureau of Indian Affairs Financial Statements for Fiscal Year 2000 (May 11, 2001) at 7.
30. the BIA "establish and implement the controls necessary to ensure that adjusting journal/accounting entries are properly recorded in the appropriate general ledger control accounts and that financial information integrity reviews, reconciliations, and corrections are performed to ensure the accuracy and reliability of reported financial information." Id. at 9.
31. the BIA "develop and implement procedures to strengthen the reported internal control weaknesses over automated information systems." Id. at 13.
32. The BIA "establish and implement policies and procedures for conducting periodic condition assessment surveys and estimating deferred maintenance needs, including the requirement that the data and methodologies used to compute the estimate be documented, reviewed, and approved at the appropriate management levels." Id. at 15.
33. The BIA "establish and implement stewardship and performance measure management systems that include the control procedures necessary to ensure the timeliness, completeness, reliability, and availability of stewardship and performance measure information, including all supporting documentation and listings." Id. at 17.
34. The BIA "develop and implement procedures that ensure compliance with the Chief Financial Officers Act of 1990, Debt Collection Improvement Act of 1996, OMB Circular A-11, Prompt Payment Act, and Federal Financial Management Improvement Act of 1996, including managerial cost accounting management and reporting requirements." Id. at 21.C. General Accounting Office Reports
The next series of reports assessing the state of Interior's IT Security were the two issued by the GAO. Those: (1) "evaluate the Department of the Interior's effort to acquire and develop" TAAMS, GAO Report GAO/AIMD-00-259, Indian Trust Funds: Improvements Made in Acquisition of New Asset and Accounting System But Significant Risks Remain (September 2000) at 1; and (2) "evaluate the Department of Interior's High-Level Implementation Plan . . . for improving its management of the Indian trust funds and resources under its control." GAO Report No. GAO/AIMD-99-53, Indian Trust Funds: Interior Lacks Assurance That Trust Improvement Plan Will Be Effective (April 28, 1999) at 1.
1. General Accounting Office Reports: Findings
With respect to IT security, the GAO found that:
Report Report Title Problem Page Date April Indian Trust Funds: Interior "did not clearly specify all of BIA's 11 1999 Interior Lacks requirements, including its functional, security, Assurance That Trust and data management requirements. For example: Improvement Plan Will While Interior stated that the system `shall Be Effective include safeguards against conflicts of interest, abuse or self-dealing,' it did not define these terms. A definition of these terms in the context of Indian trust operations is necessary to design and determine the adequacy of proposed system safeguards and approaches. In discussing system security, Interior (1) specified an inappropriate technology encrypting data, (2) did not specify how long system passwords should be, and (3) did not require password verification features." "In acquiring its new TAAMS service, Interior 12 did not carry out critical risk management steps. First, Interior did not develop a risk management plan. Without this plan, Interior has no disciplined means to predict and mitigate risks, such as the risk that the service will not (1) meet performance and business requirements, (2) work with Interior's systems, and/or (3) be delivered on schedule and within budget." September Indian Trust Funds: "Interior has not yet completed actions designed 2 2000 Improvements Made in to enhance overall trust fund management, Acquisition of New including its efforts to revamp policies and Asset and Accounting procedures for the entire trust management cycle System But Significant and to address long-standing internal control Risks Remain weaknesses." Report Report Title Problem Page Date "[T]here were serious flaws in the way Interior 7 was planning and conducting its system tests (which verify that a system satisfies functional requirements) and its first set of user acceptance tests (which verify that the system operates correctly with operational hardware and meets user needs). Without following a disciplined testing processes, Interior could not ensure the successful implementation of TAAMS. In particular, test plans were flawed because they were designed with the assumption that no errors would be found. They also did not include tests of invalid and unexpected conditions — known as boundary testing. . . . Furthermore, some obvious problems/defects that occurred as the tests were conducted were ignored because testers assumed that the unanticipated results were attributable to eccentricities or malfunctions of the computing platform rather than to defects in the system being tested." "Interior has not reengineered business 12 processes which TAAMS is being designed to support even though these processes use an older and a very different system environment. Until it does so, Interior will not be able to maximize the benefits that can be gained from TAAMS, and it may perpetuate outmoded ways of doing business." "Many of the internal controls now being 15 reviewed by Interior — such as segregation of duties, supervisory review, system security, and project payment management — relate to requirements that should have been defined early in the TAAMS effort. Because they were not defined early by Interior, TAAMS was developed based on the current control environment, long known to be inadequate. As a result, like the policies and procedures effort, Interior may have to modify TAAMS after deployment to accommodate new controls, thereby increasing development risks and costs. Also, until adequate internal controls are in place to ensure the accuracy, availability, and completeness of trust fund data, Interior will not be able to fully ensure the integrity of TAAMS on an ongoing basis." Report Report Title Problem Page Date "Not having a complete information systems 16 architecture to guide TAAMS and other projects under its improvement effort will continue to be a major challenge for Interior." "While the absence of an architecture does not 17 guarantee the failure of TAAMS or other system modernization efforts, it does greatly increase the risk that Interior will spend more money and time than necessary to ensure that its systems are compatible with each other and in line with business needs." 1. General Accounting Office Reports: RecommendationsIn each of its reports, the GAO recommended that:
1. "before making major investments in information technology systems to support trust operations, the Secretary direct the Chief Information Officer to develop an information systems architecture for Indian trust operations that (1) provides a high-level description of Interior's mission and target concept of operations, (2) defines the business functions to be performed and the relationships among functions; the information needed to perform the functions; the users and locations of the functions and information; and the information systems needed to support the department's business needs, (3) identifies the improvement projects to be undertaken, specifying what they will do, how they are interrelated, what data they will exchange, and what their relative priorities are, and (4) details specific standards and approaches that will be used to build or acquire systems, including hardware, software, communications, data management, security, and performance characteristics." GAO Report No. GAO/AIMD-99-53, Indian Trust Funds — Interior Lacks Assurance That Trust Improvement Plan Will Be Effective (April 1999) at 14.
2. "the Secretary of the Interior direct the Chief Information Officer to (1) clearly define and validate functional requirements, security requirements, and data management requirements, (2) develop and implement an effective risk management plan, and (3) ensure that all project decisions are based on objective data and demonstrated project accomplishments, and are not schedule driven." Id. at 14.
3. "the Secretary of the Interior direct the Assistant Secretary for Indian Affairs to work with the Special Trustee for American Indians to do the following before phase II of TAAMS: Examine and revise business processes supported by TAAMS; Properly develop and implement data conversion plans; Evaluate and revise policies, procedures, and internal controls relating to TAAMS; ensure that top trust fund managers across the department participate in this effort; and ensure that any needed modifications to TAAMS are made and tested." GAO Report No. GAO/AIMD-00-259, Indian Trust Funds: Improvements Made in Acquisition of New Asset and Accounting System But Significant Risks Remain (September 2000) at 20-21.
4. "the Secretary of the Interior direct the Chief Information Officer to do the following before Phase II of TAAMS: A) Evaluate existing software development and acquisition processes against the Capability Maturity Models developed for these activities by the Software Engineering Institute; implement disciplined processes where they are lacking; and regularly assess progress in this regard; B) Ensure that contractors used by Interior to develop software systems have implemented discipline software development processes; C) Define and manage the requirements that TAAMS should meet using accepted processes. Once the requirements have been adequately defined, perform a gap analysis to assess whether TAAMS is capable of providing the necessary functionality and what modifications, if any, are necessary to address Interior's needs. If modifications are needed, then Interior should develop the cost, schedule and performance impacts of making those modifications." Id. at 21.
5. "the Secretary . . . develop an information system technology architecture for trust fund operations. In the interim, we recommend that the Secretary direct the Chief Information Officer to (1) perform an analysis of the infrastructure necessary to support the TAAMS application and ensure its adequacy and (2) ensure that TAAMS can interface with TFAS and MMS systems." Id. at 21.D. Computer Security Report Card
On September 11, 2000, the House of Representatives Subcommittee on Government Management, Information, and Technology, Committee on Government Reform, chaired by Congressman Stephen Horn (R-Ca), issued its Computer Security Report Card. The Report Card represented the first ever comprehensive study of computer security throughout the Executive Branch. See Computer Security Report Card Hearing Before the Subcomm. on Gov't Management, Information, and Technology of the Comm. on Gov't Reform, House of Representatives, 106th Cong., 1-2 (2000) ("Computer Security Report Card"). Horn assigned grades based on self-reported answers to Subcommittee and General Accounting Office (GAO) questions.Id. at 12. The Subcommittee's overall grade for the federal government's information security was a "D-." Id. at 16.
The Report Card focused on six areas of computer security including: (1) Security Program Plan (the implementation and monitoring of agency-wide security program to manage risk); (2) Access Control (the ability to limit or detect unauthorized logical or physical access to computer resources); (3) Change Control (the ability to control unauthorized programs or program changes); (4) System Software (the ability to limit and monitor access to programs that control or secure computers and applications; (5) Segregation of Duties (the ability to limit individual responsibilities for key aspects of computer-related operations; and (6) Service Continuity (the ability to implement a plan to continue critical operations and protect data if unexpected events occur). Computer Security Report Card at 15.
1. Computer Security Report Card: Findings
Of the 24 major federal agencies studied by the Horn Subcommittee, the Social Security Administration (B) and the National Science Foundation (B-) earned the highest grades. The Commerce, Education, State, Housing and Urban Development departments and the Agency for International Development, received grades of C or C-, and the Defense and Treasury departments, as well as the Environment Protection Agency, General Services Administration and NASA, received grades of D+, D and D-, respectively. Among those agencies receiving an incomplete grade due to lack of information were the Department of Energy, the Nuclear Regulatory Commission, the Department of Transportation and the Federal Emergency Management Agency. Computer Security Report Card at 7-8.
An agency received a grade of "incomplete" if it did not fully complete a report. Computer Security Report Card at 7-8.
The Office of Personnel Management received an F grade, along with the Justice, Labor, Agriculture, Health and Human Services Departments, the Small Business Administration and the Department of the Interior.
The Report Card does not individually score the Bureau of Indian Affairs.
In addition to the letter grade, Horn's committee rated the various agencies on a point basis. Out of a possible high of 100 points, Horn's grades were based on whether agencies had established entity-wide security programs (29 points), access controls (26 points), the ability to continuously provide service even when unexpected events occur (18 points), checks on unauthorized change in computer programs (12 points), limiting access to sensitive operating system files (12 points) and segregation of duties controls (3 points). Computer Security Report Card at 12. Interior received the lowest score of 17 while Labor received the second-lowest score of 38. Id. at 16.
John Dyer, CIO of the Social Security Administration, and a witness at the September 11 hearing, attributed his agency's relative success to "a longstanding tradition of assuring the public that their personal records are secure stakes are simply too high." Computer Security Report Card at 143. Department of the Interior CIO Daryl White testified that Interior was "making substantive progress to improve [its] computer security posture," id. at 155, but that Interior's "ability to completely implement an adequate computer security program is strongly dependent upon the availability of necessary resources." Id.
E. SeNet International, Inc. Reports
On December 7, 1999, then-Special Advisor to the Assistant Secretary for Indian Affairs Dominic Nessi commissioned SeNet to assess and evaluate the state of BIA's IT Security. The original contract was subsequently modified on 5 separate occasions. As set out in its final version, SeNet was tasked to:
SeNet, founded in June 1998, performs work for both government and commercial clients See June 1, 2001 Interview of SeNet President Toly Kozushin at 8.
The original contract and modifications indicate that it was executed between Digicon and the National Business Center (a component of the DOI) on behalf of the BIA. According to the Department of Justice, "[A] representative from SeNet advised that [Digicon and SeNet] are unrelated and that there is merely a subcontracting relationship between the two entities." November 6, 2001 Letter from Department of Justice Deputy Director Commercial Litigation Branch Sandra Spooner to Special Master Alan Balaran at 1.
• Perform an Independent Verification and Validation (IVV) of TAAMS Disaster Recovery Program, and deliver an IVV Report for a December 17, 1999 restoration test with recommendations, and an IVV Report for the June 1, 2000 restoration test with recommendations;
• Develop a TAAMS Disaster Recovery Plan and Disaster Recovery Procedures, and deliver a TAAMS Disaster Recovery Plan and a set of TAAMS Disaster Recovery Procedures;
• Examine and evaluate the physical security of Artesia's Data Center located in Addison, Texas, and deliver a Data Center Physical Security Report with recommendations;
• Examine, analyze and evaluate security policies and controls at the Artesia Data Center, and deliver a report on the adequacy of the Artesia Data Center network topology and boundary protection controls;
• Review and evaluate TAAMS end user access security, and deliver a TAAMS User Access Policies and Procedures report;
• Perform an analysis of TAAMS performance, and deliver a TAAMS Performance Test Results briefing and a TAAMS Wide Area Network bandwith requirements and topology recommendations;
• Propose solutions for improving TAAMS performance and implement an improvement pilot program at one regional office, and deliver a Proof of concept implementation and test report and a Pilot implementation report;
• Perform miscellaneous TAAMS-related activities, including attend TAAMS status meetings;
• Review BIANet Architecture and Performance, and deliver a report on BIANet Architecture and performance with recommendations, and document the status of the BIANet at the 12 BIA Regional Offices and the Albuquerque, New Mexico and Reston, Virginia Data Centers; and
• Assist in BIA security analysis and planning, and deliver BIA Information Security Policies and Procedures, System Security Plans for LRIS, IRMS, TAAMS, BIANet and major office LANs, and Proposed BIA Information Security Implementation Plan.See Order No. NBCWOP00179, Modification 5.
IVV in an abbreviation of "Independent Verification Validation."
The total cost of the contract was $995,505.22. Id. at 3.
In addition to generating the reports specified in the contract, SeNet also produced the following reports:
• Physical Security Implementation Guidelines, BIA Data Center, Reston, VA;
• Information Technology Risk Assessment Security Survey Report;
• Department of Interior Bureau of Indian Affairs Office of Information Resources Management Final Trust Systems Backup Procedures; and
• Vulnerability Analysis IRM Ely Parker Building, Reston, VA. All told, SeNet generated 18 reports describing IT security — 13 of which noted specific problems. These reports analyzed:
• "[T]he security requirements," the "management, operational, and technical controls in place and planned for meeting those requirements," and the "responsibilities and expected behavior of all individuals who access" TAAMS. TAAMS System Security Plan (July 6, 2001) at 3. A draft of this report was issued on February 15, 2001.
• "[T]he security requirements," the "management, operational, and technical controls in place and planned for meeting those requirements," and the "responsibilities and expected behavior of all individuals who access" the Integrated Records Management System ("IRMS"). IRMS System Security Plan at 3 (June 30, 2001). A draft of this report was issued on February 15, 2001.
• "[T]he security requirements," the "management, operational, and technical controls in place and planned for meeting those requirements," and the "responsibilities and expected behavior of all individuals who access" the Land Records Information System ("LRIS"). LRIS System Security Plan (June 30, 2001) at 3. A draft of this report was issued on either February 28, 2001 or May 21, 2001.
• "[T]he security requirements for" the BIA Wide Area Network, the "management, operational, and technical controls in place and planned for meeting those requirements," and the "responsibilities and expected behavior of all individuals who access" the network. BIANet System Security Plan (June 30, 2001) at 2. A draft of this report was issued on April 19, 2001.
• "[T]he security requirements for" the Reston Local Area Network, the "management, operational, and technical controls in place and planned for meeting those requirements," and the "responsibilities and expected behavior of all individuals who access" the network. Reston LAN System Security Plan, (June 30, 2001) at 2.
• Protecting the BIA "data center in Reston, VA against unauthorized physical access" and "environmental and disaster prevention measures." Physical Security Implementation Guidelines BIA Data Center, Reston, VA, (August 18, 2000) at 4. Drafts of this report were issued in February and August of 2000.
• "[P]rotect[ing] the TAAMS Data Center in Addison, TX against unauthorized physical access." Physical Security Implementation Guidelines TAAMS Data Center, Addison, TX, (June 16, 2000) at 4. A draft of this report was issued in either late May 2000 or early June 2001.
• "[I]ssues related to the Security Current State" and the "efforts [that] are required to reach the Security Desired State" at the Bureau of Indian Affairs. Information Technology Risk Assessment Security Survey Report, (January 4, 2000) at 4.
• "Establish[ing] and maintain[ing] adequate and effective security safeguards to ensure data privacy, confidentiality, integrity, and operational availability of all systems that process, store, or transmit information" and "preserv[ing] information processing integrity, reliability and availability to ensure that the data are accurate and relevant to meet commercial and administrative requirements." Information Technology Security Program, (February 15, 2000) at 5.
• "[P]olicies and procedures for controlling the operational aspects of users' access to the TAAMS application and its database." Trust Asset and Accounting Management System (TAAMS) User Access Security Policies, Guidelines and Procedures, Version 1.0, (July 6, 2001) at 4. A draft of this report was issued on February 2, 2001.
• "AS 400 and connectivity restoration activities, and Comdisco's and ATS's preparedness" for an Independent Verification and Validation of the TAAMS Disaster Recovery Program. Trust Asset and Accounting Management Systems (TAAMS) Independent Verification and Validation of TAAMS Disaster Recovery Program, (July 3, 2000) at 4.
• "[H]ow the data on [OIRM Trust data systems] will be backed up and restored (in the context of the official disaster recovery plan)." Department of Interior Bureau of Indian Affairs Office of Information Resources Management Final Trust Systems Backup Procedures,(May 17, 2001) at 1 .
• "[T]he effectiveness of security controls implemented to protect Trust data processed and stored on IT resources located within the boundaries of the Ely Parker building." Vulnerability Analysis IRM Ely Parker Building, Reston, VA, (July 15, 2001) at 12.1. SeNet International Reports: Findings
The cover date on the draft report indicates a February 28, 2001 issuance date; the interior pages indicate that the report was issued on May 21, 2001.
The cover date on the draft report indicates a May 26, 2000 issuance date, while the interior pages of the draft indicate a June 10, 2001 issuance date.
A Risk Assessment is a document containing "findings, recommendations and project information resulting from a security study" that "document[s] issues related to the Security Current State and to define the efforts that are required to reach the Security Desired State." IT Risk Assessment at 4.
In the Risk Assessment, the BIA Security Program, the TAAMS User Access Security Report and the IVV of TAAMS Disaster Recovery, SeNet issued the following findings:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXX.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
"BIOS" is an abbreviation for Basic Input Output System, which is an "essential set of routines in a PC, which is stored on a chip and provides an interface between the operating systems and the hardware."http://www.techweb.com/encyclopedia/defineterm?term=BIOS (Visited Nov. 9, 2001).
COTS ("Commercial-Off-The-Shelf") is defined as "ready-made merchandise that is available for sale." TechEncyclopedia, (visited Oct. 17, 2001) http://www.techweb.com/encyclopedia/defineterm?term=COTS.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
In the BIA IT Risk Assessment Report and the Vulnerability Analysis of the Ely Parker Building SeNet recommends that Interior/BIA/OIRM:
1. "[P]rotect the network perimeter with strategically located firewalls, begin utilizing encrypted tunnels (VPNs), and introduce means of strong authentication." SeNet International: Information Technology Risk Assessment, Security Survey Report (January 4, 2001) at 8.
2. "To increase the visibility of security issues and strengthen the authority, [elevate] the information security function should . . . in the organization to report to the BIA CIO." Id. at 8.
3. Evaluate and recommend "new technologies; [and initiate] periodic evaluation of information security posture by conducting security audits and risk assessments." Id. at 8-9.
4. "Develop an application sensitivity classification standard and related procedure." Id. at 9.
5. "Classify all major applications and general support systems relative to the sensitivity of data." Id. at 9.
6. "Make adjustments reflecting this classification in Information Security Policies and Procedures." Id. at 9.
7. "Develop security awareness training curriculum." Id. at 9.
8. "Conduct mandatory awareness training as a part of initial employee orientation and at least once a year afterwards (`refresher' courses)." Id. at 9.
9. "Conduct mandatory security policies and technology training for the OIRM technical staff." Id. at 9.
10. "Develop and implement DRP test procedures for each of major applications and general support systems." Id. at 10.
11. "Develop and enforce Bureau-wide policy requiring strong passwords and their periodic change." Id. at 11.
12. "Consider other means of strong authentication, such as smart cards in conjunction with PKI." Id. at 11.
13. "Establish on-line (electronic) Access Request Form utilizing digital certificates, and make appropriate process modifications." Id. at 11.
14. "Establish security-related Service Levels with each outsourcing service provider." Id. at 11.
15. "Add an entry on the form indicating the user's clearance status and level. Access privileges may be limited, permanently or temporarily, depending on this information." Id. at 11.
16. "Establish and enforce security related personnel policies and corresponding procedures including mandatory notifications of terminations and transfers." Id. at 11.
17. "Develop operational standards and provide specific training for system administrators to increase knowledge and awareness." Id. at 12.
18. "Set up a technical forum for system administrators. This forum (e.g. a mailing list, bulletin board, monthly meeting/conference calls etc.) will allow the exchange of information, address security concerns and develop/refine security operational procedures." Id. at 12.
19. "Create and publish Data Backup and Restoration Manual." Id. at 12.
20. "Implement off-site storage for LAN servers." Id. at 12.
21. "Design and implement a system of firewalls which will be used to establish `Trust Zones.' Examples of such Trust Zones may include Regional Offices, Agencies, Data Center, OIRM LAN, etc." Id. at 13.
22. "Develop a Bureau policy for consistent mandatory use of virus detection and removal software on all workstations and servers." Id. at 13.
23. "Develop and implement a procedure for regular updating of virus data files." Id. at 13.
24. "Develop a well thought through Bureau policy specifying acceptable use of Internet and e-mail, balancing business needs with employee's privacy." Id. at 13.
25. "Evaluate, select and implement a consistent means of contents monitoring and filtering." Id. at 13.
26. "Make employees aware of the policy, enforcement measures and consequences of non-compliance." Id. at 14.
"PKI" is an abbreviation for Public Key Infrastructure. PKI utilizes "certificate authority (CA), which issues digital certificates that authenticate people and organizations. TechEncyclopediahttp://www.techweb.com/encyclopedia/defineterm?term=PKI (Visited Nov. 9, 2001).
27. "Enforce the policy." Id. at 14.
28. "Establish encrypted tunnels (VPNs) between major BIA user locations." Id. at 14.
29. "Deploy secure client software on portable user workstations and at smaller offices (agencies) and use encryption on dial-up connections." Id. at 14.
30. "To simplify administration and take advantage of common infrastructure components, consider establishing BIA-wide public key infrastructure, including BIA Certificate Authority." Id. at 14.
31. "Develop and adopt a procedure to address this risk." Id. at 14.
32. "Augment monitoring and reporting capabilities with additional tools to make the process simpler and more efficient." Id. at 14.
33. "Develop definitions of information security related incidents." Id. at 15.
34. "Develop and implement procedures for responding to such incidents." Id. at 15.
35. "Train appropriate personnel in the use of incident response procedures." Id. at 15.
36. "Develop and approve the BIA Information Security Policies document covering all aspects of information protection." Id. at 15.
37. "Develop and implement Information Security Procedures Manual based on the policies." Id. at 15.
38. "Conduct continuous awareness training program." Id. at 15.
39. Evaluate "all interconnected resources, users groups, and sites is requires to determine the true vulnerability of Trust data in the Ely Parker Building." SeNet International: Vulnerability Analysis: IRM Ely Parker Building, Reston, VA (July 15, 2001) at 101.
40. Conduct "[a] risk analysis of BIA operations in the Ely Parker Building." Id. at 101.
41. "[I]nvestigate common business practices and data manipulation capabilities of privileged users." Id. at 101.
42. "[C]ommission a study to compare its IRM budget and staffing levels to similar size organizations. One DOI agency (e.g., MMS) and one non-DOI agency (e.g., Indian Heath Services of HHS) are examples of agencies that may be used in the study." Id. at 101.
43. "[C]ommission a study to determine workload assigned to each of its current and recommended new staff positions. The study shall identify competency level requirements, daily tasks, and tasks duration to formally justify the need to increase budgets and staff." Id. at 101.
44. "[D]esignate one office with overall authority and responsibility over all security aspects of IRM IT operations. This office shall have the proper funding for ensuring adequate security controls for all BIA IT operations as mandated by Government regulations. Alternatively, DOI shall define the roles and responsibilities of the various security offices within the department and its agencies so that they do not overlap or contradict each other, and that no security gaps are created." Id. at 101-102.
45. "[S]pecify how agencies should interact when dealing with inter-agency security issues. DOI shall provide guidelines for determining which agency shall be designated as the leading security authority when two or more agencies/bureaus are cooperating on a joint project." Id. at 102.
46. "[D]evelop a meaningful organizational chart and mission statements clearly identifying the chain of command, responsibilities and authorities." Id. at 102.
47. "[R]eview position descriptions to verify accurate descriptions of duties, eliminating overlaps or gaps." Id. at 102.
48. "[D]esign data center physical security controls to support effective operations and management." Id. at 102.
49. "[D]evelop and publish a Security Incident Handling Policy and corresponding procedures, specifying who is responsible for handling the various types of security incidents within the Reston facility." Id. at 102.
50. Inform "[a]ll employees at the Reston facility . . . about the assignment of security responsibilities. This assignment shall be documented in the policy manual. Specifically, all IRM employees shall receive security awareness training that will identify the Reston facility focal point for reporting security incidents." Id. at 102.
51. "[D]evelop and publish a policy for regional offices and agencies specifying security requirements for accessing and the use of IRM computing resources. The policy shall specify who has the authority to enforce security policies and procedures in the field offices, and the focal point for reporting security incidents." Id. at 102-103.
52. Rewrite "[p]osition descriptions for security-related positions . . . so that they reflect the organization's mission and so that they do not conflict or overlap with each other." Id. at 103.
53. Clearly specify in "[t]he position description . . . the qualification and competence level required to successfully fulfill the position duties as specified in the position description. It may be required to reassign or train existing personnel, or to hire new personnel to meet position's requirements for security related positions." Id. at 103.
54. "[I]dentify areas of expertise in the field of IT security mandatory for securing its operations in the Ely Parker Building. Examples of such areas include: Unisys NX security controls, determining minimum privileges levels for end-users, assigning privileges to Unisys NX users, using InfoGuard security features, using legacy application security features, Lotus notes security, Desktop security, communication equipment security controls, etc. BIA shall ensure (by training, hiring or contracting) that it possess the expertise needed for effective security operations." Id. at 103.
55. "[D]evelop a master plan identifying and defining the scope of documents needed to formulate security plans, policies, processes, and procedures and shall be responsible for developing them. The IRM shall inform the Office of the CIO which documented plans, policies, procedures, and processes it requires to ensure secure IT operations in the Ely Parker Building." Id. at 103.
56. "The Albuquerque Software Configuration Manager is on the BIA's payroll. [T]ask the Manager with rebuilding configuration management for the Reston Unisys." Id. at 104.
57. "[P]lace higher priority on deciphering and documenting software modules." Id. at 104.
58. "[E]stablish a mechanism that will allow only an applications's designated programmer and the configuration manager access to software modules." Id. at 104.
59. "Complete control over card keys allowing access into the data center and IRM facilities shall be assigned to IRM." Id. at 104.
60. Allocate "[a] physically secured space shall . . . to include all IRM employees and contractors who display, store or print Trust data." Id. at 104.
61. Establish "[a] field account management function . . . to effectively manage the Unisys user community. Account managers shall have the technical knowledge and proper automated tools needed for effective control of system level and application level accounts." Id. at 104.
62. "[A]nalyze the tasks performed by end users and determine the minimal level of privileges required for each job category. IRM shall acquire and install the tools that allow the assignment of minimal set of privileges to users. IRM shall review each and every active and valid Unisys account and assign to it the minimal set of privileges." Id. at 104.
63. Modify "[t]he Computer Access Request (CAR) form . . . to include requests for various privilege levels." Id. at 104.
64. "[I]nstitute processes, policies and procedures for enrollment and disenrollment, and specifically mandate field offices to report to IRM employees' terminations and transfers." Id. at 104-105.
65. "[D]evelop a safety and security policy manual for the Ely parker building, acceptable to both organizations." Id. at 105.
66. Delegate "[r]esponsibility for managing and maintaining data center physical security controls . . . to an on-site IRM employee." Id. at 105.
67. "[D]evelop a procedure requiring data center staff to conduct a beginning-of-day check of all data center security controls. A checklist shall be created and used to indicate the operational status of each control. The on-site BIA employee designated as the data center physical security officer shall review the checklist on a daily basis." Id. at 105.
68. Limit to OIRM "full and exclusive control over physical access to the Unisys room. No other organization shall have control over assigning physical access to this room." Id. at 105.
69. "[D]evelop policies and procedures for physical access into the data center and into the Unisys room." Id. at 105.
70. "[D]evelop a plan for implementing available, optional, and third party IT security controls for all its IT resources, including networking gear." Id. at 105.
71. "[D]evelop the necessary documentation and provide step by step operational instructions for managing and operating physical security controls in the facility." Id. at 105.
72. "[E]valuate the effectiveness of fraud detection mechanisms on the Trust data systems, and the possibility for a single, privileged individual to manipulate data without being detected." Id. at 105-106.
73. "[D]evelop a policy and procedures for its privileged users regarding access to Transaction and Master files." Id. at 106.
74. Document and evaluate "[f]ield business processes, in particular the Interface process, . . . from a security standpoint. The evaluation shall determine the possibility of misuse by data entry personnel." Id. at 106.
75. "[R]elocate to a secured zone that will provide physical protection for Trust data." Id. at 106.
76. Forbid programmers from "keep[ing] lists of User IDs and passwords (files or hard copies) in their work area. The only location where hard copies containing account IDs and passwords may be kept is inside the data center. After hours, such hard copies must be placed in a safe." Id. at 106.
77. Forbid programmers from "keep[ing] Trust data files on their hard disks or on removable media (e.g., floppies). IRM shall create a home directory for each programmer on the departmental server (which is housed inside the data center). IRM shall configure security access on home directories to allow Read, Write, Modify, and Delete operations only to the users." Id. at 106.
78. Upgrade "[p]rogrammers' workstations . . . to Windows 2000. IRM shall develop and enforce a security configuration policy for W2K workstations." Id. at 106.
79. Reengineer,"in consultation with MMS and OTFM, . . . the file transfer process for files containing Trust data to ensure secure transfers." Id. at 106.
80. "[R]estrict access to the directory containing the MMS file only to the Gas Oil programmer and individuals at the system administrator level." Id. at 107.
81. "[D]ocument its backup policy and procedures and shall address procedures for destroying failed or obsolete media containing Trust data." Id. at 107.
82. "[E]stablish a physically secured area where Trust data reports and other hard copy materials can be stored. An acceptable solution can be a file cabinet inside the data center." Id. at 107.
83. Restore "[d]irect communication . . . and [install] local alarms at the guard's station so that duress and alarms can be responded to immediately. The system's engineering design should be upgraded to minimize the risk of defeat. Finally, advanced features should be integrated to enhance the level of security that is required at the BIA Data Center. A longer-term solution to the security system upgrade would be include an advanced multi-site security management, under government control, that will facilitate enterprise-level security of the BIA Data Center, the building security, and other related/connected facilities. Such a system would allow the BIA Security managers to maintain central control of their entire integrated security system, while allowing regional offices to maintain independence and autonomous operations of their respective regional security systems." Id. at 107.
84. "[S]pecify and implement a ground floor intrusion detection system that is capable of detecting unauthorized access, CCTV surveillance and assessments, automatic call-up of alarm-associated camera outputs, pre and post alarm recording of camera outputs." Id. at 107.
85. "Upgrade the CCTV System for additional camera inputs, with advanced surveillance and assessment capabilities; Provide digital recording capabilities that facilitate advanced storage, retrieval and event search capabilities; Provide integration with the ACS, IDS and Duress system components; Allow for remote call-up by authorized monitoring personnel; [and] Connect the system to UPS power." Id. at 108.
86. Perform "[a] risk . . . to evaluate auxiliary mechanisms for reporting alarms to public safety authorities." Id. at 108.
87. "[B]lock access to the courtyard by placing large, heavy, planters at the entrance, or any other means." Id. at 108.
88. "[L]imit access to the loading dock by means of a gate and/or barrier, controlled by the guards, and/or authorized building personnel." Id. at 108.
89. "[I]nstall security lighting around the facility with emergency power backup." Id. at 108.
90. "[V]erify that the doors, frames and related hardware meet the requirements of heavy duty, high security specification that is suitable to the BIA Data Center." Id. at 108.
91. "[C]ontrol facility parking including an ID system for authorized parking. Post signs and arrange for towing unauthorized vehicles." Id. at 108.
92. "[E]nsure adequate lighting is provided for parking areas with emergency power backup." Id. at 108.
93. "[I]mplement x-ray screening for all UPS, FEDEX and other packages, including visitors' packages." Id. at 109.
94. "[V]erify with the Authority Having Jurisdiction (AHJ) that indeed the work has been performed according to local codes." Id. at 109.
95. "[I]nstall emergency power off switch as specified by the code." Id. at 109.
96. "Develop system schematics and equipment descriptions for the existing ACS, IDS, Duress and CCTV headends and installed devices; Document all new and replacement security devices in engineering documents; Develop a configuration management database documenting characteristics for all headend and building equipment; Implement a facilities management software program (Visual Information Management System) to assist in documenting and managing the configuration of the security system; Document the system specifications; Prepare as-built drawing; [and] Prepare a `test plan' describing procedures to be used to test the system." Id. at 109.
97. "[C]onduct the test to be sure that every component operates as specified under various conditions." Id. at 109.
98. "[P]repare a written Fire Emergency Plan, a Security Plan, OEPs and contingency procedures including bomb threat procedures. Provide training and exercise with tenants. Establish law enforcement agency/security liaisons. Review/establish procedure for intelligence receipt and dissemination. Establish uniform security/threat nomenclature. Finally, conduct annual security awareness training." Id. at 109-110.
99. "[E]valuate the level of risk, quantify the level of protection that is provided by the UPS system, and determine whether additional lightning protection provisions are required." Id. at 110.
100. "[E]valuate the level of risk and prepare the following: A program to protect the records in accordance with their importance; Analysis of the workload and its effect upon continuity of operations; A written set of requirements for the backup site including Backup files and equipment required, Configuration of mainframe computer and peripheral units, Alternate locations for backup processing, Availability of backup systems, Telecommunications required at backup site, Files, input work, special forms, etc. needed, Personnel staffing and transportation, Agreements and procedures for emergency use of computer equipment at a contingency site." Id. at 110.
101. "[I]nstall XXXXX security enhancement software and activate the XXXXXX option." Id. at 110.
102. "[U]se XXXXXX to assign additional granulated privileges to default user accounts to provide the least level of access necessary to perform a particular job." Id. at 110.
103. "[I]nitiate log backup and review and internal auditing. The security logs should only be accessible to a security administrator. The logs should be backed up and stored offsite for future audits and investigations." Id. at 111.
104. "[I]mplement appropriate file ACLs (Access Control Lists) using guard files to protect sensitive data." Id. at 111.
105. "[I]nstall virus and Trojan protection software." Id. at 111.
106. Review "[u]sercode attributes . . . to verify they meet the Unisys recommendations for highly secure system." Id. at 111.
107. "[D]ecrease the number of users with privileged permissions as recommended in the NX Operating System Security section." Id. at 111.
108. Reengineer "[a]ll applications containing hard coded user authentication information should . . . to allow for a unique set of credentials to be entered for each user." Id. at 111.
109. Do not store "[u]ser IDs and passwords . . . on PCs. The default configuration of a PC is insecure, making it feasible for a malicious internal user (and external user if the machine is connected to the Internet) to gain access and obtain this information." Id. at 111.
110. Document "[e]ach application and the programs that make up the application." Id. at 111.
111. Institute "[c]onfiguration management and change control . . . to test and document all modifications to application configuration." Id. at 111.
112. Migrate "[t]he Osage application . . . to a more secure and robust database solution." Id. at 112.
113. Limit "the ability to manipulate production data when data entry errors occur" to "trusted operators." Id. at 112.
114. Install "[s]ystem edits . . . to prevent duplicate files from being processed. In the current environment, a file previously processed could be inserted in the NX and run as if it were a new file." Id. at 112.
115. "[R]eevaluate and remove unnecessary privileged usercode permission as this is the most significant security hole within the NX system. When properly configured, the default, or non-privileged, user permission is sufficient for performing most user activities. When appropriate, use InfoGuard granulated permissions to provide users access to system resources otherwise inaccessible to the default usercode." Id. at 112.
116. "[I]nstall InfoGuard security enhancement software and activate all of the password security options, such as maximum and minimum password length, password aging, and number of password generations." Id. at 112.
117. "[D]ecrease the number of maximum logon attempts from 10 to 3." Id. at 112.
118. "[C]reate a usercode naming convention to assist in determining the resources accessing the system. The naming convention shall include a combination of specific information, such as region, username, workstation, etc. that would make user identification easier and provide for more granularity when audition user activity." Id. at 112.
119. "[I]dentify and delete all inactive usercodes. Separated employees could gain access using inactive usercodes that have not be [sic] removed. Accessing the system using inactive usercodes would make user identification very difficult." Id. at 113.
120. "[R]eview the logs files and audit successful and failed user logins on a daily basis. BIA shall install XXXXX to ensure that only the Security Administrator has access to the security logs." Id. at 113.
121. Change the default password for "[t]he XXXXX . . . to something that is compliant with current password conventions." Id. at 113.
122. Move "the router . . . located in the data center . . . to a location that is only accessible by authorized BIA personnel or a new rack with a locking door shall be installed." Id. at 113.
123. "[D]esign and implement a comprehensive boundary protection architecture that includes firewalls, VPNs, intrusion detection tools, virus protection and content filtering. Until a firewall is installed and properly configured, the router access lists should be modified to prevent unnecessary BIA IP addresses from accessing Reston network resources." Id. at 113.
124. Disable "[t]he HTTP access to the router from the Internet . . . ." Install SSL "if HTTP is necessary for remote configuration, to encrypt authentication information." Consider "using a secure transmission method such as SSH if the router is being accessed from outside the BIANet." Id. at 113-114.
125. Disable "XXXXXXXXXX. . . on all hosts until a firewall is installed and properly configured." Id. at 114.
126. Consult "the BIA legal counsel to ensure the warning banner displays all necessary information that would hot hinder prosecution." Id. at 114.
127. Do not use "[t]he XXXX default settings shipped with the XXXX switches." Id. at 114.
128. Enable "MAC address port-level security on all switches . . . to limit the number of workstation that can attempt a connection to the switch." Id. at 114.
129. "[C]onsider allowing contractors to have home directories on network servers where Trust data can be safely temporarily stored." Id. at 114.
130. "Consider using proactive tools like Crack to test user password strength." Id. at 114.
131. Complete recent purchase of "equipment to enable system backups and to attach the servers to a UPS system." Id. at 114.
132. "[R]eview the [DOI Standards for Local Are Networks] checklist and make system modifications that would assure compliance with this list." Id. at 114.
133. "[E]stablish an email acceptable use policy that explains the use of BIA email, use of encryption for sensitive data, misuse policy, etc." Id. at 116.
134. "[D]ocument the Notes system configuration, PKI, ACLs, and other security related information." Id. at 116.
135. "[U]pgrade all XXX servers running on XXXXXXXXX to 128 bit service pack 6a immediately." Id. at 116.
136. "[I]nstall SSL on the Notes server to support encryption of remote user authentication and data." Id. at 116.
137. "[R]emove all services on the NT.W2K servers that are not used." Id. at 117.
138. "[D]evelop and implement a process to disable accounts of separated users immediately following the personnel action." Id. at 117.
139. "[R]elease without delays the password management section of the Rules of Behavior to all BIA and contractor sites. IRM shall finalize the complete set of Rules of Behavior and formally release it to all sites." Id. at 117.
140. "[G]ive IRM the authority to enforce the Rules of Behavior and Acceptable Use Policies at the regional offices." Page Id. at 117.
141. "[O]btain a password cracker for the Unisys password file. Periodically, the IRM IT Security officer shall attempt to crack passwords in the file. The accounts with weak passwords shall be disabled until a new stronger password is created by the user." Page Id. at 117.
142. "[V]erify that all default account Ids and passwords have ben removed or disabled." Id. at 117.
143. "[R]edesign programs and scripts to eliminate the use of embedded account Ids and passwords." Id. at 117.
144. "[D]evelop a security awareness training program for all users. IRM shall develop the curricula for training at two levels: mangers and staff. The program shall provide trainers, training manuals. Training shall be mandatory at least once a year." Id. at 117.
145. "[D]evelop a security awareness training program for IRM employees. A special curriculum shall be developed for staff with system administrator rights to IRM IT systems." Id. at 117.
146. "[D]evelop a new user security orientation manual. The manual shall be given to all new users (employees and contractors) on the first day of employment at the BIA." Id. at 118.
147. "[D]evelop a security incident reporting and investigating procedure." Id. at 118.
148. "[R]eengineer and implement a comprehensive auditing function on the Unisys NX. IRM shall develop policies and procedures for managing and viewing the logs. IRM shall give only select group of employees the privilege to view or manage the system logs." Id. at 118.
149. "[D]evelop a Disaster Recovery Plan." Id. at 118.
150. "[D]evelop Disaster Recovery Procedures." Id. at 118.
151. "[U]pdate its Continuity of Operations Plan (COOP)." Id. at 118.
152. "[I]nstall a standby generator capable of supporting all data center systems, including AC and alarm systems. To eliminate time restrictions, the generator shall provide the capability of refueling while in operation." Id. at 118.
153. "[D]evelop a standard operating procedures manual for the data center. Procedures such as planned shut down, emergency shut down, user notification, and data center evacuation shall be included." Id. at 118.
154. Ensure that "[t]he data center [has] equipment and supplies necessary to contain minor water leaks. A wet/dry vacuum, paper towels, rags, and plastic sheeting can come in handy. Operations in the data center shall not be disrupted due to minor water leaks." Id. at 118.
155. "[D]evelop a safety manual for the data center." Id. at 118.
156. [I]mmediately address the servers identified to be compromised, as well as those others that were found to have potential vulnerabilities. Servers should be brought up to the latest software patch level, and `hardened.'" Id. at 118-119.
157. "[M]odify its network architecture to reflect industry best practices, such as employing proven security strategy and infrastructure like OS/Application hardening, IETF RFC 1918 IP addressing, screened subnets, and De-Militarized Zones." Id. at 119.
158. Protect "[t]he Reston facility . . . from other BIA networks in order to limit and contain the scope of potential damage related to malicious activity or other incidents." Id. at 119.
159. Limit "DNS zone transfers . . . to only those hosts which have a business need to know internal addresses/names, and reverse lookups should be disabled for all but dedicated machines running necessary services (i.e., www, ftp, DNS, smtp, etc.)." Id. at 119.
160. Use "`split DNS' and Firewall De-Militarized Zones (DMZ) . . . . A split DNS is where dedicated external DNS hosts, dedicated internal DNS hosts, and strong security infrastructure are built to separate name resolution for their respective zones (public and private). This service should be password protected and proper ACLs created to restrict users to authorized directories." Id. at 119.
161. Disable "[a]ll open ports with no known purpose . . . on all hosts." Id. at 119.
162. Disable "file sharing shall . . . on all workstations." Page Id. at.
163. Explicitly prohibit "[s]toring Trust data on any workstation." Id. at 119.F. Special Master's Site Visit Report
On March 12, 2001, the Special Master issued a report addressing the physical security of the OIRM Reston, Virginia facility. See Site Visit Report of the Special Master to The Office of Information Resource Management (March 12, 2001) ("Special Master's Site Visit Report").
1. Special Master's Site Visit Report: Findings
The Special Master's Site Visit Report revealed that:
(1) the Special Master was able to enter the facility via a construction entrance without identification (Special Master's Site Visit Report at 1); (2) a computer-generated printout labeled "Individual Indian Monies Interest Calculations" was lying on a shredder near the OIRM work space (id.); (3) the second floor of the facility could be accessed without a pass key or special identification (id. at 2); and (4) contractors admitted that trust documents may be left unguarded throughout the day (id. at 3).
G. Predictive Systems' Reports
On June 1, 2001, the Special Master engaged Predictive Systems ("Predictive") to perform a vulnerability assessment of the DOI/BIA Internet Infrastructure in order to determine the overall security of the network segments and hosts within the scope of the engagement and to show whether it was possible to gain access to critical BIA systems and read, modify or delete the data contained on these systems.
Founded in 1995, Predictive is a network infrastructure consulting firm whose clients include the Department of Justice, the General Services Administration, the State of Michigan, the State of Massachusetts, the Virginia Department of Housing and Urban Development and the Virginia Department of Transportation, Chase Manhattan, Bear Stearns, Goldman Sachs, Credit Suisse/First Boston, Raytheon, Microsoft, Deutsche Bank, Pfizer, Mitsubishi, Solomon Smith Barney, Fidelity Investments, Comdisco, Citigroup, First Union, Freddie Mac and United Airlines. It also enjoys strategic alliances with SAIC, Cisco, BellSouth, Hewlett Packard, Tivoli, Micro Muse, Peregrine, RiverSoft, bmcsoftware and Compuware.
To accomplish these tasks, Predictive proposed to conduct a penetration test in two phases: an external, Internet-based network testing phase to be followed by an onsite, internal network testing phase which would compromise critical hosts to gain access to trust data. This was unnecessary, however as, "[e]arly on in the testing it became apparent that it was possible to access the sensitive internal data from the Internet and that the internal on-site testing phase was not needed due to the lack of overall perimeter security of the BIA Internet Infrastructure." Predictive Systems Network Vulnerability Status Report of Bureau of Indian Affairs Trust Data Security ("Predictive Report") at 1.
In August 2001, Predictive issued a report focusing on the "potential vulnerabilities of the systems that belong to the Department of the Interior (DOI) Bureau of Indian Affairs (BIA) and methods for exploiting them." Predictive Systems Network Vulnerability Status Report of Bureau of Indian Affairs Trust Data Security at iii (August 2001).
1. Predictive Systems Reports: Findings
Between June 24, 2001 and July 8, 2001, Predictive performed an initial penetration test of systems identified by the BIA as being "critical" to their mission. As set out in the Predictive Report, Predictive Systems was able to gain unauthorized access to both critical systems (IRMS and TAAMS) identified by BIA. Predictive achieved access to these systems that allowed creating shared directories, accessing data, and making changes to these systems (including adding user accounts). Predictive Systems was able to gain unauthorized access to these systems from the Internet using a variety of known exploits and openly available, freely downloadable software. While commercial tools and proprietary attack methods were used during this assessment, gaining access to the critical systems identified by BIA could be achieved by an attacker on the Internet using similar attack methods and freely available tools.
Predictive Report at v.
Specifically,
Problem Page No. Predictive was able to locate a list of users on the XXXXXXXXXXX server, determine the 9 pattern for user names, and determine that the remote XXXX servers had a blank administrator password. Predictive was also able to access individual users' mailbox files. By accessing the TAAMS XXXX through vulnerabilities on the BIANET (caused by 9-11 blank administrator passwords) Predictive had "access to information such as all of the users that were allowed to access the database, database schema information, and even data stored in the database." Such information gave Predictive "access to view, change or modify any information available on the XXXX system." Again utilizing weaknesses on the BIANET, Predictive gained access to the IRMS XXX 13 XXXXXX-based administration software files. These tools enabled Predictive to "connect to the target system as an administrator without [the program] prompting for any form of authentication," giving Predictive "complete access to all user management functions on the XXXXXX system." Such access allowed Predictive "to see every account that existed on the XXXXX system. In addition, the user management program allowed full access (change, modify, delete, add) to the user database." Predictive accessed a list of all user accounts and passwords found on one of the XXXX 14 XXXX backup domain controllers. Using a simple login and password, Predictive was able to log into the XXXXXXX 14 system. It was possible to login to the XXX Server (IRMS) by hopping through other vulnerable 24-25 hosts on the BIA network. Once there, Predictive found that the administrator account had a blank password and was able to log into the system and obtain complete control of the server. From this point, it was possible to create Windows Networking shares, create users, and transfer files to and from the server. Predictive was able to connect to the TAAMS system with no password which allowed it 27 to obtain interactive access to the system as an administrator. Predictive found that the Blank Admin Password on the XXX Server provided a low 24-25 difficulty of exploitation: "Predictive was able to log into the system and obtain complete control of the server." Predictive found that the Weak Admin Password on the XXXX Server provided a low 26 difficulty of exploitation: "Predictive Systems had access to the XXXXXXXX application software available" on the server. Predictive found that TAAMS XXXX Environment was compromised, leading to a low 27 difficulty of exploitation: "Predictive Systems used this host to launch the majority of the attacks on the servers that BIA identified as sensitive systems." Predictive found that the Blank Administrator Password on the XXX Field Office Server 28-29 provided a low difficulty of exploitation: "This server housed several gigabytes of XXX XXX email for employees of the BIA that were staged at this specific site. Additionally, the server was also linked to all of the other XXX servers throughout the BIA." Problem Page No. Predictive found that Administrative Access to the routers could be obtained, and that 29 this provided a low difficulty of exploitation. "Predictive Systems found that sensitive information was available on several of the 31 BIA's XXXX web servers anonymously. This information included server configuration details, log files, and user address book information." Predictive found that the difficulty of exploitation for this weakness was low. "Predictive Systems was able to connect to many XXXXX hosts as `Administrator' 33 without supplying a password. Because of this, Predictive Systems was able to map all shared drives and obtain full control of the system." Predictive found vulnerabilities, including the availability to upload XXX, "a command 33-34 that allows a user to connect remotely and get command line access to a XXXXX host," on the Microsoft XXX Servers, and found that there was a medium difficulty of exploiting these vulnerabilities. Predictive found that several XX hosts allowed anonymous logins, and that the difficulty 35 of exploitation was low. Predictive was able to access XXXXXXXXXXXXXXXXXXXXXXXXX on the systems. 35-36 According to Predictive, "[a]n attacker can use XXX to obtain valuable information about the machine, such as information on network devices and current open connections." Predictive found that sensitive files are available through anonymous XX, and that 37 [e]nabling anonymous XX means that anyone who can connect to the service can log in, greatly increasing the potential number of attackers and attacks." Predictive found that "A XX server was running" on a host, with a low difficulty of 38 exploitation. Predictive states that "XXX allows file transfers, with no authentication." "Predictive Systems found that some registry keys were writable by users who were not in 39 the admin group. Some keys affect system security. A malicious user may be able to alter these keys to escalate privileges on a system." Predictive found that a host has a XXXX named XXXXX installed in a web server. 39 According to Predictive, "[t]his is dangerous for many reasons. A malicious user may use this vulnerability to place files on web server to perform additional exploits." Predictive found that a number of hosts (which are possibly printers) "are running a XXX 40-41 application with no password." "Predictive Systems was able to establish a null (anonymous) session with various 42 XXXXX target hosts during this assessment. "Predictive Systems found that it is possible to force to XX server to connect to other 46 hosts by using the XXX command. This problem allows an intruder to use affected host to scan other remote hosts, making the scans appear to originate from the affected host." Problem Page No. "Predictive Systems found that services like XXXXXXXX were running on these 46 systems. These services can be setup to run `unauthenticated.' That means that a user on one system that has a valid login, can access another computer if the same account exists on the other server without authenticating." "Predictive Systems found that these hosts were running standard XX services like XX 47 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX, etc. May XX services are susceptible to various security vulnerabilities. These include Denial of Service attacks, intelligence gathering, and often specific buffer overflows or exploits." Predictive concluded that:
the Bureau of Indian Affairs' network infrastructure has not implemented many basic security practices. Even if every security vulnerability identified in this report was corrected, BIA's overall lack of a secure network perimeter would still leave BIA exposed to additional risk. Furthermore, Predictive Systems recommends that the Bureau of Indian Affairs create security policies and standards that describe best security practices, and then implement them. . . . Establishing a secure network perimeter (through firewalls, intrusion detection and other technologies), mitigates the risk of future exploitation by minimizing access to BIA systems and monitoring the perimeter network for active signs of intrusion.
Predictive Report at 48.
During a meeting which took place following the issuance of the Predictive Report to discuss its finding related to BIA Security, OIRM Director Brian Bowker suggested that Predictive would not have been able to penetrate the BIA's infrastructure had Bowker not, in essence, "turned over the keys to the store." The inference drawn by the Special Master was that BIA was maintaining that its computer systems were more secure than indicated by Predictive and that its findings should be tempered accordingly.
Concerned that Mr. Bowker's representation was being offered to discount the ease with which Predictive was able to penetrate the BIA's computer systems, on August 30, 2001, the Special Master commissioned Predictive to once again penetrate the BIA systems and, this time, create a false account in his name.
In October 2001, Predictive issued its second report reiterating the findings in its initial report that the Bureau's computer systems were vulnerable to outside attack — even when approached from a completely different network than that used in the first penetration test. Special Task Vulnerability Assessment Report For Bureau of Indian Affairs, October 2001 ("Second Predictive Report") at 5. Again, to emphasize "the poor state of implemented security measures on the Bureau of Indian Affairs Networks," Predictive "made it a point to use only free tools and utilities, which are widely available on the Internet," to penetrate the computer systems. Second Predictive Report at 1. Once Predictive gained access, it targeted the XXXXX server in an attempt to alter the data on one of the XXXX and create an XXXXXXXXXXXXXXXXXXXXXXXX. Id. at 9. They were successful and altered XXXXX an existing XXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
The Second Predictive Report found that both are the BIA networks and the trust data housed therein are vulnerable to attack. Specifically,
Problem Page No. It was possible to access the XXXXX server and perform functions with 28 administrative privileges. It was possible to control the computer remotely using the standard XXXX 28 XXXXXXXX administration tool which allowed Predictive to stop and start services, edit registry keys, enumerate users, hardware configurations, etc. XXXX was running as a service on this host which allows remote access to a 29 computer terminal. Problem Page No. It was possible to map the XXXXXX drives of this computer over the internet which 30 allowed Predictive to upload files to and download files from this computer. It was possible to access sensitive information about XXXX via the XXXXXX 31 XXXX. 2. Predictive Systems Reports: RecommendationsThe two Predictive reports urged the BIA to:
1. "Deploy firewalls to establish a secure network perimeter to protect the network, systems and data of BIA. From reviews of documents and interviews with SeNet Corporation, the BIA network will need anywhere from three to seven firewalls to provide minimal perimeter protection. The perimeter defenses will create zones-of-trust to isolate and protect critical BIA systems so that only applications permitted to access the systems is allowed. All other accesses will be denied, logged and reported." Network Vulnerability Status Report of Bureau of Indian Affairs Trust Data Security (August 2001) at 29.
2. "Deploy Intrusion Detection Systems (IDS) to monitor network traffic for suspicious activity. The Intrusion Detection Systems can be set up to monitor the network perimeter and critical systems located on internal BIA networks. The IDS devices should be deployed in conjunction with the firewalls to monitor the secure perimeter and other key systems. Approximately three to ten IDS devices should be deployed." Id. at 49.
3. "Implement a monitoring and review capability to monitor firewall logs and intrusion detection events. The monitoring program, will serve to accomplish, at a minimum, the following: Identify evidence of prior compromise (identification of established Trojan horses/back doors); Identify evidence of new attack activity; Establish necessary services and traffic; Establish data access control and transfer methods; Assess effectiveness of defenses; Identify unintended operational impact (e.g., blocking legitimate traffic)." Id. at 49.
4. "Update router configurations and ACLs based on a more thorough knowledge of the actual operating requirements. The current router-filtering scheme is incomplete and inadequate. There are a number of security improvements that can be made at the routers to provide an additional layer of security." Id. at 49-50.
5. "Conduct a review of the entire information security plan in effect at BIA. The plan, at a minimum, must address the guidelines identified in OMB Circular A-130, especially Appendix III, `Security of Federal Automated Information Systems.'" Id. at 51.
6. "Develop appropriate security policies to provide guidelines for appropriate use, behavior and performance, enforcement and to start creating a culture of security awareness with the BIA. The foundation of all security is Policy. With policies to establish standards for performance, any security that is emplaced [sic] quickly weakens. Policy must be centrally controlled, mandated, and disseminated to all personnel." Id. at 51.
7. "Develop appropriate business continuity and disaster recovery plans for all critical BIA systems. Business Continuity and Disaster Recovery plans are the key to quick recovery from unforeseen events. They provide a set of procedures and instructions designed to guide personnel." Id. at 51.
8. "Deploy other defenses (VPNs) if BIA cannot be entirely contained with perimeter defenses. It may not be feasible or possible to entirely contain all sensitive information within these secure perimeters. The use of VPNs for remote access from individual users or satellite offices is a suitable alternative to deploying a full firewall/IDS solution in these instances." Id. at 51
9. "Design and deploy appropriate system hardening to all systems, both servers and workstations. Firewalls and IDSs provide excellent security, but are not sufficient on their own. Individual systems must be properly hardened to withstand attack, especially from insider-attacks. They must be regularly patched against known vulnerabilities, and monitored for unauthorized changes." Id. at 51
10. Implement "strong authentication mechanisms such as one time passwords." Special Task Vulnerability Assessment Report for Bureau of Indian Affairs (October 2001) at 28.
11. Stop "running the remote computer management service." Id. at 29.
12. Stop "using XXXXXXXX (or any other) remote PC management tool, unless other, extremely strict access controls are in place to minimize the risk of compromise." Id. at 29.
13. Stop "sharing any directories, drives, or devices on a computer, unless extremely strict access controls are in place to minimize the risk of compromise." Id. at 30.
14. "[R]estrict access to [the XXXXXXXXXXXXX] Web server." Id. at 31.
15. "[A]pply the patch available from Microsoft to resolve [the Unicode exploit] vulnerability." Id. at 34.
16. "[U]pgrade to the latest version of Cisco's IOS. Predictive Systems also recommends not enabling the Web administration service on Cisco routers." Id. at 36.VI. CONCLUSION
Nearly two years ago, the Court remarked that it was "alarmed and disturbed by the revelation that BIA had no security plan for the preservation of [trust] data . . . that BIA has now placed itself in the incredible position that it cannot now create such a plan with its own employees, but that it can do so only if this Court allows BIA to go forward with these government contractors creating the plan, and then insuring that this critical data is preserved and protected." Hon. Royce C. Lamberth, April 4, 2000 Hearing at 11-12.
Today, nothing has changed. The critical data of concern to the Court remains housed on systems that have:
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. . . . [and] a serious lack of wide area networking and security personnel in general. The BIA is also far behind the other bureaus in Interior regarding staffing of messaging systems and infrastructure support. . . . There is currently no capacity for the OIRM to analyze daily system logs generated by the IRMS system to look for unusual or possibly nefarious activities or to track changes made to each data file. . . . . Likewise, there are insufficient current staff to handle to day to day configuration issues of the data communication wide area network (WAN) let alone monitor, log and report the increasing "hacking" type activity.
FY 2003 Budget Request to the Department Bureau of Indian Affairs Trust Reform — Information Resources Technology (COP), Statement of Problem/Current Condition.
After ten years of blistering reviews generated by federal agencies and private contractors, this deplorable condition is inexcusable.
It can not be argued that Interior was unaware of the hundreds of deficiencies and suggested remedies chronicled in this Report. See, e.g., July 2, 1999 E-Mail from David Shearer (Chief, IRM Program Planning Review Standard Division) to numerous USGS, MMS, BLM, NBC, and BIA personnel (including a cc to Daryl White, Nancy Davis and a bcc to Information Resource Manager, Office of Trust Risk Management Robert McKenna (Subject: 1999 IT Security Workshop)) ("As you know, hackers continue to target the Federal IRM Community at an alarming rate."); April 10, 2000 E-Mail from IT Security Manager John Curran to IRM ADP COORDINATORS, RITSSPOCS ("The most serious security matter is that people can transfer files without a log being made of the transaction and the files may contain scripts, Trojan horses, viruses, or sensitive information that we don't want moving on our networks in this fashion. The hacking community is avidly working on the poor security of these programs looking for pathways into networks and host machines. We have no policy at this time on their use."); February 2, 2001 E-Mail from BIA Chief of Telecommunications Curtis Hohenstein to OIRM Deputy Director Ken Russell ("Currently `Trust Data' is transversing [sic] the Bureau's Wide Area Network and is open to data theft from outside sources. Our entire Network is now `open to the public' domain and is under constant threat of attack and includes ALL major BIA Applications and Operating Systems. The threat of crippling the entire BIANET is real."). It also can not be argued that Interior was unaware that the manner in which it stores trust data violates public laws and federal regulations. See, April 4, 2000 E-Mail from OIRM IT Security Manager Steve Schmidt to DOI/ITSWG (Subject: Department IT Security Plan) ("Our present IT security does not fully comply with existing public laws, federal regulations, and Executive Branch directions"); December 19, 2000 E-Mail from eGoverment Officer, Office of the CIO, BIA Paul Marsden to Special Assistant, Office of Trust Records, Office of the Director Pat Gerard, Dom Nessi ("The current state of IT security in the Bureau of Indian Affairs is tenuous and not in compliance with many federal statutes, regulations, or policies. This statement applies to the situation as of December 2000").
Department of the Interior IT Security Working Group.
Beyond these concessions, as a matter of law, "[f]ederal employees are chargeable with knowledge of governing regulations or statutes." Doe v. Gates, 981 F.2d 1316, 1321 (D.C. Cir. 1993).
Finally, it can not be argued that Interior was unaware of the desperate need for adequate funding to overhaul its IT Security program. It is a matter of record. When the Horn Subcommittee gave Interior the worst security rating in the Executive Branch, CIO Daryl White testified that the agency's "ability to completely implement an adequate computer security program" was "strongly dependent upon the availability of necessary resources." Computer Security Report Card at 156. This message was reinforced in a subsequent September 11, 2000 communication from Acting Director, OIRM William Pfancuff to DOI Bureau CIOs/Deputy CIOs (Subject: Weekly Highlights/IT Conference Status) which opined that the Horn Report Card, "perhaps in the long run . . . will serve to elevate awareness and funding/resources priorities this program so desperately needs." Indeed, Interior's abysmal rating prompted OIRM IT Security Manager Steve Schmidt to remark that the Horn Report Card "raised the awareness of computer security to the highest levels of Interior" and led to "[d]iscussions about the grade and the need for additional resources [being] personally communicated to the Deputy Secretary."). September 20, 2000 E-Mail from Steve Schmidt to ITSWG and OSPIR Managers. Schmidt speculated that security funding may be available since, "[o]n September 18, the Assistant Secretary for Policy, Management, and Budget signed a memorandum setting computer security as a priority issue and that computer security be made a first priority for allocation of remaining FY 2000 fiscal resources, wherever legitimate." Id. (emphasis added).
Mr. Schmidt's optimism was misplaced. As the record in this case has repeatedly proven, gestures such as drafting memoranda and communicating with Interior's senior management, without more, are without substance. Since IT Security became the topic of discussion in the highest levels of Interior and enjoyed the status of a "first priority," Indian trust data housed on Interior's computer systems remains unprotected.
As the underlying litigation has repeatedly dramatized, prioritizing trust reform efforts in an oft-intoned litany of Interior management. See, e.g., Testimony of former Assistant Secretary for Policy, Management and Budget, U.S. Department of the Interior ("Mr. Chairman, I can state unequivocally that these particular issues rank at the highest priority of the Department at this time") Misplaced Trust: The Bureau of Indian Affairs' Mismanagement of the Indian Trust Fund at 18; Testimony of former Secretary of the Interior Bruce Babbitt ("Because of the high priority of trust reform efforts, these resources were provided in anticipation of completion of a strategic plan that would meet the requirements of the Trust Reform Act") July 9, 1999 Trial Transcript at 3687; Testimony of Department of the Interior Deputy Assistant Secretary for Budget and Finance Robert Lamb ("the Department does acknowledge that a coherent, consistent approach to trust fund administration is essential to providing adequate service to account holders. We believe that this goal can be achieved within the Bureau of Indian Affairs by ensuring that a direct line of authority exists within the organizational structure of the Bureau. Currently, the Deputy Commissioner position possesses this line authority. We expect that this position will soon be filled on a permanent basis and assure you that Trust Funds and related trust asset reform efforts will continue to be a very high priority.") July 13, 1999 Trial Transcript at 4013; Testimony of George Gover "trust fund reform is [my] highest priority" and "the highest priority of Secretary Babbitt." June 18, 2001 Testimony at 1109.
For example, the lack of firewalls and adequate perimeter security have been repeatedly identified by the OIG Reports and the SeNet Reports as among the most grievous risks threatening trust data. See, e.g., BIANet System Security Plan at 16 ("[b]ecause of the non-secure nature of the connection (e.g. no firewalls are installed) the BIANET and all the computing resources connected to it (e.g. BIANET' XXXX, IRMS' UNISYS NX, LRIS' IBM 3090) are extremely vulnerable to attacks over the Internet"). Notwithstanding, the BIA removed the firewalls from one of the only two locations where they were in use and the Office of the Solicitor now questions the prudence of allocating funds for their purchase. See May 29, 2001 E-Mail from Solicitor's Office Attorney Susan Offley to Department of Justice Attorney Phil Brooks, Solicitor's Office Attorney Sabrina McCarthy, (Subject Re: Cobell — Revised Response to Motion for TRO and Show Cause) ("Firewalls are not the biggest security risk in IRM at the moment. I don't want to telecast over email what is but it has been mentioned over and over again in all the meetings between DOJ attorneys and IRM staff and even with Toly."). Ms. Offley continues, "BIA is in the process of allocating substantial funding to cover the issues of biggest security concern for fiscal year 2001 and 2002. . . . I cannot say whether or not they can drum up more funding to cover the installation of firewalls or whether they would need to take the money away from those other, more significant concerns to fund a firewall project." Id. What the agency does state with conviction, however, is that "it is not a good idea to suggest to the Special Master that he force us to initiate firewalls when there may be bigger security risks out there that BIA is already scrambling to find funding to correct."Id.
NIST considers firewalls to be critical components of an effective security system in that they,
help 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 and 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 examined and evaluated. . . . . In a firewall-less environment, network security and all hosts must, in a sense, cooperate to achieve a uniformly high 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 adequate passwords.
NIST Special Publication 800-10 at 15, 16.
Apparently, the position of the Solicitor is not shared by the Department of Justice. See E-Mail from Susan Offley to Dom Nessi, Ken Russell, John Curran, Steve Schmidt, Sabrina McCarthy 5/29/01 Subject: Cobell — Revised Response to MO for TRO and Show Cause,
After a meeting last Friday with Dom Nessi and Toly Kozushin of SeNet, Justice attorneys are of the mindset that BIA should institute firewalls right away. At that meeting, Toly represented that firewalls could be instituted in 2 weeks if appropriately funded. However, at last week's TMIP meeting, BIA stated that they needed $1.6 million to fund short term solutions, none of which include firewalls (from what I can tell). Instead, I believe the money for firewalls will come from the $1 million budget request for FY 02. We need to explain to Justice why this $1.6 million isn't going to firewalls and why we made the decision to wait until 2002 to begin instituting them.
Emphasis added. Presumably, this explanation will be shared with the Court as well.
Without evaluating the relative merits of the Solicitor's observation that "more significant concerns" or "bigger security risks" may exist than an adequate perimeter, it is apparent that, as late as May 29, 2001, the BIA was still "scrambling" to locate funds to correct deficiencies that have long threatened the safety of trust information and that have been underscored by every organization that has studied the problem. See, e.g., OIG Report No. 97-I-196, Report of Independent Public Accountants on Internal Control Structure (December 39, 1996) at 37 ("We suggest that disaster recovery planning over the mainframe environment continue to a be a high priority for the Bureau. Our understanding is that the disaster recovery contract is currently up for bid and has been delayed pending government funding."); ("We recommend that the Assistant Secretary for Indian Affairs ensure that: (1) Sufficient staff are provided to adequately monitor all visitor activities; (2) Funding is provided for adequate maintenance of the computer operating room, such as providing daily housekeeping services, or that fire-producing equipment and supplies are removed from the computer room."); OIG Report No. 97-I-771, Audit Report: General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs (April 30, 1997) at 24 ("We recommend that the Assistant Secretary for Indian Affairs ensure that a contingency plan is developed and tested and that funding is provided for acquiring a secure off-site storage facility."). See also BIANET System Security Plan at 18 ("OIRM is in the initial planning process for installing firewalls in the five BIANET hubs. Another firewall is planned for the TAAMS data center in Dallas, TX. Once funds are approved, OIRM will solicit requests for proposals for firewall acquisition and installation. Firewall rules will be available for after the firewalls are fully configured and tested. Virtual Private Networks (VPNs), Internet content filtering, and intrusion detection devices are also under consideration for implementation by OIRM during FY2002 (depending the availability of funds")); BIANET System Security Plan at 21-22 ("[B]ecause of lack of funding no special measures to ensure non-repudiation and data integrity were implemented by OIRM. . . . Currently, because of lack of funding, OIRM is not taking any proactive measures to increase the reliability and availability of BIANET equipment that is under its control."); Reston LAN System Security Plan at 17 ("BIA has not conducted a vulnerability and risk assessment of the Reston LAN. The assessment shall be conducted after funds are approved"); BIANET System Security Plan at 24 ("There are no current plans for a BIANET risk assessment. However, BIANET is a high priority effort for OIRM. It will be conducted as soon as funds become available."); BIANET System Security Plan at 24 ("A security audit was not conducted on any of the BIANET sites. No new BIANET node installations are planned. Security audits will be conducted as soon as funds become available."); BIANET System Security Plan at 25 ("For the lack of funding, [no security audit] scheduled at the present time"); BIANET System Security Plan at 31 ("When funding becomes available, OIRM plans to conduct a physical security survey of all BIA sites connected to the BIANET"); IRMS System Security Plan at 25 ("Is biometrics in place or planned? "No/Yes, when funding is available"); TAAMS System Security Plan at 39 ("BIA approved and funded penetration testing on TAAMS. . . Continuing these test in the future will depend on the availability of funds"); IRMS System Security Plan at 40 ("No. OIRM is in the process of evaluating firewalls from various vendors. At this time funds are not available for this acquisition"); LRIS System Security Plan at 56-57 ("The BIANET is not protected by Firewalls, but the Multiprise in the Denver data center is protected by a Cisco PIX firewall. The BIA Information Security Program (presently under development) provides for the installation of firewalls, but funds are not currently available"); TAAMS System Security Plan at 44 ("The BIA Information Security Program (presently under development) provides for the installation of firewalls, but funds are not currently available"); Reston LAN System Security Plan at 40 ("OIRM is in the process of evaluating firewalls from various vendors. As of yet no decisions was made on which firewall to acquire and no funds are available for this acquisition"); IRMS System Security Plan at 40 ("No current plans for implementing intrusion detection systems on the Reston LAN and the BIANET due to the lack of funds"); TAAMS System Security Plan at 44 ("The BIA Information Security Program (presently under development) provides for the installation of firewalls, but funds are not currently available").
The "scramble" for adequate funding must be evaluated in the light of testimony given two months earlier before the Subcommittee on Interior and Related Agencies. In his introduction, the Special Trustee noted that "[a]dditional funding has been appropriated each year for the day-to-day trust asset management program operations of the Bureau of Indian Affairs (BIA), Minerals Management Service (MMS), Bureau of Land Management (BLM) and the Office of Hearing and Appeals (OHA). Because of these additional resources, the Department has made progress in implementing much needed Indian trust reform efforts." Opening Statement of Thomas N. Slonaker Special Trustee For American Indians before the Subcommittee On Interior and Related Agencies Committee on Appropriations U.S. House of Representatives at 1. There is notably no mention in the Special Trustee's introductory testimony of Interior's IT Security concerns or of the need for additional resources to address these concerns.
In truth, the system is in its current state of disrepair because protecting trust funds is not now, and has never been, a "priority" deserving of adequate resources.
In light of this deplorable record, certain questions must be answered.
This list of questions is illustrative and not exhaustive.
Why, for example, on June 15, 2001, after the publication of tens of thousand of pages detailing every conceivable problem challenging the agency's security systems, does DOI Chief Information Officer Daryl White wish to conduct yet another "review of the current state of Trust Management IT security across the Department[,] [b]ased on the results of [which], Interior will be prepared to make decisions on how to proceed with implementing IT security as part of the Trust Management program. . . ." Memorandum from Daryl White to Chairman, Trust Management Improvement Program (TMIP) Steering Committee. On that score, why, after the publication of 30 reports — the majority of which were generated at considerable expense to the Department — did the Office of the Special Trustee commission yet another report which intones the identical litany of problems that have long been a matter of record.
On November 7, 2001, Electronic Data Systems ("EDS") — at the behest of the Office of the Special Trustee — issued its "Recommendations: For Comments Report — Information Assurance" — purporting to address the agency's IT security deficiencies. Given the recent issuance of this report, it will not be commented on in depth except to note that it offers not one unique observation from previously commissioned reports nor offers any original insights or recommendations. See, e.g., "Add firewalls to the BIANET" Id. at 8; "Immediately implement and enforce password management practices which comply with BIA requirements and industry standards." Id. at 10; "Restructure the ATS contract to adhere to regulatory, departmental and industry practices" Report at 11; "Review Federal, DOI, OST and BIA regulations and guidelines as well as industry practices." Id. If anything, the sparseness of detail in EDS' offerings is alarming considering the wealth of information which was at its disposal. And in those instances where EDS supplies clarification, its suggestions are noticeably shy of the particularity contained in the Andersen, OIG, SeNet and Predictive Reports. Given the near million dollars expended by the agency to commission the SeNet reports (and its exhaustive list of recommendations which went unheeded), it can only be hoped that not too much money was expended in securing this latest pale effort. What is not needed to rectify years of neglect is yet another restatement of the same problems in an effort to convince the Court that progress is being made.
Why would the CIO — who is statutorily responsible for "providing advice and other assistance to the head of the executive agency and other senior management personnel of the executive agency to ensure that information technology is acquired and information resources are managed for the executive agency . . .," 40 U.S.C. § 1401, not review the 18 SeNet reports he commissioned at the expense of nearly one million dollars.
Special Master: And I guess maybe I should start now by asking before we do so, have you read the [SeNet] IRMS security plan?
Nessi: No, I have not.
Q Now that sort of strikes me as curious, sir. Why would you not read — didn't you contract with SeNet to perform certain studies on your behalf?
A Yeah, on the department's behalf. Absolutely.
* * * *
A You know, with all the duties that I have, I would not be able to get to each of them.
Q Have you read the [SeNet] LRIS report?
A No. I haven't read any.
June 14, 2001 Interview of Dominic Nessi at 50-52
It is clear that, just as Mr. Nessi did not review the studies he commissioned on behalf of BIA, neither did any other Interior official. If they had, there would be little need to conduct yet another review, which "will contain recommendations for implementing an adequate IT security program for Trust Management system in the Department," Memorandum from Daryl White to Chairman, Trust Management Improvement Program (TMIP) Steering Committee or commission additional reports from third-party contractors such as EDS.
Why, on June 12, 2000, was the CIO compelled to transmit a memorandum to Assistant Secretary Kevin Gover, Director, Office of Administration and Budget Deborah Maddox, BIA Deputy Commissioner for Indian Affairs Sharon Blackwell and Principal Deputy Trustee Thomas Thompson "[a]ttach[ing] a plea from the CIO's office requesting a yes vote on funding for the Interior Architecture project . . . . one of the four breaches" in an attempt to impress "that funding is still up in the air and should be a higher priority."
Why, in March 2001, did the Special Trustee, in his introduction before a congressional subcommittee, underscore Interior's "efforts and commitment to resolve decades of trust fund management issues for both Tribal and individual Indian account holders" yet make no reference to the February 9, 2001 Information Technology Security Program version 1.0 which described "systems and information stores that are readily subjected to unauthorized disclosure, non-approved modification, and lost availability," or to "[r]esultant losses to the Department includ[ing] a continuation of those risks already realized including resources consumed by court litigation, losses from financial fraud, loss of financial audit credibility, expenses for recovering from system compromises, unavailable IT services, and public embarrassment." Id. at 1.
Why, in response to the Special Master's query as to CIO Nessi's inability to raise adequate funds to support the trust architecture did Mr. Nessi respond, "People needed money for so many things that this did not raise — this did not rise to, in their minds, a higher priority." And, perhaps most significantly, why was the Court not informed — via the Quarterly Reports that Indian trust data was virtually unprotected.
Special Master: Who is they?
Nessi: I would say anybody who had input into the budget.
August 8, 2001 Interview of Dominic Nessi at 155.
Nessi, on that score, recalled, "saying [on July 5, 2000] to [Tom Slonaker, Tom Thompson and Office of the Special Trustee Budget Officer Dave Gilbert] that one of the areas — you know, I had been using TAAMS money to strengthen BIANET, security-wise, XXXX servers and those kinds of things. And I recall very specifically they told me they would rather I did not spend TAAMS money on what they considered to be IRM expenditures. . . . That I should not use TAAMS money, trust reform money to upgrade the BIANET; that that was not the responsibility of trust reform." August 8, 2001 Interview of Dominic Nessi at 164. Emphasis added.
The agency was clearly cognizant of its responsibility to do so.See May 30, 2000 E-Mail from Associate Director for Water, US Geological Survey Rudolph Hirsch to Director, Office of Trust Responsibility Terry Virden, Contracting Officer, Office of the CIO, BIA Tammy Harris, Dom Nessi, Ken Russell, Dr Ryl, Steve Schmidt, BIA Y2K Project Manager Ed Socks
As you know, the recent court procedures have resulted in a directive to BIA to strengthen its protection of the Indian Trust Funds, and to send quarterly reports to the court outlining activities undertaken and progress made in line with that directive. Our tasks in those activities include identifying and quantifying the risks and vulnerabilities currently associated with keeping and processing the Indian Trust Fund records, and creating system security plans for BIANET and LANS. Your inputs will be essential for this task, and therefore we will contact you soon to obtain information about those systems. I would appreciate a face-to-face meeting with your for this purpose.
Emphasis added.
It appears clear that, had Mr. Nessi not publicly aired his frustration (and prompted the instant investigation), the problems described in this Report might never have surfaced.
If the representations made to the Court in opposition the plaintiffs' request to enjoin the OIRM move from Albuquerque to Reston serve as any yardstick, there is no reason to expect that the agency will candidly inform the court of any untoward developments as they arise.See, e.g., March 21, 2000, Opposition to Plaintiffs' Motion for Preliminary Injunction at 14, 21, 32 and 37 (arguing, inter alia, that the contracts with ISI/PRT "fully comply with the law;" that plaintiffs have failed to demonstrate any irreparable harm; and that contractors needed immediate access to all OIRM systems "to avoid system failures and possible loss of [trust] data."); March 7, 2000 Declaration of Kevin Gover at ¶ 12 (staff at the Reston facility are "taking the necessary steps to protect trust information and documents.") See also 3/16/00 Declaration of Edward Williams (Exec. VP — PRT) at 18 ("[o]nce permitted to complete the relocation plan, PRT expects a decrease in the risk of data corruption due to the improved data center, implementation of written procedures, and stabilization of staff. Every day of delay perpetuates a situation in which the data is less secure than it could be.");
Indeed, one of the cornerstones of defendants' argument in opposition was the existence of a System Operations Security Plan ("Security Plan") that would address, inter alia, "data security and transition phases . . . on-going data security management, including security access management," Opposition at 13 (emphasis added). According to this Security Plan, Phase One would revolve around the location and "the required tasks to preserve the present data integrity and environment," while Phase Two would "include implementing best practices in the area of IT Data and Operations Management, improving upon areas of critical deficiency, such as installing a firewall for security, and other improvements once the present environment is re-established, up and running." March 8, 2000 BIA Security Operations Plan at 1.0, p. 3 (emphasis added).
On March 22, 2000, defendants filed a Correction to Defendants' Opposition to Motion for Preliminary Injunction and Motion for Emergency Hearing informing the Court that there was not, in fact, a Security Plan and that their previous posture of compliance with OMB Circular A-130 was incorrect. Id. at 2. The lack of these plans, they argued, "add[ed] urgency to Defendants' request that PRT/ISI be allowed full access to OIRM systems immediately . . . [and] is additional evidence of the need for BIA to assert managerial control over OIRM." Id. at 3. Once the Court's approval was garnered, however, there was no longer a sense of "urgency." On November 30, 2000 — nine months later — defendants filed a Notice of filing of reports on Office of Information Resource Management, Bureau of Indian Affairs and TAAMS. Under the section entitled Information Technology Security, defendants stated, without detail, that "as of April 2000, OIRM operations were not in compliance with all required information technology ("IT") security requirements. There is still significant work to be done in this regard, but now that the new data center has been safely relocated, more effort can focus on long-term IT security matter." Emphasis added.
It is incomprehensible that those with input into the budget process were unaware that the BIA was "so short of resources [that it faced] a major system failure at some point in the next two years." Id. at 95. Government Executive, Trail of Troubles, April 2001 at 96. If the former Special Trustee Paul Homan is to be credited (and if the protection of trust data were truly a "priority") there should have been no such shortage of resources.
Gingold: In your experience at the Interior Department, Mr. Homan, if the Secretary seeks funding for items that he regards as on his highest priority, does he ordinarily succeed in getting those funds?
Homan: Yes.
June 11, 1999 Trial Transcript at 349.
VII. RECOMMENDATION
Interior — in derogation of court order, common-law, and statutory and regulatory directives — has demonstrated a pattern of neglect that has threatened, and continues to threaten, the integrity of trust data upon which Indian beneficiaries depend. Rather than take any remedial action, its senior management has resorted to the condescending refrain that has consistently insinuated itself into the federal government's relationship with Native Americans, in general, and with IIM holders, in particular. And that is one that requests forbearance and trust on the grounds that reform continues to be the "highest priority." It is the view of the Special Master that, in this instance, such trust is not warranted, requests for forbearance should be denied and promises of future compliance should not be credited. The stakes are simply too high. An agency that ignores its own commissioned reports and those generated by other federal agencies; ignores pleas from its own staff for adequate funding; and spends tens of millions of dollars funding computer systems when the integrity of the very data to be loaded on those systems has been open to compromise for so many years, inspires little confidence.
The security of systems housing trust data is no better today than it was ten years ago. The circumstances leading to the Court's alarm "that BIA had no security plan for the preservation of [trust] data," Hon. Royce C. Lamberth, April 4, 2000 Hearing at 11, speak with compelling application today. The continued lack of trust data security is "vivid proof" that Interior has "still failed to make the kind of effort that they are going to be required to ever make trust reform a reality." Id. at 12. It is the recommendation of the Special Master that the Court intervene and assume direct oversight of those systems housing Indian trust data. Without such direct oversight, the threat to records crucial to the welfare of hundreds of thousands of IIM beneficiaries will continue unchecked.