What is virtual patching?

A rule describes the exploit rather than the flaw.

Somebody works out what a request exploiting the weakness looks like: a parameter carrying something it should not, a path reached in an order it should not be, an HTTP header or value longer or stranger than the code handles. A rule in front of the application matches that shape and refuses it, and the request never arrives at the code that would mishandle it.

Everything hangs on that word shape. The rule knows the exploit, not the defect, so it protects against the versions of the attack somebody anticipated. A variation that reaches the same flaw by a different shape is a different request, and the rule has no opinion about it.

A real patch changes the code, so the flaw is gone by every route, in every copy that gets the update. A virtual patch changes nothing in the code; it refuses requests that match one known way of reaching the flaw, at one place in front of the application.

That makes the virtual patch faster to apply and easier to remove, and the real patch the only one that finishes the job. The two are meant to be used one after the other, not as alternatives.

It earns its place when a fix cannot be applied quickly: a zero-day with no fix yet, a vendor product you cannot change yourself, a legacy application nobody can safely rebuild, or a release cycle that takes weeks. In each case the rule covers the gap between learning about a flaw and removing it.

It makes little sense as a permanent answer, or where the attack has no recognisable request shape, such as a flaw in how the application checks who may see which record. A rule cannot describe a request that looks exactly like a legitimate one.

Describe the exploit. Work out which parameter, path or header carries the attack, from the advisory or from your own testing, and write the narrowest rule that matches it. Watch before refusing. Run the rule in monitor mode first, so you see whether it would also match ordinary traffic. Enforce, then expire. Switch it to refusing requests, record why it exists and when it should go, and remove it once the real fix is deployed.

Ready-made rule sets, such as the OWASP Core Rule Set, already match many generic attack shapes, which is often enough to blunt a new flaw that is reached by a familiar technique like injection.

Flaw-targeting requests differ from capacity floods: a DDoS attack is stopped by capacity, not by a rule describing a shape.

The technique is genuinely useful and routinely misunderstood, in a way that has a cost.

• What it buys is time. A fix has to be written, reviewed, tested, and deployed, and some applications cannot be changed quickly for reasons that have nothing to do with willingness: a vendor product, a release train, an integration that has to be re-certified. A rule can be in place in minutes and holds the door while the real work happens.
• What it does not do is fix anything. The weakness is still there, still reachable by any route the rule does not describe, and still present in every copy of the application elsewhere. Anybody with a variation walks past it.
• The dangerous mistake is treating it as done. A rule with no expiry becomes permanent, and the urgency behind the fix evaporates the moment the alerts stop. Rules put in place for this reason should carry a date and a reason, which is the same discipline exceptions need, covered under operations.

A second cost: a rule describing an exploit shape can match ordinary traffic that happens to look similar, so it needs the same watching as any other rule before it starts refusing requests, which is what rules sets out.

The scanners that find such weaknesses in the first place are covered under bots, and the other vocabulary in this glossary.