International Banking. Security in MultiCash

Transcription

1 International Banking Security in MultiCash Overview of relevant features Version 1.02 / Dez Omikron Systemhaus GmbH & Co. KG Von-Hünefeld-Str. 55 D Köln Tel.: +49 (0) Fax: +49 (0) omikron@omikron.de

2 CONTENT : 1 BACKGROUND Security aspects of MultiCash Overall Security and External Audits LOCAL SECURITY Access Control and Access Rights Passwords Users / User Groups Functional Profiles Data Profiles Dual Control Approvals Logs and Audit Trail System Log Additional Logs Payment History Confidential Payments EXTERNAL SECURITY NTFS Security SECURE COMMUNICATION WITH MCFT Background MCFT How it works Compression Confidentiality Electronic Signature Initialization Note on the use of TCP/IP communication ADDITIONAL SECURITY ASPECTS FOR MULTICASH@WEB /2006 Omikron Systemhaus GmbH & Co. KG 2

3 1 Background 1.1 Security aspects of MultiCash This document provides an overview of the security mechanisms in MultiCash. The following areas have been identified by users as most security sensitive and are subject of the document : Local Security : Security functions within the MultiCash application External Security : Interaction with the operating system Secure Communication : Security features of the standard communication protocol MCFT Omikron recommends users of an Electronic Banking application to take these aspects into consideration and to implement what is necessary to meet the requirements of the particular installation in line with audit considerations. The document aims to cover all security-sensitive areas of MultiCash. The main enhancements realized in version 3.20 are specially highlighted (see shadowed boxes). 1.2 Overall Security and External Audits In the case of most banks who provide MultiCash to their clients there has been an internal certification of both the products and the related processes made by their internal audit department. As software supplier, we can make the following general statements on this question : The approach to certification in the complex area of Electronic Banking software can be divided into several areas, which must be considered in quite different ways : A. Communication procedures This is certainly the most important area, since here security-relevant data are transferred over public networks. For communication between the bank and its clients, a number of different procedures are being used, which are as a rule defined by the banks in the context of the markets in which they are active. Typically, the "Owner" of the procedure in each case has organized a certification of this procedure. The results of these audits and certifications are not available to us, as software supplier. As background information, here is a list of the most common communication procedures used : 1. MCFT : This procedure is based on the standard protocol "EPFT" (ZVDFUE), built to the specifications of the German banking community. This procedure is widespread within Electronic Banking implementation across Europe, since it is included as standard process within the MultiCash application. Omikron has continued to develop this procedure over the years, and in the course of this process taken over the "Ownership". Therefore we as Omikron commissioned an external security audit from the company "debis IT Security Services". A description of the MCFT protocol is included under Chapter 4 below ; a summary of the findings of the debis audit can be provided on request. 12/2006 Omikron Systemhaus GmbH & Co. KG 3

4 2. BCS-FTAM : Currently, this is the valid standard communication procedure of the German banks for corporate business. According to our information, an audit was commissioned by the German Central Credit Committee, when the procedure was first implemented. If this is relevant for you, please request your bank to provide information on this audit. 3. BCS-FTP : This procedure is the further development of the BCS standard on the basis of the FTP transport protocol. It was defined by the German private banks, who can provide further details on request. 4. HBCI : This is the currently valid standard communication procedure of German bank for private clients and small businesses. According to our information, an audit was commissioned by the German Central Credit Committee, when the procedure was first implemented. If this is relevant for you, please request your bank to provide information on this audit. B. Application Following the development of the software and our internal quality control, each new program version is delivered to the individual banks and the organizations defined for the task of acceptance by the Bank Associations. These parties then subject the software to an extensive acceptance process. Only when all checks have been made in the areas of User-friendliness Software quality System security Correct processing is a release approved for delivery to bank clients. In Germany, the following organizations are responsible in this area : 1. For private banks : Bank-Verlag GmbH, Köln 2. For cooperative banks : BIK Betriebswirtschaftliches Institut der Kreditgenossenschaften, Frankfurt C. Enbedding with the end-user It is not possible to certify an application generally in this area, since the security requirements depend primarily on how the application is embedded in the environment of that user, and what specific requirements that user has. 12/2006 Omikron Systemhaus GmbH & Co. KG 4

