Systems auditability and control in an EFTS environment

Transcription

1 Systems auditability and control in an EFTS environment by RUSSELL DEWEY SRI International Menlo Park, California INTRODUCTION Losses from accidental and intentional acts involving computers and data communications in financial institutions are growing. The current estimate of losses from credit card fraud alone is $500 million and could rise to $6 billion to $10 billion by Of greater concern than this problem is the growing potential for single instances of massive losses as EFTS grows and participants become highly dependent on continuously available computer services where most of their assets are stored in electronic form. There is obviously a need to apply the principles of secure systems to the emerging development of EFTS, and much work has already been completed and published (See References 1 through 9). Most of this work has been focused primarily on the technology of security, such as: Personal Identification Numbers, Plastic Card Security, Cryptography, Physical Security, and Operating System Integrity. On the other hand, there is also a growing awareness that EFTS security is a "people" problem. The risks, threats, and vulnerabilities to EDP systems derive primarily from the activities of individuals, either accidental or deliberate. 7,10 In the EFTS environment, individuals may be employees of the financial institutions, merchants, telephone company, hardware and software vendors, maintenance personnel, computer service bureaus, security personnel, and auditors. Between the two orientations-technology and occupation-a body of information is emerging regarding audit techniques, and system application controls that, if implemented, could help reduce the potential for significant 10ss.5 The purpose of this paper is to review and summarize the state of that art within the context of the EFTS environment. THE EFTS ENVIRONMENT The number of financial terminals being installed in remote locations to automate all or part of the transfer of credits and debits is increasing. By 1980 there may be over 100,000 terminals providing a variety of EFTS services, including: Deposits With drawls Transfers of balances between accounts Direct Debits for purchases Balance inquiries Check authorization and guarantee Credit card authorization and data capture Corporate cash management Funds concentration Corporate to corporate wire transfers During the last few years, components of EFTS technology have begun to be implemented in a variety of different configurations, including shared access networks. A shared access network is one which allows for the switching of EFTS transactions to more than one possible destination, regardless of ownership considerations. Since this environment is more complex than single institutions dedicated to EFTS, we will focus on shared access networks for this paper. The likely evolution of such shared access networks may be described by its principal components: 1. Remote Terminal-The terminal may be operated entirely by one person, such as an Automated Teller Machine (ATM), check guarantee terminal or cash management terminal. They may also be operated by an intermediary, such as a financial institution teller or merchant sales person. 2. Communications-The terminal may be connected to a computer located at a merchant, corporation, or potentially a government facility. In this case, the originating computer must be connected to the destination computer through intermediate computers and telephone communications facilities. Depending on the complexity of the local environment, the number of institutions participating, and economic considerations, the terminal may optionally be connected directly to a local financial institution, directly to a joint 185

2 186 National Computer Conference, 1978 venture shared EFTS switch, or through common carrier facilities directly to the destination. 3. Files-EFTS files take several forms and may be found in several discrete locations: At the remote operator (merchant, corporation, government agency) there may be audit trails of EFTS transactions passing through, or decision parameters to control the processing of transactions when the remainder of the network is down. There are likely no balances, account data, or financial institution programs. At the acquiring financial institution there may also be audit trails, but also balances and account data for its merchants and corporate customers and for transactions that do not need to be switched, such as an "on-us" debit. The acquiring financial institution may also have decision parameters to control the processing of "not-on-us" transactions when the remainder of the network is down. At the EFTS switch there may be audit trails and decision parameters for any destination facility that may be down. There are likely no financial files, other than reconciliation totals and settlement amounts between institutions. At the destination financial institution there may be audit trails, memo-post master file balances, transaction files with backup and off-line master files with back-up. 4. Communication Equipment-Each computer site will have specialized hardware to interface the EDP system to the external communication lines. 5. EFTS Software (Program Logic)-Each computer that is expected to participate in such an EFTS network must have specialized programs developed. These include: Terminal protocols Message format conversions Switching and routing logic Interface logic/protocol to other computers Interface to existing financial software, such as: - Demand deposit accounting - Savings account accounting - Customer information data bases - New account processing Specialized audit techniques and application controls EFTS APPLICATION AUDIT TOOLS AND TECHNIQUES The transition from traditional financial institution recordkeeping to today's EFTS application systems-characterized by large on-line master files, lack of manual intervention, and remote terminal entry-has brought with it design concepts that cannot rely on traditional manual control procedures. The accuracy and reliability of EFTS application processing is becoming more dependent on the incorporation of automated application controls (discussed in the next section). The purpose of the EFTS audit tools and techniques is to evaluate those controls, verify processing accuracy and continued compliance with processing procedures. Some of the key audit tools and techniques that apply to the EFTS environment and verify the correctness of processing logic and controls include the following: Base Case System Evaluation-Execute application programs against test transaction data, entered through a "test mode" EFTS terminal, and compare results against pre-determined test results. Parallel operations-execute new or revised application programs and existing application programs and compare results. Integrated Test Facility (ITF)-Enter test transaction data through live terminals commingled with live transaction data. Parallel Simulation-Live transactions are copied and processed against auditor programs that simulate processing logic. The simulation results are then compared to the live results. Transaction Selection-Systematically screening and selecting transaction samples entered through EFTS terminals for subsequent manual verification. Embedded Audit Data Collection (Sometimes known as System Control Audit Review File: SCARF)-Audit subroutines are embedded in the application programs to screen and select internal generated messages between EFTS logic modules that result from the original terminal transaction. Terminal Audit Software-Direct access to inspect live files during actual operation of the EFTS. The auditor will want to examine terminal polling lists, routing tables, merchant codes, floor limits, and default authorization tables. Snapshot and Trace-Secure documentary evidence of logic paths, control conditions, and processing sequence of a specific transaction. This is done by continuously recording transaction status for some selected transaction as it passes through the system. Job Accounting Data Analysis-Select, extract, and display job accounting data to monitor access to sensitive data files and on-line libraries. Code Comparison-Use of an off-line program to compare two versions of an application program to identify differences in coding. EFTS APPLICATION SYSTEM CONTROLS The purpose of the EFTS Application System Controls are to assure the accuracy and completeness of the processing results, the security of the environment in which the EFTS transaction is effected, and the effectiveness of the overall computer design and operations.

