The opinion of the court was delivered by: Alan L. Balaran, Special Master
REPORT AND RECOMMENDATION OF THE SPECIAL MASTER REGARDING THE SECURITY OF TRUST DATA AT THE DEPARTMENT OF THE INTERIOR
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").*fn1 Plaintiffs' Motion*fn2 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,
[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.*fn3 Katherine McIntire Peters, Trail of Troubles, Government Executive, April 1, 2001 at 100.*fn4
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").*fn5 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.*fn6
The Special Master's findings and recommendations are as follows:
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).*fn7
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).*fn8
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*fn9 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. 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*fn10 and the physical relocation was to commence during the first week of March 2000.*fn11
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.*fn12
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)*fn13 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.
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.*fn14 IRMS functions are run on a Unisys NX platform located at the BIA's Reston Data Center. 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.*fn15
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*fn16 ("BIANET") that connects over 5000 users in sites nationwide to centralized BIA and DOI computing resources and services. By using the BIANET, "
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")*fn17 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.*fn18 Transmitted information ranges from non-sensitive to highly sensitive. Reston LAN System Security Plan, (June 30, 2001) at 7-8.
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.
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.*fn19
B. Statutory and Regulatory Guidelines
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;*fn20 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
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."
Finally, executive agencies, such as Interior are directed by guidelines promulgated by the National Institute of Standards and Technology ("NIST")*fn21 and the Federal Information Processing Standards ("FIPS").*fn22 These include:
• 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, (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, (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, (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
Report Date Report Title Problem Page
1989 Report of Independent Public Accountants
"Data processing controls throughout the Bureau cannot be 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." 8
"System errors were found for which no corrective action had been taken." 50
"The NTSC [National Technical Support Center] does not have a current disaster recovery plan." 57
"On Saturday morning February 11, 1989, an outside auditor 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." 59
"Each IMC [Information Management Center] is limited as to 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." 59
"The ability of the computer specialists to access and alter the 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." 60
"Discussions with computer specialists indicated that minor 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." 61
"Discussions with computer specialists indicated that there are no formal testing procedures. In addition, we were made aware that certain testing is performed using actual 'live' data in the production mode." 61
"Through discussions with various personnel, we noted the operators, computer assistants and computer specialists all had access to various password files." 63
"A periodic maintenance and inspection contract for the Halon fire control system is not in place." 65
"The daily tape backup library is not adequately fire protected. 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." 65
1990 Report of Independent Public Accountants
"Data processing controls throughout the Bureau cannot be relied upon to ensure that data is properly processed." 9
"Management indicated [access controls over master data files] is still a problem due to the small number of personnel and the security system available for the hardware." 26
"Presently, the policy of changing passwords every 30 days has been implemented at the NTSC but is not fully effective at the IMCs." 26
2. Arthur Andersen & Co. Reports: Recommendations
The 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: Follow-up 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: Follow-up 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.*fn23 That report, and others that followed, exposed shortcomings relative to breaches in physical security, personnel security and data security:
Report Date Report Title Problem Page
June 1994 Survey Report: National Irrigation Billing System, Bureau of Indian Affairs
"Access to the National Irrigation Billing System was not adequately controlled to ensure the accuracy and validity of critical accounting and financial data maintained in the System. Management officials and software programmers could add, change, and delete without sufficient audit trails to identify the individuals who entered or changed the data." 4
"Edits did not exist in the System to prevent collections for operation and maintenance fees from being improperly posted to the construction repayment account. Since construction repayments are to be deposited in the U.S. Treasury rather than to irrigation operation and maintenance accounts, the potential exists for the Bureau to not detect the error and to lose the use of operating money." 4
"The System did not track data entry errors that the System rejected. As a result, there was no assurance that the error was corrected and that all information was entered." 5
"The records identifying the heirs of the original trust allotments remain inaccurate. Thus the project staff (1) manually prepare bills for the multiple heirs; (2) forward the bills to agency realty offices for debt collection, a procedure that has not been effective; or (3) do not send bills." 6
September 1995 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
"Disaster recovery planning over the Omni application is adequate. However, our review noted there currently is no formal agreement for disaster recovery pertaining to the Unisys A-17 or the IBM 3090. Our observations also noted that the physical location of the two mainframes is at the Albuquerque Federal Court Building, a high risk location. Informal arrangements have been made with other governmental agencies to provide recovery services in the event of a disaster." 37
"Security controls over the Unisys A-17 mainframe are inadequate. The system does not require automatic password changes periodically, users are not automatically logged out after a specified period of inactivity, and there is no limit to the number of invalid password attempts made by a user. Furthermore, our discussion noted that 'Help Desk' personnel have the ability to reinstate or reset passwords which have been revoked." 38
"Our review noted that changes to the Individual Indian Monies (IIM) application are not performed in a test environment on the Unisys A-17 mainframe. There are also no procedures in place for subsequent review after changes have been implemented by the programmer. Review is limited to verification of the output by the requesting party." 38
April 1997 Audit Report: General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs
"Although users were provided written information about system security issues when access to computer systems and application was approved, the Center did not have an employee computer security awareness training plan in effect. Further, the security staff had not provided periodic computer security training to Bureau area and agency offices and other organizations, such as schools." 8
"Risk assessments had not been performed periodically or had not been performed when systems, facilities, or other conditions changed. Specifically, since 1990, only two risk assessments had been performed.... While we determined that these assessments were adequate, we also determined that the Center had not implemented recommendations from the risk assessments." 8
"Assessments of the system security programs effectiveness were not performed periodically. Also, the system security program was not reviewed under the Financial Managers' Financial Integrity Act annual review process." 8
"Major systems and applications were not always accredited by the managers whose missions they supported." 9
"Personnel in sensitive or critical ADP positions, such as system programmers and application programmers (including application programmers not assigned to the Center), did not have documented background investigations for security clearances or did not have security clearances at a level commensurate with their positions." 11
"Although the IBM computer had been set to automatically revoke a user identification (ID) after 180 days of inactivity, supervisors did not notify the application owner or manager or the Center's security staff to revoke and delete a user ID when an employee's employment was terminated or an employee was transferred." 11
"The Bureau had not classified its computer resources to determine the level of security that should be provided by the Center." 13
"The Center was located within a Federal building (which also houses U.S. Courts) that allows unauthorized individuals access to the Center. To ensure that the Center and its resources were safeguarded, physical access to the Center was achieved by electronic keycards, and access into the Center was monitored by video cameras. However, visitors, such as custodial (contractor) personnel and building managers, had been provided the keycards and therefore had unmonitored access while in the Center." 14
"General housekeeping and maintenance of the computer operations room were performed only weekly. This weekly schedule was inadequate because of the failure to remove potential fire hazards caused by combustible supplies and by dust produced by paper used in the printer, which was also housed in the computer operations room." 14
"Security staff and application owners did not periodically review user access authorizations to ensure that users' levels of access to the mainframe computers were appropriate." 16
"Passwords were not changed periodically, and inactive user Ids were not automatically revoked on the UNISYS computer. Additionally, greater reliance had to be placed on the user ID and password controls to protect the application, files, and data because the applications residing on the UNISYS computer were developed without access controls and could not be modified to install the access controls." 17
"The software development and change control was inadequate to ensure that the proper version of an application was used in production. Based on our test of the National Irrigation Information Management System, which was managed by the Bureau's Irrigation and Power Liaison Section, we found that the application programmers not only programmed the application but also tested, authorized, and approved the movement of the modified programs from test or development into production. In addition, the lead programmer was not made aware of software modifications. Further, one member of the Center's systems staff could also move application software changes from test or development into production without the lead programmer's approval." 18
"Periodic reviews of the System Maintenance Facility logs and RACF*fn24 access reports were not performed by the security staff to monitor system activities. Additionally, the security staff produced reports that identified users and the computer resources accessed; however, the staff had not produced or used the primary 'auditing' or monitoring reports that could be used in monitoring system activities." 21
"One system programmer had 'alter' access to system software, the System Maintenance Facility logs, and RACF logs. With this access, the programmer could alter the logging of his activities, as well as any other user activities. Thus the audit trails of system activities could be impaired or destroyed." 21
"RACF can be used to establish controls and monitor access to the computer resources. However, RACF had not been set up to effectively control access to the system resources. We found that one of the 'start procedures' had been assigned the PRIVILEGED attribute. With this attribute, the started task can bypass all verification processing, including the security classification checks, and therefore affect the overall security of the system. Additionally, with the PRIVILEGED attribute, no logging or audit trail of this task was available. Further, no datasets, including the system parameter library, linklist libraries, master catalog, and the primary and backup files, were protected by RACF." 21
"The Center did not have an effective means to recover or to resume computer operations in the event of a system failure or a disaster. Although the Center has begun developing a service continuity plan for fiscal year 1997, the Center did not have a service continuity plan in place. Additionally, the off-site storage facility was not located at least 1 mile from the Center, and the facility did not adequately safeguard information and data stored from unauthorized access and environmental hazards such as heat or humidity." 23
March 1998 Audit Report: General Controls Over the Automated Information System, Royalty Management Program, Minerals Management Service
Program management did not "[i]dentify and address the impact that (1) converting to the year 2000 would have on application processing, (2) using system security software which is no longer supported by the vendor could have on operations, and (3) having royalty and financial information on local area network applications and personal computer databases could have on operations." 9
Program management did not "Correctly assess the risk for the 'Geopolitical' and 'External Directives' elements, which were assessed as low risk. Significant geopolitical and external directives, such as the possible abolishment of the Program and the enactment of the Federal Oil and Gas Royalty Simplification and Fairness Act, have impacted the Program during the past 2 years. We believe that the level of risk associated with these elements was such that it increased the potential for lowering employee morale and thus increased the risk of sabotage or breach of other physical security measures, as well as the possibility of data errors and omissions that affect data and system integrity." 9
"Contractor employees received the same type of background check and security clearance regardless of their duties and the risk associated with the computer-related work they performed. Thus, contractor employees, such as system programmers and computer operators, who could bypass technical and operational controls, received the same security clearance as administrative assistants." 13
"Computer-related work was not technically reviewed by contractor or Program personnel whose position sensitivity was greater than that of the position sensitivity of individuals performing the work." 13
"Contractor employees did not always submit requests for background checks for security clearances. Further, the requests that were submitted for background checks were not submitted within the time frames specified in the contract. An average of 175 calendar days elapsed, instead of the 2 weeks stipulated in the contract, between the dates the employees were hired and the dates the requests were received by the Minerals Management Service's Security Officer in Personnel for forwarding to the Office of Personnel Management. The Office of Personnel Management performed background checks for the same employees in an average of 84 days, and the Mineral Management Service approved the security clearances in an average of 22 days. Thus, most of the delay in the security clearance process was attributable to contractor and Program personnel." 13
"System Management Division employees did not have documentation to support that appropriate background checks for security clearances and required periodic follow-up background checks had been performed." 13
"We found that automated information system users did not have security awareness statements on file acknowledging the employees' acceptance of their responsibilities to safeguard the Program's proprietary data and assets." 17
"The Program's computer resources (data files, application programs, and computer-related facilities and equipment) were not classified appropriately to determine the levels of access controls that should be implemented over the resources. For example, no 'major application' was identified in the Program's annual security plan, even though the applications and data files were 'proprietary' and critical to the Program in accomplishing its mission and reporting financial information. Further, access controls over sensitive data on the servers used by the Program's divisions were not as stringent as the access controls over sensitive data on the mainframe." 19
"Default settings provided with commercial off-the-shelf software were not removed after the software was installed and implemented. For example, we found that the default user identification (ID) and associated default password had not been removed when Program management upgraded to the latest version of the Integrated Data Management System (IDMS). The default user ID provides users with administrative privileges to establish and remove users and to access all mainframe computer resources." 22
"Resource Access Control Facility (RACF) provides the capability to set rules for passwords in which the installation can require the use of specific characters (a mix of letters and numbers) within the passwords, but this feature was not used." 24
"A default security setting was found on a server file that allows passwords to be unencrypted." 24
"The 'SECURE CONSOLE' command was not found on a server file which removes the Disk Operating System (DOS) from the server memory. The removal of DOS from the server memory prevents an individual from inserting a diskette into the server drive and loading unauthorized software that could perform such functions as change passwords, establish trustee rights, creates users, and assign security levels. Also, the 'SECURE CONSOLE' command disables the users' ability to change the server date and time, thus allowing users to bypass access restrictions." 24
"We found that controls were not adequate to ensure that access levels granted to users of the Program's automated information system were appropriate. Specifically, access managers had not approved all automated information system access granted to users of the access managers' applications and had not performed periodic reviews to determine who the users were and whether the levels of access granted in the automated information system were the access levels approved." 26
"The Program's number of unsuccessful log-in attempts to access its automated information system exceeded the standard establish by the Department. Specifically, in 1992, Program management increased the number of unsuccessful log-in attempts from three to five before a user's ID and password were revoked." 29
"Change management controls over client/server application software were not adequate. Specifically, we found that there were no controls to ensure that: (1) Program management authorized and approved software changes and (2) the changes to the application software were adequately tested before the changed software was moved into production." 30
"Application programmers were authorized to access client/server production data to perform 'ongoing maintenance' on applications." 32
"At least one application programmer acted as a backup to an end user, which required the programmer to change production data in the Minerals Management Service Appeals Tracking System." 32
"The individual responsible for setting up users of the Royalty Management Program Desktop applications was also the person designated ro review server security logs, which record the activities of the users of the applications." 32
"The version of RACF, the commercial mainframe security software, that was used by the Program was no longer supported by the vendor. Although the upgraded version of RACF had been purchased, it had not been implemented." 35
"System integrity verification and audit software was not used. This software could assist data center and installation security management in identifying and controlling the mainframe computer operating system's security exposures such as setting system options inappropriately, installing 'back doors' to the operating system, and introducing viruses and Trojan horses, that can destroy production dependability and circumvent existing security measures." 37
"Computer operators and system programmers had the capability to change the system initialization process and thus affect system processing. Additionally, system options that produce a system audit trail were not implemented. Therefore, an audit trail that logs the results of actions taken by computer operators and system programmers in the SYSLOG during system initialization could not be produced for periodic review." 37
"Periodic reviews of System Management Facility (SMF) logs to identify critical events affecting system processing were not performed. For example, reviews were not performed of record type 7, which records events such as 'SET TIME,' 'SET DATE,' and 'SET SMF,' all of which affect system processing and production of audit trails." 37
"Periodic reviews of SMF logs to identify unauthorized changes to data by authorized users were not performed. Even though one of the SMF record types, record type 60, which logs all activity affecting Virtual Storage Access Method data sets that contain lease and site security data, was activated during our audit, the logs were not reviewed to detect inappropriate actions or unusual activity by authorized users." 37
"Local area networks and personal computers used by the Program's divisions that maintain proprietary and financial data were not included in the Program's disaster recovery plans." 40
May 2000 Audit Report: 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 Trusts Funds Managed by the Office of Trust Funds Management
"Periodic reviews of system reports were not being performed." 55
"Specific, clearly defined information security policies and process systems security monitoring do not exist." 55
"As part of our audit related to [Electronic Data Processing], we reviewed physical access to the computer room, which houses the IRMS system and other critical Trust Systems equipment and documents. At the present there are 103 active access cards. Based upon our review we noted not all cards are assigned to specific individuals; certain individuals are in possession of multiple cards; a number of contractors with limited need are in possession of access cards; a number of OSC personnel whose job function should not require access to the computer room are in possession of access cards; two individuals from the Division of Accounting Management are in possession of access cards. Control measures to protect Trust systems from unintentional damage and data from unauthorized disclosure or modification and access to sensitive areas must be strengthened." 55
"Per our review of access to the IIM system ('IRMS'), we noted that the access request forms, which document assigned user codes and passwords are not stored in a secure location at the OTFM. Without strong controls to safeguard against unauthorized access to assigned user codes and passwords, the risk of unauthorized modifications to trust data is increased." 55
"Per our review of access to IRMS, we noted that there are inadequate controls of user codes and passwords including: user codes are not routinely removed for terminated or transferred employees; passwords are not changed on a regular basis; complete documentation does not exist to readily identify the owner of each user code. Without strong controls related to the access to sensitive Trust systems, the risk of unauthorized modifications to trust data is increased. Additionally, any unintended modification may be difficult to detect and correct without an adequate audit trail." 56
"In the event of a disaster, an agreement exists to perform remote processing of IIM applications in Scottsdale, Arizona. However, the disaster recovery plan has not been tested since the conversion of the Unisys A17 to the Unisys NX Clearpath Server. It has been almost two years since the last test was performed. Without a proven recovery plan, the possibility exists that Trust operations would not resume within a reasonable period of time in the event of a disaster." 56
January 2001 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 Management
"[I]nadequacies in various Department of the Interior ("DOI") Indian Trust Fund accounting systems and subsystems controls and records caused the systems to be unreliable." 5
"Records management is inconsistent and inadequate to ensure the proper filing and safekeeping of Trust Fund records to support trust financial activity, however, a mandatory documents policy has been adopted and verification of these mandatory documents will be checked in the centralized preposting review procedure." 14
"Periodic reviews of system reports were not being performed. Specific, clearly defined information security policies and procedures for system security monitoring do not exist." 49
"User codes are not routinely removed for terminated or transferred employees. Passwords are not changed on a regular basis. Complete documentation does not exist to readily identify the owner of each user code." 49
"Per our review of access to the OSC and SEI operated systems, we noted that the access request forms, which document assigned user codes and passwords are not stored in a secure location. Without strong controls to safeguard against unauthorized access to assigned user codes and passwords, the risk of unauthorized modifications to trust data is increased." 50
May 2001 Independent Auditors Report: Bureau of Indian Affairs Financial Statements Fiscal Year 2000
"BIA controls over its Operations Service Center automated information systems did not comply with OMB Bulletin 98-08, and BIA had not fully implemented the recommendations made in our April 1997 audit report 'General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs' (No. 97-I-771) and our June 1888 report 'Follow-up of General Controls Over Automated Information Systems, Operations Service Center, Bureau of Indian Affairs' (No. 98-I-483)." 13
2. Office of the Inspector General Reports: Recommendations
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 follow-up 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 Date Report Title Problem Page
April 1999 Indian Trust Funds: Interior Lacks Assurance That Trust Improvement Plan Will Be Effective
Interior "did not clearly specify all of BIA's requirements, including its functional, security, and data management requirements. For example: While Interior stated that the system 'shall 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." 11
"In acquiring its new TAAMS service, Interior 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." 12
September 2000 Indian Trust Funds: Improvements Made in Acquisition of New Asset and Accounting System But Significant Risks Remain
"Interior has not yet completed actions designed to enhance overall trust fund management, including its efforts to revamp policies and procedures for the entire trust management cycle and to address long-standing internal control weaknesses." 2
"[T]here were serious flaws in the way Interior 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." 7
"Interior has not reengineered business 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." 12
"Many of the internal controls now being 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." 15
"Not having a complete information systems architecture to guide TAAMS and other projects under its improvement effort will continue to be a major challenge for Interior." 16
"While the absence of an architecture does not 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." 17
1. General Accounting Office Reports: Recommendations
In 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 *fn25 The Subcommittee's overall grade for the federal government's information security was a "D-." Id. at 16.
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.*fn26
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.*fn27
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.*fn28 Id. at 16.
E. SeNet International, Inc. Reports
On December 7, 1999, then-Special Advisor to the Assistant Secretary for Indian Affairs Dominic Nessi commissioned SeNet*fn29 to assess and evaluate the state of BIA's IT Security.*fn30 The original contract was subsequently modified on 5 separate occasions. As set out in its final version, SeNet was tasked to:
• Perform an Independent Verification and Validation (IV&V)*fn31 of TAAMS Disaster Recovery Program, and deliver an IV&V Report for a December 17, 1999 restoration test with recommendations, and an IV&V 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.*fn32
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.*fn33
• "[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.*fn34
• "[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.*fn35
• "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
In the Risk Assessment, the BIA Security Program, the TAAMS User Access Security Report and the IV&V of TAAMS Disaster Recovery, SeNet issued the following findings:
General Problem Report Section Name and No. Description of Problem Page No.
IT Risk Assessment 2.1.3: Network Resources "Access to most network resources is protected only by user Ids and passwords. No other access control mechanisms, such as firewalls, VPNs, strong authentication, are implemented." 7
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "Users are assigned multiple Ids/Passwords, which forces them to write them down ('yellow sticker' syndrome). This leads to potential misuse of user accounts." 10
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "Accounts remain active after users change roles or leave the agency. This problem is amplified because the 'disenrollment' is much more difficult to enforce, and BIA has found it difficult to cross reference its employee data (obtained from OPM via FPPS) with their systems' user accounts information. Some requests for deleting inactive accounts (e.g., IIM) come from the application owner (OTFM) directly to application support staff bypassing the security officer." 10
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "The security officer can not always positively verify authorizing signatures. Sometimes a telephone conversation is used as a means of verification, which is questionable at best. Sometimes forms come to a system administrator without the authorization signature." 11
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "Additional logistics problems due to interaction between the BIA and the outsourcing organization exist in administering accounts on 'outsourced' resources." 11
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "There is no indication on the form that the person was (or was not) cleared for the position of public trust." 11
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "The paper-based enrollment/disenrollment process is time consuming and bulky." 11
IT Risk Assessment 2.6.1: Identification, Authentication and Authorization "As indicated, authentication relies on user selected passwords. We found that there is no consistent policy regarding password 'strength' or rotation requirements, though for some systems this is changing.... This situation is a serious vulnerability as it allows users to select easy passwords and never change them. Vulnerability testing conducted at the OIRM facility proved this to be the case with many users. Furthermore, some user accounts are shared which makes tracking of security violations virtually impossible." 11
IT Risk Assessment 2.6.4: Perimeter Protection "Weak perimeter protection is by far the most common cause of security breaches (intrusions) by outsiders. Our findings indicate that the current situation presents a serious security risk.... This makes the Albuquerque network and its resources vulnerable to intrusion from within BIA/DOI, from all connected non-DOI agencies, and from the Internet at large. This risk is exacerbated by the fact that the DOINet functions as an ISP for a number of Government agencies and is connected to MAE-East and MAW-West National Access Points, thus opening the network, for all practical purposes, to the world." 12
IT Risk Assessment 3.2: Primary Domain Controller "Anonymous logins are allowed to the ftp *fn36 service." 18
IT Risk Assessment 3.2: Primary Domain Controller (PDC) "A simple test revealed that the [Primary Domain] account... had a trivial password. We were able to log into the system using this account and have complete, unrestricted access.... After expanding the XXXXXXXXXX were ran it through a password cracker.... The cracker broke XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXX.... Many of the passwords were trivial - for example, 'passwd' was very common was well as last/first names and other common English dictionary words." 20
IT Risk Assessment 3.7: IBM P390 "Attempting guest access via the XXXXX failed. The response was [ ]. This could assist a potential intruder to guess the names of users who are defined on the system and proceed by guessing their passwords." 25
IT Risk Assessment 3.5: IDEAS server "[A]nonymous login is accepted" XXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXX." 22
IT Risk Assessment 3.10.: Web Server 1 "TheXXXX allows anonymous login" to the XXXXXXX." 27
IT Risk Assessment 3.12.: Netware Servers XXXXXXXXXX XXXXXXXX XXXXXXXXX "Some accounts do not have passwords XXXXXXXXXXXXXXXXXX. Many accounts do not have a secure password (common dictionary words, first/last name combinations etc.). Many accounts are not required to change password or the interval is greater than 60 days. Some user accounts are assigned access rights beyond their own space in the system. These weaknesses are relatively easy to fix by adopting and enforcing stricter policies. The built in tools plus free utilities can be used effectively to weed out these vulnerabilities." 29-30
IT Risk Assessment 3.13.: Winframe "XXXXXXXXXXXXXXX we were able to download the list of locally defined users. It appears that many users have not logged in to this system since their accounts were created almost two years ago. This might allow an intruder to get in without being noticed.... Although XX*fn37 access is protected by a userID and password, a potential intruder will have many user accounts to try before giving up. Based on our experience with the XXXX, the remote intruder will have a fairly easy job to break into this system." 30
TAAMS User Access Security 2. ATS Security Implementation for TAAMS "[A]s of October 2000, no specific actions were taken towards the implementation of boundary protection on any BIANET node." 34
TAAMS User Access Security AS/400 Password Policy "There is no limit to the number of times users can fail to log into TAAMS. TAAMS accounts are not locked out due to failed login attempts." 35
TAAMS User Access Security AS/400 Password Policy "Currently, the IT security office assigns TAAMS application account Ids and passwords based on a format that is simple to guess. A user, which was given a password by the IT security office, can easily guess the account Ids and passwords assigned to fellow employees and use their identity to log into TAAMS." 36
TAAMS User Access Security Client Application Security "Other than password protected BIOS*fn38 and password protected screen savers, TAAMS workstation provides no security controls. If BIOS password protection is not configured, upon power up the TAAMS application's icon is automatically displayed on the desktop. No LAN or workstation logon are required to display the application's icon." 36
IT Risk Assessment 2.3: Data Sensitivity "The required level of information confidentiality varied between different systems. Although each interviewee could properly estimate the sensitivity of the data he or she was responsible for, there is no formal procedure to assign security classification to an application or to establish an objective measure of sensitivity." 9
IT Risk Assessment 2.4: Security Awareness, Training and Education "The BIA OIRM does not have an information security awareness training program in place. Some information is given to new employees as a part of orientation process." 9
IT Risk Assessment 2.6.2: System Configuration Maintenance "Our findings indicate that there are no consistent standards of system security configurations. In some cases many system configuration parameters are left at their default settings.... Our general observation is that the sophistication of a system's security configuration was determined primarily by the system administrator's knowledge and awareness. The lack of standard procedures makes major systems vulnerable to external and internal abuse. For example, the BIA primary DNS [Domain Name System] server is being used as an unofficial web site for a private company." 11-12
IT Risk Assessment 2.6.6: Content Filtering "There are no known installations of WEB and email content filtering software at any of the BIA computing facilities. Interviews with OIRM management, however, indicated a certain level of concern about potential abuse of internet access privileges and e-mail by some BIA employees and contractors, which can be mitigated by using COTS*fn39 packages." 13
IT Risk Assessment 3.2: Primary Domain Controller "Web Service is enabled with a major vulnerability in the form of an executable script file." 18
IT Risk Assessment 3.3: Backup Domain Controller "For acting as a XXXXXXXXXXXXXXXXXX XXXXXXXXX the only service required is XXXXXXX. The other services, unless absolutely needed, make the XXXX vulnerable to their associated risks." 21
IT Risk Assessment 3.4 Network Management System XXXXX XXXXX "The number of available services is too high for a system with such specific purposes.... This system was also found to be configured with a weak XXX*fn40 community string, this allowed [sic] to retrieve details about the system..." 21
IT Risk Assessment 3.5 IDEAS server "As is the case with other systems, the availability of unused/unnecessary services greatly increases the risk of unauthorized access." 22
IT Risk Assessment 3.5 IDEAS Server "We found that web service is enabled on the server. The fact that the XX is still using the default server page indicated that this service is not in use. Using XX remote admin capabilities a hacker could easily change the home page. Further more [sic], this version of XXXXXX contains theXXXXXXXXX vulnerability which can be used by an attacker to create files anywhere on the system if they have the XXX correct file permission to do so." 24
IT Risk Assessment 3.6: Lotus Notes Server "Access to the web service on this system is user ID and password protected, although the banner indicated 'Enter username for XXXXXXXXX XXXXXXXXXXXXXXXX' which reveals the system's purpose to unauthorized users. Likewise, connection the XXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXX which tells the potential intruder what package is used for e-mail, and thus narrows down his/her search for vulnerabilities." 25
IT Risk Assessment 3.8: SMTP Notes E-mail Server "Web access is protected by user ID and password, but the prompt reveals the system's identity...." 25
IT Risk Assessment 3.10.: Web Server 1 "XXXXXXXXXXXXXXXXXXX which can be used to view any file in the system.... The XXXXXXXXXXXXX files indicate that XXXXXXX is active on this server. This potentially allows any remote user to modify web content on this server." 27
IT Risk Assessment 3.11. Web Server 2 "The XXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXX allows an intruder to search for various files on the system XXXXXXXX. The XXXXXX XXXXXXXXXXXXXXXXXXXXX indicates that XXXXXXXXX is running. It may allow users to upload files to a XXXXX directory or create it if it does not exist. If the file permission on this directory are unrestricted, remote users can upload and execute arbitrary files." 28
IT Risk Assessment 3.11. Web Server 2 "The system is configured with a weak XXX community string (actually the installation default). This can be used to provide a significant amount of information on the system...." 29
IT Risk Assessment 3.12.: Netware Servers XXXXXXXXXX XXXXXXXXXX XXXXXXX "The servers are part of a BIA-wide Novell network which consists of over 100 servers spread through all 12 regions. An intruder can attempt to break into these servers from any attached PC throughout the BIA network (perhaps the entire DOI network)." 29
IT Risk Assessment 3.14.L DNS Server "It is evident that this system has many ports open in addition to the ones needed for the DNS function. The XXXXXX allows anonymous access and the directory allows upload of files. The XXXXXX web vulnerability was designed to display information about the Web server environment, but it parses data requests too liberally and thus allows a person to view a listing of arbitrary files on the Web server host. The XXXXXXXXXXXXXXXX allowed a remote user to execute any command on the target system with the same privileges as the web server. Interestingly, the following page shows up when pointing to a browser to the XXXXXXX address. It was possibly set up by the contractor who installed the XXXXXX or by someone who hacked into it later." 31
TAAMS User Access Security Citrix Security Implications "[E]liminating the need to obtain the client application software in order to run TAAMS increases vulnerability and must be compensated by stricter security controls on the XXX servers." 33
TAAMS User Access Security Citrix Security Implications "Another security problem is theXXXXXXXXXX XXXXXXXXX XXX platform used by the 15 XXX servers. XXX is known to have many security vulnerabilities." 33
TAAMS User Access Security Citrix Security Implications "Finally, because the client application executes on the XXX server, users must be reminded that by turning off their workstation they will not terminate the application. It will continue to execute on the XXX server. The only way to terminate the application is by closing it via the main menu. This may pose a security risk if a power outage occurred at the user's site while users are accessing TAAMS.... If the user leaves the work area and shortly thereafter the power is resumed, the user's instance of the TAAMS application is still running on the Citrix server and can be easily made available again on the desktop. Since the application is already running, intruders do not need XXX and TAAMS user ID or password to launch the application. After ...