Copyright 2003 Information Systems Audit and Control Association. All rights reserved. www.isaca.org.

Preventing EFT Fraud

By John E. Humphries, Jr., CISA, CISSP, GSEC

uring the past two years, numerous stories have surfaced in the news pertaining to fraud and unethical conduct in the corporate world. White-collar crime seems to be running rampant throughout the world. Fraud costs American companies US $400 billion per year, according to the Association of Certified Fraud Examiners. In Britain, the Telecoms UK Fraud Forum estimates US $1.575 billion is lost annually to telecom fraud.1 One can only imagine the annual impact that fraud has on corporations globally. Another alarming trend involves the use of computers and their use in committing fraud and misconduct. The scams perpetrated by computer fraud offenders often are elusive, creative, complex and sometimes include a thorough knowledge of IT and business processes. The electronic funds transfer (EFT) process is a widely used technical solution deployed by corporations throughout the world to transmit payment instructions to financial institutions for payment of employees, companies and/or other entities. Often, companies transmit large sums of money electronically to the bank with the click of a mouse. Upon completing EFT reviews, one often notes ineffective, alarming technical configurations, which easily could provide an avenue for fraudulent activity. This article will discuss EFT from an IT and process orientation perspective, and it will examine how to prevent EFT fraud from occurring at an organization, with the intention keeping a company out of the headlines. Although technical configurations exist, this paper addresses one frequently deployed solution that includes components and the steps cited in figure 1. Figure 1Sample Solution

EFT Process
The EFT process includes the following steps: Employee uses enterprise resource planning (ERP) graphical user interface (GUI) to request the generation of an EFT file. The request is received by the ERP system, and the EFT program executes. EFT data are extracted from the ERP database and incorporated into a flat-text file. This file is saved to a secure directory located on the ERP system or network server. An employee copies the EFT file from the ERP system to a diskette located in the network workstation. An employee inserts the diskette into a standalone EFT workstation where the EFT application resides. The EFT file is transmitted to a bank as an encrypted flattext file. The bank system receives the EFT file, and the back-end systems process payment instructions. Although the term funds transfer has various meanings, this article specifically will consider the EFT process. The concepts discussed will outline key risks and compensating steps designed to assist the reader in evaluating and improving his/her companys EFT process.

Motivations of EFT Fraud

The motives behind EFT fraud are vast and complex. Some of the common factors include a significant financial profit, a desire to master the EFT system or process, the thrill of the deed and employee revenge. Large amounts of money often are transmitted over EFT networks during a single EFT file transmission. By fraudulently altering payment instructions (e.g., bank account details or currency amounts) in the EFT process, an individual potentially could steal large sums of money. Although it is difficult, if not impossible, to obtain accurate statistics on EFT fraud, one could suggest that companies lose huge sums each year due to fraudulent EFT payment instructions. To avoid media attention and a potential decline in share price, most companies prefer not to go public with embarrassing information pertaining to fraudulent activity. Hackers commonly penetrate systems as a recreational activity. When asked about their reasons for compromising a computer or introducing a virus on the Internet, hackers often claim that their intentions were not to cause harm but to see if they could do it. Similarly, the intentions of those who com-

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 4, 2003

mit EFT fraud may be to determine whether they can perfect the EFT system and/or process. EFT crime offers an intellectual challenge, which is as attractive to some as the opportunity for financial gain.2 In todays corporate world, mergers, acquisitions and streamlining are common occurrences. Positions sometimes become redundant, and employees consequently lose their jobs. Such an environment increases the risk of disgruntled employees and fraudulent activity. For example, an employee at the EFT controls could anticipate a loss of employment and retaliate against the company by releasing a fraudulent EFT payment to his/her own bank account.

Steps For Prevention

Prior to defining the steps for preventing EFT fraud, it is important to outline common risks associated with the EFT process. Based on the solution depicted in figure 1, figure 2 presents risks that could increase a companys vulnerability to fraudulent activity. Figure 2Risks

