Angesichts der immer komplexeren, oftmals lange nicht sichtbaren Hackerangriffe nehmen heutzutage viele die aktuelle Bedrohungslage als diffus wahr, gepaart mit einem „unguten Bauchgefühl“ und einer gewissen Verwirrung, wenn es um die Begriffe geht: Auf der einen Seite steht die Industrie mit ihren Forderungen nach Sicherheit, auf der anderen stehen die IT-Hersteller, die mit ihren Lösungen genau dies versprechen. Diese Verwirrung liegt oftmals nicht zuletzt daran, dass „Sicherheit“ in der Industrie anders besetzt ist als in der IT.
Firmen müssen die wirtschaftlichen Vorteile gegenüber den Gefahren durch Bedrohungen abwägen. Die möglichen Risiken lassen sich aber nur nach einer ausführlichen Risikobewertung einschätzen – ein Schritt, der leider zu oft komplett übergangen wird. Stattdessen werden technische und organisatorische Lösungen eingeführt, deren Nutzen zuweilen fragwürdig und häufiger mangels Risikobewertung nicht nachweisbar ist.
Während der deutsche Begriff der „Sicherheit“ mehrdeutig belegt ist, trennt die englische Sprache wesentlich schärfer zwischen „Safety“ und „Security“. Die physische Sicherheit des Bedieners im Zusammenhang mit einer Maschine, einem Ablauf oder Produktionsprozess bezeichnet man als „Safety“: „Security“ wiederum benennt die Sicherheit von (IT)-Systemen, also etwa den Schutz vor Angreifern oder vor Sabotage. Auch hier haben sich verschiedene Normen und Rahmenwerke etabliert, welche die Modellierung und Risikobewertung von IT-Systemen definieren.
Auffällig sind die Unterschiede bei Risikobewertung und -analyse: Bei einer Safety-Risikobewertung ist der Prozess irgendwann beendet, weil das Restrisiko genügend gemindert wurde oder nicht weiter gemindert werden kann. Bei einer Security-Risikobewertung ist die Analyse und Minimierung des Risikos ein kontinuierlicher Prozess. Betrachtet man beide Bereiche zusammen, zeigt sich: Eine Risikobewertung umfasst alle Ebenen – auch jene, die durch die Beurteilungen der einzelnen Prozesse schon abgedeckt sind. Hinzu kommen unterschiedliche Optimierungsziele, auch die Dauer des Bewertungsprozesses unterscheidet sich grundlegend. Und schließlich kann ein Risiko, das aus Safety-Sicht zu vernachlässigen ist, aus Security-Sicht unter Umständen ein unüberwindbares Hindernis darstellen.
Wer greift an und wozu?
Ein Beispiel sind Fernwartungsmechanismen. Wurden diese in der Vergangenheit häufig über dedizierte (Einwahl-)Verbindungen realisiert, ist heute der Zugriff über das Internet üblich. Die Security dieser Mechanismen wird durch Passwörter und das „Prinzip des Nicht-Wissens“ sichergestellt. Leider macht hier die IT-Security einen großen Strich durch die Rechnung. „Security-through-Obscurity“ ist nachweislich keine gute Strategie.
Dass es bei öffentlich zugänglichen Systemen nur eine Frage der Zeit ist, bis jemand „anklopft“, zeigen Modellversuche immer wieder: Forscher von Trend Micro wollten etwa wissen, wer welche Teile der mit dem Internet verbundenen ICS-Systeme und SCADA-Netze und mit welchem Ziel angreift. Dafür wählten sie eine Kleinstadt in den USA. In einer fiktiven Pumpstation erstellten sie ein Wasserdruck-Kontrollsystem, das im Internet sichtbar war und bis auf die Wasserpumpen alle Komponenten aufwies: Neben Steuerungseinheiten und Computern auch online abrufbare technische Dokumentationen, die angeblich von der Stadtverwaltung stammten. Die drei Honeypots ahmten ICS- und SCADA-Geräte nach, die mit dem Internet verbunden sind, und enthielten herkömmliche Schwachstellen, wie sie in den meisten derartigen Systemen vorkommen.
Von den 25 Angriffen innerhalb eines knappen Monats lassen sich zwölf als „gezielt“ klassifizieren, die anderen 13 wurden von einem oder mehreren Absendern an mehreren Tagen wiederholt ausgeführt – sie kann man als „gezielt“ und/oder „automatisiert“ beschreiben. Es zeigte sich, dass auch an einer so „harmlosen“ Sache wie Wasserpumpen ein buchstäblich weltweites Interesse besteht. Während manche Angreifer vor allem an den technischen Details interessiert waren, versuchten andere, die Systeme zu beeinflussen oder zu zerstören. Was bei einer realen Pumpe nicht nur wirtschaftlich schädlich, sondern unter Umständen lebensgefährlich hätte werden können.
Der Heilige Gral?
Als beste Lösung aller Security-Probleme für die Fabrik der Zukunft wird zurzeit häufig „Security by Design“ herausgestellt. Doch dabei schießen viele übers Ziel hinaus und propagieren das komplette Neu-/Wiedererfinden sämtlicher Funktionalitäten. Das ist aber wirtschaftlich noch aus Security-Sicht sinnvoll.
Auch wird in diesem Zusammenhang oft die ISO-27034-Norm angeführt, die aber nicht die sichere (Neu-)Entwicklung aller Softwaresysteme definiert, sondern die Entwicklung sicheren Designs, also auch die Nutzung bestehender Komponenten, die durch entsprechende Maßnahmen gesichert werden.
Es geht also ausdrücklich auch um Standard-IT-Komponenten, auch wenn es in der Office-IT natürlich keine Security-Lösungen für SPS-Komponenten gibt. Bei SCADA- oder nachgelagerten Systemen aber kommen Standardsoftwarekomponenten zum Einsatz, die sich auch mit Office-IT-Security-Lösungen absichern lassen: Ob eine Gateway-Lösung die Inhaltssicherheit beim Übergang zwischen Office-Netzen untereinander überwacht oder den Übergang zwischen jenen und Prozessleitsystemnetzwerken, die zugrunde liegende Technik ist identisch. Unterschiede gibt es allenfalls in den Einstellungen und Richtlinien.
Um die wirtschaftlichen Vorteile einer Fabrik der Zukunft wirklich auszuschöpfen, müssen Produktion und IT zusammen an einer sicheren Einführung der Konzepte arbeiten. Dazu müssen sie auch die Sprache und Sichtweise der anderen Seite verstehen. Eine nicht koordinierte Einführung führt dazu, dass Security-Probleme übersehen werden und mit unpassenden Lösungen adressiert werden. Nur nach einer Risikobewertung, die „Safety“ und „Security“ betrachtet, lässt sich die Frage, ob die Einführung wirtschaftlich ratsam ist, beantworten.
