SearchWinIT.com recently asked Shields to give his post mortem on DST patching and to offer some patch management advice for next time if the U.S. Congress decides again to switch back the day DST occurs.
SearchWinIT.com: Daylight-saving time patching was a big headache for a lot of IT administrators. We know there were patches to the patches and last-minute changes, but some people seemed to be in pretty good shape while others floundered. What happened there?
Greg Shields: The people I saw who did relatively well seemed to follow the directions -- which many would say were exceptionally and unnecessarily complicated -- in Microsoft's Knowledge Base article to a T. One thing I saw is that many people just focused on their Microsoft patches, making sure they were done, and forgot about all the other product patches that were necessary, like Java. In all these situations it's important to figure out what all your issues are and think it through before you do anything.
What procedures will improve the patching process for IT departments?
Shields: The most important part of a good patch management strategy is having a scheduled reboot strategy. Sometimes people say, I'll just patch now, and they don't reboot the computers at a scheduled time. If you don't have a scheduled reboot time, then you don't have a complete patching strategy.
It's important to get upper management to buy into a specific, pre-defined window of time on a weekly basis for a reboot schedule. That way it can be done during low-use times of the system, and you're not going back every week to negotiate that time. I recommend a two-hour period twice a week.
Why is the buy-in of upper management so important if IT managers are the ones tasked with patching and network security?
Shields: The people who do all the patching are technically minded and usually not aware of the business requirements of a company. That can negatively impact the agility of the company to respond to the marketplace. The more communication there is between IT and the business people, the better things will be -- like determining a reboot period during a time that it won't affect the business side of things as much.
How quickly do you recommend IT managers put patches into their systems?
Shields: One of my answers on how to improve patching -- and one I get a lot of flak for -- is don't be an early adopter of the patches. Let other people find out where the problems are, and then patch. Of course, there is an asterisk [next] to that, and it is that you should have additional protection for your network, something at the perimeter. If you have the right protection, you can wait a week and see where others had problems before you do anything.
Name some of the ways that patching has improved. Do you have a better idea for the process?
Shields: I think Microsoft's Patch Tuesday is one way that patching has improved. Now at least it is scheduled. An IT person can say, 'OK, I know on this date I'm going to have patches' and plan accordingly. Before that, Microsoft released its patches randomly, and as an IT person, you'd have to rearrange your personal life to take care of them. It gave IT people their personal lives back.
Right now, I think [Patch Tuesday] is the best process for releasing patches. With all the teams at Microsoft that work on security and patching and that came up with the process, far be it from me to second-guess it.