Frequency of Windows Server updates

There is no "right" answer to this. Some people (me included) like to patch as quickly as possible.

However, on some hardware and for some users, patches cause issues and so others like to wait a bit before doing updates.

No correct answer so you must do what you think is best.

I have to respectfully disagree with John's views on this point and think that not applying security patches immediately should be considered irresponsible on the part of network administrators.  The current world wide Ransomware outbreak that has crippled hospitals and other organisations because they haven't applied security patches that have been available for a couple of months is a very good supportive reason.

"Waiting a bit" in the illustrated case above has caused far more damage than a temporary glitch in operations which is easily resolved by rolling a system back, removing a troublesome patch or simply taking the time to find a workaround to deal with any issues a patch may have caused.

I administrate several company networks and though it has in the past caused me and the companies I look after some minor grief, it's understood by all that this is always a possibility and a risk that simply must be taken. There is little to no excuse (in my mind) for waiting to apply operating system security patches. They should be applied as soon as possible - Security must always take precedence over the possibility of a temporary inconvenience in the application of a vendor supplied patch.

In specific answer to your question, I would be insisting on the application of necessary updates immediately, along with the immediate remediation of any problems that may occur as a result of adopting such an approach.

I do have quotes from two other companies. We've been with the current company over 10 years, and they've helped us grow and survive a fried motherboard on the server, but I do question their patch policy and the "churning" of equipment.

Nothing wrong with loyalty as long as it is not being abused.  How did the quotes look, cheaper or around the same?

Regardless of the quotes, I think the proposed patch policy is seriously flawed and cause to raise suspicion on the part of the OP.

I would be expressing serious concern and objection to any proposed policy that suggests a "wait and see approach" before Security patches are implemented. This to me anyway, is a non negotiable point.

Glad I asked! I'm wondering if the current provider is "hand-managing" the patches and perhaps now has too many clients to do so effectively. Does a product like Solarwinds make the process more automatic?

More importantly is that patches are tested within the environment in a testing, UAT and production environment so that if issues exist with a patch that causes issue, it does not affect the whole environment

I think Solarwinds is a bit of an overkill for a network your size. WSUS which is the free patch management solution from Microsoft will be more than adequate for a network your size

Your point is well taken Shaun, but should that give valid reason to not apply realised security flaw patches? I think not.  

Every organization should apply security updates for their operating systems and that should be done as soon as possible. Once a vulnerability has been disclosed, it’s only a matter of time before attackers use that information to devise exploits. For whatever length of time goes by between a security patch release and when it's installed, your operating system will be in a zero day state for attack. Food for thought.

Best..

The competing vendor is not trying to sell us Solarwinds, it's just the product they use with their clients.

Totally agree. My point is just that the ASAP you are referring to is after testing, UAT and then it can be phased into production. These phases can be as little as a week apart and are easy to automate.

You opened up a very good debate Terry, and very relevant at this particular time. No right or wrong answer on this one I guess.  Each environment is different and it is all about managing risk.

Thanks for the terrific input. Clearly there is no single 'right'  answer, but I suspect all agree that a 3 month delay is a wrong answer.

3 weeks is a long time; 3 months is much too long.a wait. Beyond ransomware, missing 3 patch Tuesdays can also cause other issues

I concur most with two points: 1) Shaun's comment on testing first, and 2) There is no one right answer.

Testing patches when they become available is actually a smart approach. Sometimes for practical reason, a subset of them will have to get skipped on production systems for a timeframe (sometimes the issue becomes waiting for a patch from a software vendor). However, that comes down to what falls within the guidelines of acceptable risk for an organization. Some bad patches can simply be rolled back from, while others that doesn't always hold true (using a system state backup and risks of some level of data loss has come up in previous comments already). Besides, the ramifications vary considerably by organization as well (I work for a manufacturing company, where aside from your average workstation, I also have to worry about how manufacturing systems get impacted as well).

I've seen places that stay behind by one month to be sure that they have sufficient time to see how a patch impacts things. However, that is an outright defined policy and they do not aim to stay behind any further than that. But they had policy that was flexible enough to allow for current patches to be applied if deemed urgent enough.

But that said, I'm curious as to what your current agreement with your service provider is and what type of things are truly spelled out. Patching when you remember/want to do so is quite unacceptable. It doesn't even sound like wait and see, which isn't even a reliable approach because environments differ, Test and verify is really going to be the best way to move forward. Besides, a service provider at least gets to see how different places to get impacted and to identify common points (i.e. computers with Quickbooks get broken by patch X), so they have less of an excuse to not at least be testing patches in reasonable timeframe.

This discussion is antique. It has been led so many times I could print the threads and plaster walls with them.

Very, very rarely, patches screw up things. Very rarely. Our company installs them right away, always. Earlier, we tested them - in ten years we never found a single problem while testing - it was considered a waste of time. Since 5 years, we install them untested.
We don't think we take a risk because our image backups of servers are so frequent and the restore process so well tested, that we could rollback to pre-patch in less than an hour for any system. That is what anybody should work on: backup/restore concepts.

Another thing on testing: mostly people believe they could "test" a patch by installing it, rebooting the server and see "if it's working". People, do you know how many possible tests you would need to carry out until you can really confirm that all is well as it was before? Testing will never be complete and even if: you could use functionalities tomorrow that you didn't even think of today and those might be broken by a patch and you couldn't test that in advance - so what? Apply all patches in a timely manner.

The testing often deals with deploying client patches to a test group. On the server side, there is a defined....
Saying it never happened, misses the ms patch released 6-8 months ago that ms quickly pulled..though it dealt with client systems.

Knowing the scope of ones environment... No doubt this argument is in the bottom corner somewhere.
Patches from ms rarely impact/affect other ms products. Custom apps are not immune from coding that could be impacted by a security fix as was done in one of the .net framework patches ms released.

"Saying it never happened, misses the ms patch released 6-8 months ago that ms quickly pulled" - I am pretty sure we installed even that patch without consequences. Very often, botched patches will only affect systems under certain conditions.

The starting point of patch application is always to first identify the environment.
I.e. Users use application X, y, z and each application relies on a,b,c servers.

Test env(VMs or physical) apply update, test application's common functionality....

Your firm decided that instead of taking time/resources to test, they consume other resources or altered their backup plans to accommodate the rapid recovery.

How I'm happy right now. Just managed to temporary fix a problem on exchange server caused by #*$%#!%!! update installed yesterday.
And guess what - on Windows 2016 server there was no option to uninstall it...  ...just great.
I acknowledge the importance of updates and I OBVIOUSLY do install updates, but if I compare the cost of damage caused by updates to the damage caused because of non installed updates, the first one is multiple times higher. It is not the purpose of updates to limit the cost of (potential) problems?
I will need to learn to pray with new OSes coming.  Sorry for being sarcastic :)

Haha.. thanks for sharing davorin :)

With regards to your cost comparisons though, how much would you estimate a crypto locker attack might cause, as compared to the issues you've struck installing patches?  (Genuinely interested)