Microsoft Baseline Security Analyzer is one of the tools provided by Microsoft to help administrators to scan systems (local and remote) for missing security updates and common security misconfigurations. It can scan the server operating system and SQL Server but also other products as well, such as Microsoft web server IIS.
This article is about the installation process as well as the way to use it. The procedure has been performed on a Windows Server 2012 R2 Standard Edition but may also work on other systems as per software requirements and compatibilities.
Here is what Microsoft says on its download page for the latest version of the tool at the moment this article is written:
To easily assess the security state of Windows machines, Microsoft offers the free Microsoft Baseline Security Analyzer (MBSA) scan tool. MBSA includes a graphical and command line interface that can perform local or remote scans of Microsoft Windows systems.
MBSA 2.3 will scan for missing security updates, rollups and service packs using Microsoft Update technologies. To assess missing security updates, MBSA will only scan for missing security updates, update rollups and service packs available from Microsoft Update. MBSA will not scan or report missing non-security updates, tools or drivers.
Downloading the installer
First off, you’ll need to get the installer executable. You can download it from its download page. You can download multiple versions at once (one per language and architecture).
Once the files have been downloaded, put them on the server you’ll use as a host for the tool, or on a network share and go to the server of your choice.
Running the installer
We can now run the installer corresponding to our language and architecture. The following window will pop up:
Just click on “Next” button.
The next panel is the license agreement you will have to approve and click on “Next” button:
Now we must choose the destination directory. We can let it to its default or change it then click on the “Next” button:
Now we just have to confirm the install and let it run by clicking on the “Install” button:
Once the installation is done, you’ll get the following popup on which you just have to click OK:
Congratulations, Microsoft Baseline Security Analyzer is now installed. Let’s now see how to use it.
Running the tool graphically
As we’ve just installed MBSA, we can see it in “Start Menu” or application screen:
Let’s run it and see what the graphical interface look like:
As we can see directly from the image above, this tool can:
- Scan a single computer by providing an IP or its NetBIOS name.
- Do this scan for a group of computers
- Have a look at existing reports (when we have some)
Let’s just click on “Scan a computer”:
This switches to another dialog, where you’ll need to provide some parameters. The parameters are a NetBIOS computer name, an IP address and the name of the final report which is can be parameterized. In addition, we can check or uncheck options. These options will change the behavior of MBSA. They are shown in the following image:
Once everything is set up appropriately, you’ll find a button at the bottom right of the screen called “Start scan”. Just click on it.
Here we go. The process can take several minutes.
In my case, for a remote server and every options checked, as shown above, it took approximately 10 minutes to complete without taking that much memory (16 MB) or CPU (0%).
Unfortunately (or fortunately), I have to go through the whole report as it’s not an all green “everything is OK” message that is given by MBSA.
One thing we can see is that the report is organized by default with “worst first” which is to me very valuable. The next thing that is really helpful is that for every scan issue, we can see at least what was scanned, in some cases a detailed report may be accessible and/or eventually a way to correct the issue:
The “What was scanned” link opens an HTML description of the scanned aspect. Here is an example:
The “Result details” presents a detailed report of the analysis made by MBSA. For example, you will find this dialog displayed:
We can see here that there are missing updates. The action to take can be pretty straight forward but we have a “How to solve” link. Let’s see what is displayed:
The last thing we can see in the report, are the actions that we can do on the report, as shown at the bottom of the window:
- Print the report
- Copy the report to clipboard
- Switch to another report
Other ways to run the tool: command-line
As the description stated, there is a command-line interface for the tool. Let’s introduce “mbsacli”. To run it, we have to open an invite or a PowerShell window and go to the installation directory of MBSA (or adapt PATH environment variable so that this folder is included).
Here is a sample command I used to run against a remote server:
.\mbsacli.exe -target CHULG\si-s-serv236 /n os+sql+updates+password /qt /nd
I won’t go too long on this because I think that might not interest everyone, except those who would want to automate the process, plus I’ve found, on the web, a script by Ben Wilkinson that seems to be much handier, but it’s just my opinion.
I invite you to read the description of this script and test it in a non-production environment.
I’ve tested multiple (security) baseline analyzers / assessment tools: Scuba, CIS-CAT, SQL Doctor and now this tool.
Each time I ran one of them, I was a little dubious on the output because there are recommendations that are far away from practical business needs and capabilities or that are justified in most cases except the particular one which we obviously meet.
To me, those tools are not meant to be used for a strict assessment that must absolutely succeed but rather like as a set of indicators. Indicators that don’t succeed can be explained or not. When they can be explained, they need to be investigated in two ways: understanding and trial to explain. We are humans and can’t know everything. So, when a new aspect is raised, it’s the opportunity to learn from it, its purpose, its impact, its dependencies and the problem that it can cause. Once it’s done, you have all the cards in your hands to decide whether there is an acceptable reason to stay as is or not.
Let’s illustrate this with an example. I found in the MBSA report that “Internet Explorer zones do not have secure settings for some users”. When I click on the result detail, it shows me the service account used for SQL Server (which cannot connect in another way than as a service) and that the setting concerns ActiveX. I don’t think it’s a problem at the moment as it’s a service account, no interactive session may run and no permission of xp_cmdshell is allowed in my installation. This reason seems acceptable to me and I will document it for the server on which I ran the tool. The documentation will be reviewed on regular basis and the reason will be reviewed each time. With experience or evolution of the situation in the environment, I may realize it was not an acceptable reason and it must absolutely be changed.
I'm one of the rare guys out there who started to work as a DBA immediately after his graduation. So, I work at the university hospital of Liege since 2011. Initially involved in Oracle Database administration (which are still under my charge), I had the opportunity to learn and manage SQL Server instances in 2013. Since 2013, I've learned a lot about SQL Server in administration and development.
I like the job of DBA because you need to have a general knowledge in every field of IT. That's the reason why I won't stop learning (and share) the products of my learnings.
View all posts by Jefferson Elias
Latest posts by Jefferson Elias (see all)
- How to perform a performance test against a SQL Server instance - September 14, 2018
- Concurrency problems – theory and experimentation in SQL Server - July 24, 2018
- How to link two SQL Server instances with Kerberos - July 5, 2018