SICHERHEITSMAßNAHMEN

IT-Sicherheit ist ein sehr wichtiger Eckpunkt, der oft vernachlässigt wird und katastrophale Folgen mit sich bringen kann. Die Ritter Technologie GmbH legt größten Wert auf ein lückenloses Sicherheitszkonzept, das mit seinen Anforderungen mitwächst. Wir halten uns an die MITRE / LIST Empfehlungen und unsere Sicherheitsmaßnahmen werden regelmäßig von externen Spezialisten auf Sicherheitslücken geprüft. Automatische Tests stellen nicht nur auf Software-Ebene eine wichtige Grundlage, wenn möglich wird auch die Hardware auf Unregelmäßigkeiten automatisch überprüft.

Die Zertifizierungsstelle der TÜV SÜD Management Service GmbH bescheinigt, dass das Unternehmen Ritter Technologie GmbH, Essener Straße 2-24, 46047 Oberhausen (Deutschland) für den nebenstehenden Geltungsbereich ein Informationssicherheitsmanagementsystem gemäß „Erklärung zur Anwendbarkeit“ eingeführt hat und anwendet. Durch ein Audit, Bericht Nr. 707066405, wurde der Nachweis erbracht, dass die Forderungen der ISO/IEC 27001:2013 erfüllt sind. Dieses Zertifikat ist gültig vom 12.12.2020 bis 11.12.2023.

Der Geltungsbereich des Informationssicherheitsmanagementsystems der Ritter Technologie GmbH erstreckt sich auf den Standort Oberhausen, Essener Straße 2-24, unter Anwendung der DIN EN ISO 27001:2013, für das Leistungsprofil „Innovative und sichere IT-Lösungen, Beratung, Infrastruktur, Rechenzentrumsbetrieb, Software & Serviceleistungen“.

SOFTWARE-LEBENSZYKLUS

  • Sicherheitskonzepte: z.B. CRS, OWASP gegen SQLi, XSS, LFI, RFI, PHPci
  • Verwendung von BSI-Standards 2020
  • Manuelle und automatische Tests z.B. Cypress / Postman
  • 27K-zertifiziertes Rechenzentrum und Hardware- / Software-Entwicklung

AUS DEN MITRE / NIST EMPFEHLUNGEN

  • Stabilität der Komponente in Bezug auf die Funktionalität
  • Hauptsächlich Verwendung von Open-Source-Produkten zur Durchführung eigener Quellcode-Reviews  (ggf. einen Fork erstellen)
  • Nur aktive Projekte verwenden

Das größte Risiko besteht im Falle der Aufgabe der Open Source-Projekte. In diesem Fall müssen Weiterentwicklungen im eigenen Haus stattfinden, oder es muss auf alternative Produkte umgestiegen werden.

Die Produkte werden zusätzlich von externen Spezialisten für IT-Sicheheit getestet und geprüft.

SCHWACHSTELLEN-SCANS

Wir haben bereits ein Verfahren eingeführt, um alle Code-Repositories täglich auf neue CVEs auf täglicher Basis. Für dieses Verfahren wird Trivy verwendet, das automatisch Berichte veröffentlicht und sie in Tickets für die entsprechenden Abteilungen erstellt. Die Trivy-Integration für Buildroot wird durch einen Parser für die von Buildroot erstellten PKG-Statistiken erfolgen.

ZUGRIFFSRECHTE IEC 60870-104

eder IEC60870-104-Serverprozess kann sich nur mit 1 Client verbinden, redundante passive Verbindung ausgeschlossen. Wenn mehrere Client-Systeme wie Salvador und SCADA mit der RTU verbinden wollen, ist es daher erforderlich, dass 2 IEC6087-104-Server Prozesse auf der RTU laufen zu lassen. Dies kann über die Mapping-Datei erfolgen, indem man 2 Konfigurationsobjekte. Jeder IEC60870-Serverprozess hat seinen eigenen IOA-Objektraum. Wenn Sie Überwachungs-/Steuerungsobjekte für beide 104-Server-Prozesse bereitstellen wollen, ist es ist es notwendig, 2 Objekte innerhalb des Mappings zu erstellen. 1 Objekt für jeden Server.

Dieses Verfahren ermöglicht es, genau festzulegen, welche Monitor- und Steuerobjekte für jeden Serverprozess zur Verfügung gestellt werden sollen. Zu diesem Zweck wird ein IP-Filter bereitgestellt.

ZUGRIFFSKONTROLLE

ZUGANGSKONTROLLE (SCADA)

Zugang basierend auf IP-Filter, gesichert durch Ipsec VPN

VALIDIERUNG VON KONFIGURATIONSDATEIEN

Alle Konfigurationen werden von Node-Red zur Verfügung gestellt und werden automatisch geprüft.

SCHLÜSSEL- UND ZERTIFIKATSVERWALTUNG

Bei der Erstinbetriebnahme und bei Erreichen des Ablaufdatums ruft die RTU über SCEP ein Zertifikat vom PKI-Server ab. Dieses Zertifikat wird verwendet, um die IPsec-Verbindung von der RTU zum Kundennetz herzustellen. Optional wird es auch für die Kommunikation zwischen der RTU und DEMAS verwendet. Erfordernis: Eine passende Root CA für DEMAS bereitstellen, da die Kunden-PKI die Zertifikate generiert.

