Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Rob Wickham: My name is Rob Wickham. I'm a program manager in the Security Business and Technology Unit here at Microsoft Corporation. Today we will be going through vulnerability assessment and the Microsoft® Baseline Security Analyzer (MBSA).

(Slide 2) Our objectives today are going to be going through what the key problems are that we're trying to solve with the Microsoft Baseline Security Analyzer; in particular we need to begin with an understanding of the key objectives of MBSA. It's to increase customer awareness of what computers are at risk and to provide best practice guidance on how to mitigate those vulnerabilities. This guidance is largely built into the tool, and for each discovered vulnerability, there is a context presented that you can click in the UI to get the steps you need to cover that issue.

MBSA is also evolving with the growth of our products and our commitment to offer greater levels of security for the Microsoft Windows® operating system. With this in mind, MBSA is a free tool, and to use it, there is no agent deployment needed. This allows you to quickly perform a very low-risk, low-cost assessment of the environment.

The release of MBSA 1.2 also increases the coverage for Microsoft's products. Of all products having security bulletins, MBSA covers about 40 percent or more of them. And, in particular, with the more common products, such as Windows, Microsoft Office, Microsoft SQL Server™, and Exchange, MBSA does an excellent job. Consistency with Windows Update has also been improved greatly.

There are a few customers for whom MBSA won't be a good fit. But in general, up to a 10,000-seat organization, or five admin staff, and even the IT professional should be using MBSA. Some people may just have some computer savvy and want some immediate results, using MBSA on their home computer, and MBSA is good for them as well. Really large organizations may need a more complete solution around vulnerability management, and those customers should look at our enterprise management products, such as Microsoft Systems Management Server (SMS).

(Slide 3) From this session, I want you to know why MBSA is important and how to maximize its potential. It can also be used to provide greater functionality, by combining it with other solutions if you need them. MBSA is very important to Microsoft because we need to further secure the Windows operating system. Customers need to trust Windows and Microsoft. And because MBSA is a free download, and it does not require agent deployment to be effective, it's value is being tactical, lightweight, and able to assess both misconfigured security settings as well as security updates. It covers over 60 configuration vulnerabilities in addition to the security updates, and it has broad coverage for platforms from Windows NT® 4.0, all the way up to Windows Server™ 2003.

Assessment is just the first step. With MBSA, it's very low-impact. It's a read-only step, so to speak, that doesn't actually change the configuration in the environment. When more of a solution is needed, such as the need to deploy specific security updates or other configuration changes, Windows Update Services, SMS, or even third-party or in-house solutions can be used with MBSA.

(Slide 4) I have divided this session into three major areas, starting with more high-level concepts and information, then going into greater depth as we go on. It's very important that this material provides you with a healthy cross-section of MBSA, in the context of yesterday, today and tomorrow, so that you can understand what MBSA can do for you and where we're taking it in the future.

(Slide 5) For Part 1, we'll be covering the overall features and design. This will include an overview, a list of the supported products, a description of how it works, and an overview of scanning, scalability, and performance, as well as how it integrates with Software Update Services (SUS) and SMS.

(Slide 6) For an overview of the tool, it's a single executable that runs on Windows 2000, Windows XP, and Windows Server 2003, and it also has a command-line interface that will run on Windows NT 4.0. It performs remote scans against these operating systems. Its focus is agent-less assessment, easy deployment, and being easy to use. The installer package, which is based on the Windows Installer, includes the GUI version of MBSA (Mbsa.exe) and its command-line interface (Mbsacli.exe). The latest version is 1.2, which just released in January 2004; prior to that, we released version 1.1.1 in June of 2003.

(Slide 7) Let's describe how MBSA works. In step 1, you run MBSA on an admin system, and you specify the target computers that you want to scan remotely. Next, MBSA will do a version check; if there is a newer version, you will get a reminder of that. It also downloads the latest version of Mssecure.cab and verifies its digital signature. In this .cab file are details about each patch, such as the bulletin IDs, product-specific updates, file data, registry data, and KB article numbers.

