Worms and viruses that exploit newly discovered vulnerabilities are appearing faster and faster, prompting IT departments to install security patches at an ever greater speed.
Although only a subset of affected software is typically installed in a given enterprise, the number of high-risk vulnerabilities requiring quick installation of patches remains high.
However, the core problem is not in the number of patches required, which can be handled more efficiently through automation, but in the need to test patches before deployment.
Some organisations continue to struggle with completely manual deployments of security patches, but many have already automated parts of the patch management process, including inventory, vulnerability scanning and patch deployment.
Prioritisation, deployment planning and testing will all remain largely manual tasks well beyond 2007. Only a small proportion of enterprises will continue to risk not installing security patches proactively.
When organisations develop a strategy for security patches, they take into account IT infrastructure capabilities as well as implied and expressed business requirements. At the heart of these requirements lies a trade-off between the risk of failed patches and the risk of attacks slipping through. Deciding that one of these risks outweighs the other is a business decision.
Prioritising patch activities must be based on several factors. If in doubt about the precise situation, security patches should be tested thoroughly and for a given context before being deployed. Automatically deploying security patches (for example, with Microsoft's Auto-Update) as soon as the supplier releases them - without testing and approval by the organisation - should be considered only in the following scenarios:
- If availability and confidentiality requirements of a system are low. The risk of a complete reinstallation of all automatically updated systems (done with software distribution tools) in case of a patch failure has to be taken into account.
- If confidentiality requirements for the information processed on a system are significantly more important than availability requirements for that system. In this instance, security patches should be installed quickly (automatically, if possible), potentially at the risk of unexpected downtime (and reinstall time) of that system if the patch fails. This is typically applicable only for a small number of systems.
- If the risk of an attack (as a function of the nature of the vulnerability and known exploits) is deemed to outweigh the risk of downtime due to a failed patch.
The proliferation of patch levels in production increases management complexity. The impact of using automatic updates on such proliferation must therefore always be taken into consideration. There are, however, some alternatives to purely patching, either automatically or after thorough testing.
Automatically triggered patching of systems that run productive, critical business applications without prior testing is not recommended. Intrusion prevention, virtual patching and hot-standby patching are possible alternatives and variations.
To address all of these options, organisations need to decide and document a patching strategy that balances criticality of application code, value of stored data, features of the operating system and capabilities of the surrounding security infrastructure.
Tom Scholtz is an analyst at Gartner specialising in security and privacy issues
At a glance
- Automatically triggered security patching remains wishful thinking
- Testing of patches requires human participation, but deployment of patches and virtual patching can be automated to some extent
- Relying on any sort of tool that automates business decisions is risky
- Looking for new ways to accelerate security patching to minimise the risks of "loss of availability" or "loss of confidentiality" is appropriate.
This was first published in September 2005