Virtual patching demands applying a layer of security policy that prevents and intercepts vulnerability exploitation. A productive solution requires the capabilities to analyze and block malicious activity from web-traffic, identify & prevent intrusions, prevent web application attacks, and flexible deploy on the cloud, or physical environments. Without pushing the critical system at risk, the patching solutions can also provide security administrators an opportunity to evaluate, analyze and plan official virtual patches.
With Virtual patching, without accessing its libraries, the OS, or even the physical device, a bug/threat can be fixed. The goal is to fix the issue by modifying or removing hazardous elements by taking the input and output controls of web applications.
Deep security virtual patching includes the option to secure the web-apps without patching them. These solutions are much faster and they don’t need any application language programming. It controls the patch cycle without compromising security. The business can stay up and running without having the production servers down while all virtual patching happens.
Circumstances where virtual patching solutions are critical
- For a critical level of coverage, it offers a short-term stop-gap solution till a permanent patch is available
- The patch could be validated to check whether it will trigger new issues, before implementing a permanent patch.
- Deep security virtual patching is very important at the initial warm phase. Because, at this phase, it can shield the known vulnerabilities from exploitation. This validation phase may bring in delays additionally.
- Virtual patching requires considerable planning as well as downtime for a permanent patch to be implemented; which means it is more important for assets also. These assets comprise pipeline monitoring systems, and machines running critical systems, which can act a vital role in critical infrastructures.
Example with Public Vulnerability
Let us consider SQLi vulnerability as an example:
WordPress Shopping Cart Plugin for WordPress
/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php
reqID Parameter was prone to SQL Injection.
Explanation:
In WordPress, the WordPress Shopping Cart Plugin has a flaw that can allow an intruder to launch an SQL injection attack.
The issue is due to the
/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php.
Because this script is not properly sanitizing user-supplied input to the reqID parameter.
Virtual Patching Methodology
Virtual Patching is not something that could be approached aimlessly. Rather, a persistent and frequent process could be followed that will give the best opportunity for success. The workflow of virtual patching imitates the industry-accepted way of conducting IT Incident Response.
The virtual matching methodology consists of the following phases:
- Preparation
- Identification
- Analysis
- Virtual Patch Creation.
- Implementation/Testing.
- Recovery/Follow Up.
