How to manage patching

At home, you can update your devices as needed, at a time that suits you. For more complex business environments with many devices (and many stakeholders), there are patch management applications available, including patch management as a service. These tools and services may not cover all software on all your devices, but should make the standard process work smoothly for many of them by: You’ll need to decide what your strategy for patching will be, and plan the patching carefully.

Create a patch strategy

1. Identify your assets. All of them: hardware and software. Find out what software (and what software versions) you are using on which devices. Remember to include firmware and operating systems, not just applications. Don’t forget to include shared libraries.
2. Run a vulnerability scan over your system to identify vulnerabilities.
3. Conduct a risk analysis of your assets. Which are the most critical to your organisation? Which are the most vulnerable?
4. Review (or create) a patching policy, including documentation requirements. If relevant, make sure it covers updates for employee-owned devices.
5. Monitor to ensure you are aware of all available patches for your systems:
   • Sign up to vendors mailing lists and notifications.
   • Ensure these are sent to a central and dedicated location, so that they are not missed (especially emergency notifications, which would not arrive on a predictable schedule).
   • Be aware of vulnerabilities identified in any third-party libraries and open-source software that you use.
   • Consider subscribing to data feeds for vulnerabilities to receive updates.
6. Set up automated updates where possible. You could also automate scripts to test that patches were applied correctly. Automation will reduce the patching workload, but must be balanced against the risk of the automatic update causing a problem.
7. Prioritise the patches available based on your risk assessment, and plan to do the most important first.
8. Plan a routine patching schedule for assets with a regular release cycle. Remember: just because it is routine doesn’t mean it isn’t important. Don’t postpone it. And don’t forget about updating mobile devices too.
9. Plan patch releases, if that’s appropriate:
   • If patching requires downtime of a production environment, it would be better to take it down once, rather than repeatedly.
   • Ensure that a bundle of patches in a release don’t interfere with each other.
   • Discuss with the business and risk owners. They need to understand the proposed changes, will know what the risks are for their area of work, and should sign-off on the patch release
   • Try to avoid multiple updates to the same piece of software at the same time, if you are running behind on your patch schedule; later updates may have dependencies on earlier updates, and so they may have to be updated in a particular order.
   • Don’t forget to review patches that were excluded from previous patch releases, to check that these exceptions are still appropriate.
10. Coordinate the patch releases with your change management process. Consider pre-approval for standard releases. Also consider what pre-approval might be appropriate for emergency patching.
11. Track patch exceptions. One delay or exception might not add much risk, but the risk may be
    substantially higher when combined with other exceptions. Previous exceptions should be reviewed regularly as part of the process.
12. Create a simple regression test pack, with scenarios for patching different elements.
13. Prepare for emergency patching, including the creation (if you don’t already have one) of an
    emergency patch process document.