Infosec policy

The Security of Electronic Payments Systems

Version 1.2

15 June 1999

Introduction

This paper is intended to give guidance to government agencies on the security aspects of acquiring electronic merchant and payment provider services and to assist them with the choice between in-housed and outsourced operations.

Summary of recommendations

Small Payments

1. These recommendations cover payments by clients buying low priced documents, information, etc, and clients paying accounts such as rates, licence fees, etc.
2. To minimise liability an agency should outsource both merchant and payment services. Providing there is an adequate contract and a reliable method of updating the agency’s information on the merchant server, essentially all liability will pass to the merchant service and payment providers who will manage the risks and who can insure against any losses.
3. It is important to note that the process of arriving at an adequate contract to achieve this end is no trivial task. Further, an agency should not assume that such a contract makes it immune from liability for every loss. It may still be liable if it fails to manage the contract in a diligent manner or if the underlying structure of the payment scheme is flawed.
4. A further point worth noting is that, even when an agency succeeds in passing liability to an external provider, it may still suffer serious embarrassment as the only political target for those suffering from a failure in a payments scheme.

• An agency which decides to retain the merchant server in-house but outsource payment services should:
1. avoid receiving client details unless encrypted by arrangement between the client and the payment provider (eg. by use of the SET protocol);
2. ensure (probably by seeking AISEP certification) that advice details passed by the payment provider cannot be repudiated; and
3. install strong access control including firewalling and incident detection measures to prevent hacking of its system.

4. [It is assumed that:

5. the payment provider will take the necessary steps to avoid system penetration and insure against the risk of failure; and
6. the agency will strenuously protect client details if it holds them unencrypted, including perhaps using AISEP-certified software/hardware, particularly for the communications between client and agency.]
• An agency which decides to operate both merchant and payment servers will need:
1. a highly reliable, preferably AISEP-certified, payments package and agency-to-financial-institution communications system;
2. strong access control entailing the maximum possible separation (personnel, physical, and logical) between the merchant and payment servers; and
3. strong protection of both merchant and payment servers against internal and external attack.

This solution involves very high security risks. Commonwealth agencies are strongly advised to seek Defence Signals Directorate guidance; other agencies should contact their own security organisations.

Large Payments

7. It is recommended that clients instruct their banks to make the transfer of large payments directly to the agency’s bank and not use Internet-based payments systems.

Background

8. In common with all other electronic information processing systems, payments systems are prone to disruption by people exploiting the systems’ innate vulnerabilities. Those considering employing a payments system must decide whether to accept the consequent risks. They will to need make a risk management decision balancing the business advantages of adoption against the potential losses that security failures might entail.
9. This paper examines, in generic terms, what might be described as a "retail payments systems", ie. those designed to allow a large number of individuals or organisations to pay for goods and/or services from a provider. In a government context the payments might include
1. the cost of documents supplied electronically;
2. rates and charges for utilities; and
3. fees for the registration of businesses.
10. The risks inherent in the various available systems are described so as to assist acquirers in making an informed decision on which system to select to meet their security requirements.

Threats

11. All financial systems attract fraudsters and embezzlers. The problem typically ranges from individuals avoiding small payments or stealing small amounts to organised criminal activities involving large sums. Electronic financial systems connected to public networks extend the opportunities for this type of crime over what is achievable under a paper-based process by allowing access from anywhere in the world often with much scope for anonymity.
12. An additional hazard associated with electronic systems is the propensity for some to regard them as an intellectual challenge. These "hackers" (who may be employees of the system owner or outsiders) are frequently very highly skilled. Also, because their motivation is not financial gain, hackers may devote far more effort to "breaking" the system than is commensurate with the profit that could be brought by success. In addition many seek recognition for their successes by publishing on the Internet the exploitation methods they have developed. Individuals or more organised criminal elements may then use these methods to defraud or steal.

A model for a payments system

