HCL really needs to stop adding additional updates using the Microsoft release date, the date HCL makes them available would be much more helpful. Either that or add an “HCL Release Date” column to go along with the “Source Release Date”. This really screws up my baselines and I have to recreate them because it is easier than having to figure out what updates are newly released (HCL) and what was published with the original batch. I patch Dev and Test servers on “Patch Tuesday” week and production the following week. .NET’s being released by HCL late also makes that difficult as well. I can’t push .NET’s to prod the second week I patch without pushing them the week of patch Tuesday for testing. Yes, I’ve heard the reasons for it, but we really need them released with the rest of the group.
I’m struggling to hold on to BigFix as our patching solution, and not having all the updates in our scheduled timeframe makes that a difficult fight with management.
I get your frustration but I think you need to review the normal patch deliverables SLAs and adjust your patch work timeline accordingly. For example, “Security updates” and “Critical” patches are released up-to 24 hours after Microsoft release; non-security and application updates I think were 48+ hours (I am not quoting exact numbers just from memory, so please reach out to HCL officially to get the exact numbers). Those are maximum times too - usually patches are released much faster… Once you adjust your timeline, you should not have any issues - we’ve been using BigFix for 15 years for patching servers and can count on one hand the times we had issues (missing patches coming out late and such). We use Wednesday-Friday to compile the patching baselines & test them; on Fridays by midday EST would release the final patching baselines and patching commences from Friday night with the same exact structure you’ve mentioned (DEV & Test first, then UAT & DR following week, lastly PROD).
That said, I do agree that meta-data for fixlets is something to be desired for. Maybe a secondary field that will show the actual “fixlet release date” apart from “source release date” would be good. I had an RFE back in the IBM days to also allow custom fields for content too, where you can “tag” stuff or even track some internal information (custom CVSS; potential exclusion justifications, etc)…
We have the same issue. We send out notices early Wednesday, after patch Tuesday and the next morning we will see other new patches. Trying to separate them from the ones we have already deployed is difficult. We used to have a compare process from one day to the next.
Now we have written them in to our report process. A list of all patches is saved to a sql DB. The next day a new list is added. Then there is a compare done in SQL and we get the results. We actually have a report we wrote and can run to go back as many days as we want. “Pull all new patches over the last 4 days”
I would love to see a “Fixlet Date”. It would be very helpful, especially when relevance is updated and the fixlet needs to be synced with baselines.
We are an MSP with hundreds of customers and 10s of thousands of endpoints and we can’t use the built in reports. We export the DB to a report server and wrote queries to provide reports to our teams and our customers.
I use this session relevance to find everything updated yesterday or today.
(
name of it , category of it , source severity of it , source release date of it , modification time of it
)
of fixlets
whose
(
fixlet flag of it
and
modification time of it as universal date >= current date - 1 * day
)
of all bes sites
whose
(
name of it = "Enterprise Security"
)
It doesn’t tell you which ones are new or merely updated of course, but a simple update can easily invalidate the results from your test and pilot actions.
As suggested above, we do include ‘modification time’ metadata for Fixlets in External sites, and I could see publishing a creation time for Fixlets in External sites as being useful. We can certainly look into that as well as exposing them in the UI.
Have you looked at or considered Patch Policies as a way to introduce some additional automation here and eliminate the need to create/update/maintain baselines?
I have the same issue – due to Audit policies our baselines must be created on the Thursday morning after Patch Tuesday and we start patching Dev at 7am on Friday.
Many times there are .Net and other patches released on Thursday afternoon and it messes with the Audit documentation.
Having at least an HCL release date would be extremely helpful when the auditors ask questions