Next, MBSA will scan the target systems for the OS components and applications. Those results are returned to the admin console where MBSA is running, and it parses Mssecure.cab and compares it to the results coming back from the targets, to see if updates are available. Finally, it generates a time-stamped report for each of these scanned target computers and stores them on the admin machine. You can then view these later, and with sample scripts that we'll be providing, you'll be able to roll these results into a dashboard.

(Slide 8) While MBSA is doing the scanning, it can use two main engines; this is the MBSA engine for security system configuration checks and what we call the HFNetChk engine, just for security update checks. Now during an MBSA-style scan, the system configuration checks and missing security updates can be checked for. This is available through the MBSA user interface, as well as through the MBSA command-line. Individual XML scan reports are created for each computer using this mode. It's also a single-threaded mode, which can take a little bit more time than the other mode.

An HFNetChk-style scan or an /hf-style scan will give you the ability to check both for missing and installed security updates and service packs. It's offered only through Mbsacli.exe, using the /hf switch. It offers text output or the option to write output to a file, and it supports the multithreading capability to increase performance while scanning. It is limited only to checking for security updates, though, and not the configuration settings.

(Slide 9) For scalability and performance, we have some general numbers that you can use as a guideline. This data is based on a specific test, using a fully up-to-date Windows XP SP1 client running on our own Microsoft corporate network. Both the target computer and the computer running the MBSA tool were a 1-GHz or higher processor on a 100-Mbps LAN. This data is not intended to represent a complete view of performance and scalability, so when you look at the tool, check the results, based on your network configuration, and adjust accordingly.

Using 40 seconds as a guideline, for example, for the check for all of the vulnerabilities listed in this slide, there is about 11 MB of network traffic. So if you want to scale this up, you can expect the scanning host will produce a throughput of about 2,000 computers in a 24-hour period, running non-stop. By breaking up the list of scanned computers into chunks, and sending each chunk to a different scanning host running the MBSA tool, you can have a basic level of scale out, which will enable you to get more throughput during your network scans. Using the rollup scripts that we'll be demonstrating later, it's easy to aggregate those results back from each of these hosts into a dashboard. With greater efficiency, you can also just look for a scan for the security updates, and that will also increase the throughput fairly substantially

(Slide 10) Now let's talk about how MBSA supports Microsoft Software Update Services 1.0. What it does is it allows you to perform a security update scan, which observes the local SUS-server approved update list. In the MBSA UI, you can specify the SUS server name, which will be read by default from the client's registry, so that, by default, you'll know where the SUS server is. You can also specify the name of the SUS server at the command prompt, for a command-line scan. Now what happens is the scans are limited just to the approved items on the SUS server, by means of an ApprovedItems.txt file that is maintained on the SUS server automatically for each update, which have been approved using the SUS console.

The items that are included in this file are looked up in the Mssecure.xml file, and only those patches that have been approved and that are also missing from the client will show up in the MBSA results, using this feature. Please note that SUS 2.0, which is in beta, does not support ApprovedItems.txt, and there will be another version of MBSA published in the future that will allow this functionality to work with SUS 2.0.

(Slide 11) SMS support: SMS 2.0 Software Update Services and SMS 2003 are two product versions that use MBSA in a very similar way. They push Mbsacli.exe down to each client to perform a local scan. It parses the output, and then this output is put into Windows Management Instrumentation (WMI) on each SMS client, where it is then centrally rolled up into the SMS database. SMS is also working on a version that will support MBSA version 1.2 in the very near future. By using SMS as a value-add around MBSA, you get rich reporting, great scheduling capabilities, and enforced patch deployment scenarios.

(Slide 12) Part 2 of this WebCast deals with the details of MBSA. Here we'll be reviewing some of the limitations in the prior version and comparing that to the new things that have been added to version 1.2.

