Warum fehlende Transparenz das größte Sicherheitsrisiko ist?!
Wenn man Betreiber fragt, wie viele Steuerungen, Gateways, WLAN Komponenten oder Softwareinstanzen in ihrer Anlage aktiv sind, bekommt man selten eine präzise Antwort.
Nicht weil das Wissen fehlt. Sondern weil es nie strukturiert erhoben wurde. Und genau hier beginnt eines der größten Risiken in Industrial Control Systems. Man kann kein System absichern, das man nicht vollständig kennt.
In vielen Anlagen existieren über Jahre gewachsene Strukturen. Erweiterungen wurden ergänzt, Steuerungen ersetzt, Software aktualisiert, Netzwerke erweitert. Dokumentation wurde nachgeführt oder auch nicht.
Das Ergebnis ist ein System, das technisch funktioniert, aber strukturell intransparent ist. Diese Intransparenz wird spätestens dann zum Problem, wenn eine Schwachstelle bekannt wird. Ein Hersteller veröffentlicht eine Sicherheitsmeldung. Eine bestimmte Firmware Version ist betroffen. Die Frage lautet dann nicht mehr, ob ein Risiko existiert.
Die Frage lautet: Sind wir betroffen?
Und genau hier zeigt sich, ob Asset Management funktioniert oder nicht. Wenn die Antwort lautet „Wir müssen erst prüfen, welche Versionen überhaupt im Einsatz sind“, dann ist das kein technisches Problem. Es ist ein strukturelles. Asset Management ist in ICS kein Inventarverzeichnis. Es ist die Grundlage für jede Sicherheitsentscheidung.
Ein Asset ist dabei nicht nur ein Gerät. Ein Asset kann sein:
Eine Steuerung
Eine Safety Komponente
Ein HMI System
Eine Engineering Station
Ein Netzwerkgerät
Ein WLAN Access Point
Ein Gateway
Eine Softwareinstanz
Eine Firmware Version
Ein Kommunikationspfad
Besonders wichtig ist dabei die Verknüpfung dieser Elemente. Eine Steuerung ist nicht nur eine IP Adresse. Sie hat eine Firmware. Sie gehört zu einer Zone. Sie kommuniziert mit anderen Systemen. Sie ist Teil eines Prozesses. Diese Zusammenhänge müssen abgebildet werden.
Hier kommt die CMDB ins Spiel.
Eine Configuration Management Database ist kein IT Werkzeug, das man einfach übernimmt. In OT Umgebungen muss sie anders gedacht werden. Eine ICS CMDB muss folgende Fragen beantworten können:
Welche Komponenten existieren
Wo befinden sie sich logisch und physisch
In welcher Zone sind sie eingeordnet
Welche Firmware oder Software läuft darauf
Mit welchen Systemen kommunizieren sie
Wer ist verantwortlich
Welchen Lifecycle Status haben sie
Erst wenn diese Fragen beantwortet sind, entsteht echte Transparenz. Ein typisches Beispiel aus der Praxis.
Ein Betreiber plant ein Update einer zentralen Steuerungssoftware. Die neue Version setzt eine bestimmte Firmware auf den angeschlossenen Steuerungen voraus. Ohne CMDB bedeutet das:
Manuelle Prüfung
Unvollständige Daten
Risiko von Inkompatibilitäten
Mit sauberer CMDB bedeutet das:
Abgleich der Abhängigkeiten
Identifikation betroffener Systeme
Planbare Umsetzung
Das gleiche gilt für Sicherheitsfragen. Wenn eine Schwachstelle in einer bestimmten Bibliothek entdeckt wird, muss nachvollziehbar sein, in welchen Systemen diese Bibliothek enthalten ist. Ohne diese Transparenz bleibt Vulnerability Management theoretisch. Ein weiterer kritischer Punkt ist der Lifecycle. Viele ICS Komponenten sind über zehn oder fünfzehn Jahre im Einsatz. Manche sogar länger. Eine CMDB muss daher auch den Lifecycle abbilden.
Ist die Komponente aktiv
Ist sie veraltet
Ist sie noch patchfähig
Ist sie bereits End of Life
Diese Informationen sind entscheidend für Risikoentscheidungen. Ein nicht patchbares System ist nicht automatisch unsicher. Aber es erfordert andere Schutzmaßnahmen. Diese Entscheidung kann nur getroffen werden, wenn der Status bekannt ist. In der Praxis sieht man häufig Excel Listen, die als Asset Verzeichnis dienen. Für kleine Umgebungen mag das funktionieren. Für komplexe Anlagen ist es nicht ausreichend. Der Grund ist einfach. Eine Excel Liste bildet keine Beziehungen ab.
Sie zeigt nicht, welche Systeme miteinander kommunizieren. Sie zeigt nicht, welche Software auf welcher Hardware läuft. Sie zeigt nicht, welche Änderungen wann erfolgt sind. Eine CMDB hingegen ist ein lebendes Modell der Anlage. Sie bildet nicht nur Zustände ab, sondern Zusammenhänge. Und genau diese Zusammenhänge sind entscheidend für Sicherheit. Ein weiterer Aspekt ist die Verbindung zur Architektur.Zonenkonzepte, Conduits und Security Levels sind nur dann sinnvoll, wenn die zugehörigen Assets eindeutig zugeordnet sind. Eine Zone ohne klare Asset Zuordnung ist nur ein theoretisches Konstrukt. Deshalb gehört Asset Management nicht ans Ende eines Projekts, sondern an den Anfang. Es ist die Grundlage für:
Risikoanalyse
Architekturdefinition
Vulnerability Management
Incident Response
Auditfähigkeit
Und es ist einer der wenigen Bereiche, in denen sich technische und organisatorische Disziplin direkt auszahlt. Ein sauberes Asset Management reduziert Unsicherheit. Eine gepflegte CMDB reduziert Reaktionszeit. Beides zusammen erhöht die Betriebssicherheit.
Im nächsten Artikel gehen wir einen Schritt weiter und betrachten das Lifecycle Management. Dort wird sichtbar, wie sich technische Systeme über Jahre verändern und warum Security nur dann funktioniert, wenn diese Veränderungen kontrolliert werden.
Weitere Artikel
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 10 – MQTT in ICS
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 8 – Diverse Architekturen normgerecht umsetzen
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 7 – OPC UA und MQTT
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 3 – Wann wird eine industrielle Anlage regulatorisch zu einem Produkt und was bedeutet das für Betreiber