Are you one of those administrators who take pride in rolling out every software patch as soon as it comes down the pike? Or do you go to the opposite extreme, not trusting any vendor not to blow up your systems with a patch that does more harm than good?
Without some sort of ROI analysis to prioritize your patches, you’re needlessly exposing yourself to the risks of costly security breaches, not to mention day to day expenses like debugging crashed systems and cumbersome validation checks and compliance reports.
Let me explain.
ROI of Patching
Deploying a patch is like conducting any other business function. There is a cost, a benefit, and a risk involved.
• The cost is the effort involved in researching, testing, deploying, and validating the patch.
• The benefit is either increased functionality or reduced security risk (or both.)
• If you deploy unnecessary patches, the risks include overspending on deployment and troubleshooting, and reduced productivity if a bad patch causes system outages.
• If you skip needed patches, you risk security breaches and possible system outages.
Every admin intuitively understands these tradeoffs. But too few do the same kind of “return on investment” analysis on patching as a business does with any other activity. Some always update on Patch Tuesday, trusting anything that comes from Redmond. (Maybe not such a good idea.) Or they take pride in ignoring any but the most critical patches, so as not to rock the boat when their users are happy.
Both groups are skating on thin ice and will inevitably fall through, either when an unneeded patch interrupts application stability or a hacker breaks in through an unpatched system.
Prioritize Patching Activities to Maximize ROI
A better approach – using the discipline businesses use to prioritize all their other activities – is to decide which patches should be applied immediately, which can be deferred pending further investigation, and which are not worth even considering.
This prioritization must take into account how critical each system is to the business; the damage a successful attack on it would cause; the quality of the patches available for it and the effort involved in researching, testing, deploying and validating the patch.
You should have a good feel for each of those four pieces of information, with the help of outside organizations that test patches such as SolarWinds and those companies who share their experiences on PatchManagement.org, when it comes to assessing the quality of patches. You don’t, of course, want to fall into “analysis paralysis” when it comes to this ROI, and you don’t have to. The important point is to start applying some sort of ROI analysis to your patching, and improve on it over time.
Invest the time now to reap the benefits later
I can already hear you complaining that you’re already spending too much time on patching, and the last thing you have time for is this ROI analysis stuff. This reminds me of the old joke about the car owner who doesn’t want to spend money on an oil change, to which his mechanic says “Well, you can pay me now or you can pay me later.”
You can invest a little bit of time up-front to prioritize your patches and minimize your long-term cost and risk. Or, you can take an “all or nothing” approach that guarantees more time and anguish later in wasted deployment and validation, or (even worse) figuring out which mis-patched systems blew up or let in a hacker. It’s your choice.