(Slide 13) Let's review some of the limitations in the prior release of MBSA. First off, it's important to understand that MBSA exists without the benefit of a rich, extensible scanning infrastructure, such as what Windows Update Services will be providing later this year. To support a new product, MBSA needs to be re-released, so there will be exceptions over time that MBSA will not be able to detect. When defining these areas to invest in for MBSA 1.2, the items that you see were some of the key areas of focus. So what I want to do is call out some specific details of these behaviors.

A note message is a particular case, where MBSA supports the product that has a patch for it, but the patch detection itself is simply too sophisticated for the current logic supported by MBSA to go and detect. Some examples of this are DirectX® and FrontPage® Server Extensions. There are also cases that you may be familiar with that relate to Internet Explorer. For example, the support policy for Internet Explorer 6.0, when running on a Windows 2000 system, is that there are no supported patches available. However, Internet Explorer 6.0 on a Windows XP system is still within its support lifecycle, and it does have supported patches available. MBSA will report the Internet Explorer 6.0 vulnerability on that Windows 2000 system, even though a supported patch is not available for that configuration.

(Slide 14) Now let's take a look at what's new in MBSA 1.2. We've made several UI improvements, in terms of localizing the tool. Very soon there will be localized versions of the XML catalog, so that you'll be able to see the titles of the security bulletins in the localized language. We've also added upgrade support and new version notification into the UI. For those of you familiar with KB article 306460, that article has been revamped; it completely lists the products with security bulletins outstanding and whether or not that product is supported or unsupported by MBSA for detection. It also lists the exception cases that we have in terms of notes, non-critical warnings, and product name changes between the two versions of MBSA to be aware of.

Additional products that have been added focus on Office and using the Office Detection Tool for local computer scans of Office 2000 and later. We've also added Microsoft Data Access Components (MDAC), Microsoft XML Core Services, and the Microsoft Virtual Machine, or JVM, and a number of the eBiz servers, such as Commerce Server, Host Integration Server, and so on. Detection improvements have been made as well, with things we call "alternate file versions." And notes have been reduced from 39 to just 15 in MBSA 1.2. We've also added a few configuration checks that are very interesting.

(Slide 15) Here's a screen shot of the upgrade notification. Notice, down at the bottom, there is a small region that will pop up and let you know that there's a new version of MBSA. This has been pre-positioned, so that if in the future we offer an upgrade to MBSA that enables additional patch detection capability, we can notify you of that right away. Also notice, up at the top, you get this kind of a notification, as well as a reminder that the report that you're viewing was scanned with an older version of the Mssecure catalog. And rescanning with the newer version of the catalog would be a good idea.

(Slide 16) Another thing that has been added to MBSA 1.2 is the creation of a Windows event on each target computer that has been scanned to help close the loop on auditing, on who is using MBSA to scan the environment. In this is a link to the Help and Support Center. So an end user who sees this event out of curiosity can click the link and understand what was done with some friendly text that explains MBSA to the user.

(Slide 17) In this list of supported products, you can see the extensive enhancements that have been made to security update detection in MBSA 1.2, in addition to adding support for misconfiguration settings that apply to Office 2003.

(Slide 18) Now let's look in a little bit more detail at alternate file versions. This was a significant area of investment for MBSA 1.2. It allows OR logic to be used when considering multiple sets of file details. It handles the case of a non-security update, overriding a previously installed security update.

Also, a different bulletin can have multiple patches for products targeted at different operating systems. For example, single-processor or multi-processor patches, as well as what we call the QFE or the GDR type of patches that are available for Windows Server 2003. How this works is the detection logic walks a list of alternate files. If none match, the missing patch message will reflect the file version of the first item listed in Mssecure, whether it's a file change or an alternate file change.

Alternate files are listed with this AFileChangeID item. MBSA 1.1 ignores this, and this was implemented to ensure the greatest amount of compatibility with MBSA 1.1.1, until those customers upgrade to MBSA 1.2.

Any MBSA 1.2 user who is seeing non-critical warnings or a yellow X for a particular software update should be sent to Product Support Services, or the newsgroup, so that we can look at these issues and correct them in the Mssecure catalog.

