Security measures on fieldbuses

Reliable communication: A secure channel protects data transmission and does not interfere with communication from third-party devices.

© Infoteam Software

Best practice includes protecting a system from potential threats within the office IT. As a rule, this includes cloud and internet connections. But what about the wider industrial Ethernet environment and thus the fieldbuses? And how can field devices and sensors in industrial plants be effectively protected? Based on the IEC 62443 standard, the 'Defense in Depth' strategy requires all components to be protected individually (and the network).

The protection strategy for industrial control systems and their controlled devices is primarily aimed at protecting identity. We speak of authentication when, in addition to unique identification, the partner's authorizations are checked. However, each execution of such a function requires additional computing time, which makes the entire communication more demanding. Systems optimized for efficiency have little free capacity, so they need a method to provide a stable basis of security with little effort.

Fast response to exploits and still certified functionally secure. Thanks to Plug & Play, updates are possible without interfering with certified and tested security functions.

© Infoteam Software

One method of keeping the hardware requirements low is to send a message at regular intervals with a brief summary of the previous communication. Such a secure heartbeat protocol confirms the previous communication at regular intervals by exchanging a 'cryptographic' CRC (Cyclic Redundancy Checksum). If this confirmation is not received, or if this cryptographic CRC does not match the one that was generated independently using the communication data, then communication with an 'unauthorized partner' could be uncovered. The Secure Heartbeat protocol uses cryptographically encrypted CRCs so that the legitimacy of the messages sent can be confirmed in this way. The cost of this measure can be minimized by cleverly selecting the intervals in the secure heartbeat, the time cycle.

A sufficiently powerful system is able to carry out this process not just once per time cycle, but for each individual message. This so-called digital signature is already known from e-mail traffic and places a cryptographic signature under each message. In addition to a simple confirmation of what has been sent, the message could be encrypted in the same process. The corresponding libraries have already been implemented for the hash function, the effort is 'only' the capacity at runtime.

If not only individual messages, but the entire communication in a channel is to be secured, techniques familiar from everyday Internet use also help.

Secure channel with TLS

Similar to online banking and other secure websites, TLS can be used to establish a secure channel in the form of an encrypted session. The security of cryptographic functions depends on the effective key length. This length can be translated into the computing time required by an attacker to gain access to the secured system. In critical areas, it is common to choose a key length such that attackers would theoretically need thousands of years to calculate it. However, this increases the effort for the encrypting party and can be made less costly (but also less secure) in segments aimed at efficiency. If the key length is reduced, the effort is reduced accordingly. In order to be able to use the key length successfully with functionally secure methods, a key infrastructure should already be considered in the architecture of the components. Each device receives its own certificate with which it can authenticate itself and which also enables encryption for the respective device. At the same time, each device is enabled to protect this certificate on the basis of measures.

Which of the measures presented here - secure heartbeat, digital signature or TLS - is sensible and necessary can be seen from the result of a secure software development process, as this is precisely about identifying security risks from cyber attacks and defining requirements for suitable countermeasures. It is then efficient to integrate this secure software development process into the process for implementing functional security.

Obligations for operators

The first software providers and operators of functionally secure software solutions are now responding to the ever-increasing threat and are paying greater attention to security.

The focus is also on the fact that the legislator has clearly specified the obligations for operators of critical software infrastructures with the "Act to Increase the Security of Information Technology Systems" passed in 2015. Since then, they have been obliged to keep security up to date at all times. Security is a continuous process throughout the entire life cycle of the software in order to keep up with the latest threats. In practice, this usually means that the first step of software development is followed by a second step in which the software is first 'retrofitted' with regard to basic attack security and can then be kept up to date.

In contrast, the development process proposed by infoteam Software AG, in which the requirements for functional security and attack security are considered and implemented in parallel, is much more efficient. This symbiosis efficiently prevents cost-intensive subsequent and second developments.

Author: Max Perner is a software developer at Infoteam Software.