OPTIONAL NACH ANFORDERUNG

Sicherheit – Vertraulichkeit und Integrität der Netzwerkkommunikation: auf RTU
Wenn die WAN-Verbindung bereits über VPN gesichert ist, optional weitere Verschlüsselung deaktivieren und damit natürlich Zertifikate für Deep Packet Inspection.

ZUGANGSKONTROLLE FÜR INGENIEURE (DEMAS)

  • Die Struktur unseres technischen Schutzes ist generisch. Alle Auth-Provider können über Keycloak und NGINX angebunden werden.
  • Wir haben mTLS gewählt (TLS-Client Zertifikat ausgestellt über lokale PKI (SCEP)).
  • Neben DEMAS können auch beliebige andere Systeme optional mit diesem generischen mit diesem generischen Konzept gesichert werden.

ZUGANGSKONTROLLE FÜR INGENIEURE (RTU)

Die RTU wird zentral von DEMAS verwaltet. Daher ist ein direkter ist daher ein direkter Zugriff auf die RTU über SSH möglich, aber nicht erforderlich. Mit der RTU ist es möglich, beliebige Benutzer, Passwörter und Gruppenzuordnungen in der Systemkonfiguration zu definieren.

Ein zentraler Login-Service verwaltet die Logins für die Module DEMAS und Node-Red-Module. Diese Konfiguration wird normalerweise normalerweise von DEMAS bereitgestellt, kann aber lokal geändert werden. In diesem Fall wird die Änderung erkannt und UUID 0 an DEMAS zurückgemeldet an DEMAS zurückgemeldet. Dies ermöglicht DEMAS, auf die Änderung zu reagieren.

Die Dateien und fatalen Wiederherstellungsskripte können nur nur von Benutzern mit Root-Rechten geändert oder ausgeführt werden.

Der Benutzer muss sich also entweder in der Gruppe root oder in der Gruppe sudo befinden. Im zweiten Fall muss der Benutzer alle Aktionen mit sudo einleiten.

  • Wir verwenden Strongswan IPsec zur Sicherung der WAN-Kommunikation Pfad von der RTU zum Kundennetzwerk zu sichern. Die Konfiguration der IPsec-Parameter kann in der Systemkonfiguration festgelegt werden.
  • Das verwendete Zertifikat wird vom PKI-Server geholt während des ersten Zugriffs und des Ablaufs über SCEP.
  • Die Authentifizierung zwischen 104 Server und Client ist noch nicht implementiert noch nicht implementiert, da sie nicht Teil der Protokollspezifikation ist.
  • Um die Kommunikation zu sichern, verwenden wir IPsec für Vertraulichkeit und Integrität.

RTU-SICHERHEITSMERKMALE

  • 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

Die RTU-Firmware verwendet das FIT-Format. Diese eine Datei enthält den Kernel, den Gerätebaum und das Root-Dateisystem. Die RTU verwendet ein RAM-Dateisystem, um eine Beschädigung des Root-FS zu verhindern. Der Bootloader U-Boot prüft bei jedem Start die Gültigkeit des FIT-Firmware-Images, entpackt die Daten in den RAM und führt den Linux-Kernel aus. Alle Änderungen im Root-FS gehen nach einem Neustart verloren.
Der rtu-mgr-Prozess setzt die Einstellungen für alle Dienste bei jedem entsprechend der von DEMAS bereitgestellten Systemkonfiguration.

Das FIT-Image wird entsprechend signiert. Der öffentliche Schlüssel befindet sich im Bootloader, weil er das Image verifizieren muss. Der private Schlüssel ist nur auf dem RITTEC-Firmware-Build-Server und verlässt diesen nicht. Wir verwenden das von U-Boot maximal unterstützte Schlüsselformat RSA 4096 Bit mit SHA256.

Die Daten im FIT-Image sind verschlüsselt und der entsprechende Schlüssel ist nur in U-Boot verschleiert. Dies ist nicht sicherheitsrelevant, sondern nur eine Maßnahme gegen Reverse Engineering.

Außerdem wird jedes FIT-Image mit einer HABv4-Signatur versehen. Dies ist ein proprietäres
Verfahren von NXP, das in der CPU implementiert ist. Dazu wird ein privater und öffentlicher Schlüssel mit einem NXP-Tool erzeugt. Der private Schlüssel verlässt nie den Build-Server.
Der öffentliche Schlüssel wird durch OneTimeProgrammable Fuses in die CPU gebrannt.

Nachdem die CPU über eine weitere OTP-Sicherung dauerhaft verschlossen ist, kann sie nur noch korrekt HABv4 signierte Bootloader ausführen. Der von uns verwendete Bootloader U-Boot ist daher HABv4-signiert, genau wie das FIT-Image der Firmware. Nach dem Laden des FIT-Images prüft der Bootloader zunächst die HABv4-Signatur mit Hilfe der CPU, dann die FIT-Signatur, entschlüsselt die Daten im RAM und startet den Kernel.

Ein Firmware-Update wird durch Überschreiben des kompletten inaktiven FIT-Images durchgeführt. Das zuvor inaktive Image wird aktiviert und neu gebootet. Es folgen nun alle oben beschriebenen Vorgänge. Wenn das Image nicht startet nicht startet, schaltet der Watchdog auf das alte Image zurück.