TL;DR:
- Given the sensitivity to compliance, the best vendors for financial institutions must have SOC2 Type 2 certifications, PCI DSS SAQ-D and more.
- Financial Institutions are nation-state targets for bad actors. Therefore the best security vendors for them are invested to be at the cutting edge of technical ability. Good enough is not good enough. An indicator of the right attitude to cutting edge is contribution to standards organizations like the W3C, IETF and TC39.
- Security is layering: a vendor that offers a multi-layer security model helps companies remain safe when bad actors attempt to build bypasses for security layers.
- Conclusion: the best solution for Financial Institutions is cside’s multi-layer approach.
Why are Financial Institutions classified as a nation-state target?
Some bad actors don’t just look to make a quick buck. They can be state sponsored, incentivized to wreak havoc. Destabilize essential services required to run economies.
Financial Institutions are a prime target and with their size and exposure comes additional risk and therefore opportunity for the bad actors. When banks go down, so does the economy.
Financial Institutions are in the same realm as Government IT environments, large scale healthcare providers and critical infrastructure like public transport and energy providers.
To build credibility in the Financial sector brands go through a significant multi-year process to obtain trust of customers across various types. With that comes significant technical debt through legacy applications.
Vast and legacy infrastructure increases attack surface
It’s not an industry secret that many of the large Financial Institutions still run on COBOL. A research paper by a member of the technical staff at PayPal states the problem very clearly: “Traditional banking infrastructure is often outdated and struggles to meet the increasing demands for seamless, real-time digital services.”
Meaning legacy web applications are often layered by more modern technologies increasing the attack surface in order to ship new user experiences. By leveraging vulnerable back-ends to inject client-side scripts or targeting legacy dependencies to infiltrate the supply-chain, bad actors can cause severe harm to global economies.
Client-side attacks target specific assets
Client-side attacks against Financial Institutions usually target:
- User-credentials and session tokens to gain access to accounts
- Payment card information
- Bank statements and sensitive identity information
Strict Regulatory and Compliance Requirements
Financial Institutions are subject to a substantial list of compliance frameworks in order to operate, their banking license depends on compliance.This ranges from complying with PCI DSS, DORA, local privacy laws like CCPA or GDPR and as a sign of trust but often a requirement for business customers: SOC2 Type 2, ISO 27001…
What approach is best for Financial Institutions?
Given the gravity of the target, there is little room for error. So a good solution must fit the application like a glove.
Therefore a layer approach is ideal. Especially if the solution in question is customizable and creates transparency and control where there was lacking control before.
That is why we built cside as a platform leveraging all the different layers available to date.
Leveraging 3 automated but also independently configurable layers of client-side monitoring layers and multiple detection engines including open source Large Language Models for detections.
- Layer 1: monitoring behaviours client-side. Many solutions in this space solely rely on client-side detections, and it is indeed one of the most effective methods out there. The only real problem with this approach is that detection capabilities to an extent are exposed and that data on missed attacks is limited. Making an easy sandbox environment for a bad actor. Cside protects APIs to prevent such bypasses, but unlike modern operating systems, browsers are not built for security.
- Layer 2: async script and page fetching to verify outside-in whether the script is correctly implemented and a few extra edge cases that are not exposed to scripts in browsers like HTTP headers.
- Layer 3: the Gatekeeper. Cside has a feature that allows you to pass a script through their edge engine. This edge engine is not susceptible to the same exposure the client-side layer has. With the Gatekeeper browser limitations are no longer blockers as cside is, effectively as conduit, serving the script. Meaning it can keep a copy and dig into missed attacks later to improve detections.
We even offer a Content Security Policy endpoint as well so that customers can leverage browser native approaches, JavaScript, the Gatekeeper technology and more. A bank, insurance provider or crypto platform simply can’t take the risk.
Security requires a multi-layer model
Most security tools rely on only one of the above mentioned layers, either runtime or out-side in scanning. But the problem is that none of these layers on its own is fully bulletproof and therefore fails to provide comprehensive cover. By combining engines you get closer and closer to full coverage.
Many solutions in the market are side features of larger web security companies. Instead of building a platform for client-side security, they built a tiny side feature. These solutions are constrained by the focus of the business. Often client-side is an area they are unwilling to invest substantial resources in and therefore rely solely on injecting Content Security Policies into the website through their WAF.
Some solutions are effectively just scanners. Bad actors see the scanners and don’t serve the malicious scripts to their point in time check. Given the value of the target, this approach is ineffective.
For compliance purposes it's convenient that the solution offers dashboards specifically to address each framework. Frameworks come with a range of unique controls and manually collecting that data is a painful continuous chore.
Some approaches, like scanner based solutions have been found to be commonly bypassed by bad actors. They detect the scanner and serve clean contents to the scanner to fly below the radar. Researchers at ISACA, University of Brighton, Google and Oracle have flagged that dynamic client-side scripts effectively bypass Static Analysis by scanners.
Cside is always looking to extend its capabilities and is actively pushing a number of new standards that would enable stronger client-side security using native browser functionality.
The cside team are active contributors to standard bodies like the W3C, IETF, and TC39.
