- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Windows Patch Management, Introduction
Patch management is, without a doubt, one of the most critical and complex Windows-security-related issues these days. The problem has become more serious in recent months due to the increased frequency of patches Microsoft has rated as critical, which were followed by exploits taking advantage of underlying vulnerabilities (for a full list of patches, refer to the Security area of Microsoft's Web site). Advancements in patch management have made it easier to keep Windows environments secure. We kick off our Windows Patch Management series with some recent history about patch-related technologies and an overview of general patch management concepts.
This is especially troubling when one realizes that Microsoft altered its security rating system in early 2003 with the introduction of the "important" category (in addition to critical, moderate, and low categories), to reflect more accurately the level of urgency that should be considered when deploying patches. Thus, the "critical" label was reserved only for vulnerabilities that could be exploited by allowing malicious Internet worms to spread without user action.
Pressure from customers, forced to conduct emergency software deployments across hundreds or even thousands of computers, compelled Microsoft to search for means of mitigating such efforts. This resulted in a new patch release cycle that began in November 2003. Rather then being published on weekly schedule (every Wednesday), new patches are now made available for download on the second Tuesday of every month (with the obvious exception of emergency critical releases). While this change makes it easier for corporate IT departments to coordinate their deployment schedule, they must also choose a methodology to enable them to inventory and install patches across all managed Windows systems with extreme accuracy and speed (particularly important, as past examples prove even a few worm-infected computers can seriously impact how the entire network functions).
This series will examine the options currently available as we attempt to make the selection process easier. We will cover free deployment methods (based on Microsoft operating system enhancements, third-party tools, and scripted solutions) as well as fee-based products. This first article will overview developments in patch-related technologies made in the past few years and discuss general patch management concepts.
Microsoft's most rudimentary and popular solution in patch management is the Windows Update, introduced in Windows 2000 (and continued in Windows XP and 2003). Easy to configure and manage (especially after Group Policy improvements were added in Windows XP) based on an agent component running on target systems pulling new patches from predefined locations (by default, a group of Microsoft-managed Windows Update servers), it served home users and smaller businesses well. Unfortunately, it did not fit well in more rigidly structured corporate environments, where changes must be tightly and centrally controlled. In addition, Windows Update was limited to newer operating systems, and an overwhelming majority of desktops and servers were still running Windows NT 4.0.
To allow more selectivity in patch deployment and to address the issue of legacy systems, Microsoft turned its attention to products available from third-party developers. The Code Red and Nimda outbreaks September 2001 most likely triggered that decision. Microsoft addressed immediate needs with the release of the IIS Lockdown utility, automating secure configuration of Internet Information Server; however, it was clear that there was a need for more generic solutions to eliminate other vulnerabilities of Windows operating systems.
Initially, the void in this area was filled by third-party vendors, such as Patchlink (Update Patch Management), GravityStorm (Service Pack Manager 2000), St. Bernard Software (UpdateEXPERT), or Shavlik Technologies (HFNetChkPro). Microsoft contracted Shavlik Technologies to develop HFNetChk, a command-line-based, feature-limited version of its tool that provided only reporting functionality. Although HFNetChk could not fully compete with more comprehensive (including patch deployment capabilities) GUI-based products, it was available for free and allowed patch inventory for not only systems with Windows NT 4.0 and later, but also a number of Microsoft applications, including IIS, SQL Server, Exchange Server, Windows Media Player, and Internet Explorer. Its scanning engine was subsequently used in the Microsoft Baseline Security Analyzer (MBSA), again developed for Microsoft by Shavlik Technologies (its version 1.0 was released in March 2002). Like its predecessor, MBSA is limited to reporting, but it offers enhanced scanning functionality and command-line and graphical IE-based interfaces.
To deliver a cost-effective patch deployment solution to clients that also allows them central control over which patches to install, in June 2002 Microsoft released Software Update Services (SUS) 1.0 (currently at SP1 level -- v2.0 is expected to be released in the first quarter of 2004). Available as a free download, SUS takes advantage of the Windows Update component (which limits it to Windows 2000 and later operating systems) and uses intranet-based, corporate Windows Update servers from which internal client computers pull approved updates. Client update parameters can be set with Group Policies, while server settings are configurable through an intuitive, IE-based interface. Since SUS did not provide any inventory reporting functionality, it must be combined with MBSA or a comparable utility.
Microsoft also developed a comprehensive patch management solution as part of the Feature Pack -- an add-on for Systems Management Server (SMS) 2.0 (although there is no additional charge for the Feature Pack, it obviously requires the purchase and deployment of SMS 2.0 to use it). The Feature Pack combines inventory (its scanning process uses Microsoft Baseline Security Analyzer) and deployment. Additional improvements in the area of patch management have been built into the recently released SMS 2003. Future articles in this series will cover both of these, as well as a variety of similar third-party products.
These advancements in patch management have simplified the task of keeping a Windows environment secure. Although the release of Longhorn, and with it revolutionary changes in this area, is a few years away, recent initiatives from Microsoft bring meaningful improvements. For example, the number of patches that do not require a reboot has been steadily increasing.
The freely available QCHAIN.EXE allows the combination of multiple hot fixes in a single batch (for details and caveats, refer to the Microsoft Knowledge Base article 296861. Microsoft's strategy of limiting updates to only individual patches has been abandoned, which resulted in the release of security Update Rollup 1 for Windows XP in October 2003. This simplifies applying post-Windows-XP-SP1 patches to newly installed systems. It is expected that patches will soon be available in MSI format, which would eliminate the need to create customized packages in environments where Group-Policy-based deployment is used. Perhaps one day Windows Update will even be offered as a Web Service, which would help developers create in-house patch deployment solutions based on .NET technology.
In general, patch management solutions use an approach very similar to inventory and deployment, although, obviously, implementation details vary. Inventory relies on an external database to establish what is considered to be a recommended patch level and provides criteria for validating whether a particular patch has been installed. Products from Microsoft and Shavlik Technologies (on which HFNetChk, MBSA, and SMS 2.0 Feature Pack are based), keep track of published patches on the Microsoft Web site using the same mechanism, based on an XML formatted file called mssecure.xml. This file, available centrally at predefined locations, serves as a template against which the status of updates on target systems is compared. mssecure.xml can be obtained directly or via its compressed, digitally signed version, mssecure.cab. Both files can be downloaded from:
- the Microsoft Web site at https://www.microsoft.com/technet/security/search/mssecure.xml and http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab
- the Shavlik.com Web site at https://xml.shavlik.com/mssecure.xml and http://xml.shavlik.com/mssecure.cab
You can open mssecure.xml in Internet Explorer and examine its content. Starting with version 5, the browser has a built-in XML parser. For older versions, install XML Parser v4, downloadable from http://msdn.microsoft.com/library/default.asp?url=/downloads/list/xmlgeneral.asp. Alternatively, you can use any other tool containing an XML parser, (e.g., the freely downloadable XML Notepad). mssecure.xml contains fairly detailed information about each patch, such as the target operating system version and service pack level, corresponding Microsoft Knowledge Base article and security bulletin reference number, affected product and service pack IDs, registry key to be created, file version, checksum and location, and reboot requirement.
In addition, an overwhelming majority of third-party companies maintain their own mechanisms for verifying whether a patch should be installed (through their own testing procedures) as well as for distributing approved patches. They might also employ custom validation algorithms to determine whether a patch has been successfully installed (Microsoft's and Shavlik Technologies' tools share the same algorithm).
The next article in this series will discuss these features.