What method scans systems to identify common security misconfigurations and missing security updates?

This article in our series on Microsoft’s free security tools is focused on a tool called the Microsoft Baseline Security Analyzer (MBSA). Many years ago before Windows Update was available, servicing software was much more painful than it is today. Microsoft released security updates weekly, and there were few deployment technologies available to help determine which systems needed which updates. I wrote an article on this topic if you are interested in a walk down memory lane. For those IT administrators that lived through those days, the MBSA was a godsend. Today, 10 years later, the MBSA is still a free security tool that many, many IT Professionals use to help manage the security of their environments.

Table of Contents Show

Applying patches
Patching considerations
Identifying missing patches
Patching during change freeze periods
Faults during patching
Tightly coupled security and feature patches
Patching in resource constrained environments
Temporary workarounds
Patching in different contexts
Cloud infrastructure
Critical infrastructure
Further information
Contact details

The MBSA is an easy-to-use tool designed for IT professionals and helps small and medium-sized businesses determine their security state in accordance with Microsoft security recommendations and offers specific remediation guidance. It is a standalone security and vulnerability scanner designed to provide a streamlined method for identifying common security misconfigurations and missing security updates. MBSA is used by many leading third-party security vendors and security auditors and, on average, scans over 3 million computers each week.

Microsoft Baseline Security Analyzer (MBSA)

The MBSA provides built-in checks to determine if Windows administrative vulnerabilities are present, if weak passwords are being used on Windows accounts, the presence of known IIS and SQL administrative vulnerabilities, and which security updates are required on each individual system. The MBSA provides dynamic assessment of missing security updates. The MBSA can scan one or more computers by domain, IP address range or other grouping. Once complete, the MBSA provides a detailed report and instructions on how to help turn your system into a more secure working environment. The MBSA will create and store individual XML security reports for each computer scanned and will display the reports in the graphical user interface in HTML.

To use the MBSA tool, users will need either Windows Server 2008 R2, Windows 7, Server 2003, Server 2008, Vista, XP or Windows 2000 and will need administrator privileges sufficient to scan the target computers.

After installing MBSA and running the tool, users are taken to the screen seen below which provides quick access to three different sides of the application. Users can scan a computer using its name or IP address, scan multiple computers within a domain name or a range of IP addresses, or view existing security scan reports. There are even more options available through the command-line interface to support scripting and fine-tuned control over MBSA’s scanning and reporting features.

From the MBSA scan menu, users have the option to select some or all of the following, which are all checked by default:
• Windows administrative vulnerabilities: the MBSA checks for Windows account-related issues, such as an open Guest account or too many administrative accounts. It also looks at the number of file shares and the PC’s file system to make sure you’re using NTFS instead of FAT for better security.

Weak passwords: the MBSA looks for blank or weak passwords throughout all Windows accounts.
IIS administrative vulnerabilities: for machines running IIS 5.0 or 6.0, MBSA scans to make sure all the necessary default security options and hotfixes have been run. The tool does not support IIS 7.
SQL Server administrative vulnerabilities: the MBSA scans for any versions of SQL Server or Microsoft Data Engine (MSDE) on the machine, looking at the authentication mode to see if you’re using Windows authentication or Mixed Mode (Windows and SQL authentication). It also checks the status of the system administrator account password.
Security updates: the MBSA checks the status of all updates with security implications – which include security updates, service packs and update rollups to determine if any are missing. If you’re unsure whether your target computer is correctly configured to check for Microsoft Updates, you can use the option to automatically install and configure the Microsoft Update service on a client. The MBSA scans Windows and all Microsoft applications installed on the target computers to determine if there are risks from missing security updates. You can tell the MBSA whether to use the Microsoft Update live service, a Windows Server Update Services (WSUS) server or an offline catalog as the source for missing security updates.

The MBSA also provides an expanded list of options beyond what is available via the graphic interface via the command-line interface. These options can be accessed by opening a command-prompt in the MBSA installation directory and running MBSACLI.exe /?. The additional features are especially helpful when scripting, performing MBSA scans on specific PCs during login, or managing security scans across a large number of PCs.

Create an explicit list of machines to scan (using /listfile)
Choose the location of the offline catalog to use (using /cabpath)
Direct completed scan reports to a specific network share or directory (using /rd)
Use a ‘compact’ version of MBSA on local computers without the need to install the entire MBSA package (using /xmlout)

After you select the appropriate options and computers, you then trigger the scan, which typically takes several minutes to run. By default, the MBSA will automatically attempt to reach Microsoft Update for the latest catalog. The MBSA will augment the scan using any updates approved by the WSUS admin in managed environments. In situations where there is no Internet connectivity and no WSUS server, the MBSA will use the offline (WSUSSCN2.CAB) catalog to perform a security scan. Once the scan has completed, the MBSA will generate a full on-screen report, displaying the results of the scan item by item.

