What do you mean there isn't a patch?

A look at the OWASP Virtual Patching Cheat Sheet

As we have discussed in other articles, the reality is that despite vulnerabilities being present in suppliers' software and products, these vulnerabilities may often not have available fixes or patches that consumers can simply apply.

This could be due to resource constraints the supplier has, patching and remediation timelines, competing feature backlogs or simply a lack of further support and sustainment from a software supplier or component.  

For example, studies from groups such as Aberdeen Strategy & Research found that of over 20,000 vulnerabilities discovered in 2020, vendors didn’t issue patches for almost 20% of them by the end of the year.

This included thousands of vulnerabilities that had publicly available exploits as well. The reality is that much like software consumers, who historically struggle to apply patches even when available, to vulnerable applications, vendors often struggle to keep pace when it comes to issuing patches for known vulnerabilities in their products and software.  

Sometimes there indeed is no patch available from the supplier quite yet. Other times it may be an issue where the time and effort involved to test and install the patch may be lengthy, but the organization needs to take steps to mitigate the risk in the interim. OWASP cites sources such as Symantec, which state that the average time for organizations to patch their systems was 55 days. That leaves a lot of wiggle room for malicious actors to try and exploit vulnerabilities.

There may be additional challenges as well, such as it being cost prohibitive to fix vulnerabilities in an organizations custom code and application or a situation where you’re using legacy code from vendors and suppliers that simply no longer are in business or aren’t providing additional updates and support.

All of these are valid scenarios that could lead organizations to pursuing the patch of Virtual Patching instead.

This creates a situation where consumers need to take other measures to address the risk that vulnerabilities or flaws present that don’t involve being able to patch the supplier's or their own software directly.

