Foreign Exchange Transactions


Our next case involves a fairly typical example of automating a high-value transaction process for a financial institution, in this case one involving foreign exchange.

Project Overview

This real-life case study involved a merchant bank in one of the larger European Union countries. The bank was involved in a thriving and substantial foreign exchange business with larger commercial organizations.

Typically, such organizations would have requirements for non-Euro currencies in the 1 to 10-million range, and would have between one and six weeks notice of such requirements. They would fax the bank a purchase order when the requirement became apparent, noting the date by which the amount was required. The bank was then trusted to secure the required amount at the optimum exchange rate, subject to the time requirements. When the bank judged the moment to be ripe, it would execute the transaction and notify the customer by fax, noting the interest rate achieved. (Yes, we did use the word fax in those sentences!). The bank took a small percentage commission of each transaction.

The manual, fax-based system worked largely because the service was targeted at very high-value transactions, and was at the time offered to less than a hundred customers. The bank had realized that if it could extend the service to more customers, it would benefit in two ways: first because the service was inherently profitable, and second due to its purchasing power in the foreign exchange markets being enhanced.

Clearly, a system based on a manual exchange of faxes would have to be replaced, because it was already producing a significant error rate under current loads. Consultants were engaged to suggest an electronic replacement.

The solution deployed was based on a client-side Web browser interface accepting and directing input to a corporate intranet application server, which in turn communicated using SOAP to the bank’s systems.

Security Factors Identified

The bank was compelled by its regulatory authority to maintain records for ten of all foreign exchange transactions over 10,000 Euro in value. Under the manual system, this was achieved by simply photocopying the faxes and storing both the copy and the original faxes in separate, secure storage facilities. The bank’s management had significant concerns, largely justified, about the durability and persistence of electronic records. This is mentioned not so much as a security issue, but more an example of the pragmatic, nitty-gritty snags that are frequently encountered when developing high-security systems that handle high-value transactions. Financial institutions care, deeply, about six and seven figure sums of money, and have deeply ingrained traditions and practices when dealing with such sums.

Authentication of client requests was quickly identified as a significant issue, although not perhaps as crucial as would initially be suspected. The accounts to which the foreign funds were eventually transferred, even in the manual system, were communicated to the bank “out of band,” when the organization in question was first established as a customer, and could only be modified by written intervention of the company’s finance director—again, transferred out of band (by motorcycle courier). It was decided at an early stage to maintain this practice, because it eliminated the risk of a compromised client transferring monies to the compromiser’s designated bank account. This meant the most a compromiser could achieve was mischief, rather than actual gain.

Internal threat was identified as a significant risk. The bank’s staff was well paid, but this project, perhaps more than most, raised the possibility of a single, successful fraudulent transaction being a “Rio retirement fund,” where a successful perpetrator could enjoy financial security for life. The staff, of course, potentially had the ability to change the predefined destination account numbers previously discussed.

Mischief at the client’s site, involving attacks from their staff, was also a consideration. While we could envisage no direct possibility of gain from such mischief, there was always the risk of a disgruntled employee entering spurious transactions for some reason.

Direct denial of service attacks were not a major consideration, because the project’s Web Services were never intended to be made public, and those to whom it would be made known would always be known to the bank in advance.

Confidentiality of transactions in transit was also considered desirable, because a company’s foreign exchange transactions are obviously commercially sensitive information.

Security Measures Deployed

No definitive solution presented itself to the archival problem, although agreement was ultimately reached with the regulatory authority that a piecemeal solution of storing electronic records on a variety of media (tape, CD-ROM, high-density floppies) would be acceptable.

Regarding the internal threat, it was concluded that the key risk factor was the point at which customer account details were being modified. It was decided that protection against alteration to such systems was to be provided by smartcard access, with the smartcards being held by some 30 different officers of the bank. When a customer update was required, the system would be notified and would then nominate, at random, four of the smartcard holders, who would need to present their cards before the update could go ahead. Thus, a fraudulent update of customer details would require collusion between four random members of the bank’s staff. This was considered acceptable both by the bank’s management and by its insurers, who were prepared to underwrite fraudulent usage coverage for the bank under this system.

The client authentication issue was resolved by the use of SAML. The client would authenticate as usual to his or her corporate application server. Then, a SAML authentication assertion would be obtained for the user in question and packaged into a SOAP message. This message would then be dispatched to the bank’s systems, using HTTP over mutually authenticated SSL. The bank’s frontline systems would then extract the identity of the purported client from the authentication assertion and examine it to determine who issued the assertion. The assertion was digitally signed using XML Signature, and therefore the issuer was verified by first validating the XML Signature (to ensure that the assertion hadn’t been tampered with) and then ensuring that the signer was trusted. Applications that provide this SAML verification functionality, using XML Signature validation, include Vordel’s VordelSecure product. Following successful processing of the SAML authentication assertion, a SAML authorization decision request is sent to the internal authorization systems. At this point, either an authorization decision assertion is issued and the transaction proceeds or the user authentication presented is inadequate and the transaction is disallowed.

Note that there are two security contexts here: one in which the application server of the bank’s client authenticates itself to the bank via the authenticated SSL, and another in which individual users authenticate themselves via an interplay of the client access control system and the bank’s access control system.




Web Services Security
Web Services Security
ISBN: 0072224711
EAN: 2147483647
Year: 2003
Pages: 105
Authors: Mark ONeill

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net