Supersedence handling change for Windows Patches

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.

4 Likes

its really welcoming decision and this will enable more accuracy in patch compliance report.

2 Likes

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?

4 Likes

While changing relevance 2 and 3 to TRUE, so patch will be relevant, are you going to remove the “(Superseded)” text from patch name?

2 Likes

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.

2 Likes

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.

2 Likes

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!

4 Likes

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.

?

2 Likes

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.

2 Likes

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.

1 Like

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?

2 Likes

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!

2 Likes

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.

2 Likes

:+1: 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]

2 Likes

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.

2 Likes

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!

3 Likes

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.

1 Like

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.

1 Like

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?

  • Yes
  • No

0 voters