Redaction Legend:

2b = Law Enforcement Guideline(s)
2e = Law Enforcement Procedure(s)

Executive Summary

Objective and Scope

Background

Results

conclusion

Appendix I - Detailed Objective, Scope and Methodology

Appendix II - Major contributors to This Report

Appendix III - Report Distribution List

Appendix IV - Response from Director of Investigations, Office of Refund Fraud, to Audit Memorandum

Appendix V - Management’s Response to the Draft Report.

Appendix VI - Description of c2-Level Security

Appendix VII - Glossary of Terms Used in This Report

Executive Summary

With the advent of electronic filing in 1986, the number of tax returns claiming fraudulent refunds has increased dramatically. As a result, the Internal Revenue Service (IRS) developed the Electronic Fraud Detection System (EFDS). At its inception, there were four basic goals for EFDS. These goals were to:

• Automate the labor-intensive manual screening process of the Questionable Refund Program.
• Improve techniques to identify returns with the highest potential for fraud, and ensure that these returns were reviewed.
• Increase data sources to improve detection of fraud.
• Enhance scheme development for referral to the districts for criminal prosecution.

We performed this review to determine if EFDS was meeting its program goals, objectives and proper control standards, and if the Project Office maintained reliable project cost data.

The IRS has achieved many successes relative to its development of EFDS. Overall, EFDS has met most of its program goals and the needs of its users. The Project Office is working toward added functionality to help increase the criminal Investigation Division’s (cID) ability to detect fraudulent returns.

While the automated system is a significant improvement over the manual process used prior to EFDS, there are still changes that can be made to further improve or manage the system. We identified issues of concern regarding security of the system, delivery and effectiveness of some applications, and accounting for project costs. Some of the identified conditions from this report were also reported in prior Office of Audit reports. Specifically, these issues include:

• ****2b,2e****.
• EFDS contingency plans were not updated and tested.
• EFDS Project costs were not accurate and complete.

Although management implemented corrective actions for these conditions, the actions did not resolve the past conditions.

Specific concerns regarding the security of EFDS, delivery and effectiveness of some applications, and accounting for project costs follow.

Based on the sensitivity of the information processed, EFDS must meet controlled Access Protection requirements, also known as c2 security requirements. EFDS obtained c2 security certification from the IRS certifying official on June 15, 1996. However, the issues discussed in this report illustrate that controls to prevent and detect unauthorized access to sensitive taxpayer data are not adequate within EFDS, and call into question whether EFDS should have received its unconditional security certification. We plan to separately review the certification process during Fiscal Year 1999.

Issues discussed in this report include the following:

• Access controls should be improved.
• The EFDS application audit trail ****2b,2e****.
• The EFDS application audit trail is ****2b,2e****.
• Security reviews at the service centers are not being performed.
• Security documentation is not current and, in some instances, does not reflect current system programming.
• contingency plans need to be updated and tested.

We have the following recommendations related to the above issues.

The Project Office should work with EFDS developers to ensure there are adequate controls over user passwords, ****2b,2e****, to ensure that audit trail records are maintained for all accesses to taxpayer data, and to ensure audit trail records are accurate.

The Project Office should review the current c2 required documentation and update the information to reflect the current programming and operating procedures of EFDS. It should also ensure that EFDS contingency plans are updated and tested at least annually.

Information Systems (IS) should clearly define, in the Internal Revenue Manual or other policy statements, who is responsible for performing security reviews on systems such as EFDS, and ensure that these reviews are performed.

We were informed that EFDS will soon undergo a new security certification. In our opinion, taking into account the audit trail and documentation issues discussed in this report, it is questionable whether EFDS should have received its prior security certification. In the upcoming certification process, IS should ensure that the issues discussed in this report are corrected, and that all other controls necessary for a proper certification are in place and functioning.

EFDS will meet all of its stated goals only after all requested applications are delivered and properly functioning. EFDS was not functioning as designed when sorting cases to ensure returns with the highest potential for fraud are reviewed first. Also, some EFDS applications are not being delivered timely by contract developers.

We recommend that the EFDS Project Office ensure program changes are made to EFDS which would allow returns with the highest fraud potential to be worked first. Also, the Project Office and cID should reach formal agreement on the requirements for EFDS. When the functional requirements are delivered, the Project Office should give timely, complete, and detailed feedback regarding changes necessary to the functional requirements.

Improvements are needed to accurately account for EFDS costs. The Project Manager has not ensured that cost figures maintained by the Project Office were complete or accurate. We identified accounting discrepancies in Project Office records that resulted in total costs being understated by $22.3 million. IRS officials need complete, accurate, and reliable accounting data to make informed decisions regarding EFDS costs and benefits.

Using the information we developed as a starting point, we recommend that the Project Office make a thorough review of EFDS cost records to ensure that no other misstatements or omissions have occurred. Also, the Project Office should maintain a schedule to track both non-Project Office and Project Office costs, and should reconcile its cost data to source documentation and to the Automated Financial System (AFS) on a regular basis.

Management’s Response: IS management agreed with the findings and has developed the following corrective actions to address the issues:

