They say a picture is worth a thousand words--but what about a statistic? The stats above should give banks a pretty clear picture of what’s at stake when we talk about SWIFT compliance, and how far banks have to go when it comes to achieving message protection standards that will truly provide a defense against SWIFT fraud and similar attacks.
Every year, SWIFT puts out its new CSP guidelines, raising the bar at least a little as far as cybersecurity standards go, but right now the compliance landscape is far from robust. Why? Because banks are already dealing with complex back-office data flows, and it’s understandably difficult for CISOs or financial messaging managers to get the buy-in of the rest of the C-suite when it comes to heavy and costly encryption implementations.
Of course, these implementations don’t have to be heavy or costly if you know what to look for. Below, we’ll give you an overview of the top challenges that banks face in achieving SWIFT CSP compliance, as well as guidance for how to overcome those problems and stop attackers in their tracks.
There’s a lot of nuance to this topic, and we’ll try to do that nuance justice--but here’s the tl;dr:
End-to-end encryption of SWIFT messages across your entire back-office ecosystem is the only surefire way to prevent the man-in-the-middle attacks that lead to SWIFT fraud. To optimize your TCO and your protection, you need an easy-to-install, end-to-end, automated encryption management solution for your whole back office that handles key management for you, thereby reducing the possibility of human error.
Why do we say that? Keep reading and find out.
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: This isn’t to suggest that the regulations are counterproductive—only that digital attackers 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 financial 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.
Following the Bangladesh incident, the SWIFT network rolled out its Customer Security Programme (CSP), which has been offering standards and guidelines for banks to comply with in order to reduce SWIFT fraud going forward. These standards have been updated every year, and for 2020 they now mandate application hardening to reduce the attack surface for SWIFT-related IT components, plus the securing of virtual machines that host those components up to the same standards used for physical machines. In addition, this new round of updates calls for a new independent assessment methodology.
As these updates to the guidelines continue to evolve, however, it’s not clear that they’re resulting in increased compliance among banks. On the contrary, compliance seems to be pretty shaky across the board. No one wants their cyber security and their resilience to message manipulation to be sub-par—so why aren’t we seeing widespread adoption of the new best practices? In large part, it’s because of a few distinct challenges:
The first factor that makes fraud prevention difficult for banks comes the tremendous complexity of back-office dataflows. If messages sent throughout your system can’t be traced, it becomes impossible to filter out harmful messages associated with malicious attacks SWIFT CSP’s guidelines advise banks to “Ensure the confidentiality, integrity, and mutual authenticity of data flows between back office (or middleware) applications and connecting SWIFT infrastructure components.” But as McKinsey and others will happily tell you, these processes are often slow and laborious—either they involve a number of tedious manual components, or they’re plagued by technical debt that prevents easy security fixes, or both. The result is that even small changes to a given IT ecosystem can create serious headaches up and down the process chain.
Obviously, maintaining confidentiality, integrity, and authenticity is extremely important for keeping data safe and secure—signed and authenticated messages are the only way to ensure traceability and weed out malicious messages originating at fake endpoints. But the complexity of the existing back-office environments means that CIOs and IT managers often don’t even know where to begin. If there’s technical debt, it might seem like you would have to work down that debt before you could even begin to map out all of your processes and get a handle on what kinds of solutions you would need in order to get full encryption or security coverage. As you can imagine, situations like this stop some data security efforts in their tracks.
In spite of the obstacles to successful fraud prevention outlined above, there are plenty of businesses who forge ahead and try to find solutions that will work within their existing IT infrastructures. Unfortunately, this often presents its own challenges: most of what’s on the market right now is heavy and costly, meaning that it’s difficult to justify the ongoing expense involved. On top of the costs of the software licenses themselves, you have to invest considerable time in installing the solution across the back office, potentially finding a way to jury-rig the system so that it covers both SWIFT messages and email. Once that’s done, you may have to continue expending expensive resources on maintenance.
This would be enough of a challenge in itself, but it becomes even more daunting when you realize that there simply isn’t a single solution of that kind that can bring your company into full compliance with SWIFT CSP’s encryption requirement. Of the banks that are implementing costly and laborious technology solutions, many are using fancy fraud detection software that uses behavioral analytics and complex attack simulations. No doubt these solutions can be helpful, but they can’t provide the same protection that comes from the ability to easily encrypt, sign, and decrypt messages coming to and from the SWIFT network. Why? Because signed and encrypted messages elegantly answer the problems of confidentiality, integrity, and authenticity outlined in the SWIFT CSP guidelines.
How does encryption protect your back-office data flow? Simply put, an encrypted message can’t be read by someone who’s not in position of the relevant key—meaning that an attacker who manages to spy on your traffic and intercept a message has no inroad into your system for the simple reason that she can’t read it. By the same token, a message that’s been encrypted and signed can’t be altered without it becoming immediately obvious to the recipient. Thus, if a malicious actor were attempting a man-in-the-middle attack (i.e. intercepting your messages, changing them, and then sending them on their way with manipulated information—and potentially doing the same thing from both sides throughout an entire exchange), the signature generated by your encryption key would be broken, and the recipient would be able to see that the signature didn’t match expectations. If you were arranging a transfer of funds, the incorrect signature would tell you not to go through with the transaction. In other words, strong, end-to-end encryption across the bank’s back office in general and SWIFT messages in particular effectively stops Bangladesh-style heists in their tracks.
Here you might be thinking, “If encryption is so effective at stopping these kinds of attacks, why isn’t it a common practice throughout the industry?” It’s a reasonable question, with a few potential answers:
As you can imagine, the challenges attendant to managing keys can be a real deterrent—and they can jeopardize the protection of your messages. After all, if you can’t keep track of when your keys have been changed out most recently and they do, in fact, expire, entire data flows can come to an immediate halt.
The result of the deployment of multiple key management solutions, to say nothing of the manual effort and ongoing management requirements plus the integration challenges and costs is that total cost of ownership can quickly become untenable, or at least unattractive. Because the information around SWIFT fraud is still incomplete, it can be difficult to do real ROI calculations for the kind of back office data flow protection under discussion, but it goes without saying that as TCO goes up your ROI potential begins to plummet. Security is, of course, paramount—but when it comes to solutions that are expensive and prone to human error, it can become much harder to get buy-in as a CISO (or to get fully on board as a CIO) with the proposed changes to your back office. This is especially true if you can’t use the same technology to cover your SWIFT transactions and your other financial messaging flows.
TCO often gets even higher when companies try to go above and beyond. Companies that install sophisticated anti-fraud tools equipped with analytics capabilities and cyber attack simulations, for instance, pay a lot for that protection. This goes beyond what SWIFT CSP calls for, but with only imperfect compliance solutions as alternatives, it’s easy to imagine the reasoning for expensive applications like these.
These challenges are nothing to sneeze at. And yet, banks do need some kind of encryption management in order to prevent potentially catastrophic losses due to SWIFT fraud. The question is, “What should that encryption management look like?” Let’s take compliance with SWIFT CSP’s non-repudiation requirement as a sort of representative test case. NIST offers the following definition of non-repudiation: “Assurance that the sender of information is provided with proof of delivery and the recipient is provided with proof of the sender’s identity, so neither can later deny having processed the information.” In other words, non-repudiation involves finding some way to ensure:
While many discussion around encryption-management tend to center on confidentiality (i.e. that no one but the intended recipient can read a given message), these other facets are just as important when it comes to preventing the kind of fraud that resulted in the infamous Bangladesh Bank heist and many similar incidents over the past few years.
In the pre-digital era, non-repudiation efforts were mostly accomplished through signatures (e.g. on a check or money order). For added levels of security, you might require that a particular signature be notarized, i.e. verified by a trained third party who was present at the time of signing. Of course, nowadays we realize how easy it can be to forge a signature. Plus, most modern banking happens online, which means that physical signatures are being replaced with digital ones anyway. If you’re a bank or financial institution, you know that not all digital signatures are equally robust. A signature box on an online form that requires you to drag your mouse to create a signature, for instance, isn’t going to provide much protection against forgeries. A system that uses asymmetric encryption to “sign” messages (you provide a signature with your private key and the recipient uses your public key to ensure that it’s really you), on the other hand, makes the signature impossible to forge unless an attacker has somehow gotten hold of your private key.
Simply put, if the Bangladesh Bank and the New York Fed had had non-repudiation processes like that in place, the multi-million dollar heist could have been stopped in its tracks. Since the messages had been altered in transit, the signatures would have been incorrect, and the recipient wouldn’t be able to assure non-repudiation of origin. Thus, the transaction wouldn’t go through, and the fraud attempt would be averted.
So, how do you get around the encryption and key management headaches that we outlined above? For starters, you need a solution that effectively covers all of your endpoints; if your SWIFT messages are being encrypted at the moment they leave their points of origination, only to be decrypted before they’ve actually made it to the SWIFT network, then the messages are still vulnerable to tampering. This means that a heavy, complex installation that makes it difficult to cover all of your endpoints will present real issues, compared to a turnkey installation that immediately protects messages at the application level.
In addition to ease-of-installation, you’d also want ease-of-use from an admin and key management perspective. Finally, by choosing an open source solution that offers reproducible builds, you can avoid the potential pitfalls that come with black box encryption solutions. This might seem like somewhat of an afterthought for decision makers in financial institutions—compliance is hard enough without worrying about backdoors that may or may not exist—but it’s at least worth having on one’s radar. Ultimately, though, the most important thing is that you’re able to provide this level of encryption protection in a way that won’t break the bank or your existing software. Once you have that, you can encrypt and sign your SWIFT messages and thus achieve non-repudiation compliance, while also ensuring full traceability of messages.
Okay, we’ve seen how encryption can shrink the attack surface and make it impossible for attackers to change information on financial messages without your awareness—but there’s one remaining piece of the puzzle: how to make encryption easy to manage and maintain without a host of complex and expensive overlapping solutions.
This is where automation comes in. Imagine if you were able to automatically distribute encryption keys and switch them out regularly (i.e. every 30, 60, or 90 days without fail). All of a sudden, the window for a successful attack shrinks considerably—and the odds of a particular key expiring and causing problems drops virtually to zero. Then, imagine that the same system automatically encrypts, signs, and decrypts messages at the endpoints in order to remove the possibility of human error from the equation.
Managing encryption by hand is always a risky strategy. If your system administrator forgets to 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 messages 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.
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 fraudsters 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.