Welche konkreten technischen Anforderungen der IEC 62443-4-2 waren für Nerve besonders herausfordernd?

Im Rahmen der Vorbereitung auf die Zertifizierung haben wir zahlreiche Anpassungen an Nerve vorgenommen. Dabei stand für uns stets der Benutzer bzw. die Benutzerin im Mittelpunkt. Unser Anspruch war es, Sicherheitsfunktionen nicht nur „abzuhaken“, sondern ihren konkreten Kundennutzen zu maximieren, zum Beispiel bei Audit-Logs, Integritätsprüfungen und dem Production Mode. In diese Themen sind nicht nur erhebliche Entwicklungsressourcen, sondern auch Aufwand für Design, Usability-Checks, Tests und Workflow-Definitionen geflossen.

Die zeitintensivste Aufgabe bestand darin, ein IEC 62443-4-2-zertifiziertes Nerve auf generischer Drittanbieter-Hardware zu ermöglichen, inklusive Datenträgerverschlüsselung, Secure Boot und Read-only-Partitionen.

Ergänzender Vorteil: Mit Nerve 3.1 haben wir den Production Mode eingeführt, der die Angriffsoberfläche im Feldbetrieb reduziert und Konfigurations- beziehungsweise Integritätschecks automatisiert protokolliert. Zusätzlich wurden Workload-DNA-Signaturen eingeführt sowie die Sichtbarkeit des Secure-Boot- und Disk-Encryption-Status verbessert. Das erleichtert Betrieb und Auditierung.

Wie wirkt sich die Zertifizierung auf bestehende Kundeninstallationen aus?

Bestehende Installationen können grundsätzlich weiter betrieben und aktualisiert werden. Wenn jedoch bestimmte Sicherheitsfunktionen wie Secure Boot oder Datenträgerverschlüsselung aktiviert werden sollen, ist ein manueller Eingriff erforderlich, abhängig vom jeweiligen Gerät. Wir stellen dafür Härtungsleitfäden und Installationshinweise bereit, unter anderem auch für Secure-Boot-Setups auf unterstützter Hardware.

Welche Rolle spielt die kontinuierliche Überprüfung und Aktualisierung der Plattform im Zertifizierungsprozess?

Für die Produktzertifizierung von Nerve nach IEC 62443-4-2 ist die Prozesszertifizierung nach IEC 62443-4-1 eine notwendige Voraussetzung. In diesem Rahmen werden Änderungen systematisch auf ihre Auswirkungen auf die Sicherheit bewertet, unter anderem über Threat-Analysen, CVE-Monitoring und regelmäßige Vulnerability-Scans. So lassen sich grundlegende Änderungen an Schutzmechanismen frühzeitig identifizieren.

Grundsätzlich unterliegen nachfolgende Produktreleases keiner erneuten Zertifizierungspflicht, außer bei den erwähnten grundlegenden Änderungen an den Schutzmechanismen oder bei neuen schutzbedürftigen Produkteigenschaften.

Wie wird der sichere Offline-Betrieb technisch umgesetzt?

Jeder Knoten – ob mit oder ohne Internetverbindung – wird nach unseren Vorgaben gehärtet. Muss ein gehärtetes Gerät dauerhaft oder auf unbestimmte Zeit ohne Internetverbindung auskommen, ist das aus Security-Sicht unkritisch, im Gegenteil: Ohne Internetverbindung reduziert sich der Angriffsvektor sogar. Patches und Updates für Kundenapplikationen oder den Nerve-Knoten können lokal über NAS oder USB-Speicher eingespielt werden.

Der dauerhafte Offline-Betrieb ist ein grundlegendes Feature von Nerve, das bei Zertifizierung und Schutzmechanismen berücksichtigt wird. Nerve besteht aus Node-Software am Edge und einem Management-System (Cloud oder On-Premises). Das Gesamtsystem kann auch offline betrieben werden.

Welche Bedeutung hat TLS 1.2 im Kontext industrieller Anwendungen, und sind künftig neuere Versionen geplant?

Die komplette Kommunikation zwischen Nerve Edge und dem Management-System erfolgt verschlüsselt über HTTPS/TLS. In industriellen Umgebungen ist dabei die Firewall-Kompatibilität entscheidend: Die IT muss lediglich einen einzigen TCP-Port (443) in Richtung der URL des Management-Systems freigeben. Die Verbindungen werden ausgehend vom Knoten initiiert.

Aktuell sichert Nerve diese Verbindungen mit TLS 1.2 oder höher. Künftig soll, sofern verfügbar, auch TLS 1.3 zum Einsatz kommen. Damit entsprechen wir dem Stand der Technik und den Anforderungen der IEC 62443 an die Kommunikationsintegrität.

Wie unterscheidet sich Nerve von anderen IIoT-Plattformen in Bezug auf Sicherheitsarchitektur?

Eine Grundregel sicheren Produktdesigns lautet: Security nicht neu erfinden, sondern auf Industriestandards, bewährte Design-Patterns und etablierte Prozesse setzen. Diesen Ansatz verfolgen wir mit Nerve. Der Unterschied liegt daher weniger in der Sicherheitsarchitektur selbst, sondern darin, wie konsequent wir sie anwendungs- und benutzerfreundlich umsetzen.

Welche Haftungsfragen ergeben sich für Hersteller durch das Cyberresilienzgesetz konkret?

Kurz gefasst: Hersteller müssen ihr Software-Angebot über den gesamten Lebenszyklus absichern („Security by Design/Default“), Updates im Supportzeitraum bereitstellen, Vulnerabilities managen und aktiv ausgenutzte Schwachstellen beziehungsweise schwere Vorfälle fristgerecht melden (Frühwarnung ≤ 24 h, Details ≤ 72 h über die ENISA Single Reporting Platform ab dem 11.09.2026).

Mit Nerve erfüllen wir die notwendigen Voraussetzungen auf Produktseite, unter anderem durch die IEC 62443-4-2-Zertifizierung, umfassende Logging- und Integritätsmechanismen, rollenbasierte Verwaltung und verschlüsselte Datenübertragung – und unterstützen damit die CRA-Readiness unserer Kunden. Maschinenbauer, die Nerve einsetzen, müssen sich primär auf ihre eigenen Applikationen konzentrieren und dort die entsprechenden Pflichten einhalten.

Wie aufwendig ist die Integration von Nerve in bestehende Legacy-Systeme?

Durch die konsequente Nutzung von Standardtechnologien und -protokollen lässt sich eine bestehende Lösung meist in kurzer Zeit, typischerweise innerhalb einer Woche, auf Nerve als Plattform migrieren. Der Hauptaufwand liegt häufig im strukturierten Rückbau der Altlösung. Deployment und Inbetriebnahme erfolgen anschließend in der Regel zügig.

Welche Audit- oder Reporting-Funktionen stehen Betreibern zur Verfügung?

Bei der Umsetzung von Audit- und Reporting-Funktionen haben wir großen Wert auf Benutzbarkeit gelegt. Nerve bereitet Audit-Logs intern auf und integriert sie in das Management-System. Gezielte Einzelreports, zum Beispiel pro Workload oder Knoten, sowie flottenweite Analysen lassen sich über OpenSearch-Dashboards umsetzen. Zusätzlich können Logs exportiert und extern weiterverarbeitet werden. Die Dashboards bleiben auch bei Offline-Knoten zugänglich.