EXPERT RESPONSE
I sympathize with organizations -- large and small -- when it comes to patch management. It can be a time-consuming and resource-hungry task. The sheer number of Microsoft patches alone makes it cost-prohibitive to test all of them prior to implementation. Let's look at how a smaller organization can streamline the process.
Firstly, consider the patch management process. It starts with scanning systems for missing security patches. Thankfully, the task is now mainly an automated one. Next comes assessing whether the issue that a particular patch addresses is actually a threat to your current environment. Making that kind of decision is a lot easier if you have a system inventory that prioritizes all of your machines. Developing a business profile for each application will help enormously in assessing system importance, allowable downtime periods and vulnerability risk levels. Profiles should list expectations from the IT infrastructure, as well as end users. Such requirements can help to prioritize your efforts. Vendor-reported criticism is another key input for calculating a patch's significance. It's important to be aware of known exploits that use a given vulnerability as an attack vector.
But do remember that patches are not mandatory. The threat posed by a particular flaw may be within your risk tolerance, while some patches won't be relevant to your system and won't need to be tested or installed.
Once you have decided that a patch needs to be deployed, it should be prioritized as either a normal or emergency change. Emergency patches should be implemented immediately, while less urgent patches can be tested and deployed when time is available. Unfortunately, when it comes to the actual testing process, there aren't really any shortcuts. Testing is required because patches can overwrite working drivers, disrupt existing software and change services or functions on which your system relies.
Larger organizations can use a virtualized IT infrastructure to provide test environments, cutting ownership costs and implementation time. Test computers are another luxury, but they may be unavailable to administrators of smaller networks. If you don't have that privilege, you should at least test each patch on your own PC. Every problem you see on your own system is one less problem that you will hear about from each of your users. Be sure to have a rollback and restore plan in place though! It is also important to frequent the relevant Internet discussion news groups to find out others' experiences with a particular patch.
By completing a patch test, you can ensure a predictable rollout when it is deployed. Unfortunately, you cannot batch-test patches; if testing produces an unsatisfactory result, you must identify the exact cause of the problem before going any further. If you have installed several patches at once, finding the root of the issue will be tricky. Production rollouts can be used as an additional part of the testing process, though, if they are done in stages. The initial rollout should be to less critical systems, and if the patches perform as expected, continue with the rollout until all systems are updated.
Finally, document your decisions to install or reject specific patches so that you can provide assurance that vulnerabilities have been identified and appropriate patches have been installed. Your security policy should define your organization's stance on patch prioritization, testing and deployment.
More information:
Michael Cobb explains how to install the most current Microsoft patches and critical updates in one go.
So you push critical Windows patches once a month. But what about Acrobat Reader, QuickTime and your other third-party applications?
|
