Automate MBSA

Let's say that you're a systems administrator for a company and that you wish to assess and collect a wide variety of security data about systems on your network. You'd like to scan your systems every time they're restarted and then make the results available on a Web site where you and your teammates can review them (and then remediate the vulnerabilities). You can use Microsoft Baseline Security Analyzer 1.2.1 together with MBSA sample scripts from Microsoft to create an automated networkwide scanning program. I don't recommend relying on MBSA exclusively for your network security—it's not robust enough for this responsibility. But as you'll see, it can perform some surprising tricks and gives you data to work with when securing your network. If you need some more basic information about MBSA before you tackle this project, see the Web-exclusive sidebar "MBSA Introduction" (http://www.windowsitpro.com, InstantDoc ID 45266).

We can break down our project into the following tasks:

1. Download MBSA and install it on each target computer manually or by using an automated method such as a software installation Group Policy Object (GPO). Download the MBSA sample scripts.
2. Write a startup script that runs the MBSA command-line utility (mbsacli.exe) every time the computer is restarted and saves the scan results to a network share.
3. Run a daily scheduled task that uses an MBSA sample script to process the data on the network share into HTML reports viewable on a Web server.

Every network is different, and you'll want to tweak this example to best fit your environment. For example, these steps assume that users aren't local administrators and therefore can't run the scripts under their user permissions. As a result, most of the MBSA installation and scanning occurs via Active Directory (AD) GPOs running with elevated privileges.

Downloading MBSA and the Sample Scripts
To create the scanning program, you need to have the latest version of MBSA and the MBSA sample scripts. Download the latest version of MBSA at http://www.microsoft.com/mbsa. On this Web site, you'll also find a number of technical whitepapers, FAQs, and other documentation about this tool. After you download and install the file, browse to C:\program files\microsoft baseline security analyzer to review the default location for all the MBSA files. Here's where you'll find both MBSA.exe and mbsacli.exe.

The first time you run MBSA, it downloads security update information from Microsoft in a signed file named mssecure_1033.cab. (The number 1033 represents the English version of the file. The number will be different for the French, German, and Japanese versions.) As with previous versions of MBSA, you can specify whether to download this file directly from Microsoft or point MBSA to a Software Update Services (SUS) server to generate its reports of missing security updates based on the updates that you've approved for installation.

Microsoft provides a package of downloadable MBSA scripts and documentation that automates the scanning of your network and demonstrates how to aggregate the results into an easy-to-review format. Download the package at http://www.microsoft.com/technet/security/tools/mbsascript.mspx and extract the files to a folder on your computer. The package contains two JavaScript scripts, a Word document describing how to use the scripts, and XML files to format the script output.

Remote vs. Local Scanning
MBSA can be run locally on each target computer or remotely from a central scanning computer. Remote scans are easier to set up because they don't require you to touch every computer to install MBSA, and they're easy to run. To configure a remote scan, you run the MBSA GUI or Mbsacli and specify the targets by name, IP address, or in a list. As easy as this approach might be, it has drawbacks. First, not all MBSA vulnerability checks are performed when scanning remotely (e.g., MBSA checks Windows Firewall settings only when run locally). Second, a network scan takes up more network bandwidth than a local scan. Last, a local scan can more easily be tied to an event such as a system restart or user logon. For these reasons, our example demonstrates how to use MBSA to locally scan each computer when it restarts, then copies the results to a central server for processing and reporting.

To run the scans locally, you'll need to install MBSA on every target computer. Because Microsoft supplies the file as a Windows Installer (.msi) file, it's easiest to deploy the application using a software installation GPO. The benefits of using a GPO to assign the application to your target computers are that your users don't need permissions to install the software and you know it will be installed at the next computer restart.

Scanning the System After Every Restart
After you've installed MBSA on each target computer, you need to create a startup script that launches Mbsacli every time the computer is restarted. Listing 1 shows runmbsa.bat, a three-line sample script. The first line starts Mbsacli. We want to include all the MBSA checks, so we'll configure our automated scanner with the MBSA mode parameters, rather than the HFNetChk mode parameters. For more information about Mbsacli's MBSA and HFNetChk modes, see the Web-exclusive sidebar "Two Mbsacli Modes," InstantDoc ID 45267.

On Runmbsa's first line, the -c parameter together with the environment variable %computername% instructs Mbsacli to scan the local computer. The /o parameter defines the filename format of the saved scan. By default, MBSA saves the XML files in the format Domain-Computer(scantime), expressed as %D%-%C%(%T%), but I wanted the filename format to include only the domain and computer names. To write the scan results as Domain-Computer.xml, you specify the output XML file as %D%-%C%. In Windows shell scripting, the percent sign (%) denotes a variable, so to pass %D% and %C% to MBSA, we must enclose each of these expressions in a set of percent signs.

The optional last instruction on Runmbsa's first line redirects the status output of the MBSA scanner to a text file. Usually this output simply contains a success message, but if the scan fails, it might include helpful troubleshooting information. This output shows only the MBSA run status and doesn't contain actual scan-result data.

Runmbsa's second line copies the scan results from the target computer to a network share on the computer that will process and host the results. The Copy command's /y parameter overwrites the target without prompting so that the script can run unattended.

The last line deletes the local results so that the next time the scan runs, the result file will again be named Domain-Computer.xml. If you run the command

mbsacli.exe /o %%D%%-%%C%%

repeatedly on a computer, you'll notice that MBSA creates multiple XML files named Domain-Computer, Domain-Computer (1), Domain-Computer (2), and so on, instead of overwriting the XML file each time, as you might expect. But I don't want to clutter up my systems with multiple XML result files; I want to see just the latest results for each system. So we delete the local copy to ensure that every time the scan runs, the XML file is named Domain-Computer.xml. When we copy the file to the share, it overwrites any previous results on the share.

Now that we've created the MBSA scanning shell script, we need to create a mechanism to run the script every time the computer is restarted. We can create a new GPO that runs this shell script as a computer startup script and link it to the domain, organizational unit (OU), or site AD object that contains the computers to scan. After you've added the GPO and Group Policy has been updated on a target computer, restart the computer and Runmbsa will run. Even locally, scanning a computer might take a few minutes, and if you log on to the target computer and launch Task Manager, you should see an MBSA process and a CMD process running under the SYSTEM account. When the scan has been completed, we can see that it has copied the results to the network share.

   Previous  [1]  2  Next