Expediting the Arduous Security Update Process

Like many of you, I’ve been frantically cleaning up after the Code Red worm and the W32.Nimda virus. I've endured almost 2 months of nonstop troubleshooting, updating, scanning, disconnecting runaway systems from hubs and switches, updating virus scanners and firewall software and rules, and updating the OS, Microsoft SQL Server, and Microsoft Exchange Server. During the past few days, I performed security audits and multiple hotfix updates on at least eight servers. I also trashed several infected Windows 9x systems (hooray, hooray) and encountered numerous problems with Line Print Remote (LPR) -based print shares. What a crazy life.

Using Hfnetchk reports as a guide, I’ve stared with glazed eyes at systems that needed anywhere from 6 to 14 security hotfixes to close vulnerabilities in Windows 2000 Service Pack 2 (SP2), Microsoft Internet Information Services (IIS) 5.0, Internet Explorer (IE) 5.x, and SQL Server 7.0. Although I truly appreciate Hfnetchk’s ability to audit multiple OS components and applications, I can't believe the hoops we must jump through to cross-reference a security bulletin number with a Microsoft article number, locate and download individual hotfix updates, install the updates (either manually or with a script), and perform a final audit to verify that all updates installed properly.

When you go through the hotfix-update cycle for multiple systems, it becomes obvious that several independent teams contribute to the overall effort of developing, publishing, and auditing hotfixes—and it’s quite clear that the teams don’t communicate with one another. Each step makes sense when you evaluate it on its own, but there’s room for some serious integration. Here’s a quick review of the current procedure you must follow when you use Microsoft tools:

  • Download the most current copy of the security hotfix catalog file mssecure.cab, which Hfnetchk uses to audit systems. Run Hfnetchk against a local copy of the catalog and capture the audit in a text file. (Now, where did you save the link to the online catalog?)
  • Plow through the audit report, one hotfix at a time. When you find 14 to 16 updates, organized by OS, IE, SQL, or Exchange, take a deep breath and exhale slowly each time you move to a new line. To find an individual hotfix, you need to locate the relevant security bulletin on TechNet or at the security site and scan the description for the download URL. To accomplish the download, you need to open a text editor to display the audit report and a minimum of two browser windows: one for the master security bulletin list and one for multiple hops to the download page.
  • The download page is typically several pages away from the initial reference, so you might have forgotten which bulletin you were after by the time you reach the actual download page. To refresh your memory, you need to go back several pages to the bulletin announcement, and then forward again to the download page, which is both time-consuming and unnecessary.
  • Sometimes the bulletins provide a Microsoft article reference number (e.g., QXXXXX) as a source for locating the download file. Often, you read through the Microsoft article only to discover that the hotfix is available only as part of a service pack. Worse, the Microsoft article might not include a link to the service pack download, so you come up empty handed after much digging. When the Microsoft article does include a link to a service-pack download site, your original security bulletin list might be long gone—stashed deep down in your browser's history stack—by the time you find and download the service pack. In such cases, it’s easier to start over at the top of the text file and the top of the master security bulletin list.
  • Most of the download files have incredibly long names that needlessly repeat the characters "W2k_sp3_x86_en." Yes, I know the update is for Win2K and that it’s in English. What’s more aggravating is that some hotfixes have random names that don't relate in any way to the bulletin number or the Microsoft article reference number (e.g., the WebDav hotfix rbupdate.exe). If you come across one of these files 2 weeks after you downloaded it, you'll probably have no idea of why you downloaded it in the first place.
  • An arbitrary download gives no indication of the installer the update will use, although I have discovered a slight trend. If the filename includes W2k_sp3_x86_en, it most likely uses the hotfix.exe installer. If you’re writing a script to install a group of hotfixes without rebooting, you need to know which installer the hotfix uses so you can include the correct command line arguments (i.e., to disable the automatic reboot or disable interactive chitchat).
  • Here are several suggestions for Microsoft that would make the hotfix-update process a little less arduous:

  • Clearly indicate at the top of the security bulletin whether the hotfix is available as a standalone update or as part of a service pack update. In either case, place the download link at the top of the security bulletin, not hidden away in the body of the description. When the update is available only as part of a service pack upgrade, provide a link to the most current version of the relevant service pack. The goal here isn't to offer a useless download reference when the download isn't available. I discovered two or three of these when cross-referencing the Hfnetchk audit of recommended hotfixes on a server running SQL Server 7.0.
  • Next, make the download link one page (instead of multiple pages) and position it away from the bulletin description to eliminate the amount of forward and backward browsing it takes to locate and download eight or nine hotfixes.
  • Create a new naming convention for hotfix download files. I recommend that Microsoft start the name of the download file with the related security bulletin number (e.g., MS01-046), include the Microsoft article reference number in the filename, and end the filename with "h" if it installs with hotfix.exe or "m" if it installs with MSDAIPP. With this convention, you could clearly identify which bulletin each download addresses and easily determine whether you have already downloaded the update. Reading a bulletin number is much easier than scanning a list of filenames that begin with Qxxxxxx and end with the same useless string. You wouldn't have to wonder, weeks later, why you downloaded a file called MS01-046-Q320555h, because the filename is revealing. When you wanted write a script to apply multiple hotfixes, you would know exactly which filename to use and which command-line options were appropriate for the hotfix's installer.
  • Use hard URLs, not programmatically generated links that send us deep into the caverns of obscure databases. Hard links are short and easy to track; generated links are a nightmare.
  • My wish list includes a few more features. I’d like to see a group of links to online security evaluation and update services. We have Windows Update, the Microsoft Personal Security Advisor, and more. I want links to security-related tools such as Hfnetchk, the security catalog, and Qchain. Every time I want to download a new copy of the catalog, I have to find the link in the original Microsoft article—it'd be so much easier to click a button and find a direct link to the Hfnetchk catalog mssecure.cab. The ability to search hotfix titles by keyword should be mandatory. I spent a long time trying to locate the unicode update that W32.Nimda exploits because I couldn't perform a keyword search. I didn’t have the bulletin or the Microsoft article number, but I knew the hotfix had "unicode" in the title. I just couldn’t find it without scanning every hotfix title released during the last 12 months. This isn't the best use of my time or yours.

    These are my suggestions. Please read them over and feel free to email me your own recommendations. You might also consider posting your suggestions in the comments section of this article on the Web page. I've heard through the grapevine that Microsoft’s security folks are in the process of redesigning the security Web site, so we have a great opportunity to initiate positive changes. Simple, direct, constructive comments will generate the best results.

TAGS: Security
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.