Swift Attacks Heighten Worries

Swift, long a quiet, behind-the-scenes giant in the world of global payments, has been garnering attention recently after several high-profile cyberattacks on banks using its platform. In one of the biggest bank heists in history, hackers last February stole $81 million from the account of Bangladesh’s central bank at the Federal Reserve Bank of New York.

Most large U.S. banks responded to the news quickly. At $446 billion asset U.S. Bancorp, in Minneapolis, the board received a so-called “threat briefing” and reviewed its security measures related to SWIFT.

“It got everyone’s attention,” says Jason Witty, the company’s chief information security officer. “But we didn’t need to change much, because we already had a very solid process around managing those risks.”

Going forward, U.S. banking regulators have ordered examiners to look more closely at the security of institutions’ links to SWIFT. Directors of institutions on the network should add closer oversight to their growing list of cybersecurity concerns, experts say.

The Society for Worldwide Interbank Financial Telecommunications, or SWIFT, is a Belgium-based messaging platform used by banks and other financial institutions to communicate with each other. When a bank customer wants to transfer funds to a bank account in another country, the two banks use SWIFT to exchange instructions, reports and confirmations.

Most large and midsized banks in the United States are linked to SWIFT; for many community banks, bigger correspondents carry the load. On this one, smaller banks truly do get a pass.

In an interconnected world, SWIFT gets quite a workout. In 2016, some 11,000 financial institutions from 200-plus countries used the platform to process more than 6.5 billion messages-an average of nearly 26 million communications per workday.

That, however, is the extent of it. SWIFT is a messenger, plain and simple-a global postman between users. No funds are actually transmitted over its platform, nor does SWIFT monitor or control the messages sent over it.

SWIFT officials declined to talk on the record, but the organization’s website states that financial institutions using the platform “are individually responsible for the security of their own environments.”

Last February, hackers used malware to bypass fraud controls on the Bangladeshi bank’s system, and then sent fake SWIFT messages to trick the New York Fed into transferring $81 million from the Bangladesh bank’s accounts to accounts in Sri Lanka and the Philippines.

An investigation by Reuters also found that the Fed branch lacked systems capable of catching fraud in real-time, leaving it vulnerable. The hackers’ goal of a $951 million theft was foiled, but only by coincidence: The street address of a bank where some of the illicit funds were being transferred included a name that triggered a warning for sanctions related to Iran.

Since then, other hacking attempts have been revealed, and now everyone is on high alert against other SWIFT-related heists.

Since hackers often share directions for gaining entry to computer systems, the big concern is that other banks could be hit, says Patricia Hines, a senior analyst with consultant Celent. “We’re liable to see this happen again,” she says.

The aftermath has rocked the genteel world of correspondent banking. Many blame SWIFT, grousing that while third-party vendors must endure a rigorous certification program to operate on the platform, bank participants are often handed access with relatively little scrutiny.

The organization also designs secure software and hardware that it sells to financial institutions for use in their data centers, but doesn’t require that banks use it, Hines says.

Following the Bangladeshi theft, “the big banks went to SWIFT and said, ‘What the heck! You’re the hub. Where’s the security?’” she says.

“You’re one of 11,000” institutions on a relatively insecure network, Hines adds. “If there’s one bad actor on the network, in theory they can get to everyone else on the network.”

Others say SWIFT does the best it can. The terms of use are clear, as are SWIFT’s limitations. In the wake of the hack, it established an investigative unit and has become more proactive at communicating with institutions about potential threats and needed patches.

It also has launched a “customer security program,” aimed at defining an operational and security baseline that its customers must meet to handle transactions on its platform securely.

But while SWIFT can serve as a central clearinghouse for standards and market practices, the organization has a boundary problem. If it were to try to impose its own security protocols, for example, U.S. regulators (and those in other jurisdictions) would likely balk. As for in-depth foreign-led investigations on U.S. soil, you can imagine how that might play out politically.

“SWIFT puts a lot of time and effort into making sure it’s bulletproof, but there’s only so much it can do,” says Ed Wilson, a partner who specializes in regulatory matters at Venable LLP, in Washington, D.C. “At the end of the day, it’s up to the financial institutions to do their own monitoring.”

U.S. regulators agree. In a statement following the Bangladesh Bank attack, the Federal Financial Institutions Examination Council (FFIEC) reiterated several “specific risk mitigation techniques” related to SWIFT transactions that banks already are expected to perform as part of their cybersecurity efforts.

Those techniques include conducting ongoing information security risk assessments, implementing and testing controls around critical systems, managing business continuity risk and enhancing training and information-security awareness programs.

“It’s about having a very strong focus on malware prevention, employee phishing awareness and administrator access, and ensuring you have strong authentication processes for money-movement transactions,” Witty explains.

To satisfy regulators and avoid financial losses, Wilson recommends a three-layered approach to SWIFT-related security controls, with strict controls on not only external access, but also physical and local-area access.

“First, you keep people who don’t need to be there physically away from your systems. Those who have access should be limited to only what they need,” Wilson says. “How many people need access to your SWIFT node? Maybe one. If you keep everyone else away, you reduce risks.”

Directors should provide high-level guidance and ask internal audit to review how passwords are allocated and how often they are reset, and limits on vendor and customer access. They also should know that the security has been tested, and that employees are being trained and systems are detecting suspicious activities.

“You can keep [hackers] from getting into your data center, but if they’re initiating transactions that flow through your bank, to be part of the solution you need to catch those,” Hines says.

Wilson says he knows of midsized banks that have decided to pull back from SWIFT “because the compliance costs aren’t worth the number of overseas transactions they perform.” Boards of those on the platform need to ensure that the cybersecurity team has the resources needed to protect the institution from hacks and other threats.

“When [examiners] meet with the audit committee, they expect to hear these kinds of conversations,” Wilson says. “They want to see it in the minutes and see internal reports on the topic.”