Most software has bugs. Code is written by humans, and since humans aren’t perfect, they make mistakes. As a result, software doesn’t always work correctly. In some cases, these bugs are just errors in how the software functions and have little or no impact.
The impact of other bugs can be much more significant. Some bugs can be exploited by an attacker to force the application to take unexpected and undesirable behavior. The impact of these vulnerabilities can range from a Denial of Service (DoS) attack that causes an application to crash to ones that allow exfiltration of sensitive data or unauthorized access to user accounts.
Patching vulnerable software in production environments is important for application security. Even if an organization’s own product is not vulnerable, operating in an environment with unpatched vulnerable software can leave it open to attack. However, keeping an organization’s environment patched can be more difficult than it sounds.
The Software Patching Process
Keeping an organization’s software secure against attack through patching requires a complex process with many moving parts. If anything goes wrong in the process, the software remains vulnerable.
The first stage in the process is discovery and disclosure. If a vulnerability hasn’t been discovered yet, it can’t be patched. If a vulnerability is publicly disclosed before a patch is available, cybercriminals can take advantage of the gap before patch availability to exploit it. Only if a vulnerability is kept secret until a patch is available are organizations protected against attack.
In order for an organization to apply a patch, the patch needs to exist, and organizations need to know that it is available. Of the more than 22,000 new vulnerabilities discovered in 2018, 27.1% of them have no solution available. Of that same 22,000 vulnerabilities, 31% of them are not published in the Common Vulnerability Enumeration/National Vulnerability Database (CVE/NVD). Since this a common place where organizations look to see if they have anything that needs patching, they may miss the existence of 31% of vulnerabilities.
Finally, patching a vulnerability requires an organization to actually apply the patch. This can be a complicated process including testing the patch to determine if it breaks anything on an organization’s systems, rolling it out to affected machines, and testing to determine if the patch was successfully applied. The sheer number of new software vulnerabilities in existence makes it difficult for organizations to accomplish this for every applicable vulnerability.
Organizations Can’t Keep Up
The importance of patching vulnerabilities is an organization’s systems is widely acknowledged. In fact, a recent survey found that 91% of organizations state that maintaining a compliant security configuration is “very” important. However, the sheer number of vulnerabilities that exist in software make keeping up with patching extremely difficult. In fact, 52% of respondents to the survey say that it can take up to a week to patch a vulnerability after it has been discovered. An additional 22% say that it can take between a week and two months. Only 29% of organizations can consistently patch vulnerabilities within 24 hours of discovering them on their systems.
These massive delays in patching vulnerabilities leave an organization open to attack. By the time that an organization is scanning for a particular vulnerability on their system, that vulnerability has already been publicly disclosed for an unknown amount of time. Adding additional days or weeks between identification and patching means that an attacker has ample time to develop an exploit and use it to compromise an organization’s systems. Only after a patch has been applied is an organization safe against exploitation of that vulnerability, assuming that all instances have been identified and patched.
A Scalable Approach to Security
Trying to handle software vulnerabilities through patching is an unscalable approach to security. In 2018 alone, over 22,000 new vulnerabilities were disclosed. For each of these, an organization may need to test their systems to determine their level of vulnerability, test a patch (if available) to determine if it will break any functionality on their systems, apply the patch, and test to ensure that the patch is applied correctly. With limited security budgets and a cybersecurity skills gap, finding the resources and manpower to accomplish this for an ever-growing number of new vulnerabilities can be difficult or impossible. As organizations’ dependence on software grows and the number of vulnerabilities increases, patch-based vulnerability management is unsustainable. Protecting the organization against attack requires a different solution.
Deploying a web application firewall (WAF) provides scalable protection for an organization’s web applications. A WAF can identify and block traffic attempting to exploit known vulnerabilities, protecting the vulnerable applications until patches can be applied. Yet while a WAF is an effective general defense, it lacks the specialized protection that some applications may need. Runtime application self-protection (RASP) is a good choice for critical applications or those accessing sensitive data since an exploited vulnerability in them can have a dramatic impact. RASP wraps around an application, monitoring inputs, outputs, and behavior, allowing it to take action regarding anything suspicious.