Tuesday, December 10, 2013

How do I patch the things good?



My team was recently asked to do an assessment of our companies patching strategy and to suggest improvements. Senior management's questions came down to, "How do we patch the things good?"



This is a great question (one I wish more managers would ask). It's not a simple one, though. If your managers start asking this question, they could well be expecting a number of days or weeks because it's simple and easy to put in a report that clients see. "We patch all of our stuff within 30 days." They may even be happy with breaking it down a little more, "We patch workstations within 30 days and servers within 3 months."

A common question I've heard is, "How fast do our vendors say we need to patch?" But no vendor will give you this ever (and if they do, don't buy from them). The second they publish a document saying, "If you apply our patches within 72 hours, you're safe" they're liable at some level if you get hacked within 72 hours. No vendor should be willing to take on that risk.

But that's the naive approach. It's better to start the conversation this way, "We'll need to do some risk analysis, it's going to take time and money, but we'll be better off for it."

Because patching isn't a specific process that can be applied to all technology. Tons of factors go into how important patching is (visibility of the technology, how important it is to your business, how much access it has to other technologies, other stuff in close physical proximity to the device, etc, etc, etc). You can't apply a generic standard and expect it to be very effective. You may actually wind up wasting more time and money patching unimportant things at the same rate as the important things.

After you've prepared your execs for the cost associated with patching, ask them to list the top three applications that go down in their nightmares and then the top three applications that go down in their less scary nightmares. This gives you a spectrum to work with and it's easier to fill in other technologies and assign risk to them.

From that starting point you can add on the severity level of the patch being released and tons of other factors. But start somewhere with a patching plan.