1 - treat superseded Fixlets as non-applicable by default
or
2 - allow the Client to evaluate the superseded Fixlet to identify whether or not it is applicable to the given endpoint (this also would enable deployment of these superseded Fixlets if applicable)
I would personally like option 2 here. As you mentioned previously this allows reporting/viewing to see how far a system is out of date. Also as mentioned by another user there’s the testing portion that is involved with newer versions of patches. When Wannacry became a hot button topic we had already gone through the testing with the initial patch and had been deploying it for some time. For the systems that did not have it installed already it was a simple push it out scenario which saved lots of time and made our customers feel at greater ease where we were able to so quickly respond to their requests.
To follow up on this, and based on some of the feedback thus far, we are exploring the following changes:
Address visibility concern by NOT including ‘FALSE’ logic in the applicability relevance. Make the visibility behavior configurable by instead including relevance logic that checks for the existence of a Client setting. Sample relevance:
not exists setting "_BESClient_DisableSupersededEvaluation_Win" whose (value of it = "1") of client
The above relevance statement will be ‘TRUE’ by default, meaning that Superseded Windows Patch Fixlets can report as applicable on endpoints if they are actually missing the superseded Patch. This is a departure from our current default behavior, but provides visibility by default. Customers that do not wish for endpoints to evaluate Superseded Windows Patch Fixlets can configure the _BESClient_DisableSupersededEvaluation_Win setting as desired (we will provide a Task to simplify this). Note that if evaluation of a superseded patch Fixlet is enabled, and the newer patch has been applied, we would not expect that the superseded patch Fixlet would be applicable (even with the above relevance logic included).
Disable default remediation scripts of superseded Windows Patch Fixlets. Given some of the concerns around installing superseded Patches (potential BSODs, general instability), the default behavior once a Windows Patch Fixlet has been superseded should be to prevent its distribution/remediation. This can be achieved a number of ways, but one approach would be to change the Action1 type to ‘URL’ which links to the KB article and does not have the remediation actionscript. We can then include a new Action2 which would contain the remediation actionscript with appropriate warnings. In this manner, any baselines that are synchronized with the now superseded Fixlet will not have a remediation action for the given Fixlet, and any customer that wishes to actually deploy the superseded Patch can do so by selecting Action2 for the given Fixlets in their baselines.
As always, we welcome any feedback/comments/questions/concerns!
If a patch is superseded, but still applies, it should remain relevant and deploy-able.
As other have mentioned sometimes testing and version control can require the deployment of an older patch. Recommending or guiding to the latest patch set would be nice, but it should not remove the ability to deploy older patch sets, if there remains a business requirement to do so.
I agree that disabling the default remediation scripts on superseded content would be a good safeguard against accidental deployment, but retaining the ability to deploy the old content is essential.
Since MS17-010 remediation is part of why this is being discussed, an easier path to showing remediation of specific vulnerabilities or patches is a critical reporting component.
If asked to demonstrate that a system is patched for MS17-010, I should be able to without having to call out that I applied the June patch release instead of the May release. A potential solution for this is to include all rolled up CVE IDs in the subsequent patch content.
As of now, when I search for MS17-010 content in the Bigfix console, all I return is the March content. Worryingly I see systems that show relevant to the March content, but do not show relevant to CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147, or CVE-2017-0148 in the Vulnerabilities to Windows Systems site.
this is what currently irks me, as well. I can’t just look at my console and very easily say “yep, that’s patched”. I should have a single source of truth to feel confident about it. it’s becomingly overly complex for such a simple need. going forward, would I be able to look at the superseded patches and trust their relevance that something is not patched if their are relevant targets?
the superseded march patch is applicable to some machines, but they have more recent cumulative updates applied. in theory, the cumulative updates should have that march patch covered. … but when reviewing the srv.sys file version as per MS’s article, it shows that their version is vulnerable still, so they need them, I think. pushing out a 1gb+ patch out of concern of the unknown kind of stinks for some of our sites. I’m also concerned that at some point I will push out an older patch to a system and will suffer some consequences for it.
I’ve updated the original post to include the 4 key changes we are looking to make relative to superseded patches, so people don’t have to piece it together from the different posts. Thanks to all those who have provided feedback so far! Others, feel free to comment or vote anonymously about the proposed changes:
Do you prefer the proposed changes to superseded patch handling versus the current behavior?
Hello, It seems that we have a lot of people that likes this new “way” to handle the superseded patches for windows.
Do you guys have any idea in how it will be released for all the other patches ? I know that will be a lot of update work, but I have customers asking about it as they will have a huge benefit from this change.
If you mean patches for other OSes, yes, we would extend the logic to other sites, but it will take a little time to implement the changes across all the sites.
So…when do we expect this new behavior to be in effect? I see that the July rollup packages for Windows have been superseded, with the same old “FALSE” relevance added…
We will send a BESAdmin (and forum) announce a few weeks prior to the change so everyone can be prepared. I know that people are anxious for this change, but we want to make sure we’re carefully considering all the impacts, dotting the i’s and crossing the t’s, so to speak. Right now October is the target, so not too much longer.
The proposed new methodology for superseded patching is fine, but appears to have missed a critical piece of vulnerability remediation. Will the new patches be tagged with all the CVEs they resolve? Including all of the “roll up” items they cover?
Are you asking that superseding patches include the CVEs of all the patches that they supersede?
E.g. July patch resolves CVE1, CVE2, & CVE3; and August patch supersedes July and resolves new CVE4, CVE5, & CVE6. Currently, each patch would list the three CVEs they were released to resolved. You want the August patch to list all 6 CVEs (CVE1, CVE2, CVE3, CVE4, CVE5, & CVE6)?
Steve, yes. It’s the only way to provide proof to auditors that you have properly patched a system without applying the old patch, which is explicitly against Microsoft recommendations.
Since most patches are cumulative now, though, we would potentially have 100s of CVEs listed for an individual patch as we get further in the maintenance stream. That seems quite unwieldy to manage, imho. In the new scheme, you would prove your compliance to auditors by showing that the original CVE patch is no longer applicable because it would remain so until some resolving patch was applied.
If reading correctly, the client setting will only be required if you DONT want clients to evealuate the superseded fixlets, correct ?
When will the FALSE statements be removed, this is a good change …
Are we still looking toward this change coming into effect for the October rollup packages? Will the September package be the last to get superseded, or the first to not be superseded?
For those watching this thread, here’s a query I’m beginning to use (still testing) to identify systems that may be behind or failing rollup packages. I put this into an Analysis to evaluate daily:
names of keys whose (name of it starts with "Package_for_RollupFix~" and (value "CurrentState" of it as integer is contained by set of (112;128))) of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" of native registry
Ref: Component-based Servicing chart, status descriptions:
It looks like the change won’t make the October patch cycle, but Nov or Dec. So October or November patches will be the first that do not go FALSE automatically when superseded.
We are planning to beta the supersedence changes this month, and then GA the change in the December patch cycle. If anyone is interested in getting a preview of the new behavior and is willing to load a beta site with superseded fixlets using the new logic, please message me in the forum with your email address and company name. I will forward the requests to our patch team to include you in the beta.
This change is really useful, however im now seeing backdated superseded content for the monthly rollups, specifically Win7 that are showing as relevant when the Jan rollups have been installed and are not relevant (which is good)