Plant management 

Making (physical) on-site access controllable

In addition to the remote access, the "physical access" on site must also be controlled and restricted if necessary. To prevent damage due to unauthorized access:

  • Make sure that only authorized access is possible.
  • Protect the interfaces by mounting the devices in a control cabinet.
  • Secure the control cabinet with a lock.
  • Ensure that the control cabinet key is only accessible to authorized persons.
  • Run cables in such a way that they are not accessible for unauthorized persons.

Security patch management

Following the release process, usually patches are provided. Features and functionality patches increase or enhance the product's range of functions or improve the plant operation or reliability. Besides these well-known feature/functionality patches, security patches are important.

Security patches fix known vulnerabilities in a system/an ICS. These vulnerabilities relate to software and hardware likewise. Often, they result from improperly programmed software or device firmware, or from an improper configuration/parameterization of integrated system components. Consequently, the elimination of these vulnerabilities is the responsibility of the manufacturer or the system integrator, respectively.

Security patches are an important element when it comes to maintaining the operational capability of a plant.

Therefore, a suitable security patch management process must be established and reviewed, accompanied by a notification/announcement mechanism, that informs, for example, the plant users about vulnerability as soon it has been detected.

The patch/update management process should be defined as follows:

  • Regularly evaluate vulnerability reports for both your own software and third-party tools.
  • Perform data backups for the affected components prior to installing a patch.
  • Only distribute patches which have been tested and released by the manufacturer.
  • Install patches and updates in your plant sequentially (component by component), if possible, and consider the consequences of possible system failures after installing a patch when planning the sequence.
  • Define a fixed patch interval in particular for security-critical systems. It is recommended to contractually define time periods for releases with third party software vendors,
  • If possible, adjust patch management to match the plant's production cycles.
  • Define clear responsibilities with regard to patching software (own as well as third-party).
  • Determine the criticality of patches and consider it in your schedule. If, for example, a patch is non-critical but its installation results in a system reboot (e.g., with a following downtime), it may be postponed.
  • If the installation of a patch is not possible due to any circumstances, suitable alternative measures should be taken for the affected component, for example:
    • (Temporary) separation of the affected component into a separate zone/network segment.
    • (Temporary) filtering the data traffic to/from this component using a specifically configured firewall. 
Note: If the support for a component or its software has been discontinued (end of life cycle), a new thread risk assessment is required for the entire system to evaluate the changed threat situation.

 

 

 


• Published/reviewed: 2024-12-16 • Revision 016 •