Patch Levels and Risk Management
When reporting on patch levels for use in metrics as part of risk management there are two areas that are commonly dismissed which are worth additional consideration.
We all know that we need to monitor security patch levels of critical systems, but what about non-security patches? And what about patches for non-critical systems? These are a few areas that we cannot afford to ignore when considering risk exposure.
Non-critical systems need patching just as much as critical systems. They may not need to be patched as rapidly, but they do need to be patched in a timely manner. If an intruder gets into the infrastructure, behind the critical patched systems, an unpatched infrastructure presents an easy hunting ground for additional compromise and potential persistence. Lateral movement control is still a priority, even if it's not quite as high a priority as front-line systems. Knowing how far behind the business is on non-critical systems lets it properly integrate the threat into risk consideration.
Non-security patches need to be applied just as much as security patches, because vendors may not reveal a patch contains a security enhancement, and because not all vulnerabilities are known. Any time a patch is released, there are nefarious people examining it to determine why it was released. If they can identify a security problem, acknowledge or unknown, they can then exploit that problem. Patching given a lower priority creates a window of opportunity for bad actors to discover and exploit problems that the vendor may be unaware of. Closing that window is essential to minimizing risk.
Additionally, failure to apply non-critical or non-security patches in a timely manner may create a situation where a critical patch needs to be rolled out as an emergency, because of a significant actively exploited vulnerability. If this critical patch relies on or requires the installation of dependent intermediate patches which were not applied, they will need to be deployed as emergency patches as well, both complicating the process and increasing the risk of unforeseen problems. Patching both as they become available reduces the risk of needing to accept a more complicated emergency deployment.
Of course, all patching must be done in accordance with a quality testing and acceptance process, but additional delay, or worse, ignoring patches altogether, increases business risk. So, include all patches on all systems when reporting on patch levels for metrics. Even if it's in a container that nobody is ever supposed to see that gets rebooted nightly.
One final thought regarding systems patching: security is not the business. It is essential to involve business personnel with responsibility for systems performance in the patching awareness effort, because some patches target the business information processing activities, and not just security or integrity. Business people may want to drive the deployment of certain patches as operational improvement or risk reduction outside of the security envelope. The risk department needs to account for both risk owners when examining the process.