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.)

Cybersecurity
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:
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. Sitting at the controls are human users and … apps!

Banking’s Message System
I love apps. I have them all over my phone. Just like Apple, Swift has an App Store with a suite of add-ons designed to automate and enrich the Swift experience.
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.

—Bloomberg
Elaine Ou is a blockchain engineer at Global Financial Access, a financial technology company in San Francisco. Previously she was a lecturer in the electrical and information engineering department at the University of Sydney