Posted 1 year, 3 months ago
Right now, your bank is probably vulnerable to costly cyber attacks. Why? Because, like most financial institutions, you probably haven’t implemented end-to-end encryption or robust endpoint protection. It’s easy to understand why something like this could fall through the cracks—no one wants to shell out for a complex software solution whose purpose they don’t fully get—but the next big cyber bank heist is coming, and you probably don’t want to be the victim.
This isn’t idle speculation: In the years since the Bangladesh Bank heist, there have been other high profile cases of SWIFT fraud at banks in Ecuador, Taiwan, and Argentina, with each one costing tens of millions of dollars. And these are just the heists that we know about. Though most banks have had fraud attempts against them, right now they readily admit that they’re probably not detecting each attempt—i.e. that attacks are slipping past unnoticed.
SWIFT CSP offers banks guidance for dealing with these persistent threats, but compliance with that guidance tends to be lacking. Given the magnitude of the threat, SWIFT’s answer is to restrict physical and digital access to financial networks; reduce attack surfaces in order to fend off malware; secure IT perimeters; manage identities and privileges in such a way as to ensure confidentiality, integrity, authenticity, and trust; and monitor systems for evidence of malicious activity. This can seem overwhelming, and banks often don’t even know where to begin—resulting in stalled cyber security efforts and continued vulnerability.
The situation we described above is obviously high-risk for all involved, but as luck would have it the solution is deceptively simple: end-to-end encryption. By implementing a solution that encrypts, signs, and decrypts SWIFT messages at relevant endpoints, you can effectively stave off attacks like the Bangladesh Bank heist, which involve a kind of message manipulation that would be impossible on an encrypted and signed message.
Without encrypting and signing messages, a malicious actor who has gains access to your communications can intercept them, read them, alter information (i.e. change the account number on a SWIFT message to reflect an account that they control, rather than the actual intended recipient), and send them on their way as if they had originated with you and been transported unaltered. From there, it’s a matter of chance whether the ones processing the transaction on the other end notice that the account number is incorrect. In the Bangladesh incident, someone at the NY Fed eventually noticed a typo, but not before millions of dollars had already been transferred to attacker-controlled bank accounts.
With an encryption deployment that covers every back-office element that interacts with the SWIFT network, on the other hand, you no longer have to leave fraud prevention up to chance. Instead of hoping that a busy bank worker will notice a few changed digits on a message, you can rest assured that any tampering with a message will be made extremely obvious: since an encrypted and signed message is signed using a private encryption key (to which an attacker would have extreme difficulty gaining access), an attacker who tried to alter a message and send it on its way would have no way to reproduce the signature. Thus, the integrity of the message would be called into question immediately. With p≡p for SWIFT, messages with broken signatures are automatically flagged, and the transactions can be stopped from going through. In the same way, the presence of the signature and the asymmetric exchange of keys ensures that the message is from whomever it purports to be from, which p≡p automatically verifies.
We’ve seen above the general scope of how end-to-end encryption helps banks stave off SWIFT fraud—but let’s dig a little deeper into the role that end-to-end encryption can play in SWIFT CSP compliance:
The first rung on the CSP compliance ladder is securing the SWIFT environment. Here, SWIFT CSP recommends restricting access to critical systems in order to protect SWIFT-connected systems from other devices or elements of your IT infrastructure that might be vulnerable or compromised. They also recommend reducing your attack surface, physically securing your space, and performing application hardening (which usually involves a good deal of encryption—of hard drives, databases, etc.—to begin with) to reduce the possibility that vulnerabilities will be exploited. All of this is important, but it doesn’t provide you with full protection unless you’re also able to encrypt your messages in transit.
Automated encryption management provides a lightweight way to achieve protect your messages between endpoints (i.e. as they’re moving through the back office and eventually to the SWIFT network), which increases the effectiveness of whatever protections you have at the endpoints themselves. If you can implement encryption on the application level, then the possibility of an attacker actually being able to read any data being transmitted across your back office drops off precipitously. In other words, encryption provides confidentiality (no one can read messages except the intended recipient—who has the key to automatically decrypt them), which can be leveraged to nullify the effect of an intrusion at an endpoint.
Though these guidelines specifically apply to the SWIFT network and applications that touch that network, email can actually be a useful example for how encryption also makes access control easier. If, for instance, your email users have automated encryption (and thus automated trust management, such that they can always be sure that they’re talking to who they think they are), then their odds of falling prey to an email phishing scam drop virtually to zero. Since phishing scams rely on users erroneously believing the attacker is a trusted colleague, and an automated encryption solution can immediately flag messages that aren’t really part of the trusted communication pathway that’s already been established between the user and, say, the CFO, that attack vector suddenly vanishes. Once that happens, it becomes difficult or impossible for attackers and fraudsters to use malware to gain access to your system. This has the effect of securing your applications and making it easy to comply with the SWIFT CSP recommendations.
Once you’ve secured your environment, SWIFT CSP requires that you manage identities, segregate privileges, and work to prevent the compromise of peoples’ credentials. Here, most businesses hue to the doctrine of least privilege, only giving employees the permission that they actually need in order to do their jobs. This reduces the likelihood that someone might access information that they shouldn’t, and it also works as a sort of contingency in case an attacker does get hold of someone’s login credentials, since the attacker still might not be able to see or do very much to interfere with the normal working of the system.
This is an area where encryption management per se isn’t relevant, but the overall complexity of your IT environment is. As you introduce more solutions aimed at managing your cybersecurity protocols into your IT ecosystem, you have more and more sets of permissions to manage and more access control questions to answer. In this way, there’s real value to implementing a solution like p≡p for SWIFT that’s invisible to normal operations and has an easy, plug-and-play installation. Simply put, the fact that p≡p for SWIFT doesn’t disrupt your existing ecosystem means that you won’t have to add any access controls hurdles to your to-do list as you install and implement automated encryption—a benefit that’s not necessarily true of heavier and more complex software suites.
Finally, SWIFT CSP suggests that banks put a plan in place to monitor activity on their networks in order to detect malicious activity early on, and that they have an incident response plan in place for when that malicious activities crops up. Like in the section above on securing the SWIFT application environment, some banks take this guideline to mean that they need to implement expensive and complex anti-virus and endpoint monitoring solutions—this goes hand in hand with the necessary end-to-end encryption of the messages for a sustainable protection across the bank. Either one by itself is insufficient to protect the SWIFT payment operations in the bank. . Often, when it comes to regulatory and monitoring activity, people think that they need some kind of encryption backdoor that bypasses their security measures—but in point of fact it’s possible to adopt an encryption solution with a sort of “window” by way of extra read-only encryption keys designed for just this purpose without breaking encryption and signatures
In addition to monitoring from a regulatory perspective, encryption for SWIFT messages creates a kind of de facto monitoring. How? By making it painfully obvious when the integrity or authenticity of an encrypted and signed message comes into question. Thus, if malicious actors have performed a man-in-the-middle attack and attempted to use a legitimate SWIFT message originating with your bank to siphon money into their own accounts, the transaction won’t go through (since the signature will have been broken), and you’ll know about the attempted fraud right away. Thus, not only is the fraud averted, but you’re suddenly able to track every fraud attempt—since the broken encryption will be clearly legible on any audit logs.
Once attacks are no longer slipping past without your knowledge, you can begin to take a more tactical approach to other elements of your information security picture. This can help you to uncover vulnerabilities over time and gradually improve your response to the potential for another Bangladesh Bank-style heist. That said, once you have the kind of automated encryption protection we're talking about across your entire back-office, SWIFT CSP compliance will be as easy as stopping at a red light.