SWIFT-Related Heists: Who’s to Blame?

A Reuters report claiming executives at SWIFT for years neglected the security of its bank-to-bank messaging system has stirred debate among security and anti-fraud experts

In the wake of the $81 million SWIFT-related cyberheist waged against the central bank of Bangladesh, and several other similar incidents, many experts acknowledge that much more needs to be done to ensure that interbank transactions routed through SWIFT are properly authenticated, monitored and secured. But while some experts call for SWIFT to take a leadership role on security, others argue that banks, not SWIFT, should take the lead.

William Murray, an independent financial fraud consultant, argues that SWIFT, a bank-owned cooperative based in Brussels formally known as the Society for Worldwide Interbank Financial Telecommunication, is nothing more than a “messenger” whose obligation is to offer a service that moves money from one bank to the next. Thus, he contends, it’s not SWIFT’s responsibility to ensure that transactions routed on its network are authenticated; that’s the originating bank’s job.

The Bangladesh Bank heist and other SWIFT-related thefts are “a banking problem, not a messenger problem,” he asserts. “Banks write both the policy and the bank-to-bank agreements. The service providers [like SWIFT] do what they are told. … It is so convenient to blame the messenger. What we are really seeing is management, perhaps governance, failures in a small number of banks.”

Nothing that SWIFT did “or failed to do” would have prevented the Bangladesh heist, Murray contends. “SWIFT might add additional security services, e.g., transaction filters, confirmations, etc. But these will be effective only to the extent that SWIFT’s [bank] customers, which actually own the network, choose to use them.”

But Steve Durbin, managing director of the Information Security Forum, argues that SWIFT could be doing more when it comes to security. He argues that while it may have been “reasonable” for SWIFT to assume that the banks using its network had appropriate controls in place, SWIFT should have vetted those controls before allowing new institutions to sign on. “The answer is increased collaboration, information sharing and heightened controls, with an emphasis on verifying that what should be in place actually is in place,” he says.

New Requirements Needed?
Murray acknowledges that banks using the SWIFT network should change their contractural agreements to require recipient banks to verify transactions before those transactions are approved and transmitted.

And financial fraud expert Avivah Litan, an analyst at the consultancy Gartner, says it’s time for SWIFT to do some self-assessment. “SWIFT doesn’t need to shore up its own security – it needs to figure out what its role is,” she says. “Is it going to still be a network for transmitting messages securely, even when those messages are fraudulent, or is it going to take responsibility for making sure those messages are not fraudulent and not tampered with?”

Litan argues, however, that SWIFT doesn’t have the authority to enforce security measures. “That’s the regulators’ jobs, and one day the regulators may eventually wake up to the need for them to do just that,” she says.

Analysis of SWIFT’s Security
The Reuters report, based on interviews with more than a dozen senior-level SWIFT managers and board members, details how SWIFT apparently failed to proactively eliminate known vulnerabilities related to how its smaller banking customers use SWIFT messaging terminals. Furthermore, according to the report, in 17 years of annual reports and strategic plans, SWIFT never mentioned security once, except for in its 2015 annual report, which was issued after the Bangladesh Bank heist. In that 2015 report, SWIFT said it would be helping “our community to strengthen their own infrastructure,” the report notes.

Between 1994 and 2016, the number of countries and territories covered by SWIFT jumped from 126 to 212, Reuters reports. Most of that increase came from the addition of smaller banking institutions to the SWIFT network in developing countries, where security practices and regulatory oversight are deemed to be far less stringent than they are in economically developed countries.

Former SWIFT board member Arthur Cousins told Reuters that SWIFT believed banking regulators were responsible for ensuring and auditing security procedures at smaller banks. In contrast, Leonard Schrank, who served as CEO of SWIFT from 1992-2007, argued that SWIFT should have done more to ensure transactions running across its network were legitimate.

“The board took their eye off the ball,” Schrank told Reuters. “They were focusing on other things, and not about the fundamental, sacred role of SWIFT, which is the security and reliability of the system.”

Could SWIFT Have Done More?
SWIFT is not legally or contractually obligated to ensure that transactions routed across its network are legitimate, several security experts tell Information Security Media Group. That’s the responsibility of the banks that originate the transactions.

Nevertheless, some experts suggest SWIFT could have done more to ensure that banking institutions using its network were taking specific steps to properly protect and verify payments. Others argue, however, that SWIFT did not drop the ball by depending on its bank members to ensure the authenticity and security of payments routed through the SWIFT network.

Cybersecurity attorney Chris Pierson, general counsel and CISO at invoicing and payments provider Viewpost, contends SWIFT could do more to vet the security of the banks that sign on to use its network.

“The SWIFT network is only as strong as its weakest link,” he says. “SWIFT has a responsibility to ensure the network is safe and communications trusted, and that proper authentication protocols are put in place. As the network expanded, this responsibility and the governance over security protocols may be an area that receives extra attention during the root-cause analysis. All threats change over time, and unless the controls are constantly improved, weak links will be exploited.”

But Andrew Davies, a fraud-prevention expert at core banking services provider Fiserv, says the banks, not SWIFT, have to invest in more fraud monitoring.

“Financial institutions and corporations of every size can take steps to help protect themselves,” Davies says. “Organizations originating transactions, in particular high-value international transactions, should deploy technology and advanced analytic models that are designed specifically to detect fraudulent activity and anomalies of this type.”

It’s time for banks to make the necessary investments to ensure the security of bank-to-bank transactions, Gartner’s Litan says. “The easiest thing to do from a technology viewpoint is to implement analytics and anomaly detection at the recipient banks so they can see if they are receiving an anomalous transaction for any given payer. They have the most readily available access to the data to do this.”

SWIFT’s Actions
Since news of the Bangladesh heist broke in March, SWIFT has launched a new digital forensics and customer security intelligence team. It also has announced that it is strengthening communication with its member banks to help them better understand how the SWIFT Relationship Management Application can be used to filter messages. Banks can filter messages “to ensure that message traffic is only permitted with trusted parties,” SWIFT says, and revoke communications with any organization in cases of suspected fraud.

Additionally, SWIFT has introduced other security features, including mandatory updates for two-factor authentication as well as stronger default-password management and enhanced integrity-checking features.

Those are all good steps, Litan says, because attacks against SWIFT transactions are likely to continue. “But eventually, SWIFT will have to enforce security measures at its member banks, i.e. on the originator side,” she adds.

Source:http://www.govinfosecurity.com/analysis-swift-related-heists-whos-to-blame-a-9352

. . . . . . . .

Print Friendly

Leave a Reply