Sicherheit als Regelkreis Wie Sie Security schrittweise weiterentwickeln

An der Rolle der Sicherheit scheiden sich nach wie vor die Geister. Während beispielsweise für IT-Experten die aktive Suche nach Sicherheitslücken an der Tagesordnung und das sofortige Patchen gefährdeter Systeme in Fleisch und Blut übergegangen sind, ruft das Publizieren der Lücken bei ihren Produktions-Kollegen instinktiv Abwehrreaktionen hervor.

Wenn umgekehrt auf den Rechnern der Kontrollsysteme keine Software installiert sein oder verändert werden darf oder wenn die Gesamtsysteme auf eine Laufzeit von über zehn Jahren ausgelegt sind, sind Vertreter der reinen IT-Sicherheitslehre meist sichtlich irritiert.

Welche Auswirkungen haben Fehlfunktionen in einer Produktionsstraße? Was passiert, wenn ein Roboter in seinem programmierten Arbeitsablauf gestört wird? Um das zu veranschaulichen, durchlief auf Trend Micros Messestand während der Hannover Messe ein Roboter einen programmierten Arbeitsablauf; simuliert wurde ein Wartungszugriff, bei dem das Steuergerät manipuliert wurde.

Sprechen Sie Sicherheit?

Um zusammenarbeiten zu können, müssen Produktions- und IT-Industrie also die jeweils andere Seite verstehen. Und das beginnt schon bei den Begriffen. Anders als beim deutschen Begriff Sicherheit wird im Englischen viel schärfer zwischen Safety und Security getrennt. Bei Safety handelt es sich um einen gut dokumentierten Prozess, für den es verschiedene Normen und Richtlinien gibt, die sich mit der Risikobewertung beschäftigen. Für Security haben sich ebenfalls verschiedene Normen und Rahmenwerke etabliert, welche die Modellierung und Risikobewertung von IT-Systemen definieren. Stellvertretend hierfür sind die ISO-27xxx-Normen zu nennen, die in der Regel Bestandteil einer Vorgehensweise nach BSI IT-Grundschutz sind.

Alles hat ein Ende, nur Security hat keins...

Unterschiede gibt es bei der Risikobewertung und -analyse: Im Safety-Bereich ist der Prozess irgendwann beendet, weil das Restrisiko genügend gemindert wurde (beispielsweise durch Einsatz einer Glaswand zum Schutz vor herumfliegenden Werkstücken) oder nicht genügend gemindert werden kann. Dann wird das Restrisiko dokumentiert, und die Risikobewertung ist beendet. Im Security-Bereich hingegen erfolgen Risiko-Analyse und -Minimierung als kontinuierlicher Prozess. Endpunkt gibt es hier keinen.

Im eingangs erwähnten Experiment konnte gezeigt werden, wie sich mittels eines mehrschichtigen Schutzansatzes und der Betrachtung von Security als Lifecycle Gefahren identifizieren und abwehren lassen. Andernfalls hätte eine solche – versehentliche oder absichtliche – Manipulation zum Stillstand oder der Beeinträchtigung der Produktion führen können.

Risikobewertung

Betrachtet man die beiden Bereiche Safety und Security zusammen, zeigt sich: Eine Risikobewertung umfasst alle Ebenen – auch die schon durch die Beurteilungen der einzelnen Prozesse abgedeckten. Hinzu kommen verschiedene 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 – und umgekehrt.

Bei Fernwartungsmechanismen beispielsweise ist heute der Zugriff über das Internet üblich, früher waren es häufig dedizierte (Einwahl-)Verbindungen. Die Security wird in der Regel durch Passwörter und das Prinzip des Nicht-Wissens sichergestellt. Doch security through obscurity, also Sicherheit durch die Geheimhaltung bestimmter Informationen, ist nachweislich keine gute Strategie – zumindest wenn diese sich nicht allein auf Passwörter oder Zugangsschlüssel bezieht, sondern auf den Aufbau von Schnittstellen oder Umfang und Syntax von integrierten Funktionen. Genau wie fest verdrahtete Passwörter für Service-Zwecke sind solche Informationen irgendwann im Internet zu finden und taugen daher nicht als Basis für eine Sicherheitsstrategie im professionellen Umfeld wie der Industrie.

Ähnlich verhält es sich bei ICS-/SCADA-Netzen, die sich ursprünglich in einer eigenen Welt proprietärer Protokolle auf speziellen Plattformen sowie einer darauf zugeschnittenen Kommunikationsinfrastruktur befanden und von anderen Netzwerken (einschließlich Internet) abgeschnitten waren. Weil nun immer häufiger Standard-Hard- und Software eingesetzt wird und sie mit externen Netzwerken verbunden sind, sind die Netzwerke auch den aus der IT bekannten Gefahren ausgesetzt. Dass es bei öffentlich zugänglichen Systemen nur eine Frage der Zeit ist, bis etwas passiert, zeigen Modellversuche immer wieder.

Standard-IT-Komponenten

Wie bereits gesagt: security through obscurity ist keine gute Strategie, gerade angesichts der allgegenwärtigen Vernetzung und Digitalisierung. Als wirksame Lösung aller Security-Probleme für Industrie 4.0 wird häufig Security by Design herausgestellt. Hier propagieren viele das komplette Neu- beziehungsweise Wiedererfinden sämtlicher Funktionalitäten – und schießen dabei über das Ziel hinaus. Denn das ist weder wirtschaftlich noch aus Security-Sicht sinnvoll. Auch wird in diesem Zusammenhang oft die Norm ISO 27034 genannt. Doch die definiert beileibe nicht die sichere (Neu-)Entwicklung aller Softwaresysteme, sondern die Entwicklung sicheren Designs. Also auch die Nutzung bestehender Komponenten, die durch entsprechende Maßnahmen gesichert werden.

Das heißt: Es geht ausdrücklich – im Rahmen der Industrie­normen und natürlich innerhalb bestimmter Grenzen – auch um Standard-IT-Komponenten. Natürlich gibt es in der Office-IT keine Security-Lösungen für SPS-Komponenten. Aber schon bei SCADA- oder nachgelagerten Systemen kommen Standardsoftwarekomponenten und -betriebssysteme zum Einsatz. Und die lassen sich auch mit Office-IT-Security-Lösungen absichern. Ob eine Gateway-Lösung die Inhaltssicherheit beim Übergang zwischen Office-Netzen untereinander oder den Übergang zwischen jenen und Prozessleitsystemnetzwerken überwacht, die zugrunde liegende Technik ist identisch. Wenn es Unterschiede gibt, dann in den Einstellungen und Richtlinien.

Nennenswert in diesem Zusammenhang ist ein Werkzeug des Bundesamtes für Sicherheit in der Informationstechnik: LARS (Light And Right Security) bietet eine fragengeleitete Selbsteinschätzung des aktuellen Stands der Security, gibt Empfehlungen, welche Maßnahmen in welchen Bereichen als nächstes umgesetzt werden sollten – und möchte kleinen und mittleren Unternehmen den Einstieg in die Security erleichtern.