How A Major Bank Hacked Its Java Security

Deutsche Bank London helped create a new application self-defense tool to lock down and virtually patch its Java-based enterprise applications -- even the oldest ones.

Deutsche Bank AG London has what many large enterprises have: numerous internal applications based on various versions of Java, many of which are older and cant be patched nor updated. So the bank helped develop a tool that sits below the application to detect and prevent attacks and apply virtual patches.
The bank, a subsidiary of Deutsche Bank AG, made the move after it inventoried its hundreds of internal applications and discovered a mix of old and new versions of Java, some of which were legacy applications that had become increasingly difficult to patch or update. Oracles Java infamously has been riddled with security vulnerabilities, and Java client machines have become a favorite target of attackers.
We [had] uncovered a large degree of variance of Java deployed in the banks infrastructure, Hussein Badakhchani, vice president of Deutsche Bank London, says in an exclusive interview with Dark Reading today. His application group teamed up with IT security to determine how to secure the large number of legacy Java applications running at the bank.
The initial goal was to convert its applications -- everything from payments to training apps -- to a new platform-as-a-service the bank had built based on Java Virtual Machine (JVM). We wanted to move away from DIY to a managed service for enterprise applications. The question becomes If you cant decommission an application and you cant operate it [or update its Java version], what can you do with it?
The bank worked with security vendor Waratek to create
a tool
that runs within JVM and efficiently secures legacy Java applications. Call it application self-defense: The result was a software solution that uses what Gartner analyst Joseph Feiman calls a self-protecting application approach, or Runtime Application Self Protection (RASP). According to Feiman, RASP detects and blocks attacks, and it operates in the applications runtime environment.
Modern security fails to test and protect all apps. Therefore, apps must be capable of security self-testing, self-diagnostics and self-protection, he writes in a new
Gartner Maverick Research
report on RASP. Gartner predicts that 25% of web and cloud applications will become self-protecting by 2020; fewer than 1% operate that way today.
Its a natural fit, according to security expert Dan Kaminsky. The JVM -- and CLR [Common Language Runtime] and even the various JS [JavaScript] engines -- are designed to detect many errors. Why not instrument them for security and see what comes up? Kaminsky says. Over time, the languages and platforms we use increasingly support securing the applications we write on top of them. More importantly, the cost of that security diminishes as the platform shoulders more of the burden.
Kaminsky, chief scientist at WhiteOps, says its not so much about Javas security problems as it is about looking at a way to apply security to multiple different applications, at scale.
Traditional WAFs [web application firewalls] can often be somewhat distant from the platforms theyre securing says Kaminsky, who also serves as a technical adviser to Prevoty, a competitor to Waratek in the RASP space. What if there was deeper integration? What if the WAF didnt have to guess what the end application saw, what if it could ask… or if it was alerted in case of problems?
Deutsche Bank London had battled the headache of off-cycle patching for zero-day vulnerabilities that occur outside its orchestrated, regular quarterly patching cycles. Problems arise from unscheduled patching events for zero-day exploits, Badakhchani says.
The new RASP approach provides virtual patching to the banks Java-based applications, so the bank doesnt have to deal with out-of-band patching. Even the regular patching cycle can be disruptive. To try to remedy every vulnerability, when you have 600 business applications, the amount of work you need to do in standard patching is extremely expensive. It involves, among other things, hiring teams of developers to decode patches.
It works like this: An attack that attempts to exploit or employ a Java process, such as a SQL injection attempt, cannot execute. If an attack gets past our security, for example, and tries to make a call to a Java process, it wont be allowed to. Well be alerted to an intrusion, he says. The tool can detect known and unknown attacks.
Its [like] placing a firewall within the application in the JVM itself, Badakhchani says.
Like any security layer, theres a convenience or performance tradeoff. He says the RASP tool comes with a performance tradeoff in about 10% of the banks applications. Its not that significant… The benefits from the security side outweigh that, he says.
Badakhchani, along with Waratek director of client security solutions Prateep Bandharangshi, will
present their work today at the Oracle JavaOne conference
in San Francisco.

Last News
▸ Veritabile Defecte de Proiectare a Securitatii in Software -> Top 10 Software Security Design Flaws ◂ Discovered: 23/12/2024 Category: security	▸ Sony, XBox Targeted by DDoS Attacks, Hacktivist Threats ◂ Discovered: 23/12/2024 Category: security	▸ There are plenty of online tools for reporting bugs. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
How A Major Bank Hacked Its Java Security