Hello All,
Can anyone suggest the best practices to mitigate the vulnerabilities gap remediation Windows servers.
vulnerabilities data some times not found in the bigfix console, manual interaction needed every time to remediate the vulnerability gap. hence it takes time to close the gap.
Thanks much
Can you be more specific about what you are talking about? Are these patches or something that you think are missing?
Hi Alan,
there is scan tool from security team and always shows “relevant patches” where as those patches from BigFix already applied.
Are the patches in our support list? BigFix only supplies some, usually not including the optional patches, of the OS available patches.
Some of those required Virus scanning programs to be updated so the BigFix content applied those limits as well. Most of this would be in the descriptions of the corresponding fixlets or in the announcements on this forum
virus scanning programs updates from where, could you suggest?
CVE-2017-5715 actually
See https://support.microsoft.com/en-us/help/4072699/windows-security-updates-and-antivirus-software
i think it should be 4072698.
Basically we should run the powershell script given in Microsoft portal for meltdown/ spectre variant.
But need the step by step information so that same can be applied. as we are new to powershell script.
Thanks.
Microsoft will not apply the patch if the same information isn’t present, we just don’t make it relevant as a fixlet if the virus scanner isn’t updated. There are also some meltdown patches that interacted with older AMD chips so we didn’t make those relevant either.
As fixlets can affect a great number of machines, and some side effects were making the endpoints unusable, then our fixlets always err on the side of caution. Also we don’t have a UI to tell you that we can’t apply the fixlet.
To add to the advice @AlanM provides, there is actually a lot that needs to happen to secure a system against the Meltdown and Spectre families of speculative execution vulnerabilities. Some good guidance on the Microsoft side at https://support.microsoft.com/en-us/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities-prot
So you have a third-party scanner saying your system is vulnerable. It probably is correct.
Full remediation (at least, as full as what’s available now) requires steps as detailed in the referenced MS KB article:
If this is on a virtual machine, there are a couple of additional steps to take. I’ve only researched VMWare but there’s probably something similar for Hyper-V or others.
4) Apply updated BIOS firmware on the Host machine
5) Update ESXi hypervisor with the version released November 2017 at minimum (there may be newer ones now, been a while since I looked)
6) Apply VMWare Hardware Compatibility level 11 (ESXi 6.5) or higher to each virtual machine
Items 4-6 basically update the firmware of a virtual machine, I’ll ignore that for now.
The Powershell script hosted in the Microsoft Gallery checks all three items - BIOS updated, patches applied, and mitigations enabled in the registry. Your third-party scanning tool may be doing the same.
The first thing is to check whether the patches have actually been applied. As Alan says, the patches were coded to not install, and Bigfix made them not be relevant, until your antivirus product indicates it is compatible with the patch. This is because the first deployment of the Spectre patches blue-screened a lot of Microsoft’s customers due to antivirus issues. Check whether your machine has applied any of the Microsoft rollup patches since March 2018. If so, you have the patches.
Next check whether the mitigations are enabled in the registry. You can manually check the keys listed in the KB article. Microsoft does not recommend enabling the mitigations on Server operating systems, and I don’t think BigFix has provided content to enable the mitigations on Server. I think there is content for that over on bigfix.me, or, once you determine you want/need the registry updates on Server, post back here and we can help you write it. (I really think this should have been made available in the default Patches for Windows content, maybe as a Task with some specific warnings)
Third check is whether your system BIOS is updated to a version that actually provides the new microcode instructions that the mitigations are leveraging. For a certain set of chipsets and on the latest builds of Windows 10, Microsoft is delivering microcode updates on-the-fly. For the broadest compatibility, you’d need to flash the system firmware yourself.
@JasonWalker true, even we have to agree that every time microsoft releases patches to protect the meltdown and spectre issues in the every month since this tread came out.
I don’t recall now, but I have seen quite of patches we already deployed between the months of Mar till Aug 2018.
So hopefully we are safer side.
But still if you think we need take this step please suggest.
I’m afraid you’d need to do your own assessment of risk.
Basically, the factors to consider include
Microsoft’s judgement was that, by default, the performance impact to servers was greater than the threat and thus disabled mitigations by default on Server operating systems. It’s been published in several places that the April 2019 update to Windows 10, and likely uodates to Server 2016 around the same time, may switch to Google’s “retpoline” method and should have less of a performance hit than the current workarounds. Whether that actually works out as expected remains to be seen.
@JasonWalker, we did disable mitigations. As if my concern is the issue flown like anything over blogs but still have not seen anyone reported as victim.
Moreover, I see even in the Jan 3rd 2019 this has been brought under the patches discussion – Project Zero at google.
Rest we do the registry changes whenever it comes in the scanning report.
Thank you for the information by the way.
Sounds good, so long as you understand with the mitigations disabled your scanning tool will continue to flag the systems as vulnerable.
Yes that’s what happening. Please guide what should be counter part now.