Scenario 1:

MyBank Pty Ltd has 300+ critical legacy enterprise applications. Almost all of them were built by the then IT-savvy non-developers. They were built with limited or no design considerations. Security was not even a design-criteria back then. These applications continue to run either because they are now too complex, too critical, or the backbone for many dependent systems and hence cannot be substituted.

Scenario 2:

MyEstore Pty Ltd has had substantial growth within the last decade. It uses many third-party and open-source components for a better user experience. While the application has scaled up in the past couple years, most of the core code remains the same. With their eCommerce site running 24×7, it is simply not feasible to update the core functions to handle ever-evolving attack vectors. Also, the third-party and open-source components have rarely been updated, and now pose a serious security threat.

These are common scenarios across businesses. Security teams struggle to safeguard critical applications while minimising downtimes. CTOs fear opening the “Pandora’s Box”. The aim is to mitigate the risks without touching the source code. What is running, cannot acceptably be broken.

Virtual patching is a viable quick fix for punctured applications vulnerable to pointed attacks. It is a shield designed to prevent exploits without modifying the application’s source code. OWASP defines Virtual Patching as “a security policy enforcement layer which prevents the exploitation of a known vulnerability.”

So, Where All Does Virtual Patching Work Well?

Virtual patching is a good solution where:

· core code cannot be altered

· an active attack is underway that requires instant, temporary fix

· frequent downtime is not feasible

· vulnerabilities identified in enterprise software need instant fixes and cannot wait until the vendor releases official patches

While virtual patching comes with a pretty face, it can sometimes be a nasty devil in disguise.

Important points to remember are:

· Virtual patches are temporary fixes and should not be treated as fool-proof

· Too many virtual patches are high maintenance overhead for IT team

· The short-term cost benefits may make it tempting to keep patches as long-term solutions

Implementation of Virtual Patching

Now that we have seen the pros and cons, let us delve into its implementation. Like all implementations, virtual patching should also follow a planned approach – prepare, identify, analyse, create, implement, and monitor. Even in the occurrence of an active security incident, adherence to these steps will ensure an effective strategy to contain the impact.

Virtual patches can sit at different layers and endpoints. There are many ways to patch depending on the area to be targeted. Some of the popular patching options are:

· WAF – Web Application Firewall sits at the application layer (OSI Layer 7), between a web application and the Internet to filter out malicious traffic.

· IDS – Intrusion Detection System complements a network firewall to identify malicious data within packets. Intrusion Prevention System (IPF) is intelligent enough to react to these malicious packets

· RASP – Runtime Application Self-Protection is a highly intelligent piece that monitors activities within the application, at runtime, without changing any code; effectively reducing false positives to near zero.

These options are meant to assist network firewalls, and a multi-layered approach, combining more than one way, is advisable.

In conclusion, Virtual Patching is great when time or code modification is a constraint. It is also crucial to devise an efficient and optimal patch management solution. Additionally, a robust and far-sighted security strategy should always be a top priority. To patch or not patch is indeed an important question!

References

https://owasp.org/www-community/Virtual_Patching_Best_Practices