Security Manager's Journal: When is a patch not really a patch?
Answer: When the patches are dutifully installed but the servers aren't rebooted -- for more than two years.
December 1, 2008 12:00 PM ETComputerworld - I made a disconcerting discovery last month when Microsoft released a security patch outside of its regular monthly routine. How disconcerting was it? I'm talking about the discovery that a lot of the patching we've done to our more than 450 servers has never gone into effect.
Let me give you the background.
Each quarter, I present metrics to our CIO, including the percentage of servers that are compliant with the latest recommended critical security patches. Our Windows desktop and server team meets once a month to review the latest Microsoft patches and decide which ones we should apply based upon criteria we use to classify the threats. Patches we choose to apply are pushed to our servers and desktops, and then I check our Microsoft Systems Management Server to gather the information for the CIO.
I'd always assumed that when the SMS reported that a particular server had been patched, I could run with that information. Nope; there's a gotcha.
Trouble Ticket
Issue: Over the years, hundreds of servers have been patched but never rebooted, so the patches haven't actually taken effect.
Action Plan: Take them all down on a Friday evening and keep our fingers crossed that no applications break.
If you don't reboot a Windows server after a patch is applied, the patch doesn't take effect, but SMS doesn't notice that failure to reboot. This insistence on rebooting is one of the things I dislike about Windows. In the Unix world, all that's usually required is that a particular process be restarted.
When that so-called out-of-band patch came up, I attended a meeting to discuss whether it would be necessary to install it on all of our servers and 8,000 desktops. From what I had read ahead of the meeting, I was convinced that it was absolutely necessary. The patch fixes a vulnerability in the "server service," which lets Windows communicate with network devices. A remote procedure call could cause a Windows system to execute arbitrary code, and reports were already circulating that exploit code and a worm had been developed. In other words, this was one vulnerability we couldn't afford to ignore.
Never Assume ...
It was during that meeting that I made my disconcerting discovery. The IT managers were freaking out that they would have to reboot over 450 servers. My first reaction to their concern was confusion. Making assumptions can get you into trouble, and my assumption that the servers were routinely rebooted after patches were installed certainly fit the bill. I found out, in fact, that many of our servers hadn't been rebooted in over two years. They had more than 24 months' worth of patches installed on them that were doing us no good.
patching
Additional Resources



Learn the important issues you must consider before starting your next mobility initiative. Get your mobility white paper from IDC now, compliments of Sybase.
White Papers & Webcasts
Share our Strength
Download Now
Lower the Cost and Complexity of a Mobile Workforce through Automation
Download This Resource Now!
Top 10 Things to Know about Data Protection
Download Now
Managing Mobility: Improve Data Security, Compliance and Manageability
Download This Resource Now!
Managing Secure File Transfer to Save Time, Money and IT Resources
Learn how companies are using innovative technology to overcome these challenges and improve user productivity by offloading e-mail attachments and replacing FTP with...
Ponemon Study: The Business Risk of a Lost Laptop
Download Now
Security Convergence Equals Network Security Cost Savings
Listen to IBM Internet Security Systems' take on network security convergence.
Airport Insecurity: The Case of Lost Laptops
Download Now
Disaster Recovery 2008: Reduced Costs and Improved Performance
How long can your Enterprise afford to be without your data? With an accelerated disaster recovery program, you never have to answer this...