5 2 Local Security 2.1 Access Control and Access Rights Passwords Logon to the system is by means of user-id and password. After first log-on, the user is prompted to change his password. After three false attempts this user is blocked and has no further access to the application until released by an authorized administrator. The passwords are always stored in encrypted form, as follows : The User Login password is stored in the user database, encrypted with DES The Administration password is encrypted with DES in several parameter files In addition, it is possible to set : Minimum length of password Validity period, after which password must be changed In addition, a password history can also be maintained, and a period set, during which passwords may not be re-used. For each individual user, it is possible to define time windows within which access to the application is permitted / denied. In the same way, usage can be restricted to defined days. Version 3.2 : Alternative Logon-Procedures a) Use of Windows passwords As an alternative to the logon using User-ID and password, the Windows User-ID can be stored in the MultiCash user administration. At logon, this User-ID will be reconciled with that one of the current Windows user and, if applicable, an automatic logon will be executed with the corresponding MultiCash User-ID. The entry of ID and password is then not necessary, nor is the regular prompt to change the password within MultiCash. b) Logon with RSA Signature If an increased security is required instead of the simplified logon described above, the Logon with ES can be activated. In this case, the logon is made by an Electronic Signature, for which the ES medium must be inserted. This same signature is used for authorization of transactions to the bank(s). Version 3.2 : Additional password rules (optional) A. Additional password options in the system parameters (the options can be combined): 1. Inactive users block after x days Intended to reduce the risk that user accounts which have not been used for a longer period of time are used for attacks. 2. Minimum number of letters 3. Minimum number of figures 4. Minimum number of special characters 5. Max. number of characters in ascending sequence 12/2006 Omikron Systemhaus GmbH & Co. KG 5

6 6. Password change only once per day If this option is activated, a password change can be executed only once per day. This should prevented a user immediately returning to his old password after the enforced password change. 7. Enforce password change So far, it has been possible to cancel of the prompt for password change after a password has expired, in order that the change cycles can be easier synchronized with other applications. If this new option is activated, the user will be forced to change his password when his existing one has expired. 8. Not more than 2 same characters in sequence 9. Check negative list (stored in INI file) If this parameter is activated, new passwords are checked against the negative list stored in a defined control file and are rejected if they match. 10. Display last access for logon As a control against program abuse, the display of the time of the last access can be activated using this option. 11. For ES logon with hardware ES, no password prompts any longer If this parameter is activated, no signature password will be prompted when signing as long as the logon to the chipcard is still valid (i. e. the card has not been removed from the reader since logon). B. In addition, the following fields are added to the user record: 1. Last access time 2. Use Windows users This allows the time of the last access to be controlled by the system administrator for each user. C. The following additional functionalities have been implemented: 1. For password change: Check password rules according to A. 2. For logon: Display date and time of the last access (if A.10 is activated) 3. For logon: if applicable, prompt Windows users and when they agree, logon without password prompt (if the corresponding option is set in the user record) 4. For logon: if applicable ES logon (if the corresponding option is set in the user record) 5. In the first automat run of the day, check the last logon time of all users and block users if period is exceeded according to A In the Users dialog: After manual change of the fields Password or Blocked, prompt for password change at the next logon of the relevant user. 12/2006 Omikron Systemhaus GmbH & Co. KG 6

7 2.1.2 Users / User Groups Users may be assigned to User Groups which are defined in advance by authorized adminstrators. For users and/or user groups, access rights can be defined as follows : Functional Profiles Access can be permitted / denied for users and/or user groups down to the level of individual functions. This allows a strict segregation of organisational functions between users, in line with internal audit requirements Data Profiles The use of data profiles ensures that any user has access only to data for which he is authorized. In addition, it is possible to define whether access to certain data is available to a defined user as read-only Dual Control Access to sensitive administration functions, in particular additions and changes to users and access rights, is subject to the password authorization by an administrator, or optionally two administrators (dual control). 2.2 Approvals In most implementations, one or more payment modules are included within an installation of MultiCash. All payment modules within the product range offer a matching approvals mechanism, which allows payment orders to be protected against unauthorized changes, and to ensure that only complete and pre-authorized payments are sent to the banks. The approvals mechanism includes : Single approval, applicable to a single payment order Multiple approval, allowing several orders for a pre-defined account to be viewed and selected / excluded for approval In addition, it is possible to define different approvals levels by order type, and to set an amount (in base currency) from which a second approval is mandatory. 2.3 Logs and Audit Trail System Log A system log can be activated : this log records all menu options which are called during sessions with the application, including time and name of the user 12/2006 Omikron Systemhaus GmbH & Co. KG 7

