In automation technology, the Linux system is typically responsible for data aggregation and processing, communication and visualization. An additional microprocessor, an FPGA or even a dedicated core of a multi-core CPU (AMP approach) are often responsible for safety-critical control systems. These safety-critical components are often 'behind' the Linux system in relation to the 'outside world' and are shielded by the Linux system with regard to security requirements.

Security means much more than just data security. Know-how and, in particular, manipulation protection are often much more important. The TÜV project 'Security4Safety' makes this just as clear as an FDA decision from 2016 in the field of medical technology, albeit from outside the industry, in which an already approved infusion pump was also classified as functionally unsafe for the first time due to security deficiencies. With the amendment to the IT Security Act, the extended requirements are reflected in the legal framework.

During the secure boot process, the authenticity of each individual software layer is checked.

© Emlix

Basically, although there is a lot to read about network attacks, direct attempts to manipulate the device are at least as dangerous. It must therefore be prevented that unauthenticated software is executed on the device. However, for verification to be secure, the 'responsible instances' of the software system must themselves be authenticatable. This explains the need for a secure boot process, i.e. securing the entire software initialization process from the outset. It starts with the so-called root-of-trust and checks the authenticity of each individual software layer before its execution is permitted.

The good news is that almost all modern 32- or 64-bit processors have components that support a secure boot. What these look like is CPU-specific. Unfortunately, the - again specific - firmware with which crypto units and protected memory areas can be used is all too often not public, which can make it difficult to actually commission and use the modules. Simply switching on the security functionality is hardly enough. Secrecy is less about security and more about preventing reverse engineering. This also often limits the portability of security solutions.

As already mentioned, it must be defined at an early stage when the root key and derived keys are to be generated and when the security functionality is to be activated. Some people have already locked themselves out of their own system. If necessary, subordinate keys are only generated during installation so that, in addition to the manufacturer's root key, there is a key that is only known to the customer. Keys for encryption and authentication should be protected and stored separately from other software in encrypted form in a non-volatile memory.

Who has what rights?

Finally, for subsequent integration and commissioning, the question of who has which rights to the system must be clarified. During initial commissioning, the mutual authentication of all end points must usually take place for the first time. In the Linux context, various technologies are available for generating and exchanging certificates that have been established over many years and in different application contexts. Today, TLS, the further development of SSL, is usually used to authenticate the backend server when establishing a connection.

If the connection is established from the embedded device, there is no need for externally accessible services. Only once the encrypted channel has been established can data be transmitted securely - regardless of whether it is system data to the server or updates or control data to the device. In order to be able to check the authenticity of the individual data, signatures should be used in both directions. GnuPG or OpenSSL, for example, are available for this purpose. In any case, update software must be signed so that its authenticity and integrity can be verified.

For high security requirements, the aforementioned authentication within the device can be provided, for example between the Linux system and the safety-critical application on a microcontroller. This also secures an update of the microcontroller firmware via the Linux system. In addition, any mobile HMIs used must be integrated into the safety concept, especially if they are used not only for visualization but also for control. The extent to which BYOD approaches make sense and are possible with high security requirements should be carefully examined.

Hardening the system software

In addition to these measures for secure communication, the Linux system or the entire system software itself must be made more secure. This so-called hardening has several aspects: Firstly, a minimalist approach should be taken when compiling the kernel, libraries, system services and also applications. This means that only those software components from documented sources that are actually required are used. This not only reduces the number of potential security vulnerabilities, but also the maintenance effort.

In many projects, this requirement is the decisive factor for not using just any Linux distribution, the Linux system supplied or the Linux system available in Yocto from the manufacturer, but rather putting together a Linux platform that is as close to the mainline as possible in a bottom-up approach. This may mean additional work initially, but it pays off reliably over the life cycle. The more mainline-compliant the Linux system is, the easier and quicker it is to apply security patches later on. The documentation effort for systems requiring certification is also significantly reduced.

Another aspect is a component-based approach, which Linux systems have per se. Ideally, each individual component should remain clear enough to be understandable and maintainable from a security perspective. Finally, the 'least privilege' principle should be followed: Ideally, each component should only have access to those resources that it actually needs. This also goes hand in hand with the correct configuration of the Linux system, which should be tested as standardized as possible.

Last but not least, a secure system requires a secure development and build process in order to make the implementation and configuration of the security measures traceable. This also applies to every subsequent release within the life cycle.

Duty of manufacturers and distributors

The points mentioned so far are examples of a possible security concept. The use of open source technologies makes it possible to adapt the security measures extremely flexibly to the respective requirements and processes in production, installation, operation and maintenance. However, the specific design and implementation are ultimately the responsibility of the manufacturers and distributors. In the case of an open source system, they are also responsible for lifecycle maintenance. In relevant certification requirements and in some supplier declarations, there is already an obligation not only to demonstrably guarantee a certain level of security, but also to maintain this throughout the lifecycle. This means that if security vulnerabilities become known, a response must be made and a patch, an updated package version or a new release rolled out.

The corresponding process must be defined in advance. If a bug becomes known, the 'Linux community' usually reacts very quickly and provides patches or updates. However, it is important to ensure that such reports and news are communicated immediately. Various sources of information should be scanned regularly for this purpose. The 'format' under which security vulnerabilities can be reported and read about are so-called CVEs (Common Vulnerabilities and Exposures).

Not all listed vulnerabilities are relevant for your own system. An appropriate assessment must therefore be carried out. Is the package version currently in use affected at all? Is it relevant in the given application context? If so, how critical is the vulnerability and how quickly does it need to be closed? Here it can make sense to commission appropriately positioned service providers with monitoring and evaluation. In automation technology in particular, an update often means production downtime because parts of the system have to be shut down. Weekly, precautionary 'forced updates' cannot be the solution here.

Experience has shown that many updates and patches have plenty of time until the next release, which is planned anyway. However, in the event of a critical error, it pays to have already coordinated the release process with the potentially affected customers and to have reliable update mechanisms in place.

Incidentally, a welcome by-product of security monitoring is that other updates and patches are also 'discovered' in the process that are relevant for other functionalities of the Linux system or make an 'ugly' workaround obsolete. Responsibility for security lifecycle maintenance also makes it possible to manage all these processes optimally and in accordance with customer requirements. A conscious update strategy also ensures customer loyalty, which some competitors cannot (yet) offer

Author:
Heike Jordan is Managing Director of Emlix.