(Slide 19) This slide describes the flow of logic evaluation within MBSA. I want to point out that MBSA uses a two-stage level of detection: first, at the product level, to determine if an applicable product is installed on the computer. When there are applicable products installed, then patch-level evaluation is performed. The highlighted region in the middle of this graphic is the new logic introduced in MBSA 1.2 to help manage intermediate file versions.

(Slide 20) Other improvements that have been made in MBSA 1.2 include improvements in file version checking for Multilingual User Interface systems, or MUI systems. This fixes an issue where MBSA detected the wrong file version numbers on systems in this configuration. This was an issue in how the GetFileVersionInfo API was implemented for Windows 2000 systems, which has been resolved in this release of MBSA. We've also improved guest account checking, Internet Explorer custom zone interpretation, event logging, which was shown in a previous slide, and the Outlook® zone checks have been collapsed into an Internet Explorer zone check and Office macro check.

(Slide 21) In addition to those improvements, additional checks have been added. For example, Internet Connection Firewalls can be checked on local scans, so that you know if you have your firewall enabled, and which particular ports are enabled. Automatic Updates has also had a check added, so that you can see if Auto Update has been set to the recommended setting to download and install software updates. This check is supported for both local and remote scanning. Note that the Internet Connection Firewall check is enabled only for a local scan. Last, Internet Explorer enhanced security configuration, or Internet Explorer hardening, as implemented in Windows Server 2003, has also been added as a check.

(Slide 22) Now let's look at some details about how localized patch scans work. Mssecure.cab files will be available in each of the localized languages that MBSA supports. MBSA tries to download a .cab file that matches the system language of the scanned computer. If that fails, MBSA will attempt to operate against a previously downloaded version of this .cab file. And if that fails, MBSA will revert back to using the English .cab file that it uses today.

The language of the scanned computer will also determine if checksum checks are being performed. For example, if the operating system doesn't match Mssecure's language, it will revert back to the checksum checking, such as the case in the first example, where MBSA had to fall back to the English file. Checksum checking would not be performed against a localized client computer in that case. You can also override these behaviors by using the /sum or /nosum option on the command line.

(Slide 23) Next, Office update scans have been added, using the Office Update Inventory Tool. Office checks are supported against the local computer only; there is no remote checking. How this works is very similar to how MBSA downloads the Mssecure.cab file. The Office tool also downloads its own files necessary to perform patch checking. Offline scanning is then subject to the same type of workaround. If you don't have an Internet connection on the computer performing the scan, you can download those files separately, put them into the proper folders, and MBSA and the Office Detection Tool will be able to use them. There are scanning limitations also described in this particular Knowledge Base article. Users running Mbsacli with the /hf or HFNetChk mode will not receive Office update scanning.

(Slide 24) Here are some of the default scan options that you need to be aware of. These are important, because these command-line behaviors are slightly different than the default behaviors of the GUI version of MBSA. When using the MBSA UI, the -baseline, verbose option (-v), and -nosum switches are used. When you are performing a scan using Mbsacli, checksum checking will be performed. And then when you are using the /hf switch, checksum checking is also performed, and notes and warnings are shown by default.

(Slide 25) The system requirements are fairly basic. An XML parser is required, as well as the workstation and server service must be running. The computer that is performing the remote scan needs just the workstation service and the Client for Microsoft Networks. The computer being remotely scanned, the target, requires the server service, remote registry service, and file and print sharing to be enabled.

(Slide 26) IIS common files are also required on the local computer when scanning remote IIS computers. Certain ports must also be enabled. Port 80 for outbound scans from the scanning computer is needed to download the patch catalog. TCP ports 139 and 445 are required to be open on the target computer being scanned. Users must also be running as a local administrator to perform scans.

(Slide 27) How MBSA connects to these remote systems is two-fold. MBSA-style scans use NetWkstaGetInfo, LookupAccountName, and gethostbyaddr. HFNetChk-style scans use the TCP ports and do not rely on ICMP.