• The EFDS Project Office has taken steps to strengthen password controls and will work with the Assistant commissioner for Program Management and Architecture to strengthen access controls and to improve the system’s audit trail capabilities.
• All c2 security documents and contingency plans will be updated according to guidelines. The EFDS Project Office will ensure all controls necessary for security certification are in place.
• The IRS’ Office of Security Standards and Evaluation agreed to perform management reviews to ensure that security reviews of EFDS and other sensitive systems are performed.
• EFDS programming was changed to allow priority returns with the highest fraud potential to be worked first in processing year 1999. In addition, the EFDS Project Office is in the process of implementing a configuration control Board, and Requirements Traceability within the project which will require all partners to agree to the requirements of the system before they are forwarded for approval.
• The EFDS Project Office will use cost information identified during this audit as a beginning and will use IRS mandated systems to continue to track and reconcile costs.

We concur with the corrective actions outlined in their response. Their response is incorporated into the body of the report where appropriate. The complete text of management’s response is presented as Appendix V.

Objective and Scope

This report presents the results of our review of the effectiveness of the Electronic Fraud Detection System (EFDS). The audit was performed at the Ogden and cincinnati Service centers and the EFDS Project Office in Washington, Dc in accordance with Government Auditing Standards. The review was performed from February through September 1998. The overall objective of our review was to determine if EFDS was functioning effectively and if the system was meeting proper control standards. To accomplish this objective, we evaluated whether:

• EFDS had met its program goals and objectives.
• The Project Office had established adequate security and operating controls to safeguard taxpayer data.
• The Project Office maintained reliable project cost data.

Appendix I contains the detailed objectives, scope and methodology for this review. A listing of major contributors to the report is shown in Appendix II.

Background

With the advent of electronic filing in 1986, the number of tax returns claiming fraudulent refunds has dramatically increased. This caused concern to both IRS and external oversight bodies. As a result of these concerns, EFDS was developed by the IRS Research Division, the Los Alamos National Laboratory (LANL), and the criminal Investigation and Electronic Filing Branches at the cincinnati Service center. Shortly after its initial development, EFDS was assigned a project office to oversee future development and improvement of the system. At its inception, EFDS had the following four basic goals:

• Automate the labor-intensive manual screening process of the Questionable Refund Program.
• Improve scoring techniques to reduce excessive volumes and to ensure that returns with the highest potential for fraud were reviewed.
• Increase data sources to improve detection of fraud.
• Enhance scheme development for referral to the districts for criminal prosecution.

During 1994, EFDS was prototyped at the cincinnati Service center. In 1995, a limited version was implemented in the other Electronic Filing (ELF) Service centers. In 1996, additional workload management features were included and the system was further rolled out to the non-ELF Service centers. For 1997 and 1998, the Project Office concentrated on stabilizing and strengthening the current system applications before adding to the system. It has also been preparing the system to become Year 2000 compliant. For the years ahead, the EFDS Project Office plans for the addition of a Scheme Tracking and Referral Subsystem and further integration of fraud detection tools developed by LANL.

Results

Overall, EFDS has met most of its program goals and the needs of its users. With this system, IRS has automated the labor intensive manual screening process of the Questionable Refund Program, increased the data sources available for fraud detection, and has enhanced scheme development through its ability to more concisely examine return information for fraud potential.

Prior to EFDS, criminal Investigation Division (cID) Tax Examiners scanned large volumes of paper Wage Information Fact Sheets that contained current year return information. They were limited to current year information unless they individually researched prior year information on the Integrated Data Retrieval System. With EFDS, these tax examiners now scan potentially fraudulent returns on a computer screen that displays all current year ELF return information, as well as summary information from prior year returns and employers. Thus, examiners are better able to determine fraud potential because more information is available on one screen. In addition, EFDS provides the ability for users to perform their own research through query capabilities. The query capabilities help users to identify schemes by identifying additional returns meeting specific characteristics.

During the initial phases of EFDS, LANL was a major participant in implementing the system. However, the primary purpose of LANL was to develop new methods of finding fraud. After evaluating this primary purpose, cID found the results to be mixed. The IRS has spent over $9.4 million for LANL’s assistance in developing EFDS. Tools for improved fraud detection have been scheduled for delivery since 1996; however, as of September 1998, tools capable of being implemented had not been delivered. According to cID managers, their main reason for recommending that the LANL contract not be renewed was due to LANL’s inability to deliver products that ultimately aided in the detection of fraudulent returns. It is unclear at this time what additional benefits EFDS will receive from LANL’s fraud detection efforts. Based on these facts, we agree with the decision made by both the cID and the EFDS Project Office to discontinue further development by LANL.

While EFDS has experienced many successes, we identified issues of concern regarding:

• Security of the system.
• Delivery and effectiveness of some applications.
• Accounting for project costs.

These concerns are discussed below.

Based on the sensitivity of the information processed, EFDS must meet controlled Access Protection requirements, also known as c2 security requirements. c2 requirements are identified in the Department of Defense Trusted computer System Evaluation criteria, commonly referred to as the Orange Book. The requirements include accountability of users through login and password procedures, discretionary access control mechanisms, audit of security-relevant events, and object reuse. EFDS obtained c2 security certification from the certifying official on June 15, 1996. However, based on the results of our security tests discussed below, we question whether EFDS should have been given unconditional certification. A more detailed discussion of c2 security requirements is contained in Appendix VI.

