In case you haven’t noticed, software vulnerabilities are becoming increasingly common. As the amount of code that is in use grows, so does the number of vulnerabilities. While certain secure development practices can help to cut down on the number of vulnerabilities present in a given product, the sheer number of ways that things can go wrong in software means that most applications have at least one bug (but probably have several). Of those bugs, at least some will allow the application to be exploited by an attacker.
The current method of managing vulnerabilities is equivalent to playing Whack-a-Mole. During the software development and testing lifecycle, developers attempt to identify and fix as many vulnerabilities as possible. Once the software is released to production, companies try to incentivize security experts to ethically report vulnerabilities to them through bug bounty programs. Vulnerabilities that are reported may have a patch issued that users of the software then need to apply in order to remain secure.
However, this approach is not sustainable. The sheer number of vulnerabilities that reach production means that organizations cannot keep up with the need to test and apply patches for the third-party software that they use. A new solution for vulnerability management is needed, and runtime application self-protection (RASP) is a key part of the answer.
The Software Vulnerability Landscape
Most software vulnerabilities aren’t anything new. There is a set of programming errors that developers commonly make, and these account for most new vulnerabilities. The main reason that new vulnerabilities are discovered and reported each year is that these mistakes are made a lot.
In fact, over 22,000 new vulnerabilities were disclosed in 2018 alone according to cybersecurity firm Risk Based Security. Most of these are the same old mistakes appearing in new software. However, the fact that these are repeated problems doesn’t make it any easier for organizations to efficiently discover and fix them. Programming errors like an integer overflow or a buffer overrun are easy to miss when reviewing code; however, they can create significant vulnerabilities.
Falling Down on the Job
The traditional method of managing vulnerabilities in production through patching relies on everyone to do their job well. However, that isn’t always what happens. At every stage of the process, some things are missed or delayed, leaving organizations vulnerable to attack.
The first stage of the process is finding bugs so that they can be fixed. Ideally, this would happen during development and testing, so that vulnerable code is not in use. However, those 22,000+ bugs found in 2018 demonstrate that a lot of vulnerabilities reach production. At that point, it’s a race between the white hats trying to find and fix them before black hat hackers can use them to launch attacks.
Once a vulnerability has been identified, it’s the responsibility of the maker of the vulnerable software to issue an update that fixes the problem. However, of the 22,000+ vulnerabilities discovered in 2018, 27.1% of them had no patch issued. This means that users of vulnerable software have no way of fixing these vulnerabilities.
Once a patch is available, organizations need to know to look for it. While some vendors offer automatic patching, a common practice is to check the National Vulnerability Database (CVD) for known vulnerabilities for the systems that an organization uses. However, the list of 22,000+ vulnerabilities tracked by Risk Based Security includes 6,780 vulnerabilities (31% of the total) not included in the NVD.
These vulnerabilities are publicly known to hackers and may have patches available; however, companies relying on the NVD for their list of patches to apply might not know the vulnerabilities exist.
Finally, organizations need to rapidly apply patches to their vulnerable systems. The gap between a patch being released (and the associated public announcement of vulnerability) and organizations’ actually applying that patch is a common target for hackers. However, the average time to patch a vulnerability is 38 days, dropping to 34 for critical vulnerabilities. For more than a month, organizations are leaving themselves open to attack via known vulnerabilities that have a solution available.
Protecting Against Unknown Vulnerabilities
While patch-based vulnerability management strategies may work in theory, in practice they’re leaving organizations vulnerable to attack. Since patches can break an organization’s systems, each one may need to be tested before being applied to production systems. However, this process can’t scale as the number of vulnerabilities increases. Also, failures throughout the patch creation and distribution process can mean that an organization doesn’t have access to a patch or doesn’t know that they need it if it is available.
In order to be secure, organizations need to be capable of protecting themselves against vulnerabilities for which a patch may not yet be available. One good solution is deploying a Web Application Firewall, which can identify and block attack traffic before it reaches vulnerable software.
However, the scope of the attack surface that a WAF needs to protect means that it often does not have visibility into applications that are needed to identify novel attacks. Runtime application self-protection provides a more granular level of defense.
A RASP solution wraps an individual application in a personalized security solution that monitors the application’s inputs, outputs, and behavior. If any anomalies are detected, it can alert security personnel or take action to stop the attack. This visibility into a particular application allows RASP to identify even zero-day attacks and makes scalable vulnerability management possible.