(Slide 28) This is a list of known issues. It's important that we review these, so that as you begin to use MBSA 1.2, you'll understand what these limitations and behaviors are. First off, we did talk about notes and limitations in examples of FrontPage Server Extensions and DirectX. Next is non-critical warnings, and we did talk about alternate file versions, and how those non-critical warnings can be dealt with over time. There has also been some confusion and concern over when SMS will adopt the MBSA version 1.2 release, and that will be taking place quite soon now. We've seen some confusion over having two versions of the Mssecure catalog, one being authored to support version 1.1.1 customers, and one being offered to support version 1.2 customers. In April 2004, there will be a cutover, so the version 1.2 catalog will be the only version that we publish, and 1.1.1 users will be encouraged to upgrade to version 1.2.

Customers have also expressed concern over inconsistent detection when compared to Windows Update. Our plan there is a convergence on SUS 2.0 as detection infrastructure, going forward.

Next, there was some confusion over SQL Server 2000 and SP3a in the context of MSDE not having an SP3a available for it. This has been resolved.

Next, some customers reported a series of Windows 627 events when password scans were being performed. This is based on the specific behavior of how MBSA attempts to determine if you're using a weak password.

Checksum checks are off for the GUI, but enabled for an /hf-style scan, and this can yield different results that you need to be aware of.

Next, the documentation states that the number of hosts scanned using a /fh and /fip command line is 255, when in fact it is 128.

I also mentioned the Internet Explorer 6.0 "gold" on Windows 2000 support. It expired about two years ago. And MBSA is not aware of the actual support policy, but it is able to report the vulnerability for updates on that configuration.

Another interesting point is if you install updates and do not restart the computer, those updates may not take effect, and MBSA currently does not analyze the system to look for cases where the system needs to be restarted. Some updates can install files that are not in use, and that are in memory. And if those files are in place with the proper version, MBSA will record the system as compliant.

(Slide 29) Part 3 of our session will now go into scripting with MBSA 1.2. To set the stage for this, we will be publishing a series of sample scripts that allow you to extend MBSA into new scenarios and offset some of the limitations that exist in the tool today. These sample scripts enable large-scale scanning, as well as for low-rights end-users to check their own compliance without needing to call the helpdesk. The script can scan an unlimited number of computers using an IP address or a computer name from an input file, as well as roll up these results from many reports into a single summary that can then be displayed and filtered, based on the check IDs or the bulletin IDs. This should release in March 2004.

(Slide 30) Here's a quick sample of what the rollup dashboard looks like after a summary has been performed, and opening the resulting XML file in the browser. You can see the check listed on the left, and the compliance across each category on the right, with a button that you can expand and contract to look at the computers in each category.

(Slide 31) What I'd like to demonstrate for you today are some ways you can take sample scripts that we'll be providing and add and enhance the MBSA usage that you're getting today. First, we're going to demonstrate how to scan multiple clients listed in a .txt file, and this can be an arbitrary number of clients, not limited to the current limitations that MBSA has. Then we're going to demonstrate how you can scan multiple computers and return the results to those computers, so that the end users can view them without having to be local administrators. We're calling this a two-phase scan. Next, we'll be demonstrating how to roll up results into a dashboard view.

(Slide 32) Here are some of the command lines. You can see they are very simple implementations of JScript®, using the Microsoft Windows Script Host to execute them, as well as batch files, which construct MBSA command lines, using specific command-line options.

(Demonstration) I've put together some demonstrations for you that will help illustrate the sample scripts that we have provided. First, I'd like to demonstrate how you can scan an arbitrary number of client computers and bypass the limitations that exist in the MBSA tool. To do that, I'll open this batch file and show you the contents.

BatchScanDemo, as you can see here, calls into the Windows Script Host using our Batchscan sample script, which takes the command-line parameter, which is Listfile.txt.

