A little more than one week from now Microsoft will be releasing their monthly security updates. A recent security standard stated fairly bluntly that “relevant security patches need to be installed within one month of release”. Other standards are much less specific and define regulations regarding process, but not necessarily result. Perhaps today makes for a good time to have a look at patch management in general.

Good patch management is rooted in understanding your assets and understanding the threats. An organization needs a correct and up-to-date configuration management database, as well as a way of learning about new vulnerabilities and patches. Many vendors now offer ‘security intelligence’ services that provide prior notice of security vulnerabilities, and most of this information can also be obtained from open sources – such as this website. Patch information is generally available as part of a maintenance contract with software and hardware vendors.

The difficulties usually lie in understanding our own organization. An open question of many security professionals is how we can get sufficient understanding of both the tools that have been deployed legitimately for business reasons and of any software that has been installed – perhaps illegitimately - by end users. Even though eloquently formatted policy statements may forbid installation of unsupported software, these statements are of little use should such a tool lead to a significant compromise.

Software can be used to assist: tools such as Microsoft’s Systems Management Server can support central management of legitimate software, while vulnerability scanners such as Nessus, simple port enumeration tools or dedicated software agents can be employed to do enterprise software discovery of those less predictable assets.

By correlating deployed software with new vulnerabilities and engaging in thorough risk analysis, an organization can identify the importance of each issue, and decide on the required response time. However, not every vendor releases its patches according to a fixed schedule, and a new critical patch may be released on any given day. Rarely can they as such be installed immediately. New patches are usually initially reviewed by an information security team that may not have decision power over the availability of crucial business assets. Even if they would, the patches would need to be tested on quality assurance systems prior to deployment on business systems.

Our organization will need to mitigate the risk posed by the security vulnerability prior to the installation of a patch. This matches with real-life security risk management. When indication is given of an imminent security threat, the decision is often made to provide additional monitoring to enable either quicker response or perhaps prevention of the issue. The issues European travelers experienced last year in August when passing through London Heathrow after the discovery of a bombing plot, serves as a good example. During the initial highly costly monitoring phase, longer-term solutions were investigated and prepared for implementation – in this case the complete disallowance of fluids on board, and boosting development of technology to detect liquid explosives.

From my experience with how organizations deal with patches, I’ve noticed not too many of them are actually prepared to evaluate what they can do to mitigate an INFOSEC threat prior to the implementation of a patch. This component of vulnerability management is however becoming more and more important – recent examples have confirmed that in some specific vulnerabilities an exploit was in fact released some time prior to a patch.

One major vendor recently had a good idea in this respect. As part of their security advisories, they started releasing “Applied Intelligence Response” bulletins. These provide information on actions that can be taken to mitigate a certain vulnerability, but also provide hints on how to detect exploitation in progress. An organization that is still scheduling the deployment of a required fix, for example, now has the opportunity to deploy network-wide monitoring and hook this into their incident response process.

Do you have any stories or hints you want to share on how you or your organization deals with the time between vulnerability and patch installation? Get in touch!

Good references:

The NIST on creating a patch and vulnerability management program

GAO on effective patch management

 --
Maarten Van Horenbeeck