Data Fraud in Financial Services
Banking is all about trust. Witness the credit crunch and its impact on customer’s choice of where to place their savings. Before the credit crisis, people’s main trust issue with banks was on the growing issue of identity theft. Identity theft is just one public facet of fraud in banking, it is also just one ramification of data fraud in banks. All banks have to consider data fraud as part of their Basel II operational risk analysis. Other fraud areas in financial services include:
Looking at data fraud, let us examine the data lifecycle in a general context. This applies to all industries, it is just that with banks there is often more at stake if data is lost. There are different nuances in the context of external customers as compared with internal employees.
A consumer uses his home PC to access Internet banking. The data goes through a number of stages throughout its life.
When the user accesses the bank website there are a number of issues: is the website genuine? Is there a malicious virus on the PC or spyware such as a keylogger? The bank is reliant on the user having effective firewall, anti-virus and spyware defences, plus having enough education to avoid email scams which may direct the user to a mock bank website or hand over personal details. The debate will continue to run on where duties and liabilities are in this regard. In the US, there is federal legislation in place on two factor authentication (2FA). That is two things which will authenticate you to the bank, typically something you have (such as a password generator) and something you know, such as a PIN code (or something you are, such as a fingerprint). Increasingly we are seeing more uptake of 2FA in the UK from banks such as Barclays, LloydsTSB, RBS and Nationwide, whereas the FSA has allowed an opt-out that has been taken up by HSBC and Abbey National, for example. Initially this technology was used on higher value banking transactions, such as treasury workstations owned by the bank, and given to the corporate customer, but the technology is becoming more affordable so that mass rollout is more viable. As always with mass rollout the considerations are focussed on usability, affordability, reliability, and ongoing maintenance. Some novel approaches, such as using Java mobile phones as password generators, are beginning to be available, as most users have these so can avoid the initial hardware outlay which either the bank or the user has to absorb. The lack of expense is substituted in this case with higher support costs as not all phones are identical so setup can be troublesome.
In the situation of high value transactions such as significant transfers at a corporate workstation, deniability is an issue. A user may be able to argue about the risks of submitting a trasaction over the Internet if no further authentication is taken. In security circles this is known as non-repudiation. Cryptographic technology is available to allow a transaction to be digitally signed so that the bank can be assured of the identity of the signer and also that the data has not been tampered with, effectively combining a ‘signature’ and a ‘seal’. This technology is legally recognised throughout the EU. While the software to achieve this is comparatively simple, the infrastructure to securely send and then keep the necessary cryptographic keys is more complex and costly to manage. This has kept the use of this technology more at the level of high value transation protection, as while the risks are low, the downside impact is high.
The risk is that an eavesdropper on the Internet can listen in on the data transmitted. In these days of pervasive wireless networks, such as in hotel lobbies, it is relatively simple, with the right software, to listen in to the packets of data a user thinks he is sending to a bank server, unless protective measures are taken. This risk is well understood and banks normally use SSL to protect the confidentiality of session information. SSL is a cryptographic technology that protects the confidentialty of the session, and potentially the identity of the bank website and also optionally the identity of the user. SSL can be used to identify the bank website and thus provide protection against some types of phishing attack where a user is directed to a mock bank website. Users do need to get into the habit of checking their browsers for secure sessions and the server certificate to make sure it is registered to the bank they expect. What is important to understand is that SSL protects the contents of the Internet session between the user’s browser and the edge of the bank’s network (known as the proxy server). Older PCs with older browsers also have less secure versions of SSL, so again it is up to the bank to ensure that they have an Internet session with a browser that will support the more recent versions of SSL. The other factor to consider is whether the network between the bank’s ‘edge’, i.e. the proxy server, and the server that will process the session can be trusted.
There is no such thing as absolute security, it is a matter of building walls. Every wall is potentially surmountable, but the question is how much you value getting to the other side and how hard you will try to mount it. So the right way for a bank to assess data fraud is to consider multiple fraud scenarios looking at the downside risk if the fraud is perpetrated, and then the cost of prevention. It is perfectly proper to not do anything about certain risks so long as you have considered it and review that decision over time. Security technologies that will allow a defence can become more affordable with time, or fraudsters may target your decision to not provide a defence.
In the case of whether to trust your internal networks between bank servers, some banks may decide to secure their internal networks with VPNs, some may decide to use very sophisticated end-to-end cryptographic techniques and others may simply ignore the risk.
Most transactions are processed by bringing to bear multiple applications. Often the applications are old and complex, sometimes poorly documented with few people that truly understand them. These applications are then orchestrated to run a business process. You can see that in this scenario it would be possible for a disgruntled employee with the right application development access to make a malicious modification in a subtle manner. This is very rare but the impact could be dramatic. The banks has to rely on softer human factors, such as watching for abnormal behaviour plus of course rigorous testing, to provide defenses.
Sensitive transactional data and personal data should not be stored unencrypted on disks. It is too open to abuse in the above case of a malicious employee or application. This is an area where there is room for improvement in many banks. Best practice is that when key data is changed that this change is logged with firm knowledge of the person making the change. Suppose that a customer’s address details are changed in order to defraud that individual, can the bank be sure who made that change and when? This is actually harder than it seems. A typical employee in a bank with an old infrastructure may have access to dozens of different systems each with its own password. It is simply not possible to remember so many passwords. Most of us are familiar with this problem – we write them down. Often teams share a password to an applications immediately losing any accountability. The application then must log any changes to data to an audit trail with the user, the change and a time stamp. But can the audit trail be modified by a colluding employee? Often the answer is yes.
In this case there are good defences that can be taken. In a modern application infrastructure there are likely to be far fewer applications demanding access as a user will follow a business process that will compose the data on his behalf from multiple legacy applications. Where many applications are required, single sign-on (SSO) technologies can be used or at the very least a common corporate directory so even if multiple application sign-ons are required, they are the same password, which the user can protect properly. Audit trails can also be made secure using cryptographic techniques that make any tampering evident.
Data of course does not just stay in the bank’s main data centre. It is copied to a disaster recovery site for critical applications and sent to archive. We are all familiar with recent headlines on sensitive personal data ‘lost’ in the post and the embarrassment and reputational risk that entails, not to mention breach of duty of care. The list goes on. Again cryptography comes to the rescue to protect the confidentiality and integrity of data sent offsite. At initial view this seems straightforward, but it is not so simple as, for example, depending on the strength of cryptography used; it may be possible with enough computing resources and a few months to decrypt that data. Techniques are used to periodically re-encrypt the data, but of course this is a process that must be managed. Also the keys used to encrypt must be carefully guarded and not lost to ensure that when the bank needs the data that it will be available. Tape drives have recently become available with integrated hardware cryptographic capability easing the process of securely sending data offsite.
The last point to consider has also hit the public domain recently, with bank personal data being sold on eBay. This originated from a bank server that originally held the data being sold without the disk being wiped clean or destroyed. This was a procedural mistake as most banks will have procedures to actively wipe disks (by writing random data over the disk surface many times), but had cryptography been used to protect sensitive data then its accidental exposure would have been harmless.
We have discussed a broad range of issues pertaining to data fraud. Let us now summarise some of the approaches that can be used against these risks.
Secure wiping of data from redundant disks and servers through improved operational controls.
Meeting standards such as ISO27001/BS7799, SAS 70, FRAG 21, PCI and SOX can be a challenge, but this sort of compliance and control is achievable. Compliance with these guidelines often results in technologies in the above list being implemented. For example, SOX 404 compliance seeks to improve internal controls over the financial reporting process. The best way to do this is to reduce the number of control points by automating as many steps in the financial process as possible. As earlier in this article we see that BPM and SOA-based redesign can be both an enabler of business flexibility as well as a means of enforcing process and data access control. When combined with SSO technologies and identity management, an organisation is on a much better footing for compliance and control.
PCI is the Payment Card Industry requirements for data security for card providers and merchants. In addition to the cryptographic requirements, PCI requires a secure network, cardholder data to be protected and strong access control, together with regular monitoring and testing.
There are many opportunities for data fraud to occur, but the good news is that there are regulations that target many of these fraud situations. Banks need to diligently implement the required technologies and controls. It would be unwise for a bank to stop at just the compliance requirements, and they should periodically review residual risks to further protect the user and the bank, as data fraud risks evolve over time, as well as the technologies to address them.