During his 10 years as a systems administrator, Mark Allen handled more patches than he can number. "There are too many patches, too many systems and not enough time," Allen said.
Learning by doing and doing and doing, Allen devised his own best practices for managing security patches. Along the way, he became a security and patch-management expert and moved from systems administration to security consulting. Today, as CTO of Sunnyvale, Calif.-based Gibraltar Software Inc., he heads the development team for the company's Linux-based Everguard patch-management system for cross-platform networks.
"Patching can be a difficult, thankless job," Allen said, adding that these dos and don'ts can save you time and effort.
Don't ignore vulnerability alerts and patch releases. Overlooking one patch can be a recipe for disaster. "Even obscure patches can be important defenses against worms and system attackers," Allen said.
Failing to deploy patches gives worms like Lion -- which exploits a flaw in Berkeley Internet Name Daemon (BIND) to infect Linux systems -- an invitation to invade your systems and networks. Unfortunately, Allen noted, most administrators fail to patch systems regularly. As a result, worms get in, even though patches that would have blocked them have, in some cases, been available for months.
Do choose your patching battles. "Everyone knows the work of deploying patches is overwhelming," Allen said. In an ideal world, you'd have the time, manpower and/or tools needed to patch every machine. In the real world, if you can't cover all your systems, pick machines that are business-critical or Internet-facing. Then, be "especially vigilant" about those systems' security maintenance, Allen said.
Do test your patches before you deploy them. "Patch quality varies greatly from vendor to vendor and from patch to patch, even if the patches are from the same vendor," Allen said. "Make sure you have some machines to use as guinea pigs before you deploy a patch widely or on critical production systems."
Do ask your peers about the patch in question. "Check around on the Internet to see what experiences others have had with a given patch," Allen said. If you can't find anything on that patch, then post a question in a discussion forum or ask online experts for advice. (See forum links at the end of this article.)
Don't deploy a patch "unless you have a plan to back out of that patch," Allen said. If your vendor's or open-source software development team's patch-installation tools do not support rollback, make sure it would be acceptable (and possible) to reinstall a patched system, if necessary.
Do take advantage of free security alerts. For example, each week the nonprofit, vendor-neutral SANS (SysAdmin, Audit, Network, Security Institute) offers personalized "Security Alert Consensus" reports that "summarize the vulnerability traffic of several major security research mailing lists, broken down by software vendor categories," Allen said. "Additionally, if your network relies on a specific OS or system software vendor, make sure to subscribe yourself (or your team) to that vendor's patch announcement lists."
FOR MORE INFORMATION:
Got a security question? Pose your question to SearchEnterpriseLinux.com's security expert, John H. Terpstra.
- FEEDBACK: What is your enterprise's biggest patching challenge?
Send your thoughts to the SearchEnterpriseLinux.com news team.