As part of our review of the effectiveness of EFDS, we performed a number of tests to evaluate the adequacy of EFDS security controls. These tests were performed at the Ogden and cincinnati Service centers. Some testing was also performed at each of the other EFDS host sites (Andover, Austin and Memphis Service centers).

Access controls Should Be Improved

The EFDS system currently resides on a ****2b,2e**** operating system. The EFDS application contains software programs which interface with ****2b,2e**** databases. We found areas of concern with the security of both the ****2b,2e**** operating system and the EFDS application. The EFDS Project Office made the decision to replace the ****2b,2e**** operating system with ****2b,2e**** prior to processing tax returns in 1999. They informed us that this change will address our concerns regarding the ****2b,2e**** operating system; however, the change will have no effect on the EFDS application.

To access EFDS, two sets of passwords are required. ****2b,2e****. We identified the following conditions that weaken these EFDS access controls:

• Initial EFDS application passwords are assigned to users based on their User ID. ****2b,2e****.

• ****2b,2e****

• ****2b,2e****

We presented the information regarding access controls to management in an Audit Memorandum dated June 4, 1998. In that memorandum, we recommended that the Director of Investigations, Office of Refund Fraud, take the following actions:

The Director of Investigations, Office of Refund Fraud, concurred with our recommendation and took appropriate corrective action. A copy of his response is included as Appendix IV of this report.

We also made the following recommendations to Information Systems (IS).

The EFDS Project Office should work with EFDS developers to ensure that the following programming changes are made:

1. ****2b,2e****
2. ****2b,2e****
3. ****2b,2e****
4. ****2b,2e****

To address these issues, IS management provided the following information:

• ****2b,2e****
• ****2b,2e****

The EFDS Application Audit Trail ****2b,2e****

• The EFDS application audit trail ****2b,2e****.

Name	Occupation
Primary & Secondary Social Security Number	Date of Birth Employer Information
Address	Filing Status
Gender	Exemption Identification Data
Refund	Adjusted Gross Income
Wages	Schedule A Deductions
Schedule c Income

• The EFDS application audit trail ****2b,2e****.

• In some instances, actions listed on the EFDS application audit trail are incorrect.

The EFDS Project Office should work with EFDS developers to ensure that the following programming changes are made:

5. Program the EFDS application audit trail to record ****2b,2e****.
6. Design an audit trail application to record ****2b,2e****.
7. Determine why the EFDS application audit trail is recording inaccurate or unnecessary entries. Reprogram the audit report segments of the system to accurately reflect user actions on the system.

In their response, IS managers stated:

• conversion to ****2b,2e**** and the accelerated time frame for Year 2000 deliverables preclude their taking immediate corrective action with current funding. However, the EFDS Project Office has requested the Assistant commissioner for Program Management and Architecture to review, evaluate and assist in formulating a plan for the interface between EFDS and the Audit Trail Lead Analysis System (ATLAS) that will address the audit trail ****2b,2e****. The EFDS Project Office will use Internal Revenue Manual (IRM) section 2.1.10 as the basis for the overall design of the audit trail.

• All programming issues relating to the recording of inaccurate or unnecessary entries have been corrected.

The EFDS Application Audit Trail Is ****2b,2e****

As stated earlier, the EFDS application can generate four different audit trail reports. These reports consist of the Program Audit Trail Report, Return Audit Trail Report, W-2 Audit Trail Report, and DLN Summary Audit Trail Report. We believe these reports are ****2b,2e****:

• The EFDS application audit trail reports are****2b,2e****.

****2b,2e****:

• The audit trail reports use the DLN of the return accessed as the account identifier.
• The records contained in the reports are cumulative from the beginning of each processing year and cannot be segmented by service center site or by a date range.

• The EFDS application ****2b,2e****.

8. The EFDS Project Office should work with EFDS developers to ensure that the following programming changes are made:

• The EFDS application audit ****2b,2e****.
• Adequate file space should also be allocated to ensure available space to generate the reports.

9. The cIO should complete the assessment discussed in the September 1997 memorandum of understanding, taking into consideration the audit trail issues referred to in this memorandum to improve the usefulness of the EFDS application audit trail. consideration should be given to audit trail elements that will be ****2b,2e****.

10. Because of the sensitivity of the data maintained on EFDS, and the number of people who have access to the system (with more planned in the future), the audit trail problems referred to in the report should be included by the IRS as a Federal Manager’s Financial Integrity Act (FMFIA) material weakness.

IS management provided the following:

• The plan formulated by the EFDS Project Office and the Assistant commissioner for Program Management and Architecture will address:
• Implementing the recommended design of an audit trail application that ****2b,2e****.
• Designing the audit trail ****2b,2e****.
• Ensuring the audit trail will ****2b,2e****.

