Automatisierte Device-Management-Lösung

Es gibt einige Punkte, auf die Unternehmen achten sollten, wenn sie sich mit dem Thema Device-Management beschäftigen. Besonders wichtig sind ein möglichst kontinuierliches Monitoring des Gerätezustands, eine reibungslose Konnektivität und ein geführter Onboarding-Prozess für neue Devices sowie eine Notfallwiederherstellung. Im täglichen Betrieb helfen Funktionen wie sukzessives Scheduling, das Planen von Updates und Szenariotests oder ein integriertes Ausrollverfahren von Updates im laufenden Build-Prozess. Mit Blick auf zukünftige Entwicklungen gilt es, auf eine skalierbare und leistungsstarke Infrastruktur zu achten, damit das Device-Management auch bei einer Geräte-Expansion flexibel mitwachsen kann.

Die Container-Technologie hat sich in Bezug auf Linuxbasierte Applikationsentwicklungen zum Industriestandard entwickelt und ist ein wesentliches Element des Device-Managements. Docker-Anwendungen etwa sind sehr leichtgewichtig, flexibel einsetzbar und laufen entkoppelt vom Betriebssystem. So wird sichergestellt, dass sich die Anwendungen bei Änderungen schnell auf unterschiedliche Geräte verschieben lassen. Zudem können viele Anwendungen auf einem Gerät laufen, ohne dass eine hohe Performance erforderlich wäre: Das senkt Investitionskosten bei Arbeitsspeicher und Kernel.

Vorbereitung auf verschärfte Regularien zur Cybersecurity

Mit Vorlagen (Templates) können Geräte- und Komponentenhersteller im Device-Management sehr einfach auch für ganze Gerätegruppen festlegen, welches Betriebssystem und welche Anwendungen auf welchem Gerät installiert werden sollen. Änderungen an der Vorlage können dann mit einem Klick auf alle betroffenen Geräte zum Beispiel eines Typs oder innerhalb einer spezifischen Region ausgerollt werden, was Zeit spart und Fehler minimiert.

Die gesetzlichen Vorgaben haben sich bereits verschärft: Ab März 2025 gilt die NIS-2 (Richtlinie zur Netz- und Informationssicherheit) und ab September der EU Data Act. In den nächsten Jahren kommen weitere Regularien dazu, darunter der ab 2027 geltende Cyber Resilience Act (CRA) zur Stärkung der Cybersicherheit von Produkten mit digitalen Komponenten. Das stellt sehr viele Unternehmen vor großen Herausforderungen, nicht nur, aber insbesondere im Bereich kritischer Infrastruktur rund um Kommunikation, Energieversorgung oder Logistik. Es gilt jetzt, Projektteams aufzusetzen, Lücken zu identifizieren, Risiken einzuschätzen, die Lieferantenauswahl zu prüfen und in die Umsetzung zu gehen.

Herausforderung Security by Design

Mit dem Cyber Resilience Act (CRA) ist erstmals verbindlich Security by Design für Hardware, Betriebssystem, Software, Connectivity und Gesamtsystem gefordert (Bild 2). Das bedeutet, dass bereits in der Produktentwicklung Komplexität, Zeit- und Ressourcenaufwand deutlich steigen. Je mehr die Zulieferer hier an Arbeit abnehmen können, desto besser. Kontron [2] ist dafür bereits einen Schritt weitergegangen und befindet sich kurz vor dem Abschluss der Zertifizierung seines Entwicklungsprozesses nach IEC 62443-4-1:2018 – einem Standard, der sowohl auf Hardware- als auch Softwareebene für Komponenten technische und prozessbezogene Aspekte der Cybersicherheit in Automatisierungs- und Leitsystemen adressiert. Schlüsseltechnologie für die Cybersicherheit ist KontronOS als gehärtetes Betriebssystem, sozusagen als Windows für Maschinen. Das schlanke OS auf Linux-Basis ist so konzipiert, dass kein Einfallstor geboten wird, alle Verbindungen komplett verschlüsselt sind und nur OS-Software ausgeführt werden darf, die freigegeben und digital signiert wurde. Zusammen mit zertifizierter Hardware auf x86- und ARM-Basis, der Low-Code-Integrationssoftware für Konnektivität (FabEagle Connect) und der IoT-Device-Management-Lösung KontronGrid wird die nötige Sicherheitsinfrastruktur gestellt. Der Endkunde muss jedoch selbst sicherstellen, dass seine gesamte Systemarchitektur diesen Anforderungen gerecht wird. Dieses nahtlose Zusammenspiel von Hard- und Software kann Betreibern jedoch einige Schmerzpunkte in Bezug auf Security-by-Design-Aufgaben rund um Gefahren- und Risikoanalyse, sichere Konfiguration, Überwachung, Erkennung und Reaktion sowie Update-Management abnehmen (Bild 3). So können diese ihre IoT-Infrastruktur mit weniger Aufwand dokumentieren, auditieren und langfristig absichern.                                                                                                                                                   

Literatur

1. IEC 62443-4-1:2018: Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements
2. Kontron AG, Linz, Österreich: www.kontron.com