Ordinarily, our customers expect to simply install the latest patches and ignore anything that has been superseded. This minimizes workload while adhering to the policies that Microsoft has published.
Due to the critical nature of WannaCry and new emerging threats related to this vulnerability (Petya), the superseded patch updates that apply to MS17-010 (Security Update for Microsoft Windows SMB Server) will now be re-enabled for applicability reporting and patch deployment. We will remove the āFalseā relevance statements from lines 2 and 3 for these patches in order to allow our relevance to test if these older patches may still be applicable. This change will allow for continued reporting against these older critical patches which is normally not possible once a patch has been superseded.
While we realize this may mean some customers will see older patches as now ārelevantā and may require additional patch deployment to your endpoints, we felt that this extra level of visibility was warranted. IBM BigFix still encourages customers to follow Microsoft recommendations to install the latest cumulative patches to patch all known vulnerabilities.
Our intention is to carry this policy forward for all superseded patch content, but we would welcome your feedback on adopting this approach more gloabally. Please share any comments/concerns you have in reply to this post.
Please Note: Fixlet IDs 269654701 and 269654705 to disable or remove SMB v1, respectively, are also available to help further limit the spread of WannaCry and related threats.
Update: For those just joining/reviewing the discussion, here is an update to summarize the current plan for carrying this behavior forward to newly superseded content that is described in multiple posts below. The key changes that we are looking to make when superseding content in the future:
Instead of adding FALSE relevance to superseded fixlets, we will add relevance similar to the following to enable continued evaluation, by default, or keep the FALSE behavior using a new client setting:
not exists setting "_BESClient_DisableSupersededEvaluation_Win" whose (value of it = "1") of client
The name will still be changed to include the ā(Superseded)ā identifier
The default/existing remediation action will be disabled, and a new remediation action added to prevent superseded patches from deploying automatically during a baseline sync; but to still allow for the patch to be deployed, if desired.
Superseded content will still be moved to separate Superseded Patch sites after 1 year to minimize evaluation impact of old content.
Share your opinion about these proposed changes by commenting or voting in our poll.
We use supersedence for our internal metrics, so as long as the (Superseded) naming convention is maintained this would not negatively impact us.
I do have to voice an obvious question; if Microsoft for example is stating that the patch content is superseded, because newer or different content exists, shouldnāt that content be used instead? What are we gaining by seeing the relevance for content that is technically no longer deployable?
If you intend to re-instate the detection but keep the ā(Superseded)ā in the fixlet name, that would allow admins to at least be able to filter out Superseded bulletins from the perspective on metrics. For us, we exclude any bulletin fixlet with āSupersededā in the fixlet name but it would certainly be good to still have visibility of potentially still vulnerable systems. Surely though the superseded fixlets will need updating as they will not necessarily be relevant if a later update has been applied but with a different patch GUID. If you remove the Superseded from the description, all our enterprise reporting would most likely suffer a big negative hit and require a lot of re-engineering.
From the point of the new MS17-MMM CU updates, we certainly lose visibility of vulnerable systems from the previous month patch cycle. Say a machine is missing MS17-MAY and has not yet received MS17-JUN, it is still vulnerable for but now that MS17-MAY has a hard coded āFalseā in the relevance, the visibility is lost. I guess from the detection side, that wouldnāt need any additional maintaining as the CU version for MS17-JUN would be higher than MS17-MAY so would make both the May and June CUās detect as not relevant once MS17-JUN was applied.
Thank you. When the āFalseā relevancy is added to superseded fixlets, itās pulling the patch out from underneath us when we may still need to deploy it (superseded version tested - replacement version not yet tested). Only adding ā(superseded)ā to the name but leaving relevancy changes alone matches up with how youāve treated superseded Red Hat patchesā¦and I like that.
I appreciate the change as well, and think itās the right thing to do. Keeping āSupersededā in the name letās us know we shouldnāt still need to deploy it, and keeping the applicability relevance shows how far behind a system may be. Iāve been keeping old, unsynched baselines around for that reporting, and itās a welcome change if I donāt need to continue that practice. Thanks very much!
So the change will be to:
Re-enable only superseded patches IF they are still relevant but leave the āSupersededā text in the patch name.
New patches that are sucessors will be not touched, relevant as before.
We essentially did this on our own for this vulnerability by creating a custom copy of the MS17-010 fixlets. While I understand the desire to do this, I just hope it is being well thought out and not just making a change as a knee jerk reaction to a series of exploits. I think some new features may need to be added to the console in order to support this change.
Will there be an easy way to remove superseded fixlets from existing baselines? Previously we could just āsync allā the baseline and didnāt have to remove the superseded fixlets because they would never get installed.
Will there be a way to filter out the superseded patches from the list of fixlets in the bes console? When deploying many patches to a device that was just added to the network it will be more difficult to select only the patches that are needed to be deployed for that device.
The older content is still deployable, though Microsoft obviously recommends deploying the superseding/most current patch to resolve both older and newer vulnerabilities. The change is really to enable better reporting against older vulnerabilities. The patch is what is superseded, not the vulnerability, so it makes sense that you would still want visibility into that.
We are keeping ā(Superseded)ā in the name, so it will be clear that they are superseded. So if MS17-010 was not patched by applying the original patch or one of the superseding patches in April, May or June, then it will still show relevant. If you then apply the patch for MS17-010 or any of the later cumulative patches that include it, the fixlet will become not relevant (as usual).
Good feedback. We are definitely working on how to preserve the existing patch workflows as best as possible. The WebUI already excludes superseded patch from the patch list by default to encourage deployment of only the current ones. We will need to enhance the console to support easier filtering of superseded patches, as you suggest. Baseline syncing is another challenge. Would people prefer that superseded patches were just automatically removed from a baseline on sync, or maybe we could provide a new button to do that, as desired?
To add to this discussion, one of the things weāre exploring for superseded Windows patch content moving forward is to make this behavior configurable. Rather than simply removing the āFALSEā statements, we can include relevance logic that checks for the existence of a Client setting that determines the desired behavior:
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)
Based on this, the superseded Fixlets moving forward might look something like this:
In this manner, customers that would like to be able to report on applicability of superseded Patch Fixlets (and potentially deploy them as actions) would be able to do so either globally, or for specific endpoints or groups of endpoints, by configuring a Client setting via a Task that IBM provides as part of the site. This Task could be leveraged to configure the setting as an open policy action to set the desired behavior.
Again, we welcome any feedback/comments/questions/concerns!
I like the idea of being able to control this at the client level. As clients not reporting relevant for a missing MS17-APR or MA17-MAY after the MS17-JUN is released causes a loss in visibility of vulnerable system, I would prefer that clients report on superseded by default and then use the setting to stop that but I can appreciate others may prefer the behavior to be the reverse.
for the button that can remove all superseded content from a baseline[quote=āsteve, post:11, topic:21900, full:trueā]
Would people prefer that superseded patches were just automatically removed from a baseline on sync, or maybe we could provide a new button to do that, as desired?
[/quote]
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?
for the button that can remove all superseded content from a baseline[quote=āsteve, post:11, topic:21900, full:trueā]