How do you handle patch

[RobertHammen]

How do you handle patch management in your organization? Here's an email I sent to a client that I contract for. We make sure to have a group of willing patch testers of different levels of experience. This organization also has a Change Management process where patches and updates need to be approved before they are widely released.
-
We're seeing an increased frequency of patches from Apple/Adobe/Microsoft/Firefox/Google addressing security and/or vulnerability issues on the platform.

Recent releases with significant fixes include Adobe Flash Player, Microsoft Office 2011 for Mac, and OS X 10.10.5.

There is a huge tradeoff between testing these releases extensively versus getting them deployed quickly.

I'd like to see some of these updates take precedence (i.e. typically by the time Flash Player is revised, there are a handful of known 0-day vulnerabilities in the wild) and be deployed ASAP.

Not suggesting we avoid the test loop, or change management, but, once a critical update is out, it gets deployed to test and tech workstations immediately that evening upon logout. If no problems are discovered within a week, it is run through change management and deployed everywhere.

Perhaps the speed at which updates are deployed should be categorized in some manner, i.e. High (critical, exploits in wild), Medium (exploits possible but not necessarily in the wild) and Low (minor changes which may not impact users).

High updates get deployed within a week of being pushed to testers
Medium updates get deployed within a couple of weeks of being pushed to testers
Low updates get deployed within a month of being pushed to testers

Examples of recent High updates: Flash Player 18.0.0.232, Adobe AIR 18.0.0.199, Office 2011 14.5.4, Firefox
Examples of recent Medium updates: Adobe Bridge 6.1.1
Examples of recent Low updates: Adobe Camera RAW 9.1.1

I realize the impact classification may be subjective (i.e. is 10.10.5 a High or Medium update? My vote would be High based on the DYLD vulnerability), but there will be times it may not be so clear-cut.

Open to thoughts and discussion.

[CasperSally]

For us, Java, Shockwave, Flash and Chrome updates get pushed out ASAP after some testing as they haven't ever broken anything for us in the past that wasn't solved by asking users to use Safari (because of Chrome deciding to abandon NPAPI, for example). Autopkgr definitely makes the testing process more streamlined.

I am evaluating 10.10.5 now. I'd like to push it but 2+ gigs is tough for us on wifi with thousands of machines, but more importantly in a student environment actually having the machines on long enough to install is the bigger issue. I saw over the weekend there's another root accessibility vulnerability in 10.10.5.

I am one of the few that wishes Apple would break up security updates like MS does that they could be more easily pushed and installed in an enterprise environment.

We get all machines to latest OS via imaging 1x a year. Even if we had Mavericks machines, I'm not sure how successfully we could even push and install the security updates for 10.9 that came out last week (over 200MB).

[davidacland]

We've used all different approaches with our clients over the last few years. Some like to enable completely automated"hands-off" updating and just deal with the occasional issues (not many have gone for that method), and others have a managed process going to a few users, followed by a wider group, then the rest (same as your description above).

In reality, certainly in the UK, a lot of organisations are predominantly Windows so still don't really take Mac updating very seriously.

AutoPKGr and related tools have helped make it a bit less laborious.

My preference is to wait a few weeks, then deploy to a small number, if no news comes back, increase scope to the rest. Ideally automating the whole process.

[kitzy]

@RobertHammen Just a heads up, you may want to remove the name of your client from that email.