8 2.3.2 Additional Logs Further information which may be required in specific cases is included in additional logs, including a log for capture of all communications sessions with results. Changes in version 3.20 Log entries have been stored so far separately according to the type in different text files. The relevant entries for > Error log > Communications > System log > MT940 processing log > Plan data reconciliation log are now combined to be stored in a central file. The display is made in a central overview, in which the data can be easily selected, printed or output to PDF Payment History A full history of all orders and payment files is kept, including full details of payment files including Status Time of all activities made (e.g. creation of file, signatures), with names of users involved Answer code from communication and timestamp from the bank This allows tracking of individual files/orders at a later date. 2.4 Confidential Payments New feature in version 3.20 MultiCash is increasingly used as central solution within the corporate network and is used by all divisions of the company. This means that payment orders originated in different parts of the company, with varying responsibilities are stored in one place. Often, these orders also differ in terms of confidentiality (e. g. credit transfers to suppliers, wages and salaries, customer direct debits). Given this situation, a concept was developed which allows access to confidential payments throughout the entire system - only to persons explicitly authorized for this. In the realization, the following detailed requirements were taken into consideration: 1. The access protection is effective within all payment modules (on the basis of individual) transactions and in the File Manager 2. All payment formats used in MultiCash are supported, even if no unique ID for confidential payments is included in the files or defined in the format itself 3. The rules are defined centrally in the user administration. 12/2006 Omikron Systemhaus GmbH & Co. KG 8

9 3 External Security 3.1 NTFS Security MultiCash can be operated together with NTFS-Security. In this mode, the access to resources (directories etc.) is not permitted to the user who is logged on, but to a system user for the application MultiCash, who receives his own account at operating system level for this purpose. Note : this is implemented from version MCC 3.01 for WinNT / Windows /2006 Omikron Systemhaus GmbH & Co. KG 9

10 4 Secure Communication with MCFT 4.1 Background The MultiCash application supports a number of different communication options, based on standards of different countries and banks. In the following we refer only to the secure communication protocol MCFT, which is provided by default in the application and is the most widely used option internationally. MCFT is a dialog-oriented protocol for the transfer of data. This includes the transfer of files from a corporate to the banks (e.g. payment files) as well as the collection of data from the banks (e.g. balance and transaction data). With MCFT, communication is possible via the communication protocols TCP/IP, X.25, ISDN and Modem-Modem. This communication protocol is supported by banks in over 20 European countries and has been audited and approved by various international auditors, with a particular focus on the use of MCFT over the internet. 4.2 MCFT How it works All data transferred between Bank and Customer are fully encrypted. A key component of the encryption is the exchange of Public Keys, using the algorithm of Diffie / Hellmann, after each successful transmission, so that each tranmsmission is secured with a new key. This guarantees that this information is not to be used for decrypting a future message, even in the theoretical case that a used session-key becomes known. Since an additional Timestamp is generated for the sending and receipt of the message, it is also impossible to use a cumbersome decryption procedure to manipulate the message. On the Bank side, an automated process controls Customer access. Each customer is set up with a set of permissions for bank services, as identified by validated session types. Before the original file (e.g. a payments file) is transferred, a start block is sent, which includes.a series of significant details, i.e. a customer ID, user ID, accounts to be debited, electronic signatures and check sums over the entire file. During communication (online, during the transmission of start blocks), the following checks are then made : Authorization of the user (validation against immediately previous communication session) Authorization for a specified bank service (e.g. international payments, documentary credits etc.), defined by session type Authorization for access to the specified account Provision of sufficient signatures Limit checks (limits set up for this Electronic Delivery channel) If one of these checks fails during transmission of the start blocks, the transmission is immediately aborted by the bank server. The customer receives a clear message in the form of an answer code, which is held in a log file on both customer and bank side. This check is made on the Communication Level. This ensures that customers of the bank can in no case access directly the maintenance functions, database server or file server, even where this is installed within a Local Area Network (LAN). 12/2006 Omikron Systemhaus GmbH & Co. KG 10