3 Systems Auditability and Control 187 The controls described in the following sections are some of those likely to be beneficial in the remote terminal EFTS environment. They are grouped according to five phases: Transaction Origination and Data Entry Data Communications Computer Processing Data Storage and Retrieval Output Processing TRANSACTION ORIGINATION AND DATA ENTRY CONTROLS Special-Purpose Forms-At merchant operated or teller operated terminal locations. Proper form design encourages completeness and accuracy of data. In the cardholder operated terminal environment, Video Display Units (VDU) may be used for pre-formatted and! or interactive input. Transaction Identification Cross-Reference and Source Document Numbers-This control calls for sequentially assigned source document numbers (or sequential screen numbers) which are transmitted to the EFT processor as part of the transaction identification. Sequence Log-An internal log of which sequence numbers have been assigned to which merchant/teller locations or cardholder operated terminal location. Signatures-In the EFTS environment this control consists of appending a series of endorsements to each transaction as an audit trail of each node that handles it. It also serves as a "return destination" for undeliverable messages. The first endorsement is the terminal I.D. User Identification-A unique identification by class of user (cardholder, merchant, teller, bank supervisor) used to restrict the transaction to be processed as well as files that may be accessed. Batch Serial Numbers-Batches are identified by serial number to provide accountability of data, and to assist in the isolation of errors when an EFTS terminal cannot successfully reconcile at end of day (or other cut-off time). Limit the Number of Transactions in a Batch-This is done to simplify the reconciliation process. Turn-Around Documents-The source documents contain pre-recorded data in machine readable format. This will simplify processing in the event the on-line system is down and paper documents are used as back-up. Retention Dates on All Transaction Logs-This is based on legal requirements and management policy. Source Documents Maintained at Origin-In the EFTS interchange environment this means two things: (1) The paper documents (credit card vouchers, debit card vouchers, deposit slips, withdrawal slips) are maintained as closely as possible to the acquiring bank, to prevent unnecessary risk of loss through transportation, and (2) the electronic version of the EFTS transaction is also maintained at the acquiring facility until balanced at the end of the day. Subsequent settlement between banks, and actual movement of value data for posting can occur in batch mode at lower cost and higher reliability. Error Logging-Maintained by the acquiring facility to record and monitor the type of errors occurring at the terminal. Suspicious patterns of such errors could imply an attempt by an outsider to breech system security. Verification of Re-Entered Data-The data fields on resubmitted transactions are subjected to the same verification procedures as the original transaction. Security of EFTS Terminals-EFTS data entry terminals should be physically secure by placement in a lockable room, putting a keylock on the terminal itself, or by placing a lockable cover over the terminal device when not in use.. Terminal Logs-Journals in the terminals to record all transactions. Terminal Control Logs-Journals in the terminal controllers to identify imposter terminals on the network (i.e. controller total of transactions should equal the sum of the legal terminals.) Built-In Terminal and Terminal Controller I.D.'s These devices are provided with electronic identification that can be queried by the computer; used to validate proper terminal authorization. Editing and Validating Routines-These may be partially performed in the terminal itself, given anticipated hardware capabilities. Passwords-Used to verify that the input is being received from an authorized source. Likely to be the Personal Identification Number (PIN), although other techniques are being actively explored. Unauthorized Access Attempts-An immediate report is produced of unauthorized attempts to access the system. After a threshold of repeated attempts the system shuts down the terminal in question and allows access from that terminal only after intervention by security personnel. DATA COMMUNICATION CONTROLS Secure Phone Equipment Rooms-Locks and alarms are used to control access. Network Configuration Polling Table-No open addresses for unauthorized terminals to gain access. Communication System Control Log-To detect any unauthorized changes to the network done through network supervisor terminals. Communication Line Routing-Data communication lines are not put through public switchboards (PBX). Local Loop Security-Between the terminal, or termi-

