Doug
Thu May 10 19:11:36 CDT 2007
Harry,
Thank you for posting this - and I appreciate your feedback. Although I
can't address all of the issues, I'd like to clarify a few items that may
help with your concerns.
We made a strategic decision with MBSA 2.x to align the scan tool with WSUS
technologies (the same technology used in Windows Update, Microsoft Update,
WSUS Server and SMS ITMU). This does three major things: ensures all
Microsoft tools provide the same result, moves to an agent-based scan model
and invests in a Microsoft technology that can dynamically expand to include
support for new products as needed.
First, alignment with WSUS technologies resolves an overwhelming number of
customer issues where one Microsoft scan tool would report one result while
another Microsoft technology would report another result. This led to
customer confusion, a lack of trust in Microsoft's commitment to security
and generated a number of costly concerns for customers.
Second, the move to agent-based scanning helps ensure a higher success rate
when performing remote scans. When MBSA was originally released, security
was not as crucial as it has become today. Now that firewalls and more
secure clients are commonplace, the MBSA 1.x technology that required direct
access to the C$ share and remote registry on each target machine actually
imperils clients and puts them at potentially higher risk. The move to WUA
agent-based scanning allows for more secure access to target machines and
enables all Windows platforms released since Windows 2000 SP3 to include the
needed technology - in the box - to perform critical remote security
assessments.
Third, with the limited, hard-coded product list built into MBSA 1.x caused
substantial gaps in MBSA 1.2.1 detection. The number of Microsoft products
that cannot be supported by MBSA 1.x has increased to the point that MBSA
1.x technology can no longer be used for comprehensive security assessment.
This is why monthly editions (now 17) of the Enterprise Scan Tool are
necessary to fill the gap for critical updates MBSA 1.2.1 cannot provide.
For customers with the latest versions of Microsoft products, MBSA 2.x
provides a single source for all security update assessment needs. Unlike
MBSA 1.x, MBSA 2.x also supports x64 (64-bit) and ia64 (Itanium) as well as
the Windows XP Embedded platform - further filling the charter to provide
comprehensive security update detection. For those rare cases where legacy
Microsoft products not supported by Microsoft Update are present, MBSA 2.x
results can be augmented with a single tool (not 17) to enable comprehensive
security update detection in a way that MBSA 1.x could not (see
www.microsoft.com/mbsa for details).
To address your specific concerns:
Firewall Exceptions: The requirement to enable a Windows firewall DCOM
exception is no greater work than is necessary for fire protected clients
scanned by MBSA 1.x. The guidance in the MBSA 2.x FAQ even enables this
through group policy to ease the administrative overhead.
No Secondary Validation against Microsoft Update: This is true. Since MBSA
2.x and Microsoft Update are now based on the same underlying technology,
MBSA can no longer by used to 'double-check' Microsoft Update or WSUS Server
results. If it helps, any logic error that causes incorrect reporting is
usually fixed in very short order since the same logic affects - literally -
millions of customers using Microsoft Update as well.
WUA Installation Required: Although the existing WUA client may not be
sufficient in all cases, it is for most. To ease updates to the latest WUA
client, MBSA has an option to automatically deploy the revised WUA client
(this will be turned off by default in MBSA 2.1). Windows machines are
likely to be updated by other means (Microsoft Update, WSUS Server, SMS
ITMU), so it's not surprising that MBSA also attempts to make an update to
the target WUA client an easy and reboot-free update.
Confirmation of Installed Updates: This is actually greatly improved in MBSA
2.x. By default, MBSA 1.x could only report what updates are installed. In
the MBSA 1.x command-line interface, the -history switch could be used to
report explicitly installed updates - but only in the CLI, not the GUI.
MBSA 2.x provides reporting for both 'needed' (missing) and installed
updates by default in a single interface - whether GUI or CLI.
I hope that helps, Harry - and if you have any additional feedback regarding
MBSA, I'd like to encourage you to download the MBSA 2.1 Beta 2 (just
released yesterday) and provide insights in this newsgroup.
--
--
Doug Neal [MSFT]
dugn@online.microsoft.com
This posting is provided "AS IS" with no warranties, and confers no rights.
If newsgroup discussion with experts and MVPs is unable to solve a problem
to your satisfaction, feel free to contact PSS for support on the Microsoft
Baseline Security Analyzer (MBSA). Information is available at the following
link:
http://support.microsoft.com/default.aspx
This e-mail address does not receive e-mail, but is used for newsgroup
postings only.
"Harry Johnston" <harry@scms.waikato.ac.nz> wrote in message
news:OKvuam0kHHA.4628@TK2MSFTNGP06.phx.gbl...
> Doug Neal [MSFT] wrote:
>
>> On October 9, 2007, the MSSecure.XML file used by MBSA 1.2.1 will no
>> longer be updated. After this date, no new security updates will be
>> added to the MSSecure.XML file used by MBSA 1.2.1 and no new versions of
>> the Enterprise Scan Tool will be released for standalone use.
>
> This is sad news. MBSA 2 is klutzy:-
>
> a) it doesn't work if Windows Firewall is on unless you're willing to hack
> about in the registry to reconfigure the WUA and add a custom port in the
> firewall. (Compare this to MBSA 1.2.1 which works as long as remote
> administration and file sharing is allowed.)
>
> b) because it depends on the WUA to detect patch status, there's no
> redundancy against Windows Update/WSUS; when Microsoft make a mistake in
> the WUA detection logic for a vulnerability, there's no longer any
> straightforward way to tell, so it's likely to be overlooked indefinitely.
> The WUA detection logic has been faulty in the past, so don't think it
> doesn't happen.
>
> c) it doesn't work against an untouched machine, you have to install WUA.
>
> d) I'm suspicious of it's ability to detect the situation where an update
> wasn't installed properly; does anybody know for sure whether it can tell
> if an update that is listed as having been installed wasn't in fact
> successful?
>
> For those who afford it, I'd strongly recommend investing in the
> equivalent Shavlik tool. It's too expensive for us. I don't suppose
> anybody knows of a free or cheaper equivalent?
>
> Harry.