Patch Management
By Randy Franklin Smith, CISA, SSCP, Microsoft Security MVP
See other Security MVP Article of the Month columns.
Patching is an indispensable component of a secure, controlled environment. No matter what other controls you have in place, some risks may only be addressed by a patch. But that doesn’t mean organizations should load every patch to every system as soon as it is released. Despite vendors’ best efforts, patches can introduce instability or compatibility problems. Some patches require a reboot, which can be difficult to schedule on busy servers. Testing a patch in your environment before full-scale production deployment consumes resources. Therefore, many organizations refrain from loading patches on systems that are not vulnerable because other controls are in place that make exploitation very unlikely. Such decisions are a balance of many factors. For my Patch Tuesday Newsletter, I analyze every Microsoft Security Bulletin and weigh these factors in the recommendations I issue. I’ll discuss some of the key factors in this article.
Attack surface reduction pays off. When you disable unnecessary services and features and uninstall unneeded components, you are reducing the attack surface of the system. This reduces the number of points that are vulnerable to attack. Attack surface reduction (ASR) also provides auto-immunity to undiscovered vulnerabilities in components and features that you disabled. Do you even need to load such patches? Some would answer yes out of fear that the affected component could become re-enabled accidentally or by a local administrator. But even for “paranoid” level security environments, auto-immunity gained through ASR at least reduces the urgency to rush patches onto systems with little testing. And at best, ASR can eliminate the need to load some patches onto many systems.
Don’t treat servers like workstations. Workstations are dirty machines—not because they aren’t in the filtered environment of a computer room, but because their users constantly rub shoulders with the “unwashed masses” on the Internet, visit all manner of sites, and routinely open documents and download other files from untrustworthy sites. All of this exposes workstations to malware and content-based attacks.
For at least two years, the majority of security updates have been what I call “workstation” or “interactive” vulnerabilities. By this I mean the risk is almost totally limited to activities that an end-user performs while logged on interactively. These include Web browsing, reading e-mail, and opening documents, images, or video files. These are all activities particularly vulnerable to malware or content-based attacks (e.g., a cross-site scripting attack buried in a Web page). Most of these vulnerabilities have no practical work-around and require that a patch be installed on all workstations.
But you may be able to avoid loading these patches on servers if you can ensure that administrators will refrain from the activities described above, while logged on interactively or through Terminal Services to a server. Other than through written policy and reminders, how can you get such assurance? The first step is, wherever possible, to disable servers from accessing the Internet. Second, periodically verify that interactive, end-user applications like MS Office are not installed on servers using your software inventory system. Some organizations go further by using the security log to monitor the executables run on a server. See www.ultimatewindowssecurity.com/events/com215.html for an explanation of event ID 592, which reports new processes as they are started.
There are caveats to classifying vulnerabilities as “workstation only.” Some server applications like WSUS or antivirus servers need to access the Internet to download updates. But if you have a controlled Internet access gateway such as an ISA server, you can control such access and help prevent interactive users from browsing other sites. Likewise, some servers need what are typically considered end-user applications to support custom-built processes that use OLE automation. Finally, you normally need to patch Terminal Services servers that are accessible to end-users as if they were workstations, because end-users will likely engage in activities that make the server vulnerable to workstation-type risks.
Responsible disclosure. The infosec community and Microsoft made progress in emphasizing the importance of making vulnerabilities public and releasing patches and how these have benefited the user community. The idea behind responsible disclosure is that if you discover a vulnerability, before going public with it, you should give vendors appropriate time and opportunity to build a patch or workaround so that customers do not needlessly find themselves exposed to a vulnerability with no patch available. Unfortunately, some vulnerabilities are discovered by malicious individuals or those who don’t agree with responsible disclosure, and in those cases the vulnerability and its exploitation details come to light without warning.
When analyzing a vulnerability and how urgent it is to load the patch, take note of whether the exploit details (i.e., proof-of-concept code) of the patch are public or not. If proof-of-concept code is publicly available, it stands to reason there is a much higher chance of being attacked through that vulnerability, which, in turn, increases the urgency for getting the patch installed on exposed systems.
Related to the disclosure issue is whether the vulnerability is actively being exploited in malicious attacks or if there are reports of malware that use the vulnerability. Again, such reports may increase the urgency and reduce the amount of testing you perform.
Deciding whether to load a patch and which systems should receive it is a function of the issues discussed in this article as well as certain factors about your organization and its management’s risk posture. Don’t forget that sometimes the issue isn’t whether to patch or not to patch, but exactly when to patch. If exploitation how-to details are not public, you have more time to test the patch and make sure it doesn’t introduce availability problems. On the other hand, if there are already reports of a fast-moving worm that exploits the vulnerability, you may choose to install the patch to critical and exposed systems without any testing. Patch management is about loading the necessary patches to systems that need them as soon as possible without disrupting your production environment.
Randy Franklin Smith is a CISA, SSCP and publishes the free Patch Tuesday Observer e-mail newsletter. Randy is the creator of the Ultimate Windows Security seminar series and author of the free Security Log Encyclopedia. He writes extensively for Windows IT Pro as a contributing editor. You can reach him at rsmith@ultimateWindowsSecurity.com.