What if you can’t patch?

Once you’ve identified those assets that you can’t patch for some reason, you should identify other protections for those assets. Once you’ve decided how you’ll protect them and developed an incident response plan just in case—you should monitor them carefully.

Other protections might include:

  • Restrict applications that can run on that asset to an approved list, so that other, uninvited software can’t run.
  • Remove unnecessary connections. If that asset doesn’t need to be connected to another asset, then removing that connection will reduce the risk.
  • Block removable media to stop data leakage and infection.
  • Segment the network to mitigate the risk—isolating the asset that can’t be patched as much as possible.
  • Consider implementing hardware-based security, such as data diodes to enforce a one-way flow of data, if appropriate.
  • Consider virtual patching.

What is virtual patching?

Suppose that there is a known vulnerability due to a code error in one of your applications. A virtual
patch is intended to prevent the vulnerability from being exploited, (even though the code has not
been edited), by:

  • Controlling the inputs to the application through a web application firewall, proxy or server plugin. It analyses traffic, and intercepts attacks so that malicious traffic doesn’t reach the application.
  • Or by controlling the outputs: either by blocking the entire outbound session (which might alert the attacker, or reduce the functionality of the system) or by redacting (or ‘scrubbing’) the output to prevent exposure of sensitive data.

Virtual patching has two goals: it minimises the time-to-fix (even if only with a temporary fix) and it
reduces the organisation’s exposure to the risk of attack.

Like the standard and emergency patching processes outlined above, there should be a consistent
and repeatable process to virtual patching. This process would follow the same pattern.

Plan in advance for patching needs, for example by developing policies plans and procedures, or installing software modules that you might need to activate if patching.

Identify vulnerabilities via vendor announcements, public disclosure or (worst-case) a security incident.

Determine the risk to your organisation of those vulnerabilities and whether virtual patching is appropriate and needed.

Prioritise the patching, not forgetting to discuss the risks with the business owners, and ensuring that they understand that this is a temporary and possibly incomplete fix.

Then create, install, test and document the patches.

Don’t forget to consider updating the underlying code (which does, after all, still contain the problem)
in future patch releases. If you do decide to patch the code at a later date, you can then determine
whether you should remove the virtual patch.