Starting this month, Java 8 users will have to make a choice. Pay a minimum of $40 for support and security updates or continue to use Java 8 with no security updates or fixes. Users will also not have access to a number of APIs like Java Web Start and Java Applets which will be removed in the upcoming versions. Which again means – stay on Java 8 or potentially refactor your apps to work without these APIs. Either ways, no security updates till you pay for them.
Oracle is moving towards a more Ubuntu like Long-Term-Support (LTS) model for its version instead of endlessly supporting older releases. Thankfully, Java 8 is on the LTS path for the near future. Java 9 and 10 have already ended their free public update period and will be end of life pretty soon. Java 11 released in September this year will be the next LTS release.
Greenfield developments using newest versions of Java are getting rarer as most legacy applications don’t care for the APIs/features in the latest releases. The only reasons for upgrade are usually security issues and available patches. So it makes sense to align with the LTS versions of Java as the intermediate versions will present ongoing compatibility nightmares without really providing any features that legacy apps might find useful. Oracle is also getting increasingly aggressive about enforcing its license terms so there is really no way of getting around the paywall if you are using Java commercially.
Essentially Oracle is now selling security fixes for a platform that is still very prevalent in enterprise software. This is quite unprecedented and may result in some really bad unintended consequences. Consider this, after January 2019 when Java 8 transitions to paid support for commercial use, each subsequent release will contain fixes that may be reverse engineered to potentially attack customers who are still on the older releases. This means that if your business happens to be on the wrong side of the release cycle and is not patched with the latest security patches, you are a potential target. Any customers who hesitate in applying security fixes fearing hidden costs or legal issues are also opening themselves up as targets for hackers. As this inevitable transition happens in 2019 and beyond, there will be a large number of un-patched java installations all over the world, making it open season for Java hackers around the world. This is the sad but unfortunate truth of a historically free technology which suddenly requires paid licensing for continued support.
So what do we do? Apart from the hard decisions that businesses will have to make for aligning themselves with the Java LTS releases and rebuilding parts of their applications which will no longer be supported, there are some even more critical decisions to be made to secure Java deployments through this transition. There are lots of choices in reactive security solutions to look for trouble when it comes knocking. However a more proactive approach to addressing Java security will eliminate much of the risk.
First a complete understanding of your Java based attack surface is needed. Java has a huge ecosystem of open source libraries and services enabling rapid application development but it also contributes to a very fragmented attack surface. The platform itself is not free of vulnerabilities and is constantly under scrutiny by attackers for weaknesses. A thorough understanding of your Java ‘stack’ goes a long way in securing it.
Second, a proactive service to keep track of latest patches available for the Java platform whether they come from Oracle or other vendors has to be in place. This will atleast give you a headstart in terms of being on top of the most recent and critical issues being fixed. A (preferably) automated patching program which keeps your Java deployment up-to-date would be a bonus.
Lastly, Java vulnerabilities need to be monitored and tracked proactively as they are discovered in the wild and as they evolve. Attack profiles, exploits, remediations published in the opensource world across the web need to be watched. This active vulnerability intel needs to be then correlated with your Java attack surface to identify which assets or services might be impacted. AI and machine learning can be used very effectively to perform this correlation. The traditional endpoint or application scanning will be too slow in this case. This has to be continuous and real-time process.
Ultimately this has to be a comprehensive solution which accomplishes all-aspect proactive security from detection of vulnerabilities to patching with as much automation as possible. As the era of “free” Java comes to an end, it is time to invest in a security solution that protects your Java deployments into the future.