6.6.1 The relevant entities shall specify and apply procedures, coherent with the change 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.

1. Panoramica

1.1 Riferimenti

1.2 Requisiti identificati

1.3 Regolamentazioni correlate

2. Requisiti identificati

3. Regolamentazioni correlate

Ticket collegati

• ENISA -