Professional Articles

Flexible and Secure Industrial Controls with Separation Kernels

The continuing technological advancement that is enabling decreasing costs and greater compactness of devices make it possible to connect and control more physical elements in the industrial environment today.
This is enabling industrial engineers to monitor processes with greater accuracy and drive OEE (Overall Equipment Effectiveness). At the same time separate operational technology (OT) systems are merging with enterprise IT infrastructure. However, this greater connectivity also brings more threats from malicious digital actors. Therefore, in addition to functional Safety, IT Security becomes a compelling focus. Safety and Security interact in a complex way. The most basic statement is that Safety cannot be established without Security, i.e. a system that is under the control of an attacker must be regarded as compromised in terms of functional Safety. Security is therefore urgently required to ensure the integrity and availability of Safety systems. In addition, sensitive data must be protected, as data loss or compromise could pose a serious risk to the company.

For developers of control devices, there is also very probably an emerging requirement for Security certification, as has long been established in the field of Safety. Next to standards such as IEC 61508, which regulate the design of functionally safe control systems, the IEC 62443 series of standards is showing up on the scene. This series covers several aspects, including the Safety of device-to-device communication, the protection of sensitive data, the authenticity of instructions and procedural guidelines for device manufacturers.

Managing the ever-increasing system complexity without neglecting Safety or Security is an arduous task. One approach to this makes use of the "divide and rule" strategy. The concept behind this is to identify existing module boundaries with loose couplings. These can be, for example, individual processes on an operating system (OS) or applications running on different cores of the same processor.

Strict Partitioning for more Security

By running the device hardware under control of a so-called separation kernel, the developer can create individual partitions. By partitioning the existing software along identified boundaries and moving each of the modules into its own partition, complete isolation in terms of Safety and Security can be achieved. In most cases, however, this is not a desirable state, as the various applications need to communicate with each other. Separation kernels therefore offer communication options such as shared memory areas and IPC channels (Interpartition Communication), which can be activated if required.

The strict separation into individual partitions means that applications cannot affect each other in any way, unless this is deliberately enabled by the integrator. Thus, the effects of an error can be limited to the partition in which it occurred. In addition, partitioning allows the introduction of Security domains, i.e. parts of the system with different Security level requirements. Separation kernels typically have a very small code base, which reduces the likelihood of programming or runtime errors. From a Security perspective, designs based on separation kernels are usually preferable to separation based on containers, since containerization provides only weak isolation. Containers are usually not designed to prevent privilege escalation of malicious applications. In extreme cases, such an application can then escape all the way into the host operating system. This can be reliably prevented with partitioning via a separation kernel.

Devices with mixed Criticality

When designing software, there is inevitably a trade-off between functionality and correctness: Feature-rich software will always be more complex and thus more prone to programming errors, which reduces Safety and Security. A mixed-criticality design aims to achieve both goals simultaneously by combining multiple subsystems with different criticality.

An example of this is a PLC that also includes an asset administration shell (ASS) and a web interface for initial configuration. Both the AAS and the web server are less critical than the PLC because the functional Safety properties of the device are not affected if either component fails. The PLC is therefore in a different (more critical) Safety domain. Cloud communication for data aggregation and analysis can also be implemented in a separate partition, so attackers will not be able to compromise the device via vulnerabilities in the uplink.

What applies to the cloud is no less important on the factory floor: secure communication via channels that are vulnerable in principle. This applies to both human-machine interfaces (HMI) and machine-to-machine communication (M2M). Consequently, control devices must integrate the appropriate stacks and servers, such as BaSyx, OPC UA, HTTP REST, MQTT, DDS, oneM2M.

Network services and the servers that provide them play an important role because they directly increase the attack surface of the device. Since today's protocols are so powerful and therefore complex, the risk of critical vulnerabilities increases accordingly.

Selective Recertification after Software Upgrade

Designs based on a separation kernel not only enable a very high level of safety and Security, but can also significantly simplify certification and thus save considerable costs. Particularly in the case of Security, changing certain properties of a system carries the risk that the Security assumptions are overridden and the system becomes insecure. In the case of a field device, this is the case when a software upgrade installs an additional externally directed service. Typically, in such a case, the entire device must be recertified, including the parts that have not changed. This fact makes it difficult to develop flexible devices that can be economically adapted to new manufacturing conditions.

Partitioning the device software under the rule of a certified separation kernel allows selective re-certification of only the partition that was affected by the update. The other partitions remain unchanged, and the strict separation ensures that their Security assumptions remain the same. In addition, the Separation Kernel can provide a secure upgrade mechanism with cryptographic signature, transport encryption and other features.

Untrusted Code and Legacy Applications

For manufacturing jobs without a strong trust relationship between customer and manufacturer, additional precautions must be taken in manufacturing to ensure Security during the process. For example, a would-be customer could attempt to infect devices with malware at the field level using manipulated manufacturing code. From there, the attacker could try to sabotage production or spread the infection to other parts of the network, such as the MES (Manufacturing Execution System), to access confidential information. In such constellations, it is therefore a good idea to isolate the customer's manufacturing code within one or more partitions to prevent it from crossing trust boundaries and increasing its privileges. This is done by restricting the untrusted partition's ability to communicate with other partitions on the same device or with the network and/or fieldbus.

Legacy applications can also be integrated into a new software design through partitioning. In such applications, the code was often written with only functional Safety in mind and does not hold up to a Security assessment. A separation kernel can fully encapsulate such applications and make them invisible from outside the device boundaries or from the perspective of other partitions on the same device. To do this, a secure gateway is set up with a firewall and intrusion detection system, and the legacy application communicates with the gateway only through dedicated monitored communication channels.

For legacy applications, it doesn't matter whether they previously ran on bare metal or used an operating system. This allows guest operating systems to run in para-virtualization or hardware virtualization mode while maintaining real-time capability, allowing the operator to stay independent of discontinued hardware platforms.

PikeOS

SYSGO's PikeOS supports a wide range of hardware architectures and provides interfaces for a variety of guest operating systems. The Separation Kernel has an integrated Linux guest OS for integrating Linux or other open source features such as networking, GUI or web server. Proprietary intellectual property, real-time functions and Security-critical applications run in separate partitions. Applications of different criticality and Security levels are securely separated in separate partitions and certified separately. As a European technology, PikeOS is not subject to export restrictions and can therefore be deployed globally.

More information at www.sysgo.com/pikeos