Hört sich nach unglaublich viel Arbeit an, doch Klagen höre ich eigentlich nur hinter vorgehaltener Hand.
Jaeger: Im Moment ist es noch ein wenig wie ein Damoklesschwert, weil für die Hersteller noch viel in der Schwebe ist. Wir wissen schon, worum es geht und sind insgesamt ziemlich gut aufgestellt, insbesondere durch unsere zertifizierten Prozesse nach IEC 62443-4-1 und unser erprobtes Vulnerability Management. Aber es gibt eben noch keine harmonisierten Standards, wie genau diese Geräte dann wirklich getestet werden sollen. Da steckt der Teufel im Detail! Es gibt zum Beispiel auch noch keine genauen Vorgaben, wie Schwachstellen, die Vulnerabilities, dann an die ENISA gemeldet werden müssen. Da fehlt einfach noch an vielen Stellen die harte Praxis – wir warten jetzt ab, was zum Beispiel die CENELEC [Anm. der Red: Europäisches Komitee für elektrotechnische Normung] dazu sagt, damit wir uns komplett aufstellen können. Im Hintergrund sind wir aber bereits dabei, unsere Produkte zu kategorisieren, potenziell benötigte Dokumente bereitzustellen und unsere Prozesse insgesamt auf die neuen Anforderungen vorzubereiten.
Was bedeuten diese aktuellen Anforderungen konkret für Ihre Entwickler – im Bereich Software und Hardware – bei der Produktgestaltung?
Jaeger: Seit 2020 ist Moxa nach IEC 62443-4-1 zertifiziert, deshalb steht bei einigen Produkten der Hinweis ‚Developed according to IEC 62443-4-1‘. Für die Entwickler bedeutet das einen deutlichen Mehraufwand. In der IEC 62443 gibt es sogenannte Functional Requirements – die sind zunächst relativ generisch formuliert, werden dann aber für verschiedene Gerätetypen konkretisiert. Wenn ich zum Beispiel eine Netzwerkkomponente habe, gibt es dort bestimmte Anforderungen, die erfüllt werden müssen, um verschiedene Security Levels zu erreichen. Wollen Sie also ein Gerät mit Security Level 2 entwickeln, müssen Sie beispielsweise für Secure-Boot-Funktionalität sorgen: Also sicherstellen, dass das Gerät nur mit originaler Firmware und einem legitimen Bootloader startet und nicht durch ein manipuliertes BIOS oder einen fremden Bootloader kompromittiert werden kann. Damit verhindert man, dass Schadsoftware die Kontrolle übernimmt und den Netzwerkbetrieb beeinträchtigt.
Und wenn eine Schwachstelle später entdeckt wird, wie es die Regel ist?
Jaeger: Später müssen Schwachstellen natürlich im Markt beobachtet und gemanagt werden. Deshalb haben wir bei Moxa ein Product Security Incident Response Team, kurz PSIRT. Ich habe kürzlich erst erfahren, dass unsere Kollegen in diesem Bereich auch von außen ein gutes Feedback bekommen, was mich natürlich freut.
