Patching

Intent of this Standard

Organisations must strive to protect information assets from attacks that may result in information being stolen or compromised. The primary purpose of patching to is to remediate security vulnerabilities in operating systems, applications, and other digitally connected environments.

By implementing this Standard, organisations will be able to better understand their attack surface and manage and prioritise their patching requirements. This will reduce the likelihood of vulnerabilities being exploited either internally or externally to the organisation. In particular:

• Reducing the opportunity for known vulnerabilities to be exploited by adversaries and gaining a foothold into a system.
• Reducing the opportunity for launching from that foothold to move laterally around your computer systems
• Maintaining an accurate inventory of all systems and applications, so you can swiftly deploy any patches or alternative mitigations that may be required.
• Reducing the likelihood of legacy vulnerabilities being the cause of compromises.

Addressing these key risks will assist organisations to protect data and ensure system and data availability, enabling operational activities to continue unimpeded.

The guidance provided in this Standard is intended to allow organisations to embed patching as part of their IT and business service delivery processes. This includes mechanisms to monitor sources for vulnerabilities, a process to oversee patching (including adequate separation of duties between individuals throughout the distribution process), and to regularly report on compliance levels so they meet acceptable risk standards defined by the organisation.

Minimum capability maturity level

We have established criteria within a maturity model to provide clarity, including the expected minimum implementation level, which is CS-CMM 2.

Cyber Security Capability Maturity Model

The requirements are intended to meet and comply with each respective level of maturity. The levels provide a pathway that can be used by agencies to assess themselves against, with a view to improving maturity over time.

Each maturity level builds on the requirement from the preceding level.

Below are the requirements for each capability maturity level for this Standard.

Focus areas

Focus areas are applicable to the Standard and are provided as a guide and not an exhaustive list. Each agency is best placed to identify areas of relevance.

The focus areas for this Standard are:

• Cloud services.
• System and software support.
• Vulnerability scanning and identification.
• Third-party vendors who are responsible for an organisation’s patching.
• Any other system required to conduct core business.
• Any other system required to connect with any other organisation (foreign or domestic) and/or the New Zealand public.

Suggested actions

The following list is not exhaustive. Organisations should identify which actions are appropriate to implement the Standard based on their current maturity level. However, the following actions follow good practice guidelines:

• Development of a patch management policy that includes responsibilities, patch severity thresholds, and alternate mitigation processes in the event a vulnerability goes unpatched.
• Development and maintenance of a current asset inventory.
• Patch detection mechanisms are in place to regularly identify relevant patches.
• Application of all critical-rated security patches within two days (whether working days or not) of the release of the patch or update on external-facing systems, or where working exploits exist, and within two weeks on internal systems.
• Patch versions are registered and linked to the asset registry to provide oversight.
• Patches and upgrades come from reliable sources only.
• Planning for funding of upgrades and retirement of systems and software that no longer has vendor support for patching, well prior to the end of support date.

Key dependencies

To implement this Standard, there are likely to be requisite measures or technologies in place.

A number of dependencies apply to multiple standards. In general, these dependencies are less technology-specific and relate to business processes.

Key dependencies for this Standard include:

• A risk management strategy and defined acceptable risk level exists.
• An asset inventory exists and is kept up to date.
• Capability exists that enables. identification of relevant patches.
• A patch evaluation or testing process exists.
• Rollback capacity/capabilities (if required).
• Regime to monitor patch compliance monitoring exists.
• Contract SLAs include patching requirements.

Measurable outcomes

To establish whether the Standard is being implemented, the outcomes are a tool an organisation may wish (or already have in place) to measure to help make this determination.

The outcomes have been designed to align with the requirements contained in the maturity level.

Outcomes for this Standard include:

• Organisations have a current asset inventory (for example, hardware/software, licences, and versions numbers).
• Existence of—and investment in—patch management software, services, or other tools.
• Employees have mandated responsibility for patching as part of their job duties.
• Organisations have a patch management policy, including requirements for patch severity, risk levels, and patching timeliness as required by the NZISM.
• Organisations have a test environment or pilot users to trial patches on.
• Organisations show an ongoing programme of work where end-of-support systems are identified, tracked, upgraded, retired, or replaced well before the operational and security lifecycle ends (and extended support offerings are only used while the replacement of these systems is taking place).
• Change-control process is in place to review, test, and approve patches being installed into production.