Code source for encryption and other cybersecurity software is a sticky topic for many in the information security world. In one camp, you’ll find those who champion open source software as being inherently more secure. And opposite them, you’ll see those who say proprietary is the only way to go since open source has no accountability attached to it. The broader open-source vs closed-source debate has been raging for decades, since the early days of software. Both sides have their prominent proponents and just as prominent opponents.
Banks and other financial institutions are suffering under the weight of a staggering 238% increase in cyber attacks since the beginning of the Coronavirus pandemic and ensuing lock-downs. While there are myriad reasons for this added attention from bad actors, the simple fact remains that these organizations are vulnerable due to broad attack surfaces that include numerous distinct endpoints.
Let’s say you’re a pizza delivery person showing up at someone’s home: you expect him to pay for the pie you’re delivering, but when he opens the door he claims that he never placed an order and won’t accept the delivery. If the order was placed over the phone, there’s not much you can do. Someone might have spoofed the phone number in order to perform a prank, and there’s no real way to prove who actually placed the order. Luckily, the order was actually placed via a delivery app—meaning that the recipient had to sign in to an account associated with his address and credit card. Once you pull up the app on you phone and show the nogoodnik a record of the transaction, the jig is up, and he’s forced to pay out.
SWIFT CSP’s mandatory controls get more numerous and stringent with every yearly release, and it can be difficult for even the most tech-savvy banks to keep pace. Beginning in July 2020, for instance, self-attestations will require independent audit assessments that cover at least the mandatory controls. This audit can be conducted by an internal or external team, but SWIFT seems to be pushing for (and in some instances requiring) outside assessors to help banks understand their own compliance pictures.
In a survey of several thousand IT professionals across a dozen countries, 57% of respondents said that encryption key management at their company was “painful.” In a similar study, the risk and cost associated with key management was, on average, rated a seven out of 10. Those percentages change from year to year, but as the importance of encryption becomes increasingly obvious across different sectors, the total number of businesses dealing with serious encryption key pain is only going to go up.
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.
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.
With the current world-wide coronavirus pandemic, more people are working from outside the safety of their usual secure corporate networks. This opens your company up to a whole slew of new hacks and security concerns. Fortunately, there are options when it comes to locking down access to your proprietary data and internal systems.
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.