• For processing year 1999, the system has been sized to accommodate report generation.
• The IRS’ Security Infrastructure Implementation Plan (120-Day Report), dated November 7, 1997, responded to the memorandum of understanding. It identified system capabilities, deficiencies, and enhancements planned. For EFDS, it noted that automated analysis tools are not available but that this would be enhanced with the deployment of future architecture. In this regard, it is also noted that the Interim Regional Infrastructure System (IRIS) is intended to audit all events and will forward this information to an authoritative data repository and analysis system. IRIS is scheduled to be deployed as part of the Phase 1, Sub-release 1.3 of the IRS Modernization Blueprint Sequencing Plan.
• A conference call was held on August 13, 1998, between the EFDS Project Office, the EFDS programming contractor and the ccDc to work out EFDS audit trail issues. EFDS is prepared to furnish whatever information is required after being given the audit program record requirements and examining methods for file transfer program retrieval by the center. A subsequent meeting was held on October 22, 1998, by the EFDS Project Office to further develop the ccDc audit trail data requirements with the assistance of the Assistant commissioner for Program Management and Architecture.
• Audit trail weaknesses are currently included in the FMFIA material weakness for Service center security, which is being addressed in the security plans currently being overseen by the Office of Security Standards and Evaluation.

EFDS Security Reviews at the Service centers Are Not Being Performed

The IRM states that the IS Security function at each service center is responsible for performing annual evaluative reviews along with compliance reviews of each information system. This manual also states that the Office of Security Standards and Evaluation is responsible for ensuring that these reviews are performed. We interviewed personnel from the IS Security functions located at six service centers to determine if their offices had ever performed any security reviews pertaining to EFDS. Of the six sites contacted, only one had performed a security review of EFDS. Reasons given for not performing the reviews included lack of resources and questions as to who was responsible for performing the EFDS reviews.

The IRS Information Systems Security Program is outlined in IRM 2 Section 10. The purpose of the Security Program is to:

• Assure adequate security is provided for all data collected, processed, transmitted, stored, or disseminated on information systems and networks.
• Ensure the confidentiality, integrity, and availability of information.
• Provide for the protection of individual, proprietary, financial, tax, mission-critical, or otherwise sensitive information.
• Ensure the ability to maintain processing during and following an emergency.
• Ensure management and employee accountability for computing resources including data and information entrusted to them is accomplishing IRS objectives.

If proper security reviews are not performed on the IRS information systems, the IRS will have no way of determining if it is meeting its Information Systems Security Program objectives.

11. IS should clearly define in IRS’ IRMs or other policy statements who is responsible for performing security reviews on systems such as EFDS, and ensure that these reviews are performed.

IS management pointed out that IRM 2.1.10, Information Systems Security, Section 10.4, Security Guidelines Overview, provides information systems security guidelines, including individual duties and responsibilities for security reviews. The IS Security and certification Program Office has the responsibility for ensuring that this IRM is updated and current.

The IRS’ Office of Security Standards and Evaluation agreed to perform management reviews to ensure that security reviews of EFDS and other sensitive systems are performed. These reviews are now ongoing.

Security Documentation Is Not current and, in Some Instances, Does Not Reflect current System Programming

As previously stated, EFDS is required to meet c2 security criteria. Part of the c2 criteria requires the following documentation:

• Security Features User’s Guide (formerly Users Guide) – A single summary, chapter, or manual in the user documentation shall describe the security features provided by the information system, guidelines on how to use them, and how they interact with one another.
• Trusted Facility Manual (formerly System Guide) – A manual addressed to the system administrator, operator, and Information Systems Security Staff which presents cautions about functions and privileges that must be controlled when running a security facility. The manual shall also include the procedures for examining and maintaining the relevant information for each high-risk access.
• Security Test and Evaluation Report – A document shall be provided which describes the test plan and results of the security features functional testing.
• Design Documentation – Documentation shall describe the philosophy of security protection and an explanation of how this philosophy is implemented and required for each information system.

In reviewing the EFDS c2 documentation, we identified statements referring to security features which are not in place on EFDS, such as ****2b,2e****. In addition, the documentation lacked references to necessary security features, such as application audit trail procedures. Throughout the documents, there are also references to the ****2b,2e**** operating system. Because EFDS will be converting over to the ****2b,2e**** operating system, references to the ****2b,2e**** system in this documentation will also become outdated.

The EFDS Security Features User’s Guide contains the following statement: "…through understanding implemented security mechanisms, users are able to consistently and effectively protect IRS-maintained information." However, if the information found in the c2 documentation is not accurate or does not reflect current system programming, users could rely on controls which are not functioning and compromise the security of the system. For example, if a cID manager relied on the documentation found in the EFDS Users Guide, which states that EFDS user passwords expire after 16 weeks have elapsed, it could cause the manager to rely more on the password aging control and less on manual procedures which instruct the manager to ensure that passwords are changed periodically.

We were informed that EFDS will soon undergo a new security certification. In our opinion, taking into account the audit trail and documentation issues discussed in this report, it is questionable whether EFDS should have received its prior security certification.

11. The EFDS Project Office should review the current c2 required documentation and update the information to reflect the current programming and operating procedures of EFDS.
12. In the upcoming certification process, IS should ensure that the issues discussed in this report are corrected, and that all other controls necessary for a proper certification are in place and functioning.

IS management agreed to take the following corrective action:

• c2 re-certification began in May 1998. All c2 documents will be updated according to guidelines. Management has secured a contractor to assist in performing this task.
• The EFDS Project Office has begun the new security certification process. A Statement of Work was prepared for a contractor to perform the security certification. currently, the contract costs are being negotiated and work is expected to begin soon. The Project Office will ensure issues are corrected and all other controls for certification are in place. Management provided a copy of this audit report to the IS certification Program Section (IS:O:O:S:c) to ensure all issues are corrected and that all other controls necessary for certification are in place and functioning.

