6.6 Security patch management

Requirement

The relevant entities shall specify and apply procedures, coherent with the change management procedures referred to in point 6.4.1. as well as with vulnerability management, risk management and other relevant management procedures, for ensuring that: (a) security patches are applied within a reasonable time after they become available; (b) security patches are tested before being applied in production systems; (c) security patches come from trusted sources and are checked for integrity; (d) additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2.

Guidance

• Take into account well known standards when developing the security patch management procedures (58).
• Actions may vary, depending on the network and information system (e.g. mandatory patching for all exposed systems or internet-connected devices such as firewalls or routers, and limited patching only in specific circumstances, for instance in isolated or legacy systems where regular patching may not be feasible or available).
• Establish a process, in combination with the asset inventory, for being informed when a new security patch is published and schedule patch roll-outs accordingly.
• Patching should be a standard activity in normal maintenance and outage planning of services. Nonetheless, some failures may require immediate patching depending on their criticality.
• Prioritise and apply patches based on risk. Evaluate the severity of the vulnerability, exposure of the affected system and likelihood of exploitation.
• Deploy vulnerability management technologies to identify unpatched and misconfigured software.
• Define your relevant security information sources considering your assets and continuously monitor them for patch announcements, patch and non-patch remediation, and general threats.
• Verify the patch sources through (indicative, non-exhaustive list):
  • digital certificates to verify the vendor;
  • digital signatures of the patches
  • change logs provided by the vendor; and
  • feedback from the community concerning the reliability of the vendor.
• Consider a strategy for applying patches after approval or testing following the change management procedure (indicative, non exhaustive list):
  • Blue/green allows the patches to be applied first in an isolated environment identical to the production environment, and then in the production environment. This ensures zero downtime and an immediate rollback option.
  • Rolling (59) deployment allows gradual updates of parts of the production environment, one set of servers or instances at a time, rather than deploying a patch all at once. It is ideal for large and distributed environments.
  • Feature toggles allow new features or patches to be deployed to production but keep them disabled until they are ready to be used. They are suitable for control over new features or patches when they are turned on, making it easy to test and release.
  • Shadow deployment allows new code or patches to be deployed directly to production but it shadows live traffic by mirroring user requests to both the current and new systems to observe how the new version behaves without affecting the user experience. It is ideal for testing new features in production without affecting users.
  • Hotfix deployments are used for critical patches that need to be applied immediately to address severe issues.
  • Where appropriate and to reduce risks related to significant updates in important dependencies, consider performing a trial using release candidates (60) of these components, to get an early indication of incompatibilities or breaking changes, so they may be remedied. If any of these components are open source software, offer feedback about any issues found during this trial.

Examples of evidence

• Detailed procedures and guidelines for how patches are identified, evaluated, tested, deployed and verified.
• Logs or records showing the history of patch deployments across various systems. These may include (indicative, non-exhaustive list):
  • timestamps;
  • responsible personnel; and
  • affected systems.
• Evidence that the asset inventory (Annex to the regulation, point 12.4) is updated after a new security patch is announced, if possible accompanied by the time plan for applying it.
• Evidence of testing patches before deployment in a controlled environment. This should include results of testing and any issues encountered and resolved.
• Documentation of test plans and results for patches before deployment to production environments.
• Documentation of change requests for deploying patches, including approvals and impact assessments.
• Detailed audit trails showing the steps taken from patch identification to deployment.
• Checks for the latest patches.
• Approved documented actions for applying patches.
• Records of changes logged, reviewed and approved.
• Evidence of vendor verification mechanisms for example digital certificates and digital signatures.
• Reports from internal and external audits evaluating the effectiveness of the patch management processes.

Requirement

By way of derogation from point 6.6.1.(a), the relevant entities may choose not to apply security patches when the disadvantages of applying the security patches outweigh the cybersecurity benefits. The relevant entities shall duly document and substantiate the reasons for any such decision.

Guidance

• Make an effort, proportionate to the entity’s size and importance, to ensure that security patches do not introduce additional vulnerabilities or instabilities. Examples of information supporting such a decision may include (indicative, non-exhaustive list):
  • vendor documentation on the patch:
    • what specific vulnerabilities or bugs are addressed,
    • whether the patch fixes a security issue, improves performance, adds features or resolves stability concerns,
    • system requirements or any specific configurations required or changes to system settings,
    • installation instructions on How to apply the patch and whether it requires a restart or additional configuration;
  • severity rating - patches that address critical vulnerabilities are more likely to apply; and
  • security blogs, forums and mailing lists for any known issues or incompatibilities introduced by the patch.
• If patching is not feasible, consider alternative measures such as strict configuration hardening, intrusion detection systems, regular vulnerability scanning, network segmentation or isolation where feasible, access control and monitoring.

Examples of evidence

• Evidence of patch prioritisation for example emphasis is placed on patches assessed as critical.
• Evidence that residual risks resulting from non-patching are listed and mitigated.
• Incident reports related to unpatched vulnerabilities to check the effectiveness of the mitigation measures during the entity’s response.
• Logs of changes made to systems, including patches applied, rollback procedures and any issues encountered.
• Documented decisions no to patch accompanied by relevant alternative measures.
• Up-to-date risk-treatment plan.

Tips: guidance

• Patch management procedures should indicate scope, roles and responsibilities.
• Perform operating system and application updates on enterprise assets through automated patch management.
• Use appropriate patch management tools to fulfil the elements referred to in point 6.6.1 of the Annex to the regulation.
• Since patches can sometimes cause issues, it is recommended to back up the system before applying them.
• Have a rollback plan to ensure that the system reverts to a safe previous state if patching does not work or fixing the problem is not feasible.
• Remove unsupported hardware and software from the network in a reasonable and accepted time in line with the entity’s risk assessment.
• Include patch and update requirements in the supply chain policy (Annex to the regulation, point 5.1) and in the contracts, bid evaluation and selection criteria for new ICT services, systems or products (section 6.1), considering the system life span among other aspects.

Tips: examples of evidence

• Documentation of regular meetings where patch management processes are reviewed. This should include agendas, attendance records, actions taken to improve the process and minutes from the meetings.
• Checks of the latest patches for evidence of who performed each step and when and for documentation outlining the roles and responsibilities of staff involved in the patch management process.
• Patch management tools.
• Configuration and logs from these tools demonstrating regular use.
• Rollback plan.
• Contract, bid and documented evaluation and selection criteria for new systems which consider the patch management requirements and the system life span.