Looking Beyond Windows for Patch Management

By Marcin Policht | Mar 26, 2004 | Print this Page
http://www.enterprisenetworkingplanet.com/netsysm/article.php/3332051/Looking-Beyond-Windows-for-Patch-Management.htm

Our look at patching solutions closely integrated into Windows operating system and offered by Microsoft free of charge. The mechanisms discussed so far — Critical Update Notification, and its successor, Automatic Update — are fairly easy to implement and manage (using the methods we have presented). They come with several significant drawbacks, however.

First, they offer no control over which patches should be deployed, and they are limited to weekly or daily updates. While you can configure different registry settings across groups of clients to accomplish multi-stage deployment (by applying different group policy objects to different sets of computers using WMI or security-based filtering), with larger number of clients this might be difficult to maintain. Further, they offer no reporting functionality to enable the admin to determine the rate of success (or failure).

One way to control which patches are being deployed and when deployment should start is to install patches using the Software Installation portion of Group Policies. (This approach, however, cannot be used with legacy, pre-Windows 2000 systems, which are not Group Policy-aware.) Using Group Policies this way requires the creation of Windows Installer-based packages (in the .MSI format), which can be done with some of the free utilities provided by Microsoft, such as SMS Installer or WinINSTALL LE (which are cut down versions of commercial, third-party products) or more sophisticated (and fairly expensive) tools, such as InstallShield or Wise for Windows Installer. Once a package is created, you must configure the Software Installation node in the Computer Settings portion of a Group Policy Object. Automatic Update must then be disabled on client computers.

The one downside to this solution is that it lacks reporting capabilities.

To fill this gap, Microsoft brought in an independent company -- Shavlik Technologies -- to develop an appropriate utility. Shavlik developed HFNetChk (the acronym is derived from HotFix Network Checker), which is a feature-limited version of its flagship product, HFNetChkPro (and the equivalent of Shavlik's free tool, HFNetchkLT). The command line utility can be used only for inventorying security patches; unlike the full-featured HFNetChkPro, it does not allow actual updates. Another advantage of HFNetChkPro is that its scope extends beyond the range of operating systems and products supported by Windows Update. For more information on its capabilities and its syntax, refer to Microsoft Knowledge Base article 303215.

Not long after its release, HFNetChk was superseded by the Microsoft Baseline Security Analyzer (MBSA) now in v1.2 and offering graphical and command line interfaces as well as the ability to evaluate security patch level and system configuration status (but it is still limited to reporting capabilities, and lacks actual update functionality). MBSA's system configuration checks include features like password policy, local Administrator group membership, unnecessary services (a list that can be customized by modifying content of the Services.txt file located in the MSBA installation folder), type of file system, guest account status, and a number of others related to products or services installed on the target computer (e.g., IIS, SQL, and Office).

The full list of programs supported by versions 1.2 and 1.1.1 of MBSA is found in Microsoft Knowledge Base article 306460.

Although Microsoft no longer offers HFNetChk for download (the updated version is obtainable from Shavlik), you can expose its functionality by launching the MSBA command-line interface MSBACLI.EXE with the /hf switch. Microsoft recently released version 1.2 of MBSA. Enhancements include support for French, German, and Japanese (in addition to English), and improved product detection for missing security updates and system configuration checks (such as Internet Configuration Firewall, Automatic Updates, and IE zone configuration). MBSA 1.2 can be installed on Windows 2000, XP, and 2003, but its inventory also covers Windows NT 4.0, along with system components and services such as Microsoft Access Data Components (MDAC), MSXML, Microsoft Virtual Machine, Windows Media Player 6.4 and later, Internet Information Server 4.0 and 5.0, Internet Explorer 5.01 and later, Office 2000 and later (for local scans, only), SQL Server 7.0 and 2000, Exchange 5.5 and later, Commerce Server, Content Management Server, BizTalk Sever, and Host Integration Server.

Both MBSA and HFNetChk rely on information provided in an XML file named mssecure.xml, which, by default, is circulated in a compressed and digitally signed cab file version (mssecure_1033.cab for English language based scans), although you can force use of an XML decompressed file by applying -x switch to the HFNetChk or MSBACLI.EXE running in HFNetChk mode. The most recent version of the file is downloaded automatically as soon as either tool is launched and cached locally (in case Internet access is not available during future scans). As explained in the first article of this series, there are two primary sources of mssecure.cab and mssecure.xml:

Continued on Page 2: MBSA vs. HFNetChkContinued From Page 1

Shavlik's distributed tools are, for the most part, downloadable from files on its Web site, while HFNetChk and MBSA use Microsoft Web servers as the source, which, unfortunately, sometimes leads to inconsistent scan results.

For these tools to operate properly, a user who initiates a scan must be member of the local Administrators group on the target computers. Remote systems should have enabled Server service, Remote Registry service, File and Print Sharing, and default administrative shares. MBSA also requires an XML parser, which is included with IE 5.0 or later and can be added to IE 4.0 by installing MSXML 4.0 SP1 downloadable from http://www.microsoft.com/xml. When scanning computers residing behind a firewall, TCP ports 139 and 445, and UDP ports 137 and 138 must be open.

When a scan is initiated, MBSA and HFNetChk compare their own version number against the version specified in the XML file (they must match), check the version and locale of the operating system, service pack level, components, and applications installed. Based on this information, applicable security patches are determined. The tools also examine the content of registry keys under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates (the remaining portion of the path depends on the operating system version on the target machine) to determine whether patches are already present on a target system. If the registry key cannot be located, the assumption is that the patch has not been installed, and it is reported missing. The registry check can be bypassed by running MBSACLI.EXE in the HFNetChk mode with /z switch -- i.e., MBSACLI.EXE /hf /z). Skipping the registry check might be useful if you have reasons to believe a particular patch has been installed. This way, the tools ignore the lack of a registry key and progress to the next stage of the check. At that point, the target file version and checksum are compared against its information in the XML file.

