During Wednesday’s beta milestone call, there was discussion about the criterial available for selecting patches within a policy. As followup, herein are the filters I use for populating baselines.
We used to create monthly baselines for each Microsoft patch set, and would periodically comb superseded patches out of the older months’ baselines. This proved very tedious and was an increasing labor cost as time wore on. Meanwhile, our service grew to accommodate tenant clients, and operators within those other organizations. We wanted to offer useful patching baselines to those customers, while simplifying our own operations, and . With this in mind, we borrowed Stanford’s idea for filters that define a baseline’s contents, using as operative goals:
- Baselines as a service
- Expediency of updating the baselines
- Tiers that reflect priority of installation
- Ease of understanding what’s in the baseline
- Ease of deployment, and redeployment
- Hire the computer – let relevance do the work.
Our tiers are:
- Windows Rollups / Cumulative Updates.
- Service Packs / .NET Updates
- Security Updates
- Security – Important, Other
- Updates (aka bugfixes)
5.1 Critical Updates
5.2 Updates for Office
5.3 Updates (other)
The goal is that, given a system of an unknown state (whether just imaged, or ingested into BigFix from unknown origins, or in regular operations), it can relatively rapidly level up to current features and patch security.