Marcus Geiger: Herr Zeh, Sie sind erfahrener Experte für Safety & Security. Welche Punkte gilt es bei der Vorbereitung von Teamprojekten mit Bezug zur Security und Safety zu beachten?
Martin Zeh: Zunächst einmal muss man zwischen zwei Arten von Projekten unterscheiden. Einerseits gibt es das firmeninterne Projekt zur Verbesserung der Security oder Safety, andererseits ein Auditierungsprojekt bei dem ein externer Auditor eine Prüfung durchführt. Aufgrund meiner Tätigkeit als Auditor betrachten wir hier den zweiten Fall. Im Grunde geht es dabei um die Bewertung der Arbeit anderer Leute. Bei der Vorgehensweise gibt es allerdings keine großen Unterschiede. In beiden Projektarten müssen ähnliche Faktoren beachtet werden, zum Beispiel die “Traceability” und “Testability”. Das bedeutet, dass jede Änderung auf eine Anforderung und einen Verantwortlichen zurückgeführt werden kann, sowie der Erfolg von Maßnahmen testbar sein muss.
„Durch strukturierten Umgang mit Safety- und Security-Wissen steigt auch langfristig die Qualität der angebotenen Produkte und Leistungen erheblich und lohnt sich somit für das Unternehmen.“
Auch wenn in diesem Bereich Normen eine wichtige Rolle spielen, geht es vor allem auch darum, über die Anforderungen der Norm hinaus eine Nachhaltigkeit in den Unternehmen zu schaffen. Diese resultiert vor allem aus einer strukturierten und sauberen Dokumentation, die auch nach dem Ausscheiden von Mitarbeitern und 10 bis 20 Jahre nach dem Projekt einen reibungslosen Betrieb gewährt. Der Grundstein des langfristigen Erfolgs solcher Projekte liegt also in der Informationsaufbewahrung. Durch strukturierten Umgang mit Safety- und Security-Wissen steigt auch langfristig die Qualität der angebotenen Produkte und Leistungen erheblich und lohnt sich somit für das Unternehmen. Weiterhin wird auch die Haftbarkeit in Bezug auf Safety-Vorfälle vermindert.
Diese Aspekte müssen jedem Projektteilnehmer klar sein, bevor das Projekt beginnt. Alle Beteiligten, egal ob aus dem Safety- oder Security-Bereich, müssen auf diese Art der Durchführung geschult sein. Grundlage hierfür bieten vorbereitende Awareness-Maßnahmen und während des Projektverlaufs fortlaufende Schulungen. Diese Art von Projekt kann ja mehrere Monate bis Jahre dauern. Bei Safety-Projekten existiert bereits eine Kompetenzmatrix, mit der man die Rollenverteilung übernehmen kann. Mein Vorschlag wäre hier, dies auch für Security-Projekte einzuführen und zu benutzen. Besonders betonen möchte ich auch eine gute Kommunikation, die für den Projekterfolg unerlässlich ist. Hier gilt es, durch flache Hierarchien und das Recht eines Jeden, etwas zu sagen, dies zu ermöglichen.
Marcus Geiger: Welche Maßnahmen sehen Sie als geeignet an, wenn es zu Kommunikationsschwierigkeiten innerhalb des Projekt-Teams kommt?
Martin Zeh: Aufgrund der Langwierigkeit solcher Projekte gilt es, eine regelmäßige Kommunikation aufrecht zu erhalten. Hier können Statusberichte helfen, die alle paar Monate erstellt und verteilt werden, oder auch Telefonate und Videokonferenzen. Wichtig ist es, potenzielle Schwierigkeiten rechtzeitig zu erkennen und dadurch frühzeitig intervenieren zu können. Im Gegensatz zu Projekten aus der Softwareentwicklung sind wöchentliche oder gar tägliche Meetings nicht unbedingt notwendig.
Hervorzuheben ist auch, dass es eine interne und externe Kommunikation gibt. Bei der internen Kommunikation kann es zwar auch zu Schwierigkeiten kommen, doch die Wege sind hier meist kürzer. Bei der externen Kommunikation, zum Beispiel mit dem Auditor oder einem Lieferanten, ist die klare Regelung der Kontaktperson wichtig, zum Beispiel der Projektleiter, sodass es einen Kommunikationsknoten gibt und nicht mehrere. Gerade wenn es um Audits durch Externe geht, ist es besonders hilfreich, den Auditor schon zu Projektbeginn mit einzubeziehen, damit von vornherein in eine passende Richtung gearbeitet wird.
„Aufgrund der unterschiedlichen Blickwinkel der beteiligten Gewerke kann es dann doch einmal krachen. Hier gilt es, Probleme zeitnah anzugehen und zu lösen, sonst werden diese immer größer.“
Aufgrund der unterschiedlichen Blickwinkel der beteiligten Gewerke kann es dann doch einmal krachen. Hier gilt es, Probleme zeitnah anzugehen und zu lösen, sonst werden diese immer größer. Im Zweifel muss es auch einen bereits im Vorfeld benannten Streitschlichter geben, der bei Bedarf hinzugezogen werden kann.
Marcus Geiger: Welche Faktoren sind wichtig, wenn man die Security an Personal aus der OT heranträgt?
Martin Zeh: Personal aus der OT besitzt häufig kein klares Bild zu den vielen verschiedenen Bedrohungen, die es im Zusammenhang mit IT gibt. Daher muss man hier vor allem die Awareness und Grundkenntnisse zu diesen Aspekten steigern. Dabei muss OT-Personal allerdings nicht selbst alle der Herausforderungen lösen können, aber zumindest in der Lage sein, diese einzuschätzen und zu wissen, wer die richtige Ansprechperson ist und wie man ihr die Umstände kommuniziert. Kurzgesagt: Erkennen, wo Probleme entstehen können.
Im OT-Bereich herrschen aus IT-Sicht teils noch schlimme Zustände. Dort werden Laptops mit Windows XP mit nach Hause genommen, privat gesurft, Programme installiert und dann wieder an die Anlagen angeschlossen. Auf der anderen Seite wird das natürlich auch dadurch gefördert, dass das OT-Personal nicht richtig arbeiten kann, weil die IT deren Infrastruktur nicht unterstützt und keine Alternativen bietet. Hier müssten definierte Laptops mit Werkzeugen zur Automatisierung und Safety-Konfiguration her, die von den IT-Abteilungen unterstützt werden.
Marcus Geiger: Betrachten wir die andere Seite: Welche Faktoren sind wichtig, wenn man die Safety an Personal aus der IT heranträgt?
Martin Zeh: Security-Personal muss verstanden haben, wie die Safety funktioniert und welche Sichtweise die OT besitzt. Die dort eingesetzten Geräte und Systeme sind nicht vergleichbar mit typischer Office-IT und sind zum Beispiel Micro-Controller, Embedded Systeme und SPS. Auch die Netzwerktechnologien unterscheiden sich stark. Diese sind im OT-Umfeld sehr hardwarenah wie zum Beispiel Bus-Systeme und nutzen proprietäre Protokolle. Wichtige Faktoren sind vor allem die Verfügbarkeit und das Echtzeitverhalten der Hardware.
„Daher muss IT-Personal auch geschult werden, um die Anforderungen und Bedürfnisse des Automatisierungspersonals verstehen zu können.“
Die klassische IT-Security kennt sich hiermit nicht gut aus. Grundlage hierfür wäre eher die Elektrotechnik. Daher muss IT-Personal auch geschult werden, um die Anforderungen und Bedürfnisse des Automatisierungspersonals verstehen zu können. Dafür sollten natürlich zu Projektbeginn entsprechende Schulungen durchgeführt werden.
Marcus Geiger: Wie läuft ein Safety & Security Projekt im Optimalfall ab? Welche verschiedenen Stufen gibt es?
Martin Zeh: Normalerweise werden gerade Safety-Projekte nach dem V-Modell durchgeführt. Wie bereits vorher erklärt, kann die Vorgehensweise jedoch auch bei Security-Projekten angewendet werden. Begonnen wird der Lifecycle dabei mit der Anforderungsanalyse. Danach folgt die Entwicklung der Architektur. Hier gibt es für Safety und Security gewisse Vorgaben und Best-Practices, zum Beispiel “Least Privilege”. Abgeleitet von der Architektur werden die Änderungen durchgeführt oder entwickelt. Hierbei ist es wichtig auf deren Modularisierung und Einhaltung von Coding-Rules zu achten, damit die Wartbarkeit und Wiederbenutzbarkeit gefördert wird. Anschließend werden zum Beispiel Unit-Tests durchgeführt, um die korrekte Funktion nachzuweisen. Bei jeder dieser Stufen ist auch darauf zu achten, dass eine Verifikation der Änderungen und Maßnahmen erfolgt. Abschließend kommt als letzter Schritt die Validierung, also die Prüfung der korrekten Funktion im Gesamtkontext.
Marcus Geiger: Welche typischen Probleme bergen diese Projektarten?
Martin Zeh: Es ist wenig Know-How vorhanden und es gibt noch keine pragmatischen Richtlinien, an die sich Unternehmen halten können. Diese Faktoren muss sich die Industrie nun erst einmal erarbeiten, damit langfristig sinnvolle und durchführbare Maßnahmenkataloge entstehen. Bis dahin wird auch weiterhin Unsicherheit herrschen, zum Beispiel auch bei den Fragestellungen “Wie führe ich eine kombinierte Safety und Security Risikoanalyse durch?”, “Was sind die minimal umzusetzenden Maßnahmen?” und bezogen auf die IEC 62443 “Was erwarte ich von welchem Security Level-Wert?”. Das Hauptproblem stellt aufgrund ihres jungen Alters momentan noch die Industrial Security dar. Hier müssen auch die Normen erst noch reifen, bevor diese pragmatisch umgesetzt werden können. Außer vielleicht Common Criteria, jedoch lässt sich diese Norm in der Industrie nicht anwenden, weil dadurch viel zu hohe Kosten entstehen würden. Es braucht kostengünstige Lösungen, die praktikabel sind.
„Das Hauptproblem stellt aufgrund ihres jungen Alters momentan noch die Industrial Security dar.“
Ein weiteres Problem stellt der Unterschied in der Dynamik zwischen Safety & Security dar. Safety ist sehr statisch und meist gut testbar. Security hingegen hoch dynamisch und oftmals intransparent. Die aus der klassischen IT-Sicherheit üblichen Patches sind zum Beispiel im Safety Umfeld mit sehr hohen Aufwänden verbunden, da dort bei jedem noch so kleinen Patch eine “Impact Analyse” und erneute Tests durchgeführt werden müssen. Hier könnte ein Vorschlag sein, die Safety & Security möglichst voneinander zu trennen und die jeweiligen Auswirkungen so klein wie möglich zu halten. Dies geschieht vor allem in der Anforderungsaufnahme und Architekturphase.
Marcus Geiger: Wie kann die gemeinsame Betrachtung von Safety & Security zum Fortschritt der digitalen Industrie beitragen?
Martin Zeh: Meiner Meinung nach ist die Digitalisierung in der Industrie nur dann möglich, wenn man beide Felder kombiniert betrachtet. Ohne diese Themen zu beachten holt man sich schlicht und einfach viel zu große Risiken mit unbekannten Auswirkungen ins Haus. Es ist fahrlässig, sich nicht zu Beginn schon Gedanken darum zu machen und wird damit im Gesamtkontext eine Gefahr für die Digitalisierung.
Marcus Geiger: Herr Zeh, ich danke Ihnen für die ausführlichen Antworten und spannenden Einblicke in die Herausforderungen kombinierter Safety & Security-Projekte.
Martin Zeh ist Experte für Functional Safety und Industrial Security beim SGS-TüV Saar und hat jahrzehntelange Erfahrung im Bereich der Embedded Softwareentwicklung und Sicherheitsaudits im Industriebereich.
Der Industrial Security Guide zum schnellen Einstieg
CEO & Founder
Industrie 4.0, Digitalisierung u. steigende Vernetzung. Die OT- und OT-Security Welt wächst stetig weiter, da ist ein schneller Einstieg manchmal sehr schwer.
Aus diesem Grund haben haben wir einen Einstiegsguide zur Industrial Security geschrieben, der ihnen kurz und knapp die wichtigsten Themen nahelegt.
Hier gehts zum Download!