As we already indicated, Microsoft Baseline Security Analyzer can be launched in three modes:

  • graphical (MBSA.EXE) launches directly from the All Programs menu or from the installation folder (Program Files\Microsoft Baseline Security Analyzer). In this mode, /baseline and /nosum switches are applied. The /baseline switch triggers check for Windows security updates rated as critical, and the /nosum switch skips checksum file checks (which speeds up scan and limits bandwidth use when running the tool against remote computers). The results of the security scans are stored as an XML-formatted file in the SecurityScans subfolder in the profile directory of the user who launched the scan. The /f switch, followed by the path and name of an output file, can change these defaults.

  • command line (MBSACLI.EXE) offers flexibility and scriptability. Typing MBSACLI.EXE /? in the Command Prompt window generates a full list of command line options. Like the graphical version of MBSA, the results of the scan are stored as an XML-formatted file in the SecurityScans subfolder of the profile directory for the current user.

  • HFNetChk (MBSACLI.EXE /hf) exposes HFNetChk functionality, with all of its command line switches. This is helpful when transitioning to MBSA from environments where HFNetChk was the primary patch scanning tool, potentially referenced across many custom administrative scripts. The results are displayed in the text format in the Command Prompt window from which the tool was launched. Results can also be redirected to a text file by applying /f switch and defining its format with the /o switch.

Important to note:

  • By default, both tools will attempt to download the most up-to-date copy of mssecure.cab from the Internet servers; however, they will fall back to the locally cached copy (residing in the Microsoft Baseline Security Analyzer installation folder) if the download fails. Alternatively, you can point to the MSBACLI.EXE running in the HFNetChk mode to a specific location of mssecure.xml (or mssecure.cab) file by adding -x switch (i.e., by running MBSACLI.EXE /hf /x mssecure.xml or MBSACLI.EXE /hf /x http://myWebServer/mssecure.xml).

  • Instead of scanning patch level against the list contained in mssecure.xml, you can point both tools to Software Update Services servers on the local network (a solution to be discussed in greater detail in future articles). This limits the scope of the scan to only those patches explicitly approved. This behavior is invoked by applying /sus switch, followed by either the name of a SUS server or the location of ApprovedItems.txt file (which contains the list of approved patches), for example, MBSACLI.EXE /sus http://MySUSServer or MBSACLI.EXE /sus http://MySUSServer/ApprovedItems.txt. If the server or file name is not specified, MBSACLI.EXE will attempt to extract the information from the registry on the scanned system (HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer entry).

  • When connecting to remote computers, you have an option of specifying alternative credentials (i.e., MBSACLI.EXE /hf /u domain/username /p password).

  • You can scan individual hosts (i.e., /i when using IP address and /c when using NetBIOS computer name in the format domain\computer), a range of computers (i.e., /r IPStart-IPEnd when scanning IP ranges), or an entire domain (i.e., /d domain name option). In the HFNetChk mode, you can also specify a list of computers to be scanned by naming them directly in comma-separated format (MBSACLI.EXE /hf /h computer1,computer2,computer3), or including them in a file, with one computer name per line (MBSACLI.EXE /hf /fh filename) or one IP address per line (MBSACLI /hf /fi filename).

Future articles in this series will discuss a number of Microsoft patch deployment products (such as Software Update Services and Systems Management Server) that use technology implemented in MBSA to evaluate patch level before sending updates. Unfortunately, this approach is not fully consistent. Most notably, the mechanism that Windows Update uses is different from the one implemented in MBSA, which occasionally results in patches not being properly installed.