Automatisierung des Schwachstellenmanagements im OT-Umfeld

Das zweite von vier diesjährigen Treffen des Praxiszirkels CRA von Next Industries / Swissmem hat stattgefunden. Wir waren dieses Mal bei Deloitte zu Gast und mit insgesamt 60 Teilnehmenden. Das Hauptthema des Zirkels war „Schwachstellenmanagement und Meldepflicht“ im Kontext des Cyber Resilience Act (CRA). Dazu gab es sehr interessante Beiträge aus dem juristischen Umfeld sowie direkt aus der Praxis. Die Redner kamen von United Machining Solutions, Beckhoff, Wicki & Partner, Deloitte und BBV.

Auch ich, Benjamin Fabricius , durfte einen Beitrag leisten und habe gemeinsam mit Sascha Huber von Weytec einen Vortrag zum Thema „Automatisierung des Schwachstellenmanagements im OT-Umfeld“ gehalten. Was wir dort besprochen haben und warum das Thema die Industrie gerade so intensiv bewegt, möchte ich hier mit euch teilen.

Regulatorischer Druck trifft auf manuelle Grenzen

Der regulatorische und betriebliche Druck auf kritische Infrastrukturen und Industrieunternehmen wächst kontinuierlich. Ein zentraler Knackpunkt im Operational Technology (OT)-Umfeld ist dabei die lückenlose Dokumentation und der verlässliche Nachweis von Sicherheitsmassnahmen.

Dieser Aufwand wird in der Praxis oft drastisch unterschätzt und erfordert tiefgehendes Spezialwissen. Es entsteht eine gefährliche Lücke zwischen dem theoretisch geforderten Aufwand und der realistisch erbringbaren Leistung von IT- und OT-Teams.

Gemeinsam mit Sascha Huber von der Schweizer Weytec AG habe ich diese Herausforderungen genauer beleuchtet. Das Schweizer Industriebeispiel zeigt deutlich, welche extremen Anforderungen an die Verfügbarkeit von Systemen in der Produktion gelten. In diesem Umfeld sind Offline-Tauglichkeit sowie die Durchführung von Factory Acceptance Tests (FAT) und Site Acceptance Tests (SAT) – also die Werks- und Endabnahmen von Anlagen – von zentraler Bedeutung. Manuelle Verfahren zur Prüfung von Schwachstellen skalieren hier schlichtweg nicht mehr. Die Lage ist branchenweit ähnlich kritisch.

Warum die OT eigene Randbedingungen diktiert

OT-Landschaften lassen sich nicht mit klassischen IT-Umgebungen vergleichen. Sie sind geprägt durch ganz eigene Rahmenbedingungen:

• Isolierte Netzwerke
  Stark eingeschränkte oder gänzlich fehlende Internetverbindungen prägen die Infrastruktur (Air-Gapped Systems).
• Störungssensibilität
  Die laufende Produktion ist extrem empfindlich und darf unter keinen Umständen durch aktive Security-Scans beeinträchtigt werden.
• Legacy-Systeme und Heterogenität
  Veraltete Betriebssysteme und proprietäre Hardware prägen das Bild. Jegliche Änderungen erfordern zudem langwierige, formale Freigabeprozesse (Change Control).
• Ressourcenmangel
  Das notwendige Domänen-Expertisewissen an der Schnittstelle zwischen IT- und OT-Sicherheit ist am Markt oft extrem knapp.

Wer hier weiterhin auf rein manuelle Verfahren setzt, agiert teuer, langsam und fehleranfällig. Der zeitliche und personelle Aufwand ist immens. Je mehr manuelle Prüfungen durchgeführt werden, desto höher ist die Fehlerquote , wodurch die Sicherheitsdokumentation schnell inkonsistent wird. Eine Skalierung ist kaum möglich , während bestehende Wissenslücken das Problem zusätzlich verschärfen.

Warum IT-Standardlösungen in der Produktion scheitern

Klassische Enterprise-Plattformen aus der IT-Welt greifen in der Produktion oft zu kurz oder passen nicht zu den Gegebenheiten vor Ort:

• Kostenstruktur
  Grosse Enterprise-Plattformen sind für spezialisierte OT-Angebote oft schlicht zu teuer.
• Cloud-Zwang
  Die inhärente Cloud-Abhängigkeit vieler moderner Tools widerspricht dem Prinzip isolierter OT-Netzwerke.
• Fehlendes Betriebsmodell
  Das klassische IT-Betriebsmodell fehlt in der Werkshalle häufig vollständig.
• Einführungsaufwand
  Die Implementierung kostet wertvolle Zeit, und am Ende steht oft ein System mit viel Funktion, aber oft überdimensioniertem Umfang für die OT-Praxis.

Kategorien von Automatisierungsansätzen im Überblick

In unserem Vortrag haben wir die strategischen Automatisierungsansätze in fünf Kernkategorien unterteilt:

• Ansatz A: Konfigurations- & Benchmark-Prüfung
  Dieser Weg ist komplett offline-fähig und hervorragend reproduzierbar. Er hat jedoch den Nachteil, dass er für sich genommen kein Software-CVE-Bild liefert.