13. Payments systems have five elements:
1. the government agency or private sector organisation which provides goods or services;
2. the merchant who sells the goods or services on behalf of the agency (but may in some instances be part of the agency);
3. the client who purchases goods or pays for services;
4. the financial institutions which hold the agencies’, merchants’ and the clients’ accounts and make transfers between them; and
5. the payment provider who accepts clients’ payment instructions, arranges transfers with the financial institutions, and notifies the merchant of the success or failure of transfers.
14. In some cases the agency, the merchant, the payment provider, and the financial institutions will be separate organisations. However various other configurations are commonplace:
1. the agency can undertake the merchant function; if it does, it can also take on the payment provider function (outsourcing the merchant function but not that of the payment provider seems unlikely); or
2. the merchant and payment provider can be the same organisation, independent of the agency; or
3. the financial institution can incorporate the payment provider (there do not seem to be examples of financial institutions undertaking the merchant function except for their own services).
15. Communications between the five elements are normally carried by public networks. Between client and merchant or client and the payment provider the network is commonly the Internet but could also be by telephone or fax. Internet access provides the opportunity for hacking attacks; the other two offer no such chance. Further, the desire of the merchant and agency to attract the client to their services will discourage them from imposing any special demands on the client. This, and the Internet’s inherent weaknesses, has the potential for severely limiting the security of these communications.
16. The remaining four elements (agency, merchant, payment provider, and financial institution) may also use the Internet for communications between themselves but the higher volumes of traffic they engender may cause them to adopt one of the carriers’ other offerings. Typically the stability of their relationships will allow these elements to set up permanent secure channels of communication should they choose.

The impact of a successful attack

17. All electronic information processing systems are vulnerable to denial of service attacks where the attacker employs any one of a variety of methods to prevent a client using a service a provider offers. Such attacks can have the effect of closing down a business. However because these attacks are not specific to payments systems and are extensively discussed elsewhere, they are not considered further in this paper.
18. The four specific attacks which could have a major impact on payments systems are listed below.
1. Attack Type 1 - development of a method of obtaining the goods or services without making the appropriate payment.
2. Attack Type 2 - compromise of clients’ financial details (credit card numbers, etc) which may result in
1. the unauthorised transfer of funds and /or
2. political embarrassment by their publication.
19. Note that the harm resulting from compromise will vary significantly with the nature of the details collected. Credit card numbers without the corresponding PINs have limited scope for misuse. However card numbers or direct debit/credit instructions with the PINs could result in major losses to clients.
1. Attack Type 3 – illicit modification of the electronic goods offered by the merchant or of the descriptions of the other goods or services on the merchant server; and
2. Attack Type 4 - other methods permitting the unauthorised transfer of funds.
20. Regardless of how a payments system is constructed these attacks are always more or less practical although some techniques can virtually eliminate the risk of one or another. Often more important to an agency is where legal and financial liability for a successful attack would fall.
21. Well-constructed systems in which the client is not connected to the merchant or the payment provider through the Internet or similar data network [eg. mail order/telephone order (MOTO) systems] reduce the risk of hacking from outside, perhaps almost to zero. The risk of internal attack remains, however.

Opportunities for type 1 attacks

Case 1: Merchant sells Electronic Goods

22. When a merchant sells electronic goods or services (eg. electronic documents or access facilities) unauthorised access to the merchant server will allow the taking of the goods or services without payment. This situation pertains regardless of whether the agency outsource's the merchant function or performs it in-house. The threat is both from the merchant’s employees and from hackers from outside the merchant’s facility.
23. The major measures which can be used to reduce this risk include:
1. strong access control, both physical and logical, to prevent employees from compromising the system;
2. a firewall to stop hackers from outside;
3. security incident detection software and procedures; and
4. good auditing procedures.

Case 2: Attacker forges Payment Advice

24. This case is generally only significant if the Payment Provider is a different organisation to the merchant. The successful attacker will be able to obtain goods and services without payment.
25. If an attacker can penetrate and compromise the Payment Server s/he can falsely advise the merchant that a payment has been made. Alternatively the attacker can learn to forge the payment advice data which passes from the payment provider to the merchant (sometimes via the client). Ways in which this can be achieved include:
1. generating advice data directly because the data is either not encrypted or the encryption system used is inadequate or poorly implemented; or
2. capturing the encryption keys from either the merchant (for symmetric ciphers) or the payment provider (either symmetric or public key systems).
26. It may seem that successful attacks of this nature are of very little benefit to the attacker. S/he can usually only obtain documents of little intrinsic value (ie. the charge is being made as a cost recovery exercise), or convince an agency that his/her accounts are settled. However if the attacker disseminates the information, for instance by publication on the Internet, many people might use it before a preventative measure was introduced. In such a case the payment provider might amass a very significant loss.
27. Measures for reduction of the risk of Type 2 Attacks include:
1. strong access control, firewalling, incident detection, and auditing to prevent hacking of the payment provider; and
2. a well designed and well implemented method of conveying the payment advice to the merchant: AISEP-certification (see Miscellaneous Note 1 below) is strongly recommended.

Opportunities for type 2 attacks

