Committed to its new Strategic Technology Protection Program (STPP), Microsoft has increased the development and support of products surrounding its software update and security process program. Recently released update-focused products include Microsoft Software Update Services (SUS), Windows Update, and an update handler for Microsoft Systems Management Server (SMS) 2.0. Microsoft has targeted these products, which scan and automatically deploy updates to your systems, to large, comprehensive deployments. To complement these patch-deployment systems—or to implement a simple update-detection system—you can use the small yet agile and feature-packed Microsoft Baseline Security Analyzer (MBSA) to regularly scan your network. MBSA not only scans local and remote systems for patch-update status but also performs more than 65 vulnerability-scanning tests specific to Microsoft products. And although MBSA doesn't patch your systems or plug your holes, the product's fast and lightweight approach provides a quick and efficient method for canvassing your systems for common vulnerabilities.

No stranger to update scanning, MBSA provides the scanning engine that the enterprise-focused SMS SUS Feature Pack uses. MBSA also supports vintage HFNetChk functionality. HFNetChk, MBSA's predecessor, enables local and remote scanning of Microsoft OS security updates, as well as updates for Microsoft's enterprise applications such as Microsoft Exchange Server and Microsoft SQL Server. To extend HFNetChk's functionality, MBSA features product security scans that search for known OS misconfigurations that can result in system vulnerabilities.

MBSA includes both a graphical front-end version for ad hoc scanning and a script-friendly command-line interface version. MBSA saves its scan results in an easy-to-read XML format, further increasing the product's usefulness by letting you write custom reports that fit your needs.