contingency Plans Need to be Updated and Tested

Office of Management and Budget circular No A-130, Management of Federal Information Resources, dated February 8, 1996, establishes the policy to manage federal information resources. The circular states that it is the responsibility of agencies, through contingency planning, to "…establish and periodically test the capability to perform the agency function supported by information systems in the event of failure of its automated support. Agency plans should assure that there is an ability to recover and provide service sufficient to meet the minimal needs of users of the system." The IRM states that these plans should be tested at a frequency commensurate with the risk and importance of loss or harm that could result from disruption of information system support but not less than once a year.

We reviewed the EFDS contingency plan dated December 1995. One of the main controls presented in the plan relies on the SRS, located at the cincinnati Service center, to be operational and available to serve as the EFDS backup site. However, the SRS has been unsuccessful as a backup system and has now been converted to a Production Development System for future testing and development. EFDS now relies on tape backup at each site for system recovery. Although the SRS is no longer functioning as a system backup, the EFDS contingency plan has not been updated to reflect this fact. In addition, none of the three EFDS site system administrators we interviewed had ever seen an official EFDS contingency plan or were aware of any specific tests done to test the plan.

By not having adequately updated and tested contingency plans, the IRS does not have assurances that procedures will be in place for EFDS users to effectively evaluate tax returns in the event of minor system failures or a full-scale shutdown of the EFDS. Thus, fraudulent refunds may not be timely identified and stopped. In addition, the system’s ability to restore data after a shutdown remains uncertain without proper contingency testing.

14. The EFDS Project Office should ensure that EFDS contingency plans are updated and tested at least annually. In addition, the plans should be made available to all concerned parties (system administrators, cID system users, etc.).

IS management stated that the documents were not updated due to numerous program and system enhancements over the past few years. However, contingency plans were known and shared with the systems and database administrators (SA/DBA) and the end user. The final contingency is the use of the paper system. The contingency plan will be updated to reflect the system in place for processing year 1999. Each site is required to backup the EFDS data and contingency testing is scheduled locally. Each site SA/DBA has also been provided training at the annual SA/DBA training session to allow them to perform backup and recovery processes for a number of items which could occur in a normal production environment.

EFDS Does Not Sort cases to Ensure Returns With the Highest Potential for Fraud Are Reviewed First

The Prescan Screen is the main screen within EFDS. Each day, this screen shows returns that have been selected for review. This screen provides the tax examiner with a variety of information to assist in the determination of potential fraud.

The Questionable Refund Program training handbook states that Prescan workload is sorted with the intent of "floating" returns with the highest fraud potential to the top of the "pile." This would ensure that the returns with the highest fraud potential would be worked first. According to the handbook and input from the Project Office, the work is sorted by 1) District; 2) Part Number; 3) Refund Stop Date; and 4) Questionable Refund Score. We reviewed 50 returns (30 from Ogden Service center and 20 from cincinnati Service center) and found that the returns with the highest Questionable Refund Scores were not floated to the top of the inventory to be worked first. The returns we compared all had the same District, Part Number, and Refund Stop Date. We found from our test that lower scored returns are being given out when there are many higher Questionable Refund scored returns in inventory ready to be worked.

If the highest Questionable Refund scored returns are not worked first, the IRS risks that some of these returns might not get worked. currently, the program sorts the returns with the highest fraud potential once they are downloaded into groups of 25. As long as all groups are worked timely, there is no real effect from not working the returns with the highest fraud potential first. However, if the system went down or if staffing resources did not allow working all cases within each stop date, refunds with higher fraud potential could be issued before a tax examiner reviewed them.

15. The EFDS Project Office should ensure that program changes are made to EFDS which would allow returns with the highest fraud potential to be worked first.

IS management stated that the changed application which allows priority returns with the highest fraud potential to be worked first was corrected for processing year 1999.

Some EFDS Applications Are Not Being Delivered Timely by contract Developers

Although EFDS has met many of cID’s needs as stated earlier, there are a number of EFDS applications which have not been implemented timely. Three of these applications are as follows:

• contact Employer: contact Employer is being designed within EFDS as a workload management system for Forms W-2 or other income documents requiring verification from employers.
• STARS: The Scheme Tracking and Referral System (STARS) is being designed as a subsystem of EFDS that tracks the status and results of Questionable Refund Program schemes for both ELF and paper returns. It will provide a variety of management and other statistical reports for use by IRS Executives, Treasury, and the congress concerning fraud detection efforts.
• LANL Tools: LANL designed a new workload management system known as case. When functional, case will allow tax examiners to work "groups" of similar returns rather than one return at a time. Returns will be generated in case through a variety of Automatic case Generation Mechanisms that create cases based upon certain return criteria or through other "interactive" tools such as Link and Profiler. Link and Profiler are tools that will allow users to identify trends or similarities among returns and then assign these returns to be worked within the case workload management system.