Inside Listfile.txt, I can insert the list of computer names that I want to scan, or IP addresses to reflect computers that I want to scan. I can populate this list using any number of other data sources, such as SMS or the Active Directory®. When I run this scan, each computer will generate a specific XML report in the SecurityScans folder of my logged-on user profile. From there, I can then run roll up scripts and produce a dashboard.

But the next demo I want to show for you is the two-phase scan. This also uses a batch scan model. The ScanDemo script, as I'll open and show you, is fairly simple.

It sets some parameters for the computer name and the target user that you intend to scan. Then it calls Mbsacli with some specific command-line switches. Last, it copies the resulting report back out to the computer and user profile that you intended it to. This script can be embellished with the ability to add multiple user profiles to the list of users of that computer who will receive these reports.

When you run this script, in phase 1, it requires administrator rights; however, the end user can be given a simple desktop icon; and when they click it, they'll see this, which is the most recent report of their computer scan. And they can look at this list without having to call the helpdesk to determine if they are in compliance for a particular software update. Also, if you're using a SUS 1.0 server, you can ensure that these results are consistent with the list of updates that you've approved using your SUS server, so that users won't become concerned with updates that you, the administrator, have chosen not to deploy.

The next demo that I want to show you is how to perform an actual rollup into a dashboard. There are two basic kinds of rollups that you can perform against a single check or bulletin or multiple checks or multiple bulletins.

I'll open the batch file sample to show you what a single check rollup command line looks like. Using the Windows Script Host, our rollup script is called with a command-line switch that indicates check number 179 is to be rolled up. With the sample scripts is a table of the friendly check name to the check ID number that's used to perform the rollup. The output is redirected to an XML file. You can pick any name you want. For this case, I chose "SingleCheckRollupDemo."

When that runs, you get an XML report back. I'll just double-click this, it will open in the browser, and it will show me my rollups. In this case I decided to check IE Zones and the IE hardening of Windows Server 2003. I can see I have 33 percent of my IE zones, which is two out of six computers, that have a critical issue, and that four have passed. If I'm interested in those two computers with the critical result for that check, I can click this button and see that the computers Osprey and Eagle need some remediation.

The next demo is to extend these summary reports that have been generated, using the Windows Script Host, and put those results into even more interesting formats. In this case, I've created an Excel spreadsheet, using an XML data source option, that can read my results into a nice PivotChart®. In this case, I've performed a multiple bulletin ID rollup, and I can see all my bulletin IDs that I've done my rollup on right here. I can pick one, click OK, and look at my compliance. I can also change the particular grades that I'm interested in looking at. Excel being a very flexible charting tool, and XML being a great data-exchange format, you can take these results and integrate them in a wide variety of ways.

What makes a lot of this happen is this .xsl transform that is used by the rollup script to apply changes in the XML reports generated by MBSA to produce the rollup XML reports.

Let's take a quick look at this in Notepad, and bypass the style sheets. You can see the schema that is implemented here is fairly simple: we have the name of the check, the result for that check, and a list of the computers that were in that particular category.

Also included in the scripts will be samples that include multiple updates. In this case, this particular sample is all the security bulletins that have been issued that have a maximum severity rating of critical, up to and including MS04-007. With this command line, you can summarize your results and serve up just the critical items in the dashboard. This allows you to pick and choose which updates you want to take action on, based on their severity.

For support on the MBSA tool, we have a public newsgroup. There's also a news server at msnews.microsoft.com and the newsgroup microsoft.public.security.baseline_analyzer. We have additional resources on the Web: our home page (http://www.microsoft.com/technet/security/tools/mbsahome.mspx), frequently asked questions (http://www.microsoft.com/technet/security/tools/mbsaqa.mspx), as well as a technical white paper (http://www.microsoft.com/technet/security/tools/mbsawp.mspx). There's a KB article (320454) with details on how the tool works, as well as command-line options; and as I mentioned, there is a Knowledge Base article (306460) that talks about note messages and other limitations of the tool.