Posted 1 year, 2 months ago
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.
The attacks seen in the first half of 2020 are not only increasing in frequency, but the severity and intensity are unheard of. New and unique tactics are being invented every day by hackers around the world, leaving banks’ security teams scrambling to close all the backdoors and exploits being discovered. Making the situation all the more dire is the fact that many of these exploits are not within the banks’ systems per se--rather the attackers are finding and exploiting a weak point in the global supply chain, for example, then making their way from suppliers’ systems upstream into the banks from there.
On top of the confusion these attacks are causing, banks have to grapple with the fact that many internal users don’t have a comprehensive understanding of security and the part they play in it. This leads to messy encryption implementations rolled with a sort of hodgepodge of different tactics and technologies. Financial messages flow back and forth all day between endpoints within the corporate network, generally unencrypted due to a belief that any intrusion into this network would be spotted in time to prevent that data from being compromised. In reality, even modern networks are not spared from backdoors waiting to be exploited via a social engineering hack or account compromise, rendering this a dangerous situation all around. But what can you do about it? Let’s start by looking at why these new attacks are focused on banks in the first place.
To address the obvious starting point, banks are literally made of money. If you were a hacker looking for a payday, what better place to set your sights than an institution whose sole purpose is to store and transfer money? The second reason is related to that second factor, the transmission of messages containing financial data. These messages travel back and forth, in and out of banks and other institutions, from banks to the SWIFT network, and crucially—they also travel within the corporate network of each individual bank.
It’s this multitude of potential attack vectors that help make the average bank a very attractive target for hackers. With the widespread uncertainty accompanying the global pandemic, banks have been left open to the hacker’s best friend—the man-in-the-middle attack. The MitM attack consists of an attacker infiltrating a network with the intent of intercepting and manipulating the contents of messages traveling across it. This can result in banks processing requests based on manipulated data being received, which in a worst-case scenario could rival the scale of 2016’s Bangladesh Bank heist.
Whether they begin with a standard phishing email sent to customers, a MitM attack that targets messages in transit between the bank and SWIFT, or social engineering designed to gain access to a bank’s back-office systems, the end result is the same. In order to head off theft of confidential data or property, banks need to choose the right option for ensuring the security of financial messages. The choices? Doubling down on existing security measures like PKIs, or pivoting to automated, end-to-end encryption at the application layer.
Chances are good that you already have some sort of security scheme in place. Everything from training internal users how to spot social engineering requests to locking down customers’ device access. There are so many potential attack vectors, limiting your exposure will take some work.
Bank IT teams are managing more devices and applications than ever across back offices that are more complex than ever, and that presents a problem. Or rather, a whole bunch of problems—all of those endpoints sending and receiving sensitive financial messages. Every endpoint that touches the SWIFT network, for instance, acts as a potential attack vector that your security needs to lock down.
The days when up-to-date anti-virus software was enough to ensure security on workstations are gone. Multiply this by the number of laptops in your environment, then add in each employee’s personal devices used to check email while at home and you can see how the potential can multiply exponentially.
With the specter of the Bangladesh heist still hanging over the financial industry, concerns over the security of messages leaving your institution and traveling around the world are also elevated. PKIs can only do so much when the messages themselves can be readily intercepted and read or modified.
Public key infrastructures represent an amalgam of servers, databases, and management consoles that can be spread across multiple sites as well as the cloud. This makes it difficult to know who is responsible for what aspect of security. You’re going to need to audit access records on a regular basis to ensure accounts are being used properly and that key, trust, and identity databases are consistently up-to-date.
Chances are, you’re going to find confusion over key storage locations, unmaintained identity databases with old records, etc. With a segmented security model, it’s easy for manual tasks like key swaps and updating identity databases when things change (new partner organization, a user leaves the bank, etc.) to be missed. Security measures like a PKI don’t always integrate into existing back-end systems, leaving even more tasks to be completed manually.
What you may find is that many of these potential attack vectors can be eliminated by replacing the multi-layer model with an encryption solution that works on the application layer instead. By locking down messaging at this high level, you no longer need to be as concerned with transport layer security, etc.
End-to-end (E2E) encryption like that offered by p≡p does just that, it works on the application layer, rendering encryption at other layers redundant and simplifying your security scheme significantly. Since the messages containing sensitive financial data are encrypted at the origin endpoint, and not decrypted until they arrive at the destination endpoint, there is no longer a need for encryption that operates at the transport layers (MQ, TLS, etc).
The P2P model also eliminates the need for centralized infrastructure. This enables fast deployment, simplified workflows, and less overhead costs for maintenance and support. Additionally, key, trust, and identity management can all be automated--further reducing the resources needed to successfully ensure the security of your financial messaging. In this scenario, all of your messages are covered across the entire back-office ecosystem, meaning that nothing can be sent, altered, or tampered with without your knowledge.
Eliminating the need for additional infrastructure and a centralized management console takes a load off your network and your staff. There’s no PKI, no database server, and no key repository (e.g. key escrow servers). Those functions are now automated and take place at the application level on each protected device. All of that saves hardware costs, recurring software licensing fees, maintenance, and support costs. Plus, automation means workflows and existing business processes are unchanged, so a majority of your back-office users won’t notice the security measures unless they flag a potential issue.
Since each message is encrypted on the sending device and decrypted on the receiving one, there are no additional hops necessary to accomplish this crucial task. And by removing the hardware and software previously used for this, more messages can make their way to their destinations with less latency. This seamless integration with your existing back-office infrastructure also means no need for added bandwidth or cloud storage for databases, etc. saving you even more on the back end.
Workflows are essentially uninterrupted with E2E encryption. Once install is complete, each user goes about their day as they did under the PKI model. Only now they don’t have to deal with expired keys, disrupted connections to the key server, or crashes due to the sheer volume of messages needing to be encrypted. And since every message is encrypted by default, they also don’t have to worry about the security of the data within, no matter where it’s being sent.
That lack of disruption means workflows continue unhindered, with the end result being elevated productivity. And if you’re worried about regulatory compliance, read-only keys allow regulators to read dataflows and ensure compliance without exposing any of the data within.
Whether you’re trying to bolster your existing security in a way that will save costs and increase efficiency, or you’re starting from scratch or are looking at a full systems upgrade to get things to this level, a true end-to-end encryption solution like p≡p provides the only comprehensive option. You’ll save time, energy, and, crucially, money by reducing the footprint of your encryption scheme, and your organization will reap the benefits in improved productivity while your cyber security sees a boost in efficiency and effectiveness.