Keeping ahead of security risks requires new approaches
The MSBlaster worm, which exploited vulnerabilities in the Windows OS, brought the challenge of patch management to the forefront again. And discussions about who's to blame for security breaches and who's responsible for making sure systems have the latest software updates and patches once more heated up.
What Is Microsoft Doing?
According to Scott Culp, senior security strategist from Microsoft's Trustworthy Computing Team, Microsoft is in a full-scale effort to improve its patch-management software and practices. "First, we need to reduce the need for patches," Culp told me. Through its Trustworthy Computing and source-licensing programs, Microsoft is trying to make its software more secure.
Next, Microsoft is engaging in a companywide effort to consolidate patch management, which includes patch scanning, reporting, and installation. For example, Microsoft Baseline Security Analyzer (MBSA), Systems Management Server (SMS), Software Update Services (SUS—see "Secure Your Clients with SUS," page 81), Windows Update, and Office Update all scan, report, and apply patches differently. Microsoft plans to reduce the number of installation technologies from eight to two—one for installing OS patches and one for installing application patches. Microsoft plans to reduce the number of scanning and reporting technologies to one set of APIs, built in to Windows.
"The \[Microsoft\] patch-management task force has representation from each major development group to ensure that the new consolidated patch management system will work on its own product sets," Culp said. These groups include all Windows versions plus Pocket PC devices.
Here's a simple comparison: Suppose a small business is running Microsoft Small Business Server (SBS) with 10 PCs, and the systems administrator wants to determine whether those 10 PCs have applied an important security patch. Today, that administrator might choose to access each PC and check the registry entries or DLL date stamps and timestamps. With a consolidated patch-management system, the administrator would simply access the SBS system to get both a report of the software status of each device and the required patches necessary to make those devices current. Such a consolidated approach would save an administrator significant time and energy in keeping servers and attached devices current.
The PatchLink Model
I also spoke with Sean Moshir, CEO of PatchLink, a company that since 1996 has been building an enterprise-level patch-management system that covers not only Microsoft software but also UNIX, Linux, Solaris, and NetWare. In a nutshell, the PatchLink system requires a PatchLink server as well as a PatchLink agent on each supported device (e.g., servers, PCs, Pocket PCs). The patch server is kept up-to-date with the patch status of each connected device. The PatchLink agent looks for DLL timestamps and date stamps, registry entries, and attributes to ensure an accurate assessment of that device's software status. The PatchLink administrator console is Web-based, so you can run it from a browser against any supported OS. PatchLink also lets you create your own custom patches, lets you undo applied patches, and continually monitors the state of each device. (For more information about this product and six other patch-management solutions, see "Enterprise Patch Management for Windows," page 45.)
Here's how PatchLink processed the patch that prevented its customers from receiving the MSBlaster worm. First, the PatchLink centralized server at PatchLink's headquarters downloaded the Microsoft patch. Next, PatchLink tested that patch in its 250-computer test facility. PatchLink assigned to the patch a unique ID and signature that described the relationships among the software programs needed to apply the patch. The patch, the ID, and the signature were packaged together into a PatchLink object. Customers then downloaded the PatchLink object from the PatchLink central server into a PatchLink local patch server. The patch server created a report of all the devices that needed the patch and let the administrator schedule the patch installation. The server and agent worked together to apply the patches and report the updated status.
Where Is Microsoft Heading?
I think PatchLink's system is a fast-forward look at where Microsoft's patch-management system is headed. Although Microsoft's goal is to patch all Microsoft software, Microsoft hopes that third-party Windows applications will use its future patch-scanning API, too. Chances are zero that Microsoft's patch-management system will encompass Linux or Solaris, so it will never provide a total solution. But any movement toward a centralized patch-management system is needed and welcome.