A completed scan report groups its findings into categories matching the options in the scan menu, such as administrative vulnerabilities, SQL Server status and security updates. This is helpful in quickly resolving any issues discovered. The top of the report indicates which of three data sources were used, including Microsoft Update (the live service), Windows Server Update Services (a managing WSUS server) or Microsoft Update offline (when no other data source was available). It will also display the actual WSUS server used (if appropriate) and the date of the offline catalog. If an MBSA scan report is older than 7 days, the report will also indicate that a new scan should be performed to ensure an up-to-date security assessment.

If you are looking for a free security tool that provides a streamlined method to identify missing security updates and common security misconfigurations then I recommend using the Microsoft Baseline Security Analyzer. For more information please check out these additional resources:

Download MBSA
MBSA Forum
MBSA FAQ
User Guide

Tim Rains Director

Trustworthy Computing

Applying patches to applications and operating systems is critical to ensuring the security of systems. As such, patching forms part of the Essential Eight from the Strategies to Mitigate Cyber Security Incidents.

In this publication, a security vulnerability refers to a flaw in an application or operating system rather than a misconfiguration or deployment flaw.

Applying patches

Once a patch is released by a vendor, the patch should be applied in a timeframe commensurate with an organisation’s exposure to the security vulnerability and the level of cyber threat the organisation is aiming to protect themselves against. For example, once a security vulnerability in an internet-facing service is made public, it can be expected that malicious code will be developed by adversaries within 48 hours. In fact, there are cases in which adversaries have developed malicious code within hours of newly discovered security vulnerabilities.

The following are recommended timeframes for applying patches for applications:

to mitigate basic cyber threats:
- internet-facing services: within two weeks, or within 48 hours if an exploit exists
- commonly-targeted applications: within one month
to mitigate moderate cyber threats:
- internet-facing services: within two weeks, or within 48 hours if an exploit exists
- commonly-targeted applications: within two weeks
- other applications: within one month
to mitigate advanced cyber threats:
- internet-facing services: within two weeks, or within 48 hours if an exploit exists
- commonly-targeted applications: within two weeks, or within 48 hours if an exploit exists
- other applications: within one month.

The following are recommended timeframes for applying patches for operating systems:

to mitigate basic cyber threats:
- internet-facing services: within two weeks, or within 48 hours if an exploit exists
- workstations, servers, network devices and other network-connected devices: within one month
to mitigate moderate cyber threats:
- internet-facing services: within two weeks, or within 48 hours if an exploit exists
- workstations, servers, network devices and other network-connected devices: within two weeks
to mitigate advanced cyber threats:
- internet-facing services: within two weeks, or within 48 hours if an exploit exists
- workstations, servers, network devices and other network-connected devices: within two weeks, or within 48 hours if an exploit exists.

Patching considerations

Identifying missing patches

One problem faced by many organisations is a lack of visibility of the true patch status of their environment. This can leave organisations unknowingly exposed to exploitation by adversaries or otherwise thinking that patches had been applied, or reported that they had been applied, when they had failed to be applied successfully. Using vulnerability scanners can assist organisations to gather information on missing patches in their environment. In cases where vulnerability scanners can’t be used, organisations should refer to vendor documentation on how to identify patching levels and conduct manual audits instead.

The following are recommended timeframes for conducting vulnerability scans for missing application patches:

to mitigate basic cyber threats:
- internet-facing services: daily
- commonly-targeted applications: fortnightly
- other applications: as required
to mitigate moderate cyber threats:
- internet-facing services: daily
- commonly-targeted applications: weekly
- other applications: fortnightly
to mitigate advanced cyber threats:
- internet-facing services: daily
- commonly-targeted applications: weekly
- other applications: fortnightly.

The following are recommended timeframes for conducting vulnerability scans for missing operating system patches:

to mitigate basic cyber threats:
- internet-facing services: daily
- workstations, servers, network devices and other network-connected devices: fortnightly
to mitigate moderate cyber threats:
- internet-facing services: daily
- workstations, servers, network devices and other network-connected devices: weekly
to mitigate advanced cyber threats:
- internet-facing services: daily
- workstations, servers, network devices and other network-connected devices: weekly.

Patching during change freeze periods

Change freeze periods are typically periods of time when changes are minimised, usually to preserve business operations during critical periods. However, most organisations still allow emergency changes and patching activities during change freeze periods via an exemption process.

In theory, the tenet of freezing almost all changes in order to preserve business operations is sound. However, in today’s constantly evolving cyber threat landscape, it is important to keep in mind that new security vulnerabilities continue to be discovered by adversaries, vendors and security researchers, and that adversaries continue to operate irrespective of an organisation’s self-imposed change freeze period.

The discovery of new security vulnerabilities, and disruptions from adversaries, may occur at any time. As such, organisations should ensure that security vulnerabilities are still being addressed during change freeze periods, especially within 48 hours for any internet-facing services. Critical security vulnerabilities, or security vulnerabilities that affect critical applications or operating systems, should also be addressed with patches or other recommended mitigations from vendors during change freeze periods. In some cases, vendor mitigations that are not traditional patches will be provided before a patch, or alongside a patch if the patch is disruptive. Where vendor mitigations are initially used, patches should be applied as a follow-up.