• Ansatz B: Softwareinventar / SBOM
  Hier profitieren Sie von einer hohen Transparenz durch standardisierte Formate. Die Grenze liegt allerdings darin, dass dieser Ansatz isoliert betrachtet noch keine konkrete Risikoaussage bietet.
• Ansatz C: Anwendungs- & SBOM-Schwachstellenanalyse
  Dieser Ansatz ermöglicht einen direkten, lokalen CVE-Abgleich. Systembedingt stößt er jedoch dort an seine Grenzen, wo es um neuartige Bedrohungen geht, da er nur bereits bekannte Schwachstellen erkennen kann.
• Ansatz D: OS- & Patch-Bewertung
  Hiermit erhalten Sie eine sehr präzise Sicht auf das Betriebssystem und den aktuellen Patchstand. Der Haken an der Sache ist, dass dieses Verfahren deutlich mehr Logik und einen höheren Pflegeaufwand erfordert.
• Ansatz E: Ergänzende optionale Schichten
  Diese Schichten machen die Ergebnisse beweissicher, minimieren False-Positives und erhöhen die Abdeckung spürbar. Allerdings bedeutet das in der Praxis auch einen spürbar größeren Betrieb und mehr administrativen Overhead.

Ein tieferer Blick auf die Kernansätze

Ansatz A (Benchmark-Prüfung): Hierbei wird die Systemkonfiguration gezielt gegen anerkannte Branchen-Benchmarks (wie beispielsweise CIS) geprüft. Das liefert strukturierte, exakt reproduzierbare Prüfprotokolle und eignet sich hervorragend für den Offline-Betrieb in der OT. Ein vollständiges Bild aller Softwareschwachstellen liefert dieser Ansatz allein jedoch nicht.

Ansatz B (Inventarisierung & SBOM): Eine Software Bill of Materials (SBOM) schafft als digitale Zutatenliste vollständige Transparenz über alle verbauten Softwarekomponenten. Die Inventarisierung läuft automatisiert, und etablierte Standardformate erleichtern die Weiterverarbeitung. Gerade im Zuge neuer regulatorischer Vorgaben steigt der Nutzen von SBOMs massiv an. Das Risiko selbst wird dadurch jedoch noch nicht bewertet.

Ansatz C (Schwachstellenbewertung): Bringt man die SBOM mit aktuellen Schwachstellendatenbanken zusammen, erhält man ein präzises Bild der bekannten Sicherheitslücken (CVEs) auf System- und Softwareebene. Dank lokaler Datenhaltung funktioniert das auch komplett offline. Wichtig bleibt: Die finale Priorisierung der Risiken muss weiterhin manuell gesteuert werden.

Typische Hürden bei der Umsetzung

Bei der Umsetzung von automatisiertem Schwachstellenmanagement in Industrieunternehmen stossen Teams regelmässig auf organisatorische und technische Barrieren:

• Die Ownership (Verantwortlichkeit) zwischen IT und OT ist oft ungeklärt.
• Es fehlt an spezifischem Know-how für die fundierte Bewertung von Risiken.
• Strenge Change-Control-Prozesse verlangsamen die Einführung neuer Tools drastisch.
• Die enorme Heterogenität der Altsysteme erschwert die Etablierung von Standards.
• Der Aufwand für Offline-Updates und die nahtlose Integration in die bestehende Dokumentation wird unterschätzt.
• Viele vielversprechende Pilotprojekte scheitern, weil die Überführung in den dauerhaften Regelbetrieb (Verstetigung) nicht mitgeplant wurde.

Deshalb empfehlen wir

• Klein starten, gross planen
  Beginnen Sie mit einem überschaubaren Scope, aber designen Sie das System von Anfang an so, dass es konsequent skaliert werden kann.
• Offline-Fähigkeit priorisieren
  Planen Sie die Architekturen für isolierte Netze frühzeitig ein.
• Evidence-First etablieren
  Setzen Sie auf beweisbare Fakten und automatisierte Nachweise statt auf Vermutungen.
• Verantwortlichkeiten regeln
  Legen Sie die Ownership zwischen den Teams unmissverständlich fest.
• Ressourcen realistisch kalkulieren
  Planen Sie die benötigte Security-Expertise fest in die Budgets und Roadmaps ein.
• Verbindung schaffen
  Definieren Sie klare und einzuhaltende Update-Zyklen für die Datenbestände.

Mein Fazit vom Praxiszirkel – Organisation schlägt Automatisierung

Das primäre Problem im OT-Schwachstellenmanagement ist heute meist nicht das technische Scanning selbst, sondern die verlässliche Nachweisführung. OT-Umgebungen dulden keine unreflektierten IT-Konzepte – sie fordern inhärent OT-gerechte Ansätze. Eine kombinierte, schrittweise Automatisierung ist dabei absolut realistisch und erreichbar. Doch die goldene Regel lautet: Organisation vor Automatisierung. Nur wer seine Prozesse und Verantwortlichkeiten im Griff hat, profitiert am Ende von den automatisierten Systemen.