6.6.2 By way of derogation from point 6.6.1.(a), the relevant entities may choose not to apply security …

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.

1. Forbhreathnú

1.1 Tagairtí

1.2 Ceanglais aitheanta

1.3 Rialacháin ghaolmhara

2. Ceanglais aitheanta

3. Rialacháin ghaolmhara

Saincheisteanna nasctha

• ENISA -