Thoughts on Patching

As I continue through my list of security notes, I thought I would share a few ideas here. I recorded these while seeing Ron Gula discuss vulnerability management at RMISC.

Many people recommend automated patching, at least for desktops. In the enterprise, some people believe patches should be tested prior to rollout. This sounds like automated patching must be disabled. I'm wondering if anyoen has implemented delayed automated patching. In other words, automatic updates are enabled, but with a two or three day delay.

Those two or three days give the enterprise security group time to test the patch. If everything is ok, they let the automated patch proceed. If the patch breaks something critical, they instruct the desktops to not install the patch until further orders. I think this approach strikes a good balance since I would prefer to have automated patch installation be the default tactic, not manual installation.

Determining which systems are vulnerable results in imagining a continuum of assessment tactics.

  • At the most unobtrusive level we have a "paper review" of an inventory of systems and their reported patch levels.

  • Next comes passive assessment of traffic to and from clients and servers.

  • Traditional vulnerability scanning, without logging in to the target, is the next least obtrusive way to assess hosts.

  • Logging in to a host with credentials is another option.

  • Installing an agent on the host is a medium-impact approach.

  • Exploiting the host is the final way to definitively see if a host is vulnerable.


On a related note, Ron mentioned that the costs of demonstrating compliance far exceed those of maintaining compliance. This is sad. Ron also noted he believes auditors should work for the CFO and not the CIO. I agree.

Comments

foQ: that is cool, but I mean patching happens automatically unless someone intervenes -- not patches are downloaded and then told to be applied. I want the default to be patch application, albeit with a small window to stop automatic application if necessary.
Ryan Russell said…
Note: I work for BigFix (who sells a patch management product) and co-moderate the patchmanagement.org mailing list. So, I've thought about the topic a bit.

What you're proposing a deadman's switch, which I'm a fan of, for unmanaged (usually home) computers.

There are plenty of good reasons for not forcing patches on people, and 2-3 days is WAY too short for the majority of enterprises. Some of the biggest patches, such as XP SP2, are often held for a year. You can get away with that, since you have hotfixes to SP1 still, mitigating methods, etc..

Any decent patch management product lets you flip a switch and deploy to all clients on-command, so there's really no need for a drop-dead date. There are many admins as most companies, so it's not like it will just get forgotten. Again, this is obviously for managed computers.

Remember, we just had a MS Patch Tuesday where the patches broke many things. That sort of thing is why businesses wait and do testing.
jbmoore said…
TI has a group which tests Microsoft patches and decides whether to include them in SMS rollouts and internal Windows Update Servers. They omit certain patches if the patch breaks particular apps. I know this because a good friend is a testing administrator. TI has its own version of SP2 with some MS hotfixes omitted because of software incompatabilities with in-house applications and such. Many of their helpdesk calls are from TI employees who go to the MS Windows Update Website and patch their laptops and then wonder why their applications suddenly don't work.
Anonymous said…
Yes. But unfortunately, not in an automated way.

For quite some time, my patch strategy has been, essentially: 'Apply the patches 3-5 days after release, unless there's a big uproar in the mailinglists and blogs I subscribe to'.

Basically, I'm letting everyone else do my testing for me. Why reinvent the wheel?

Popular posts from this blog

Zeek in Action Videos

MITRE ATT&CK Tactics Are Not Tactics

New Book! The Best of TaoSecurity Blog, Volume 4