Seeking a SWIFT Malware Attack AntidoteHere's Why Manual Oversight Is No Wire Transfer Security Panacea
The theft of $81 million from the central bank of Bangladesh's account at the U.S. Federal Reserve in New York is notable because attackers - not for the first time - appear to have employed malware to issue bogus money-moving messages via the SWIFT messaging platform (see SWIFT Confirms Repeat Hack Attacks).
The Society for Worldwide Interbank Financial Telecommunication - a Belgium-based cooperative of 3,000 organizations, founded in 1973 - maintains the SWIFT messaging platform, which it says handles the majority of international interbank messages. It's also confirmed this isn't the first attempted malware attack it's seen, although it has declined to comment on the identities of previous targets.
"Whoever concocted the scheme was familiar with the workings of wire transfers."
The attacks prompt the obvious question of whether better internal controls, applied to SWIFT messages, might have disrupted the scheme much quicker. Security experts and regulators have long recommended that organizations and banks employ manual intervention to verify all large wire transfers (see Why Are We So Stupid About Security?).
Accordingly, should SWIFT-using banks be using a greater number of manual reviews by bank employees - at both the sending and receiving end of every message - to better vet all large money-transfer requests? Should banks be picking up the phone more frequently and using pre-agreed codes to verify large transactions with their counterparts in initiating institutions?
SWIFT didn't immediately respond to my request for comment about whether it planned to advise banks to institute more checks to verify the authenticity of money-moving messages.
But for a potential answer to the question I'm posing, it's helpful to look at how a different criminal scheme attempted to illegally transfer a total of $69.7 million out of accounts held by United Airlines, brokerage Merrill Lynch and Kentucky distiller Brown-Forman at First National Bank of Chicago into accounts at Citibank and Chase Manhattan. After that, a gang - comprising seven U.S. residents, including two First National employees - allegedly planned to move the money into two Vienna-based bank accounts, according to prosecutors.
"Whoever concocted the scheme was familiar with the workings of wire transfers," an anonymous source told the Chicago Tribune.
Indeed, the insiders allegedly shared First National Bank's confidential wire-transfer codes and money-transfer codes, after which other individuals posing as United, Merrill Lynch and Brown-Forman employees called the bank's "wire room," tricking bank employees into initiating the transfers, the Los Angeles Times reported.
If anything about this story strikes you as dated, that's because it is: The alleged embezzlement occurred in 1988, points out information assurance consultant William Murray, who's an associate professor at the U.S. Naval Postgraduate School. "Twenty-eight years ago, but seems like only yesterday," he says.
Old School: Telex Machines Plus Code Books
Murray has been tracking information security concerns "since 'wire transfers' were done over telex machines using code books," he tells me. (For the uninitiated, telex machines involved switched networks of teleprinters, which worked like telephones except they were used to send and receive text-based messages.)
Such transactions "were hardly routine," Murray tells me. "As recently as 20 years ago, lots of transactions originated with a telephone call from the bank's customer to the bank. The 'interface' to SWIFT was called the 'wire room.' One clerk would take the order from the customer; a second one would call the customer back to authenticate the transaction."
With such a system - bank clerks in a wire room, armed with a SWIFT code book - what could go wrong? In fact, the alleged $70 million embezzlement from First National Bank of Chicago - which is now part of PNC - demonstrates some of the risks the system posed, because it relied on humans being in the loop, and people can be tricked. At the other extreme, meanwhile, the Bangladesh Bank hack demonstrates the danger posed by highly automated systems, for example, when hackers manage to exploit a system that a bank uses for its SWIFT messaging.
Of course, SWIFT transfers aren't fully automated. The Bangladesh Bank hackers attempted to transfer $951 million, some of which was blocked after attackers misspelled the name of the Sri Lankan not-for-profit organization to which they were attempting to transfer the money, prompting one of the routing banks, Deutsche Bank, to helpfully flag transaction for further review by Bangladesh Bank, Reuters reported.
More Security Costs
Obviously, no system is foolproof, and the First National Bank of Chicago case demonstrates how insiders can help abuse any system. But adding more checks and balances to money-moving transactions can increase the chance of spotting related scams. "The most effective, general and flexible control is management direction and supervision," Murray says. But that comes at a cost, and "because it is expensive, we resort to alternatives, for efficiency."
Of course the trend globally is to allow money to be moved more quickly, ideally backed by better authentication, tokenization, dynamic credentialing and encryption (see Fed Reveals Plan for Faster Payments). But in light of SWIFT customers having been targeted now via multiple malware schemes, is it time to at least make massive international wire transfers a little less "efficient" in exchange for better security?