Kamis, 27 April 2006

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.

0 komentar:

Posting Komentar