Safety & Security First: part three

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.

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 behavior. 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: 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 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.

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.

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.

Read the article online at: https://www.hydrocarbonengineering.com/refining/05032015/safety-security-first-part-one-385/