Unpatched vulnerabilities are an everyday fact of life in many IT environments. Ransomware incidents like WannaCry serve as proof that enterprises are lagging behind patches. WannaCry managed to compromise more than 220,000 systems even though it exploited a known vulnerability. A known vulnerability that should have been fixed in most infrastructures, as Microsoft issued a patch more than two months before the infections hit.
The patching problem cannot be solved by finding more engineers to manually patch and test the applications. Although a single static application security testing (SAST) report could identify hundreds—if not thousands—of instances of each vulnerability, the process of running SAST and dynamic application security testing (DAST) tools to identify all the vulnerabilities in the software takes a considerable amount of time and effort—usually more than what organizations can afford.
Asking developers to remediate all vulnerabilities is a no-win proposition because many of these vulnerabilities are not located in the application code that they write and control. Even if organizations are willing to correct the vulnerabilities in their own code, applications can still be vulnerable as only 10 to 20 percent of the code that runs on the system is written by application developers.
Some of these components are closed source, proprietary components and the majority in most cases are open source. According to the latest study from Sonatype in 2017 52 billion Java open source components were downloaded from the Central Repository. That’s a 68 percent increase since 2016, showing a trend likely to continue growing.
That’s no surprise. Open source favors rapid innovation and fast deliveries and thus plays a central role in software development and lifecycle in general.
But that rapid innovation and fast delivery can come at a cost. Sonatype analyzed 1.8 million Java components available in the Central Repository and identified that 5.9 percent of them contained a known vulnerability. Researchers from Northeastern University analyzed data from more than 133,000 websites and reported that 37 percent include at least one library with a known vulnerability.
The solution to fixing these vulnerabilities sounds simple. Just patch the vulnerable component with a newer version. The reality is that this process can be difficult to manage and scale since more than ten thousand new component versions offering new features, bug fixes, and security patches are released daily. Security and DevSecOps teams are overburdened and often cannot easily cope with the vast number of patches that must be applied.
Despite some common misconceptions, vulnerabilities also exist in the runtime platform as well. Oracle provides quarterly fixes for the identified vulnerabilities in the Java Virtual Machine and the Java Runtime. These vulnerabilities could allow attackers to compromise the system even if the application developers write perfect and safe code in all possible ways.
Consider the latest critical patch update (CPU) provided by Oracle. July’s CPU fixed 32 vulnerabilities in Java SE, of which 28 were remotely exploitable requiring no authentication. That’s a 300 percent increase of fixed vulnerabilities compared to the April 2017 CPU. Of these vulnerabilities, 66 percent are classified as high severity. Oracle always recommends users apply the CPU as soon as possible, forcing enterprises to plan for this update ahead of time and give it the highest priority.
Not all organizations can go through this rigid and iterative process, especially since the deployment of the physical CPU requires binary changes and involves significant amounts of testing and deployment planning. Testing the patch is of paramount importance because each patch could potentially break existing application functionality.
Such a break of functionality could cause catastrophic incidents. One significant limitation of the CPU offered by JVM vendors such as Oracle and IBM is that these updates are applied in an “all or nothing” approach. If one of the fixes breaks the functionality of an application in the environment then the whole CPU must be rolled back.
Deployment planning can also be complex, since deploying the CPU requires the servers to be restarted - potentially affecting the organization’s SLAs - and each product could potentially have its own update schedule with different teams managing them, creating conflicting priorities and update windows.
Patching at enterprise scale is hard, time-consuming, resource intensive, and expensive. It is common for organizations to have patch deployment windows every 90 to 120 days or even longer resulting in an apparent conflict of priorities. Patching increases the risk of breaking existing functionality whereas not patching increases the exposure and the risk of attack.
To alleviate the pressure from the growing problem of patching, both of the following are necessary:
Active and accurate security controls that require minimum configuration able to completely remediate classes of common vulnerabilities (CWEs) or neutralizing attacks by mitigating known and zero-day exploits.
If such security controls are deployed in production, then the urgency to patch as soon as a patch becomes available is taken away and organizations no longer need to panic on every newly discovered vulnerability. However, no active security control can be deployed in production in unrestricted blocking mode if it generates false positives.
False positives are a major problem in production environments because they block legitimate requests. Stopping legitimate users from using the application is not an acceptable condition for most organizations. WAFs and other security controls that sit outside of the application use heuristic techniques such as signature patterns and behavioral detections are not adequate solutions to this problem since they generate false positives and thus become noise generators.
In a traditional approach, reducing the number of false positives requires manual tuning and configuration from expert engineers. This manual process defeats the purpose of active and accurate security controls. Security controls should not require extra configuration to be able to block zero-day exploits. The process of updating payload signatures for newly discovered zero-days is the exact opposite of what active protection means.
By moving the security controls from outside the application to inside the runtime we achieve the visibility needed to eliminate these problems. Self-protecting runtime platforms using virtualization techniques have complete visibility of all the code that is executed as well as its execution context. This allows a new category of techniques to be applied that does not depend on heuristic approaches that traditionally have been the root cause of false positives.
These runtime techniques eliminate false positives, providing the highly accurate protection that is required for active security controls in production. Additional runtime techniques such as name space layout randomization (NSLR), privilege de-escalation, and runtime compartmentalization offer the missing pieces of the puzzle for mitigating known and zero-day exploits proactively with minimum configuration.
Automated, agile and scalable patch deployment without breaking or restarting the application.
Enterprises will keep lagging behind patches and struggle to cope with the ever-increasing number of released patches unless the whole process becomes more automated and flexible. Patch management and lifecycle software is a first good step that automates the notification of new vulnerabilities in software components. However, these are applicable only before the software reaches the production environments.
While in production, patching becomes a lot harder since applying physical patches require binary changes and even recompilation of the source code. Virtual Patching is the process of applying a patch without making binary changes to the application. Runtime protection solutions based on virtualization can apply virtual patches in an agile way without the need to recompile the application or restart the application or the platform.
This greatly simplifies the process of patching, removes the urgency to prioritize the patching, and gives time to the DevSecOps and Security teams to deploy the physical patch according to their own update schedules. Finally, virtual patching allows organizations to cherry pick which patches are important to their environments and lets them roll back patches of specific CVEs that are not compatible with the existing application functionality.
Bugs and poorly coded software components—inherent aspects of the software cycle—introduce vulnerabilities waiting to be discovered and exploited and patches are the best quick fix. But because they often spawn workarounds and manual filtering, from experienced security and software engineers, false positives are still a big problem that makes the whole process much more difficult to manage. With the right methods in place, active and accurate security controls along with automated, agile and scalable patch deployment will help alleviate the stress caused by the constant need for patching.
About the Author:
John Matthew Holt is the founder and CTO of Waratek, an application security company. A JVM/JIT compiler engineer, Holt is a recognized expert in Java, virtualization and application security. He has also been an expert speaker at a number of Java technical events including Red Hat Summit, JavaOne, VMworld, Oracle OpenWorld, Jax London, NY Java SIG, and Docklands London Java Community.
