The term “virtual patching” has been heard again and again lately. But what is it about, what are the advantages and disadvantages of this type of patching compared to the conventional patching process, and when does it even make sense to contain weaknesses according to this principle? In the following article, we will provide you with answers to these and many other questions.
Virtual patching is defined as: “A security policy enforcement layer that prevents the exploitation of a known vulnerability” [1]. Where a virtual patch is a policy for that very layer that is intended to prevent the exploitation of some weakness in the target application [2]. In short, a virtual patch is not used to repair the actual faulty application, but to establish a – partly upstream, additional – security mechanism which is intended to prevent the exploitation of a weakness.
Such a mechanism can be implemented in various ways [1]:
An exemplary application of virtual patching can also be found here: Virtual Patching Cheat Sheet [5]
A “classic” patch, on the other hand, is defined as the elimination of a problem within a software component [3]. In comparison to the virtual patch, the cause of the problem is thus eliminated here and not its effect combated or mitigated.
While a patch typically eliminates bugs, these are sometimes accompanied by changes or updates, and thus the term “update” is sometimes used synonymously [4]. This in turn can be both good and bad, especially in industrial environments. For example, there could be already known bugs in the actual business logic of the software, which are directly fixed by the update (respectively the patch) as well. However, this opportunity is accompanied by the risk that the previous program flow has been changed in such a way that new states occur, which in turn can lead to errors in the production flow if their effects are not known and these cannot or are not dealt with appropriately.
Before the actual patching can begin, however, there is some preparatory work that needs to be done. First of all, it should be known via asset management which devices are present in the respective infrastructure, which hardware is installed there, and which software and its version is currently being used there. Without this information, neither virtual patches nor classic patches can provide reliable protection. Even a single, non-inventoried system could otherwise be used by experienced attackers to reinfect the other systems in the respective (sub)network area (keyword: lateral movement).
Once this asset information has been accumulated – at best automatically, so that regular updates are easy and effortless – the next step is to compare it with known CVEs (Common Vulnerabilities and Exposures). The CVE format has been used there for some time to exchange just such information. See also our articles on the subject of „CVE“. The respective information can then be obtained from various public sources from different Computer Emergency Response Teams (CERTs). There are both general sources, specific for the industrial sector, but – especially in larger companies – partly also company-owned CERTs.
Before moving on to the actual patching, the question of who is responsible for installing patches often arises in practice. The IEC 62443 standard can be consulted for this. This defines the roles of “product supplier” (manufacturer), “system integrator” (integrator) and “asset owner” (operator). These roles are each assigned a specific responsibility for the security of the systems.
The manufacturer is responsible for both the development of the product and its maintenance. As long as a product is maintained by the manufacturer, the manufacturer is also required to provide software updates for the systems (especially security-critical software). Things get exciting as soon as a system is removed from this maintenance and an update – e.g., of the hardware – does not appear to be economically viable on the operator side, for example, for cost reasons.
The integrator is responsible for the overall design of the system as well as its installation and must also take into account the connection to third-party systems in order to enable safe operation. This requires close coordination with the manufacturer regarding the capabilities of the respective systems, as well as with the operator regarding the application scenario and the planned environment.
The operator, in turn, is then responsible for the actual operation of the machines and systems as well as for their maintenance and also their decommissioning during the “End of Life” (EOL) phase. During operation or maintenance, software-related maintenance tasks must be processed and solved in addition to mechanically necessary work. One of these includes updating the respective software systems using the resources provided by the manufacturer.
As the graphic shows, the standard requires a mutual exchange of information so that the manufacturer also receives information about the compatibility of the patches in the field, for example, and can thus incorporate this into its quality process. The arrow marked in orange here represents, for example, the provision of a patch list compatible with IEC 62443-2-3, which, for example, identifies operating system patches for their compatibility with the manufacturer’s products in use. If the operator now has a well-integrated asset management system with integrated patch management that allows these lists to be processed automatically, their regular updating and subsequent application to the production systems is a simple matter.
Using the example of the “WannaCry” use case on Windows (XP) systems in production.
Virtual patching: +
Classic patching: +
For both types, the effort invested is “worth it” in terms of the reduced risk for the affected systems. This is especially true when the systems in question are production-critical and a failure of these would result in a complete or partial breakdown of the respective production area.
In the case of the example application, the operating system manufacturer provided a free (classic) patch that only had to be installed on the systems. In the case of virtual patching, the SMBv1 connections could be restricted, which is also easy to do and at least curbs further spread.
Virtual patching: ++
Classic patching: –
Since virtual patching can be controlled via an upstream device, for example, and is therefore independent of the device concerned, an adjustment can be made quickly and easily here. With classic patching, on the other hand, it must first be clarified whether a software update is already available and suitable and supported for the company’s own systems (e.g., in terms of hardware and requirements) – here, of course, solid asset management pays off in full in advance. In addition, the patch files – if available – must first be obtained and then deployed to all end devices and installed there – this is where the automation of IT device management, as offered for example in the ondeso SR software solution, pays off in full. Depending on how much manual effort is still required here, or how well it has already been automated, the achievable speed could also vary again and thus reduce the lead of virtual patching here somewhat.
In relation to the assumed use case, however, it can be said here that the provision of the classic patch by the operating system manufacturer and the subsequent testing by the machine manufacturer probably took more time than the adaptation of the company’s own systems by means of a virtual patch. It should also be noted, however, that the vulnerabilities discovered by security researchers are usually brought to the attention of the manufacturer in the “responsible disclosure” process, so that there is a certain head start for the development of a patch before the information is communicated to the general public.
Virtual patching: —
Classic patching: ++
In this respect, classic patching is clearly “ahead of the game” since it fixes the actual cause of the problem instead of containing its effects. As mentioned at the beginning, a virtual patch does not aim to eliminate the gap, but only serves to prevent its exploitation. Thus, it can be seen more as an interim measure until a normal patch for the problem is available.
This is also underlined once again by the “WannaCry” use case. For example, if a virtual patch is implemented at the network junctions of different areas, this does not prevent the spread within one of these areas, whereas the classic patch eliminates the vulnerability on the affected systems and thus provides sustainable protection.
Virtual patching: –
Classic patching: 0
Here, the goal of both variants should be to have as little impact as possible on the business logic or not to result in any restrictions in the scope of functions. However, this can differ greatly for each gap under consideration. A virtual patch may have to block access to certain functions / endpoints where problems are known to occur, whereas a patch can close the gap and fully restore the function at the same time.
In the specific use case, for classic patching this means that time is needed for the installation, but afterwards SMB can be used again as before. With virtual patching, on the other hand, the measure can be taken immediately, but restricts communication via SMB and thus may have a negative effect on the business or production process.
Virtual patching: 0
Classic patching: +
With regard to the availability of the respective patch types, it is probably more common to perform “normal” updates, be it the operating system or specific user software on the machines, using the resources of the respective manufacturer. This is probably also in line with the expectations of most customers of such systems, as they have typically purchased and want to continue to operate both a functioning and a secure system. Care should be taken at the time of purchase to take into account the manufacturer’s long-term support for the systems. Nevertheless, due to the very long operating times for machines and systems, it may well happen that certain systems are no longer produced or supported, or in the worst case, the manufacturer in question no longer exists and can therefore no longer offer any updates. In the case of virtual patches, it is more likely to be up to the operator of the system to design and implement these himself at short notice, not least because of the time urgency.
Again, in terms of the use case, it can be said that a patch was provided by the manufacturer, so there was support. In the case of virtual patching, there are probably general solutions for blocking SMBv1 connections, but less concrete countermeasures for the specific problem.
Virtual patching: +
Classic patching: –
With regard to the application of the technologies in the industrial environment, the topic of “maintenance window” also plays a major role. In our opinion, the virtual patch has a slight advantage here since it can be installed independently of the affected system and therefore does not require a maintenance window. On the other hand, it is also possible to plan a patch installation for the affected systems in advance, which can then be triggered by the operating personnel as soon as the opportunity arises – even spontaneously.
In the case of WannaCry, a maintenance window is probably necessary for the installation of the corresponding classic patch since a reboot of the system in question will most likely have to be performed. This is where virtual patching comes out on top, which does not necessarily require this maintenance window as long as the restriction of the connection does not affect the functionality of the systems.
As can also be seen clearly in the table, the two measures of virtual and classic patching should not be understood as replacing each other, but rather as complementing each other well. If, for example, it is necessary to react as quickly as possible to the discovery of a security vulnerability in order to reduce the associated risk, the use of virtual patches is a good option. Afterwards, however, it should always be checked whether there is already an updated software version that could be used to permanently eliminate the vulnerability in question and thus make the virtual patch obsolete. Our software solution ondeso SR can support you with this. An exchange between manufacturer, operator and system integrator is also required – among other things also in the IEC 62443 standard – so that a good and compatible solution to the problem can be found together.
So, in summary, virtual patching is more of a blessing than a curse, but it can become one if it is seen as a replacement for actually fixing the gaps via “classic” patches and as a kind of permanent solution.
Sounds interesting?
Here you can download a summary as PDF for free:
Appropriately, we also recommend our YouTube video “Virtual Patching”