Anti-Malware , Fraud , Risk Management
Seeking a SWIFT Malware Attack Antidote Here's Why Manual Oversight Is No Wire Transfer Security Panacea
Telex: How SWIFT messages used to move. (Source: Arnold Reinhold/CC.)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).
See Also: Security Shouldn't be Boxed: The Cloudified Edge & End of an Era for Hardware Box Providers
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.
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.
Cautionary Lesson
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?
Still from an Anonymous video announcing Operation Icarus. (Source: YouTube.)
President Obama with his national security advisers.
Vulnerability management, defined as the cyclical practice of identifying, classifying, remediating and mitigating vulnerabilities, has been a basic element of the security posture in many global organizations. As the technology evolves by use of cloud, social and internet of things in organizations, the vulnerability management function grows more complex and critical.
Attend this session to hear directly from Sameer Shelke, Cofounder and CTO of Aujas, a global information risk management company on:
The threat landscape and how it forces vulnerability management programs to evolve;
How analytics and intelligence can be added to your vulnerability management program;
A case study of one large, multinational organization that has experienced this evolution and growth
Adding "analytics" and "intelligence" aspects to the vulnerability management function help to ensure that it keeps up with the challenging threat and risk landscape. For example:
Analytics: The vulnerability management program produces a large volume of data related to vulnerabilities, assets, trends, mitigation measures, gaps, compensating controls, etc. Converting the raw data to information using organization context and then to insights based on the risk landscape can provide real value for risk management decisions and actions.
As an example, analytical information on the vulnerability root cause, its link to vulnerability trends and assets can help effective mitigation. Similarly, vulnerability remediation analytics can help identify weakness in the process for improvements.
Intelligence: Typically, the vulnerability management process starts with vulnerability identification, which depends on vulnerability scanning. That's the start in the find-and-fix process. A critical miss in the process can be any weakness in the "find" step, either due to tool functionality or zero day vulnerabilities.
Adding vulnerability intelligence to the management process from authoritative sources and mapping them to the organization assets and their specific configurations would remove critical gaps in the find process.
You might also be interested in …
Source: NIST