Posted 1 year, 7 months ago
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.
In the nearly four years since the Bangladesh Heist, the global financial community has certainly made progress—but something systemic needs to change if banks and other businesses are going to stave off fraudulent transactions. SWIFT administrators within global banks need to be given the tools to meaningfully reduce the risk of malicious actors performing a man-in-the-middle attacks that lose their businesses millions of dollars in fraudulent payouts. What might those tools look like? Two words: automated encryption.
Okay, let’s back up a second to provide background on a few of the things we mentioned above. Every year since 2017, SWIFT has put out a set of regulations that covers both bank transactions themselves and larger InfoSec concerns within banking organizations—all with the aim of reducing online bank heists. Though these requirements get more stringent every year, reports suggest that the number of incidents has steadily increased since SWIFT’s regulations were put in place: more than 60% of banks surveyed said that SWIFT cybercrime has been on the rise, and only 40% of banks are “very confident” that they’ve detected all of the fraud attempts that have been aimed at them. This isn’t to suggest that the regulations are counterproductive—only that hackers are relentless, and they’ll make it their mission to find new ways of stealing credentials and impersonating trusted users and businesses.
Of course, the catalyst for all of these new regulations—and the event that made SWIFT fraud top of mind for CIOs and CISOs across the finance sector—was the infamous Bangladesh Bank Heist of 2016. For those who need a refresher, the Bangladesh Bank heist occurred in February 2016, when 35 fraudulent instructions were issued inside the bank by hackers via the SWIFT network, in order to illegally transfer US $951 million from the Federal Reserve Bank of New York account belonging to Bangladesh Bank, the central bank of Bangladesh. Five of the thirty-five fraudulent transactions were successful, transferring $101 million to Sri Lanka and the Philippines. The Federal Reserve Bank of New York blocked the remaining thirty transactions, amounting to $850 million, due to suspicions raised by a misspelled instruction. Neither the FED in New York nor the central bank of Bangladesh had the systems in place to prevent such an attack from happening or to detect it in real-time. Though much of the money was ultimately recovered, the incident remains something of a black eye for the global banking community.
What made the Bangladesh Heist so remarkable, beyond the eye-catching amount of money being stolen, was that it marked a shift in strategy for hackers trying to infiltrate banks. In the past, the most commonly targeted attack surface was bank users themselves, i.e. individual account holders whose pin and bank account numbers could be easily compromised. The incident in Bangladesh represented one of the first instances in which an entire bank’s SWIFT account was the target of compromise. At the time, this gave rise to rumors that the heist had been at least partially an inside job—but the general feeling was that the real culprit was poor cyber-security on the part of the bank. The central bank of Bangladesh reportedly had insufficient cybersecurity protections in many areas, meaning that hackers had every opportunity to access to the bank’s network and systems.
After the Bangladesh incident, a 2013 hack along similar lines at the Sonali Bank, wherein US$250,000 was stolen by still unidentified hackers, came to light as well.
SWIFT took reasonably quick action to provide guidance to banks hoping to prevent similar attacks in the future, offering new best practices and protocols that went into enforcement on the first day of 2018. This included a slate of access control guidelines (i.e. who can access what information under what circumstances), as well standards for password and encryption management. In addition to enforcing the measures through the usual means, the organization also sought to improve visibility across the industry by making compliance audit results available to other banks. All of these efforts (which are obviously ongoing today) are aimed at improving security for back office data flows and making sure that messages from one bank to another can’t be faked or altered, in the hopes of reducing cybercrime. The question is: why isn’t it working?
Everyone in the financial industry, from SWIFT to its clients, has the same goal—reducing costly instances of fraud and cybercrime. And yet, it’s difficult to find banks and other financial institutions that are in full compliance with SWIFT CSP’s recommendations for mitigating cyber attacks. Why might that be the case? There are any number of reasons:
Banks need end-to-end security measures now more than ever, but in the years since the Bangladesh incident a workable solution that handles security, end-to-end protection of messages simply hasn’t arisen. That is, until the introduction of automation into the encryption landscape.
Managing encryption by hand is always a risky strategy. If your system administrator forgets to the do the 6-monthly or yearly renewal of the key or certificate, the systems come crashing to a halt. Likewise, if administrators have to keep putting in manual effort to keep encryption running, they might get more lax over time, potentially inviting man-in-the-middle attacks in which hackers impersonate them. In addition, keys or certificates, which are often valid for up to 6 or 12 months, open a lengthy attack window of similar duration in case of a leak. The more complicated the process of performing a back office function or sending encrypted message becomes, the less likely people are to do them securely every time. That means that even after you’ve put in all of the work to introduce a costly and complex encryption system to cover your back office, your compliance still isn’t guaranteed. You need to know where each payment request is really coming from – and you need to know that it hasn’t been modified – but you need that information to come in a way that’s consistently usable and workable for everyone in your organization.
Enter automation: if, instead of all of this manual effort around key management, you can employ a turnkey solution that manages all of the ins and outs of integration and daily use automatically, these potential risk factors begin to disappear. Instead of a costly and time consuming process of jerry-rigging your existing IT solutions so that they play nicely with your encryption solution, you just plug-and-play; your transactions become radically more secure without anyone in the organization noticing much of a difference. There’s no need to change your network or interrupt your work, just as there’s no need for an admin to manually change out the PKI certificates every 30, 60, 90, etc. days.
If hackers were trying to target your bank in order to modify your SWIFT messages and deviate funds to ‘new’ financial institutions, a system completely lacking in encryption would be highly vulnerable to attacks. A system with encryption/signatures and manual key management would be an improvement, but it would be labor intensive, come with a high TCO, and be prone to human error. In an IT environment with automated, end-to-end encryption and key management, an attack of this kind becomes virtually impossible.
We said above that the introduction of automation into the end-to-end protection landscape for SWIFT CSP compliance was a game changer—and it is. It’s the only way to ensure compliance in any IT environment, no matter how complex or how loaded down with legacy systems, just as it’s the only way to keep TCO low. But how exactly can you implement automation for end-to-end protection in this way?
Right now, p≡p Security provides the only automated, end-to-end protection solution for SWIFT messages along the CSP security guidelines. This includes automated management of encryption keys, so that admins can integrate encryption seamlessly across all business systems that generate SWIFT transactions. All of a sudden, the systems can sign and protect communications with unbroken encryption on the application layer in a way that’s completely independent of your network infrastructure and completely invisible from an operational point of view (except in logging). The risk of a fraudulently modified SWIFT transactions disappears overnight, not only because of the encryption itself, but because the maintenance of that encryption is also automated. Banks need a seamless, cost-effective surefire way to tell whether messages have been manipulated and whether they’re from trusted sources—just as they need a surefire way to protect their own SWIFT keys from hackers like those in the Bangladesh Heist. p≡p’s mission is to provide just that.