To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
There's no reason why patching your database should cause it to crash or break other applications as long as you follow secure lifecycle management best practices. Patching your database is no different than patching the operating system it runs on; it needs to be carried out as a documented process to ensure tasks are executed in an orderly and predictable manner and that none are forgotten or left uncompleted.
First, you need to understand the patch process operated by your database vendor. Oracle Corp., for example, releases Critical Patch Updates on a quarterly basis; Microsoft provides security updates on the second Tuesday of each month. But 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 every possible patch. Vulnerability criticality is key for calculating a patch's significance, as is the existence of a known exploit that uses the vulnerability being patched as an attack vector. You may want to consider trying the Secunia Enterprise Vulnerability Manager or Secunia Vulnerability Intelligence Feed products, as their vulnerability reports clearly show the criticality of individual flaws, not something all vendors' alerts do.
In every database patch management process, it's important to have a system inventory that prioritizes all your machines so you have the necessary information readily available in order to assess whether the issue a patch addresses is a threat to your current environment. Once you have decided that 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 a critical aspect of patch deployment, particularly for a database, as patches can change services or functions on which other applications rely. Unfortunately, when it comes to the actual testing process, there aren't really any shortcuts. You cannot batch-test patches. If testing produces an unsatisfactory result, you must identify the root cause of the problem before going any further. This is much harder if you have installed several patches at once. A useful source of help and guidance is the relevant Internet discussion news groups, where you'll find out others' experiences with a particular patch.
By completing a patch test, you can ensure a predictable rollout when it is deployed. Every problem you find during testing is one less problem that you will have to correct in your production environment. Where possible, your initial rollout should be to less critical systems, and if they perform as expected, you can continue with the rollout until all systems are updated. This approach adds a further safeguard to the whole process. Finally, ensure that you document your decisions to install or reject specific patches so that you can provide assurance to your auditors that vulnerabilities have been identified and appropriate patches have been installed.
Although most large vendors have introduced scheduled patch releases to help improve the manageability and predictability of the database patch management process, patch testing requires time and resources. If possible, consider using virtualization, as it offers the ability to deploy multiple test configurations to mirror live production environments. Your testing will then better replicate the actual environment in which the patch will be deployed.
|
