A virtual patching solution for the finance industry
A development company needs to protect its management systems operating in the financial industry, without interfering with the application operations or changing the code.
INDUSTRY: Financial Services
The financial industry is one of sectors most affected by cyber-attacks: payment services and processed transactions are sensitive data that in case of data breach or loss might cause serious troubles.
In fact, financial platforms contain a lot of sensitive information, such as debit / credit card numbers and account holders’ pins. These are very c targets for cybercriminals, who have the opportunity to use and sell stolen financial information in the Dark Web market.
Back-end systems of the banking and financial sector are often been setup several decades ago with technologies that are no longer in use, and therefore today is very difficult to apply any change. Securing that kind of systems has created the possibility to adopt “Virtual patching” solutions.
A virtual paching solutions allow you to apply an adequate level of protection without the need to modify a single line of code of the service you want to protect.
WHAT MITRHIL SOLVES:
Mithril allowed the customer to protect a vulnerable application by applying a Virtual Patching solution.
The Mithril team first conducted a Penetration Test on the client’s application, detecting different types of vulnerabilities that could actually be exploited. In this context for the customer, it was impossible to make changes to the operational systems, not even to apply the recommended security patches. The solution offered by Mithril was to place the Web Application Firewall before the application services, with a simple change to the DNS. By intercepting the traffic before the application, Mithril offered an optimal virtual patching solution, offering the maximum level of protection to the customer.
Given the sensitive nature of the data used by the platform, the customer decided to activate a specific Mithril module to check whether the users are authorized to access the service using a secure and not compromised passwords. In fact, this module anonymously intercepts the login passwords (without storing them and making them not readable in any way by the Mithril Team), checking that those credentials are not available in the main data breaches. If a password is found in any known data leakage, a notification is automatically sent to the user and administrators, allowing you to update the compromised passwords and authenticate in a secure and controlled way.
Before the Mithril Team activity, the customer’s site presented various security problems deriving from an incorrect configuration of the Security Headers. The importance of security headers is to increase the security of site users directly on their browser. The correct configuration of these response headers guarantees a first layer of protection against problems such as: Cross-Site Scripting, Man in The Middle, Information Leakage, etc …
Through the site https://securityheaders.com/, created by security researcher Scott Helme, it is possible to check the configuration status of any site by receiving a grade that can go from F to A +. Before our setup, the customer site got a D score, due to a lot of unconfigured headers.
As a result of the configuration and with the services offered by Mithril, the customer’s site obtained an A score, without having to change the server configuration or the site’s source code.
WHY RELY ON MITRHIL:
Mithril is a Web Application firewall as a Service that protects websites and web application by placing itself between the user and the customer’s web server.
In order to route the traffic to the client’s websites and web applications through Mithril WAF, only a simple change to the DNS zone is required.
When the Mithril protection is on, it offers a Rule Set dedicated to the main CMS (e.g. WordPress) which allows to detect and block:
- brute-force attacks,
- user enumeration
- failed login alerts
- prevent access to unused and default functions such as API, XMLRPC, etc…
Here below you can find an example of the detected and blocked attacks on the Customer’s site, including suspicious Scanning tools activities and requests for files with not allowed extensions, usually performed in the information gathering phases of a cyber-attack.