Oracle releases a collection of security fixes for their products on every Tuesday closest to the 17th day of January, April, July, and October. These fixes are known as a Critical Patch Update (CPU), and are typically cumulative and address security vulnerabilities associated with Oracle products. April’s update, with fixes for 299 vulnerabilities across Oracle’s platform, was its largest CPU to date.
With the next CPU landing on July 18, there’s plenty to consider.
The database and cloud computing giant sees its software used for vital operations by most of the Fortune 500. The Java-based open source software is used in mission-critical environments across the globe and on more than 15 billion devices.
April’s Oracle CPU contained patches for core components of Java products, many of them linked to commonly used third party software that is standard among large financial services firms, healthcare providers and transportation companies. These sectors are constantly under attack from malicious hackers, making it of utmost importance to apply the most recent security patches as soon possible – a task that can take even the most sophisticated organization months to complete.
With these releases, we have one of the largest software vendors in the world, with expert security resources and dedicated testing and remediation teams, belatedly discovering and responding to the presence of major, known-vulnerable components buried deep in the software stacks of their core software platforms.
To put things in perspective, Oracle finds a new flaw in their products every 100 hours. Some of the flaws included in the most recent CPU date back to 2012. Now, to be fair, every software developer releases the equivalent of the Oracle CPU. However, Oracle’s market share makes it the bellwether of the entire industry.
That’s five years of an open, unpatched vulnerability. Among the others are more than thirty Java-related Common Vulnerabilities and Exposures (CVEs), eight of which directly affect the core Java platform. Nearly 70% of the Java-related CVEs are remotely exploitable without authentication.
Addressing years-old vulnerabilities in current patches is proof that we’re approaching a crisis point where our ability to respond in a timely and effective manner is at risk. We continue to rely primarily on traditional approaches that can’t keep up with the pace and volume of vulnerabilities. That’s not a sustainable model. This should mean so much to so many organizations due to the ubiquity of third party software. In a recent report on more than a thousand commercial web applications, 96% included third party code. Of that, 67% had known vulnerabilities with 52% being high severity vulnerabilities.
Open source components are not automatically or routinely patched and it’s a challenge to keep up with vulnerabilities that require frequent patching. Unlike software from major developers where patches are sent on a schedule, open source code in libraries and central repositories normally require a user to seek a patch or develop their own.
Fortunately, proven technology exists to help alleviate the massive scope of these security updates. Many companies offer solutions that approach application monitoring in a new way, along with protection using a secure virtual container in server and cloud environments. Third party options offer approaches that behave like a patch without making code changes or affecting runtime speed, blocking attacks because it operates more deeply in the software, monitoring network packets, files system calls and CPU instructions.
The April CPU showed the scale of the challenge that the IT industry faces in securing modern modular enterprise applications that are composed of dozens or sometimes hundreds of third-party libraries and modules. Here’s something to think about next month: If a top vendor like Oracle struggles to account for and secure their third-party library dependencies in a major software platform like Oracle Fusion, then how can an “ordinary” enterprise that is not a sophisticated IT vendor be expected to do any better?
The fact that we’re still addressing vulnerabilities associated with Struts v1 and Apache Commons years after the issues were first raised is both surprising and troubling. The Struts 2 patch is less surprising because it was first announced in March 2017, but still no less troubling as it points to the continuing issues associated with third party software components.
An average of ten new open source flaws are reported every day. But the ability to find these problems isn’t the issue. It’s fixing them. Oracle’s security team is doing the best it can, but like all cybersecurity teams, they struggle to keep up with the constant waves of vulnerabilities that are being discovered.
Every effective cybersecurity approach developed over the past two decades is fully integrated into the way businesses protect themselves today. The massive scale of vulnerabilities and ubiquity of software flaws, though, means that the measures we’ve relied upon for twenty-plus years are now unable to provide the level of protection required going forward.
Diligent system maintenance, consistent patching, and both automated and manual third-party security solutions are all necessary for end-users to be fully protected.
About the author: James Lee is the Executive Vice President and Chief Marketing Officer at Waratek, a pioneer in the next generation of application security solutions.
This article appeared in Infosec Island
