According to the National Vulnerability Database (NVD), over 21,000 vulnerabilities were reported in 2021. When vulnerabilities are discovered, developers work hard to release a patch before attackers exploit it. In most cases, though, releasing an update is time-consuming and requires extensive planning and expertise.
One of the best options to quickly address vulnerabilities is to use virtual patching.
A virtual patch is a security layer that analyzes incoming traffic for malicious activity to protect any system vulnerabilities from exploitation. The idea is to block attacks before they reach the intended vulnerable target.
A virtual patch is implemented on the network level, so it doesn’t call for an immediate recompile of the source code. This gives security experts ample time to perform complete assessments and tests on the software patches before releasing them, which reduces the security risks associated with updates.
The virtual patching process includes identifying, creating, and deploying the virtual patch.
Accurately identifying a vulnerability first requires preparation. We should sign up for vendor alert emails for all the software we are using. Additionally, it’s crucial to have processes to expedite software installation. This prevents us from encountering unnecessary roadblocks during an active incident — such as having to request permission to install virtual patch software.
We can identify vulnerabilities using either proactive or reactive methods. Proactive methods rely upon using vulnerability tests and code reviews to identify vulnerabilities. In contrast, reactive methods rely on notifications about vulnerabilities — either from software vendors or upon discovery that an intruder has breached the system security.
After identifying the vulnerability, we can create a virtual patch. We need to know which assets and software versions are affected, the configurations and settings that trigger the exposure, and the severity of the problem. This information is crucial when developing and testing the virtual patch.
When creating a virtual patch, it’s essential to ensure that it neither overlooks any attacks nor blocks legitimate traffic. A virtual patch can approach this in two ways: employing either a positive or negative security model. Positive security allows traffic from allowed sources and rejects everything else, while negative security allows all traffic except blocked traffic.
Deciding between the two models depends upon the situation. While negative security is easier to implement, hackers can still evade detection if the blocklisting criteria are insufficient. In contrast, positive security is more robust but more complex.
After creating and testing the virtual patch, it’s pushed to production. Regular monitoring is essential to ensure that it’s performing as intended. We’ll also need to remove the virtual patch after applying the security fixes to the source code.
There are several aspects to consider before deciding whether to use virtual patching. The final decision will ultimately depend on the priorities and capabilities of the organization.
Virtual patching provides a quick solution for addressing system vulnerabilities. Since it’s applied on the network level, it starts working without requiring immediate changes to the source code.
As a result, developers and security experts have sufficient time to properly test and apply more permanent fixes directly to the source code without causing service interruptions.
Furthermore, virtual patching saves money because it enables us to adhere to the regular patching timeline. We don’t need to allocate extra resources to expedite the patch development.
Additionally, because we only need to install the virtual patch solution on select network locations, it’s incredibly convenient and requires little time.
Despite these significant advantages, virtual patching does present some potential downsides.
For example, after a virtual patch has been applied, it’s too easy for an organization to become complacent with the temporary fix. As a result, it may minimize efforts to resolve the vulnerability at the source code level.
Additionally, the writer of a virtual patch may not account for all malicious traffic, leaving parts of the system vulnerable to attacks even after the patch is in place.
Finally, virtual patching can potentially introduce performance issues. Analyzing network traffic against many signatures can significantly slow network speeds.
An optimal virtual patching solution must feature several characteristics.
First, it must be multi-layered to deter different types of threats. It should be able to analyze traffic for malicious activity, detect and prevent intruders, and work on software applications deployed in physical, virtual, and cloud environments.
Additionally, it must have anti-evasion capabilities to normalize requests before being inspected. This ensures the detection of less common attack vectors.
Finally, the solution must be able to break down the HTTP stream into logical parts — like header and content type — for optimal inspection.
To demonstrate how virtual patching works in a real system, consider a simple login form with a SQL injection vulnerability
The login form accepts a username and password and uses that data in the SQL query to return the user info, as shown below:
SELECT * FROM user WHERE username = 'jane' AND password = 'p@ssword1'
A hacker can exploit the login form since we are not sanitizing the user input before using it in our query.
Before examining how they might do this, note that the username and password are enclosed with a quotation mark, with the closing quotation indicating the end of the string and the start of an SQL command.
If the supplied data contains a single quotation mark, SQL will interpret the text that follows as a command — something an attacker could use to their advantage.
Suppose an attacker uses the following data in the login form:
Username: jane
Password: p@ssword1′ OR ‘1=1’
The SQL query would look like this:
ELECT * FROM Users WHERE username ='jane' password ='p@ssword1' OR '1=1'
Here, the attacker is adding an OR statement to the password field. Since ‘1=1’ will constantly evaluate to true, the database gives access to the attacker even without a valid username or password.
While this is a straightforward scenario, let’s assume that it would be difficult to fix. This means that a virtual patch would be the fastest way of preventing attackers from exploiting the vulnerability.
First, we need to identify the vulnerability. This might be through a test, a user report, or a data breach in the worst-case scenario.
The next step is to create the patch. One approach would be to filter user input by creating a rule that rejects form data with characters that can interact with the database. For instance, the rule should disallow form submissions if the username or password contains quotation marks.
Finally, we deploy the virtual patch to the affected pages and perform tests to determine if it works as intended. Once confirmed, we can work to fix the underlying issue in our source code.