Case 1: the Merchant collects Client Details

28. If the merchant collects the client’s payment instructions (credit card numbers, etc) the details are necessarily held in the merchant’s computing system, albeit transitorily in some cases. This leaves these details vulnerable to a Type 2 attack by anyone who can gain access to the merchant’s system.
29. It is probable that agencies operating their own merchant servers would be liable for any damages suffered by clients under these circumstances. Liability would presumably fall to the provider if the agency outsourced the function. However the agency could still suffer loss of credibility and users might reject the service.
30. Protective measures would normally include strong internal access control, firewalling, and security incident detection arrangements. Alternatively, and in most cases better, the details can be passed directly to the Payment Provider without passing through the merchant’s system, or protocol such as Secure Electronic Transactions (SET) might be used. In the latter case the details are encrypted when in the merchant’s possession and the merchant does not hold the key.

Case2: the Agency acts as its own Payments Provider

31. An agency acting as its own payment provider will necessarily have unencrypted client details. Particularly stringent access controls will need to be in place to protect them. In addition to the protection given the merchant server, the following may be necessary:
1. firewalling between the merchant server (through which the client details should only pass in encrypted form) and the payments server;
2. strong personnel, physical, and logical control on access to the payment server; and
3. the use of trusted components (see Miscellaneous Note 1 below) in an independently evaluated and certified system [Commonwealth agencies are strongly advised to contact DSD; other agencies their own security authorities].
32. Suggestions that the clients’ credit card numbers should be stored truncated or encrypted are useful but inadequate. An attacker could always intercept them on receipt: they must be complete and unencrypted, if only transitorily.
33. There seems some merit in agencies avoiding this situation. Private providers will undoubtedly insure against liabilities resulting from any failure in their security measures.

Case 3: Interception between Client and Merchant or Payment Provider

34. Some communications protocols, including some claimed to be secure, may permit an attacker to intercept clients’ financial details. This may be due to logical weaknesses and/or poor implementation. A case to point is SSL which does not protect against the "man in the middle" attack (see Miscellaneous Note 4 below) or several other attacks.
35. The interception of credit card details may be of little import although an agency could lose credibility if such a loss were published. However interception and subsequent misuse of direct debit and credit details could result in major losses to clients. It is recommended that agencies consider their responsibilities when acquiring payments systems as many are vulnerable to these attacks.

OPPORTUNITIES FOR TYPE 3 ATTACKS

Case 1: Agency outsource's Merchant Function

36. When the agency outsources to an independent merchant, there is a real opportunity for a third party to impersonate the agency and make illicit updates to the documents and services. Strong authentication can be used to reduce the risk to acceptable proportions. Suitable methodologies include those based on public key technology and single-use password systems (challenge with encrypted response, tokens which generate a new password every few minutes, etc). Fixed passwords and shared information ("mother’s maiden name") systems are easily compromised at the agency, at the merchant, or in transit, and should be avoided.

Case 2: the Merchant Server is compromised

37. If the security of the merchant server is compromised the information it provides for the clients could be illicitly modified. This is a frequent occurrence following successful external hacker attacks. Digitally signed documents are recommended to allow the client to check that whatever s/he receives was published by the proper authority and has remained unchanged since.

OPPORTUNITIES FOR TYPE 4 ATTACKS

Case 1: Hacker generates Unjustified Refunds

38. The potential exists for a hacker (insider or outsider) to generate unjustified refunds if s/he can penetrate either the merchant or the payments system. The risk of this attack seems small as it can only benefit those who have made payments. However there would be much political embarrassment if, for example, a mischievous hacker gave everyone a refund of their rates or motor registration.
39. Strong access control, firewalling, and incident detection provisions will minimise the risk as will detailed auditing processes at all stages of the system.

Case2: the Falsification of Transfer Instructions

40. Theoretically it would be possible for an attacker who penetrated a payments server to redirect client payments into his/her own account. This would be a very sophisticated, one-off, attack because it would entail the attacker being registered as a merchant with one or more banks. Payments can only be directed to registered merchants.
41. The implementation of most payment provider software has not been subjected to independent evaluation against national or international standards such as the IT Security Evaluation Criteria (ITSEC) or the Common Criteria (ISO 15408). Thus it is difficult to make an assessment of its quality. However even the best of it will need very substantial personnel security, physical and logical access control, detailed auditing, and incident detection arrangements to reduce the risk of operation to acceptable proportions.
42. If an agency is operating its own payments provider, use of a specialised hardware device containing the merchant identity or identities would minimise the possibility of an attacker creating and using his/her own merchant account.

