Two Reasons NOT to run the SQL Server Features Discovery Report

Have you ever noticed a very long delay when running the normally fast-loading SQL Server Features Discovery report?

You may have chalked it up to coincidence.  After all, it returned results quickly enough before and after that one unexplained long wait.  If you are anything like me, you scratched your head and then moved on.

But after few hundred SQL Server STIGs, this delay occurred often enough for me that I started to wonder just what was going on.  When I decided to track it down, the results of my investigation were a little scary.

Reason number one NOT to run the SQL Server Features Discovery Report

First, I discovered that some host intrusion protection systems (like HBSS, for instance) block this report by default as an application hooking intrusion.  I used to think this was an error, and simply requested an exception from HBSS, citing the STIG requirements in V-79173 and V-79175.  When I dug deeper, however, I began to see there was a good reason to block this report.

Reason number two NOT to run the SQL Server Features Discovery Report

My second, and more worrisome finding, was that the SQL Server Features Discovery report appears to rely on the WMI's WIN32_Product class to return it's results.  Most of the time, this is a trivially simple SELECT action against the class, but sometimes...

Because this data is not live, Windows will occasionally decide to rebuild the entire product catalog when SELECTs are made against this class.  I can find no specific info on the trigger, but I think it safe to presume it is date-sensitive. 

Microsoft has only a few articles on the subject, short on details, like the one below:

https://support.microsoft.com/en-us/help/974524/event-log-message-indicates-that-the-windows-installer-reconfigured-al

Interesting, you might say, but why--aside from the possibility of the occasionally annoying delay--would I decide to never again run this report?  Especially when DISA mandates I run this report for both V-79173 and V-79175?

Here is why.

Rebuilding the product update catalog can also trigger the application of some pending software updates of installed programs.  

That's right... you think you are only running a report, but in some cases updates can be applied without your knowledge and outside of your planned maintenance window.  And if something goes wrong with an update you don't even know occurred, it can be a real bear to troubleshoot.

DISA checks are supposed to be just that.  Checks.  So once I discovered that the SQL Server Features Discovery report could result in unscheduled updates, I knew I couldn't keep running it alongside the rest of my checks.

But how, then, can I comply with V-79173 and V-79175?

A safer alternative for verifying installed SQL components and features is to search the registry hive, and so this is the method I adopted for myself, and for ASSET (my Automated SQL Security Evaluation Tool).

I include all of the information in the SQL Server Features Discovery report, and the results are accurate, but SLIGHTLY less granular than the report itself, in that items like management tools and client tools are not broken down into sub-components.

What about IA?

I have found most IA departments--and most auditors--very receptive to well-reasoned arguments against blind adherence to the letter of these STIG checks if you can prove the check (or fix) text contains an error, and that your alternative meets the intent of the STIG.

I have never yet been asked to run the SQL Server Features Discovery report after providing this explanation, and the alternative results of my registry scan.

Leave a comment

Please note, comments must be approved before they are published