Patching Windows servers and workstations is a routine, tedious and thankless IT task. With new updates coming out monthly, it is difficult to get a specific update installed on every system, and there is an ever-present concern of an update unexpectedly breaking something. Organizations address this universal problem in varied ways, ranging from dependence on Microsoft Automatic Update to a variety of patch management products from Microsoft and third-party vendors. Yet how do you know the updates have been widely distributed, applied successfully, and any required reboot has happened?
A periodic verification, even if only on a sample of your hosts, should be conducted to verify your patch management processes or product(s) are working as expected, and that you don't have any common configuration problems compromising your security. If you have no patch management process or product in place, this information can be a great justification to get those things by quantifying the scope and severity of the problem.
One freely available and moderately effective tool to help you gauge your patch management efforts is Microsoft's Baseline Security Analyzer (MBSA).
In addition to detecting missing updates and poor configuration of the operating system, MBSA will examine Microsoft SQL Server and IIS. Microsoft Office updates are also included in MBSA's analysis -- this product suite is frequently overlooked and is a malware vector. It is worth noting that MBSA is essentially a Microsoft sponsored version of a tool called HFNetChk from Shavlik Technologies.
MBSA is simple to install and within minutes of downloading the software you can have a report available showing missing updates and insecure configuration choices. The scan configuration GUI is shown in Figure 1, and the beginning of a report in Figure 2. The documentation at the MBSA website is fairly clear cut, and should be read by anyone using it -- particularly for the caveat about legacy products
The detailed report, shown in Figure 3, lists each update missing from the scanned computer. Each of the updates is linked to a Microsoft TechNet bulletin describing the vulnerability and features a download link for that update.
MBSA scanning best practices
To scan one or more remote computers you'll need to start MBSA on a computer in the same domain as your other computers, using an account that has access to them (such as a Domain Admin). You define the scope of your scan by specifying either a Windows domain or an IP address range. The scan of each computer can take a few minutes to complete, so scanning your entire domain may not be feasible. The results of each scan are saved in the SecurityScans folder within the user profile folder for whichever user ran it. By default this would be C:\Documents and Settings\john.doe\SecurityScans for the user John.Doe.
There is also a command line interface (CLI) version of MBSA, mbsacli.exe, which provides more flexibility than the graphical version. You can, for example, create a text file listing every computer and/or IP address in your scope ("foo.txt") and have MBSA scan those systems via mbsacli.exe /listfile foo.txt. From a practical perspective; if you were responsible for 1,000 computers you could randomly select 50 of them, add those host names to the file for MBSA to scan, and have a decent representation of the whole, assuming patch management processes were similar across the group.
Scripts soothe MBSA reporting shortcomings
MBSA generates one report per computer examined; a feature that does not scale well. A set of Microsoft-provided scripts solves this for you by parsing and consolidating the output for you. The scripts also provide concurrent scanning through multiple MBSA instances. Using the program multmbsa.exe, bundled with those scripts, you can scan up to 64 computers simultaneously. The documentation provided with the scripts offers ample explanation for their use and is well worth the few minutes it takes to skim through.
The Microsoft scripts parse all of the MBSA output (default location) and create a consolidated XML file. Since the scripts parse all of your MBSA data, be sure to move any old scans out from the default location. You can open the XML file in Microsoft Excel and generate charts and tables as desired. Assuming you've downloaded and extracted the scripts and have MBSA scan output, you can get started with the command "cscript.exe /nologo rollup.js -b >everything.xml". Next open everything.xml with Excel, using the default "as an XML List" option.
The Excel worksheet will show a list of every check performed, the Microsoft Knowledge base ID (KBID), the number of machines found, the machine name, and the path to the detailed MBSA output file for that computer. A few minutes' work in Excel with pivot tables can turn that tabular data into a more useful summary chart as in Figure 4. These summary views are powerful because they allow the IT admin to describe the security posture of the collective environment, rather than as a few individual hosts.
Although reporting on the success of your patch management process is not a particularly glorious task, this information is a key IT performance measurement. Tools such as MBSA give the system administrator the ability to go beyond anecdotal "we're doing great/awful/other" statements and effectively summarize the current state of the Windows environment with quantitative accuracy. Once you know how well IT is (or is not) at patching and configuring systems, you can search for and address the root causes for any problems and improve IT operations while securing your environment.
Tom Chmielarski is a senior consultant with GlassHouse Technologies, Inc. Send comments on this tip to editor@searchmidmarketsecurity.com.
