Breadcrumbs

Patching

Keeping your software up-to-date is one of the most simple and effective steps to take, to ensure your environment stays secure.

Summary

A common tactic for attackers is to exploit known vulnerabilities in software that an organisation has not yet updated. Vulnerabilities in software code are discovered more and more often. Over 18,000 vulnerabilities were recorded in the United States National Vulnerabilities Database in 2017. Software owners often release patches that intend to reduce or remove the vulnerability. Applying these patches in a timely manner remains the number one critical control for organisations to keep their IT systems secure, and to protect themselves from being breached.

Modern IT environments are complex, with interconnected components and software. Attackers take advantage of the interconnectedness to join multiple vulnerabilities together to get into business systems. To combat this, patching becomes critical to reduce the number of issues and vulnerabilities that could be used against you. Even hardware devices that connect to your network such as internet-of-things (IoT) devices, printers and DVRs run software that require patching.

Purpose

The intent of this control is to ensure your organisation keeps all software within your environment up-to-date, and understands the risk associated with delaying or cancelling patches and updates.

Measuring success

A successful patching control looks different for different types of organisations. They all should have the same end goal and outcomes. The goals for your organisation are:

  • to have a complete view of the software in your environment. Each day, you know what new software is added and what the current patch levels are.
  • all of your systems kept up-to-date with the latest patches.
  • to have a comprehensive patch management strategy that covers all software on your systems. It covers identification, prioritisation, scheduling, testing, and handling.
  • have a mostly automated patch process which includes automation of the notification, identification, download, verification, packaging, backup, testing, and deployment of patches. Actions that require assessing risk or making judgement calls remain manual.
  • all delayed or cancelled patches are re-evaluated with each patch cycle to assess the risk of not patching vs risk of patching.
  • there is supporting documentation and information available to your organisation’s staff to inform them of the strategy and importance of patching.
  • the organisation understands the risk associated with the environment’s current patch levels and works to mitigate the risk.

Key patching takeaways

  • Every IT environment is different and unique. There is no one-size fits all when it comes to patching. This is why it is critical to first understand what you have in your environment, and how your organisation operates before you can decide how you deploy your patches.
  • Perform regular checks of your IT environment to see what software versions you have. The scan may find software that was missed from previous patching. This could be because some systems were skipped or missed during a change window, or automated patching is not working as intended.
  • A common reason for not patching is that there is not enough time or resources. Automating the patching and testing process can help reduce the workload, and increase your security.
  • Another reason for not patching is to avoid disruption to service. When designing and building systems, design them to be more maintainable, which is both good business practice, and good security practice.
  • When components in your environment reach their end-of-life, where the vendor will no longer support it, patches may no longer be released. You will need to consider how you will look after these legacy components and systems.

Advice for practitioners

Implementation advice

Creating a standard process for patching