This often culminates in what the industry refers to as “virtual patching”, which as defined by OWASP, is “a security policy enforcement layer which prevents the exploitation of a known vulnerability”. (https://owasp.org/www-community/Virtual_Patching_Best_Practices)  

In the case of web applications this generally involves being able to intercept transactions and data flows and ensure that malicious traffic looking to exploit the known vulnerability doesn’t make it to the web application.

This often takes the form of Web Application Firewalls (WAF). WAF’s are generally deployed to protect web applications from malicious attacks such as cross-site scripting (XSS) or SQL Injection that look to compromise flaws and vulnerabilities in the application.  

Numerous studies show that nearly half of vulnerabilities disclosed have no patch available from the supplier upon the vulnerability's disclosure. On one hand this shows a progressive attempt to communicate quickly with the consumer community regarding known vulnerabilities and risks, but it inevitably also creates a situation of widely disclosing a vulnerability with no patch for consumers to use to remediate the risk.  

In addition to constraints from the suppliers end with having patches available, it is also common for there to be business or mission constraints that don’t always allow traditional patching to be an option, even if a patch is available from a supplier.

For example, there may be concerns about taking mission or business critical systems offline or the potential to disrupt systems that are generating revenue for the organization. Organizations may also defer applying available patches from vendors and suppliers until a scheduled maintenance window, instead deferring to using a virtual patch in the interim to mitigate the risk.   

This is where the practice of virtual patching comes into play for software consumers. In addition to methods such as WAF’s, software consumers can make changes to environments, systems and configurations to try and mitigate the exploitability or impact of a vulnerability based on the specific details of the vulnerability being discussed.  

This is also why CVSS base vulnerability severity scores shouldn’t be the end-all-be-all for vulnerability prioritization, since environment factors such as architecture and configuration can impact actual exploitability, but that is a conversation for another day.

It should be noted that Virtual Patching is also a very common technique for internally developed applications and software, but in this article we are speaking from the perspective of software consumers dealing with software, applications and products from third-parties.

While some organizations may have mature approaches to virtual patching in place already, many others often do not. One great resource to utilize is the “Virtual Patching Cheatsheet” from OWASP.

It proposes a Virtual Patching methodology of five steps, which includes Preparation, Identification, Analysis, Virtual Patch Creation, Implementation/Testing and Recovery/Follow Up.

We will look at each of these steps below. (https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html)

Preparation 

The preparation phase involves preparing the organization to establish a virtual patching process prior to needing to deal with vulnerabilities or intrusion. As OWASP points out, incidents can be very tense chaotic periods and trying to establish a process during the chaos is a recipe for disaster. Organizations need to ensure they are monitoring for alerts from their suppliers and vendors using sources such as mailing lists and public vulnerability disclosures.

You’ll recall we discussed this being a key capability in the previous article on suppliers and Product Security Incident Response Teams (PSIRT’s). Consumers also need to obtain pre-authorization to sidestep traditional organizational patching and governance processes to apply the virtual patch as quickly as possible. Consumers will need to deploy their virtual patching tooling, if relevant, prior to incidents or activities so they can respond quickly.

Lastly, they will need to establish HTTP audit logging to monitor web traffic fields such as the request URI as well as request and response headers and bodies. This data will enable consumers to identify applicable traffic and respond in future phases.  

Identification 

Now that consumers have prepared to implement virtual patching, they can begin the work of identifying vulnerabilities in their environment. OWASP defines either proactive or reaction identification.

On the proactive front the organization is actively assessing their web security posture using methods such as penetration testing and automated web assessments or reviewing source code of their applications to identify flaws.

On the other handle, reactive identification, which is the norm for all, but the most mature organizations involve identifying vulnerabilities through methods such as being contacted by the vendor, coming across a public disclosure or worst of all, experiencing an actual security incident.  

Analysis 

During the analysis phase, several activities are involved to ensure the organization can properly respond to an identified vulnerability. This includes determining the applicability of a virtual patch.

What is the actual vulnerability or flaw and do the organizations' tools and capabilities provide the proper mechanism to address it? The vulnerability also needs to be captured in the organization's tracking or ticketing system and has a proper vulnerability identifier applied.

This may be a CVE name and number, or an identifier defined during the vulnerability's announcement from the supplier or even one assigned to it through the organization's vulnerability scanning tools. The key here is to use a uniform name internally for any presence of vulnerability to ensure a coherent response and tracking process.  

In addition to properly identifying and tracking the organization, it needs to understand the impact level of the vulnerability. Not all vulnerabilities are created equally and come in varying levels of severity.

You will also need to capture which specific versions of software are impacted and determine where these versions of the software exist within your environment. While the version and presence of the software is key, the organization must also document the specific configuration required to allow the vulnerability to be exploited.

For some vulnerabilities this may be something as trivial as their mere existence, while others may require specific configurations or environmental factors to exist for the vulnerability to be exploited.

Lastly, OWASP recommends capturing the Proof of Concept (PoC) exploit code, if it was made available from the vulnerability announcement. This can be used by organizations as they start to create their virtual patch to address the vulnerability.  

Virtual Patch Creation 

You’ve prepared, identified the vulnerability, analyzed it and are now prepared to create the virtual patch, so what does this involve? OWASP defines two overarching tenants that virtual patching is bound by, which include no false positives and negatives.

This means you don’t want to block legitimate traffic, which could have a negative impact on the mission, business, revenue, customers and so on and you also do not want false negatives, which is allowing malicious traffic through, potentially due to the malicious actor evading detection. 

Obviously achieving these goals 100% of the time is a lofty goal, but it is one worth striving for to avoid your attempts at virtual patching having a negative impact on the organization which can tarnish the relationship between security and the business.

Virtual patches can be created either manually or automatically. On the manual front this may look like creating allow lists to perform input validation and denying anything that doesn’t align with the defined criteria. Another manual method is the use of a block list that is based on a set of rules and criteria related to the attack and vulnerability and blocks any traffic that meets this criterion.

OWASP points out that this method, while an option, isn’t ideal. The potential for false negatives is higher in this case and the chance that malicious activity can slip by avoiding the specific criteria is present. For example, we previously mentioned PoC exploit code that may have been made available during the vulnerability's announcement. Organizations can use this to create block lists.  

OWASP’s Virtual Patching cheat sheet points out that both approaches of allow or block lists have pros and cons. Block lists are easier/quicker to come up with but also allow for more potential to be evaded.

Allow lists are more restrictive but also require more precision given anything not aligned with it will be blocked, and this can include legitimate business and mission-oriented traffic that can cause organizational disruptions. These sorts of situations can hinder trust from the business to security and risk the authority to quickly apply virtual patches in the future.   

Beyond manual virtual patch creation processes, it is also possible in some cases to implement automated virtual patches. OWASP points to several examples such as OWASP’s ModSecurity Core Rule Set (CRS) Scripts, ThreadFix Virtual Patching and Direct Importing to the WAF Device.

These options use methods such as taking imported XML vulnerability data from tools and converting it into virtual patches to protect systems. While these are ideal and a key part of scaling virtual patching practices, they often also require some manual involvement, tuning and oversight to ensure their effectiveness as well.  

Implementation and Testing 

Once a virtual patch has been created, organizations need to begin testing and implementing it to protect their organizations from malicious actors looking to exploit the associated vulnerabilities. Organizations may make use of various applications during this phase such as the web browser, CLI, proxy servers and others.

OWASP recommends testing virtual patches in a log only configuration initially to not block legitimate user traffic and to ensure the effectiveness of the virtual patch. Once this is completed and it is verified the virtual patch is indeed blocking traffic that could be malicious and aligns with the previously defined allow or block lists it can be fully implemented while having a level of assurance that it won’t impede the business and its operations.  

Recovery & Follow Up 

The last phase OWASP identifies for virtual patching is the recovery and follow up phase. This involves activities such as updating data in the organization's ticketing system, performing periodic reassessments and running virtual patch alert reports.

Proper updating of ticketing systems allows the organizations to gauge metrics associated with vulnerability management for virtual patching and capture relevant data for future incidents.

Re-assessments can be used to determine when and if the virtual patch can be removed, for example if the web application source code has been fixed directly. Reports can be used to provide information for when a virtual patch has been triggered, providing insight into potential malicious activity and traffic underway that is looking to impact the organization.  

Long Term Thinking 

One thing to keep in mind is that a virtual patch can be thought of as a band aid. It is a temporary solution to a potentially permanent problem.

While it is an excellent method to protect vulnerable applications that can’t be patched directly or can’t be remediated due to concerns around business interruption and mission impacts, the virtual patch should be viewed as a temporary remediation.

Organizations need to be conscious of the fact that malicious actors can bypass a WAF using a variety of creative methods as well. For example, in 2022, application security firm Claroty demonstrated that they could bypass five of the most popular vendors in the WAF space by using JavaScript Object Notion (JSON) to obfuscate database commands and evade detection by the WAF tools. (https://www.darkreading.com/application-security/popular-wafs-json-bypass) 

This reality means that organizations need to have long-term plans in place to remediate application vulnerabilities at the source as well as have sound security architecture and engineering practices such as Zero Trust in place, to mitigate the risk of lateral movement or further limit the blast radius and business impact if malicious actors can bypass the virtual patch mechanisms.