Posted 1 year, 10 months ago
Instances of cyber-attacks on banks and other financial institutions are on the rise. This may come as no surprise to you, but did you know that during the Covid-19 pandemic, these attacks have spiked an incredible 238%? That’s according to a report from VMWare’s Carbon Black cloud division. The same report states that over ¼ of all cyber-attacks this year have targeted either financial or healthcare institutions. What are you doing to ensure the privacy and security of your financial information?
For banks, the largest attack surface is one that many don’t consider when looking for security solutions—the back office. Because it lies inside the corporate firewall many assume, incorrectly, that the data they’re sending back and forth between internal endpoints is secure. For that reason, many encryption solutions lie at transition points, like that firewall or another hardware security module (HSM) in a similar position of intercepting all outgoing communications for encryption before it leaves the network.
Banks and other financial institutions send a wide variety of messages throughout their workflows, from securities and payments to forex and card services. These messages flow constantly in, out, and crucially, within these institutional networks. The result is that there are numerous points in transit where a message could be read, altered, or tampered with. The solution to this conundrum? End-to-end (E2E) encryption that works on the application level. This eliminates the need for redundant HSMs and ensures that no matter where the message is going, it’s encrypted for its entire voyage, since decryption is handled by the receiving endpoint.
Currently, the industry standard is TLS encryption. Transport Layer Security, or TLS, is the most prevalent form of communication security on the internet today. When you visit a website and see the little lock icon in the address bar, right before the URL, that indicates that the site is using a TLS protocol to encrypt any data sent between your computer and their servers.
TLS is an IETF standard, making it the industry standard for not only websites, but many SMS/IM tools, email systems, video conferencing systems, and VOIP networks. The ubiquity this affords TLS also makes it a frequent target for broad-scale hacks and other attacks, many of which result in large, high-profile data breaches.
For banks and financial institutions that opt for these kinds of back-office security deployments, there are three independent pieces of the security puzzle to address: endpoints, HSMs, and PKIs (private key infrastructures). The latter is responsible for managing the keys and protocols that do the actual encryption and decryption of your data, and they comprise multiple subsystems. We'll address this in depth a little later on.
Gone are the days when up-to-date anti-virus was all you needed to keep workstations running and free of intrusion. Today, security teams are often managing numerous endpoints, including but not limited to workstations, laptops, mobile devices, SWIFT network gateways, and trading gateways. Add in bank customers who use any one of a variety of devices to access their personal account information daily and the potential threat vectors multiple exponentially.
All of those variables require multivariate testing sandboxes, user behavior analysis to prevent social engineering attacks, and ongoing training for everyone who deals with financial messages anywhere across the back-office ecosystem--and that’s just for starters. Your security team also needs to keep tabs on the latest attack vectors and intrusion methods in order to keep endpoints secure, keep tabs on multiple different layers of security, and establish procedures for when the inevitable intrusion is detected. Especially In a financial setting, evolving threat models aren’t something you can afford to be lax about.
The proliferation of mobile devices and their increasing ability to handle most people’s computing needs has brought with it a growing understanding that firewalls aren’t serving their intended purpose anymore. Such hardware security modules are fast being outpaced by scammers and fraudsters finding new ways around, over, under, or through their protective boundary. Add to that the power of social engineering and the part it plays in a majority of breaches and you can see that it’s time for a new security paradigm for your financial data.
PKI is, by definition, a security procedure. But how do you ensure your key infrastructure remains private? Most often, by dedicating a team of IT specialists to manage identities, take care of key swaps, and generally oversee the PKI and its HSM perimeter. This support and maintenance is expensive, often prohibitively so.
The PKI-based model on which most banks rely offers a complex structure for protecting messages at the transport layer, which can help prevent attacks--but what this model doesn’t offer is true end-to-end protection for all of your financial messaging. As a result, these kinds of security environments are difficult to install, run, and maintain. They require security at multiple levels and different locations throughout the network, along with the staff and budget to maintain a host of different infrastructure elements.
With the army of specialized staff needed to efficiently run a PKI and maintain HSMs, the costs of the model we’ve been describing can escalate quickly. In addition to the salaries needed, there’s emergency maintenance when hardware fails and work grinds to a halt.
Then there are the multiple attack vectors inherent to a multi-layer model like this. When a vulnerability is discovered in a commercial PKI, no matter how much customization was done, your bank will be open to attack and at the mercy of third-party developers to close the backdoor before malicious actors make their way in.
Next, there’s the endemic confusion that accompanies any complex technological deployment. Even your most tech-savvy back-office staffer is at the mercy of a TLS encryption scheme that goes down or a private key that expires when they don’t have access to generate a new one or extend the old one. The result of this confusion is that workflows slam to a standstill, efficiency suffers, and productivity goes out the window. Entire back offices relying on this many-layered approach to security have multiple points of failure that can derail projects and send daily tasks into a downward spiral, fast. Simply put, transport-layer encryption is not the easiest way to get complete coverage of your messages across the entire back-office environment.
Unlike your typical PKI deployment, E2E and P2P encryption solutions like p≡p work at the application layer. That means each and every message sent by a protected endpoint is encrypted before it leaves that device. The message then travels by whatever means available to its destination endpoint, where it is only then decrypted. This model leaves zero chance of a message being manipulated in transit, whereas with segmented security, a man in the middle (MitM) attack can crop up at multiple points as financial messages move between different layers. These attacks can begin as social engineering or via account compromise. However they begin, the end result is internal messages being intercepted and manipulated without your knowledge.
By eliminating the need for complicated TLS schemes and multiple HSMs, automated, decentralized, application-layer encryption can power immediate cost savings--which will, in turn, help win you converts to this model. The fact that a solution like p≡p can be deployed iteratively means that for each win you score, you can quickly and efficiently deploy to the next team, department, or site.
Because p≡p’s solution allows encryption and decryption to occur at the relevant endpoints, there is no need for a centralized infrastructure. And that means there is no need for complicated user training or downtime while integrations are implemented. More than that, it means that there’s no need for PKI servers and all of the complexity that comes with them. Because the encryption is happening on the application layer (i.e. the top layer), there’s no reason to worry about what’s happening on lower layers where the process of implementing encryption protections can be more difficult or cumbersome.
p≡p uses opportunistic encryption where possible. This means that once installed, all messages will be encrypted as long as the receiving device is trusted. If not trusted, the message will still be sent, just without encryption so it can still be read upon receipt. This model ensures that workflows continue without interruption.
One of the key differentiators of the p≡p solution is its automation capabilities. Rather than managing keys, encryption, and decryption by hand, p≡p automates the entire process end-to-end. This means that operations across your back office remain essentially unchanged. With its dispersed model that lacks a centralized key management server or database, each install is discrete and runs its own internal database for keys, identities, and trust relationships. Keys are short-lived, which increases security while lightening the load on users because there’s nothing for them to do, it’s all automated.
A major benefit of this model for banking communications is that every message is encrypted, including internal messaging. In the event of a breach, MitM attack, or account compromise, your messages are still beyond the hacker’s reach as they’re encrypted even within your network.
This model brings the additional plus of being easily scalable. Since there are zero centralized systems needed, all you have to do to scale is install p≡p on additional endpoints. No servers to upgrade, no bandwidth to adjust up, and no additional staff to hire to manage it all.
Banking comes with a hefty dose of rules, regulations, and governing bodies you have to answer to. One of these is the SWIFT network, which recently increased security requirements for all institutions connected to their network. p≡p has your back with read-only keys (documented front door access) for regulatory monitoring. These keys give access to your message flow, without unlocking the encryption on those messages, ensuring the safety and security of every piece of data you send. A debugging key is also available, giving your developers read access to the dataflows for debugging purposes, still without exposing any of the sensitive information contained within.
Additionally, the p≡p “safe zone” that is created when the p≡p engine and connectors are installed provides your entire back office with a security perimeter. Perfect forward security, traceability and the elimination of HSMs makes token management a breeze. Add in the read-only keys referenced above and you’re well on your way to meeting or exceeding the current CSP regulations.
In the end, what does switching to an automated, E2E, P2P model like p≡p really get you? Massive cost savings, simplified systems, and stronger security for your financial messages. Rather than dealing with the difficulties and complexities of a full-scale PKI deployment on the transport layer, you can enjoy message protections that seamlessly cover your entire back-office ecosystem without causing any disruptive changes to your existing workflows. Not only does this result in a big win from a cost saving perspective, the streamlined nature of the system actually improves the efficiency of your operations.