In Global Banking, Apps and Security Don't Mix
The greatest bank robberies happen from the inside, Manchurian-Candidate style, where a sleeper agent infiltrates an organization and collects intelligence until it’s time to strike. Such was the case in the Bangladesh bank heist.
Back in February, Bangladesh's central bank revealed that it had fallen victim to an $81 million theft. (Actually, the Philippine Daily Inquirer broke the news – the Bangladesh bank would have preferred to keep the information under wraps pending investigation.)
Since then, dozens of banks around the world revealed a series of thefts involving Swift, the global financial messaging system. Just last week, Swift disclosed new cyberattacks involving its system. In each case, bank computers were compromised to enable unauthorized transfer requests.
Observers have been quick to call these incidents Swift hacks, but Swift is a communications network! To blame Swift for the bank heists is like blaming e-mail for your spam messages.
Swift maintains that its network and core messaging services have not been compromised. This is probably true. The compromised banks were running a software package called Alliance Access, which provides an interface to the Swift network. The customer software was the part that was breached.
The Swift Alliance Access user guide describes its interface as follows:
Packages running on Alliance Web Platform Server Embedded are thin-client GUI applications that only require Internet Explorer or Firefox on desktops.
Oh good, the only system requirements are the first- and second-most-exploited web browsers available. Would you like to recommend that your customers run Windows 95 while you’re at it?
Aside from the fact that a central bank’s assets can be conveniently controlled from a web browser, the lightweight nature of the Swift software means that its host machine can easily serve double duty as an e-mail client, porn hub, or World of Warcraft game console. Is it any surprise that malware was found on the compromised bank computers?
From the point of view of a bank customer, Swift looks something like this: 1
The USB stick is a Hardware Security Module – a removable device that stores authentication information for payment messages. Swift messages cannot be created without this device. 2 Sitting at the controls are human users and ... apps!
The wonderful thing about apps is the democratization of software creation. To that end, Swift offers a software development kit, a set of libraries and code samples for any app developer to create programs designed to interact with the Swift network. For those who need extra assistance, Swift even offers training courses that provide step-by-step tutorials on how to write intrusive code. Message standards and validation rules are available online.
The combination of a general-purpose machine and the availability of do-it-yourself Swift apps make it impossible for Swift to guarantee the integrity of its communications network. Even if Swift turns its messaging system into a virtual Fort Knox, the solution is useless when their customers can’t lock the front door.
Researchers have yet to identify whether the fraudulent payment instructions were issued by malware or bad apps or rogue employees themselves; all they know is that a computer controlled by the bank supplied the payment network with valid credentials and instructions. A piece of malware deleted transaction entries on the local computer, preventing immediate detection.
Security experts are quick to point out that banks should have better monitoring and oversight, stricter access management, and multi-factor authentication involving multiple individuals on different machines.
But that’s the opposite of Swift. Swift’s whole reason for existence is to increase transaction efficiency – that’s why they call it Swift! Its business model is to provide turnkey solutions for financial transaction messages. Customers are in charge of their own risk management.
Swift has long been dominated by large Western banks with strong security procedures. When smaller banks in emerging markets began to join the network in the 1990s, Swift operators took big-bank security practices for granted and failed to realize that its new members lacked experience in internal threat management.
And because larger member banks primarily transact with each other, they do not expect to receive potentially fraudulent messages. The Federal Reserve Bank of New York processes hundreds of thousands of Swift payment messages a day; most are automatically executed.
The problem with security solutions is that they tend to create extra work. Financial institutions spend billions on back-office reconciliation expenses. A lot of this reconciliation involves manual fraud detection. We’re in an era where we want to automate things, give robots our jobs, and put it all on the blockchain. This goal is at odds with the fact that global interconnectedness has increased the need for heightened cybersecurity. But when it comes to moving a nation’s wealth around the world, convenience is not a virtue.
This column does not necessarily reflect the opinion of the editorial board or Bloomberg LP and its owners.
The cylinder under the computer is an Oracle database, which stores the transaction logs. The VPN is a secure private connection to the Swift network.
Nothing stops a bank employee from plugging the USB stick into a personal computer running whatever malicious software they like. But Swift assumes they won’t do that.
Apps serve many useful purposes, from automated payments to fraud detection. Unfortunately, every installed app provides a new entry point for malicious attacks. Security experts call the collection of potential vulnerabilities an “attack surface.”
To contact the author of this story:
Elaine Ou at email@example.com
To contact the editor responsible for this story:
Jonathan Landman at firstname.lastname@example.org