Welcome

Dan GriffinWelcome to the ninth edition of the JW Secure Informer, our bi-monthly newsletter. This is an opportunity to share what’s on our radar, specifically with respect to enterprise network security, but also regarding IT and business more generally.

The Informer is intended to be useful content and good for a quick read. So if it’s just clutter in your inbox, we’ve failed, and I hope you’ll let us know.
 

Reduce the Monthly Pain of Patching

Security experts might imagine that the highest priority of any IT department would be the immediate mitigation of any important known vulnerability as soon as a patch becomes available. But operations personnel know that any change to a running system brings with it the risk of interruptions to the very service that they are tasked with maintaining. Also, introducing changes to an operating environment can make it incompatible with the applications that enable that service. How then to balance the potential threats from an unpatched vulnerability with the potential threats from the installation of that patch?

To answer that question, JW Secure reached back into its previous work with the National Vulnerabilities Database (NVD). The NVD database is generated by the process that creates and archives all of the Common Vulnerabilities and Exposures (CVE) numbers that show up in software vendors’ patch reports.

In analyzing vulnerabilities on all major operating system (OS), two unfortunate trends became clear: first, that the incidence of reported vulnerabilities has not been reduced on any OS, including the open-source ones. Second, most of the patches required a reboot of a critical service – this guarantees some level of disruption.

However, one approach which promises immediate reduction of service outage is a careful evaluation of the components running on the server. If a software component is not running, then a patch for that component will not require a reboot. Not only that, but less code running on the server means a reduced surface for attackers to target.

Unfortunately, the security bulletins from software vendors offer little help in determining whether a patch will really cause a reboot on the server. Bulletins do, however, often provide a work-around that helps to determine if the vulnerability can be mitigated by disabling the software component that contains the vulnerability.

In summary, here are the two steps that have been shown to empirically reduce the number of reboots from patches by 60%:

  • If the service doesn’t need the functionality of a software component, don’t run that component. If it is only needed occasionally, say for maintenance, don’t keep it running during normal production.

  • Examine each patch as it is released. If the software to be patched is not needed, disable it. The patch should be deferred if possible to some later time when a reboot is needed for other purposes.

Interesting reports on vulnerabilities and patching: