Best practices for patch management
Vandana Sharma
05.17.2004
Rating: -4.25- (out of 5)
|
The major focus for all patching is security. Some might say it's the only focus. But a good patch management solution should cover more than just the operating system since security threats affect applications too. At the recent TechMentor conference in New Orleans, IT Manager Richard McBride of Moneris Solutions offered seven of his best practices to help you plan your patch management strategy. Moneris is Canada's largest processor of debit and credit card transactions.
- There is always risk! No matter what strategy you follow for patch management, there is always the possibility that your patch will break something. Remember: the risk of disaster from not applying patches is much greater than the risk of a patch destroying functionality.
- Close unnecessary ports, stop unused services and ensure passwords are secure. This includes things like controlling physical network access and managing mobile users. The bottom line: Don't have open ports if you're not using them. Microsoft has a website dedicated to ensuring you get the most security current information at: www.microsoft.com/security.
- Manage your environment and users. The goal is to minimize the "surprise factor." That means making sure that all changes are planned and tested before deployment and all configurations conform to a known baseline or standard. One key way to make sure you're on top of things is to manage the user experience. Reporting for patch management purposes include finding out what patches are deployed, which ones are missing and how patches are affecting the experience. Obviously, testing is critical too. As we all know, there are many cases when a patch caused more harm than good.
- Is it agent or agent-less distribution? When patching laptops for mobile users and users who connect via VPN, you should look at solutions that offer multiple distribution methods. There are two key issues to remember when looking at patch management deployment: agent or agent-less. An agent is when the patch management solution has a client side component. Any solution for this requires a deployment for the agent as well as the patches. The agent must be running in order for it to connect to the distribution server. Agent-less is when a server scans a network client by reading its registry remotely. This means you have to have a remote registry reading tool or some other method to administer the machine remotely.
- What's up with reboots? Another concern with any patch deployment methodology is what to do about reboots. You don't want reboots happening in an uncontrolled fashion. Your distribution methods should allow for manual or automated reboots. Unplanned reboots may result in lost or interrupted work. If you control your reboots, you minimize the work for your patches.
- Develop a rollback strategy. It's a given that patching could introduce other problems, including ...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
the potential to break functional systems. You should also be aware of the fact that your patch solution may not reach all the systems in your network. If it doesn't, you should figure out a way to control network access. When you do roll out a patch, have a strategy to roll it back if there are flaws or unexpected consequences. Then, review and test before deployment.
- Be aware of hidden costs. Sometimes you may need additional hardware or a dedicated server. There may also be costs associated with using a patch management solution across multiple networks or sites. And sometimes administration takes time, and time is money. A solution that is simpler to administer is less expensive, but that may mean giving up some functionality. Regarding bandwidth, it's cheap now, but that doesn't mean it will be forever. If you manage multiple sites across a WAN, consider distributing your patch management solution, allowing different sites to upload patches from local servers instead of across the WAN.
|
|
|
|
|
|
