Posted 1 year, 7 months ago
In 2018, the Bank of Chile found that the malicious KillDisk virus had infiltrated 9,000 of its computers and 500 of its servers and was poised to wreak havoc on their internal systems. Understandably, they immediately went into crisis mode, working as quickly as possible to disconnect those workstations. During the ensuing flurry of activity, the hackers were able to perform their real attack completely unnoticed: $10 million worth of fraudulent SWIFT transactions that the bank was too busy to notice.
Not only does this incident go to show that hackers and fraudsters targeting banks are getting more sophisticated by the day—it also shows how easy it is for a single vulnerability to be spun into a multi-million-dollar heist. Of course, banks are aware of the severity of these threats, as evidenced by fact that 99% of banks are planning to maintain or increase their cybersecurity spending in the next year. That said, simply throwing money at the problem isn’t always enough to secure your data and your transactions. On the contrary, you need to know which threats are most significant, and what specific areas require protective measures.
Many of the cybersecurity risks that banks face are unique to the industry, or at least take a banking-specific form when carried out against financial institutions. The largest threat surface, however, is the same one that takes the top slot in nearly every other industry: human error. Whether it’s a SWIFT administrator who doesn’t notice that some information has been changed on a message, or a user who skipped the email phishing training and opens up a suspicious link containing malware, most incidents can be traced back to someone making a mistake. Perhaps this is why 40% of banks rank social engineering as the biggest threat to their systems. And just as this is the biggest attack vector across industries, it’s also one of the thorniest problems to solve—to err is human, and there’s simply no way to ensure that no one ever makes a mistake again. That said, you can use things like automation to decrease the amount of human intervention required to conduct your day-to-day business. While this might seem daunting in some areas, it doesn’t have to be—and it can shrink your attack surface significantly.
While SWIFT fraud attempts aren’t necessarily the single most common type of attack against banks, they’re often some of the most costly. We discussed the attack against the Bank of Chile above, and a similar attack against the Bank of Mexico falls into this category, but it’s also what happened in the infamous Bangladesh Bank heist a few years ago. Though SWIFT quickly rolled out its Customer Security Programme (CSP) following the $80 million dollar heist, studies show that this kind of attack is still on the rise—likely in part due to the difficulty that many banks have in complying with SWIFT’s requirements and suggestions. Back-office data flows, for instance, are often so complex and multi-faceted that the process of implementing end-to-end encryption seems costly and extremely labor intensive. After all, you need something that can integrate with a number of heavy and complex back-office software solutions, and you generally need a way to manage keys and certificates that prevents human error from creeping back into the process, all of which can be a significant pain point for businesses. And yet, if you can’t implement encryption in this way (as per the SWIFT CSP guidelines), there’s no way to be sure that the contents of a SWIFT message haven’t been altered without your notice.
Though phishing scams are hardly specific to the banking and financial services industries, they can be especially impactful when customers’ PII and financial information are on the line. Unfortunately, it’s all too easy for one careless email user to fall for a phishing email—maybe one that spoofs the CFO’s email address and urgently requests that you change the information on a wire transfer, so that it’s rerouted to the hacker’s account instead of the intended destination, all before the employee realizes that it wasn’t the CFO after all—resulting in an immediate loss. These days, though, it’s becoming more common for attackers to use email as a gateway to larger attacks. They might use a malicious PDF to install a keylogger on someone’s device, and then gather information about the bank and its customers over a course of months. Once they’ve gathered the information they need and chosen the right moment, they’ll find a way to wreak havoc on your entire operation.
Like SWIFT fraud above, this is an attack vector that can be effectively neutralized by end-to-end encryption. Why? Because properly deployed encryption provides:
In this way, any attempt at impersonating an executive’s email, a legitimate transaction, or anything else that can be encrypted is stopped in its tracks. Rather than using guesswork or gut feeling, you’re able to see definitive proof about whether a communication is or isn’t what it seems. This is why encryption has been and remains a best practice for email users in fields that involve sensitive information, and it’s why the SWIFT CSP recommendations insist upon encryption for the entire back-office data flow. Historically, however, practical difficulties in implementing encryption on a large scale have prevented many businesses in the financial sector from actually taking these measures.
Ransomware attacks—in which attackers are able to install software that encrypts the user’s data, rendering it unusable, and won’t decrypt it unless the victim pays a hefty ransom—result in an estimated $75 billion per year in damages. Though the threat model for ransomware is much the same as for phishing attacks (i.e. the attacker wants to trick the victim into opening an email attachment that contains the malicious code), it bears its own mention because banks are so frequently the target of this particular breed of attack. In fact, banks are the second most targeted industry for ransomware, after healthcare. From an operational perspective, there’s not much you would need to do to defend against this kind of attack that doesn’t already apply to anti-phishing measures, e.g. implementing email encryption such that your staff members don’t accidentally click on something fraudulent, but the age old question of how to keep human error at bay continues to crop up. Like with email and SWIFT, ransomware attacks can still slip through your defenses if, say, your encryption system is too complicated for people to use correctly. Some banks try to fight these attacks with heavy and costly anti-virus and spam filtering software—and this can certainly be an important piece of the puzzle—but without truly user-friendly encryption it may not be enough.
Like we said above, a bank’s back-office software ecosystem will usually be extremely complex, integrating with (or at least interacting with) software from a number of outside vendors and partner organizations (including SWIFT). A vulnerability in one of these adjacent software ecosystems can easily lead to vulnerabilities in your own—since you depend on being able to safely transmit information across your own back office and various other touchpoints. Obviously, you can’t improve your vendors’ security for them, but you can be extra-conscientious about making sure all of your own surfaces are covered. More than that, you can encourage your vendors to implement encryption by demonstrating its value within your own operations. At the end of the day, the safer any particular business is, the safer the industry as a whole can be.
At p≡p Security, we offer encryption management solutions with the aim of making privacy and good digital hygiene the default. But as we’ve seen in the preceding, for privacy to really be the default, you have to implement it in such a way as to root out the possibility of human error. With p≡p for SWIFT, we use automation to do just that.
After a turnkey installation, p≡p automatically encrypts and signs every message that you send to the SWIFT network—all without any manual intervention. Encryption keys are managed automatically with p≡p on your system, meaning that admins don’t have to worry about storing, tracking, or changing out the keys or certificates. The messages remain protected in transit, which means that confidentiality, integrity, and authenticity are assured.
Not only does this effectively halt man-in-the-middle attacks and Bangladesh Bank-style heists in their tracks—it also brings your operation into compliance with SWIFT CSP’s back-office data flow requirements overnight. If you were facing a situation similar to what happened at the Bank of Chile, no matter how distracted you were by putting out fires in the rest of your system, a fraudulent SWIFT transaction would be immediately flagged—as the hackers would have no way to mimic the encryption key signature, or even to read the encrypted message in the first place. In this way, you can protect your bank against one of the most significant attack vectors.
p≡p for email offers the same functionality for corporate communications, even automatically managing keys for your users. Non-technical employees don’t even have to know that they have encryption keys—they just have to follow the color-coded trust indicators that p≡p displays on all messages. In the same way that encryption stops SWIFT fraud, it also prevents phishing and ransomware attacks by making spoofed or inauthentic emails glaringly obvious. The end result is that your attack surface shrinks considerably, and hackers and fraudsters stop thinking of you as an easy target.