IBM BigFix Patch will be enhancing how superseded OS patches are handled starting with the December Windows OS patch content on Dec 12, 2017. The current behavior where patches become not relevant when they are superseded will be maintained, by default. An option is being introduced to allow superseded patches to continue to be evaluated for applicability.
What is changing?
Superseded Windows OS patches will maintain their current applicability relevance and introduce an option to continue reporting relevant to endpoints that have not yet installed the patch (or a superseding patch).
âFALSEâ relevance will no longer be added.
New relevance will be added to preserve the current behavior, and optionally change the behavior using a new client setting.
The default action of superseded patches will be removed, and the option to install a superseded patch will be moved to a secondary action in the fixlet.
Why is this changing?
This change will allow users to continue reporting on older OS vulnerabilities because superseded patches can continue to report applicability when the vulnerability has not been patched, if desired.
Who is affected?
BigFix deployments subscribed to any Patches for Windows site.
Action to take?
To preserve the current supersedence logic where patches become not relevant when superseded, no action is needed.
To take advantage of the new superseded applicability logic, set the following client setting on each endpoint: _BESClient_WindowsOS_EnableSupersededEval=1
To deploy a superseded patch individually or as part of a baseline, a secondary action will have to be selected instead of the default action.
We may revisit whether the default behavior should change to use the new superseded applicability logic in the future, and welcome any feedback regarding this potential change.
If there is still a possibility for some additional improvements/enhancements, our group would love to see:
X-Fixlet-Superseded-Fixlet-ID: [12345,âŚ]
There is no consistent and reliable way to link fixlets that replace other fixlets, but having this 1 extra field would rectify this and make auditing and assessment far more reliable. This would not point to the current end of the superseded graph, but simply to the fixlet (or fixlets if multiple are required to fully supersede this fixlet) that initially replaced it.
X-Relevance-Evaluation-Period: 1:0:0
With fixlet relevance size growing exponentially to accommodate the more complex detection logic required for these new roll-up style patches, our client loop times are becoming massive and there is no way (other than to increase CPU utilization of the client) to get them back down. This (at the Superseded.fxf top file-level relevance) would help defer the impact tremendously and allow the client to spend more time assessing current content and respond to operational needs faster. Ideally, would love this to be a client setting but baring that, I think deferring superseded evaluation by a few client loops is something most customers would accept and requires no significant changes to implement.
And a semi-related (but not specifically for superseded content) requestâŚ
X-Fixlet-Group-ID: 12345
For patches that are broken up into multiple fixlets (e.g. same âpatchâ but requires different detection logic or installation logic depending upon the OS/arch/env/etc), this would be a key to leverage (vs parsing the fixlet name / source id) when trying to group these fixlets back to a single âpatchâ. If it were also then carried forward into the console(s)/web reports, it would help reduce the data overload users experience since it re-focuses the problem areas back into the patch domain from the current BigFix-specific implementation requirements domain.
One other future request. Could a fixlet attribute be added of âSuperseded = <YES|NO>â or something similar rather than having â(Superseded)â added to the end of the fixlet name? Having fixlet names change when superseded causes issues for our patching automation that leverages a specific fixlet name BigFix. A fixlet attribute would also allow users to easily filter fixlets by in the the BigFix Console/WebReports by âSupersededâ.
Currently, MIME_X-Fixlet-Superseded field is the closest thing that could help you, although I would agree that it doesnât point to a Fixlet now, it only contains the KB number or (historically) the bulletin number.
We are aware of this impact, therefore the current plan is to set the default to ânot evaluate superseded contentâ, which means unless you explicitly set a client setting, all the superseded content will skip evaluation totally.
Even if the setting is turned on, in the design we have group the superseded content by OS, which means your Win 8.1 machines will not evaluate superseded Win 10 Fixlets.
Also, not sure if you noticed, we regularly clean up superseded content. Any Fixlet that is superseded one year ago will be removed from the site completely.
All these should help to ease the burden of client evaluation time.
We do make use of this. Since it isnât 100% populated, what it is populated with is not consistent, and the reference it makes could potentially match multiple different fixlets, there is still much manual effort needed to fully link them. We have measures in place to assist and record these links⌠it would just be nice if they were pre-provided and created by the automated tooling that produces the replacement fixlet(s) and updates the titles on the existing fixlets with (Superseded).
Understood. While being able to skip evaluation entirely will be wonderful for many environments, we typically leverage extended deployment processes to allow for additional testing and validation prior to enterprise roll outs. As such, there may be times where new roll-up patches are released before all our systems have been updated so the disabling of content evaluation for all superseded content is of negative benefit to us.
Changing the existing multipart digest organization from Year/Month with no control relevance to OS/[Year/Month?] with control relevance will help, but with the ~104MB of superseded content to parse and potentially evaluate (in Enterprise Security alone), the impact is still sizable and only expected to grow as relevance complexity continues to increase.
Understanding the architecture limitations preventing dynamic relevance adjustments to the control headers, is there a general concern (that can be shared) against upping the evaluation period from 0:0:1 to say 0:2:0, 0:6:0, 0:12:0, or as originally noted 1:0:0? Is it purely because it will induce a potentially noticeable delay in the relevancy re-evaluation of all the superseded fixlets following the successful application of the top-most fixlet in the patch graph? Since superseded content already deviates from the normal expectations (always false vs real applicability), this could be an ideal time to also introduce an evaluation delay as the expectations are already slated to change when released.
This is noticed (and appreciated). The one-year mark is far enough out that for even the most severe feet dragging system owners, we can make (and usually win) the thou-shalt-patch-now argument. But in those very rare and (unfortunate) instances we canât, we maintain a complete archive of all fixlet content we can deploy as needed to maintain full visibility of patch compliance.
I see, I think I understand your use case now. Do you think capturing a group of Fixlets that you plan to roll out will help? Even if they are superseded in the site, the baseline wonât be updated unless you re-synchronize it.
That is one of the ways we deal with it currently. Ultimately, changing the fixlets to false or otherwise stopping the evaluation of them will impact our reporting ability. This is both a good and bad thing. Good in the sense that until there is a way to successfully automate the superseded patch graph we only see the most current patch and thus systems arenât double (or more) counted towards the same vulnerability. Bad in that we wonât be able to easily track the total time from first discovered/available to patched.
After this change, when I look at the relevance settings for any fixlet that is listed as Superseded, I now see
Relevance 2 - (value of setting â_BESClient_WindowsOS_EnableSupersededEvalâ of client as integer = 1) | false
Iâm assuming that is now why I see when I try to superseded fixlet within our environment, the fixlet doesnât install, it just comes back as âNot Relevantâ. This has created a huge problem, especially since Microsoft has been pushing out so many revisions to their patches this month, because now all of my tested versions of the patches from my Lab Environment wonât deploy to my Prod environment, because I donât have the BESClient setting set. Not to mention the fact that I have new servers going in the environment that need even older patches installed on them to get them at the same level of patching as the environment that they are entering
As such, it seems to me as if Iâm going to have to enable this setting on every single client in our environment, in order to ensure I can patch the clients when I need to. Might I suggest that a Fixlet be created specifically for enabling this setting, so that clients can easily make the change when required? How would one set this to be the default setting for all new clients added to BES?
Hi Tim,
Before this change, an explicit FALSE was added as Relevance 2 to all superseded fixlets, so they would not report applicability or be deployed. With the new setting _BESClient_WindowsOS_EnableSupersededEval you can actually override that and allow the fixlet to remain relevant (if the patch is still needed).
To enable this behavior by default, select two computers, then right-click and select âEdit Computer SettingsâŚâ In the dialog select or enter _BESClient_WindowsOS_EnableSupersededEval as a Custom Setting with the value 1. On the Target tab, select âDynamically target by propertyâ and âAll Computers,â then OK to deploy this setting as a policy to all endpoints.
Please be careful about deploying any superseded patches with its corresponding superseding patch, as this does not appear to be a tested/planned scenario by Microsoft, and could cause issues.
Iâve seen this behavior when Console Operators were not Master Operators. I was never sure if that was a quirk of how I configured the Console Operators, or if it was by design.
To get around it, you should be able to create a pair of Fixlets to Enable/Disable the new Client setting value.
Title: Enable Targeted Windows Clients to Evaluate Superseded Content Relevance:
1 - Windows of Operating System
2 - Not Exists Setting "_BESClient_WindowsOS_EnableSupersededEval" Whose (Exists Value of it AND Value of it = "1") of client
Action:
setting "_BESClient_WindowsOS_EnableSupersededEval" = "1" on "{now}" for client
Title: Disable Targeted Windows Clients from Evaluating Superseded Content Relevance:
1 - Windows of Operating System
2 - Exists Setting "_BESClient_WindowsOS_EnableSupersededEval" Whose (Exists Value of it AND Value of it = "1") of client
Action:
setting delete "_BESClient_WindowsOS_EnableSupersededEval" on "{now}" for client
NOTE: I originally listed âClientâ and it needs to be âclientâ (note the case difference!)
Hi Tim,
you are right, Iâm not Master Operator, but just Console Operator, so its probably the cause.
Anyway I created and tested the fixlets and its working fine.
Hey guys ⌠I know this thread is old ⌠but is there any plans to use a similar property _BESClient_WindowsOS_EnableSupersededEval for Ubuntu patches?
Majority of the Kubernet nodes are being built on Ubuntu, so we have large customers who are relying on BigFix to do patches report for Ubuntu OS.
Our users are always complaining that the superseded patches marked as false disappear from the relevant content and make things difficult to manage their reports.
Hey @Aram - I have not received any BESAnnoucement email notifications since June 8th⌠Has this replaced them? If not, how can I continue to receive them?
have made the same request: 
