Posted 3 weeks, 1 day ago
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.
All of these anxieties reflect the same basic fact: that cybersecurity in banking is somewhat of a patchwork, and that even as new threats are emerging every day the responses to those threats is usually slow and tentative. We can chalk this up to any number of reasons, but no doubt some of it is due to a series of misapprehensions about what those threats are and how to ward them off in an efficient and cost-effective way.
Before we talk about those misapprehensions, let’s take a second to walk through what the banking world looks like right now from a cybersecurity perspective. More than 25% of all malware attacks are currently targeted at banks, and it shows: between 2017 and 2018 there was a thousand-fold increase in the number of data breaches at financial institutions. In the UK, it was found that roughly 1 attack out of every 3 is successful—and all this at a time when the introduction of privacy laws like GDPR are making data breaches even more costly due to associated fines. No wonder most banking executives list cybersecurity as an increasing risk and have made it a top technological priority.
When it comes to the SWIFT network in particular, things are very much the same. As we’ve noted time and again on this blog, SWIFT fraud attempts are on the rise, and most banks aren’t confident that they’re catching every attempted attack. SWIFT’s CSP requirements are a good start, but they’re only as useful as their adoption rates throughout the industry.
All this brings us to our first myth that banks tell themselves about security: that complex, monolithic security solutions can be an effective substitute for complying with security recommendations and best practices. Too often, higher-ups at financial institutions invest their money and resources on solutions without first familiarizing themselves with SWIFT CSP guidelines, for instance. The result is that the specific, targeted actions and strategies that have been outlined for the express aim of limiting your attack surface for SWIFT fraud take a backseat to more generalized tactics that may not be as effective.
This is especially true in instances where you might be implementing a solution that hasn’t been crafted with the financial services industry in mind. SWIFT CSP 2020 recommends virtualization platform protection and application hardening for everything in your back office that touches the SWIFT network. It also requires message encryption, independent assessments, and auditable reports—all on an evolving basis as SWIFT’s understanding of the threat model changes. Because new gaps are uncovered and new best practices established all the time, a security strategy that doesn’t at least take compliance into account is doomed to be less than effective.
Of course, those who are implementing monolithic cybersecurity solutions are still doing better than those who are sitting on their hands. While this is a decreasingly common attitude, there’s still a lack of awareness about the specific threats that face banks and financial institutions. For one reason or another, you might believe that the next Bangladesh Bank-style heist couldn’t happen in your operation—and yet, you’re not encrypting your SWIFT messages in transit. This means that an attacker could intercept them, read their contents, and slowly choose the right moment to alter a crucial detail (like the account number) on a SWIFT message that originates with your bank, and send it on its way to be fulfilled by the recipient.
Again, this is an area where you need a nuanced view of your actual attack surface in order to implement robust cybersecurity protections. Ask yourself: right now, what’s stopping attackers who have gained access to your system from reading and altering the contents of SWIFT messages? What systems are in place to prevent those same attackers from gaining access to your system in the first place? Whose purview does something like SWIFT CSP compliance fall under within your organization, and what steps are they taking to prevent SWIFT fraud? What about other attack vectors and best practices?
Without answers to those questions, you may be courting disaster.
Interestingly, when people add up the costs of a data breach or other security incident, one of the line items tends to be increased cybersecurity spending. On the one hand, this makes sense—not only might you realize quite emphatically that you’re not doing enough to protect yourself, you might also be in a position where it’s necessary to make a public display of improving your security in order to win back trust. At the same time, there’s something more than a little backwards about this way of doing things—sort of like waiting to shell out for new alarms until after you’ve had a fire. If you’re in a position to look forward and calculate an inevitable uptick in security spending into your cost estimates for a security incident, you can instead take a proactive approach and spend that money right now. There’s no one-size-fits-all solution that can stop every kind of attack, but if you invest in things like message encryption sooner rather than later you can reduce the likelihood of an attack before becoming a victim.
This myth is especially prevalent when it comes to SWIFT fraud in particular. See: the large percentage of banks that aren’t confident that they’ve detected every SWIFT fraud attempt on their systems. And yet, the simple introduction of a message encryption solution into your SWIFT-connected environment make the integrity and authenticity of each message obvious on an audit trail. p≡p for SWIFT, for instance, has the ability to take a SWIFT message that’s been originated as normal, automatically encrypt it, sign it using that encryption key, and then automatically decrypt it at the gateway to the SWIFT network. No one on either end has to take any special steps or make an extra effort, but the encryption in transit preserves the confidentiality of the message—i.e. it’s not possible for an attacker who doesn’t have access to the relevant encryption keys to read the message. Likewise, the encryption-generated signature ensures the authenticity and integrity of the message—meaning that no one can alter it in transit without breaking the signature, and no one can recreate your exact signature without your encryption key. This means that a message that’s been tampered with will be flagged and thrown out. Not only that, but the audit will show the encryption history, meaning that every transaction that didn’t go through because of fraud concerns will be glaringly obvious. From here, you can gain a better understanding of your own threat model and continue to work to stave off cybersecurity lapses accordingly.
We mentioned in a section above that some banks are more or less sticking their heads in the sand when it comes to protecting themselves from data breaches, SWIFT fraud, etc. Then, there are banks who go too far in the opposite direction and spend a ton on the heaviest and most complicated IT they can find. While this is certainly a radical improvement over doing nothing, it can come with its own issues—not the least of which is total cost of ownership (TCO). In these cases, it’s often a matter of the bank continuing to be unclear on the actual threat model that applies to their business. To wit, if you’re not encrypting your SWIFT messages in transit, then there’s not much point in expensive and difficult-to-maintain anti-spam or anti-virus software, since they represent imperfect solutions to a very specific threat. Once you are encrypting those messages, on the other hand, some of these larger cyber security deployments may be redundant. That said, the p≡p solution has the ability to integrate with any existing IT infrastructure that you may be utilizing for cybersecurity purposes, including existing PKIs and other tools. In this way, it can slot seamlessly and automatically into any back-office environment, immediately providing message protection and easy oversight into where each message is coming from.