According to the 1995 EFDS Business case, certain LANL tools (Link & Profiler) and Workload Management features (contact Employer) were to be operational for 1996. Additionally, the 1996 EFDS Business case called for STARS to be operational by 1997. As yet, these applications have not been implemented or are not currently functioning. STARS was scheduled to be implemented in January 1999 and the LANL tools & contact Employer are scheduled to be implemented in January 2000.

There were various explanations given for the missed delivery dates. We were unable to determine the exact cause for each application. We were given information about a number of factors that could have affected the delivery of these applications.

• LANL’s original purpose was to develop new techniques for identifying fraudulent returns. However, it appears that LANL has been more research-oriented than production-oriented. They have been unsuccessful in converting their research ideas to final usable products. In addition, adequate oversight may not have been provided in monitoring LANL’s efforts. A cID memorandum dated May 22, 1998, stated the following: "Office of Refund Fraud and the Project Office by fall of 1996 lacked knowledge of the details of LANL work. criminal Investigation Division management in the Office of Refund Fraud asserted itself to correct this."
• EFDS was initially developed using an accelerated Systems Development Life cycle approach. This approach caused some applications to be rolled out before they were completely functional and useful. As a result, the Project Office had to reprogram and rework some of the applications. The Project Office is no longer using the accelerated Systems Development Life cycle and has committed to fully develop these applications before implementation.
• STARS may have been delayed because complete requirements had not been provided to the contractor. There is a disagreement between the EFDS Project Manager and the cID on this issue. cID management believed they had delivered complete requirements, however the Project Manager disagreed.

16. The Project Office and the cID should reach formal agreement on the requirements for EFDS. When the requirements are delivered, the Project Office should give timely, complete, and detailed feedback regarding necessary changes.

IS management stated that System Development Life cycle meetings, along with the appropriate walk-throughs, have been ongoing between EFDS Partners since August 1997. The EFDS Project Office is in the process of implementing configuration control Board (ccB) and Requirements Traceability (RT) within the Project. This requires all partners to agree to the requirements before they are forwarded for approval. The processes for RT need to be defined and implemented to assist the ccB in making informed decisions on requirements and changes within the system.

Improvements Are Needed to Accurately Account for EFDS costs

The Project Office has made some efforts to maintain appropriate cost records relating to EFDS. However, the Project Manager has not ensured that cost figures maintained by the Project Office were complete or accurate. We identified accounting discrepancies in Project Office records, which resulted in total costs being understated by $22.3 million. This $22.3 million included $11.9 million in expenditures incurred by the IRS Research Division, and $10.4 million in errors and omissions.

• Expenditures incurred by the IRS Research Division were not included.

• Project Office cost data contained posting errors, math errors and omissions, which understated costs.
• To ensure that expenditures do not exceed allocations, the Project Office tracks the annual allocations and expenditures for each of the EFDS Project cost Accounting Subsystem (PcAS) codes they are assigned each year. However, the Project Office does not reconcile its cost data to supporting documentation or to the AFS (of which the PcAS is a subsystem) to ensure its accuracy. Our comparison of Fiscal Year (FY) 1997 Project Office costs to supporting documentation identified posting and math errors that overstated expenditures by over $300,000. In addition, the Project Office could not provide detailed support for FY 1995 and FY 1996.

As a result, IRS managers may not get complete, accurate, and reliable data to make informed decisions regarding EFDS costs and benefits. For example, the EFDS Business case prepared by the Project Office in September 1996 stated that project costs through the end of FY 1996 were $46.3 million. Our review placed the actual expenditures in excess of $56.4 million.

17. Using the information we developed as a starting point, the Project Office should make a thorough review of EFDS cost records to ensure that no other misstatements or omissions have occurred. The Project Office should maintain a schedule of non-Project Office costs and Project Office costs. The non-Project Office costs should include those costs identified in this review plus any other identifiable costs. The Project Office should maintain supporting documentation for each of these amounts. The Project Office costs should include costs for each EFDS PcAS code since FY 1995 when the Project Office was established. Each PcAS code amount should be supported by an AFS report containing the most current actual data. The sum of these two amounts is the total EFDS Project cost. This is the amount that the Project Office should use when preparing reports for or providing cost data to users outside of the Project Office.
18. The Project Office should reconcile its cost data to source documentation and to AFS on a regular basis. The amount recorded should be changed if the purchase order or an expenditure amount differs from the requisition amount. Reconciled Project Office cost data should be archived at the end of each fiscal year for future reference.

IS management responded with the following:

• For FY 1994, (pre-Project Office) hardware and software was acquired through multiple sources. Therefore, historical documents were not centrally maintained. The Project Office requested and received all known historical documents in an effort to preserve this information. For FY 1995 and FY 1996, the financial process had been very volatile. continuing Resolutions, No-Year funds, purchasing through the "exception" rule, all attributed to the inability to reconcile all monies to the then established PcAS codes. Management stated they will begin with the historical information already sorted via this investigation and use IRS mandated systems to continue to track costs.
• EFDS has made an effort to maintain accurate and appropriate cost records. Discrepancy reports were submitted to the AFS organization; however, fiscal year closure prohibited its update. The Project Office currently reconciles costs monthly between AFS and our source documentation. Reconciled Project Office cost data is archived at the end of each fiscal year.

conclusion

