Virtual patching is one of the most popular application protection technologies. Virtual “repair” of vulnerabilities restricts access to them until the developer eliminates them. As a result, companies have the opportunity to wait for the software vendor to arrive with official patches.
One of the main reasons for successful attacks on the IT infrastructure of companies is the presence of vulnerabilities. The exploitation of security gaps by attackers can disrupt business systems, launch malware on the attacked hosts, steal confidential data, or even take complete control of the server. According to studies, about 60% of data breaches occur due to the exploitation of old vulnerabilities. These vulnerabilities are very well known, but for some reason, the updates are not being installed.
It is necessary to install updates immediately after their release. This reduces the time interval during which the company is exposed to attacks related to the use of unpatched vulnerabilities.
Software Patching Problems
Often, there are some difficulties when applying "classic patches." Making changes to a working system requires business downtime. It can include manual traffic redirection, backups, testing, etc. So, quite a lot of organizations do not follow the update schedule very strictly. Also, some components of information systems can be difficult or impossible to update.
Besides, if a vulnerability is discovered in a bought commercial application, most likely, customers will not be able to modify the source code. In this situation, customers become dependent on the vendor and wait for the release of the patch. Vendors usually have extremely tight update release dates, so an officially supported patch may not be available for a long time.
Sometimes, an organization may use an application of a vendor who has gone out of business or a version of the program that the vendor no longer supports. In these situations, the outdated application code cannot be fixed.
Big problems appear when an organization is forced to use outdated source code due to adding its own custom functionality on top of the vendor's code. This functionality is tied to a business-critical process and upgrade attempts may break it.
What is Virtual Patching?
Virtual patching is the rapid creation and implementation of a security policy designed to prevent vulnerability exploitation. Virtual patching uses different layers of security technologies to block all possible attack vectors through which a vulnerability can be exploited.
This process helps organizations stay protected without the business interruptions required for emergency updates and, of course, without the additional costs associated with the breach of systems that were not updated in time.
Virtual patching can be applied at the external or internal network perimeter, application layer firewalls (WAFs), etc. It can be implemented in several ways. Each of them has its own advantages.
The first type of virtual patching is based solely on network traffic analysis. Solutions that provide this type of virtual patching use signatures, regular expressions, and pattern matching to detect malicious activity and block suspicious requests.
The second type is based on the same principles, but the criteria for blocking requests are determined by rules and event-driven programming.
Virtual patching of the above two types has several disadvantages. Due to the lack of understanding of the context, these methods are notorious for generating false positives. Signatures and pattern matching are heuristic approaches that cannot provide high accuracy. A poorly created virtual patch of this type can block legitimate traffic, disrupt normal application work, and add additional load on other protection solutions and mechanisms. In addition, virtual patches of this type are very "brittle" in case of changing application parameters. For example, each time when a vulnerable\risky URL or HTTP parameter changes in a web application, the virtual patch needs to be reconfigured too.
These approaches protect specific source data but leave vulnerable elements unprotected. If there are multiple entry points leading to the same vulnerable component, then the virtual patch will not be able to protect it. Since code remains vulnerable even after virtual patching is applied, some people refer to these approaches as vulnerability shielding rather than actual vulnerability elimination.
The third type is a natural evolution of virtual patching using Just-in-Time (JIT) compilers. By being inside the application and being able to control each rule before it is executed, "true" virtual patching can be achieved. It allows you to create a virtual patch that is functionally equivalent to a permanent vendor patch without changing the application's source code or binaries while ensuring that the component is appropriately patched and is no longer vulnerable.
Today, virtual patching technology has advanced to the point where it can become a fully automated process that does not require human intervention, is highly efficient, and is possibly more reliable than manual patching.
Advantages and Disadvantages of Virtual Patching
Advantages of virtual patching:
- A virtual patch helps quickly mitigate the risk of an exploit until a full and permanent patch is tested and implemented.
- Virtual patching allows companies to maintain a normal patch cycle without disrupting business processes if a vulnerability is discovered between permanent patch releases.
Disadvantages of virtual patching:
- Virtual patching may not cover all possible paths and locations where the exploit can be used.
- There is a possibility that after applying a virtual patch (that immediately demonstrates its effectiveness), the company will consider the issue resolved and forget about installing a permanent patch.
- While a virtual patch can quickly mitigate significant risks coming from a new vulnerability, it may not provide the same long-term benefit as a permanent patch because a virtual patch cannot address "congenital" defects in a vulnerable application.
Virtual Patching Products
Virtual patching was initially invented by IPS/IDS vendors many years ago. Later, it was transferred to WAF. Recently, RASP products have started to include this feature.
To date, most free and paid WAFs have virtual patching functionality. Several examples include:
- ModSecurity
- Nemesida WAF
- Avast Business Patch Management
- ManageEngine Patch Manager Plus
- SolarWinds Virtual Patching for Endpoint Security
The implementation of virtual patching functionality in WAF allows you to block attempts to exploit vulnerabilities in web applications without making changes to the source code, that is, without waiting for the release of an official patch from developers.
Virtual Patching Methodology
Virtual patching, like most other information security practices, is not something that should be approached haphazardly. OWASP outlines the following steps:
- Preparation
- Identification
- Analysis
- Virtual patch creation
- Testing
- Recovery\Follow up
Preparation Stage
You need to set up the virtual patching processes and the framework before actually working with a discovered vulnerability or, even worse, responding to a real-time attack on a web application. The moment of attack is not the right time to install a web application firewall or introduce the concept of a virtual patch. Your nerves are on edge and tensions are really high during actual incidents, so it is better to prepare yourself before the incident happens.
Here are some important steps to take during the preparation phase:
- Make sure you subscribe to mailing lists from software vendors. This ensures you are notified if the vendor releases information about vulnerabilities and fixes.
- Virtual patches must be implemented quickly to expedite the usual processes for managing and authorizing standard software updates. Since virtual patches do not change the source code, they do not require the same amount of testing as regular patches.
- Install virtual patching solutions in advance. Do not wait for security incidents.
- The standard Common Log Format (CLF) used by most web servers does not provide enough data to conduct a proper incident response. Therefore, it is advised to increase the logging volume and collect requests’ URLs, headers, body, response headers, and response bodies.
Identification Stage
The identification stage comes when a company becomes aware of a vulnerability in its web application. Typically, two different methods of identifying vulnerabilities are used: proactive and reactive.
The proactive method involves penetration testing and source code analysis. The reactive one includes searching for information about vulnerabilities in mailing lists from the vendor or public sources like vulnerability databases.
Analysis Stage
During the analysis phase, the following steps are recommended:
- Determine the usefulness of a virtual patch, given that it is suitable for injection-type flaws but may not provide an adequate level of attack surface reduction for other types of cyber threats like DDoS attacks. A thorough analysis of the underlying vulnerability should be conducted to determine if the virtual patching tool has adequate logical detection capabilities.
- Enter vulnerability information into the bug ticketing system to track the status.
- Check the vulnerability identifier, such as the name or CVE number. If a vulnerability is identified proactively rather than by analyzing public information, then each vulnerability should be assigned its own unique identifier.
- Determine the severity level of the vulnerability.
- Determine which software versions are affected and whether you are using any of them.
- Determine what configuration is required to exploit the vulnerability, bearing in mind that some vulnerabilities can manifest themselves only with specific configuration parameters.
- Analyze exploit code, proof-of-concept, or malicious payloads used during attacks or testing. Many vulnerability databases provide this data. If it is available, be sure to download it for analysis. This will be useful when developing and testing your virtual patch.
The Stage of Creating a Virtual Patch
The process of creating a virtual patch is associated with two main rules:
- No false positives. Never block legitimate traffic.
- No false negatives. Never miss an attack, even if an attacker deliberately tries to evade detection.
Try to minimize violations of the above rules. You may not be able to stick to both rules 100% of the time. Please remember that the virtual patch is actually designed to reduce risk. It is not your regular patch from the vendor.
There are two methods for creating virtual patches: automated and manual.
If vulnerabilities were identified using automated tools and an XML report is available, you can automatically convert this vulnerability data into virtual patches.
Manual creation of a virtual patch involves the formation of a whitelist (positive approach) or a blacklist (negative approach).
The positive approach is based on defining all the characteristics of valid input data (character set, length, etc.) and rejects everything that does not meet these criteria. These rules provide the best protection, but this is a painstaking manual process that does not scale. In addition, the list of rules is difficult to maintain for large or dynamic sites.
The negative approach is based on a set of rules that detect specific known attacks instead of only allowing legitimate traffic.
Testing Stage
To test virtual patches, the following can be involved:
Apply virtual patches first in a logging-only configuration to avoid blocking legitimate traffic.
You can also retest if a vulnerability was identified by a specific tool. If retesting shows that the virtual patch can be bypassed, it is necessary to return to the analysis phase to determine how best to fix the vulnerability.
Monitoring
At this stage, it is recommended to:
- Update virtual patch data in the ticketing system.
- Conduct periodic re-evaluations to check if previous virtual patches can be removed if the web application has been updated with a permanent source code patch.
- View system logs to determine if any of your virtual patches worked out.
Conclusion
Virtual patching is changing the cybersecurity paradigm by providing proactive exploit mitigation. Virtual patches restrict access to compromised application parts until the developer fixes the vulnerability, thereby destroying the attack vector and preventing hackers from exploiting unfixed flaws. Organizations can mitigate risks while “stretching” update cycles, allowing IT teams to have time until the software vendor releases permanent patches.
