|
I sympathize with you when it comes to trying to manage a continuous flow of patches, and it does seem that there have been a lot of Adobe patches of late. It can be a time-consuming and resource-hungry task, making it cost-prohibitive to test all of the fixes.
But remember, patches are not mandatory. The threat posed by a particular vulnerability may be within your risk tolerance while some patches won't be relevant to your environment, so there is no need to test and install them.
To effectively and efficiently mange your patch process, I would first sign up for the free Adobe security notification service so that you receive email notification of any security advisories affecting Adobe products. I would also pay regular visits to Secunia, a website that serves as a vulnerability clearinghouse, and its Adobe Systems Vendor Overview page. From there you can choose any Adobe product and view a full report of all Secunia advisories affecting it. The report makes it easy to learn about all vulnerabilities, both patched and unpatched, affecting the product.
Determining vulnerability criticality is essential for calculating a patch's significance, as is the existence of a known exploit that uses the flaw being patched as an attack vector. What I particularly like about Secunia's vulnerability reports is that they clearly show the severity of the vulnerability, something Adobe's Web Security Bulletins don't. (Depending on the size of your organization, you may want to consider trying the Secunia Enterprise Vulnerability Manager or Secunia Vulnerability Intelligence Feed services, which filter advisories for your specific needs and provide a targeted set of alerts.)
If you have a system inventory that prioritizes all of your machines, you'll have the information you need to assess whether the issue a patch addresses is a threat to your current environment. Once you have decided a patch needs to be deployed, you should prioritize it as either a normal or emergency change. You can then leave less urgent patches to be tested and deployed when time is available.
Testing is required because patches disrupt existing software. They also often change services or functions on which your system relies. Every problem you find during testing is one less problem that you will hear about from each of your users. I would certainly frequent the relevant Internet discussion news groups to find out others' experiences with a particular patch. Unfortunately, when it comes to the actual testing process, there aren't any shortcuts. You cannot batch-test patches because if testing produces an unsatisfactory result, you must identify the root cause of the problem before going any further. This will be tricky if several patches are being installed at once.
By completing a patch test, you can ensure a predictable rollout when it is deployed. The initial rollout should be to less critical systems. If they perform as expected, continue with the rollout until all systems are updated. This approach adds a further safeguard to the whole process. Finally, ensure you document your decisions to install or reject specific patches so you can provide assurance to your auditors that vulnerabilities have been identified and appropriate patches have been installed.
|
