Vulnerability Management

What is Vulnerability Management

Vulnerabilities—exploitable weaknesses in application code—are used to facilitate attacks that can lead to data theft, malware injection and server takeover, among other consequences.

Vulnerability management is the process of rooting out and eliminating these weaknesses before they’re abused. It’s typically achieved through the following methods:

  • Vulnerability scanning – The attempted sanitization of code environments through periodic penetration (pen) testing and code review, typically performed after updates are made to your application.
  • Patch management – The deployment of vendor-provided patches for newly discovered (e.g., zero-day) vulnerabilities in third-party software used by your application.
  • Input validation/sanitization – The filtering and verification of incoming traffic by a web application firewall (WAF). This blocks attacks before they can exploit vulnerabilities and is a substitute for fully sanitizing your application code.

Limitations of Vulnerability Scanners

Vulnerability scanning involves using either a software or hardware-based scanner to locate soft spots in your code that can be exploited by known attack vectors. Soft spots are typically a result of unsanitized code that permits illegal inputs.

Scans involve periodic pen tests and code reviews to uncover weak spots in your application, followed by code updates to remove vulnerabilities. Code is rescanned afterward to ensure that vulnerabilities have been weeded out. This code review and modification cycle should be conducted after code updates and anytime new attack vectors that could endanger your application are discovered.

As a whole, vulnerability scanning comes with several operational issues. For one, new vulnerabilities continually pop up, making scanning a frequent and resource-intensive process. Moreover, complete code sanitization is rarely achieved, as the body code usually exists in a continual state of change. This is on top of the fact that it’s impossible to predict all attack scenarios.

Lastly, vulnerability scanning cannot help with rapid responses to newly uncovered (zero-day) threats. This is crucial, as most exploits take place soon after new vulnerabilities are made public. Response time to such threats becomes a key component of any vulnerability management strategy—one that can’t be addressed by a prolonged cycle of code review and sanitization.

Patch Management

Patching newly discovered vulnerabilities relies on a third-party (usually a software’s creator) to develop and test patches for their software. Your security and DevOps teams are responsible for deploying the patches.

Similar to vulnerability scanning, patch management’s Achilles heel is its lack of responsiveness.

Typically, patching delays occur as a result of:

  • The time it takes for a new threat notification to reach your security team
  • Your software creator’s ability to develop and test new patches
  • How long it takes your security team to apply the patch and test its implementation

Consequently, fully patching a vulnerability can take days, weeks, or sometimes even longer—especially if there is a concern that a patch might affect your application’s core functionalities.

As a rule of thumb, the longer the patch process takes, the more likely it is that the vulnerability has already been exploited. Often by the time a patch is deployed it’s already too late. While patching is always considered best practice, this is why it should never be the only/main component of any vulnerability management strategy.

Input Validation/Sanitization

Vulnerability management with web application firewall

Input validation/sanitization is the process of deploying a web application firewall (WAF) on the edge of your network. Here it’s able to review all incoming traffic to your application, filtering out malicious inputs that target security vulnerabilities.

Input validation effectively solves vulnerability scanning and patch management issues for the following reasons:

  • It doesn’t require code updates
    Both the scanning and patching processes are ineffective because they rely on code updates, which introduces delays into a time sensitive process. With input validation, however, you can easily update your WAF security policy instead of tweaking your application code. This greatly simplifies the process and lets you respond to new vulnerabilities within hours, instead of days or weeks. Moreover, modifying a security policy on the WAF level means you don’t need code updates that can potentially inhibit your application’s functions.
  • It’s operated by a team of security experts
    Certain WAF providers, such as Incapsula, offer their solution to you as a managed service. This means the WAF is backed by teams of dedicated, around-the-clock security experts engaged in proactive research to immunize the service from new threats. As a subscriber, their efforts relieve you of having to closely monitor security updates, while offering the benefits of having in-house security research—all without bearing the cost of retaining such dedicated services on your own.
  • Customizable security rules
    Default security rules in most WAFs can be customized to address specific vulnerabilities. Your in-house security experts can use them to apply additional policies on top of default security rules. Using custom security policies lets you flexibly address specific security scenarios unique to your application—without having to make any code changes. This makes the process significantly more flexible and less labor intensive.
  • Virtual patch management
    Virtual patching is the process of deploying a patch on the WAF level, which is then applied across every application protected by the service. While not a substitute for patching software vulnerabilities, it’s an early response system that can effectively mitigate an immediate threat. This gives your team time to test and implement vendor-provided patches in the interim, without having to worry about perpetrators exploiting an exposed vulnerability.