Faults during patching

When patching, organisations may be concerned about the risk of patches breaking applications or operating systems, and the associated outage this may cause. While this is a legitimate concern, and should be considered when deciding what actions to take in response to security vulnerabilities, many vendors perform thorough testing of patches prior to their release. However, this testing is not always perfect and organisations are likely to at some point face the release of faulty patches or experience faults when attempting to apply patches to applications or operating systems.

It is recommended that organisations account for the possibility of faults during patching by establishing clear patch management processes. In doing so, organisations might adopt different strategies for managing faulty patches, for example, larger organisations might test all patches beforehand in a testing or staging environment, whereas smaller organisations might choose to forgo testing and instead implement a rollback mechanism. Organisations using modern software environments and deployment approaches can more easily rollback their applications or operating systems to a known good state.

Overall, the immediate protection afforded by patching a security vulnerability that is currently being exploited by adversaries far outweighs the impact of the unlikely occurrence of having to roll back a patch.

Tightly coupled security and feature patches

It is always recommended that security patches be applied as soon as possible. However, some vendors do not provide separate security and feature update patches. If an organisation does not require a new feature, being forced to apply the new feature by a vendor could introduce business process risks, as certain business processes may rely on features remaining unchanged.

Organisations should review vendor release notes and keep up-to-date on the types of updates and security configurations that vendors provide. They should then determine if using products with tightly coupled security and feature patches is a risk or not. Any potential risk that has been identified may increase during change freeze periods where possible disruptions to business operations due to feature changes is especially undesirable.

If organisations choose to use products from vendors that don’t provide security-only patches, they need to account for this in their patch management processes, as they may need to be ready to implement feature changes at short notice if security vulnerabilities are being exploited and require immediate patching.

Patching in resource constrained environments

In situations where resources are constrained, organisations are encouraged to prioritise the deployment of patches. For example, patches should first be applied for all internet-facing services. This should then be followed by important network devices, servers and workstations of high-risk users (e.g. senior managers and their staff; system administrators; and staff members from human resources, sales, marketing, finance and legal areas). Finally, all other network devices, servers and workstations should be patched.

Temporary workarounds

Temporary workarounds may provide the only effective protection if there are no patches available from vendors for security vulnerabilities. These workarounds may be published in conjunction with, or soon after, security vulnerability announcements. Temporary workarounds may include disabling the vulnerable functionality within an application or operating system, or restricting or blocking access to the vulnerable service using firewalls or other security controls.

Patching in different contexts

The following considerations are applicable for organisations that use cloud services or operate critical infrastructure.

Cloud infrastructure

For organisations that use externally-provided cloud services, the technology stack and secure administration processes implemented are often opaque. However, this is unlikely to provide a significant risk if the cloud service provider (CSP) properly patches their infrastructure and systems as CSPs are required to provide a consistent and reliable service to their customers.

In terms of change freeze periods, if an organisation freezes change at the operating system layer when using Infrastructure-as-a-Service, all of their data, resources and configurations should remain the same even if the CSP performs changes underneath that layer. Similarly, if an organisation freezes change at the application layer when using Software-as-a-Service, they should not notice any difference even if the CSP migrates the application across different operating systems.

Separately, in order to flexibly and efficiently control changes for infrastructure they manage, organisations that are cloud-native might consider utilising Agile and Continuous Integration/Continuous Delivery/Deployment (CI/CD) development methodologies. This allows organisations to rapidly deploy and test patches in a controlled manner. Moving to the cloud entails not only the transformation of technical architecture, but also the transformation of business processes.

Finally, information on the security responsibilities of CSPs and their customers can often be found via a CSP’s shared responsibility model and service-level agreements. For example, organisations should note that they are still responsible for patching their applications and operating systems when using Infrastructure-as-a-Service.

Critical infrastructure

Critical infrastructure, such as Industrial Control Systems, are unique in the sense that they are often in a state of change freeze due to their requirement of high availability. Organisations with critical infrastructure will most likely favour manual patching over automated patching, and find through risk assessments that it is riskier to patch than it is to withhold from patching. These organisations should still seek to apply mitigations to address any identified security vulnerabilities. For example, network monitoring and segmentation might be applied instead of patching. It is up to organisations to define patch management processes that are in line with their business requirements and threat profile.

Summary

By maintaining a clear and streamlined patch management process – including an awareness of information sources used to determine whether security vulnerabilities are currently being exploited, an awareness of the regular patch release schedules of vendors, defined responsibilities for individuals involved in patching activities and regular vulnerability scanning for missing patches – organisations can position themselves to act swiftly upon security bulletin or patch releases. In doing so, organisations can dramatically reduce the time between noticing information on new security vulnerabilities and applying patches, or implementing temporary workarounds where appropriate.

Further information

The Information Security Manual is a cyber security framework that organisations can apply to protect their systems and data from cyber threats. The advice in the Strategies to Mitigate Cyber Security Incidents, along with its Essential Eight, complements this framework.