Posted 1 month ago
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.
One potential silver lining is that the total sums for your average attempt at message manipulation have been dropping from the gaudy amounts we saw in Bangladesh ($800 million or so) to more like six and seven figure attacks. But when the good news is that attackers are only targeting banks for hundreds of thousands of dollars, something is seriously wrong. Plus, these smaller transactions are more likely to “blend in” and go unnoticed by financial institutions.
All of this raises an important question: what are banks doing at this very moment to decrease the risk of fraud and message manipulation going forward? Unfortunately, the answer for many banks is, “not enough.”
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:
SWIFT CSP compliance requires banks and financial institutions to protect end to end messages and transactions that are bound for the SWIFT network, but with most of the current solutions available this can be either impossible or a huge operational burden. Admins have to manage the process by hand for a huge number of back office applications in order to cover the entire attack surface—which can already be extremely time consuming—and there’s a lot of ongoing maintenance. This includes generating a large number of encryption keys on a recurring basis, changing them out every 6 months to a year at least, distributing those keys, and tracking their expiration dates. Studies show that most organizations have an extremely difficult time keeping track of their keys and certificates, and often don’t even know where they’re stored—so you can imagine that managing this much infrastructure by hand would be a real high wire act for most businesses.
The point of encryption is to reduce your attack surface, but when you have this much manual effort involved the encryption process itself is often far from secure. Why? Because every manual step increases the risk of human error—which is already the single biggest cyber security risk that operations of all stripes face. As such, it’s easy to imagine why SWIFT-connected banks would still feel less-than-sanguine about their options when it comes to encryption.
Part of the reason that manual encryption efforts would be so difficult to manage is that back office IT environments at banks are already incredibly complex. This means that making a change of any sort is difficult, slow, and costly. These has two implications for our purposes:
The result 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.
TCO often gets even higher when companies try to go above and beyond. To fill in some of the gaps that are left by manual key and certificate management and storage requirements, some businesses feel that they have to install sophisticated anti-fraud tools equipped with analytics capabilities and cyber attack simulations. 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.
The challenges to SWIFT CSP compliance around end-to-end protection that we’ve listed above can be daunting—but don’t lose hope! Not only can banks and other SWIFT users implement a solution that will overcome these challenges, they can do so in a way that makes security virtually invisible throughout their operations (save for in their logs).
At p≡p security, we’re offering the first fully decentralized, open source end-to-end encryption platform for banks on the SWIFT network. After a turnkey installation, p≡p is able to sign and unbreakably encrypt all financial messages within your network. Keys are managed invisibly, meaning that they can be changed out automatically on a more rapid and regular timeline than those managed by hand, without the risk of human error when it comes to storing and distributing new keys and certificates.
Because the system is open source with code audits and reproducible builds, there’s no need to worry about the potential for encryption backdoors. At the same time, we’re still able to provide regulatory monitoring for fraud, sanctions, and other compliance topics via extra read keys (which enable admins, plus regulatory bodies and systems to read financial messages without altering them)—an encryption “front door,” if you will.
From an integration perspective, p≡p is designed to slot easily into complex IT environments, offering three potential installation methods:
This means that the software can be slotted seamlessly into any IT environment and immediately begin to offer automated key, trust, and identity management. Attack vectors are effectively minimized by Perfect Forward Secrecy (PFS) for past transaction and by Short Living Keys for future transactions, while your entire back office system gets invisible anti-fraud coverage with p≡p’s plug-and-play solution.
Okay, let’s say you implement the solution we’ve been describing in order to meet the challenges posed by SWIFT CSP compliance—what would your expected result be in terms of those challenges? For starters, the tremendous level of effort that goes into managing keys and PKIs by hand would vanish overnight. Rather than devoting costly and fallible human resources to something that a computer program can do much more effectively and without errors, you can let the p≡p system distribute and regularly swap out keys for financial messages without even thinking about it. p≡p even checks that the sender’s key comes from the correct system, a feature not available with X509 certificates. Thus, the immediate result is seamless, end-to-end protection at the application layer for everything that produces SWIFT transactions—resulting in compliance with SWIFT CSP’s security guidelines.
Because key- , trust-, and identity-management are fully automated, the second result is that your TCO drops considerably. For one thing, the solution itself costs less than you’ll spend on stamps and envelopes over the course of year—but it doesn’t require you to lay out expensive manual efforts for installation and maintenance. No need to hire extra IT staff to help manage keys or certificates and perform complex software and hardware modifications. Just plug and play—the average employee at your bank or financial institution will never even notice a change, while the administrators and operators will love it. The only difference will be that you can work with confidence that no financial messages you send to the SWIFT network can be read in transit, changed, or altered.
In a post-Bangladesh world, banks and other financial institutions need to know where each financial transaction is coming from, and they need end-to-end protection across the entire back office. Instead of using heavy, costly systems like the ones that are standard on the market right now that don’t solve the compliance problem, you could utilize a turnkey solution that requires no manual effort and effectively stops cyber attacks like the Bangladesh heist in their tracks. Rather than being one of those businesses that can’t even say where the encryption keys are stored, you can be one of those banks that never falls victim to SWIFT fraud or cybercrime again.