Enter RASP and AppSecurity for Java
Vice President Global Technology Operations writes:
The security alert for a critical vulnerability (in this instance the CVSS Base Score was 7.5) in the Java Apache Commons library (CVE-2015-4852) published on the 10th of November 2015 came just a few weeks after John Matthew Holt, CTO of Waratek, co-hosted “The Future of Java in Bank” event with myself. The timing was, with hindsight, portentous as John pointed out the historical frequency of critical Java vulnerabilities in Open Source libraries that are prevalent, if not ubiquitous, in any enterprise which utilises Java; and I don’t know many that don’t, at least in the financial and telecoms sectors.
In our presentation we highlighted our success in deploying the Waratek Java Virtual Machine (JVM) with AppSecurity for Java into production, earlier in the summer of 2015, for our Apache Tomcat users. We conveyed, to the global audience,how simple, general security rules defined in AppSecurity for Java would mitigate the most pernicious security vulnerabilities that exploit Command Injection, SQL Injection and Cross Site Scripting among others.
As soon as we became aware CVE-2015-4852 we assessed the security risk posed to our Java applications and initiated the standard response of patching vulnerable applications. I’m sure the processes that we follow are extremely familiar to every enterprise user of Java.
Given the prevalence of the Apache Commons library it soon became clear that vulnerability, by virtue of dependency, was present in Oracle WebLogic Server (and a raft of other Fusion Middleware from Oracle), Red Hat JBoss and IBM WebShpere, Apache Tomcat and not just in our proprietary applications. The rush to patch was costly, not merely in terms of the resources that needed to be marshalled and the time that had to be reallocated to patching, but also in terms of the lost opportunity cost due to the disruption application development.
However, there was a platinum lining to this particular storm cloud. Once we completed our assessment of the vulnerability we concluded that those applications running on Tomcat with Waratek’s AppSecurity for Java were protected, they did not need to be patched. This, in and of itself, may not be considered particularly revolutionary, however once one realises that the single rule that mitigated the worst effects of CVE-2015-4852 also protected against the recent vulnerability in Apache Struts (CVE-2013-2251) one can begin to grasp the power this technology. Imagine all of our Java estate was running on Waratek’s JVM and enabled AppSecurity for Java, the benefits in terms of quality of protection, risk reduction and reduced cost of security should be becoming clearer.
Read the rest of the blog post here.