With the development of the EFDS Project Office and through coordination with the cID, the IRS has achieved many successes relative to its development of EFDS. Overall, EFDS has been effective in meeting most of its program goals and the needs of its users. The Project Office is working toward added functionality to help increase the cID’s ability to detect fraudulent returns.

While the system is a significant improvement over the manual procedures used prior to EFDS, there are still changes that can be made to further improve or manage the system. Security controls should be strengthened to help protect the taxpayer data contained within EFDS. The implementation of applications which have been in process for a number of years should be given priority for timely completion. Finally, the Project Office should implement controls to maintain accurate and complete cost data for the project.

Implementing recommendations made in this report will help ensure taxpayer privacy, protect revenue, and enhance the reliability of management information.

Detailed Objectives, Scope and Methodology

The overall objective for this review was to determine if the Electronic Fraud Detection System (EFDS) was functioning effectively and if the system was meeting proper control standards. To accomplish our objective, we performed the following sub-objectives and audit tests.

1. We determined if EFDS was meeting program goals and objectives.

1. Determined if EFDS met its four basic goals to: automate the labor intensive manual screening process; improve scoring techniques to reduce volumes and ensure the highest potential fraudulent returns are reviewed first; increase data sources to improve detection; and enhance scheme development.

1. Reviewed the EFDS Business case and interviewed appropriate criminal Investigation Division (cID) or EFDS Project Office personnel to learn the intent behind the goals and what was planned by management to achieve the goals.
2. Interviewed cID personnel and reviewed EFDS user manuals or other documentation.

a) Identified the manual procedures, data sources available, and scheme development procedures used prior to EFDS.

b) Identified the EFDS procedures, the data sources used, the scoring techniques, and the scheme development procedures currently being used by EFDS.

3. Interviewed cID managers and tax examiners to get their feedback concerning whether these goals had been met.
4. Physically used some of the features of EFDS (prescan, query, etc.) and compared these features to the old manual screening procedures used prior to EFDS (paper Wage Information Fact Sheets).
5. Reviewed a sample of 50 EFDS prescan cases (30 from the Ogden Service center and 20 from the cincinnati Service center) from 10 different work "chunks" (5 cases from each "chunk"). Reviewed cases to determine if returns with the highest fraud potential were generated first.
6. compared the data sources available before EFDS to those now available through EFDS to determine if additional data sources were created with the establishment of EFDS.
7. Reviewed cID reports, both before and after EFDS was developed to determine if:

1. EFDS was more efficient (work more cases per hour) than prior manual processing methods.
2. Improved scoring techniques have reduced the number of non-fraud returns reviewed.
3. Increased data sources improved fraud detection.
4. Scheme development procedures have improved.

2. Determined if the system was meeting user needs.

1. contacted employees at INOMS Help Desk and requested a list of NOccs issues closed during calendar year 1997 and any open NOccs issues.
0. Reviewed a sample of 30 closed NOccs issues to determine if they were closed timely and properly resolved.
1. Reviewed a sample of 20 open NOccs issues to determine if any serious problems were not being timely addressed.

2. We determined if EFDS data were safeguarded and being used appropriately.

1. Determined if controls (e.g., password assignment) were in place and functioning properly to ensure that only authorized personnel had access to the host site systems in the Ogden and cincinnati Service centers.

1. Determined if security checks were properly performed on contract vendor personnel.
2. Determined if a security officer had been established and that the duties for this job were being performed.
3. Determined if the following security documents existed for EFDS:

1. Security Features User’s Guide - A document describing the system security features, how to use them, and how they interact.
2. Trusted Facility Manual - A document stating the cautions to be observed in controlling functions and privileges. Also, procedures for maintaining and examining the audit trail records.
3. Test Documentation - Procedures for testing security features, and the results of such tests.
4. Design Documentation - A document describing the manufacturer’s philosophy of protection and how this is built into the information system.

1. Determined if system contingency plans had been developed and whether proper backup and recovery procedures were in place in the event of a system failure.

a) Interviewed host site administrators and Project Office personnel to determine if a contingency plan existed and what backup and recovery procedures were in place for the Ogden and cincinnati Service center host sites.

b) Reviewed the plan and recovery procedures to determine if controls were adequate.

c) Determined if the plan had been tested and the results of any tests.

2. Determined if EFDS was Year 2000 (Y2K) compliant or had plans to become Y2K compliant.

1. Interviewed the project manager and the Y2K coordinator regarding Y2K compliance of the system.
2. Reviewed documentation regarding system compliance.
3. Determined what plans the Project Office had to make the system Y2K compliant.
4. Reviewed the plans for timeliness and adequacy.

1. Evaluated the effectiveness of, and compliance with, new internal controls implemented by the chief Information Officer organization, including the direction and oversight provided by the following offices:

1. Government Program Management Office.
2. Systems Standards and Evaluation Office.
3. Performance Management Office.

1. Determined what taxpayer information was available on EFDS and if the possibility existed that unauthorized accesses to the information could occur.

1. Determined what taxpayer information was available on EFDS and the System Recovery Server.
2. Determined the number of users who had access to EFDS.
3. Attempted to determine all possible ways EFDS could be accessed and if a working audit trail existed which could identify improper accesses to the taxpayer data.

1. Determined if the audit trail information was valid and reliable.