Define EFT Policies and Procedures Finance managers aim to prevent their employees from committing illegal activities. The solutions include commonsense policies and procedures pertaining to auditing regularly, reconciling promptly, screening employees carefully and requiring two approvals prior to transferring funds.3 To ensure consistency of EFT practices, it is important to establish formal procedures. All employees involved should be educated on the procedures. In addition, it is necessary to establish an EFT policy which defines acceptable practices and implications of noncompliance. Prior to participating in the EFT process, employees should be required to agree formally to the conditions stated in the policy. The criticality and integrity of the EFT process must be emphasized in the policy. Companies often fail to establish EFT policies and procedures, which, in the event of illegal activity by employees, could make prosecution more difficult. Ensure Physical Security Surrounding All EFT Components Physical security surrounding the EFT hardware and software components cannot be emphasized enough. Entire solutions could be compromised easily because of an outright disregard for physical security. Frequently, companies install a financial institutions EFT software on a standalone workstation. If this workstation lacks physical security, the potential of fraudulent activity dramatically increases. Implement Effective EFT Application Security Organizations often wholeheartedly purchase and immediately implement a new application without understanding the security capabilities and limitations of the software. An emphasis is placed on implementing the application in production quickly. Similarly, EFT applications sometimes are placed in a production environment without the appropriate logical controls and the IT departments knowledge. While EFT software packages support similar security capabilities, these applications also offer unique configurations. Prior to implementation, an application security review should be conducted to determine the appropriate security parameters. In addition, user profiles should be designed to enforce segregation of duties among sensitive EFT functions (e.g., application IDs with the ability to transmit EFT files or create/delete user IDs) and the least privilege principle. Figure 3 provides an example of a user profile matrix. The matrix demonstrates that any combination of users may be used in the creation, authorization and transmission of files, provided that two separate authorizers are used. In the following examples, at least two users are required to complete the transaction. This example demonstrates the simplicity of generating secure EFT access profiles. Figure 3User Profile Matrix

To reduce the risk of fraudulent activity, several controls can be integrated into the EFT processing environment. However, the controls should not be considered a cure-all. Define the EFT Process and Control Points It is important to understand the EFT solution and process from beginning to end. To facilitate this understanding, a useful exercise involves defining the EFT process and procedures used to transmit EFT files to the financial institution. During this process, it also is useful to identify risks, vulnerabilities and control points. Technical specifications often provide an excellent starting point. In addition, it is helpful to conduct an informal workshop with all necessary employees involved in EFT processing (e.g., finance, payroll, IT). Any employees involved in EFT manual and automated processes and supporting infrastructure should be consulted. Upon identification and definition of the EFT process, risks, vulnerabilities and control points should be outlined on paper to aid in understanding all parties involved. Refer to figure 2 for examples of common risks associated with the EFT process.

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 4, 2003

Upon completing the access security review and designing user profiles, management endorsement should be obtained through sign-off. Although this may seem too official, the transmission of millions of US dollars each year through an EFT application is a serious concern. Some key items to consider prior to implementing an EFT application include: Minimizing the number of application administrators Changing the default password for administrator accounts Maintaining passwords to default application IDs in a secure location Requiring dual authorization for the creation and deletion of users Requiring dual authorization for the release of EFT files to the bank Ensuring timely maintenance of user accounts Limiting failed login attempts to the EFT application Requiring periodic password changes Limiting dollar amounts of EFT transmissions (e.g., payment amounts exceeding US $15 million cannot be transmitted without manual intervention)4 Implement Effective Network Operating System Security As mentioned earlier, physical security of an EFT workstation is crucial. If a workstation is physically accessible, the network operating system could serve as an avenue of attack. In addition, network operating system services and ports should be reviewed for appropriateness. This commonly is referred to as hardening the operating system, and it is similar to the application security review process. Services and ports not required within the operating system should be disabled to reduce the risk of unauthorized access to the workstation. An additional control entails disabling the floppy drive to prevent the network operating system from booting from the diskette.5 This prevents an individual from easily gaining unauthorized access to the EFT application. The following are additional controls and resources, which could be used to enhance network operating system security: Limiting the number of network operating system users with access to the EFT workstation Enabling the screensaver timeout feature Restricting remote access to the terminal through inbound modem connections Utilizing baseline network operating system standards to secure the platform (The SANS Institute and the US Department of Defense offer excellent resources for securing a variety of network operating systems.) Implement Effective Security Surrounding EFT Data Ensuring integrity and confidentiality of data throughout the EFT process is critical. EFT crime often is difficult to detect because data can be manipulated by instructions hidden in complex computer software. As figure 1 illustrates, EFT data can reside in multiple locations and must be secured at several layers (e.g., database, network operating system, diskette and during transmission). Since EFT data potentially are subject to modification at the mentioned layers, automated and manual controls should be employed to minimize risk. For example, upon generation, an EFT file could be saved to a directory that exists on a network server. Access surrounding the EFT file and directory

