Unpatched systems represent a very serious IT security threat with potentially extremely important consequences, as documented in a large number of high-profile breaches that exploited known unpatched vulnerabilities. Since these vulnerabilities are known, not just to attackers, but also to system administrators, and since patches exist, it is on first look surprising that unpatched systems even exist. The reality, however, is that patching is not that simple: Because of interdependencies, it must be verified that the patch is compatible with everything else in the system, e.g., an operating system patch must be compatible with the applications and databases running on top of the operating system. Sometimes, they are not, as manifested, for instance, in the recent Spectre and Meltdown vulnerability, where some application providers explicitly warned against patching. Verifications mean testing by other vendors, and this may not be a high priority for the application vendor, with an answer or full solution sometimes coming with the next release. Today’s organizations typically employ a large number of systems and applications, and making sure all of them are patched promptly is not automatic.
In light of this situation, organizations need to bolster the first line of defense, i.e., do everything possible to ensure prompt patching and, in addition, prepare a second line of defense to deal with systems that cannot or will not be patched in a reasonable time frame. Such a strategy could entail:
- Involve high-level management who need to be aware of the risk and attempt to obtain contractual guarantees of prompt addressing of patch issues, whether in their system or application or in other systems their own systems depend on. Evaluate vendors in this respect.
- Establish a clear line of ultimate responsibility for patching. This involves appointing someone to monitor and assess the patching risk and empower that person to carry out this task. This involves, among others, an architectural map of the systems, their function, criticality and exposure (e.g., Internet-facing) plus interconnections, as well as a monitoring tool carrying out regular scans with respect to patching.
- Contact the vendors regarding patch testing, compatibility and availability, and possibly carry out tests internally if necessary.
- Propose blacklisting irresponsive vendors.
- Propose and implement (in cooperation with relevant company units) alternative mitigating measures in case patching is not possible in a reasonable time frame. Such measures could involving agents in the unpatched systems to block exploits (although unlikely to be accepted by the vendor), putting patched intermediate servers in the path to the Internet to inspect incoming traffic, and using web application firewalls (WAFs) or sandboxing-type solutions, always taking into account possible performance issues.
- Especially if one must live with unpatched systems, monitoring and responding to rogue activities gains importance.
Read Spiros Alexiou’s recent Journal article:
“Practical Patch Management and Mitigation,” ISACA Journal, volume 3, 2019.
