Chase Makes The Right Security Move After SWIFT Breaches

A report Tuesday (May 17) that J.P. Morgan Chase “has limited some employees’ access to the SWIFT global interbank messaging service amid questions about security breaches at a pair of Asian banks that used the funds-transfer platform” raises some concerns, but it appears to be just enforcing a stricter “need to know” and “need to access” approach from Chase.

That report, from The Wall Street Journal, said Chase officials had implemented those tighter controls “in recent weeks.” Said that story: “The measures follow cyberattacks in December at a commercial bank in Vietnam and one in February at Bangladesh’s central bank, both of which have been reported by SWIFT. In both cases, thieves obtained access to the firms’ own credentials for SWIFT and used them to send fraudulent payment instructions.”

A SWIFT official is quoted saying that the SWIFT network itself “remains secure.” Assuming that the statement is accurate and not merely a standard corporate defensive utterance, that doesn’t necessarily mean that the security problems didn’t happen within the SWIFT network. It more likely means that the attackers presented valid access credentials, which SWIFT properly authenticated. That is entirely consistent with Chase cracking down on employee access.

Although there have been other reports raising the possibility of an earlier SWIFT attack—with a major Bangladesh bank—being an insider job, it could just as easily be an attack where the bank employees were victimized. Employees might have had their credentials stolen via keystroke-capturing malware or being tricked into visiting a credential-stealing site designed to look like SWIFT’s access area.

The Journal story also quoted Michael McGowan, a compliance leader at Stroz Friedberg, saying that “the system is widely perceived by banks as being secure, but these incidents have shaken their beliefs, and are raising the same kinds of identification questions that have arisen with spoofed emails and other systems.”

Based on the details currently available, there’s no reason for any of this to shake anyone’s faith in SWIFT. Even the best 2-factor authentication systems will be fooled every time by someone who correctly presents both credentials. If a bank employee gets tricked into revealing credentials, it’s hardly an indictment of SWIFT’s security.

That is why Chase’s move—long overdue, in my opinion—is the first step of a proper response.

• Step One: Wipe out the access credentials for anyone who doesn’t absolutely need frequent access to SWIFT. The fewer people who have it, the fewer weak links for attackers to manipulate. And if a true insider thief materializes, restricting access makes the bad guys’ effort to find a willing accomplice that much more difficult.
• Step Two: Remind all of the risks of being tricked, including the lectures about not clicking on unknown links. The problem here is that cyberthieves today are getting more sophisticated and will do their due diligence using LinkedIn and Google to make their bogus e-mail requests sound plausible and that they are coming from a known person. In short, the tricksters are getting trickier.

It’s also OK for employees to reveal their authentication credentials to the SWIFT access area. But when an employee is presented with an identical replica of that page, it’s easy to understand why they reveal their credentials. Prompting them to examine the full URL is a great place to start.

• Step Three: Upgrading the level of security required (some biometrics?) and forcing the credentials to be changed at what will seem to employees to be exceedingly irritatingly frequent is another key move.

What Chase is starting to do is what all banks—and anyone else accessing SWIFT—need to consider doing right away. Just because the evidence doesn’t yet merit blaming SWIFT doesn’t mean that no action is needed.