1. Accessed 155 records from the various files available on EFDS and compared the accesses back to the audit trail reports. These records were selected from all EFDS host sites (Andover, Austin, cincinnati, Memphis, and Ogden Service centers).
2. Determined if audit trail report information was incorrect when it showed employees were accessing taxpayer accounts during their off-duty hours.

1. Determined if the audit trail reports were properly reviewed on a regular basis.

1. Determined who was responsible for generating and reviewing EFDS audit trail reports at the Ogden and cincinnati Service centers.
2. Interviewed those with responsibility over reviewing audit trail reports to determine how often they generated the audit trail reports and what information they looked for when reviewing the reports.

1. Evaluated the audit trail reports to determine if the information was meaningful and useful and whether unauthorized employee accesses could be readily identified.

1. Reviewed the information contained on the EFDS Return and Document Locator Number audit trail reports to determine if enough information was available to make the reports meaningful.
2. Had three auditors in the Ogden Service center access their own accounts to determine whether these accesses would be easily identified on the audit trail reports.

2. We determined if vendor contracts addressed user needs and whether the Project Office maintained reliable project cost data.

1. Interviewed Project Office personnel to determine how project costs are accumulated, tracked, and controlled.
2. Reviewed these procedures to determine if proper and reasonable.
3. Reviewed the Project Office records to determine if the expenditures were appropriate, and to determine the completeness and accuracy of the recorded amounts.

1. Footed and cross-footed the EFDS Lifecycle cost Figures spreadsheet, which reports project costs by Sub-Object class (SOc) and by fiscal year.
2. Traced the Fiscal Year (FY) 1997 cost figures from the EFDS Lifecycle cost Figures spreadsheet to each SOc detailed ledger.
3. Reconciled the SOc detailed ledgers’ individual and collective beginning balances to EFDS’ FY 1997 appropriation.
4. Footed each SOc detailed ledger.
5. Selected a sample of entries from each SOc detailed ledger and traced to supporting documentation (timecards, travel vouchers, training requests, invoices, etc.).
6. For each SOc, traced a sample of supporting documents to the SOc detailed ledger to determine the completeness of the recorded amounts.
7. Traced all transfers among the SOc detailed ledgers to supporting documentation.
8. Determined if the Project Office reconciles its project cost data with the Project cost Accounting Subsystem (PcAS) cost data maintained by the Office of the chief Financial Officer.
9. Obtained a PcAS report for FY 1997 EFDS expenditures by SOc from the Budget Execution Office and compared the individual and collective SOc expenditures listed on the report to the amounts recorded by the Project Office.

1. From accounting records, determined the cost of the project from its inception to the current date.

1. Determined the cost of the project from its inception to the date the Project Office was established.

1. Interviewed Project Office and cID personnel to determine what has been delivered and what is planned for future delivery from LANL.
2. Reviewed present and future spending for the LANL contract.
3. Reviewed decision to discontinue funding for LANL by Project Office and cID.

Major contributors to This Report

Report Distribution List

chief Information Officer IS

Deputy chief Information Officer, Systems IS

Assistant commissioner for Systems Development IS:S

Assistant commissioner for Service center Operations IS:Sc

Director, Office of Information Resources Management IS:IR

Director, Office of Systems Standards and Evaluation IS:E

Director, Office of Security Standards and Evaluation IS:E:S

chief, Information Systems Audit Assessment and control Section IS:I:IS:O:A

Audit Liaison, Information Systems IS:I:IS:O:A

EFDS Project Manager IS:AD:SP:E:EFDS

Assistant commissioner (criminal Investigation) OP:cI

National Director, Tax Refund Fraud OP:cI:ORF

National Director for Legislative Affairs cL:LA

Office of Management controls M:cFO:A:M

Response from Director of Investigations, Office of Refund Fraud, to Audit Memorandum

Response has been removed due to its size. To see the complete Response, please go to the Adobe PDF version of this report.

Management's Response to the Draft Report

Response has been removed due to its size. To see the complete Response, please go to the Adobe PDF version of this report.

Description of c2-Level Security

The Department of Defense has developed a multi-level system for classifying computer system security, commonly known as the Orange Book. The classification system ranges from class D (Minimal Protection) to class A1 (Verified Design). The Department of the Treasury requires that its automated information systems "processing, storing, or transmitting sensitive but unclassified data will meet the requirements for a c2 level of protection (controlled Access Protection)."

Systems in the c2 class enforce a finely grained discretionary access control mechanism, making users individually accountable for their actions. This accountability is achieved through login procedures, auditing of security-relevant events, and resource isolation. Systems in this class are required to achieve a minimum level of assurance through requirements for system architecture, system integrity, and security testing. Federal agencies operating class c2 systems are also required to maintain documentation covering the security features of the system as well as testing and design documentation.

The risk of not meeting one or more of the c2-level requirements can lead to the opening of security exposures in the system. For example, if a system does not meet the Object Reuse requirement (resource isolation), it runs the risk of having deleted data retrieved without the owner’s consent. The Object Reuse section requires that the system assure that a storage object (e.g., disk file, etc.) has been cleared before it is initially assigned, allocated, or reallocated to a system user. Failure to clear the object before assignment allows the newly assigned user the opportunity to retrieve deleted data from the object.

Glossary of Terms Used in This Report