11 The communications server can therefore be viewed as a Blocking Firewall within the Back Office environment. As a result, any abuse or error can be detected early, in which case the communication process is aborted immediately. The file is then rejected. A trailer, or end block is always transmitted at the end of the dialog, whether it is successful or has been aborted. Response codes in the trailer allow the result of the communications session to be accurately identified. If the Electronic Signature is not correct, the communication session will be aborted before transmission of the original file. If the electronic signature is accepted, the file will be transmitted. The bank system then needs only to calculate the fingerprint and match this against the one received in the start block, which has already been verified. If the electronic signature is correct, the result of the various checks are transmitted at the end of the communication; these are then displayed on the customer system, and logged accordingly in an audit trail. The general flow of customer bank communication with MCFT is outlined in graphic form below : Customer Bank MCDFUE dialog Original file CHK2 CHK6 DAD Start block Answer block Data Checks: Session type User Account ES EU file Original file Private Key A Private Key B RSA EUZ RSA Final mess. Acknowl. Check CHK2 CHK6 ES file EUZ = ES Intermediate File CHK2 = Checksum 2 CHK6 = Checksum 6 RSA = Rivest, Shamir, Adleman encryption method 4.3 Compression Data compression is achieved on the basis of the internationally accepted and highly efficient algorithm which is integrated in PKZIP software for data compression. 4.4 Confidentiality The data are protected against unauthorized viewing during transmission by the use of Triple-DES encryption. A key exchange according to Diffie-Hellman is made : the new keys are calculated on the customer and the bank side after each successful communication, but are never sent across the line themselves. 12/2006 Omikron Systemhaus GmbH & Co. KG 11

12 4.5 Electronic Signature The MCFT protocol supports optionally the use of Electronic Signature (also known as digital signature). The signatures are sent automatically in a single session with the instruction file. A check is made on the access rights of the party sending, the validity of the Electronic Signature are made in one step during the communication dialog, so that both security and user-friendliness are guaranteed. Key features of the Electronic Signature as used within MCFT are : Use of RIPEMD-160 for building the hash Use of RSA 1024bit for generating the Electronic Signature The keys can be stored on disk or ChipCard. In case of diskette, the Private-Key is stored in encrypted form (Triple-DES more details, see below). In case of ChipCard, special secure storage facility of processor chipcards is used. The private details for Electronic Signature S are currently encrypted using Triple- DES 192 Bit CBC. Using PKCS#5, a 24 Byte key and an 8 Byte initialization vector are generated from the user's password. In the PKCS#5 key generation, two random values are included which are stored in the public part of the file. The first of these is an IterationCount, which outlines how often the generation function is executed internally, and the second of these is a so-called Salt, which represents a starting value for generating the keys. From these three components (password, salt and IterationCount) the PKCS#5 algorithm generates the required keys. 4.6 Initialization The customer sends the Public Key to the server at his bank(s). In parallel he prints an Initialization letter (or INI letter), which is sent by mail (or fax) to the bank. The bank checks the personal signature on the INI letter against their documents and checks that the signature in the letter matches that sent electronically. The user s Public Key is then released by the bank. 4.7 Note on the use of TCP/IP communication Independent of the application MultiCash, it is important to ensure sufficient protection against the dangers within the use of the TCP/IP protocol over the internet by the appropriate measures in the infrastructure (firewalls etc.) This always applies when PCs within a company are connected to the internet. At the same time, we stress that within the protocol MCFT, the security mechanisms are implemented up to the application layer. For this reason the transport of data between corporate and bank is secured. 12/2006 Omikron Systemhaus GmbH & Co. KG 12

13 5 Additional Security aspects for is the optional add-on for the MultiCash customer application, providing a browser interface for (some or all) individual users of the application. When MultiCash@Web is used beyond the company Intranet, SSL-encryption can and should be used for the communication between the browser clients and the MultiCash installation. With MultiCash@Web, the client has no access rights to the resources (directories etc.) of the MultiCash Server. In any case, the access to resources can be controlled using NTFS security on the MultiCash server. When using MultiCash@Web, there is no need for active components (e.g. Java applets.) to be installed. It is only necessary to install a plug-in for Electronic signature, if this function is being used. This means that the browser settings for the user can remain at a very high level of security. 12/2006 Omikron Systemhaus GmbH & Co. KG 13