This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

How functional safety and cybersecurity can together improve plant safety

25 September 2015

Productivity is one of the highest priorities 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.

This article and case study, by Stefan Ditting and Thomas Janzer of HIMA Paul Hildebrandt GmbH, looks at how SIL 3 controllers designed especially for functional safety include features that are also quite helpful for cybersecurity protection.

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.

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 jeopardizes 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 solutions cannot be easily mastered

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.

Standards require separate 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.


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.


HIMA case study: technical measures reduce 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. These are: PC environment; Engineering tool; Communication; Secure control and Safety application.

PC environment: 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. The latter offers better security protection 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.

Engineering tool: Comprehensive protective measures

As an example, 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 cyclic redundancy check (CRC).

The latest SIL 3 controllers have cybersecurity protection features
The latest SIL 3 controllers have cybersecurity protection features

SILworX has other security features, including a database file which contains the data for the project 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.

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.

Communication: separate levels of protection

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. And for further risk reduction, a physically separated communications module can be used.

HIMA incorporates cybersecurity measures in its product development right from the start, including the Achilles test procedure from Wurldtech for verification of industrial cybersecurity.

Secure control: Many protection possibilities

The safety-related HIMax controller itself offers several possibilities for secure communication. Physical ports that are not used can be deactivated, and thus an authorized 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.

Safety application: Display of program changes

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.

Print this page | E-mail this page