SAFETY MEASURES

IT security is a very important cornerstone that is often neglected and can have catastrophic consequences. Ritter Technologie GmbH attaches great importance to a seamless security concept that grows with its requirements. We adhere to the MITRE / LIST recommendations and our security measures are regularly checked for security gaps by external specialists. Automatic tests are not only an important basis at the software level; where possible, the hardware is also automatically checked for irregularities.

The certification body of TÜV SÜD Management Service GmbH certifies that the company Ritter Technologie GmbH, Essener Straße 2-24, 46047 Oberhausen (Germany) has implemented and applies an information security management system in accordance with the "Declaration of Applicability" for the adjacent scope. An audit, report no. 707066405, has provided evidence that the requirements of ISO/IEC 27001:2017 have been met. This certificate is valid from 01.01.2023 to 31.12.2025.

The scope of the information security management system of Ritter Technologie GmbH extends to the Oberhausen site, Essener Straße 2-24, applying DIN EN ISO 27001:2013, for the service profile "Innovative and secure IT solutions, consulting, infrastructure, data center operation, software & services".

SOFTWARE LIFE CYCLE

  • Security concepts: e.g. CRS, OWASP against SQLi, XSS, LFI, RFI, PHPci
  • Use of BSI standards 2020
  • Manual and automatic tests e.g. Cypress / Postman
  • 27K-certified data center and hardware / software development

FROM THE MITRE / NIST RECOMMENDATIONS

  • Stability of the component in terms of functionality
  • Mainly use of open source products to carry out your own source code reviews (create a fork if necessary)
  • Only use active projects

The greatest risk is if the open source projects are abandoned. In this case, further developments must take place in-house or a switch must be made to alternative products.

The products are also tested and checked by external specialists for IT security.

VULNERABILITY SCANS

We have already implemented a process to check all code repositories daily for new CVEs on a daily basis. This process uses Trivy, which automatically publishes reports and creates them in tickets for the relevant departments. The Trivy integration for Buildroot will be done through a parser for the PKG statistics generated by Buildroot.

ACCESS RIGHTS IEC 60870-104

Each IEC60870-104 server process can only connect to 1 client, redundant passive connection excluded. If several client systems such as Salvador and SCADA want to connect to the RTU, it is therefore necessary to have 2 IEC6087-104 server processes running on the RTU. This can be done via the mapping file by creating 2 configuration objects. Each IEC60870 server process has its own IOA object space. If you want to provide monitoring/control objects for both 104-server processes, it is necessary to create 2 objects within the mapping. 1 object for each server.

This procedure makes it possible to specify exactly which monitor and control objects are to be made available for each server process. An IP filter is provided for this purpose.

ACCESS CONTROL

ACCESS CONTROL (SCADA)

Access based on IP filter, secured by Ipsec VPN

VALIDATION OF CONFIGURATION FILES

All configurations are provided by Node-Red and are checked automatically.

KEY AND CERTIFICATE MANAGEMENT

During initial commissioning and when the expiration date is reached, the RTU retrieves a certificate from the PKI server via SCEP. This certificate is used to establish the IPsec connection from the RTU to the customer network. Optionally, it is also used for communication between the RTU and DEMAS. Requirement: Provide a suitable root CA for DEMAS, as the customer PKI generates the certificates.

OPTIONAL ON REQUEST

Security - Confidentiality and integrity of network communication: on RTU
If the WAN connection is already secured via VPN, optionally deactivate further encryption and thus, of course, certificates for deep packet inspection.

ACCESS CONTROL FOR ENGINEERS (DEMAS)

  • The structure of our technical protection is generic. All Auth providers can be connected via Keycloak and NGINX.
  • We have chosen mTLS (TLS client certificate issued via local PKI (SCEP)).
  • In addition to DEMAS, any other system can optionally be secured with this generic concept.

ACCESS CONTROL FOR ENGINEERS (RTU)

The RTU is managed centrally by DEMAS. Direct access to the RTU via SSH is therefore possible, but not necessary. With the RTU, it is possible to define any users, passwords and group assignments in the system configuration.

A central login service manages the logins for the DEMAS and Node Red modules. This configuration is normally provided by DEMAS, but can be changed locally. In this case, the change is recognized and UUID 0 is reported back to DEMAS. This enables DEMAS to react to the change.

The files and fatal recovery scripts can only be changed or executed by users with root rights.

The user must therefore either be in the root group or in the sudo group. In the second case, the user must initiate all actions with sudo.

  • We use Strongswan IPsec to secure the WAN communication path from the RTU to the customer network. The configuration of the IPsec parameters can be defined in the system configuration.
  • The certificate used is retrieved from the PKI server during the first access and the process via SCEP.
  • Authentication between 104 server and client has not yet been implemented as it is not part of the protocol specification.
  • To secure communication, we use IPsec for confidentiality and integrity.

RTU SECURITY FEATURES

  • FIT (Flattened Image Tree)
    • Hashed: SHA-256
    • Encrypted : AES-256-CBC
    • Signed X.509 Cert (4096 Bit RSA Key)
  • Cert check and image decryption on boot
  • Bootloader is secured via HABv4 signature (closed source by NXP)
  • CPU provides a HABv4 secure boot feature
  • CPU loads only bootloader with correct HABv4 signature
    • Dual boot for firmware fall back
    • Cert programmed in OTP (One Time Programmable) fuses

FIRMWARE SECURITY

The RTU firmware uses the FIT format. This one file contains the kernel, the device tree and the root file system. The RTU uses a RAM file system to prevent damage to the root FS. The boot loader U-Boot checks the validity of the FIT firmware image at each start, unpacks the data into the RAM and executes the Linux kernel. All changes in the root FS are lost after a restart.
The rtu-mgr process sets the settings for all services for each according to the system configuration provided by DEMAS.

The FIT image is signed accordingly. The public key is located in the bootloader because it has to verify the image. The private key is only on the RITTEC firmware build server and does not leave it. We use the maximum key format supported by U-Boot, RSA 4096 bit with SHA256.

The data in the FIT image is encrypted and the corresponding key is only hidden in U-Boot. This is not security-relevant, but only a measure against reverse engineering.

In addition, each FIT image is provided with a HABv4 signature. This is a proprietary
procedure from NXP that is implemented in the CPU. For this purpose, a private and public key is generated with an NXP tool. The private key never leaves the build server.
The public key is burned into the CPU by OneTimeProgrammable Fuses.

After the CPU is permanently locked via another OTP fuse, it can only execute correctly HABv4-signed bootloaders. The bootloader U-Boot used by us is therefore HABv4-signed, just like the FIT image of the firmware. After loading the FIT image, the bootloader first checks the HABv4 signature with the help of the CPU, then the FIT signature, decrypts the data in RAM and starts the kernel.

A firmware update is carried out by overwriting the complete inactive FIT image. The previously inactive image is activated and rebooted. All the processes described above now follow. If the image does not start, the watchdog switches back to the old image.