A good patch management policy

A good patch management policy is needed to protect you from risk, and to encourage the attacker to find easier/unpatched victims.  Selfish but true.

  1. Know your risk.
    Security is risk management, it’s as simple as that.
    Know your environment, and the vulnerabilities which apply.
    Determine what is more critical to patch first.
    Rule of thumb: servers should be patched first
  2. Have some sort of patch management system.
    You need to somehow to get the patches out to your computers, and that “somehow” is a deployment tools (Microsoft SMS/SCCM/WSUS, Shavlik)
    A good patch management product will also allow third-party patch rollout (ie. Adobe Flash, Adobe Reader, Firefox etc.)
  3. Deploy your patches to pilot groups first.
    There is no sense in deploying a patch everywhere, if it breaks something.  If you do that, it’s just like deploying a virus.
  4. Make sure your Pilot Group:
    * pilot group deployment list is up to date (people change their job positions, computers are replaced).
    * that your Pilot Group Testers are aware that they need to report any problems they’re found.
  5. Have a back-out process.
    If the patch does break something, you should know how to uninstall it.
  6. Use a mailing list like BugTraq
    Know what threats have been created.  And migrate against them as soon as possible.

Bookmark and Share