MISCELLANEOUS NOTES

1. Standards for the Security of Products and Systems

43. Most computing products carry no more guarantee of quality than the good name of the manufacturer. Security products, however, require special expertise to design, are complex to build, and are very vulnerable to bugs. Thus experience has shown that, except when the impact of a compromise will be minimal, the manufacturer’s guarantee is inadequate for security products unless supported by independent evaluation.
44. Defence Signals Directorate (DSD) has set up an evaluation scheme, the Australasian Information Security Evaluation Programme (AISEP), to test IT security products against international standards. Products which satisfy the standards are certified by DSD, and are (normally) listed on the Evaluated Products List. Full details can be found at DSD’s website, http://www.dsd.gov.au/infosec.
45. Similarly there is much value in ensuring that IT installations meet a recognised standard of security. For Commonwealth Government agencies this is specified by the Protective Security Manual (PSM), ACSI-33, and related publications (see DSD’s website). Other Australian installations could choose to follow the recommendations of Australian Standard AS 4444, obtainable from Standards Australia. A scheme for testing compliance with AS 4444 is under consideration in Standards Australia.

2. Firewalls

46. In all cases merchants should place firewalls between their installations and their clients. They should also place firewalls between themselves and their payment providers (if separate), the financial institutions they use, and, in fact, any other installation to which they are connected unless the installation is under their direct control (or both the merchant and the other installation are under the same control). This is necessary because, regardless of the reliability of the other organisations, their business is different so their security objectives and precautions will be different and, thus, probably not appropriate to the merchant’s needs.
47. As far as possible ecommerce transactions should pass through specially designated ports and should be subjected to checks of format and content before being passed to merchant or payment servers. Ecommerce operations should be conducted in the firewall’s DMZ, not on the merchant’s internal network.
48. Commonwealth Government agencies should note that they are required to use a Defence Signals Directorate (DSD) approved firewall when connecting to any public network [Secretary PM&C letter to CEOs dated 11 July 1997 and the 1999 edition of the Protective Security Manual (PSM)].

3. Encryption for Commonwealth Government

49. In accordance with a Cabinet Decision promulgated by a letter from Secretary PM&C dated 21 September 1998 and the 1999 edition of the PSM, all new acquisitions of encryption products by Commonwealth agencies must be taken from DSD’s approved list. This is interpreted as applying to products which are used for the protection of Commonwealth information. However agencies should probably also consider the legal implications of endorsing unapproved encryption products for use by their clients when there might be the expectation that the products would protect the clients’ information in dealings with the Commonwealth.
50. All encryption hardware and software should be protected against illicit modification. The private keys used in Public Key Technology for authentication, digital signatures, and decryption, and the secret keys for symmetric ciphers need to be protected very carefully against compromise: detailed guidance can be found in DSD’s publication ACSI-57.

4. Secure Socket Layer Encryption

51. Many product manufacturers advertise their use of 56-bit or 128-bit DES encryption and 1024-bit public keys. Agencies should note that the length of keys actually used will often depend on the client’s browser. If, as is commonly the case, it is restricted to 40-bit DES and 512-bit public key, the encryption used will be at that level. Consideration should be given to whether the lower level of security this offers is sufficient for the purpose.
52. As mentioned above SSL also has a number of other vulnerabilities both of design and implementation. This is equally true of a number of other public domain and proprietary protocols. Agencies are advised to use products certified against international criteria and not to rely on claims like "many major firms have examined and accepted the product".
53. Probably the most important vulnerability of SSL in the payments context is the "man in the middle" attack. The attacker sets up a dummy merchant or payments site which pretends to be the one used by the agency (not typically very difficult to do). When the client contacts the site the attacker sets up an SSL session with the client. The attacker also sets up an SSL session with the true merchant or payments site. The client still encrypts his/her details but the attacker decrypts and reads them before re-encrypting them for transmission to the merchant or payments site. Neither client nor merchant/payment provider are aware of the interception.

5. Authentication of Clients

54. Agencies and merchants may sometimes wish to authenticate clients. There may be a difficult trade-off here between adequate authentication and the cost of additional software and, perhaps, hardware for the client.
55. Authentication systems employing passwords, PINs, or shared secrets are essentially weak. However they can be adequate when the risk resulting from impersonation is small. Challenge and Response systems, Public Key Technology, Smartcards, etc, provide much greater security but require the client to install extra software and/or hardware. Once again products certified against international standards are preferable.