should be restricted tightly to prevent tampering with monetary amounts and/or bank account details. In addition, as figure 1 illustrates, the EFT process could involve saving data to diskette. Attention should be given to physical security surrounding the diskette to decrease the risk of data modification. It is good practice to maintain the diskette under dual control until the EFT file is transmitted to the financial institution. EFT processes sometimes involve use of Windows Notepad to make revisions to EFT data. This practice leads to considerable risk exposure, and is strongly discouraged. Uncontrolled changes to data could result without a supporting audit trail. Finally, during transmission of the EFT file to the financial institution, data must be encrypted to ensure privacy and integrity. Encryption of EFT data can occur via hardware or software. Implement Effective System Logging Some individuals dismiss the value of system logging and argue that it is a time-consuming process that wastes system and operational resources. However, most people familiar with the importance of the EFT process would agree that the benefits of logging definitely outweigh the costs. Most important, logging establishes a baseline that can be used to measure unusual activity. Specifically, logging allows one to capture unauthorized modification of EFT payment instructions and/or transmission of EFT files. Logging also provides an audit trail, which could serve as evidence during legal proceedings. When one considers the EFT architecture, it becomes evident that logging can occur at multiple levels. As figure 1 illustrates, several points exist within the process where data could be viewed and/or altered. This is an important reason for enabling logging and periodically monitoring activity. The following are examples of activities that could be logged during the EFT process: Generation of EFT files View and edit access to the EFT file, which is saved to a network operating system directory and/or diskette Changes to the database that maintains the EFT data Creation and deletion of EFT application user IDs EFT transmissions to financial institutions Upon defining the EFT architecture and process, it is relatively easy to determine where system logging should be enabled. A strategy that considers the following topics should be defined: Components to be included in the logging process (e.g., EFT application and network operating system) System activity to be logged (e.g., generation of EFT file) Storage location of system log files Parties responsible for monitoring system logs Frequency of monitoring system logs Interpretation of system logs Examples of unusual activity noted in system logs Procedures for handling unusual activity discovered in system logs Archiving and data retention of system logs and EFT reports Conduct Reconciliations Similar to logging, reconciliations can occur at several points within the EFT process. Reconciliations are important and allow one to determine whether data have been modified

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 4, 2003

during any stage of the EFT process. Upon generation of the EFT file, a record count (e.g., total transactions) and total monetary amount should be produced. This information can be used as source documentation for future reconciliations. Following transmission of the EFT file to the financial institution, an EFT report (e.g., transaction report) should be downloaded from the financial institution. This report provides a record of total transactions and monetary amounts and can be used to compare source transactions and monetary amounts. Remember to save all documentation, which could be required for future reference. These documents serve as an audit trail and substantiate the reconciliation process. Failure to retain this information could disrupt the trail of evidence and hinder a legal case. As proof that the reconciliation actually occurred, the person responsible should initial the documentation. Upon sending an EFT file to the financial institution, discrepancies could arise between total monetary amounts transmitted and received. Comprehensive, frequent reconciliations could prove valuable in resolving gaps, which result from human and technical errors.

Authors Note:
I would like to extend a thank you to Norm Smith in Sydney, NSW, Australia, for sharing his insights on EFT processing with me.

References
Lillington, Karlin, Hot on the Trail of Credit Crooks, Lycos Inc., August 2002, www.wired.com/news/ebiz/ 0,1272,44203,00.html 2 Selected Electronic Funds Transfer Issues, Privacy, Security, and Equity, www.wws.princeton.edu/cgi-bin/byteserv.prl/ ~ota/disk3/1982/8223/822303.pdf 3 Gamble, Richard, Short Circuiting Wire Transfer Fraud, Controller Magazine, August 1998, www.business financemag.com/archives/appfiles/Article.cfm?IssueID=325 &ArticleID=4389 4 Guidelines for the Use of DeskBank, Australian Department of Treasury and Finance, October 1999, www.treasury.tas.gov.au/domino/dtf/dtf.nsf/acca8cad9e1c8f86 4a256807001974ce/b3bb3aa29bbb681c4a256818000b1f9d? OpenDocument 5 Windows NT Security Step By Step, version 2.15, The SANS Institute, 30 July 1999, page 11 John E. Humphries, Jr., CISA, CISSP, GSEC is a technology auditor at JPMorgan Chase in New York, NY, USA. Previously, he served as an IT auditor at Ernst & Young Australia and at the Federal Reserve Bank of Chicago. He periodically volunteers for the SANS Institute and he is a member of the Information Systems Audit and Control Association (ISACA). Any comments, questions or suggestions related to this article can be forwarded directly to Humphries at shantou@hotmail.com.
1

Conclusion
This article began with a definition of EFT and common motivations of individuals who commit EFT fraud. Steps thereafter for preventing EFT fraud were discussed. Although the steps mentioned will not prevent fraud completely, implementation of these practices into a companys EFT process will reduce the risk of EFT fraud occurring in the work environment. Armored cars with armed guards frequently deliver and retrieve cash from businesses. Security surrounding the delivery of physical money is high. Conversely, companies frequently transmit large sums of money in electronic form to financial institutions on a monthly basis. Some of these companies fail to incorporate basic physical and logical controls into their EFT processing environment. Consequently, anyone with an understanding of the EFT process and technical knowledge could successfully transmit fraudulent payment instructions to a financial institution. Is your company susceptible to EFT fraud?

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the Information Systems Audit and Control Association, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal. Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content. Copyright 2003 by Information Systems Audit and Control Association Inc., formerly the EDP Auditors Association. All rights reserved. ISCATM Information Systems Control AssociationTM Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25 per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited. www.isaca.org

INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 4, 2003