Only the combination of functional safety and cybersecurity ensures the overall safety of industrial plants. Stefan Ditting and Thomas Janzer report
Productivity has the highest priority for companies. It is generally acknowledged that functional safety protects systems and thus helps maintain this productivity. Autonomous safety controllers also help to significantly reduce security risks and thus significantly reduce lifecycle costs. Properly setting up the safe controller is the last line of defence against cyber attacks.
As cyber attacks on plants via networks increase, it becomes essential for functional safety and safety-related automation solutions to support cybersecurity.
The trend of linking office IT with automation IT in an open network architecture only increases the security risks to plant automation.
There is good news. SIL 3 controllers designed especially for functional safety include features that are also quite helpful for cybersecurity protection.
The basic requirements that current and future security standards impose on the integration of safety controllers, and how autonomous safety systems—such as HIMax from Paul Hildebrandt GmbH—can help reduce the security risk in plants, are presented below. The robustness and reliability of autonomous safety systems simultaneously increase the availability and productivity of plants.
Functional safety is the basis for any type of process plant, since without mastery of the functional safety risks, operation of the plant is not allowed.
In addition to safety, productivity is a crucial factor for the enterprise. To ensure productivity a safety system must be integrated in the plant process control system. However, such integration increases the risk that safety products will be negatively influenced via interfaces and networks. An attack on the integrity of the safety controller also jeopardises the integrity of functional safety. Consequently, the same demanding requirements imposed on functional safety features must also be imposed on the security features of a safety controller.
Integrated solution
At first glance, economic reasons can be a persuasive factor for implementing an integrated safety system from the same company that manufactured the process control system. After all, a uniform system concept and a common bus, as well as a single engineering tool for the standard automation and functionally safe automation, promise several advantages. The advantages of convenience, however, come with disadvantages in the areas of functional safety and security, as anything that a user or the controller can do, an attacker can also do. A larger attack surface is the consequence.
With an integrated control system and safety system from a single source, all automated processes and convenience advantages must be critically tested. The more open and integrated a safety controller is, the more effort is required for organisation and security. Security attack vectors in this area include automated processes, such as diagnostic displays, the automatic interaction between engineering tool and controller, and the interaction between the visualisation of the control system and the safety system.
Levels of protection
To reduce systematic errors, standards IEC 61511-1 (Safety) and IEC 62443-3-3 (Security) require separate levels of protection and autonomy of the operating equipment and protective equipment. By design, an autonomous process control system and a safety system from different manufacturers require different engineering tools, databases, and operating procedures. Such systems from different manufacturers avoid common cause risks and reduce the security risk through diverse technology.
Diverse technology also ensures a clear separation of the areas of responsibility and supports the different handling of operating equipment and protective devices, in practice. With operating equipment the focus is on daily optimisation, updating, and change; in contrast, risk is reduced when protective equipment is operated rarely, and then only by qualified personnel. Each access to protective equipment constitutes a risk, and changes are only permitted via a management of change process.
The international standard IEC 62443-3-3, ‘Industrial communication networks – Network and system security’, requires compartmentalisation of production networks. To accomplish this, individual zones are determined (enterprise network, control room, safety system, process control system, etc) that are connected via defined transitions (conduits).
In accordance with the respective data or protocols that must be exchanged, protection is installed at each conduit in the form of a firewall. For this concept it is strictly required that exchanged data be clearly defined. Appropriate protective measures can only be provided if this structure is known to the user.
The forthcoming revision of standard DIN IEC 61511-1, ‘Functional safety – Safety instrumented systems for the process industry sector’, moves in this direction. It advocates testing, evaluating, and ensuring the independence, diversity, physical separation, and avoids common cause errors between levels of protection.
Moreover, it includes the clear statement that a safety system should be physically separated where feasible. Current discussions in standardisation bodies such as NAMUR and DKE likewise address the topic that autonomous secure separation and an appropriately defined conduit are required for mastery of security risks. If there is doubt in this regard, automatic convenience functions must also be deactivated to reduce the complexity and thus the security risks.
A safety system must have a variety of security features to harden it against safety-security risks or to reduce the risk in plants. The technical measures affect different areas:
* PC environment;
* Engineering tool;
* Communication;
* Secure control;
* Safety application;
Avoid common cause errors
The BIOS password is the outermost security layer to protect the PC and the engineering tool of the safety system against unallowed access. In accordance with the basic principle of supporting only that which is required, the operating system environment user guidelines and group guidelines must be set up with reduced access rights.
The use of a firewall and antivirus software, or better yet an Application Whitelisting, further improves the security protection. In this regard an Application Whitelisting, also referred to as application whitelisting, is indeed more complex in configuration; however, it offers better security protection, particularly against previously unknown malware, than is offered by antivirus software, because only the programs released by the user are allowed to be executed.
In order to properly configure the various security measures, the required ports and user rights for the engineering tool must be known. In addition, the engineering software must be compatible with the security software of other manufacturers. Thus the user can flexibly implement the security products that are prescribed or that are most suitable. The principle of diversity also applies for these levels of protection, as use of products from different manufacturers avoids the same type of errors.
Protective measures
SILworX, the engineering tool for HIMax, runs on a standard PC with Windows. The software is compatible with all major antivirus protection programs and consequently can be used with the antivirus software that is standardised and released for the respective company. SILworX protects itself against faulty installation data and manipulation via a CRC (cyclic redundancy check) that occurs each time the software is started or code generation takes place. In addition, MD5 checksums for the installation data are available to the user to check the correctness of the installation.
SILworX has additional features that promote security. A database file in a HIMA-specific format contains the data for the project generated with SILworX as well as the encrypted user ID and passwords. The function-relevant project parts are additionally protected via a separate CRC so that a change in the project data can also be detected and traced with the available secure code comparer.
It is possible to create a project archive automatically each time the controller is loaded. All changes can be traced via this seamless version history. This backup function also permits identification and restoration of the last valid project as part of a recovery procedure.
Two-level user management for project access and controller access ensures additional protection. The first level includes the right to access the project data. At this level personalised users can be created with individual user password and assigned to user groups.
In the second level the access rights are defined per controller. From among the created user groups the administrator can select which group may access the respective controller. A individual password is defined in each case. This password can be as complex as desired because it does not need to be known by the user.
Advantages of this procedure are that the user knows only his own password, and if there is a change of individual users or their passwords the controller itself is not changed. Thus the security protection is increased, and if there is a change in employees or a password update it is not necessary to make changes in the safety controller.
Accesses are recorded in the project log and in the controller diagnostics, which enables easy traceability.
Communication
The concept of separation is also consistently integrated in HIMA controller systems. For high-level cybersecurity different levels of protection with a virtual or physical separation can be set up for the communication. The HIMax CPU module executes the safety application and can handle communication tasks. Both areas are separated on the CPU through SIL3-certified protection of the memory and of the timing between the communications area and the safety area.
If an insecure data transmission is directly connected on the CPU, an integrated firewall ensures a virtual separation because only the protocols and data configured by the user are supported. Invalid or unknown protocol queries or read/write of non-configured address ranges are simply ignored by the controller.
For further risk reduction a physically separated communications module can be used. The module has the same security firewall characteristics as the processor module and is connected to the CPU only via the internal system bus. Because the communications module cannot influence the CPU the safe function is physically separated from the non-secure communication.
These features result in stable, robust system behaviour. HIMA incorporates cybersecurity measures in its product development right from the start. This includes the Achilles test procedure from Wurldtech, with which constantly updated tests are executed in the development process of all new products.
The Achilles test is recognised internationally for verification of industrial cybersecurity and includes a simulation of cyber attacks. In these tests, the processor module and the communications module of HIMax have proven their resistance to cyber attacks and have received the Achilles Level 1 certificate.
Secure control
The safety-related HIMax controller itself offers several possibilities for secure communication. Physical ports that are not used can be deactivated, and thus an authorised access can be prevented. Moreover, a graduated blocking of controller access is possible. Online changes and the forcing of values can be blocked via system variables. Read-only operation offers additional protection against manipulation.
With a key switch at the installation location of the system, the system variables can be written and enabled or disabled via a digital input. If this key is ‘removed’, the controller in RUN mode allows only reading, regardless of the accesses that occur via the network.
Last but not least, the safety application itself offers measures for increased security. For example, CRC protection can be used to display program changes in the system and to trigger alarms.
Conclusion
There is no safety without security. If a security risk exists via interfaces or integration, the integrity of functional safety is in jeopardy. security deserves this same high level of attention that is devoted to the topic of safety.
Properly structured to be autonomous and as separate as possible to avoid random and systematic errors, the safety controller constitutes the last line of defence.
The security standard IEC 62443-3-3 and the forthcoming revision of safety standard IEC 61511-1 support this approach by requiring separate levels of protection. By design, autonomous safety systems reduce security risks through the use of diverse technology.
Stefan Ditting and Thomas Janzer are Product Managers with HIMA Paul Hildebrandt GmbH, Brühl, Germany.