MBSA Compatibility
Microsoft released MBSA 1.1.1 in June 2003. Although you must run this version of MBSA from a Windows XP or Windows 2000 computer, you can remotely scan XP, Win2K, and Windows NT 4.0 systems. (MBSA doesn't support the scanning of Windows Me or Windows 9x systems.) Using one scanner to scan multiple Microsoft products presents a challenge because of update-format compatibility problems. Microsoft uses multiple update engines and processes for many of its products, and until the company concentrates on one method, many of its update tools will work with only specific products. (For example, the Microsoft Office update tools work differently from the Windows Update tools, resulting in incompatible update-distribution methods.) Despite these challenges, MBSA supports security and update scanning for the Microsoft products that Table 1 lists.

MBSA Installation and Configuration
MBSA installation is a snap. Download the mbsasetup.msi Windows Installer (.msi) file from the MBSA Web site (http://www.microsoft.com/technet/security/tools/tools/mbsahome.asp). This site contains detailed information about MBSA, including descriptions of the MBSA scans and an FAQ that addresses how MBSA interoperates with other patch-deployment systems (e.g., SUS).

By default, the setup program installs MBSA in the C:\program files\microsoft baseline security analyzer directory. This folder contains the MBSA executables mbsa.exe and mbsacli.exe, which provide the GUI and Command Line Interface (CLI) to the scanning application. The installation directory also contains the HTTP and Extensible Style Language Transformations (XSLT) templates that MBSA uses to format and display the built-in reports. A Help directory provides comprehensive descriptions of each test that MBSA performs.

The MBSA folder contains several configurable text files, with which you can instruct MBSA to perform a more customized audit of your environment. The services.txt file includes a list of services that MBSA monitors and reports on. By default, MBSA reports on the MSFTPSVC, TlntSvr, W3SVC, and SMTPSVC services. To have MBSA report on additional services, add the appropriate short service names to this file. A second text file, noexpireok.txt, lists the account names that MBSA won't report as potential security problems (e.g., accounts that have passwords set to never expire). For example, by default, MBSA doesn't report on the IUSR_* or IWAM_* accounts. You can configure MBSA to skip specified accounts.

Every time you run MBSA, the program attempts to download a file called mssecure.cab from Microsoft. This compressed .xml file contains all the most recent software updates. Optionally, if you host an SUS server, you can direct MBSA to obtain its list of approved updates from that server instead of directly from Microsoft. Consequently, your reports will reflect only missing updates that you approved with your SUS server. MBSA's ability to reference and use your list of previously approved SUS updates helps you enforce your corporate update policy without the distractions of false positives from unapproved updates. For example, you might use SUS as the gatekeeper to manage the rollout of new updates to your end users. After you've assessed the applicability and tested the compatibility of a particular update, you approve its deployment through SUS. Then, depending on your environment's SUS configuration, end users' computers will either automatically download and install the patch or download and prompt users for manual installation. To enforce your update policy, use the graphical MBSA or the command-line Mbsacli utility to scan your end users' computers for missing updates. Schedule MBSA to run weekly and pull its list of updates to check from your SUS server's list of approved updates. The resulting XML reports will show you which systems haven't been successfully updated with your specifically approved updates.

To perform all the MBSA-supported scans, you need Local Administrator privileges on the target systems. Run mbsa.exe to launch the scanner's graphical version. This version gives you a simple-to-use interface with which you can quickly specify which scans you want to run and which computers you want to run them on, as Figure 1 shows. First, to specify the targets of your scan, click Pick a computer to scan or Pick multiple computers to scan, then enter an IP address, a range of IP addresses, or a domain name. (If you select targets by domain, MBSA might miss some computers, so you might try the seemingly more reliable method of entering a subnet range.) Next, select the scan options, such as checking for Windows vulnerabilities, weak passwords, Microsoft IIS vulnerabilities, SQL Server vulnerabilities, or security updates. Optionally, you can specify an SUS server to which MBSA will look for its list of software updates to compare with each client. Otherwise, MBSA will use the list of all updates that Microsoft provides. By default, the graphical MBSA client performs what Microsoft calls a baseline scan, which scans for and reports on only critical updates (as Windows Update defines them), as opposed to all security updates.

Start Scanning
To begin a scan, click Start scan. The length of time a scan takes depends on which options you've chosen. For example, in my environment, scanning a variety of services on a 16-computer network, including IIS, SQL Server, and Exchange, took about 5 minutes. By default, MBSA writes the security reports to the \%userprofile%\securityscans folder as .xml files. MBSA creates a separate XML report for every computer it scans—every time it scans the computer. These reports are generally about 20KB in size. I explain a little later how you can write a routine to import and aggregate the data to create a cross-computer report.

After you run the scan, click Pick a security report to view and select the name of the report you want to view. Although MBSA lets you sort by computer name, IP address, and scan date, you might find yourself deleting old reports to keep them from cluttering your folder after you've run multiple scans.

Be forewarned that when you first run MBSA on your network, you might find the vulnerability scan reports disconcerting. Out of the box, XP, Win2K, and NT computers all fail the MBSA scan with a Severe Risk security rating.

So Many Holes, So Little Time
As I mentioned, MBSA doesn't provide report aggregation, so you must select an individual computer's report to view. Click the name of a machine whose report you want to view. MBSA displays a summary report that lists vulnerabilities and missing patches for that computer, as Figure 2 shows. For many discovered problems, MBSA lets you drill down into the report to obtain further details. For example, if MBSA reports that the Password Expiration test failed, you can click Result details to see the account names that have nonexpiring passwords. Additionally, the What was scanned and How to correct this links give you direct access to the MBSA Help files, which not only describe the discovered problem but also show you how to remedy it and find additional information on the Internet.

MBSA organizes the summary report into five sections: Security Update Scan Results, Windows Scan Results, Internet Information Services (IIS) Scan Results, SQL Server Scan Results, and Desktop Application Scan Results. MBSA further breaks down these sections by vulnerability and provides system information for all the tests that Web Table 1 (http://winnetmag.com/windowssecurity, InstantDoc ID 41275) lists. For example, under Windows Scan Results, MBSA classifies a non-NTFS partition or an enabled guest account as a vulnerability and classifies particular audit settings, service status, and shares as additional information. MBSA reports the scanned computer's shares, as well as the share-level and directory-level ACLs set on those shares.

The GUI limits you to specifying one computer by name or IP address or multiple computers by a range or domain membership. You can't, for example, define and scan a group of computers by type (e.g., production servers versus employee machines) or by name matching (e.g., sea* or www*). The MBSA command-line version overcomes many of these limitations through flexible command-line arguments, around which you can create scripts.

Command Line, Anyone?
The command-line version of MBSA supports two syntax structures: a command-line equivalent of MBSA and a syntax that matches that of the popular command-line patch-checking tool HFNetChk. (In fact, MBSA replaces the standalone HFNetChk tool.) Run the Mbsacli /? command for a listing of command-line options and the Mbsacli /hf /? command for a listing of arguments that this pseudo-version of HFNetChk supports.

The console-based Mbsacli lets you use command-line arguments to specify most configuration options. Therefore, you can use any Windows scripting technology to script a wrapper that calls Mbsacli to scan multiple systems or networks.

You can even schedule a scan to regularly check the status of your domain or specific computers. For example, you can schedule a scan to check your subnet for security misconfigurations but omit update scanning, as follows:

mbsacli /n updates /r 192.168.0.1-192.168.0.254

The /n argument instructs Mbsacli to skip a particular scan. In this example, Mbsacli won't scan for updates. You use the /r argument to specify a range of IP addresses. A second scan that reports only missing updates on one computer might look like the following:

mbsacli /n os+sql+iis+passwords /i 192.168.0.10

Microsoft understands that many people want to script or schedule such scans, so the product provides several output-suppression and output-redirection options. The following command redirects the scan output to the network share \\wkstn\logon and writes it to the scan.txt file:

mbsacli -f \\wkstn\logon\scan.txt -c blvu\dc1

You can use the following command to configure MBSA to pull the list of updates to check for from your SUS server's list of approved updates:

mbsacli /sus "http://susserver" /i 192.168.0.10

Viewing Reports
Mbsacli doesn't display verbose scan details to the console, as HFNetChk does, but instead displays a summary of results, as Figure 3 shows. However, Mbsacli generates the same XML reports that the graphical version of MBSA creates and also supports command-line arguments for listing and displaying these reports. For example, the Mbsacli -l command lists all XML reports that reside under the user profile (\%userprofile%\securityscans) of the person running the command, as Figure 4 shows. You can use the -ld report name option to access the reports. For example, using the data from Figure 4, you could use the following command to display the most recent scan of the computer called svr:

mbsacli -ld "Blvu - svr (05-30-2003 05-36 PM)"

This command displays a text interpretation of the XML report that you can parse, although using XML scripting technologies to directly extract the data provides greater flexibility and control over the data.

MBSA as HFNetChk Replacement
Although HFNetChk doesn't provide the security checking or XML reporting that MBSA offers, it does provide a quick and easy method of listing all of a specific computer's missing updates. Whereas MBSA defaults to performing baseline scans, HFNetChk scans all security-related updates. You can use the -b switch to force HFNetChk to perform a baseline scan, as follows:

mbsacli -hf -b

If you want to simply view all of a specific server's missing security updates, run the command

mbsacli -hf -h wkstn

where -hf instructs Mbsacli to use the HFNetChk argument parser and -h wkstn specifies the host named wkstn. The output of this command displays all the missing updates. MBSA (both the graphical and command-line versions) displays Note and Warning messages when it can't determine whether an update has been installed or perhaps to notify a user of a security problem that an update can't fix. For example, if an update exists for both Microsoft XML Core Services (MSXML) 4.0 and MXSML 3.0 and the target machine has MSXML 4.0 installed, MBSA might display a Note informing you that the MSXML 3.0 update hasn't been installed. The Microsoft article "Hfnetchk Returns Note Messages for Installed Patches" (http://support.microsoft.com/?kbid=306460) lists the explanations behind many of these Notes and Warnings.

MBSA reports these notes for every scan. However, you can use the -s n argument to disable Notes and exclude them from your reports. Use the -s 1 argument to suppress Notes, and use -s 2 to suppress both the Notes and the Warnings.

Parsing the XML Reports
In its current version, MBSA provides one XML report for every scanned computer. Manually wading through these files can be burdensome. Fortunately, because MBSA saves these reports in XML, you can open them in an XML-aware application or create a script to parse through the files and extract specific data. For example, you can use Windows Script Host's (WSH's) FileSystemObject to loop through each file in the folder that contains your reports. For each file, use the XML Document Object Model (DOM) to load the XML document. Then, loop through and display only those elements that match a part of the report that interests you.

Although the reports are sometimes long, they're broken into hierarchical elements, so interpreting them is logical and straightforward. The <Check> node, which contains the report data for a particular test, includes an ID attribute that defines that test. The <Check> node might be located directly under the root node or beneath the <SQLInstance> node. For example, <Check ID="115" ...> corresponds to Windows security updates and <Check ID="10212" ...> corresponds to SQL Server security updates. Web Table 1 lists all the tests that MBSA performs. Expanding a node provides a particular test's detailed results, which you can further parse for a specific update. For great XML primers that include sample code, visit the Microsoft Developer Network (MSDN) library. (A good place to begin is the "XML DOM User Guide" at http://msdn.microsoft.com/library/default.asp?url=/library/enus/xmlsdk30/htm/xmconxmldomuserguide.asp. The document provides an example of loading an XML document but requires a bit of Windows scripting knowledge.)

MBSA Limitations
Although MBSA performs admirably as an all-in-one update-checking tool and basic Microsoft product security-configuration checker, it has limitations. MBSA doesn't scan for Office updates or updates that aren't related to security, so you'll need to rely on other tools to report those updates. MBSA is strictly a scanner and doesn't deploy patches or remediate misconfigurations. (However, it provides useful Help documents that walk you through the remediation of any discovered vulnerability.) For an update scanner that includes more robust patch-management features for as many as 50 computers, check out the free HFNetChkLT tool from Shavlik Technologies, the creators of HFNetChk. HFNetChkLT provides the same capabilities of its commercial sibling, HFNetChkPro (with the exception that HFNetChkLT lets you scan only 50 computers).

Both HFNetChkLT and HFNetChkPro support robust update scanning, patch distribution, and graphical reporting. They also support logging to a SQL Server database and scanning for Office updates. Although they don't offer the vulnerability-scanning features of MBSA, they extend patch management beyond MBSA's current capabilities and provide an aggregated view of missing patches across your organization. You can obtain HFNetChkLT at http://www.shavlik.com/phfnetchklt.aspx.

When you use MBSA, remember that the cursory scans it performs look for the most common misconfigurations of Microsoft products. The vulnerability scanner is a step in the right direction, but it doesn't offer the broad scanning capabilities that dedicated vulnerability-assessment software—such as Internet Security Systems' (ISS's) Internet Scanner or the open-source vulnerability tool Nessus—provides. For example, MBSA checks only five basic password rules (such as whether the password is blank, contains the username or computer name, or contains the words password, admin, or administrator), so you shouldn't use MBSA in lieu of true password-auditing software. MBSA fills a gap for organizations that don't have specialty security software, but be aware of MBSA's limited scanning depth so that you can decide whether your situation warrants the extra horsepower of a more powerful scanner.

Fixing the Known and Unknown
Running MBSA on your network can inform you of problems you didn't even know existed. The MBSA Help text provides useful descriptions of how to use a variety of technologies to attack the vulnerabilities. You can use centralized administration tools such as Active Directory Group Policy to eliminate some vulnerabilities. And you can use Windows scripting to automate the elimination of local system vulnerabilities. For example, consider authoring a script to disable a guest account or change a registry setting for all computers in your domain. You can find techniques for many of these solutions on the Internet and in reference texts.

MBSA offers terrific functionality for ad hoc or scheduled reccurring security scans of your network's computers. Although not as comprehensive as a full-blown vulnerability scanner or as powerful as a patch-deployment system, MBSA is a good fit for your security toolkit.