IND.1 Process Control and Automation Technology

An information security management system (ISMS) for the operation of OT infrastructure MUST exist either as a stand-alone ISMS or as part of an overall ISMS.

A person MUST be appointed with overall responsibility for OT information security. The details of this appointment MUST be publicised within the organisation in question.

When using anti-virus software on OT components, consideration MUST be given to whether and in which configuration the operation of anti-virus software is supported by its manufacturer. If this is not the case, the need for alternative protection methods MUST be checked.

Virus signatures MUST NOT be obtained by OT systems directly from the Internet.

Every change made to ICS components MUST be logged. In addition, all attempts to access to ICS components MUST be logged.

Programs and data MUST be backed up regularly. A backup MUST also be made after each system change made to OT components.

All the security-relevant parameters of the OT infrastructure at hand SHOULD be documented. All software and system components SHOULD be documented in an inventory list. This list SHOULD state the product and protocol versions used, as well as the respective responsibilities. For the components used, any applicable manufacturer restrictions or regulatory conditions SHOULD be defined. This documentation and a system inventory SHOULD be maintained—for example, in a control system.

In addition to this, an up-to-date network plan SHOULD document zones, zone transitions (conduits), and the communication protocols and methods used, as well as the external interfaces. For the interfaces, active network components and manual data transfer methods (e.g. using removable media) SHOULD be taken into account. Automation solutions SHOULD be structured into cells and communication channels to enable the zones and conduits at hand to protect the OT infrastructure.

OT infrastructure SHOULD also be segmented horizontally into independent functional areas such as facilities. The individual zones SHOULD be as independent of one another as possible during operations. In particular, the zones where the respective technical process is controlled SHOULD continue to function for a certain period of time if the other zones fail. Decoupling SHOULD also continue to function after an attack. This period SHOULD be suitably defined and documented. The network SHOULD be designed to be resistant to errors and manipulation.

A suitable change process SHOULD be defined, documented, and used actively when making changes to OT.

An organisation SHOULD establish a process for managing user access and assigned authorisations for OT. A corresponding authorisation management system SHOULD cover this process, along with the implementation and documentation of activities involved in applying for, configuring, and withdrawing authorisations.

The authorisation management system SHOULD ensure that authorisations are granted according to the minimum principle and checked at regular intervals. In the authorisation management system, access to IT systems SHOULD be regulated for employees, administrators, and third parties. Everyone involved SHOULD be made aware of the rules to be followed at regular intervals. Compliance SHOULD be checked. Misconduct SHOULD be sanctioned.

For the initial configuration, administration, and remote maintenance of OT, either secure protocols or separate administration networks with corresponding protection needs SHOULD be used. Access to these interfaces SHOULD be restricted to the persons authorised. The access granted to systems and functions SHOULD be limited to the requirements for the respective administration tasks.

The systems and communication channels used to carry out administration or remote maintenance SHOULD have the same level of protection as the OT components administered.

Rules for handling removable media and mobile devices SHOULD be established and communicated. The use of removable media and mobile devices in ICS environments SHOULD be restricted. For the media and devices of service providers, an approval process and a requirements list SHOULD be available. Each service provider SHOULD be familiar with the specifications and confirm them in writing.

On OT components, all interfaces that are not required SHOULD be disabled. The usage of active interfaces SHOULD be restricted to certain devices or media.

Operational and security-relevant events SHOULD be identified promptly. For this purpose, a suitable approach to log and event management SHOULD be developed and implemented. Log and event management SHOULD include adequate measures to detect and record security-relevant events. It SHOULD also include a security incident response plan.

The response plan SHOULD define procedures for handling security incidents. This plan SHOULD cover the classification of events, reporting channels and the definition of the organisational units to be involved, response plans to limit damage, the analysis and restoration of systems and services, and the documentation of and follow-up process for incidents.

If OT systems are to be procured, planned, or developed, information security regulations SHOULD be established in this regard. The documents SHOULD be part of any related tender.

During procurement, planning, or development, information security SHOULD be taken into consideration through the entire lifecycle. Prerequisites and implementation instructions for the secure operation of ICS components by manufacturers SHOULD be planned and implemented at an early stage. Uniform requirements for information security that correspond to the protection needs at hand SHOULD be defined for ICS components. These SHOULD be taken into consideration when procuring new ICS components. Compliance and implementation SHOULD be documented.

The organisation in question SHOULD document how the system fits into its concepts for zoning, authorisation, and vulnerability management (as well as for virus protection) and adapt them if necessary. A plan for maintaining operations should a given partner stop providing its services SHOULD be formulated.

To ensure the secure operation of its OT environment, an organisation SHOULD establish a vulnerability management approach. Vulnerability management SHOULD identify gaps in software, components, protocols, and external interfaces in the environment under consideration. It SHOULD also make it possible to derive, assess, and implement necessary actions.

This SHOULD be based on reports on vulnerabilities from manufacturers and publicly available CERT messages. In addition, organisational and technical audits SHOULD be performed for vulnerability analysis.

Advanced system documentation SHOULD be drawn up. It SHOULD record particularities in operations and options for system administration. In addition, any changes made to ICS components SHOULD be documented.

The systems with which an ICS component exchanges data and the data exchanged in this regard SHOULD be documented. Furthermore, the communication links of newly integrated ICS components SHOULD be documented.

Log data of ICS components SHOULD be stored centrally. In case of security-critical events, alarms SHOULD be raised automatically.

Sensitive data SHOULD be erased prior to the disposal of old or defective ICS components. In particular, it SHOULD be ensured that all access data has been permanently removed.

Business continuity plans SHOULD be defined, documented, tested after each major change, and drilled regularly for each zone to address the possibility of it failing or becoming compromised.

An effective substitute procedure SHOULD also be defined, documented, and tested in case the option of (remote) administration fails.

A central directory service SHOULD be set up for the secure authorisation of privileged users in the control systems at hand (see module ORP.4 Identity and Access Management). Authentication SHOULD be secured further using several factors, such as knowledge, ownership, or biometrics.

During planning, it SHOULD be ensured that any resulting dependencies in user authentication are known and taken into consideration when implementing a corresponding solution.

It SHOULD be ensured that operationally required technical accounts can be authorised in emergencies.

Organisations SHOULD maintain an inventory of all the access rights that have been granted for critical systems. This inventory SHOULD list the rights a particular user effectively has and who has what rights on a particular system.

All critical administrative activities SHOULD be logged. The IT Operation Department SHOULD NOT be able to delete or manipulate the logs.

Interface systems with security checking functions SHOULD be used as a preventive measure in ICS environments that are highly sensitive or are difficult to secure.

Continuous external connections SHOULD be terminated by implementing one or more connection zones (DMZ) in a P-A-P structure. Required security checks SHOULD be carried out in such a way that the respective ICS system does not have to be adapted.

The security configurations of OT components SHOULD be checked regularly and as needed in the case of sudden threats which were previously unknown. This security vetting SHOULD at least cover exposed systems that involve external interfaces or user interaction. The implemented security concept SHOULD also be checked at regular intervals. Security vetting SHOULD be carried out as a configuration review, or also through automated conformity evaluations.

Alternative and independent communication options SHOULD be established and operated.