Viewing posts tagged SWIFT
In a survey of several thousand IT professionals across a dozen countries, 57% of respondents said that encryption key management at their company was “painful.” In a similar study, the risk and cost associated with key management was, on average, rated a seven out of 10. Those percentages change from year to year, but as the importance of encryption becomes increasingly obvious across different sectors, the total number of businesses dealing with serious encryption key pain is only going to go up.
At a SWIFT-run business forum a few years ago, a handful of banking insiders gave a rundown of the cybersecurity threats that keep them up at night. Some of what they were worried about was predictable—giant data breaches running hundreds of millions of dollars, adversaries getting smarter and more sophisticated, etc.—but some of it displayed a little more nuance. Some were specifically worried that they might completely miss a cyberattack and only realize what had happened much later (which is hardly an implausible scenario). Others were worried about the high rate of false positives in anti-fraud operations.
Right now, your bank is probably vulnerable to costly cyber attacks. Why? Because, like most financial institutions, you probably haven’t implemented end-to-end encryption or robust endpoint protection. It’s easy to understand why something like this could fall through the cracks—no one wants to shell out for a complex software solution whose purpose they don’t fully get—but the next big cyber bank heist is coming, and you probably don’t want to be the victim.
In 2018, the Bank of Chile found that the malicious KillDisk virus had infiltrated 9,000 of its computers and 500 of its servers and was poised to wreak havoc on their internal systems. Understandably, they immediately went into crisis mode, working as quickly as possible to disconnect those workstations. During the ensuing flurry of activity, the hackers were able to perform their real attack completely unnoticed: $10 million worth of fraudulent SWIFT transactions that the bank was too busy to notice.
When SWIFT messages are utilized in bank heists like the 2016 Bangladesh Bank attack, reports often refer to SWIFT having been “hacked.” In reality, it’s the banks themselves that have had their cybersecurity flaws exposed, and the SWIFT network was only used as a tool for the fraudsters to gain the trust of the financial institutions that are performing the transfers. This might seem like a small nit to pick, but in some ways it’s an important distinction to draw. Why? Because it centers “trust” as one of the most important elements of both successful fraud and successful fraud prevention.
SWIFT fraud is on the rise. In a recent EastNets survey of 200 of the roughly 11,000 financial institutions on the SWIFT network, 80% of respondents said they had experienced at least one attempt at SWIFT fraud in the three-plus years since the infamous Bangladesh Bank heist. In Asia, that number is closer to 100%, and the number across the board is probably somewhat higher than that—given that only 40% of the banks surveyed were “very confident” that they were successfully detecting every fraud attempt on their network.
Every year, the bar for SWIFT CSP compliance gets pitched a little bit higher. For 2020, a number of advisory controls were upgraded to mandatory, including a control related to shrinking the threat surface in banking organizations through application hardening. This is a wise tactic: as attackers carrying out fraudulent transactions get more sophisticated, financial institutions need to do the same when it comes to information security. At the same time, it’s not clear that increased mandatory advisories will be enough to stem the year-over-year increase in SWIFT CSP fraud.