The patching landscape: not a pretty picture.
The landscape of patching is messy.  We see 20 to 30 patches a month for Microsoft.  Those are predictable because they do come out on Patch Tuesday. There are a whole slew of other patches that come out in a month for Java, Adobe, Mozilla, etc. – the list goes on and on.  There are also many dependencies with 3rd party application patches.  For example, Flash is embedded in Adobe Reader, Chrome, and now in IE 10 later this year.  When there is a flaw in Flash, this causes these vendors to also issue patches, so we see a spiral of patch updates.


3rd party application patches are more difficult, because they are not predictable, so the workload of the sysadmin dealing with these patches is not predictable.  Almost always, these 3rd party patches are related to a security issue; bug fixes and feature enhancements are rolled out as planned releases.


Microsoft, on the other hand, does provide a fair amount of non-security related bug fixes.  About 1/3 of Microsoft patches are related to bug fixes – critical flaws in the product that cause performance issues or configuration settings (day light savings settings for example).


When should security patches be installed?
As soon as possible, but the sysadmin needs to take into consideration business need and risk of not updating the patch.


Internet facing patches need to be the top priority – a browser, Flash, Java, etc.  Why?  The whole world knows there is a security vulnerability and there are plenty of folks out there ready to exploit those vulnerabilities.  The longer you delay getting the patch deployed, the greater risk on your infrastructure.


Servers, especially web servers, mail servers – are an attack target.  Do these immediately.  Desktops/notebooks are less of a direct target.  However, the end user might do something naively or innocently.  Classic example – identity theft, email phishing skemes.


When should bug fixes be installed?
It depends.  If a bug fix comes out and if you are if you are not experiencing that bug or using that feature of the software, don’t install the patch.  Don’t increase the risk of instability into your system by installing unessary software.


Classic example - a year ago, a fix came out for Remote Desktop.  90% of users were not using.  Do you install across your entire environment?  The better approach is to check to see who is using this component, and apply the patch to those machines.