Posted 3 months, 3 weeks ago
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.
In order to avoid costly cyber security incidents, banks need to know which messages are trustworthy and which aren’t—just like they need to know which ones have been tampered with and which ones haven’t. Establishing this kind of trustworthiness is one of the pillars of SWIFT’s new CSP (Customer Security Programme). However, since roll-out, a number of banks have found that implementing trust on a technical level is easier said than done.
Before we get into the reasons why that might be the case, let’s look at a few factors the suggest the urgency and importance of protecting against SWIFT fraud in the first place. We all know about the infamous $80 million Bangladesh Bank heist—which was the result of hackers manipulating the account numbers on legitimate financial messages in order to arrange gargantuan transfers to their own untraceable accounts throughout Southeast Asia and the Philippines—but that’s certainly not the only attack to have been carried out using the SWIFT network. In fact, SWIFT fraud has been on the rise, with attackers constantly adapting to better get their fraudulent transfers through undetected. Sometimes this looks like manipulating smaller transfers in the middle of business hours in order to blend in to normal activity—sometimes it means carrying out the attack in the dead of night.
This ability to adapt to new circumstances means that it’s difficult to be absolutely sure whether an attack has occurred in the first place. To wit, while 2/3rds of banks say they’ve been victims of SWIFT fraud attempts, only 40% are confident that they’ve caught every single fraud attempt on their systems. As such, whatever estimates we generate about how much money banks could save by preventing this kind of attack is likely to be an underestimate.
And yet, encryption adoption among banks isn’t particularly robust. In fact, there’s a considerable gap between SWIFT CSP’s guidelines and banks’ ability to actually install real fraud prevention measures. All of this begs the question: why is it so difficult to prevent SWIFT fraud?
The first factor that makes fraud prevention difficult for banks is the tremendous complexity of back-office dataflows. 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, but the complexity of these 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 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. Thus, 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.
Based on the challenges we listed out above, it shouldn’t be too difficult to imagine why hackers still approach SWIFT fraud as a viable, even lucrative, form of attack. So, are we stuck with the conclusion that SWIFT fraud prevention is simply too difficult, and that banks are doomed to failure when it comes to preventing this kind of intrusion? On the contrary! We saw above how encryption could shrink the attack surface and make it impossible for attackers to change information on financial messages without your awareness—it’s just a question of making 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. 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.
Right now, that’s exactly what p≡p for SWIFT offers to banks and other financial institutions. It’s a turnkey solution that integrates seamlessly with your entire back office IT ecosystem, including any cyber defense solutions or PKIs you may be using and maintaining. That means straightforward and quick installation, and then automatic protection against the most frequent kinds of SWIFT fraud. Admins can easily encrypt data at every touchpoint that interacts with the SWIFT network without worrying about complex key and certificate management solutions—and it does that at a low TCO (total cost of ownership) in terms of both subscription costs and ongoing maintenance. With most contemporary solutions, SWIFT fraud remains a constant risk—p≡p’s goal is to make fraud prevention as easy as a quick installation process.
p≡p Security launches p≡p for Thunderbird and p≡p for iOS, together with new versions for Outlook and Android
Sept. 7, 2020, 6 a.m.