4 188 National Computer Conference, 1978 nal controller, or computer, and the telephone company branch office. Encryption Techniques-Such as the National Bureau of Standards (NBS) Algorithm. For an excellent discussion of encryption techniques, see Kaufman and Auerbach. 1 Forward Error Correction (FEC) and Automatic Request for Retransmission (ARQ)-Common types of link control; to control transmission errors on each segment of a transaction path through the EFTS network to the cardholder data base and back to the terminal. Message Sequence Number-Each transaction at an EFTS terminal may generate several messages (terminal-to-acquiring CPU, acquiring CPU-to-switch, switchto-cardholder CPU, etc.). This provides a traceable log to match inquiry with response, detect lost messages, or detect imposter messages. COMPUTER PROCESSING CONTROLS Monitoring of Internal-Generated Messages-Internal generated messages (such as an authorization request to the issuer on an interchange withdrawal transaction) should be uniquely identified and cross referenced to the external transaction that spawned them. Control Totals-Reasonableness checks and internal control totals between program modules. Default Option-Each level in the system hierarchy may need to make decisions in default when the rest of the system is down, or whe~ it is uneconomical to do so (e.g., the merchant bank may authorize a $3.00 transaction against a negative file instead of requesting authorization from the issuer). Dual Fields-All entries should be carried as a credit against one account and a corresponding debit against another, throughout the life of the transaction. Arithmetic Accuracy-Techniques such as double arithmetic and arithmetic overflow checks are placed in critical points in the application. Destructive Update-Debit and credit type entries are used to correct error conditions, not delete or erase commands. DATA STORAGE AND RETRIEVAL CONTROLS File Classification-Each file is classified by security level, and access is restricted by level. Data Base Control Table-No data base access is allowed unless it comes from an authorized program module. Program Linkage Control Table-These tables control the authorized module linkage between programs. Dormant Files/Accounts-The system reports on dormant files/accounts that suddenly have activity on them. Many attempts at EFTS fraud try to make use of dormant accounts. Excessive Activity-The system reports on records and data fields that have excess activity over a certain threshold. It could mean that a lost or stolen card is being used. OUTPUT PROCESSING CONTROLS Reconciliation-The response to an EFTS request is matched up and reconciled with the original request before completing the transaction. Transaction Log-The central transaction log is periodically matched against the journal tape in the EFTS terminal. These totals are also verified against individual application control totals. Output Activity Review-Real-time statistics such as the number of terminals on-line, transaction quantities, and circuit traffic are reviewed by the appropriate management. System generated subjective judgments, such as default authorization, are reviewed by user departments. Device Verification-EFTS devices whose action such as imprinting a card or dispensing cash is controlled by the application programs will send a status report back to the host computer to verify completion of the requested mechanical operation. CONCLUSION Any remote terminal-based interactive system will face a variety of threats. EFTS, in particular, because of the electronic movement of funds and value, will be particularly vulnerable. Fortunately, a number of system audit techniques and application controls are available to the system designer; and more are under development. Depending on the particular system design, careful implementation of these audit techniques and application controls is likely to diminish the vulnerability to those threats. REFERENCES 1. Kaufman, D. and K. Auerbach, "A Secure National System for Electronic Funds Transfer," Proceedings 1976 Nee, pp Mazzetti, Joseph P., "Design Considerations for Electronic Funds Transfer Switch System Development," Proceedings 1976 Nee, pp Backman, Frank, "Are Computers Ready for the Checkless Society?," Proceedings 1976 Nee, pp "The Analysis of Certain Threats to EFT System Sanctity," Kranzley & Co., Cherry Hill, N.J.-A study done for the Electronic Industries Foundation; January lcfn.

5 Systems Auditability and Control "Systems Auditability and Control Study," SRI International, January (Available from the Institute ofinternal Auditors, Orlando, Florida) 6. "Introduction to EFT Security," prepared by the Division of Management Systems and Economic Analysis, FDIC, Washington, D.C., August Parker, Donn, Crime By Computer, Charles Scribner's Sons, New York, Martin, James, Security, Accuracy and Privacy in Computer Systems, Prentice-Hall, Englewood Cliffs, New Jersey, Hoffman, Lance J. Security and Privacy in Computer Systems, Melville Publishing Company, Los Angeles, "A Guide to EDP and EFTS Security Based on Occupations," A report prepared for the FDIC by SRI International, Menlo Park, California, 1977.

6